View source | View content page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Show collection (0 pages)
Collections help

Search

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:

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:

In the business processes:

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

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.


Variable UoM and Referenced Inventory

See Referenced Inventory

Closed Discussion Items

Retrieved from "http://wiki.openbravo.com/wiki/Projects:UoM-Management/Functional_Specification"

This page has been accessed 1,080 times. This page was last modified on 20 May 2015, at 14:37. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.