Hi Dev and User Community, I would like to share and discuss significant enhancements made in PR https://github.com/apache/ofbiz-framework/pull/1168, specifically to the Manufacturing module’s inventory management system (OFBIZ-13262).
Goal is to bring the manufacturing module into parity with the Sales Order fulfillment engine by introducing formal Inventory Reservations. Here are a few major improvements made to the system: *1. Automation & Policy-Driven Control* We have introduced a new entity, WorkEffortInvRes, to track material commitments. To ensure this fits diverse business models, we’ve added two key facility-level flags: *autoReservePrun Flag in Facility*: When enabled, the system automatically initiates component reservations the moment a Production Run reaches the Printed/Approved status. *Backward Compatibility*: This process is entirely optional. Organizations that prefer the traditional "direct issuance" model can continue to work without reservations; the issuance logic has been designed to remain backward compatible. *2. Intelligent Issuance & Granular Control* The issuance logic has been upgraded to be "Reservation Aware": *Priority Issuance:* If a reservation exists for a task, the system will automatically issue from that reservation first. *Partial Logic:* If a component is only partially reserved, the system will issue the reserved portion and then attempt to fulfill the remainder using pre-configured FIFO/LIFO rules based on available stock. *Floor Manager Empowerment:* Floor managers can now reserve or release specific Inventory Item IDs or Lot IDs at specific locations. This allows for precise control over high-value or batch-sensitive materials. *3. Force Issuance & "Theft" Governance* Previously, Apache OFBiz allowed "Force Issuance," which automatically "stole" stock from Sales Orders if Quantity on Hand (QOH) was available but Available to Promise (ATP) was zero. We have formalized this with: *allowInventoryTheft Flag in Facility:* This flag governs whether a production task is permitted to reclaim stock already promised to other orders. *Impact Visibility:* Instead of a silent theft, we’ve introduced a summary/popup that informs the user exactly which Sales Orders or Production Orders will be impacted by the force issuance, ensuring better cross-departmental communication. *4. Real-time Backorder Satisfaction* With the new *reconcilePrunBackorders* flag in Facility, the system now includes a "Backorder Satisfier." When new inventory is received, the system automatically identifies pending production runs with a "Global Debt" (backordered reservation) and allocates the new stock to them in real-time, reducing manual intervention. *5. Architectural Stability: The "Trinity Sync"* One of the core problems we identified was "Ledger Blindness." Since the InventoryItem table does not have a quantityNotAvailable (QNA) field, the availableToPromiseTotal (ATP) can easily drift if reservations are modified without corresponding ledger entries. For example, let's take the Force Issuance (Theft) scenario: *Initial State:* Inventory: QOH=5, ATP=0. Task A: Has a physical reservation of 5 units (secured). Task B: Has a backordered reservation of 5 units (QNA=5). *The Action: *A floor manager performs a "Force Issue" for Task B, stealing the 5 units from Task A. *The Transformation:* Task B now has 5 physical units issued/committed. Task A's reservation is automatically converted from "Physical" to "Backordered" (QNA becomes 5). *The Drift:* The Ledger Error: During this "theft," the InventoryItem ledger can easily drift. If the system "releases" Task A's reservation to give it to Task B, the ATP might momentarily jump to 5. If the satisfaction of Task B's backorder doesn't precisely trigger a corresponding ledger subtraction at the exact same moment, the ATP remains at 5. *The Result: *The system incorrectly reports ATP=5, even though all 5 units are physically issued to Task B and 5 units are still owed to Task A. You have created 5 units of "Ghost Inventory." *The Solution:* The trinitySync service solves this by performing a cold recalculation of the "Physical Truth." It looks at the resulting state of all reservations after the theft, determines that True ATP must be 0, and forces the ledger to match. This ensures that a "Force Issuance" for one task doesn't accidentally inflate the availability for others. So this auditor service performs a three-way check between: Physical Stock (QOH) Logical Commitments (Active Reservations in WorkEffortInvRes and OrderItemShipGrpInvRes) The Promise Ledger (ATP) If a drift is detected, trinitySync calculates the "True ATP" and applies a correction via the createInventoryItemDetail service, ensuring the ledger always reflects physical reality and maintains financial auditability. *6. Testing* This entire framework is backed by a robust suite of 35 unit tests covering manual and automatic modes, theft policies, and reconciliation guards. *7. Moving from Reactive to Proactive* These changes shift the Manufacturing module from a reactive tracker to a proactive engine: *Proactive Planning:* Shortages are identified as "Logical Debt" (Backorders) at the Approval stage, days before the job reaches the assembly line. *Proactive Fulfillment:* The system "wakes up" upon inventory receipt and automatically assigns stock to the highest-priority tasks. *Proactive Availability*: The trinitySync auditor ensures that ATP never drifts, preventing the over-promising of materials to sales or other production runs. I look forward to your feedback and thoughts on this strategy. I also invite everyone to review the code changes in the PR: https://github.com/apache/ofbiz-framework/pull/1168 I plan to commit these changes by the end of next week and would appreciate any feedback or reviews from the community in the meantime. Once I commit, I will also share the user manual and testing steps on the ticket and the OFBiz wiki. Thanks -- Divesh Dutta www.hotwaxsystems.com
