Hi Dev and User Community, I would like to share a quick update on OFBIZ-13262 / PR #1168.
The changes have now been committed to trunk: https://github.com/apache/ofbiz-framework/commit/d850c17b6f4ed2b78ba5e59dabbfc7dd06d468f5 I will soon share the manual test case report on the Jira ticket, along with the testing details for the new inventory reservation and reallocation flows. After that, I plan to close the Jira issue in a week or two, assuming no further concerns are raised. Thanks -- Divesh Dutta www.hotwaxsystems.com On Fri, May 15, 2026 at 4:10 PM Divesh Dutta <[email protected]> wrote: > Hi Dev and User Community, > > I would like to share an update on PR > https://github.com/apache/ofbiz-framework/pull/1168 for OFBIZ-13262. > > Jacopo reviewed the proposal and raised two very helpful points: > > > 1. The trinitySync service addressed the inventory inconsistency after > the fact, however, the better approach is to prevent the inconsistent state > from being created initially. > 2. Terms like “theft” and “stealing” were not ideal for a generic ERP > system and should be replaced with more neutral business terminology. > > > I have updated the PR based on this feedback. > > The trinitySync service and its usage have now been removed. Instead, the > core inventory issuance and reservation logic has been adjusted so that > ATP/QOH/reservation consistency is maintained during the actual issuance > and reallocation flow. This keeps the fix closer to the source of the issue > rather than relying on a later synchronization/auditor step. > > I have also renamed the facility-level policy field from > allowInventoryTheft to allowInventoryReallocation, and updated the related > code, comments, labels, test data, and test cases to use neutral “inventory > reallocation” terminology instead of “theft” or “stealing”. > > So the updated approach is now: > > > 1. No separate trinitySync correction service > 2. Consistency is handled directly in the core issuance or > reallocation logic. > 3. Neutral terminology: “inventory reallocation” > 4. Facility policy now named "allowInventoryReallocation". > 5. Tests were updated accordingly > > > The inventory issuance test suite is passing after these changes. > > Thanks again to Jacopo for the thoughtful review. The feedback helped > improve both the architecture and the terminology of the proposed solution. > > I will still keep the PR open and wait for more reviews and feedback. Then > I will push the changes in OFBiz trunk by end of next week. > > Thanks > -- > Divesh Dutta > www.hotwaxsystems.com > > > On Thu, May 7, 2026 at 2:09 PM Divesh Dutta < > [email protected]> wrote: > > > > > > 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 > >>
