Re: WebPOS Setup

[Taher Alkhateeb]

Hi

I'm not sure if this would help, but the readers has only seed data, perhaps 
adding seed-initial might solve some problems?

> On Apr 7, 2017, at 12:28 AM, stim...@comcast.net wrote:
> 
> Hi,
> 
> Thought I'd summarize with some specific steps since I've made progress, but 
> still fail (writing down to explain to others might help me catch my own 
> mistakes too).
> 
> Problem: I need WebPOS to work on a brand new install using my own 
> hand-entered data for a real retail store (versus demo data). WebPOS login 
> page can be reached, but login cannot occur because there are no terminals. 
> Apparently terminals cannot be added until there is a retail store. Creating 
> the retail store and associating terminals is failing.
> 
> The explicit steps:
> 
> I drop the PostgreSQL DBs (to clear old data), recreate them, then run:
> ./gradlew 'ofbiz --load-data readers=seed'
> 
> I then create "admin" user via:
> ./gradlew loadAdminUserLogin -PuserLoginId=admin
> 
> Start ofbiz:
> ./gradlew ofbiz
> 
> Under the setup app I create Company (requires admin password update first, 
> Party Id "Company" created by manually typing in info of a real company):
> https://localhost:8443/ofbizsetup/control/initialsetup
> 
> Go to Catalog Manager->Stores, click New Product Store. "Primary Store Group 
> Id" can't be selected or entered ("Not Applicable [_NA_]" is all that is 
> there), the drop-down is empty other than "Not Applicable" (so I pick Not 
> Applicable). Set Store Name to "Main Store". It isn't a demo store, and I 
> don't know what the effect is, but I pick drop-down of "Is Demo Store" as 
> "N". Everything else is unmodified and default. Click Update. Error rejects 
> adding the store: "Inventory Facility Id Required".
> 
> Summary 1: Store cannot be added via Catalog Manager until an Inventory 
> Facility Id is created.
> 
> I switch now to Applications->Facility Manager. "Main" or "Facilities" is 
> only for searching, not for adding a Facility. This is where the prior email 
> reply mentions to do this under Asset Management, but Asset 
> Management->Facility is also only for searching, not for creating a Facility. 
> Perhaps it is a Fixed Asset?
> 
> Summary 2: The required Facility Id of Summary 1 cannot be added under 
> Applications->Facility Manager. Asset Management->Facility is also a search 
> mechanism, and cannot be used to add the required facility.
> 
> Under Fixed Asset I can click "New Fixed Asset". Is it "Real Estate", 
> "Property", or "Other"? Real Estate is chosen since it is most descriptive 
> (Property might be a tract of land, Real Estate is more specific since it 
> implies a building on the land). When I get to RoleType ID I am convinced 
> this is not the correct place to create a facility.
> 
> Summary 3: I can add a new fixed asset, but it does not seem to give me a 
> Facility Id. Perhaps I missed a detail.
> 
> Under Applications->Facility Manager->Facility Groups I can click "New 
> Group". The only part I can logically add is Facility Group Name, and I add 
> "Retail Facility" in that text entry box. This fails. Although nothing is 
> marked as mandatory, submitting this requires a currently missing parameter, 
> "createFacilityGroup.facilityGroupTypeId". I don't really know if the 
> Facility type is Management Structure, or if it is Pricing Group, but it 
> seems Management Structure is more logical for a structure serving a 
> store...I pick this. It works, I now have a Management Structure with 
> Facility Group Name "Retail Facility". I don't have a Facility Id.
> 
> Summary 4: I can add a Facility Group, but I'm unsure how to use this to 
> create a Facility. I don't  believe this is the right approach.
> 
> I'm now at a loss as to how to add a Facility since I've only found how to 
> edit a facility which already exists in Asset Manager; Facility Manger is 
> definitely the wrong place. If Asset Manager can add a facility and produce a 
> Facility Id, how is this done? Do I need to think of my Retail Store as a 
> Fixed Asset of type Real Estate?
> 
> Thanks!

Re: Default key size

[Paul Mandeltort]

https://cwiki.apache.org/confluence/display/OFBIZ/Data+Model+Diagrams 

Print these up and frame them, I wish I had found them earlier in my OFbiz 
journey. Will quickly show you how everything fits together. My greatest regret 
was not finding them sooner. They’re a little dated but still 95% accurate 
especially for getting going. 

Good place to store UPC information is here: 
https://demo-stable.ofbiz.apache.org/catalog/control/EditProductGoodIdentifications?productId=GZ-1000
 


Then you can use an arbitrary schema for your top-level product catalog which 
is always a good idea. 

I suggest avoiding modifying the core data model if at all possible to protect 
yourself down the road for upgrades. It’s pretty easy to paint yourself into a 
corner if you start modifying that stuff unnecessarily. 

—P


