Towards A New Libero

[red1]

After learning and discovering new design concepts during the making of the new , I now set my mind to rewrite Libero Manufacturing (Mfg) likewise from scratch. One thing that needs to decouple right away from it is the Shipping Distribution Order (WMS has been successfully decoupled in the new version). (Shipping Distribution also sits embedded inside Mfg as was the case before in old WMS.) I also like to rewrite the complex Issue/Receipt module and leave CostCollection out for last.

So with that let's just begin. I like to define first a Forecast / Sales demand of a production product. But take one thing at a time. Remember in Libero it is coupled with the shopfloor dimension of scheduling resources, and workflow. I want to go with the minimalist and 'separation of concern' and 'lazy loading of function' approach that i find useful in WMS.

At this juncture i see Mfg as twin-part. First is the simple 'Adaxa' like production of using a BOM plan and seeing it through the WMS supply chain with a KanbanBoard visibility of action. Those actions can be time-tracked to later estimate its theory of constraints. Second (next phase), a simpler interface with the intricate shopfloor.

The forecast production will incorporate the BOM Drop but with a twist. It will allow lazy cost loading
and low-level progressive bom drops. This is a step further from Adaxa single bom production.
a) Lazy cost loading, is when a product is not determined some late raw materials such as a car not knowing what accessories to fix or a cloth not knowing what design to emboss. The key intent here is to get total direct materials and their roll-up costs.
b) Low-levelling is to properly (as Libero attempted) to get MRP (Materials Requirements Planning) and CRP (Capacity Requirements Planning) across the Shopfloor. This is where schedule estimates are derived. And also indirect production costs.

This will mean a change in the BOM Drop. It may have to work with BOM instances. The instance can be in an extended ProductionLine detail, with BaseQty, QtyVariance, and FinalQty to keep track.

Since the lines can grow a long tail with the raw material ingredients break down, another sibling tab will revert back to the parent singularity at the ForecastLine/OrderLine tab. Thus the ProductionLine remains aribitrary and fulfills at the materials building level.

Now let me introduce another wonderful concept that seems simple but an elegant break-thru in loose-coupling lazy-loading land. I call it the Panel approach. It is to put a custom master model over the core models but not needing to go via the core models. For example a PM_JobProduction with PM_JobProductionLine is created as new models and it forms a loose relationship with core models such as M_Forecast/C_Order and PP_Bom. It does not necessarily need the core models to operate first, saving input time, and hassle of sub tabing too much. The extra work will be in the process or event validator code to rope in those core references.

Such a construct gives few distinct qualities:
1. There is better separation because PM_JobProduction demonstrates better leadership, not been under another core model such as M_Forecast/C_Order to mysteriously trigger stuff. It is also not generated from such core data but in itself is the starting source of data and can immediately summon a M_Forecast instance.
2. It has its own descendant PP_JobProductionLine and its sibling M_ForecastLine/C_OrderLine after associating with a runtime core model.
3. The governing master model can be Kanban Board ready signifying DocStatus conditions that signify its time scheduling in a pseudo manner.
4. The panel model can be modified readily by users for more relevance without worrying about disturbing underlying core models.
5. The custom panel is thus the input point, more usable, easily tuned, and marshall everything else thru its encapsulating plugin.
6. Thus there is even more freedom to maneuver easily around rather than touching any core.

Item (3) is crucial and forms my latest enlightenment just some hours ago. DocStatus of a workflow structured document doesn't need further fresh design as it already is. It nicely sits in a Kanban Board and can be dragged from stage to stage using those arbitrary status conditions.

From there is where we juxtaposed another future model that will then fully govern the shopfloor scheduling. It loops back to the DocStatus without disturbing such arbitration.

Though this lightblub blows my mind, it is not easy to explain to another mind. So i will go ahead and use the Ninja to set it up and hopefully, at least for me too, prove that this concept works and can solve the Libero mess.

[red1]

Here is the tentative data-set model design, ready in Excel format for my Ninja to generate straight into iDempiere. (Drag the images to the left to view more of the obscured right.)

ProductionModelMaker.png (98.13 KiB) Viewed 11279 times

ProductionCodeMaker.png (71.92 KiB) Viewed 11279 times

Without adding a line of hard code, the Help Description injects directly into the meta-data processes.

BOMDropProcess.png (83.79 KiB) Viewed 11279 times

CompleteProcess.png (41.15 KiB) Viewed 11279 times

[red1]

Now I will comment on the next two matters in the process: 1. The BOM Production Plan rolling up costs and display, and its final FinishGood congruence; 2. Integration with WMS and the JIT tracking.

