You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <de...@me.com> on 2011/03/20 04:33:22 UTC
Discussion: Potential Data Model Improvements
I'm writing this to start a thread to discuss:
If you could change ANYTHING in the OFBiz data model, what would it be?
To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
-David
========================================================
- Rename *Role entities to *Party
- Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
- Remove all status history (*Status) and just using audit on the statusId field
- ProductPrice add quantity breaks, change PK to single field sequenced
- Get rid of QuantityBreak and use the two simple fields instead in each place used
- Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
- Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced
- Change Quote to be other types of Order
- Make Return more like Invoice (ie no adjustment, just use items for everything)
- Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere
- PartyRelationship simplify (single sequenced ID)
- Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc
- Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType
- Move most *Type entities to Enumeration values (update seed data, referring
entities, remove *Type) (after this remove all remaining hasTable fields)
- Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem
- Review use of Appl, Assoc (look at book, make sure consistent)
- Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...)
- Change GoodIdentification to ProductIdentification
- Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech)
- Get rid of NoteData, put noteText very-long field directly on various *Note entities
- Review all entities with large PKs (esp 4+ fields)
- Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field
- CustRequest to Request
- FinAccount to FinancialAccount
- Invoice handle recurrence? (was using RecurrenceInfo)
- Get rid of optional ProductFeature concept (conf/etc products much better model)
- Instead of various *Term entities and mapping, just use OrderTerm everywhere
- Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
- Agreement - make price list easier/cleaner
- Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log)
- Product clean up: move dimenstions to new entity, remove content fields, etc
- Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/19/2011 8:33 PM, David E Jones wrote:
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>
> -David
>
> ========================================================
> - Get rid of NoteData, put noteText very-long field directly on various *Note entities
>
-1
I prefer the many-to-many relationship. A note might apply to more than
one entity.
-Adrian
Re: Discussion: Potential Data Model Improvements
Posted by David E Jones <de...@me.com>.
On Apr 2, 2011, at 5:41 AM, Paul Foxworthy wrote:
> Status History
> ---------------------
>
> I can see the sense in having one repository for all change tracking. We
> just need to bear in mind there are more use cases for using the information
> in the repository than “auditing”. Auditing is a security activity, and it
> will be security professionals looking at a history of who did what. Looking
> at a status history could well be a business activity with no security
> dimension to it. So viewing the history of changes to an order’s status
> might be something a manager would do.
>
> We would need to structure permissions so that people who need some of the
> information for business purposes can use it even though they are not
> security professionals. The other thing to observe is that status history is
> currently *on* by default in Ofbiz, and auditing is *off* by default.
The "audit log" is a pretty general term and does not imply restricted access to the information. Control of access to any database information is up to the application developer, and nothing about the term "audit log" prevents that.
> QuantityBreak
> ---------------------
>
> No, don’t get rid of the QuantityBreak entity, and it should be used as part
> of pricing. Many organisations will have standard QuantityBreaks that apply
> to a wide range of products. An organization might want to offer various
> agreed prices to customers, but use the same quantity breaks consistently.
> It should be possible to add a new price for a product without having to
> define quantity breaks, with the risk that the newly entered quantity breaks
> are inconsistent with standard organisation policy.
Maybe this wasn't clear... the goal is to get rid of the QuantityBreak entity and use the quantity fields directly. This significantly simplifies both the data model and the code. In theory what you say is correct, that quantity breaks could be maintained separately, but that hasn't happened in any of the OFBiz UIs, and in fact I've never seen anything like that actually used (I've seen them built, but then abandoned because for the user they are cumbersome).
If an organization wants a policy of specific quantity breaks they can certainly implement that and design the user interface for it, even with the data model designed this way.
> Purchase and Sales Agreements
> -----------------------------------------------
>
> - the AgreementItem has the currency for prices. The currency should be on
> individual AgreementProductAppls. It should be possible to have agreed
> prices in various currencies for a product
> - AgreementProductAppl should have its own from and thru dates. A particular
> price might have a different timespan than the Agreement or (in the case of
> a purchase agreement) the SupplierProduct. You could imagine an agreement
> spanning a year with a list of special prices, each of which is available
> for one month
This is a good point, it would be good to have prices in multiple currencies in the same agreement, I'm modifying the AgreementItemProduct entity in the Mantle data model to support that and in general be more like the ProductPrice entity.
On second thought, after looking at the model, I like them (currency, from/thru dates) on the AgreementItem better since it can apply to multiple things and agreements may be better organized if price lists for different currencies and date ranges are under different items (and the actual data is a lot cleaner).
> - There’s no way at present to have a quantity break associated with an
> agreed price for a sales agreement. Quantity breaks are currently within the
> SupplierProduct entity, so are available for purchase agreements, but not
> sales agreements.
Actually, that's not quite true. The current AgreementProductAppl model is cumbersome, but this last point IS supported (ie agreement-based sales pricing with quantity breaks) in both the OFBiz data model and the sales order code.
In the data model I'm working on this is simplified and much more clear. See the "AgreementItemProduct" entity here:
https://github.com/jonesde/mantle/blob/master/mantle-udm/entity/PartyEntities.xml
> SupplierProduct
> -----------------------
>
> - As David says, a five-attribute primary key is unwieldy. It should be
> replaced with a simple ID.
Agreed. Here is my current take on the SupplierProduct entity:
https://github.com/jonesde/mantle/blob/master/mantle-udm/entity/ProductInventoryEntities.xml
> - SupplierProduct has a minimumQuantity attribute, so must be read in
> combination with other SupplierProducts. SupplierProduct should *not* have
> any information on quantity breaks. There should be just one instance of
> SupplierProduct to record that a product can be obtained from a supplier. A
> SupplierProduct should have associated QuantityBreaks and ProductPrices, as
> described in the Data Model Resource Book.
> - lastPrice in SupplierProduct is used both for the last price we obtained
> the product, and an agreed price. These are two separate things. Given the
> lastPrice might have been determined by an agreement that has expired, and
> by a quantity that we are not ordering this time, it's not very useful. It
> ought to be possible to determine the most recent prices we paid at various
> quantity breaks for a given product from a given supplier
Actually in OFBiz the "lastPrice" is meant to be just that, the last known price from the supplier. It isn't meant to represent any sort of purchase agreement. The Agreement* entities should be used for that (though I don't know off the top of my head if that is current supported in the OFBiz purchase order code).
> TaxAuthorityRateProduct
> -------------------------------------
>
> - This entity is used to determine tax on shipping and promotional pricing
> adjustments, when these are not products. There should be a separate entity
> for tax on all order adjustments, which will determine tax based on the
> adjustment type rather than on the product category
Yes, agreed. In the Mantle UDM I changed the name to "TaxAuthorityRateSales":
https://github.com/jonesde/mantle/blob/master/mantle-udm/entity/AccountingOtherEntities.xml
> - The ProductStore is used to determine the tax payable. That’s fine for
> sales, but makes no sense for purchases. Really, the ProductStore is a proxy
> for the geo of the seller. TaxAuthorityRateProduct should be revised to list
> the geo of the seller rather than the ProductStore, then the same rules
> could be used by purchases as well as sales. For a sale, the ProductStore
> geo would be used as the geo of the seller.
I'm not sure what you mean about the geo of the seller thingy. The geo used on TaxAuthorityRateProduct is the taxAuthorityGeoId where the customer is shipping to (or billing to) a geo where there is a PartyTaxAuthInfo (or Mantle TaxAuthorityParty) record where the seller organization has isNexus=Y.
As for the productStoreId field, it should only be used as an extra constraint on the "rule" record, and should be fine if null (from the model perspective, the code may not currently behave that way).
=======================
Anyway, thanks for your feedback Paul. I've made a few changes while reviewing your comments and related entities and they are now in Mantle UDM.
-David
> David E Jones-4 wrote:
>>
>> I'm writing this to start a thread to discuss:
>>
>> If you could change ANYTHING in the OFBiz data model, what would it be?
>>
>> To kick this off here are some ideas I've compiled that have come up over
>> the years (many based on feedback from people on this mailing list), or
>> that I thought of recently will working on this topic. You can see them
>> below...
>>
>> -David
>>
>> ========================================================
>>
>> - Rename *Role entities to *Party
>> - Remove *Attribute and *TypeAttr entities (not generally a good practice
>> to use)
>> - Remove all status history (*Status) and just using audit on the statusId
>> field
>> - ProductPrice add quantity breaks, change PK to single field sequenced
>> - Get rid of QuantityBreak and use the two simple fields instead in each
>> place used
>> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly
>> associate to the store
>> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to
>> single field sequenced
>> - Change Quote to be other types of Order
>> - Make Return more like Invoice (ie no adjustment, just use items for
>> everything)
>> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType,
>> ReturnItemType just use Shared ItemType everywhere
>> - PartyRelationship simplify (single sequenced ID)
>>
>> - Make prefixes consistent (no suffixes), ie toPartyId instead of
>> partyIdTo, etc
>> - Change all relationships to PartyRole to be type one-nofk; use plain one
>> for Party and RoleType
>> - Move most *Type entities to Enumeration values (update seed data,
>> referring
>> entities, remove *Type) (after this remove all remaining hasTable
>> fields)
>> - Rework PhysicalInventory and InventoryVariance to simplify, reduce
>> dependency on InventoryItem
>> - Review use of Appl, Assoc (look at book, make sure consistent)
>> - Add PartyIdentification entity, get rid of various fields and other
>> entities (maybe even PartyTaxAuthority...)
>> - Change GoodIdentification to ProductIdentification
>> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use
>> entity with purpose, name PartyContactMech)
>> - Get rid of NoteData, put noteText very-long field directly on various
>> *Note entities
>> - Review all entities with large PKs (esp 4+ fields)
>> - Review and do something with all createOn/By lastUpdateOn/By fields,
>> maybe add an auditing flag for the entity instead of just for a field
>> - CustRequest to Request
>> - FinAccount to FinancialAccount
>> - Invoice handle recurrence? (was using RecurrenceInfo)
>> - Get rid of optional ProductFeature concept (conf/etc products much
>> better model)
>> - Instead of various *Term entities and mapping, just use OrderTerm
>> everywhere
>> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
>> - Agreement - make price list easier/cleaner
>> - Remove all createdDate, createdByUserLogin, lastModifiedDate,
>> lastModifiedByUserLogin fields (use framework defaults, audit-log)
>> - Product clean up: move dimenstions to new entity, remove content fields,
>> etc
>> - Trim down big entities like Product, WorkEffort, etc; for groups of
>> similar fields use a more normalized structure
>>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Discussion-Potential-Data-Model-Improvements-tp3390620p3422000.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Discussion: Potential Data Model Improvements
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Status History
---------------------
I can see the sense in having one repository for all change tracking. We
just need to bear in mind there are more use cases for using the information
in the repository than “auditing”. Auditing is a security activity, and it
will be security professionals looking at a history of who did what. Looking
at a status history could well be a business activity with no security
dimension to it. So viewing the history of changes to an order’s status
might be something a manager would do.
We would need to structure permissions so that people who need some of the
information for business purposes can use it even though they are not
security professionals. The other thing to observe is that status history is
currently *on* by default in Ofbiz, and auditing is *off* by default.
QuantityBreak
---------------------
No, don’t get rid of the QuantityBreak entity, and it should be used as part
of pricing. Many organisations will have standard QuantityBreaks that apply
to a wide range of products. An organization might want to offer various
agreed prices to customers, but use the same quantity breaks consistently.
It should be possible to add a new price for a product without having to
define quantity breaks, with the risk that the newly entered quantity breaks
are inconsistent with standard organisation policy.
Purchase and Sales Agreements
-----------------------------------------------
- the AgreementItem has the currency for prices. The currency should be on
individual AgreementProductAppls. It should be possible to have agreed
prices in various currencies for a product
- AgreementProductAppl should have its own from and thru dates. A particular
price might have a different timespan than the Agreement or (in the case of
a purchase agreement) the SupplierProduct. You could imagine an agreement
spanning a year with a list of special prices, each of which is available
for one month
- There’s no way at present to have a quantity break associated with an
agreed price for a sales agreement. Quantity breaks are currently within the
SupplierProduct entity, so are available for purchase agreements, but not
sales agreements.
SupplierProduct
-----------------------
- As David says, a five-attribute primary key is unwieldy. It should be
replaced with a simple ID.
- SupplierProduct has a minimumQuantity attribute, so must be read in
combination with other SupplierProducts. SupplierProduct should *not* have
any information on quantity breaks. There should be just one instance of
SupplierProduct to record that a product can be obtained from a supplier. A
SupplierProduct should have associated QuantityBreaks and ProductPrices, as
described in the Data Model Resource Book.
- lastPrice in SupplierProduct is used both for the last price we obtained
the product, and an agreed price. These are two separate things. Given the
lastPrice might have been determined by an agreement that has expired, and
by a quantity that we are not ordering this time, it's not very useful. It
ought to be possible to determine the most recent prices we paid at various
quantity breaks for a given product from a given supplier
TaxAuthorityRateProduct
-------------------------------------
- This entity is used to determine tax on shipping and promotional pricing
adjustments, when these are not products. There should be a separate entity
for tax on all order adjustments, which will determine tax based on the
adjustment type rather than on the product category
- The ProductStore is used to determine the tax payable. That’s fine for
sales, but makes no sense for purchases. Really, the ProductStore is a proxy
for the geo of the seller. TaxAuthorityRateProduct should be revised to list
the geo of the seller rather than the ProductStore, then the same rules
could be used by purchases as well as sales. For a sale, the ProductStore
geo would be used as the geo of the seller.
David E Jones-4 wrote:
>
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over
> the years (many based on feedback from people on this mailing list), or
> that I thought of recently will working on this topic. You can see them
> below...
>
> -David
>
> ========================================================
>
> - Rename *Role entities to *Party
> - Remove *Attribute and *TypeAttr entities (not generally a good practice
> to use)
> - Remove all status history (*Status) and just using audit on the statusId
> field
> - ProductPrice add quantity breaks, change PK to single field sequenced
> - Get rid of QuantityBreak and use the two simple fields instead in each
> place used
> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly
> associate to the store
> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to
> single field sequenced
> - Change Quote to be other types of Order
> - Make Return more like Invoice (ie no adjustment, just use items for
> everything)
> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType,
> ReturnItemType just use Shared ItemType everywhere
> - PartyRelationship simplify (single sequenced ID)
>
> - Make prefixes consistent (no suffixes), ie toPartyId instead of
> partyIdTo, etc
> - Change all relationships to PartyRole to be type one-nofk; use plain one
> for Party and RoleType
> - Move most *Type entities to Enumeration values (update seed data,
> referring
> entities, remove *Type) (after this remove all remaining hasTable
> fields)
> - Rework PhysicalInventory and InventoryVariance to simplify, reduce
> dependency on InventoryItem
> - Review use of Appl, Assoc (look at book, make sure consistent)
> - Add PartyIdentification entity, get rid of various fields and other
> entities (maybe even PartyTaxAuthority...)
> - Change GoodIdentification to ProductIdentification
> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use
> entity with purpose, name PartyContactMech)
> - Get rid of NoteData, put noteText very-long field directly on various
> *Note entities
> - Review all entities with large PKs (esp 4+ fields)
> - Review and do something with all createOn/By lastUpdateOn/By fields,
> maybe add an auditing flag for the entity instead of just for a field
> - CustRequest to Request
> - FinAccount to FinancialAccount
> - Invoice handle recurrence? (was using RecurrenceInfo)
> - Get rid of optional ProductFeature concept (conf/etc products much
> better model)
> - Instead of various *Term entities and mapping, just use OrderTerm
> everywhere
> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
> - Agreement - make price list easier/cleaner
> - Remove all createdDate, createdByUserLogin, lastModifiedDate,
> lastModifiedByUserLogin fields (use framework defaults, audit-log)
> - Product clean up: move dimenstions to new entity, remove content fields,
> etc
> - Trim down big entities like Product, WorkEffort, etc; for groups of
> similar fields use a more normalized structure
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Discussion-Potential-Data-Model-Improvements-tp3390620p3422000.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Discussion: Potential Data Model Improvements
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 24/07/2011, at 6:56 PM, Adrian Crum wrote:
> While working on converting a midrange legacy system to OFBiz, I've come up with more thoughts on this...
>
> On 3/20/2011 3:33 AM, David E Jones wrote:
>> - Get rid of optional ProductFeature concept (conf/etc products much better model)
>
> -1 From my perspective, the ProductFeature model in the DMRB is a lot more logical/flexible than the convoluted mess OFBiz uses.
I think David is simply suggesting to get rid of the OPTIONAL_FEATURE ProductFeatureApplType and any logic associated with it, not the entire ProductFeature model. I've never used that type so I can't really comment on it's usefulness.
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
While working on converting a midrange legacy system to OFBiz, I've come
up with more thoughts on this...
On 3/20/2011 3:33 AM, David E Jones wrote:
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>
> -David
>
> ========================================================
>
> - Rename *Role entities to *Party
> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
> - Remove all status history (*Status) and just using audit on the statusId field
> - ProductPrice add quantity breaks, change PK to single field sequenced
+1 on using a sequence. Also, get rid of ProductPriceType- it is a
duplicate of SaleType.
> - Get rid of QuantityBreak and use the two simple fields instead in each place used
> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced
> - Change Quote to be other types of Order
> - Make Return more like Invoice (ie no adjustment, just use items for everything)
> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere
> - PartyRelationship simplify (single sequenced ID)
>
> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc
> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType
> - Move most *Type entities to Enumeration values (update seed data, referring
> entities, remove *Type) (after this remove all remaining hasTable fields)
> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem
> - Review use of Appl, Assoc (look at book, make sure consistent)
> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...)
> - Change GoodIdentification to ProductIdentification
Why? The current name is from the DMRB - makes it easier to understand
what it's for.
> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech)
> - Get rid of NoteData, put noteText very-long field directly on various *Note entities
> - Review all entities with large PKs (esp 4+ fields)
> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field
> - CustRequest to Request
> - FinAccount to FinancialAccount
> - Invoice handle recurrence? (was using RecurrenceInfo)
> - Get rid of optional ProductFeature concept (conf/etc products much better model)
-1 From my perspective, the ProductFeature model in the DMRB is a lot
more logical/flexible than the convoluted mess OFBiz uses.
> - Instead of various *Term entities and mapping, just use OrderTerm everywhere
> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
> - Agreement - make price list easier/cleaner
> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log)
> - Product clean up: move dimenstions to new entity, remove content fields, etc
> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure
>
>
Re: Discussion: Potential Data Model Improvements
Posted by David E Jones <de...@me.com>.
On Mar 26, 2011, at 8:33 AM, Jacques Le Roux wrote:
> I don't see any problems but one question inline
> BTW, I think BJ would have loved that :o)
>
> Jacques
>
> David E Jones wrote:
>> I'm writing this to start a thread to discuss:
>>
>> If you could change ANYTHING in the OFBiz data model, what would it be?
>>
>> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this
>> mailing list), or that I thought of recently will working on this topic. You can see them below...
>>
>> -David
>>
>> ========================================================
>>
>> - Rename *Role entities to *Party
>> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
>> - Remove all status history (*Status) and just using audit on the statusId field
>> - ProductPrice add quantity breaks, change PK to single field sequenced
>> - Get rid of QuantityBreak and use the two simple fields instead in each place used
>> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
>
> Rename ProdCatalog* to ProductStoreCategory (only 1 entity?) and add field for an association with store?
It wasn't "Rename ..." it was get rid of all of the ProdCatalog* entities and use a single ProductStoreCategory entity instead.
The concept of "catalogs" always seems to have been confusing for people, and serves little purpose. There are also issues with the cart when switching catalogs, etc.
The new ProductStoreCategory entity would be based on the ProdCatalogCategory entity, but associate various categories directly with the store instead of going through a catalog.
-David
Re: Discussion: Potential Data Model Improvements
Posted by Jacques Le Roux <ja...@les7arts.com>.
I don't see any problems but one question inline
BTW, I think BJ would have loved that :o)
Jacques
David E Jones wrote:
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this
> mailing list), or that I thought of recently will working on this topic. You can see them below...
>
> -David
>
> ========================================================
>
> - Rename *Role entities to *Party
> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
> - Remove all status history (*Status) and just using audit on the statusId field
> - ProductPrice add quantity breaks, change PK to single field sequenced
> - Get rid of QuantityBreak and use the two simple fields instead in each place used
> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
Rename ProdCatalog* to ProductStoreCategory (only 1 entity?) and add field for an association with store?
> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced
> - Change Quote to be other types of Order
> - Make Return more like Invoice (ie no adjustment, just use items for everything)
> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere
> - PartyRelationship simplify (single sequenced ID)
>
> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc
> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType
> - Move most *Type entities to Enumeration values (update seed data, referring
> entities, remove *Type) (after this remove all remaining hasTable fields)
> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem
> - Review use of Appl, Assoc (look at book, make sure consistent)
> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...)
> - Change GoodIdentification to ProductIdentification
> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech)
> - Get rid of NoteData, put noteText very-long field directly on various *Note entities
> - Review all entities with large PKs (esp 4+ fields)
> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just
> for a field
> - CustRequest to Request
> - FinAccount to FinancialAccount
> - Invoice handle recurrence? (was using RecurrenceInfo)
> - Get rid of optional ProductFeature concept (conf/etc products much better model)
> - Instead of various *Term entities and mapping, just use OrderTerm everywhere
> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
> - Agreement - make price list easier/cleaner
> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log)
> - Product clean up: move dimenstions to new entity, remove content fields, etc
> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
Party classifications can be used in a number of ways - marketing
campaigns and employee classifications are two uses that come to mind.
So, I could have a marketing campaign that targets families and
therefore includes the "Family" party classification. Another marketing
campaign might target corporations, so it would include the
"Corporation" party classification.
How am I being vague? I have cited the book, and in the previous
discussion I gave a very detailed use-case scenario that demonstrated
how the current model doesn't work and the book's model works. Maybe you
could spend some time going over that thread again.
Where am I going with this? As the thread's subject says, I'm discussing
data model improvements.
-Adrian
On 3/29/2011 11:27 AM, David E Jones wrote:
> Hmmmm.... PartyType has the following data in OFBiz:
>
> <PartyType description="Automated Agent" hasTable="N" parentTypeId="" partyTypeId="AUTOMATED_AGENT"/>
> <PartyType description="Person" hasTable="Y" parentTypeId="" partyTypeId="PERSON"/>
> <PartyType description="Party Group" hasTable="Y" parentTypeId="" partyTypeId="PARTY_GROUP"/>
> <PartyType description="Informal Group" hasTable="N" parentTypeId="PARTY_GROUP" partyTypeId="INFORMAL_GROUP"/>
> <PartyType description="Family" hasTable="N" parentTypeId="INFORMAL_GROUP" partyTypeId="FAMILY"/>
> <PartyType description="Team" hasTable="N" parentTypeId="INFORMAL_GROUP" partyTypeId="TEAM"/>
> <PartyType description="Legal Organization" hasTable="N" parentTypeId="PARTY_GROUP" partyTypeId="LEGAL_ORGANIZATION"/>
> <PartyType description="Corporation" hasTable="N" parentTypeId="LEGAL_ORGANIZATION" partyTypeId="CORPORATION"/>
> <PartyType description="Government Agency" hasTable="N" parentTypeId="LEGAL_ORGANIZATION" partyTypeId="GOVERNMENT_AGENCY"/>
>
> Those don't look at ALL like the classifications mentioned in the book. The book mentions classification types such as "Income" and the actual classification would be something like "$20K-$40K".
>
> How is "$20K-$40K" like "Family"?
>
> I still have no idea where you're going with this... and I feel like as like as you respond with vague generalizations it's going to take a LOT of me responding with details to make up for that.
>
> -David
>
>
> On Mar 29, 2011, at 12:08 PM, Adrian Crum wrote:
>
>> Yes, we have been over this before, and no, I'm not forgetting anything about the PartyType entity.
>>
>> Look at the PartyType demo data - what does it contain? It contains party classification types. Whether the PartyEntity was originally intended to follow the book's model or not, the truth is it is being used to store party classification types. If that is the case, then why do we need another entity that does the same thing?
>>
>> Yes, PartyClassification would be a join entity. I haven't looked at the impact on the Party.partyTypeId field - that is certainly worth discussing.
>>
>> -Adrian
>>
>>
>> On 3/29/2011 10:58 AM, David E Jones wrote:
>>> Yeah, I think we've been over this before. You're still forgetting that the *Type entities in OFBiz have NOTHING to do with anywhere the term "type" is used in the Data Model Resource Book.
>>>
>>> Stepping back and allowing that this may not be the case, how would you imagine this model would look? Are you talking about PartyClassification being a join entity between Party and PartyType? What about the Party.partyTypeId field?
>>>
>>> -David
>>>
>>>
>>> On Mar 29, 2011, at 11:01 AM, Adrian Crum wrote:
>>>
>>>> A PartyClassification ties a Party to a PartyType and it includes from and thru dates (Figure 2.3 and Table 2.3).
>>>>
>>>> If you want to group classifications, then you group PartyType, not PartyClassification.
>>>>
>>>> -Adrian
>>>>
>>>> On 3/29/2011 9:48 AM, David E Jones wrote:
>>>>> Could you be more specific?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote:
>>>>>
>>>>>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 3/26/2011 9:57 AM, David E Jones wrote:
>>>>>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote:
>>>>>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
>>>>>>> Yes, this is another good one. This the pattern I had in mind:
>>>>>>>
>>>>>>> <entity entity-name="PartyClassification" package-name="mantle.party.party">
>>>>>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>>>>>> <field name="classificationTypeEnumId" type="id"/>
>>>>>>> <field name="parentClassificationId" type="id"/>
>>>>>>> <field name="description" type="text-long"/>
>>>>>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration">
>>>>>>> <key-map field-name="classificationTypeEnumId"/>
>>>>>>> </relationship>
>>>>>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification">
>>>>>>> <key-map field-name="parentClassificationId"/>
>>>>>>> </relationship>
>>>>>>> </entity>
>>>>>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party">
>>>>>>> <field name="partyId" type="id" is-pk="true"/>
>>>>>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>>>>>> <field name="fromDate" type="date-time" is-pk="true"/>
>>>>>>> <field name="thruDate" type="date-time"/>
>>>>>>> <relationship type="one" related-entity-name="Party"/>
>>>>>>> <relationship type="one" related-entity-name="PartyClassification"/>
>>>>>>> </entity>
>>>>>>>
Re: Discussion: Potential Data Model Improvements
Posted by David E Jones <de...@me.com>.
Hmmmm.... PartyType has the following data in OFBiz:
<PartyType description="Automated Agent" hasTable="N" parentTypeId="" partyTypeId="AUTOMATED_AGENT"/>
<PartyType description="Person" hasTable="Y" parentTypeId="" partyTypeId="PERSON"/>
<PartyType description="Party Group" hasTable="Y" parentTypeId="" partyTypeId="PARTY_GROUP"/>
<PartyType description="Informal Group" hasTable="N" parentTypeId="PARTY_GROUP" partyTypeId="INFORMAL_GROUP"/>
<PartyType description="Family" hasTable="N" parentTypeId="INFORMAL_GROUP" partyTypeId="FAMILY"/>
<PartyType description="Team" hasTable="N" parentTypeId="INFORMAL_GROUP" partyTypeId="TEAM"/>
<PartyType description="Legal Organization" hasTable="N" parentTypeId="PARTY_GROUP" partyTypeId="LEGAL_ORGANIZATION"/>
<PartyType description="Corporation" hasTable="N" parentTypeId="LEGAL_ORGANIZATION" partyTypeId="CORPORATION"/>
<PartyType description="Government Agency" hasTable="N" parentTypeId="LEGAL_ORGANIZATION" partyTypeId="GOVERNMENT_AGENCY"/>
Those don't look at ALL like the classifications mentioned in the book. The book mentions classification types such as "Income" and the actual classification would be something like "$20K-$40K".
How is "$20K-$40K" like "Family"?
I still have no idea where you're going with this... and I feel like as like as you respond with vague generalizations it's going to take a LOT of me responding with details to make up for that.
-David
On Mar 29, 2011, at 12:08 PM, Adrian Crum wrote:
> Yes, we have been over this before, and no, I'm not forgetting anything about the PartyType entity.
>
> Look at the PartyType demo data - what does it contain? It contains party classification types. Whether the PartyEntity was originally intended to follow the book's model or not, the truth is it is being used to store party classification types. If that is the case, then why do we need another entity that does the same thing?
>
> Yes, PartyClassification would be a join entity. I haven't looked at the impact on the Party.partyTypeId field - that is certainly worth discussing.
>
> -Adrian
>
>
> On 3/29/2011 10:58 AM, David E Jones wrote:
>> Yeah, I think we've been over this before. You're still forgetting that the *Type entities in OFBiz have NOTHING to do with anywhere the term "type" is used in the Data Model Resource Book.
>>
>> Stepping back and allowing that this may not be the case, how would you imagine this model would look? Are you talking about PartyClassification being a join entity between Party and PartyType? What about the Party.partyTypeId field?
>>
>> -David
>>
>>
>> On Mar 29, 2011, at 11:01 AM, Adrian Crum wrote:
>>
>>> A PartyClassification ties a Party to a PartyType and it includes from and thru dates (Figure 2.3 and Table 2.3).
>>>
>>> If you want to group classifications, then you group PartyType, not PartyClassification.
>>>
>>> -Adrian
>>>
>>> On 3/29/2011 9:48 AM, David E Jones wrote:
>>>> Could you be more specific?
>>>>
>>>> -David
>>>>
>>>>
>>>> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote:
>>>>
>>>>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 3/26/2011 9:57 AM, David E Jones wrote:
>>>>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote:
>>>>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
>>>>>> Yes, this is another good one. This the pattern I had in mind:
>>>>>>
>>>>>> <entity entity-name="PartyClassification" package-name="mantle.party.party">
>>>>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>>>>> <field name="classificationTypeEnumId" type="id"/>
>>>>>> <field name="parentClassificationId" type="id"/>
>>>>>> <field name="description" type="text-long"/>
>>>>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration">
>>>>>> <key-map field-name="classificationTypeEnumId"/>
>>>>>> </relationship>
>>>>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification">
>>>>>> <key-map field-name="parentClassificationId"/>
>>>>>> </relationship>
>>>>>> </entity>
>>>>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party">
>>>>>> <field name="partyId" type="id" is-pk="true"/>
>>>>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>>>>> <field name="fromDate" type="date-time" is-pk="true"/>
>>>>>> <field name="thruDate" type="date-time"/>
>>>>>> <relationship type="one" related-entity-name="Party"/>
>>>>>> <relationship type="one" related-entity-name="PartyClassification"/>
>>>>>> </entity>
>>>>>>
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
Yes, we have been over this before, and no, I'm not forgetting anything
about the PartyType entity.
Look at the PartyType demo data - what does it contain? It contains
party classification types. Whether the PartyEntity was originally
intended to follow the book's model or not, the truth is it is being
used to store party classification types. If that is the case, then why
do we need another entity that does the same thing?
Yes, PartyClassification would be a join entity. I haven't looked at the
impact on the Party.partyTypeId field - that is certainly worth discussing.
-Adrian
On 3/29/2011 10:58 AM, David E Jones wrote:
> Yeah, I think we've been over this before. You're still forgetting that the *Type entities in OFBiz have NOTHING to do with anywhere the term "type" is used in the Data Model Resource Book.
>
> Stepping back and allowing that this may not be the case, how would you imagine this model would look? Are you talking about PartyClassification being a join entity between Party and PartyType? What about the Party.partyTypeId field?
>
> -David
>
>
> On Mar 29, 2011, at 11:01 AM, Adrian Crum wrote:
>
>> A PartyClassification ties a Party to a PartyType and it includes from and thru dates (Figure 2.3 and Table 2.3).
>>
>> If you want to group classifications, then you group PartyType, not PartyClassification.
>>
>> -Adrian
>>
>> On 3/29/2011 9:48 AM, David E Jones wrote:
>>> Could you be more specific?
>>>
>>> -David
>>>
>>>
>>> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote:
>>>
>>>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 3/26/2011 9:57 AM, David E Jones wrote:
>>>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote:
>>>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
>>>>> Yes, this is another good one. This the pattern I had in mind:
>>>>>
>>>>> <entity entity-name="PartyClassification" package-name="mantle.party.party">
>>>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>>>> <field name="classificationTypeEnumId" type="id"/>
>>>>> <field name="parentClassificationId" type="id"/>
>>>>> <field name="description" type="text-long"/>
>>>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration">
>>>>> <key-map field-name="classificationTypeEnumId"/>
>>>>> </relationship>
>>>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification">
>>>>> <key-map field-name="parentClassificationId"/>
>>>>> </relationship>
>>>>> </entity>
>>>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party">
>>>>> <field name="partyId" type="id" is-pk="true"/>
>>>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>>>> <field name="fromDate" type="date-time" is-pk="true"/>
>>>>> <field name="thruDate" type="date-time"/>
>>>>> <relationship type="one" related-entity-name="Party"/>
>>>>> <relationship type="one" related-entity-name="PartyClassification"/>
>>>>> </entity>
>>>>>
Re: Discussion: Potential Data Model Improvements
Posted by David E Jones <de...@me.com>.
Yeah, I think we've been over this before. You're still forgetting that the *Type entities in OFBiz have NOTHING to do with anywhere the term "type" is used in the Data Model Resource Book.
Stepping back and allowing that this may not be the case, how would you imagine this model would look? Are you talking about PartyClassification being a join entity between Party and PartyType? What about the Party.partyTypeId field?
-David
On Mar 29, 2011, at 11:01 AM, Adrian Crum wrote:
> A PartyClassification ties a Party to a PartyType and it includes from and thru dates (Figure 2.3 and Table 2.3).
>
> If you want to group classifications, then you group PartyType, not PartyClassification.
>
> -Adrian
>
> On 3/29/2011 9:48 AM, David E Jones wrote:
>> Could you be more specific?
>>
>> -David
>>
>>
>> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote:
>>
>>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works.
>>>
>>> -Adrian
>>>
>>>
>>> On 3/26/2011 9:57 AM, David E Jones wrote:
>>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote:
>>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
>>>> Yes, this is another good one. This the pattern I had in mind:
>>>>
>>>> <entity entity-name="PartyClassification" package-name="mantle.party.party">
>>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>>> <field name="classificationTypeEnumId" type="id"/>
>>>> <field name="parentClassificationId" type="id"/>
>>>> <field name="description" type="text-long"/>
>>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration">
>>>> <key-map field-name="classificationTypeEnumId"/>
>>>> </relationship>
>>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification">
>>>> <key-map field-name="parentClassificationId"/>
>>>> </relationship>
>>>> </entity>
>>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party">
>>>> <field name="partyId" type="id" is-pk="true"/>
>>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>>> <field name="fromDate" type="date-time" is-pk="true"/>
>>>> <field name="thruDate" type="date-time"/>
>>>> <relationship type="one" related-entity-name="Party"/>
>>>> <relationship type="one" related-entity-name="PartyClassification"/>
>>>> </entity>
>>>>
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
A PartyClassification ties a Party to a PartyType and it includes from
and thru dates (Figure 2.3 and Table 2.3).
If you want to group classifications, then you group PartyType, not
PartyClassification.
-Adrian
On 3/29/2011 9:48 AM, David E Jones wrote:
> Could you be more specific?
>
> -David
>
>
> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote:
>
>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works.
>>
>> -Adrian
>>
>>
>> On 3/26/2011 9:57 AM, David E Jones wrote:
>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote:
>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
>>> Yes, this is another good one. This the pattern I had in mind:
>>>
>>> <entity entity-name="PartyClassification" package-name="mantle.party.party">
>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>> <field name="classificationTypeEnumId" type="id"/>
>>> <field name="parentClassificationId" type="id"/>
>>> <field name="description" type="text-long"/>
>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration">
>>> <key-map field-name="classificationTypeEnumId"/>
>>> </relationship>
>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification">
>>> <key-map field-name="parentClassificationId"/>
>>> </relationship>
>>> </entity>
>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party">
>>> <field name="partyId" type="id" is-pk="true"/>
>>> <field name="partyClassificationId" type="id" is-pk="true"/>
>>> <field name="fromDate" type="date-time" is-pk="true"/>
>>> <field name="thruDate" type="date-time"/>
>>> <relationship type="one" related-entity-name="Party"/>
>>> <relationship type="one" related-entity-name="PartyClassification"/>
>>> </entity>
>>>
Re: Discussion: Potential Data Model Improvements
Posted by David E Jones <de...@me.com>.
Could you be more specific?
-David
On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote:
> Why can't we use the pattern in the Data Model Resource book? It's simple and it works.
>
> -Adrian
>
>
> On 3/26/2011 9:57 AM, David E Jones wrote:
>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote:
>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
>> Yes, this is another good one. This the pattern I had in mind:
>>
>> <entity entity-name="PartyClassification" package-name="mantle.party.party">
>> <field name="partyClassificationId" type="id" is-pk="true"/>
>> <field name="classificationTypeEnumId" type="id"/>
>> <field name="parentClassificationId" type="id"/>
>> <field name="description" type="text-long"/>
>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration">
>> <key-map field-name="classificationTypeEnumId"/>
>> </relationship>
>> <relationship type="one" title="Parent" related-entity-name="PartyClassification">
>> <key-map field-name="parentClassificationId"/>
>> </relationship>
>> </entity>
>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party">
>> <field name="partyId" type="id" is-pk="true"/>
>> <field name="partyClassificationId" type="id" is-pk="true"/>
>> <field name="fromDate" type="date-time" is-pk="true"/>
>> <field name="thruDate" type="date-time"/>
>> <relationship type="one" related-entity-name="Party"/>
>> <relationship type="one" related-entity-name="PartyClassification"/>
>> </entity>
>>
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
Why can't we use the pattern in the Data Model Resource book? It's
simple and it works.
-Adrian
On 3/26/2011 9:57 AM, David E Jones wrote:
> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote:
>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
> Yes, this is another good one. This the pattern I had in mind:
>
> <entity entity-name="PartyClassification" package-name="mantle.party.party">
> <field name="partyClassificationId" type="id" is-pk="true"/>
> <field name="classificationTypeEnumId" type="id"/>
> <field name="parentClassificationId" type="id"/>
> <field name="description" type="text-long"/>
> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration">
> <key-map field-name="classificationTypeEnumId"/>
> </relationship>
> <relationship type="one" title="Parent" related-entity-name="PartyClassification">
> <key-map field-name="parentClassificationId"/>
> </relationship>
> </entity>
> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party">
> <field name="partyId" type="id" is-pk="true"/>
> <field name="partyClassificationId" type="id" is-pk="true"/>
> <field name="fromDate" type="date-time" is-pk="true"/>
> <field name="thruDate" type="date-time"/>
> <relationship type="one" related-entity-name="Party"/>
> <relationship type="one" related-entity-name="PartyClassification"/>
> </entity>
>
Re: Discussion: Potential Data Model Improvements
Posted by David E Jones <de...@me.com>.
On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote:
> Thanks David,
>
> they are all good points; here are a few more from my wish list:
>
> - Remove TechData* entities and use WorkEffort
Yeah, that's a good idea that would simplify the data model and make things more flexible (though make the manufacturing scheduling code somewhat more complex).
> - get rid of all the different GlAccount Default mappings entities and design a cleaner and central entity
As a start we could at least move all of these entities to the accounting component (ie put them all in a single package, and in a single file). If we consolidate various of these to a single entity would we use a generic related key column? It's always a bummer to lose foreign keys, but there are quite a few entities that follow the same pattern and it certainly could be simplified...
> - move return type from the return item and to the header
Yes, this is a mess of bad design, we have:
ReturnHeaderType
ReturnItemType
ReturnReason
ReturnType
IMO ReturnItem.returnTypeId should go to returnResponseEnumId (since it's really where the response is selected, and not a type for the return or the return item... at all), ReturnHeader.returnHeaderTypeId -> returnTypeEnumId, ReturnItem.returnItemTypeId -> itemTypeEnumId (use the shared item types mentioned in another item below to consolidate these so the same set are used for OrderItem, OrderAdjustment, InvoiceItem, ReturnItem, RequestItem, QuoteItem (irrelevant if/when Order* entities are used for quotes)
> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
Yes, this is another good one. This the pattern I had in mind:
<entity entity-name="PartyClassification" package-name="mantle.party.party">
<field name="partyClassificationId" type="id" is-pk="true"/>
<field name="classificationTypeEnumId" type="id"/>
<field name="parentClassificationId" type="id"/>
<field name="description" type="text-long"/>
<relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration">
<key-map field-name="classificationTypeEnumId"/>
</relationship>
<relationship type="one" title="Parent" related-entity-name="PartyClassification">
<key-map field-name="parentClassificationId"/>
</relationship>
</entity>
<entity entity-name="PartyClassificationAppl" package-name="mantle.party.party">
<field name="partyId" type="id" is-pk="true"/>
<field name="partyClassificationId" type="id" is-pk="true"/>
<field name="fromDate" type="date-time" is-pk="true"/>
<field name="thruDate" type="date-time"/>
<relationship type="one" related-entity-name="Party"/>
<relationship type="one" related-entity-name="PartyClassification"/>
</entity>
> - instead of OrderItemShipGrpInvRes we could use InventoryItemDetail (expanded)
This one I'm not sure about. I like the idea of changing "OrderItemShipGrpInvRes" to just InventoryReserveration and moving it to the product.inventory package, but the InventoryItemDetail entity is used to keep a history of changes to the quantities/etc on an InventoryItem and the reservation records are created and removed as needed for the actual reservations needed, so I'm not sure it would be a good fit.
-David
>
> Kind regards,
>
> Jacopo
>
> On Mar 20, 2011, at 4:33 AM, David E Jones wrote:
>
>>
>> I'm writing this to start a thread to discuss:
>>
>> If you could change ANYTHING in the OFBiz data model, what would it be?
>>
>> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>>
>> -David
>>
>> ========================================================
>>
>> - Rename *Role entities to *Party
>> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
>> - Remove all status history (*Status) and just using audit on the statusId field
>> - ProductPrice add quantity breaks, change PK to single field sequenced
>> - Get rid of QuantityBreak and use the two simple fields instead in each place used
>> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
>> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced
>> - Change Quote to be other types of Order
>> - Make Return more like Invoice (ie no adjustment, just use items for everything)
>> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere
>> - PartyRelationship simplify (single sequenced ID)
>>
>> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc
>> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType
>> - Move most *Type entities to Enumeration values (update seed data, referring
>> entities, remove *Type) (after this remove all remaining hasTable fields)
>> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem
>> - Review use of Appl, Assoc (look at book, make sure consistent)
>> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...)
>> - Change GoodIdentification to ProductIdentification
>> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech)
>> - Get rid of NoteData, put noteText very-long field directly on various *Note entities
>> - Review all entities with large PKs (esp 4+ fields)
>> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field
>> - CustRequest to Request
>> - FinAccount to FinancialAccount
>> - Invoice handle recurrence? (was using RecurrenceInfo)
>> - Get rid of optional ProductFeature concept (conf/etc products much better model)
>> - Instead of various *Term entities and mapping, just use OrderTerm everywhere
>> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
>> - Agreement - make price list easier/cleaner
>> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log)
>> - Product clean up: move dimenstions to new entity, remove content fields, etc
>> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure
>>
>>
>
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
+1 On WorkEffort redesign.
+1 On PartyClassification redesign.
On 3/22/2011 5:27 AM, Jacopo Cappellato wrote:
> Thanks David,
>
> they are all good points; here are a few more from my wish list:
>
> - Remove TechData* entities and use WorkEffort
> - get rid of all the different GlAccount Default mappings entities and design a cleaner and central entity
> - move return type from the return item and to the header
> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
> - instead of OrderItemShipGrpInvRes we could use InventoryItemDetail (expanded)
>
> Kind regards,
>
> Jacopo
>
> On Mar 20, 2011, at 4:33 AM, David E Jones wrote:
>
>> I'm writing this to start a thread to discuss:
>>
>> If you could change ANYTHING in the OFBiz data model, what would it be?
>>
>> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>>
>> -David
>>
>> ========================================================
>>
>> - Rename *Role entities to *Party
>> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
>> - Remove all status history (*Status) and just using audit on the statusId field
>> - ProductPrice add quantity breaks, change PK to single field sequenced
>> - Get rid of QuantityBreak and use the two simple fields instead in each place used
>> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
>> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced
>> - Change Quote to be other types of Order
>> - Make Return more like Invoice (ie no adjustment, just use items for everything)
>> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere
>> - PartyRelationship simplify (single sequenced ID)
>>
>> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc
>> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType
>> - Move most *Type entities to Enumeration values (update seed data, referring
>> entities, remove *Type) (after this remove all remaining hasTable fields)
>> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem
>> - Review use of Appl, Assoc (look at book, make sure consistent)
>> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...)
>> - Change GoodIdentification to ProductIdentification
>> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech)
>> - Get rid of NoteData, put noteText very-long field directly on various *Note entities
>> - Review all entities with large PKs (esp 4+ fields)
>> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field
>> - CustRequest to Request
>> - FinAccount to FinancialAccount
>> - Invoice handle recurrence? (was using RecurrenceInfo)
>> - Get rid of optional ProductFeature concept (conf/etc products much better model)
>> - Instead of various *Term entities and mapping, just use OrderTerm everywhere
>> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
>> - Agreement - make price list easier/cleaner
>> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log)
>> - Product clean up: move dimenstions to new entity, remove content fields, etc
>> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure
>>
>>
Re: Discussion: Potential Data Model Improvements
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Thanks David,
they are all good points; here are a few more from my wish list:
- Remove TechData* entities and use WorkEffort
- get rid of all the different GlAccount Default mappings entities and design a cleaner and central entity
- move return type from the return item and to the header
- redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification
- instead of OrderItemShipGrpInvRes we could use InventoryItemDetail (expanded)
Kind regards,
Jacopo
On Mar 20, 2011, at 4:33 AM, David E Jones wrote:
>
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>
> -David
>
> ========================================================
>
> - Rename *Role entities to *Party
> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
> - Remove all status history (*Status) and just using audit on the statusId field
> - ProductPrice add quantity breaks, change PK to single field sequenced
> - Get rid of QuantityBreak and use the two simple fields instead in each place used
> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced
> - Change Quote to be other types of Order
> - Make Return more like Invoice (ie no adjustment, just use items for everything)
> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere
> - PartyRelationship simplify (single sequenced ID)
>
> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc
> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType
> - Move most *Type entities to Enumeration values (update seed data, referring
> entities, remove *Type) (after this remove all remaining hasTable fields)
> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem
> - Review use of Appl, Assoc (look at book, make sure consistent)
> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...)
> - Change GoodIdentification to ProductIdentification
> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech)
> - Get rid of NoteData, put noteText very-long field directly on various *Note entities
> - Review all entities with large PKs (esp 4+ fields)
> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field
> - CustRequest to Request
> - FinAccount to FinancialAccount
> - Invoice handle recurrence? (was using RecurrenceInfo)
> - Get rid of optional ProductFeature concept (conf/etc products much better model)
> - Instead of various *Term entities and mapping, just use OrderTerm everywhere
> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
> - Agreement - make price list easier/cleaner
> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log)
> - Product clean up: move dimenstions to new entity, remove content fields, etc
> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure
>
>
Re: Discussion: Potential Data Model Improvements
Posted by David E Jones <de...@me.com>.
The point is not how, the point is what.
-David
On Mar 22, 2011, at 12:43 AM, Hans Bakker wrote:
> Sure, this would certainly improve things, but we need an upgrade path
> and conversion programs.
>
> Further we need a version number related to the entity because the 'old'
> pattern does not do so well when there are several versions in the
> system: 'old', 'older' oldest'?
>
> Regards,
> Hans
>
>
> On Sat, 2011-03-19 at 21:33 -0600, David E Jones wrote:
>> I'm writing this to start a thread to discuss:
>>
>> If you could change ANYTHING in the OFBiz data model, what would it be?
>>
>> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>>
>> -David
>>
>> ========================================================
>>
>> - Rename *Role entities to *Party
>> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
>> - Remove all status history (*Status) and just using audit on the statusId field
>> - ProductPrice add quantity breaks, change PK to single field sequenced
>> - Get rid of QuantityBreak and use the two simple fields instead in each place used
>> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
>> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced
>> - Change Quote to be other types of Order
>> - Make Return more like Invoice (ie no adjustment, just use items for everything)
>> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere
>> - PartyRelationship simplify (single sequenced ID)
>>
>> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc
>> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType
>> - Move most *Type entities to Enumeration values (update seed data, referring
>> entities, remove *Type) (after this remove all remaining hasTable fields)
>> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem
>> - Review use of Appl, Assoc (look at book, make sure consistent)
>> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...)
>> - Change GoodIdentification to ProductIdentification
>> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech)
>> - Get rid of NoteData, put noteText very-long field directly on various *Note entities
>> - Review all entities with large PKs (esp 4+ fields)
>> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field
>> - CustRequest to Request
>> - FinAccount to FinancialAccount
>> - Invoice handle recurrence? (was using RecurrenceInfo)
>> - Get rid of optional ProductFeature concept (conf/etc products much better model)
>> - Instead of various *Term entities and mapping, just use OrderTerm everywhere
>> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
>> - Agreement - make price list easier/cleaner
>> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log)
>> - Product clean up: move dimenstions to new entity, remove content fields, etc
>> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure
>>
>>
>
> --
> Ofbiz on twitter: http://twitter.com/apache_ofbiz
> Myself on twitter: http://twitter.com/hansbak
> Antwebsystems.com: Quality services for competitive rates.
>
Re: Discussion: Potential Data Model Improvements
Posted by Hans Bakker <ma...@antwebsystems.com>.
Sure, this would certainly improve things, but we need an upgrade path
and conversion programs.
Further we need a version number related to the entity because the 'old'
pattern does not do so well when there are several versions in the
system: 'old', 'older' oldest'?
Regards,
Hans
On Sat, 2011-03-19 at 21:33 -0600, David E Jones wrote:
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>
> -David
>
> ========================================================
>
> - Rename *Role entities to *Party
> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use)
> - Remove all status history (*Status) and just using audit on the statusId field
> - ProductPrice add quantity breaks, change PK to single field sequenced
> - Get rid of QuantityBreak and use the two simple fields instead in each place used
> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store
> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced
> - Change Quote to be other types of Order
> - Make Return more like Invoice (ie no adjustment, just use items for everything)
> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere
> - PartyRelationship simplify (single sequenced ID)
>
> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc
> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType
> - Move most *Type entities to Enumeration values (update seed data, referring
> entities, remove *Type) (after this remove all remaining hasTable fields)
> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem
> - Review use of Appl, Assoc (look at book, make sure consistent)
> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...)
> - Change GoodIdentification to ProductIdentification
> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech)
> - Get rid of NoteData, put noteText very-long field directly on various *Note entities
> - Review all entities with large PKs (esp 4+ fields)
> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field
> - CustRequest to Request
> - FinAccount to FinancialAccount
> - Invoice handle recurrence? (was using RecurrenceInfo)
> - Get rid of optional ProductFeature concept (conf/etc products much better model)
> - Instead of various *Term entities and mapping, just use OrderTerm everywhere
> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
> - Agreement - make price list easier/cleaner
> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log)
> - Product clean up: move dimenstions to new entity, remove content fields, etc
> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure
>
>
--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.
Re: Discussion: Potential Data Model Improvements
Posted by Jacques Le Roux <ja...@les7arts.com>.
On Saturday, January 18, 2014 5:34 PM, pierre.smits@gmail.com wrote
> Indeed, doing cleanups in the data model is a major feat requiring
> awareness, focus and coordination.
> But not putting these improvement issues on the docket (roadmap) will
> ensure that the suggestions (discussion items) done in this thread will be
> overwhelmed by other threads and keep recurring as discussion topics not
> addressed.
> But also the perception of (potential) organisations, that investing in
> (the implementation of) OFBiz is a valid option, will wither and die.
I tend to agree
> After incorporating these improvement issues in the roadmap, associated
> JIRA issues can be created to discuss impact in detail, increase awareness
> of impact and dependencies, and integration can be planned. In stead of
> muddling along on the path where we are now.
We could discuss it again, but IIRW the path is:
1) Discuss ideas/concepts, define/refine requirements/data-models on dev ML (simply because it's faster and easier for most, if not all of us, at the ASF Jira and Confluence can be slow...)
2) Write them in Confluence
3) Open corresponding Jira issues (grouping them can help, how to group depends but sub-tasks sounds easier to me)
> If the community would embark on the endeavour regarding the cleanup the
> data model, services and ui aspects, it would warrant a new branch of trunk
> leading to new version of OFBiz.
Premature, we should before estimate who wants to do what, the bottleneck as always been the manpower.
I noted we should prune https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
Future is still not a priority to me (hopefully soon). I'm still in cleaning and securing stuff.
> I believe that this could also recharge the community to interact more and
> even grow. Otherwise this project will not live long enough to celebrate a
> second decade.
It would be a pity.
Things like node.js and AKKA are quickly gaining interest (for good reasons).
Still all those lack what OFBiz framework has around it (even is not perfect).
Jacques
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Sat, Jan 18, 2014 at 11:04 AM, David E. Jones <de...@me.com> wrote:
>
>>
>> Doing significant data model cleanups and changes is a LOT of work with a
>> large code base and user community. All code that uses the data structure
>> needs to be changes, and accommodations are needed for deprecating the old
>> entity or fields and migrating data to the new ones. So yes, to the point
>> Jacques made, it's not likely short-term and without significant investment
>> and coordination with others in the community it is not really likely
>> long-term either.
>>
>> For years I built up a list of changes that would be nice to do in OFBiz
>> itself, but so many are not really feasible. There may still be some of
>> them worth doing, so for some ideas to consider here are my change notes
>> for the Mantle data model:
>>
>> https://github.com/jonesde/mantle/blob/master/mantle-udm/Planning.txt
>>
>> At this point there are lots of generic services and end-to-end automated
>> tests that use many of these changes to the data structures so they are
>> pretty well vetted and validated and not just theoretical like when this
>> thread started a couple years ago. One of the benefits to many of these
>> changes is that not only is the data model smaller and cleaner, but it
>> makes it possible to simplify or eliminate large amounts of logic layer
>> code.
>>
>> For OFBiz, along the lines of the reasons mentioned above, that would
>> involve quite a few code changes but maybe the best way to look at it is
>> that this is the main reason to do the data model changes (ie simplifying
>> and eliminating code) as opposed to just changing the data model for the
>> sake of the data model itself.
>>
>> -David
>>
>>
>>
>> On Jan 17, 2014, at 4:57 AM, Jacques Le Roux <ja...@les7arts.com>
>> wrote:
>>
>>> I think it's still alive, but I bet it will not be short-term...
>>>
>>> Jacques
>>>
>>> On Friday, January 17, 2014 12:34 PM, pierre.smits@gmail.com wrote
>>>> Is this subject still valid? And wouldn't it be great to have one (or some)
>>>> of the subjects on the (short-term) roadmap?
>>>>
>>>> Regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
Re: Discussion: Potential Data Model Improvements
Posted by Pierre Smits <pi...@gmail.com>.
Indeed, doing cleanups in the data model is a major feat requiring
awareness, focus and coordination.
But not putting these improvement issues on the docket (roadmap) will
ensure that the suggestions (discussion items) done in this thread will be
overwhelmed by other threads and keep recurring as discussion topics not
addressed.
But also the perception of (potential) organisations, that investing in
(the implementation of) OFBiz is a valid option, will wither and die.
After incorporating these improvement issues in the roadmap, associated
JIRA issues can be created to discuss impact in detail, increase awareness
of impact and dependencies, and integration can be planned. In stead of
muddling along on the path where we are now.
If the community would embark on the endeavour regarding the cleanup the
data model, services and ui aspects, it would warrant a new branch of trunk
leading to new version of OFBiz.
I believe that this could also recharge the community to interact more and
even grow. Otherwise this project will not live long enough to celebrate a
second decade.
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sat, Jan 18, 2014 at 11:04 AM, David E. Jones <de...@me.com> wrote:
>
> Doing significant data model cleanups and changes is a LOT of work with a
> large code base and user community. All code that uses the data structure
> needs to be changes, and accommodations are needed for deprecating the old
> entity or fields and migrating data to the new ones. So yes, to the point
> Jacques made, it's not likely short-term and without significant investment
> and coordination with others in the community it is not really likely
> long-term either.
>
> For years I built up a list of changes that would be nice to do in OFBiz
> itself, but so many are not really feasible. There may still be some of
> them worth doing, so for some ideas to consider here are my change notes
> for the Mantle data model:
>
> https://github.com/jonesde/mantle/blob/master/mantle-udm/Planning.txt
>
> At this point there are lots of generic services and end-to-end automated
> tests that use many of these changes to the data structures so they are
> pretty well vetted and validated and not just theoretical like when this
> thread started a couple years ago. One of the benefits to many of these
> changes is that not only is the data model smaller and cleaner, but it
> makes it possible to simplify or eliminate large amounts of logic layer
> code.
>
> For OFBiz, along the lines of the reasons mentioned above, that would
> involve quite a few code changes but maybe the best way to look at it is
> that this is the main reason to do the data model changes (ie simplifying
> and eliminating code) as opposed to just changing the data model for the
> sake of the data model itself.
>
> -David
>
>
>
> On Jan 17, 2014, at 4:57 AM, Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
> > I think it's still alive, but I bet it will not be short-term...
> >
> > Jacques
> >
> > On Friday, January 17, 2014 12:34 PM, pierre.smits@gmail.com wrote
> >> Is this subject still valid? And wouldn't it be great to have one (or
> some)
> >> of the subjects on the (short-term) roadmap?
> >>
> >> Regards,
> >>
> >> Pierre Smits
> >>
> >> *ORRTIZ.COM <http://www.orrtiz.com>*
> >> Services & Solutions for Cloud-
> >> Based Manufacturing, Professional
> >> Services and Retail & Trade
> >> http://www.orrtiz.com
>
>
Re: Discussion: Potential Data Model Improvements
Posted by "David E. Jones" <de...@me.com>.
Doing significant data model cleanups and changes is a LOT of work with a large code base and user community. All code that uses the data structure needs to be changes, and accommodations are needed for deprecating the old entity or fields and migrating data to the new ones. So yes, to the point Jacques made, it's not likely short-term and without significant investment and coordination with others in the community it is not really likely long-term either.
For years I built up a list of changes that would be nice to do in OFBiz itself, but so many are not really feasible. There may still be some of them worth doing, so for some ideas to consider here are my change notes for the Mantle data model:
https://github.com/jonesde/mantle/blob/master/mantle-udm/Planning.txt
At this point there are lots of generic services and end-to-end automated tests that use many of these changes to the data structures so they are pretty well vetted and validated and not just theoretical like when this thread started a couple years ago. One of the benefits to many of these changes is that not only is the data model smaller and cleaner, but it makes it possible to simplify or eliminate large amounts of logic layer code.
For OFBiz, along the lines of the reasons mentioned above, that would involve quite a few code changes but maybe the best way to look at it is that this is the main reason to do the data model changes (ie simplifying and eliminating code) as opposed to just changing the data model for the sake of the data model itself.
-David
On Jan 17, 2014, at 4:57 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
> I think it's still alive, but I bet it will not be short-term...
>
> Jacques
>
> On Friday, January 17, 2014 12:34 PM, pierre.smits@gmail.com wrote
>> Is this subject still valid? And wouldn't it be great to have one (or some)
>> of the subjects on the (short-term) roadmap?
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
Re: Discussion: Potential Data Model Improvements
Posted by Jacques Le Roux <ja...@les7arts.com>.
I think it's still alive, but I bet it will not be short-term...
Jacques
On Friday, January 17, 2014 12:34 PM, pierre.smits@gmail.com wrote
> Is this subject still valid? And wouldn't it be great to have one (or some)
> of the subjects on the (short-term) roadmap?
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
Re: Discussion: Potential Data Model Improvements
Posted by Pierre Smits <pi...@gmail.com>.
Is this subject still valid? And wouldn't it be great to have one (or some)
of the subjects on the (short-term) roadmap?
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/20/2011 3:33 AM, David E Jones wrote:
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>
> -David
>
> ========================================================
>
> - Move most *Type entities to Enumeration values (update seed data, referring
> entities, remove *Type) (after this remove all remaining hasTable fields)
I have been thinking about this one and I have come up with an idea. I
believe some of the *Type entities were meant to implement the entity
subtypes mentioned in The Data Model Resource book. In some cases, that
distinction is lost over time and the *Type entity contains values that
have nothing to do with subtyping the related entity. So, for the entity
subtype cases we could have something like an EntitySubtype entity, and
use a standard ID field name in all subtyped entities - like
entitySubTypeId. That approach could still be abused, but at least the
original intent of the id field can be preserved.
-Adrian
Re: Discussion: Potential Data Model Improvements
Posted by Joe Eckard <ec...@redrocketcorp.com>.
On Mar 21, 2011, at 2:34 AM, David E Jones wrote:
>
> On Mar 20, 2011, at 10:02 AM, Joe Eckard wrote:
>
>>
>> On Mar 19, 2011, at 11:33 PM, David E Jones wrote:
>>
>>>
>>> I'm writing this to start a thread to discuss:
>>>
>>> If you could change ANYTHING in the OFBiz data model, what would it be?
>>>
>>> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>>>
>>> -David
>>>
>>> ========================================================
>>>
>>>
>>> - Move most *Type entities to Enumeration values (update seed data, referring
>>> entities, remove *Type) (after this remove all remaining hasTable fields)
>>
>> Related to this:
>>
>> - Add the enumTypeId to the entity definition for the field
>>
>> <field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ...
>
> That's an interesting idea, make the framework aware of the EnumerationTypes...
>
> What I'm thinking of instead would be to use a convention, basically have the relation(ship).@title attribute be the enumTypeId (and use CamelCasing for the enumTypeIds).
>
That would work also, anything that would let you determine the type to look for. When I was building a generic entity editor in wicket, not being able to determine this programmatically was a big problem.
>> Also,
>>
>> - Make userLoginId an ID that isn't changed, add a field for "name" that can be updated
>
> Yeah, that's a good idea. I like it enough that I just changed Moqui to work that way.
>
> Right now OFBiz has a work-around for changing usernames by creating a new UserLogin record and attaching it to the same Party. Since most stuff in the system records by party this works okay, but it's true that there is still a lot of stuff attached to the userLoginId that wouldn't be carried over, so this approach you're talking about is clearly better.
>
>
>> - Condense credit card name fields (first, middle, last, prefix, suffix, etc.) into a single "nameOnCard"
>
> This one I'm not so sure about. The OFBiz CreditCard entity actually started out with a single field for the name on card (and one for the company name on card), and then we ran into a problem where certain payment processors ask for separate first/middle/last names, and splitting based on spaces is not reliable (especially for those with multiple last names, etc).
>
You're right, I didn't look into the other payment processors. I've worked with several large ones in the past and they all either didn't use the name, or accepted a single name field and I was concerned about the re-assembled name not matching what someone could have entered as a single string.
> Is there are particular reason you've found the separated fields annoying?
>
> -David
>
>
Re: Discussion: Potential Data Model Improvements
Posted by David E Jones <de...@me.com>.
On Mar 20, 2011, at 10:02 AM, Joe Eckard wrote:
>
> On Mar 19, 2011, at 11:33 PM, David E Jones wrote:
>
>>
>> I'm writing this to start a thread to discuss:
>>
>> If you could change ANYTHING in the OFBiz data model, what would it be?
>>
>> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>>
>> -David
>>
>> ========================================================
>>
>>
>> - Move most *Type entities to Enumeration values (update seed data, referring
>> entities, remove *Type) (after this remove all remaining hasTable fields)
>
> Related to this:
>
> - Add the enumTypeId to the entity definition for the field
>
> <field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ...
That's an interesting idea, make the framework aware of the EnumerationTypes...
What I'm thinking of instead would be to use a convention, basically have the relation(ship).@title attribute be the enumTypeId (and use CamelCasing for the enumTypeIds).
> Also,
>
> - Make userLoginId an ID that isn't changed, add a field for "name" that can be updated
Yeah, that's a good idea. I like it enough that I just changed Moqui to work that way.
Right now OFBiz has a work-around for changing usernames by creating a new UserLogin record and attaching it to the same Party. Since most stuff in the system records by party this works okay, but it's true that there is still a lot of stuff attached to the userLoginId that wouldn't be carried over, so this approach you're talking about is clearly better.
> - Condense credit card name fields (first, middle, last, prefix, suffix, etc.) into a single "nameOnCard"
This one I'm not so sure about. The OFBiz CreditCard entity actually started out with a single field for the name on card (and one for the company name on card), and then we ran into a problem where certain payment processors ask for separate first/middle/last names, and splitting based on spaces is not reliable (especially for those with multiple last names, etc).
Is there are particular reason you've found the separated fields annoying?
-David
Re: Discussion: Potential Data Model Improvements
Posted by Brett Palmer <br...@gmail.com>.
I agree with Joe on making the userLoginId a "system ID" and allowing the
user to change their userName. This would work a like the current partyId.
We would still require the userName to be unique but it could be changed
without impact so many other tables.
Brett
On Sun, Mar 20, 2011 at 10:02 AM, Joe Eckard <ec...@redrocketcorp.com>wrote:
>
> On Mar 19, 2011, at 11:33 PM, David E Jones wrote:
>
> >
> > I'm writing this to start a thread to discuss:
> >
> > If you could change ANYTHING in the OFBiz data model, what would it be?
> >
> > To kick this off here are some ideas I've compiled that have come up over
> the years (many based on feedback from people on this mailing list), or that
> I thought of recently will working on this topic. You can see them below...
> >
> > -David
> >
> > ========================================================
> >
> >
> > - Move most *Type entities to Enumeration values (update seed data,
> referring
> > entities, remove *Type) (after this remove all remaining hasTable
> fields)
>
> Related to this:
>
> - Add the enumTypeId to the entity definition for the field
>
> <field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ...
>
> Also,
>
> - Make userLoginId an ID that isn't changed, add a field for "name" that
> can be updated
>
> - Condense credit card name fields (first, middle, last, prefix, suffix,
> etc.) into a single "nameOnCard"
>
>
>
Re: Discussion: Potential Data Model Improvements
Posted by Joe Eckard <ec...@redrocketcorp.com>.
On Mar 19, 2011, at 11:33 PM, David E Jones wrote:
>
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>
> -David
>
> ========================================================
>
>
> - Move most *Type entities to Enumeration values (update seed data, referring
> entities, remove *Type) (after this remove all remaining hasTable fields)
Related to this:
- Add the enumTypeId to the entity definition for the field
<field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ...
Also,
- Make userLoginId an ID that isn't changed, add a field for "name" that can be updated
- Condense credit card name fields (first, middle, last, prefix, suffix, etc.) into a single "nameOnCard"
Re: Discussion: Potential Data Model Improvements
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 3/19/2011 8:33 PM, David E Jones wrote:
> I'm writing this to start a thread to discuss:
>
> If you could change ANYTHING in the OFBiz data model, what would it be?
>
> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below...
>
> -David
>
> ========================================================
> - CustRequest to Request
+1000
That entity is a mess. Some of its fields duplicate its related
entities. I prefer the model in the DMRB.
-Adrian
Re: Discussion: Potential Data Model Improvements
Posted by BJ Freeman <bj...@free-man.net>.
my understanding of ofbiz basic design is that the entity define the UI
display, which this statement does not follow.
so till the Javascript is generated on the fly in the Webapp I consider
all efforts to integrate JS, extra effort for the reason stated here.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Nicolas Malin sent the following on 5/17/2011 2:05 AM:
> My comments inline...
>
> [...]
>>>>>> QuantityBreak
>>>>>> ---------------------
>>>>>>
>>>>>> No, don’t get rid of the QuantityBreak entity, and it should be
>>>>>> used as
>>>>>> part
>>>>>> of pricing. Many organisations will have standard QuantityBreaks that
>>>>>> apply
>>>>>> to a wide range of products. An organization might want to offer
>>>>>> various
>>>>>> agreed prices to customers, but use the same quantity breaks
>>>>>> consistently.
>>>>>> It should be possible to add a new price for a product without having
>>>>>> to
>>>>>> define quantity breaks, with the risk that the newly entered quantity
>>>>>> breaks
>>>>>> are inconsistent with standard organisation policy.
>>>>> Maybe this wasn't clear... the goal is to get rid of the QuantityBreak
>>>>> entity and use the quantity fields directly. This significantly
>>>>> simplifies
>>>>> both the data model and the code. In theory what you say is correct,
>>>>> that
>>>>> quantity breaks could be maintained separately, but that hasn't
>>>>> happened
>>>>> in
>>>>> any of the OFBiz UIs, and in fact I've never seen anything like that
>>>>> actually used (I've seen them built, but then abandoned because for
>>>>> the
>>>>> user
>>>>> they are cumbersome).
>>>>>
>>>>> If an organization wants a policy of specific quantity breaks they can
>>>>> certainly implement that and design the user interface for it, even
>>>>> with
>>>>> the
>>>>> data model designed this way.
>>>>>
>>>> QuantityBreak is also used for shipping, and quantity breaks for
>>>> shipping
>>>> are often in terms of weight. I think that's sensible, and the entity
>>>> should
>>>> not be removed altogether.
>>> I'm not quite suire I get clearly which were the 2 quantity fields you
>>> spoke about David, I guess it's for pricing and shipping?
>>> Then, I tend to agree with Paul here about keeping the QuantityBreak
>>> Entity even if we could refactor the code to use the 2 fields
>>> (did not look into code and I don't remember OTTOMH). They could
>>> still be
>>> useful in some specific cases.
>>>
>>>> For product pricing as opposed to shipping, how about keeping
>>>> QuantityBreak,
>>>> but only to support UIs? Remove the relationship between QuantityBreak
>>>> and
>>>> product pricing. What does everyone think?
>>> Yes that sounds good to me. The best way would be to provide a patch
>>> in a
>>> Jira. If it's not used OOTB (Paul's assertion, to be
>>> confirmed) then I think we don't need to provide a way for data
>>> migration
>>> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
>>>
> I prefere keep QuantityBreak entity to given the possibility to define
> prototype input for user screen.
> With QuantityBreakType it's easier to define many formated table price
> depending on product type.
>
> Nicolas
>
Re: Discussion: Potential Data Model Improvements
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Nicolas Malin" <ma...@librenberry.net>
> My comments inline...
>
> [...]
>>>>>> QuantityBreak
>>>>>> ---------------------
>>>>>>
>>>>>> No, don’t get rid of the QuantityBreak entity, and it should be used as
>>>>>> part
>>>>>> of pricing. Many organisations will have standard QuantityBreaks that
>>>>>> apply
>>>>>> to a wide range of products. An organization might want to offer
>>>>>> various
>>>>>> agreed prices to customers, but use the same quantity breaks
>>>>>> consistently.
>>>>>> It should be possible to add a new price for a product without having
>>>>>> to
>>>>>> define quantity breaks, with the risk that the newly entered quantity
>>>>>> breaks
>>>>>> are inconsistent with standard organisation policy.
>>>>> Maybe this wasn't clear... the goal is to get rid of the QuantityBreak
>>>>> entity and use the quantity fields directly. This significantly
>>>>> simplifies
>>>>> both the data model and the code. In theory what you say is correct,
>>>>> that
>>>>> quantity breaks could be maintained separately, but that hasn't happened
>>>>> in
>>>>> any of the OFBiz UIs, and in fact I've never seen anything like that
>>>>> actually used (I've seen them built, but then abandoned because for the
>>>>> user
>>>>> they are cumbersome).
>>>>>
>>>>> If an organization wants a policy of specific quantity breaks they can
>>>>> certainly implement that and design the user interface for it, even with
>>>>> the
>>>>> data model designed this way.
>>>>>
>>>> QuantityBreak is also used for shipping, and quantity breaks for shipping
>>>> are often in terms of weight. I think that's sensible, and the entity
>>>> should
>>>> not be removed altogether.
>>> I'm not quite suire I get clearly which were the 2 quantity fields you
>>> spoke about David, I guess it's for pricing and shipping?
>>> Then, I tend to agree with Paul here about keeping the QuantityBreak
>>> Entity even if we could refactor the code to use the 2 fields
>>> (did not look into code and I don't remember OTTOMH). They could still be
>>> useful in some specific cases.
>>>
>>>> For product pricing as opposed to shipping, how about keeping
>>>> QuantityBreak,
>>>> but only to support UIs? Remove the relationship between QuantityBreak
>>>> and
>>>> product pricing. What does everyone think?
>>> Yes that sounds good to me. The best way would be to provide a patch in a
>>> Jira. If it's not used OOTB (Paul's assertion, to be
>>> confirmed) then I think we don't need to provide a way for data migration
>>> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
> I prefere keep QuantityBreak entity to given the possibility to define prototype input for user screen.
> With QuantityBreakType it's easier to define many formated table price depending on product type.
>
> Nicolas
Nicolas,
Anyway, it seems to me that David was mostly inquiring possible changes for Moqui but did not expect to do the same in OFBiz. I
might be wrong...
Jacques
> --
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>
Re: Discussion: Potential Data Model Improvements
Posted by Nicolas Malin <ma...@librenberry.net>.
My comments inline...
[...]
>>>>> QuantityBreak
>>>>> ---------------------
>>>>>
>>>>> No, don’t get rid of the QuantityBreak entity, and it should be used as
>>>>> part
>>>>> of pricing. Many organisations will have standard QuantityBreaks that
>>>>> apply
>>>>> to a wide range of products. An organization might want to offer
>>>>> various
>>>>> agreed prices to customers, but use the same quantity breaks
>>>>> consistently.
>>>>> It should be possible to add a new price for a product without having
>>>>> to
>>>>> define quantity breaks, with the risk that the newly entered quantity
>>>>> breaks
>>>>> are inconsistent with standard organisation policy.
>>>> Maybe this wasn't clear... the goal is to get rid of the QuantityBreak
>>>> entity and use the quantity fields directly. This significantly
>>>> simplifies
>>>> both the data model and the code. In theory what you say is correct,
>>>> that
>>>> quantity breaks could be maintained separately, but that hasn't happened
>>>> in
>>>> any of the OFBiz UIs, and in fact I've never seen anything like that
>>>> actually used (I've seen them built, but then abandoned because for the
>>>> user
>>>> they are cumbersome).
>>>>
>>>> If an organization wants a policy of specific quantity breaks they can
>>>> certainly implement that and design the user interface for it, even with
>>>> the
>>>> data model designed this way.
>>>>
>>> QuantityBreak is also used for shipping, and quantity breaks for shipping
>>> are often in terms of weight. I think that's sensible, and the entity
>>> should
>>> not be removed altogether.
>> I'm not quite suire I get clearly which were the 2 quantity fields you
>> spoke about David, I guess it's for pricing and shipping?
>> Then, I tend to agree with Paul here about keeping the QuantityBreak
>> Entity even if we could refactor the code to use the 2 fields
>> (did not look into code and I don't remember OTTOMH). They could still be
>> useful in some specific cases.
>>
>>> For product pricing as opposed to shipping, how about keeping
>>> QuantityBreak,
>>> but only to support UIs? Remove the relationship between QuantityBreak
>>> and
>>> product pricing. What does everyone think?
>> Yes that sounds good to me. The best way would be to provide a patch in a
>> Jira. If it's not used OOTB (Paul's assertion, to be
>> confirmed) then I think we don't need to provide a way for data migration
>> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
I prefere keep QuantityBreak entity to given the possibility to define
prototype input for user screen.
With QuantityBreakType it's easier to define many formated table price
depending on product type.
Nicolas
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Discussion: Potential Data Model Improvements
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Further to my last post re VAT/GST on purchase orders...
I have double-checked and I was wrong about accounting for Australian GST
from purchase orders. When a business chooses accrual accounting, it is
always the sending or arrival of an invoice that changes your GST-related
liability . Smaller businesses have the option of cash accounting, where
actual payments, not invoices, change the liability.
Sorry for the mistake.
I still think estimating the tax when a purchase order is created is useful.
We would know what we expect to pay in total, and if we choose to send
payment with the purchase order, the payment would be tax-inclusive.
Cheers
Paul Foxworthy
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Discussion-Potential-Data-Model-Improvements-tp3390620p3513587.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Discussion: Potential Data Model Improvements
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Thanks Jacques.
My comments inline...
Cheers
Paul Foxworthy
Jacques Le Roux-3 wrote:
>
> Paul Foxworthy wrote:
>> Hi David,
>>
>> Many thanks for your comments.
>>
>> My responses inline....
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>> On Apr 2, 2011, at 5:41 AM, Paul Foxworthy wrote:
>>>
>>>> Status History
>>>> ---------------------
>>>>
>>>> I can see the sense in having one repository for all change tracking.
>>>> We
>>>> just need to bear in mind there are more use cases for using the
>>>> information
>>>> in the repository than “auditing”. Auditing is a security activity, and
>>>> it
>>>> will be security professionals looking at a history of who did what.
>>>> Looking
>>>> at a status history could well be a business activity with no security
>>>> dimension to it. So viewing the history of changes to an order’s status
>>>> might be something a manager would do.
>>>>
>>>> We would need to structure permissions so that people who need some of
>>>> the
>>>> information for business purposes can use it even though they are not
>>>> security professionals. The other thing to observe is that status
>>>> history is
>>>> currently *on* by default in Ofbiz, and auditing is *off* by default.
>>>
>>> The "audit log" is a pretty general term and does not imply restricted
>>> access to the information. Control of access to any database information
>>> is
>>> up to the application developer, and nothing about the term "audit log"
>>> prevents that.
>>>
>>
>> Cool. Do you think it would be a good idea to have limited auditing
>> enabled
>> from the beginning in a demo/starter system, the rough equivalent of the
>> current status history?
>
> IMO, this could be interesting as a POC demo. Could be used on Example
> entity only for instance.
>
>>
>>>> QuantityBreak
>>>> ---------------------
>>>>
>>>> No, don’t get rid of the QuantityBreak entity, and it should be used as
>>>> part
>>>> of pricing. Many organisations will have standard QuantityBreaks that
>>>> apply
>>>> to a wide range of products. An organization might want to offer
>>>> various
>>>> agreed prices to customers, but use the same quantity breaks
>>>> consistently.
>>>> It should be possible to add a new price for a product without having
>>>> to
>>>> define quantity breaks, with the risk that the newly entered quantity
>>>> breaks
>>>> are inconsistent with standard organisation policy.
>>>
>>> Maybe this wasn't clear... the goal is to get rid of the QuantityBreak
>>> entity and use the quantity fields directly. This significantly
>>> simplifies
>>> both the data model and the code. In theory what you say is correct,
>>> that
>>> quantity breaks could be maintained separately, but that hasn't happened
>>> in
>>> any of the OFBiz UIs, and in fact I've never seen anything like that
>>> actually used (I've seen them built, but then abandoned because for the
>>> user
>>> they are cumbersome).
>>>
>>> If an organization wants a policy of specific quantity breaks they can
>>> certainly implement that and design the user interface for it, even with
>>> the
>>> data model designed this way.
>>>
>>
>> QuantityBreak is also used for shipping, and quantity breaks for shipping
>> are often in terms of weight. I think that's sensible, and the entity
>> should
>> not be removed altogether.
>
> I'm not quite suire I get clearly which were the 2 quantity fields you
> spoke about David, I guess it's for pricing and shipping?
> Then, I tend to agree with Paul here about keeping the QuantityBreak
> Entity even if we could refactor the code to use the 2 fields
> (did not look into code and I don't remember OTTOMH). They could still be
> useful in some specific cases.
>
>> For product pricing as opposed to shipping, how about keeping
>> QuantityBreak,
>> but only to support UIs? Remove the relationship between QuantityBreak
>> and
>> product pricing. What does everyone think?
>
> Yes that sounds good to me. The best way would be to provide a patch in a
> Jira. If it's not used OOTB (Paul's assertion, to be
> confirmed) then I think we don't need to provide a way for data migration
> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
>
>>> Purchase and Sales Agreements
>>>> -----------------------------------------------
>>>>
>>>> - the AgreementItem has the currency for prices. The currency should be
>>>> on
>>>> individual AgreementProductAppls. It should be possible to have agreed
>>>> prices in various currencies for a product
>>>
>>>> - AgreementProductAppl should have its own from and thru dates. A
>>>> particular
>>>> price might have a different timespan than the Agreement or (in the
>>>> case of
>>>> a purchase agreement) the SupplierProduct. You could imagine an
>>>> agreement
>>>> spanning a year with a list of special prices, each of which is
>>>> available
>>>> for one month
>>>
>>> This is a good point, it would be good to have prices in multiple
>>> currencies in the same agreement, I'm modifying the AgreementItemProduct
>>> entity in the Mantle data model to support that and in general be more
>>> like
>>> the ProductPrice entity.
>
> So this is for Mantle work only?
>
>>> On second thought, after looking at the model, I like them (currency,
>>> from/thru dates) on the AgreementItem better since it can apply to
>>> multiple
>>> things and agreements may be better organized if price lists for
>>> different
>>> currencies and date ranges are under different items (and the actual
>>> data is
>>> a lot cleaner).
>>>
>>
>> I think, as a general proposition, a price should have a currency. It's
>> meaningless without. AgreementItem is an organising principle for
>> components
>> of an overall agreement, and it should be up to the user to define
>> agreement
>> items in whatever way makes sense to them. If a company using Ofbiz
>> prices
>> their products in many different currencies, what you've suggested
>> fragments
>> product prices into many different agreement items. The currency that a
>> product happens to be priced in is not necessarily the most important
>> organising principle for agreed prices.
>>
>> Similarly, from and thru dates might be useful on individual
>> AgreementProductAppls. Think about the situation where we have an
>> agreement
>> for a year with a special-of the-month, a special agreed price for a
>> different product each month. Does that on its own justify twelve
>> AgreementItems?
>>
>> I have no problem with an AgreementItem having *default* from date, thru
>> date and currency. When we enter an AgreementProductAppl for the
>> AgreementItem, the defaults obtained from the AgreementItem should be
>> visible, but they should be editable.
>
> This is not an easy choice. It looks logical to have the currency with the
> price value, but on the other hand the currency may apply
> to many AgreementProductAppl. Having them editable sounds good to me, as
> ever words are good code is better => patch in Jira
>
>>
>>>> - There’s no way at present to have a quantity break associated with an
>>>> agreed price for a sales agreement. Quantity breaks are currently
>>>> within the
>>>> SupplierProduct entity, so are available for purchase agreements, but
>>>> not
>>>> sales agreements.
>>>
>>> Actually, that's not quite true. The current AgreementProductAppl model
>>> is
>>> cumbersome, but this last point IS supported (ie agreement-based sales
>>> pricing with quantity breaks) in both the OFBiz data model and the sales
>>> order code.
>>>
>>
>> From what I've found:
>>
>> - At
>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/product/src/org/ofbiz/product/price/PriceServices.java?hb=true#to247,
>> I think the product pricing code just looks for the first
>> AgreementProductAppl with no regard for quantities.
>>
>> - As far as I can tell the QuantityBreak entity is only currently used
>> for
>> shipping calculations, not pricing.
>>
>> - The ProductPriceRule entity can hold a number of ProductPriceCond
>> conditions, including a test for the party and for the quantity, but
>> ProductPriceRules aren't related to Agreements, and they are only used
>> for
>> sales, not purchases.
>>
>> I assume you're talking about the QuantityBreak entity being used for
>> agreement-based sales pricing. Can you point me to where in the code that
>> happens?
>
>
I would still like to know if I've missed somewhere where this happens.
Jacques Le Roux-3 wrote:
>
>
>>
>> In the data model I'm working on this is simplified and much more clear.
>> See
>>> the "AgreementItemProduct" entity here:
>>>
>>>
>>> https://github.com/jonesde/mantle/blob/master/mantle-udm/entity/PartyEntities.xml
>>>
>>>
>>>> SupplierProduct
>>>> -----------------------
>>>>
>>>> - As David says, a five-attribute primary key is unwieldy. It should be
>>>> replaced with a simple ID.
>
> Agree also, but I don't know what it would mean in term of change... I
> begin to better understand David's decision. It's not only
> about framework depencies on application but also about data model
> refactoring...
>
>
>>> Agreed. Here is my current take on the SupplierProduct entity:
>>>
>>>
>>> https://github.com/jonesde/mantle/blob/master/mantle-udm/entity/ProductInventoryEntities.xml
>>>
>>>> - SupplierProduct has a minimumQuantity attribute, so must be read in
>>>> combination with other SupplierProducts. SupplierProduct should *not*
>>>> have
>>>> any information on quantity breaks. There should be just one instance
>>>> of
>>>> SupplierProduct to record that a product can be obtained from a
>>>> supplier. A
>>>> SupplierProduct should have associated QuantityBreaks and
>>>> ProductPrices, as
>>>> described in the Data Model Resource Book.
>>>> - lastPrice in SupplierProduct is used both for the last price we
>>>> obtained
>>>> the product, and an agreed price. These are two separate things. Given
>>>> the
>>>> lastPrice might have been determined by an agreement that has expired,
>>>> and
>>>> by a quantity that we are not ordering this time, it's not very useful.
>>>> It
>>>> ought to be possible to determine the most recent prices we paid at
>>>> various
>>>> quantity breaks for a given product from a given supplier
>>>
>>> Actually in OFBiz the "lastPrice" is meant to be just that, the last
>>> known
>>> price from the supplier. It isn't meant to represent any sort of
>>> purchase
>>> agreement. The Agreement* entities should be used for that (though I
>>> don't
>>> know off the top of my head if that is current supported in the OFBiz
>>> purchase order code).
>>>
>>
>> Agreement entities are not currently supported for purchase pricing. See
>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/product/src/org/ofbiz/product/price/PriceServices.java?hb=true#to1323.
>> What's provided in the data model and what Ofbiz code currently does
>> are
>> not always the same thing. lastPrice is used for purchase prices, and it
>> takes no account of quantities.
>>
>> Re your SupplierProduct in Mantle: it has a price and minimumQuantity
>> attributes. Doesn't that mean that if a supplier offers different prices
>> for
>> different quantities, there must be two or more SupplierProducts?
>> Wouldn't
>> it be better to have two different entities, one to record that a product
>> can be obtained from a supplier, and a separate one for prices at various
>> quantities? There would be a one-to-many between the former and the
>> latter.
>
>
Any opinions on this proposition:
For any given product obtainable from a given supplier, there should be one
and only one occurrence of SupplierProduct. Quantity breaks belong somewhere
else.
What do people think?
Jacques Le Roux-3 wrote:
>
>
>>
>>> TaxAuthorityRateProduct
>>
>>>> -------------------------------------
>>>>
>>>> - This entity is used to determine tax on shipping and promotional
>>>> pricing
>>>> adjustments, when these are not products. There should be a separate
>>>> entity
>>>> for tax on all order adjustments, which will determine tax based on the
>>>> adjustment type rather than on the product category
>
> On this subject, at r1070830 I have committed Paul's patch with a simple
> information on screen to handle the shipping/promotion case
> (only one line). Keeping the curent data model, ideally a js script would
> enforce this case.
>
>>> Yes, agreed. In the Mantle UDM I changed the name to
>>> "TaxAuthorityRateSales":
>>>
>>>
>>> https://github.com/jonesde/mantle/blob/master/mantle-udm/entity/AccountingOtherEntities.xml
>>>
>>>> - The ProductStore is used to determine the tax payable. That’s fine
>>>> for
>>>> sales, but makes no sense for purchases. Really, the ProductStore is a
>>>> proxy
>>>> for the geo of the seller. TaxAuthorityRateProduct should be revised to
>>>> list
>>>> the geo of the seller rather than the ProductStore, then the same rules
>>>> could be used by purchases as well as sales. For a sale, the
>>>> ProductStore
>>>> geo would be used as the geo of the seller.
>>>
>>> I'm not sure what you mean about the geo of the seller thingy. The geo
>>> used
>>> on TaxAuthorityRateProduct is the taxAuthorityGeoId where the customer
>>> is
>>> shipping to (or billing to) a geo where there is a PartyTaxAuthInfo (or
>>> Mantle TaxAuthorityParty) record where the seller organization has
>>> isNexus=Y.
>>>
>>
>> I'm talking about the "buyer" and the "seller" because, for VAT/GST
>> taxes,
>> we need to support tax on purchases as well as sales. For a purchase,
>> we're
>> the buyer and the supplier is the seller. For a sale, the customer is the
>> buyer, we're the seller.
>>
>> TARP *should* be used for both purchases and sales, because what it's
>> really
>> capturing are tax rules we care about, and they don't change just because
>> we're buying something instead of selling it. Governments define taxes in
>> terms of the geographical location of the buyer and the seller, and of
>> course a government doesn't know or care about our product stores.
>>
>> TARP can manage rules based on the geographical location of the buyer,
>> but
>> only has the product store for the seller. That's OK for sales, but
>> breaks
>> down for purchases. I think TARP should have attributes for the
>> geographical
>> location of both the buyer and the seller. In effect, I think the product
>> store is a proxy for the geographical location of the seller. I'm happy
>> to
>> leave the product store in TARP if people think it's useful.
>>
>> While we're talking about TARP, I am unsure whether it should also have
>> flags to say if the tax should be applied to purchases, sales or both, or
>> if
>> the tax type should drive that, so a tax type of SALES_TAX will be taken
>> to
>> apply only to sales, and a tax type of VAT_TAX will apply to both
>> purchases
>> and sales.
>
> I see VAT taxes as a cascade down to Governments. So you don't have to
> care about the seller, he has to care about you. I don't see
> the point of handling VAT for purchase, since you will not generate the
> invoice for the purchase, the seller will. What is is needed
> for, to have an idea about the costs? Then maybe we should think about
> creating a Cost Center as we have a Profit Center with the
> ProductStore...
>
> Jacques
>
>
Yes, when we create a purchase order, we are only *estimating* the tax. The
key document that defines the tax we will pay is the supplier's invoice.
When we receive the invoice, we may need to revise the tax we're paying.
But, if we have accurate pricing information from the supplier, the tax
*can* be estimated and is useful information.
If I choose to send payment with the order rather than waiting for an
invoice, an estimate of the tax is useful so I can make one inclusive
payment.
In Australia at least, you can choose to account for the GST on an accrual
basis. Large companies must use accrual. That means that tax is calculated
based on purchase orders and invoices, rather than on payments. In short,
the tax is levied earlier based on payment obligations, rather than later on
the actual payments. If I create a purchase order on the last day of the
quarter, I darned well want the tax I will pay to reduce my GST for this
quarter. An estimate is far better than nothing. I can always put in an
adjustment later on when the invoice arrives from the supplier.
I don't quite understand your mention of Cost Centers. Do you mean there
should be General Ledger accounts for the VAT/GST we have paid on purchases?
If that's what you mean, I agree.
Jacques Le Roux-3 wrote:
>
>
>> As for the productStoreId field, it should only be used as an extra
>>> constraint on the "rule" record, and should be fine if null (from the
>>> model
>>> perspective, the code may not currently behave that way).
>>>
>>
>>> David E Jones-4 wrote:
>>>>
>>>> I'm writing this to start a thread to discuss:
>>>>
>>>> If you could change ANYTHING in the OFBiz data model, what would it be?
>>>>
>>>> To kick this off here are some ideas I've compiled that have come up
>>>> over
>>>> the years (many based on feedback from people on this mailing list), or
>>>> that I thought of recently will working on this topic. You can see them
>>>> below...
>>>>
>>>> -David
>>>>
>>>> ========================================================
>>>>
>>>> - Rename *Role entities to *Party
>>>> - Remove *Attribute and *TypeAttr entities (not generally a good
>>>> practice
>>>> to use)
>>>> - Remove all status history (*Status) and just using audit on the
>> statusId
>>>> field
>>>> - ProductPrice add quantity breaks, change PK to single field sequenced
>>>> - Get rid of QuantityBreak and use the two simple fields instead in
>>>> each
>>>> place used
>>>> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie
>>>> directly
>>>> associate to the store
>>>> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to
>>>> single field sequenced
>>>> - Change Quote to be other types of Order
>>>> - Make Return more like Invoice (ie no adjustment, just use items for
>>>> everything)
>>>> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType,
>>>> ReturnItemType just use Shared ItemType everywhere
>>>> - PartyRelationship simplify (single sequenced ID)
>>>>
>>>> - Make prefixes consistent (no suffixes), ie toPartyId instead of
>>>> partyIdTo, etc
>>>> - Change all relationships to PartyRole to be type one-nofk; use plain
>> one
>>>> for Party and RoleType
>>>> - Move most *Type entities to Enumeration values (update seed data,
>>>> referring
>>>> entities, remove *Type) (after this remove all remaining hasTable
>>>> fields)
>>>> - Rework PhysicalInventory and InventoryVariance to simplify, reduce
>>>> dependency on InventoryItem
>>>> - Review use of Appl, Assoc (look at book, make sure consistent)
>>>> - Add PartyIdentification entity, get rid of various fields and other
>>>> entities (maybe even PartyTaxAuthority...)
>>>> - Change GoodIdentification to ProductIdentification
>>>> - Combine PartyContactMechPurpose and PartyContactMech (remove, only
>>>> use
>>>> entity with purpose, name PartyContactMech)
>>>> - Get rid of NoteData, put noteText very-long field directly on various
>>>> *Note entities
>>>> - Review all entities with large PKs (esp 4+ fields)
>>>> - Review and do something with all createOn/By lastUpdateOn/By fields,
>>>> maybe add an auditing flag for the entity instead of just for a field
>>>> - CustRequest to Request
>>>> - FinAccount to FinancialAccount
>>>> - Invoice handle recurrence? (was using RecurrenceInfo)
>>>> - Get rid of optional ProductFeature concept (conf/etc products much
>>>> better model)
>>>> - Instead of various *Term entities and mapping, just use OrderTerm
>>>> everywhere
>>>> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc
>>>> - Agreement - make price list easier/cleaner
>>>> - Remove all createdDate, createdByUserLogin, lastModifiedDate,
>>>> lastModifiedByUserLogin fields (use framework defaults, audit-log)
>>>> - Product clean up: move dimenstions to new entity, remove content
>> fields,
>>>> etc
>>>> - Trim down big entities like Product, WorkEffort, etc; for groups of
>>>> similar fields use a more normalized structure
>>>>
>>>
>>>
>>> --
>>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Discussion-Potential-Data-Model-Improvements-tp3390620p3422000.html
>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Discussion-Potential-Data-Model-Improvements-tp3390620p3511051.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.