> On Apr 6, 2017, at 4:01 PM, Mike  wrote:
> 
>> Under your proposed data import integration, you’ll have to maintain
> descriptions, titles, content, pricing, associations, variants, etc FOR
> EVERY SUPPLIER.  You’ll go insane.
> 
> Awesome advice Paul, and a great example.  It's definitely better to just
> use the UPC (in my case), and maintain the supplier table. For stuff that
> *I* control (like products, descriptions, content, electronictext, etc), I
> prefer to use primary keys that I control.  For all other stuff (sales
> orders, invoices, etc.) ofbiz can take care of that.  Thanks a lot.
> 
> On Thu, Apr 6, 2017 at 10:59 AM, Paul Mandeltort  wrote:
> 
>> While I don’t know the details of your application, sounds like you are
>> trying to hardcode a join into the ProductID primary key which is just
>> going to lead you to a world of pain down the road.
>> 
>> OFbiz supports composite/compound primary keys which in many cases
>> eliminates the need for an arbitrary unique identifier.
>> https://en.wikipedia.org/wiki/Compound_key > wiki/Compound_key> OFbiz uses these extensively in sub entities. Look in
>> the entity reference (/webtools/control/entityref) you’ll see the primary
>> keys in red.
>> 
>> The supplierProduct entity is already setup with a composite primary key
>> OOTB.
>> Product.ProductID-PartyID-MOQ-Currency guarantees uniqueness within the
>> entity.
>> 
>> Why crap up your Product entity with redundant information that should be
>> kept in the supplier table? Products should be things that are, to an
>> end-user, unique. A hardware store, for example, sells framing 2x4’s from
>> thousands of suppliers, but the same end-user Product number is applied to
>> them. Under your proposed data import integration, you’ll have to maintain
>> descriptions, titles, content, pricing, associations, variants, etc FOR
>> EVERY SUPPLIER.  You’ll go insane.
>> 
>> Need to select, delete, etc all your products from a supplier? Just do the
>> simple joined query:
>> 
>> SELECT FROM supplierProduct WHERE
>>supplierProduct.productId=1 AND
>>supplier.productManufacturerCode=798936836182.
>> 
>> That’s the same.
>> 
>> supplier.productManufacturerCode is currently not part of the
>> SupplierProduct composite key but you could make it one if you’d like.
>> 
>> The 20 character limit is there for a reason - IDs (such as productId) are
>> used in MANY areas of Ofbiz, including forms like invoices, sales orders,
>> purchase orders, barcodes, receipts, etc, so having a known sane limit
>> there enables consistency throughout the business processes.  I wouldn’t
>> mess with it.
>> 
>> You gotta remember that Ofbiz is far from “finished”, In many areas,
>> human-readable values are “encoded” into ID fields as a shortcut to avoid
>> creating lookup entities for that information and to simplify programming
>> for things that only ever have a handful of values in the entity like with
>> the roleTypeId=“INTERNAL_ORGANIZATIO” that was mentioned originally,
>> 
>> As a general rule, if you find yourself trying to change the framework for
>> your convenience, take a real good hard look as to why you’re doing that.
>> Every time I try to take shortcuts with the data model because I’m too lazy
>> to get my data cleaned up to fit it, I ALWAYS regret it,100% of the time,
>> often years later.
>> 
>> Hope that helps!
>> —P
>> 
>> 
>> 
>>> On Apr 6, 2017, at 12:34 AM, Mike  wrote:
>>> 
>>> Apologies for the absurd reference.  Certainly the screen real estate is
>>> the biggest issue.  Sure, it is nice to display primary keys within 20
>>> characters...
>>> 
>>> But let me give you a working example.  In fact, this was a real issue
>> with
>>> me, considering the import of products.  Sure, I could have assigned a
>>> non-meaningful sequential number, but I like real reference, like a part
>>> number or UPC code.  In my case, multiple suppliers may carry the same
>> UPC,
>>> so I elected to create the primary k

Re: WebPOS Setup

[stimits]

Hi,
 
Thought I'd summarize with some specific steps since I've made progress, but 
still fail (writing down to explain to others might help me catch my own 
mistakes too).
 
Problem: I need WebPOS to work on a brand new install using my own hand-entered 
data for a real retail store (versus demo data). WebPOS login page can be 
reached, but login cannot occur because there are no terminals. Apparently 
terminals cannot be added until there is a retail store. Creating the retail 
store and associating terminals is failing.
 
The explicit steps:
 
I drop the PostgreSQL DBs (to clear old data), recreate them, then run:
./gradlew 'ofbiz --load-data readers=seed'
 
I then create "admin" user via:
./gradlew loadAdminUserLogin -PuserLoginId=admin
 
Start ofbiz:
./gradlew ofbiz
 
Under the setup app I create Company (requires admin password update first, 
Party Id "Company" created by manually typing in info of a real company):
https://localhost:8443/ofbizsetup/control/initialsetup
 
Go to Catalog Manager->Stores, click New Product Store. "Primary Store Group 
Id" can't be selected or entered ("Not Applicable [_NA_]" is all that is 
there), the drop-down is empty other than "Not Applicable" (so I pick Not 
Applicable). Set Store Name to "Main Store". It isn't a demo store, and I don't 
know what the effect is, but I pick drop-down of "Is Demo Store" as "N". 
Everything else is unmodified and default. Click Update. Error rejects adding 
the store: "Inventory Facility Id Required".
 
Summary 1: Store cannot be added via Catalog Manager until an Inventory 
Facility Id is created.
 
I switch now to Applications->Facility Manager. "Main" or "Facilities" is only 
for searching, not for adding a Facility. This is where the prior email reply 
mentions to do this under Asset Management, but Asset Management->Facility is 
also only for searching, not for creating a Facility. Perhaps it is a Fixed 
Asset?
 
Summary 2: The required Facility Id of Summary 1 cannot be added under 
Applications->Facility Manager. Asset Management->Facility is also a search 
mechanism, and cannot be used to add the required facility.
 
Under Fixed Asset I can click "New Fixed Asset". Is it "Real Estate", 
"Property", or "Other"? Real Estate is chosen since it is most descriptive 
(Property might be a tract of land, Real Estate is more specific since it 
implies a building on the land). When I get to RoleType ID I am convinced this 
is not the correct place to create a facility.
 
Summary 3: I can add a new fixed asset, but it does not seem to give me a 
Facility Id. Perhaps I missed a detail.
 
Under Applications->Facility Manager->Facility Groups I can click "New Group". 
The only part I can logically add is Facility Group Name, and I add "Retail 
Facility" in that text entry box. This fails. Although nothing is marked as 
mandatory, submitting this requires a currently missing parameter, 
"createFacilityGroup.facilityGroupTypeId". I don't really know if the Facility 
type is Management Structure, or if it is Pricing Group, but it seems 
Management Structure is more logical for a structure serving a store...I pick 
this. It works, I now have a Management Structure with Facility Group Name 
"Retail Facility". I don't have a Facility Id.
 