1. Production Plan as it is will do costs roll up depending on its child lines. In this new Mfg, the childlines are not fixed and the user has full freedom to either adhere to the BOM Drop (with variant) and further variances in the ProductionPlanLines (which is hidden away but its exposure in sufficient in the governing PM_JobProductionLine). Forecast/Order association will always show rolled up parent line. This is because end-user final output is messy if repeated what was the raw material lines and over hundreds of production plans, is not sane. Here the user can quickly switch back to the underlying PM_JobProductionLine tab to see the final variances and in complete detail. Such detail include the original BOMQty as comparision and historical analysis. This PM_JobProductionLine in another way, is an instance of the BOM template.

In the final FinishGoods status, it is considered thus (likely) a 'customised' produce with costs price differing from BOM design to BOM design. This will be congruent as reflected in the ProductionPlan accounts posting - consuming raw material amounts to produce a final product amt.
TBC..

[red1]

The WMS interfacing occurs here:
1. When raw materials are identified, they are picked via the WMS and sent to 'Production' Warehouse locators. Such locators are marked in virtual manner and can even act for external sub contractors.
1.b Such locators are 'blocked' as they go into the assembly line, not letting its contents be accidentally picked by others.
2. Within the 'Production' type locators is where they await been finally consumed with a single ProductionPlan process.

Thus the pseudo status phases of the parent PM_JobProduction/Line comes in. Firstly at each line level there is awareness if it is Complete Line (green) or not (red). At the parent level if its all red, then its Kanban Board card is red. If a mix, then its orange. If its all green, then its green. And the status from 'In-Progress' can now move to 'AwaitingConfirmation'.

The DocStatus changes can denote the respective stages in a Production assembly line. For example, for Patio Furniture set, there can be 'cutting, gluing, polishing, packing'. We can change the DocStatus labels to these arbitrarily without needing to code anything into the MPM_JobProduction model class.

The actual shopfloor (later phase of Mfg) will then interface with these status changes. Shopfloor itself will carry the sophistication of Workflow Activity with its Capacity per line, per machine (resource) handling, taking from the alloted raw materials set and as each stage is satisfied, update the PM_JobProduction DocStatus, to 'move' each status along the Kanban Board.

Thus the Shopfloor is entirely a model and panel of its own not disimilar to what WMS is sitting in between Orders and WM_InOuts.

InfoWindows can easily join these silo of models together on the same page and export their data for Excel intelligent analysis.

This in essence attempts to describe at a macro level with certain grasp of domain based on own experience thus far. The good news is that I am drawing all this up with an actual user case here in Thailand to bounce of for reality model checking.

[red1]

Here i want to describe the idea of the incremental BOM Drop. In a multi level bom, lets say in the case of Patio Furniture, it is first used in the non shopfloor scenario to ascertain total BOM material costs. Its BOM level can be used when the user is a contractor for a certain level only and others are iterated or sub-contracted.

Now to describe the relationship with the Shopfloor model that shall keep tack of all JobProductions and not the other way round to avoid entanglement. An info-Window view can extrapolate which Job stands to complete first according to separate formula sets and give separate Estimated Delivery Dates (when the fuller Shopfloor functionality is not in play).

The Shopfloor data models will think of 24X7 operations. The JobProduction model is more of an accounting and Kanban helps to give that pseudo shopfloor view in a lighter mode (taking the cue from Adaxa Lite).

JobProductions can have priority and their assignments can be managed simply at the KanbanBoard level between two status of 'InQueue' and 'InProduction'.

Thus the idea is to be considerate to lesser users, that just need a 'Libero Lite' (JobProduction with Kanban Board) that can remain so as the middle ground between Adaxa Lite and Libero Heavy. The 'Shopfloor' will then be a ready option to add-on to JobProduction. Shopfloor is not the scope in this present phase but given preliminary design treatment so as not to be left out or wrongfully designed later.

At the philosophical level, is to design each component model as standard Ninja OSGi freely as possible with minimal entanglement so they can managed more better particularly at a later BI enablement stage.

At this preliminary round, there will be more online domain studies and experimentation using the Ninja wizard before finally arriving at an industry applicable suite. Expect more furious changes and lots of throaways prototypes.

[red1]

Committed early release, the first module called Job Production, handling the first part - http://bitbucket.org/red1/org.pm.production. (Drag around to see the whole screen.)

JobProduction.png (204.22 KiB) Viewed 11208 times

At the pull down process list, the PM_Sales_Delivery is done to create Sales Order, Delivery Schedule and Picking List in one go for the listed products.

[red1]

I have done a Sales Order Info-Window that shows the past performance by Year and Period to Generate Forecast records that will eventually be taken by the MRP Info Window.

After checking out the plugin http://bitbucket.org/red1/org.pm.production and starting in Eclipse, the Views panel has the Sales Performance Info-Window. Or take it as binary at https://sourceforge.net/projects/red1/f ... facturing/[ProjectProduction-OUT_1.0.0.jar]

Open it at iDempiere Info Views Panel to select for new forecast records either by Year or Period. I already activated the Forecast window to view the results. Also the MRP Info later shall get to them.

