Plugin: Couple Product

From iDempiere en
Jump to navigation Jump to search

Container-Content Concept



  • This is a module that handles inventory as a serialised item with varying UOM (unit of measure) qty been transacted upon.
  • It is first thought out for a barrel or drum of cable lengths to sell as described further below. Or imagine a big barrel of juice in a bar, where drinks are sold from it, and the supplier pours large consignment into it to top up. Or a metered gas line to a house. Or electricity meter. Or prepaid phone cards. I can go on and on.
  • The use case needs a coupled twin product comprising 'both' container and content.
  • 'Both' bears the same ASI (attribute set instance) but its content qty value stands for 'another' active product subjected to a normal purchase or sales cycle.
  • The product variable qty gets added on or deducted from when it is transacted with other similar products.
  • It exists even if its qty is zero, where only one twin is exhausted but the ASI serial remains as a 'container'.
  • This construct seems to fit the definition of a plain ASI item and thus allows high reuse of the present core iDempiere material management as the screenshot above shows (done with no system changes).
  • The name 'couple product' is a temporal one as the model thought process is still in progress.

The Drum Cable Business Case

  • Drums or barrels where cables are wound onto them are purchased and sold.
  • The lengths of cables are cut out and sold in shorter lengths.
  • The drums need to tracked as they are costed on rental basis.
  • The cables can be moved from drum to drum for easier handling.
  • The remaining cable length has to be tracked and calculated to give the available lengths during sales or transfers to another drum.

The Normalised Data Model Concept

  • An ERP must remain normal and not modified to ensure stability, familiarity and low cost of software maintenance.
  • Any changes or extensions to it has to be in a separate plugin.
  • The extra data model has to be normalised, object oriented for easy user understanding and copy any present ERP data for processing.
  • The data model then interacts with the core ERP model via an external plugin.
  • High reusability of core ERP features is thus ensured.

Important Reused ERP artifacts

  • The following are important features of the ERP that are usable in this module without modifications.
  • ASI - Attribute Set Instance, where serial numbers or code can be associated with the container aspect of the couple product. ASI already has granted high traceability in the ERP.
    • Its Guarantee Date stands as the Return Date. Payment terms model can be used together with Aging Analysis to manage the costs of rental.
  • Product Info main panel can display a high level aggregated view.
  • StorageOnHand is referred to in the Product Info detail panel - where Availability on Demand lists all Reservation or Ordered Qty for both Container (ASI) and content (Qty).
  • Product definition, pricing, purchasing and sales cycles giving full supply chain management.
  • Inventory Move within same Locator, same ASI
    • M_Transaction (see image proof)
    • Source ASI ID : Target ASI ID : Qty Moved

Singular Product Concept

  • It is established that the Product's ASI is the container and that the Product's StorageOnHand Qty is its content measure. Thus the related models are all sharing the single product in ERP.
    • For example a Drum XX1 with 100 meters of cable can be defined as a single product of 100 qty and UOM meter.
    • As orders are made against it, it reduces its qty i.e. Drum XX1, qty 50
    • The label Drum XX1 is actually the ASI serial code and thus there is no loss of data been single.
    • The only gap for the plugin to handle is that even if the qty is zero it is still existing and has to be returned or some payment terms of rental is due.
  • The plugin's strategic role is to wrap the couple product concept to handle its further character of a Container with Content.
  • This strategy is still under study with the business user to see if it survives on paper simulation of the prototype.

Gaps that need to be in core

  • ASI auto generation of items for Material Receipts which is only present in Shipments out of stock.
  • Patric of AulerSipel has also raised issues to such an approach. (See Issues next)


  • "The accounting consequences will be ferocious. There be too many redundant postings and accountants from all over Germany will kill us" - Patric, in the WhatsApp project discussion group.
    • "I would like to have a word with one of the German accountants to know which accounts can be reduced." - Red1 (talk) 14:02, 26 October 2015 (CET)
  • This is due to too many item qty product lines in the documents and particularly noted during 3 way matching.
  • "My initial idea will be to try using Plugin:_Alternative_Output to also hide accounting logic from the accountants" - Red1 (talk)