Summary 4: I can add a Facility Group, but I'm unsure how to use this to create 
a Facility. I don't  believe this is the right approach.
 
I'm now at a loss as to how to add a Facility since I've only found how to edit 
a facility which already exists in Asset Manager; Facility Manger is definitely 
the wrong place. If Asset Manager can add a facility and produce a Facility Id, 
how is this done? Do I need to think of my Retail Store as a Fixed Asset of 
type Real Estate?
 
Thanks!
 

Re: Default key size

[Mike]

> Under your proposed data import integration, you’ll have to maintain
descriptions, titles, content, pricing, associations, variants, etc FOR
EVERY SUPPLIER.  You’ll go insane.

Awesome advice Paul, and a great example.  It's definitely better to just
use the UPC (in my case), and maintain the supplier table. For stuff that
*I* control (like products, descriptions, content, electronictext, etc), I
prefer to use primary keys that I control.  For all other stuff (sales
orders, invoices, etc.) ofbiz can take care of that.  Thanks a lot.

On Thu, Apr 6, 2017 at 10:59 AM, Paul Mandeltort  wrote:

> While I don’t know the details of your application, sounds like you are
> trying to hardcode a join into the ProductID primary key which is just
> going to lead you to a world of pain down the road.
>
> OFbiz supports composite/compound primary keys which in many cases
> eliminates the need for an arbitrary unique identifier.
> https://en.wikipedia.org/wiki/Compound_key  wiki/Compound_key> OFbiz uses these extensively in sub entities. Look in
> the entity reference (/webtools/control/entityref) you’ll see the primary
> keys in red.
>
> The supplierProduct entity is already setup with a composite primary key
> OOTB.
> Product.ProductID-PartyID-MOQ-Currency guarantees uniqueness within the
> entity.
>
> Why crap up your Product entity with redundant information that should be
> kept in the supplier table? Products should be things that are, to an
> end-user, unique. A hardware store, for example, sells framing 2x4’s from
> thousands of suppliers, but the same end-user Product number is applied to
> them. Under your proposed data import integration, you’ll have to maintain
> descriptions, titles, content, pricing, associations, variants, etc FOR
> EVERY SUPPLIER.  You’ll go insane.
>
> Need to select, delete, etc all your products from a supplier? Just do the
> simple joined query:
>
> SELECT FROM supplierProduct WHERE
> supplierProduct.productId=1 AND
> supplier.productManufacturerCode=798936836182.
>
> That’s the same.
>
> supplier.productManufacturerCode is currently not part of the
> SupplierProduct composite key but you could make it one if you’d like.
>
> The 20 character limit is there for a reason - IDs (such as productId) are
> used in MANY areas of Ofbiz, including forms like invoices, sales orders,
> purchase orders, barcodes, receipts, etc, so having a known sane limit
> there enables consistency throughout the business processes.  I wouldn’t
> mess with it.
>
> You gotta remember that Ofbiz is far from “finished”, In many areas,
> human-readable values are “encoded” into ID fields as a shortcut to avoid
> creating lookup entities for that information and to simplify programming
> for things that only ever have a handful of values in the entity like with
> the roleTypeId=“INTERNAL_ORGANIZATIO” that was mentioned originally,
>
> As a general rule, if you find yourself trying to change the framework for
> your convenience, take a real good hard look as to why you’re doing that.
> Every time I try to take shortcuts with the data model because I’m too lazy
> to get my data cleaned up to fit it, I ALWAYS regret it,100% of the time,
> often years later.
>
> Hope that helps!
> —P
>
>
>
> > On Apr 6, 2017, at 12:34 AM, Mike  wrote:
> >
> > Apologies for the absurd reference.  Certainly the screen real estate is
> > the biggest issue.  Sure, it is nice to display primary keys within 20
> > characters...
> >
> > But let me give you a working example.  In fact, this was a real issue
> with
> > me, considering the import of products.  Sure, I could have assigned a
> > non-meaningful sequential number, but I like real reference, like a part
> > number or UPC code.  In my case, multiple suppliers may carry the same
> UPC,
> > so I elected to create the primary key as "SUPPLIER_CODE-UPC".  This way
> I
> > can always work on a set of P/Ns from a given supplier.  So, the primary
> > key becomes: "1-798936836182", already 18 characters.
> >
> >  >  > productCategoryId="10002"...
> >  >  >  idValue="798936836182"...
> >  >  >  **FAIL**
> >  >  > contentId="1-798936836182Den" ...
> >  > contentIdTo="1-798936836182Den"/> ...
> >  > dataResourceId="1-798936836182Len" ...
> >  >  > contentId="1-798936836182Len" ...
> >  > ...etc...
> >
> > And this is a relatively short part number sequence.  If I WANT to pad
> > extra info into the primary key.. for MY convenience, I don't have to
> worry
> > about the import failing due to a 20 character limit somewhere.
> >
> > In addition, setting up the data import as above allows me to quickly
> blow
> > away the product, because all primary keys on all affected tables were
> > created using a consistent pattern.
> >
> > That is all that I am saying.  Once you set up a database, you have to to
> > live with it.
> >
> > On Wed, Apr 5, 2017 at 3:12 PM, Scott Gray  >
> > wrote:
> >
> >> Perhaps lookup performance isn't the on

File template

[Guillaume Fortin]

Hi,

I have some trouble with the project template.

I created a project template named template with some resources, tasks 
and phases. I created a new project (p1) who uses the this template.
The problem is when I go to my time page to add the hours spent on the 
project p1, the tasks do not appear in the list. There is only Template 
task1,  I would like to have p1 task1, p1 task2, etc., for each 
resource listed in the template project. Isn't the main purpose about 
creating a template?


