Projects:UoM-Management/Functional Specification
Contents |
My Project - Functional Specifications
This is a draft document, a preliminary set of thoughts to outline the functionality and facilitate the discussion.
Overview
In the discrete manufacturing industries, finished goods are assembled according a bill-of-material and mainly full-units of components. In the process manufacturing industry type, finished goods are created as result of a formula that consumes ingredients in any posible quantity and unit of measure. Most manufacturing companies will have both type of 'product-conversions', but also pure distributors might see conversions for products that are purchased in bulk and sold to the final customer in smaller units.
Inventory is viewed in different ways depending the process, role or person that is viewing. To facilitate the understanding of the information, alternative units of measures are used depending on the context and/or role.
Purpose
The purpose of this project is to enable the ability to manage transactions in an unlimited but defined number of alternative unit of measures, within and between organizations in the same client. These transactions must maintain integrity and transparancy of inventory and, subsequently, the inventory-related value.
Scope
The scope of the project is to implement Unit of Measure management in all transactions of the Openbravo software that relate to inventory. Just like an amount is always acompanied by a currency, a quantity should always be acompanied by a unit of measure.
It should be possible to:
- Define Metric or Imperial units on the level of organization. The choice for metric or imperial would enable a different subset of units (KG vs LB or m vs ft).
- Define Base- and Alternate UOM on the level of product. The Alternative Unit of Measures (AUM) represents the quantity, relative to the quantity in “base UoM” (BUM) in which the product is defined. The BUM should preferable be an fundamental UM (a universal, definite and predetermined unit of a physical quantity like meter, kilogram), whereas AUM can be either a handling unit (organization- and/or product-specific expression of a physical quantity) or a fundamental unit. See Unified Codes writing on base units.
- Define universal- and product-specific UOM-Conversions. A universal conversion is product-independent like LB->KG=2.2046nnn, whereas a BX (box) of product-A holds 30 EA(each) while for product-B a BX contains 50 EA.
All unit-abbreviations, metric and imperial according to the ISO coding system, should be delivered with the Openbravo instance as system values and on client-level. However, it should be possible to create new unit-codes.
In the definition of master data:
- Ability to Create/Modify/Delete universal UMC.
- Ability to Create/Modify/Delete item-specific UMC, both in a new function on the UMC dataset as in the UMC tab of the product definition.
- Ability to set in an additional TAB for UMC in the product definition, the following:
- Default purchase UM per item + per supplier / item.
- Default Sales UM per item + per customer / item.
- Include the dimension “UM” in the pricelists.
- Default Logistic UM per item.
- Default Replenishment UM per item + per location / item.
- Default KanBan UM per item + per location / item.
In the business processes:
- On creation of a Purchase Order: prompt the proper UM for this item / supplier and store the conversion that is valid at creation.
- On creation of a Sales Order: prompt the proper UM for this item / customer and store the conversion that is valid at creation.
- On receipt of a Purchase Order: prompt the proper (Logistic) UM for this item.
- On the Picklist: express the quantity to pick in handling units (logistic/replen/Kanban UM) like: "2PL + 1BX + 2PK"
- On the Shipping document: Express the quantity in Sales UM for this customer / item.
Note that the inventory and all inventory transactions are always registered in the database in the BUM. The above mentioned business processes just visualize the inventory in the selected AUM. Also, all transactions will go through the central broker that translates and executes the transactions and deals with rounding issues.
References
- Base Unit of Measure (BUM): The Unit of measure in which the product is defined. Internally all transactions will be executed and stored in this unit of measure. The product costs are expressed in BUM unless otherwise indicated.
- Alternative Unit of Measure (AUM): The unit of measure that is used to present the quantity to the viewer, depending on which business flow this viewer is using.
- Unit of measures can relate to fundamental units like KG, M, EA or TH or can relate to handling units like PL, BX DR(um). Handling units are interpretable and may confuse, especially with external parties. It is advised to define the BUM of products in fundamental units.
- Unit of Measure Conversion (UMC): The quantity of BUM in the related AUM. Note that this quantity most often is bigger than 1 but can also be less than one. If the BUM of chocolate is KG, then a UMC to EA (a chocolate bar) can be 0,100.
UMC can be universal like KG -> T = 1000 (There are 1000 KG in each Tonne). These conversions do not require (or better said should not have) an item-number specified. Most of them are pre-supplied with the Openbravo instance. Most UMC are item specific like Teddy Bear XXL: EA -> PL = 30 (Each pallet of this product contains 30 Teddy Bear XXL).
Example of the UoM conversion table:
| Product | BaseUM (ReadOnly) | AlternateUM | GTIN | Conversion | Comment |
|---|---|---|---|---|---|
| * | KG | T | 1000,00000000 | A universal conversion (valid for any product): There are 1000 KG in each Tonne | |
| * | T | KG | 0,00100000 | Idem, reversed. All these come with the OB instance. | |
| * | m | cm | 0,01000000 | There are 0,01 m in each cm. Note the 8 decimals of the conversion. | |
| TMBR20*80*4 | KG | EA | AABBBBBCCCCCD | 2,50000000 | There are 2,5 KG in each 'ea' of Timber 20*80*4. The EAN13 represents the first handling unit. |
| TMBR20*80*4 | KG | PK | XAABBBBBCCCCCD | 10,00000000 | And a PACK weighs 10 KG; The EAN14 represents a secundary handling unit |
| TMBR20*80*4 | KG | PL | YAABBBBBCCCCCD | 500,00000000 | When we scan the GTIN (in this case a EAN14) of this product (YAABBBBBCCCCCD) we are transacting 500 KG |
Design Considerations
Regardless the UM in which the inventory is presented, the inventory transactions should always be calculated in the BUM in order to preserve integrity and transparancy of the representation of inventory and it's value.
Assumptions
All functions should call a central broker, supplying the item, Qty, From-UM, To-UM and business process. Depending on the business process the broker transacts or returns the calculated value in the requested To-UM.
The central broker executes/calculates with the defined number of decimals. The central broker handles the potential rounding issues as described above.
Dependencies
Constraints
No UMC defined: If no UMC is defined, the central broker returns an error message.
Rounding issues: As defined in the UM setup, each UM is rounded with a specific, predefined number of decimals, depending on the preferences in the organization. The universal rounding rule is applied (Round To Even). An algorithm should be developed to deal with rounding remainders or deficits, e.g.: If the BUM is KG (3 decimals) but it is sold in PK, There are 3 PK in each KG. Two PK are sold so 0,334 remains in inventory (1,000 – 2*(0,333) = 0,334). When the last PK sells it technically leaves 0,001 in stock. The central broker should handle this.
Glossary
Functional Requirements
User roles & profiles
It could be considered to define the presentation UoM for each role. The employee with the Warehouse role would see / manage inventory in the Logistical or Storage UoM, whereas the purchaser would see the inventory represented in the purchase UoM of the item, regardless which that UoM is. This representation should be not more than a default, allowing the user to select different UoM.
Business process definition
For different flows within the same product, often different units of measure are required. A product can very well be purchased in another UM than in which it is sold. And even inside purchasing, for the same product and from the same supplier, buying in 'pallets' could bring a price advantage compared to buying in 'thousands'. Additionally, handling inside the warehouse can be in 'outer pack' and replenishment to the shopfloor could be in 'inner pack' while it is sold in 'each'. In other words: inventory is viewed and handled in different ways; The Alternative UoM gives the proper flexibility for this.
User stories
Functional requirements based on business processes
Miscellaneous
Pricing per UoM
It should be considered, perhaps in a secong phase, to allow pricing per UoM.
The projects as presented above, handles the conversion with the objective to visualize different units per process, while maintaining inventory integrity. However, it is fact that f.i. a six-pack of beers does not cost the equivalent of six inividual cans. Hence, the desire for a pricelist that not only indicates the product but also the UoM in which it is sold.