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
>>
>>
>