Is there a way to link automatically the tasks, phases and resource to 
the new project from a template?


I have a second question. Is there a way to update a template already 
created?


I want to do it because I have about 80 main tasks and around 20 
resources, so I really don't want to manage it manually

Re: Log Monitoring tool / server with OFBiz

[Sakthivel Vellingiri]

Thanks Michael for your response, will explore zabbix to see if that could
be a fit.

On Tue, Apr 4, 2017 at 4:34 PM, Michael Brohl 
wrote:

> Hi Sakthivel,
>
> We are monitoring our production servers with Zabbix (
> http://www.zabbix.com/). It's not only for log monitoring but also for
> the JVM via JMX, the database, network, Apache Webserver metrics etc..
>
> Best regards,
>
> Michael
>
>
>
> Am 04.04.2017 um 19:57 schrieb Sakthivel Vellingiri <
> info.integ...@gmail.com>:
>
> Hi, Sorry for the blast,
>
> Any recommendations on Open Source Log Monitoring tool/ server that you are
> using in Production with Ofbiz for real-time error monitoring &
> notifications.
>
> Going thru past history, it appears ASF Infra was using Nagios until 2014
> time frame, Not sure if an alternative tool is used currently?
>
> Appreciate any pointers.
>
> regards
>
>

Re: Default key size

[Michael Brohl]

+1

Thanks Paul,

Michael



> Am 06.04.2017 um 19:59 schrieb Paul Mandeltort :
> 
> While I don’t know the details of your application, sounds like you are 
> trying to hardcode a join into the ProductID primary key which is just going 
> to lead you to a world of pain down the road. 
> 
> OFbiz supports composite/compound primary keys which in many cases eliminates 
> the need for an arbitrary unique identifier. 
> https://en.wikipedia.org/wiki/Compound_key 
>  OFbiz uses these extensively in 
> sub entities. Look in the entity reference (/webtools/control/entityref) 
> you’ll see the primary keys in red. 
> 
> The supplierProduct entity is already setup with a composite primary key 
> OOTB. 
> Product.ProductID-PartyID-MOQ-Currency guarantees uniqueness within the 
> entity. 
> 
> Why crap up your Product entity with redundant information that should be 
> kept in the supplier table? Products should be things that are, to an 
> end-user, unique. A hardware store, for example, sells framing 2x4’s from 
> thousands of suppliers, but the same end-user Product number is applied to 
> them. Under your proposed data import integration, you’ll have to maintain 
> descriptions, titles, content, pricing, associations, variants, etc FOR EVERY 
> SUPPLIER.  You’ll go insane. 
> 
> Need to select, delete, etc all your products from a supplier? Just do the 
> simple joined query: 
> 
> SELECT FROM supplierProduct WHERE 
>supplierProduct.productId=1 AND
>supplier.productManufacturerCode=798936836182. 
> 
> That’s the same. 
> 
> supplier.productManufacturerCode is currently not part of the SupplierProduct 
> composite key but you could make it one if you’d like. 
> 
> The 20 character limit is there for a reason - IDs (such as productId) are 
> used in MANY areas of Ofbiz, including forms like invoices, sales orders, 
> purchase orders, barcodes, receipts, etc, so having a known sane limit there 
> enables consistency throughout the business processes.  I wouldn’t mess with 
> it. 
> 
> You gotta remember that Ofbiz is far from “finished”, In many areas, 
> human-readable values are “encoded” into ID fields as a shortcut to avoid 
> creating lookup entities for that information and to simplify programming for 
> things that only ever have a handful of values in the entity like with the 
> roleTypeId=“INTERNAL_ORGANIZATIO” that was mentioned originally, 
> 
> As a general rule, if you find yourself trying to change the framework for 
> your convenience, take a real good hard look as to why you’re doing that.  
> Every time I try to take shortcuts with the data model because I’m too lazy 
> to get my data cleaned up to fit it, I ALWAYS regret it,100% of the time, 
> often years later. 
> 
> Hope that helps!
> —P
> 
> 
> 
>> On Apr 6, 2017, at 12:34 AM, Mike  wrote:
>> 
>> Apologies for the absurd reference.  Certainly the screen real estate is
>> the biggest issue.  Sure, it is nice to display primary keys within 20
>> characters...
>> 
>> But let me give you a working example.  In fact, this was a real issue with
>> me, considering the import of products.  Sure, I could have assigned a
>> non-meaningful sequential number, but I like real reference, like a part
>> number or UPC code.  In my case, multiple suppliers may carry the same UPC,
>> so I elected to create the primary key as "SUPPLIER_CODE-UPC".  This way I
>> can always work on a set of P/Ns from a given supplier.  So, the primary
>> key becomes: "1-798936836182", already 18 characters.
>> 
>> > > productCategoryId="10002"...
>> > > > > > > > > contentId="1-798936836182Den" ...
>> > contentIdTo="1-798936836182Den"/> ...
>> > dataResourceId="1-798936836182Len" ...
>> > > contentId="1-798936836182Len" ...
>> > ...etc...
>> 
>> And this is a relatively short part number sequence.  If I WANT to pad
>> extra info into the primary key.. for MY convenience, I don't have to worry
>> about the import failing due to a 20 character limit somewhere.
>> 
>> In addition, setting up the data import as above allows me to quickly blow
>> away the product, because all primary keys on all affected tables were
>> created using a consistent pattern.
>> 
>> That is all that I am saying.  Once you set up a database, you have to to
>> live with it.
>> 
>> On Wed, Apr 5, 2017 at 3:12 PM, Scott Gray 
>> wrote:
>> 
>>> Perhaps lookup performance isn't the only consideration?
>>> 
>>> A few things come to mind:
>>> - screen realestate when PKs need to be displayed
>>> - bandwidth for syncing to slaves and transporting data to/from the client
>>> - file size for export/import be it XML or whatever
>>> 
>>> Given that PKs shouldn't perform any function beyond guaranteeing
>>> uniqueness within a given table, and that we use numeric sequences for
>>> nonstatic tables, I struggle to see where it makes sense to use anything
>>> bigger than 20 characters. So we have to abbreviate some seed data to fit,
>>> not really a

Re: Default key size

[Paul Mandeltort]

While I don’t know the details of your application, sounds like you are trying 
to hardcode a join into the ProductID primary key which is just going to lead 
you to a world of pain down the road. 

OFbiz supports composite/compound primary keys which in many cases eliminates 
the need for an arbitrary unique identifier. 
https://en.wikipedia.org/wiki/Compound_key 
 OFbiz uses these extensively in 
sub entities. Look in the entity reference (/webtools/control/entityref) you’ll 
see the primary keys in red. 

The supplierProduct entity is already setup with a composite primary key OOTB. 
Product.ProductID-PartyID-MOQ-Currency guarantees uniqueness within the entity. 

Why crap up your Product entity with redundant information that should be kept 
in the supplier table? Products should be things that are, to an end-user, 
unique. A hardware store, for example, sells framing 2x4’s from thousands of 
suppliers, but the same end-user Product number is applied to them. Under your 
proposed data import integration, you’ll have to maintain descriptions, titles, 
content, pricing, associations, variants, etc FOR EVERY SUPPLIER.  You’ll go 
insane. 

Need to select, delete, etc all your products from a supplier? Just do the 
simple joined query: 

SELECT FROM supplierProduct WHERE 
supplierProduct.productId=1 AND
supplier.productManufacturerCode=798936836182. 

That’s the same. 

supplier.productManufacturerCode is currently not part of the SupplierProduct 
composite key but you could make it one if you’d like. 

The 20 character limit is there for a reason - IDs (such as productId) are used 
in MANY areas of Ofbiz, including forms like invoices, sales orders, purchase 
orders, barcodes, receipts, etc, so having a known sane limit there enables 
consistency throughout the business processes.  I wouldn’t mess with it. 

You gotta remember that Ofbiz is far from “finished”, In many areas, 
human-readable values are “encoded” into ID fields as a shortcut to avoid 
creating lookup entities for that information and to simplify programming for 
things that only ever have a handful of values in the entity like with the 
roleTypeId=“INTERNAL_ORGANIZATIO” that was mentioned originally, 

As a general rule, if you find yourself trying to change the framework for your 
convenience, take a real good hard look as to why you’re doing that.  Every 
time I try to take shortcuts with the data model because I’m too lazy to get my 
data cleaned up to fit it, I ALWAYS regret it,100% of the time, often years 
later. 

Hope that helps!
—P



> On Apr 6, 2017, at 12:34 AM, Mike  wrote:
> 
> Apologies for the absurd reference.  Certainly the screen real estate is
> the biggest issue.  Sure, it is nice to display primary keys within 20
> characters...
> 
> But let me give you a working example.  In fact, this was a real issue with
> me, considering the import of products.  Sure, I could have assigned a
> non-meaningful sequential number, but I like real reference, like a part
> number or UPC code.  In my case, multiple suppliers may carry the same UPC,
> so I elected to create the primary key as "SUPPLIER_CODE-UPC".  This way I
> can always work on a set of P/Ns from a given supplier.  So, the primary
> key becomes: "1-798936836182", already 18 characters.
> 
>   productCategoryId="10002"...
> contentId="1-798936836182Den" ...
>  contentIdTo="1-798936836182Den"/> ...
>  dataResourceId="1-798936836182Len" ...
>   contentId="1-798936836182Len" ...
>  ...etc...
> 
> And this is a relatively short part number sequence.  If I WANT to pad
> extra info into the primary key.. for MY convenience, I don't have to worry
> about the import failing due to a 20 character limit somewhere.
> 
> In addition, setting up the data import as above allows me to quickly blow
> away the product, because all primary keys on all affected tables were
> created using a consistent pattern.
> 
> That is all that I am saying.  Once you set up a database, you have to to
> live with it.
> 
> On Wed, Apr 5, 2017 at 3:12 PM, Scott Gray 
> wrote:
> 
>> Perhaps lookup performance isn't the only consideration?
>> 
>> A few things come to mind:
>> - screen realestate when PKs need to be displayed
>> - bandwidth for syncing to slaves and transporting data to/from the client
>> - file size for export/import be it XML or whatever
>> 
>> Given that PKs shouldn't perform any function beyond guaranteeing
>> uniqueness within a given table, and that we use numeric sequences for
>> nonstatic tables, I struggle to see where it makes sense to use anything
>> bigger than 20 characters. So we have to abbreviate some seed data to fit,
>> not really a big deal and certainly not "absurd".
>> 
>> Like any other code base in the world, OFBiz contains opinionated design.
>> Everyone is free to discuss those opinions ad nauseam, but using strong
>> language such as "absurd" because you have a different opin

Re: Default key size

[Mike]

Thanks Jacques.  The Jira and article are good examples of why you
shouldn't paint yourself in a corner when it comes to defining the database
structure.  Eventually, it will come back to haunt you when you need to do
special stuff, like using GIUDs, if that is your new requirement.  In my
opinion (only), this is the beauty of localpostnew..  All variable length
fields throughout the DB structure.

On Thu, Apr 6, 2017 at 1:27 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Scott;
>
> I crossed that in a project. They wanted extended PK lengths. It's somehow
> explained here https://blog.techottis.ch/2016/10/03/the-quest-for-the-id/
>
> I created OFBIZ-5648 for that
>
> Jaqcues
>
>
>
> Le 06/04/2017 à 00:12, Scott Gray a écrit :
>
>> Perhaps lookup performance isn't the only consideration?
>>
>> A few things come to mind:
>> - screen realestate when PKs need to be displayed
>> - bandwidth for syncing to slaves and transporting data to/from the client
>> - file size for export/import be it XML or whatever
>>
>> Given that PKs shouldn't perform any function beyond guaranteeing
>> uniqueness within a given table, and that we use numeric sequences for
>> nonstatic tables, I struggle to see where it makes sense to use anything
>> bigger than 20 characters. So we have to abbreviate some seed data to fit,
>> not really a big deal and certainly not "absurd".
>>
>> Like any other code base in the world, OFBiz contains opinionated design.
>> Everyone is free to discuss those opinions ad nauseam, but using strong
>> language such as "absurd" because you have a different opinion is
>> unnecessary and not constructive to the conversation.
>>
>> Regards
>> Scott
>>
>>
>>
>> On 6/04/2017 09:33, "Mike"  wrote:
>>
>> Well, with postgresql, and localpostnew, there are no worries about UTF8
>>> compatibility, or lengths of *ANY* fields.  It works just fine, and the
>>> performance is fast.
>>>
>>> One may argue that you SHOULD limit your primary ID fields.  OK:  Maybe
>>> to
>>> 255, using VARYING(255)...  But never use VARCHAR(255), because you are
>>> physically storing 255 characters... but never just 20.
>>>
>>> On Wed, Apr 5, 2017 at 12:42 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> For history sake: I committed localpostnew.

 After a discussion (on dev ML or somewhere else? Unfortunately I can't
 find) it was commonly agreed that we should merge localpostnew in
 localpostgres and then remove localpostnew.

 Later we commonly decided http://markmail.org/message/op2yl3pcbj3lgxpg

>>> to
>>>
 revert some changes in the new (merged) localpostgres

 Feel free to use localpostnew. We could even put it back in, as
 suggested
 Nicolas, but I believe it should be then named otherwise to avoid

>>> confusion
>>>
 Jacques


 Le 05/04/2017 à 19:32, Mike a écrit :

 Pierre, here is an example from the demo data:
>
> accounting_OrganizationData.xml: roleTypeId="INTERNAL_ORGANIZATIO"/>
>
> The default of ID (20 chrs) is so small that you can't even properly
>
 spell
>>>
 "INTERNAL_ORGANIZATION"... I work with databases every day, and I would
>
 be
>>>
 so limited if I had to work with such small primary IDs.
>
> The thing is you don't want to not limit yourself when you first build
> a
> database.  The jira is interesting, and GUIDs are a good example.
>
> Personally, I use postgresql, using the "localpostnew" type... Removed
> from
> trunk for some reason.. It has unlimited primary ID sizes (ok, 2.1G),
> which
> allows me to create any sort of primary key I want.
>
>    java-type="String"/>
>   
 java-type="String"/>
>>>
   
 java-type="String"/>
>>>
 If you think that type=TEXT is slow or less efficient..  Here is what
> postgres says about type "TEXT"..
>
> https://www.postgresql.org/docs/9.3/static/datatype-character.html
>
> *Tip:* There is no performance difference among these three types,
> apart
>
> from increased storage space when using the blank-padded type, and a
> few
> extra CPU cycles to check the length when storing into a
> length-constrained
> column. While character(n) has performance advantages in some other
> database systems, there is no such advantage inPostgreSQL; in fact
> character(n) is usually the slowest of the three because of its
>
 additional
>>>
 storage costs. In most situations text or character varying should be
>
 used
>>>
 instead.
>
> Mysql has a similar type... I personally haven't tested it.
>
> On Wed, Apr 5, 2017 at 10:06 AM, Pierre Smits 
> wrote:
>
> HI Mike, all,
>
>> Re 2: Talk about adjustment of default key size
>> Why is that absurd? You believe it is too long/too short?
>> Following JIRA issue may be of int

Re: Users using the snapshots?

[Jacques Le Roux]

Hi Moatasim,

Without answer from you I considered it's OK with you and removed the snapshots 
creation as discussed on dev ML: https://s.apache.org/9fEE

Jacques


Le 04/04/2017 à 19:10, Jacques Le Roux a écrit :

I'd suggest to rather check out from the repository 
http://ofbiz.apache.org/source-repositories.html

Would that works for you?

Jacques


Le 04/04/2017 à 16:15, Moatasim Al Masri a écrit :

We are using https://ci.apache.org/projects/ofbiz/snapshots/ to download 
latest, so please what is alternative links?



-Original Message-
From: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
Sent: Tuesday, April 4, 2017 4:01 PM
To: user@ofbiz.apache.org
Subject: Users using the snapshots?

Hi,

Are there users using the snapshots at 
https://ci.apache.org/projects/ofbiz/snapshots/…  ?

We are thinking about removing them...

Thanks

Jacques

OFBiz Blog - March 2017 Update

[Sharan Foga]

Hi Everyone

Our monthly blog update is now available at the link below:

https://blogs.apache.org/ofbiz/entry/apache-ofbiz-news-march-2017

Kudos and thanks goes out again to Michael and Jacques for their help reviewing 
it. 

Thanks 
Sharan

Re: Returns in Ofbiz

[Julien NICOLAS]

Hello James,

I create a french "documentation" (reminder is the best word) for return 
product.


I translate it for you. I translate it fast so my english could be very 
bad. I'm not sure about the label between double cote.


Hope that help :)