The Plugin

  • Data model to relate to the composed coupled product, its terms of use and life cycle status.
  • Translation to represent model data in industry terminology.
  • More realistic presentation of the product.
  • Ensure its existence even if Container (ASI) QTY is zero.

Data Model

  • Couple-Product
    • MAttributeSetInstance (ASI) = Container
    • MStorageOnHand (SOH)= Content
  • Container InfoWindow
    • ASI JOIN M_Product JOIN SOH JOIN PaymentTerms
    • Rented? : UOM : Max Qty : Status : C_BPartner (user) : (BP) Location
  • Content
    • SOH
    • ASI_ID : QtyOnHand :

MOdelVaidator DocEvent

On Material Receipt

  1. Set initial Qty
  2. Translate to serial Qtys based on balance from PO

on Sales Order

  1. To assign the OrderLines to a particular ASI that is
  2. Oldest with sufficient length
  3. to generate Movement for ASI Qty to go to another empty ASI if first ASI is more than orderline Qty
  4. Issue a Request Ticket on Calendar attaching Order
  5. OrderLine has new ASI (with note - pending movement, thus In Progress)
  6. Complete when new ASI is moved, ready to generate Shipment of new ASI

on Receipt

  1. To assign suitable empty lot to right type of drum category


  • Q:What is the rationale behind all this definition of a new type of product?
  • A:It is meant to revolutionize the way we use the present ERP to avoid more coding, change to the present core, and exercise the power of a plugin in 'polymorphing' for a 'meta-product'.
  • Q:What is the difference with other type of products such as BOM or Supplementary?
    • A:The attempt (still rudiment idea) here is to handle something that is a container of the actual product in sale. It is quite similar to the supplement product idea in use by the bottle drinks industry, but in this case it is more akin to a large barrel of juice where the client sells glasses of drinks from it continously.
  • Q:Why not use the other types?
    • A:The idea here is to avoid too much definition of product within the ERP to avoid difficult handling. For example during product costing and evaluation. The couple product is more singular than a combination as the material in question is for example a long cable or an amount of juice and not a BOM of other ingredients. Using a BOM may be overkill and need extra work to define.
  • Q:How then does this couple product behave?
    • A:Easy. It is first defined as a normal product with an UOM and Qty. It is its ASI that has the value of a 'container'.
      • Checking with M_Storage and MStorageReservation tables within the database show their records persist even though their qty is finally zero. The M_AttributeSetInstance record still persists with its guarantee date intact which can be used for return dates of the container.
      • The external plugin model can then still handle them as 'empty containers'.
  • Q:Can I receive a new cable and assign to an old drum?
    • A:Yes, you can do that during Material Receipt, assigning to existing ASI as long as there is still some residual length or QTY left even though it is last precision value i.e. 0.01 kilometer (10 meters) left.
  • Q:What if i want to assign to an empty drum during Material Receipt?
    • A:Yes, just use the plugin to inject a residual length to it and it will be visible during Receipt. Or you won't need to do that and leave it to the plugin.
  • Q:How do i transfer the content from one container to another?
  • A:As the last screenshot above shows, it is easily done with a simple Inventory Move but with same Locator and ASI, the QTY gets transferred and the M_StorageOnHand reflects all.
  • Q:How are orders' length requests handled?
    • A:Quite simply by putting them as individual orderlines. Each line qty intuitively signifies the requirement. The system thus need to look no further. Otherwise creating extra core field will incur further overhead and maintenance.
    • For example lets say a customer requires 3 lengths of 100 meters and 2 lengths of 200 meters. Thus the orderlines will be:
      • Line 1 - 100
      • Line 2 - 100
      • Line 3 - 100
      • Line 4 - 200
      • Line 5 - 200
  • Q:Wouldn't that be cumbersome? Why not just one line '100 meters X 3' and next line '200 meters X 2'?
    • A:Well, indeed that can be an option. We can have a ModelValidator that takes such lines and convert them into those 5 lines and a PrintFormat that reads those lines and consolidate them back.
  • Q:What if for some reason the plugin fails or the new data model gets corrupted?
    • A:That is the beauty of it. When any of them or both fails, you fall back to the natural product definition shown in the screenshot above, which is fully intact, functional and non business stopper.

If you want to provide additional comments, please use the Discussion page or please also visit our contribution list at AulerSipel..