Comments
Adding another note here to raise this back up in the history. Without this capability, an organization that wants to shift from general parts handling to traceable parts handling has to essentially duplicate all of their released products, and change all Bills Of Material that utilize the products. This is an undue burden for products that are otherwise form-fit-and-function the same except for the addition (or removal) of traceability.
I will try to explain a working example of this requirement. Many years ago we were selling widgets and at the volume we were selling we stocked them as Eaches. After many years the popularity of the product increased and the volume of goods going in and out of the warehouse has increased. So now the vendor sells it to us in Boxes (1 Box = 10 Each). But we still have to count the goods on the shelf one at a time. It would be preferred to crate an entry somewhere that indicates a choice was made that as-of a point in time, the inventory unit changed. If inventory has to be removed from the system to make the change then OK. The confusion of "what does an Each represent?" as one widget or a box of widgets results in handling the wrong quantity.This would improve the ability of an organization to adjust to the changing needs of a product without having to create a duplicate released product. This would also allow fixing a mistake where the product was created with the wrong unit. I understand why this capability was removed when D365 was released, but we should revisit the impact this decision is having on organizations and the physical handling of goods in the warehouses.
Examples were not submitted correctly:tableextension 50000 "Customer ISV" extends Customer{ fields { field(50000; "Rating ISV"; Code[20]) { Caption = 'Customer Group'; DataClassification = SystemMetadata; } } keys { key(MonolithAppKey1 "Rating ISV") {} }}Before MoveApp Monolith: TableExtension Customer -> Field "Rating ISV" (+ declared as additional key)New App :After MoveApp Monolith: New App : TableExtension Customer -> Field "Rating ISV" (+ declared as additional key)
Yes, we do have a customer with 2 legal entities. All sales order goes via a sales company. Logistics is the second company. The small items are directly send to end-customer, but bigger items are send to a warehouse of the sales company for consolidation purposes (also items can be ordered at a vendor) for a one-time delivery. This is really required behaviour for the customer... without intercompany-relation this is possible, but then we miss the intercompany benefits...