Julien.

1.


 Create customer return for defective product exchange



In « Order » application, « Order list » menu (or « find order »), find 
your order and clic on the ID to open the order details.


1.


   Create a return

In the « Actions » area, click on the « Create return » button.

In the screen of return management, fill in the quantity to return, in 
« purpose » field choose « Defective », in « Type » field choose 
« Replacement » and in the « item status » field choose « Defective », 
then check the checkbox of the item line and validate.


It open the return screen and you have to click on the « Return 
accepted » button. At this level, the product is now in stock with a 
quantity of 0 with the status « Defective ».


2.


   Create a new order to send back a replacement product

In the return detail screen, choose the status « Return received and 
accepted », in “facility” select the facility where the returned product 
must be received and then click on “Send” button.


A this state, a new order (0$) is ready to send replacement product to 
the customer.


3.


   Recept of defective product

In “Facility”, “Facility” menu, select the facility and go to the 
“Return receipt” tab.


Fill in the return number and click on the “Item to receive” button.

Check information and click on the “Receive selected items”.

4.


   Send replacement product

Use the normal way of the order sending on the return order.



On 06/04/2017 14:01, ja...@productive1.com wrote:

Is there any document that shows the proper way Ofbiz handles product
returns?  Can someone point me to where I can find more information?

Also does Ofbiz support RTV (Return to Vendor)

