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.