GenerateForecastInfo.png (62.05 KiB) Viewed 11086 times

Pressing the Generate Forecast allows a parameter to set to generate at percentage to the previous Qtys. If exact replica is needed, then the Percentage is left alone and it will defaulted to be 100%

[red1]

From here, we shift to a different way to generate MRP records. (MRP is a 'Plan' and PP_Order or Manufacturing Order is an actual production record.)

In old Libero, MRP are automatically generated (in Make To Order during Sales Order, ProductPlanning Data in Forecasts, Requisitions etc). This is quite invisible and there is no easy pre-steps to really simulate plans ahead in terms of resources, constraints and timelime. Indeed the old MRP-Info does show these, but it is organisational and the SQL View (RV_PP_MRP) is hardcoded to include Safety Stock and Forecasts.

(I am also considering if ProductPlanning Safety Stock is redundant and the reference to Product's Minimum Reorder Quantity with 'Keep Minimum' Replenishment Rule can be a good default for that.)

So for solving the above, I am creating a fresh Process that has the criteria of choosing to include or otherwise: Forecasts, Purchases, Requisitions, Safety Stock, etc and generate MRPs as simulations (Parameter savings already inherent in iDempiere Process opening dialog box is perfect for the simulation to be stored). Old MRPs that are not committed will then be deleted or over-written.

The generated MRPs will then be viewable in the MRP-Info View.

[Post-script - I am thinking of making a new Info-Window to view resources and records and process those selected directly in the above proposed Generate MRP Plan. This is to give visibility.]

[red1]

In the Job Production window which does Forecast generation manually (besides the Sale Performance Period/Year Info-Window), I have incorporated another feature to give meaning to the 'paneling' strategy that does not touch core but presides over core. Following is a screenshot what i mean. The user is now able to see each Product's available quantity as well as backorders during save.

ObtainProductStatus.png (47.64 KiB) Viewed 11037 times

The back orders count is done by searching all order lines that are completed but not shipped. Orders that are in draft or progress mode are not taken into count.

[red1]

Now i move the values to persistent properties so that later they can be called as a new JOIN with PM_JobProductionLine in the Orders to Schedule window that be more highly usable.

MoveToFields.png (75.35 KiB) Viewed 11024 times

[red1]

The 'Cockpit Panel' approach can now graft out usable panel to control all core plugins. This is an alternative Orders to Schedule Info-Window with data injected from the Job Production model.

ExpandedOrdersDelivery.png (112.26 KiB) Viewed 11008 times

The Job Production model is extended to cover more usable properties such as Days Since DateOrdered, its own Sales back order and total back orders vs availability of the product and later will be putting in a flag if a finished good is still at contractor's or back to warehouse.
There shall be a Refresh-Data process at this Info-Window to update those new properties and a PrintOut can be added to this Info-Window via Ninja easily.

[red1]

The cockpit panel tested to work fully. Added Days Till Promised(Date) to give visibility to user when an order is due to ship out. This is besides the Days Since Ordered(Date). There is also flags to say 'Ready' to ship as OnHandQty is checked available, and 'Insufficient' when otherwise. The 'Ready' flag is a cumulative calculator that marks which line can be shipped and which cannot as it goes down the list. The list thus is therefore sortable. That is why i put a LineNo as the first column, which is default to '99' so that any line that user wish to pump up, can just put a value in the Job Production Line window.

PowerCockpit.png (84.27 KiB) Viewed 10994 times

From here it shall behave like the usual WMS. This cockpit approach (as a reminder) follows the separation of plugin concern, and sits squarely above the WMS which sits independently above iDempiere. This cockput plugin thus does not mess with the other core models nor require hard coding into them. This is the way of the Ninja.

The SQL JOIN for the Info Window is now pivoting off PM_JobProductionLine instead. Thus I have to copy over the WMS CreateDeliverySchedule to do likewise. Zooming individual record in the above will go straight to the Job Line. There, the Sales Orderline is linked for easy zoom across.

The source code is at https://bitbucket.org/red1/org.pm.production and binary plugin with 2Pack at https://sourceforge.net/projects/red1/f ... rehousing/

[red1]

I have refactored PM_Production to focus only on Forecasts to MRP to BOM Drop and Production. Latest progress this previous week has been the more fully decoupled approach in plugin design, where there is no inter-dependency together with BackOrderManagement and WMS plugins which works in conjunction with each other. Let's see how far this purist approach goes.

From here there is branching into separate forum threads that explains sub improvements - and .

As a reminder the source of the three projects are:
https://bitbucket.org/red1/org.red1.wms
https://bitbucket.org/red1/org.pm.production
https://bitbucket.org/red1/org.backorder.management

At the moment backorder (beta release) and WMS binaries are uploaded to https://sourceforge.net/projects/red1/f ... rehousing/. PM_Production is unreleased pending work in MRP to WMS handling.