Thanks,

James

Re: Returns in Ofbiz

[Jacques Le Roux]

This at least https://cwiki.apache.org/confluence/display/OFBENDUSER/3.5+Returns

Help yourself: documentation menu at http://ofbiz.apache.org/ to search on wiki

More on ML archives: menu community ->  mailing lists -> 
http://ofbiz.apache.org/mailing-lists.html "Global Searchable Archives" section at 
bottom

Jacques


Le 06/04/2017 à 14:01, ja...@productive1.com a écrit :

Is there any document that shows the proper way Ofbiz handles product
returns?  Can someone point me to where I can find more information?

Also does Ofbiz support RTV (Return to Vendor)

Thanks,

James

Returns in Ofbiz

[james]

Is there any document that shows the proper way Ofbiz handles product
returns?  Can someone point me to where I can find more information?

Also does Ofbiz support RTV (Return to Vendor)

Thanks,

James

Re: Default key size

[Jacques Le Roux]

Hi Scott;

I crossed that in a project. They wanted extended PK lengths. It's somehow 
explained here https://blog.techottis.ch/2016/10/03/the-quest-for-the-id/

I created OFBIZ-5648 for that

Jaqcues


Le 06/04/2017 à 00:12, Scott Gray a écrit :

Perhaps lookup performance isn't the only consideration?

A few things come to mind:
- screen realestate when PKs need to be displayed
- bandwidth for syncing to slaves and transporting data to/from the client
- file size for export/import be it XML or whatever

Given that PKs shouldn't perform any function beyond guaranteeing
uniqueness within a given table, and that we use numeric sequences for
nonstatic tables, I struggle to see where it makes sense to use anything
bigger than 20 characters. So we have to abbreviate some seed data to fit,
not really a big deal and certainly not "absurd".

Like any other code base in the world, OFBiz contains opinionated design.
Everyone is free to discuss those opinions ad nauseam, but using strong
language such as "absurd" because you have a different opinion is
unnecessary and not constructive to the conversation.

Regards
Scott



On 6/04/2017 09:33, "Mike"  wrote:


Well, with postgresql, and localpostnew, there are no worries about UTF8
compatibility, or lengths of *ANY* fields.  It works just fine, and the
performance is fast.

One may argue that you SHOULD limit your primary ID fields.  OK:  Maybe to
255, using VARYING(255)...  But never use VARCHAR(255), because you are
physically storing 255 characters... but never just 20.

On Wed, Apr 5, 2017 at 12:42 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


For history sake: I committed localpostnew.

After a discussion (on dev ML or somewhere else? Unfortunately I can't
find) it was commonly agreed that we should merge localpostnew in
localpostgres and then remove localpostnew.

Later we commonly decided http://markmail.org/message/op2yl3pcbj3lgxpg

to

revert some changes in the new (merged) localpostgres

Feel free to use localpostnew. We could even put it back in, as suggested
Nicolas, but I believe it should be then named otherwise to avoid

confusion

Jacques


Le 05/04/2017 à 19:32, Mike a écrit :


Pierre, here is an example from the demo data:

accounting_OrganizationData.xml:

The default of ID (20 chrs) is so small that you can't even properly

spell

"INTERNAL_ORGANIZATION"... I work with databases every day, and I would

be

so limited if I had to work with such small primary IDs.

The thing is you don't want to not limit yourself when you first build a
database.  The jira is interesting, and GUIDs are a good example.

Personally, I use postgresql, using the "localpostnew" type... Removed
from
trunk for some reason.. It has unlimited primary ID sizes (ok, 2.1G),
which
allows me to create any sort of primary key I want.

  
  
java-type="String"/>

  
java-type="String"/>

If you think that type=TEXT is slow or less efficient..  Here is what
postgres says about type "TEXT"..

https://www.postgresql.org/docs/9.3/static/datatype-character.html

*Tip:* There is no performance difference among these three types, apart

from increased storage space when using the blank-padded type, and a few
extra CPU cycles to check the length when storing into a
length-constrained
column. While character(n) has performance advantages in some other
database systems, there is no such advantage inPostgreSQL; in fact
character(n) is usually the slowest of the three because of its

additional

storage costs. In most situations text or character varying should be

used

instead.

Mysql has a similar type... I personally haven't tested it.

On Wed, Apr 5, 2017 at 10:06 AM, Pierre Smits 
wrote:

HI Mike, all,

Re 2: Talk about adjustment of default key size
Why is that absurd? You believe it is too long/too short?
Following JIRA issue may be of interest:
https://issues.apache.org/jira/browse/OFBIZ-8343

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Apr 5, 2017 at 5:10 PM, Mike  wrote:

Nice videos.  Regarding the mysql setup, you may want to include two
items:


1) Make sure mysql is setup as UTF8, discussed earlier in this mail


group.


Requires tweaking:

framework/entity/config/entityengine.xml
/etc/mysql/my.cnf

2) Talk about adjusting the default sizes of primary keys (ID).  The
default is an absurd 20 characters:

framework/entity/fieldtype/fieldtypemysql.xml

  
  
  



On Wed, Apr 5, 2017 at 6:03 AM, Pranay Pandey <
pranay.pan...@hotwaxsystems.com> wrote:

Thanks so much Deepak!

Best regards,

Pranay Pandey


On Wed, Apr 5, 2017 at 5:51 PM, Deepak Dixit



wrote:
Hi Team,

Here are some more videos from Pranay

-  Setup OFBiz in IntelliJ IDEA IDE - Release 16.11 and Trunk

- Setup OFBiz with MySQL 


Thanks Pranay for your effort.


Thanks & Regards
--
Deepak D

Re: Default key size

[Jacques Le Roux]

Mike,

OK then use the big gun. I have also crossed something similar in a project. I implemented a way to extend PKs w/o changing OOTB lengths, see 
https://issues.apache.org/jira/browse/OFBIZ-5648


The idea is you want to extend only some PKs lengths (not all as when forcing in field types files) and you don't want to change anything in OOTB 
code, for easier maintenance reason.


Most of the time it's easy, but beware of PKs dependencies in the data model, 
anyway OFBiz will tell you...

HTH

Jacques


Le 06/04/2017 à 07:34, Mike a écrit :

Apologies for the absurd reference.  Certainly the screen real estate is
the biggest issue.  Sure, it is nice to display primary keys within 20
characters...

But let me give you a working example.  In fact, this was a real issue with
me, considering the import of products.  Sure, I could have assigned a
non-meaningful sequential number, but I like real reference, like a part
number or UPC code.  In my case, multiple suppliers may carry the same UPC,
so I elected to create the primary key as "SUPPLIER_CODE-UPC".  This way I
can always work on a set of P/Ns from a given supplier.  So, the primary
key becomes: "1-798936836182", already 18 characters.

 ...

wrote:


Perhaps lookup performance isn't the only consideration?

A few things come to mind:
- screen realestate when PKs need to be displayed
- bandwidth for syncing to slaves and transporting data to/from the client
- file size for export/import be it XML or whatever

Given that PKs shouldn't perform any function beyond guaranteeing
uniqueness within a given table, and that we use numeric sequences for
nonstatic tables, I struggle to see where it makes sense to use anything
bigger than 20 characters. So we have to abbreviate some seed data to fit,
not really a big deal and certainly not "absurd".

Like any other code base in the world, OFBiz contains opinionated design.
Everyone is free to discuss those opinions ad nauseam, but using strong
language such as "absurd" because you have a different opinion is
unnecessary and not constructive to the conversation.

Regards
Scott



On 6/04/2017 09:33, "Mike"  wrote:


Well, with postgresql, and localpostnew, there are no worries about UTF8
compatibility, or lengths of *ANY* fields.  It works just fine, and the
performance is fast.

One may argue that you SHOULD limit your primary ID fields.  OK:  Maybe

to

255, using VARYING(255)...  But never use VARCHAR(255), because you are
physically storing 255 characters... but never just 20.

On Wed, Apr 5, 2017 at 12:42 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


For history sake: I committed localpostnew.

After a discussion (on dev ML or somewhere else? Unfortunately I can't
find) it was commonly agreed that we should merge localpostnew in
localpostgres and then remove localpostnew.

Later we commonly decided http://markmail.org/message/op2yl3pcbj3lgxpg

to

revert some changes in the new (merged) localpostgres

Feel free to use localpostnew. We could even put it back in, as

suggested

Nicolas, but I believe it should be then named otherwise to avoid

confusion

Jacques


Le 05/04/2017 à 19:32, Mike a écrit :


Pierre, here is an example from the demo data:

accounting_OrganizationData.xml:

The default of ID (20 chrs) is so small that you can't even properly

spell

"INTERNAL_ORGANIZATION"... I work with databases every day, and I

would

be

so limited if I had to work with such small primary IDs.

The thing is you don't want to not limit yourself when you first

build a

database.  The jira is interesting, and GUIDs are a good example.

Personally, I use postgresql, using the "localpostnew" type... Removed
from
trunk for some reason.. It has unlimited primary ID sizes (ok, 2.1G),
which
allows me to create any sort of primary key I want.

  
  
java-type="String"/>

  
java-type="String"/>

If you think that type=TEXT is slow or less efficient..  Here is what
postgres says about type "TEXT"..

https://www.postgresql.org/docs/9.3/static/datatype-character.html

*Tip:* There is no performance difference among these three types,

apart

from increased storage space when using the blank-padded type, and a

few

extra CPU cycles to check the length when storing into a
length-constrained
column. While character(n) has performance advantages in some other
database systems, there is no such advantage inPostgreSQL; in fact
character(n) is usually the slowest of the three because of its

additional

storage costs. In most situations text or character varying should be

used

instead.

Mysql has a similar type... I personally haven't tested it.

On Wed, Apr 5, 2017 at 10:06 AM, Pierre Smits 
Re 2: Talk about adjustment of default key size
Why is that absurd? You believe it is too long/too short?
Following JIRA issue may be of interest:
https://issues.apache.org/jira/browse/OFBIZ-8343

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensi

Re: Tutorial Videos

[Michael Brohl]

Great work, thanks for your efforts Praney and Deepak.

Best regards,

Michael

Am 09.03.17 um 13:48 schrieb Deepak Dixit:

Hi Everyone,

Pranay has created two video tutorials, these have been published on our
OFBiz YouTube channel :
1 - Apache OFBiz Mailing Lists 
2 - OFBiz Beginners Tutorial - Basic Setup Release16.11


Thanks Pranay for these helpful videos.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com






smime.p7s
Description: S/MIME Cryptographic Signature