​

Execution Plan

The Execution plan is the roll-up of everything you’ve committed: every purchase, production run, and transfer the solver must respect, grouped by kind and lifecycle status. It’s the counterpart to the recommendation queue — the queue is what the solver suggests, this is what you’ve committed. Navigate to Execution plan under the Supply Chain group in the sidebar.

​

Page layout

The header shows total counts as badges — N committed and N ordered — plus a New movement button that creates a movement directly (a dropdown of Purchase, Transfer, and Production). Below it, three collapsible sections: Each section repeats its own N committed / N ordered badges, and rows carry a status badge:

• Committed — accepted but still editable.
• Ordered — transaction-backed; a real ERP order exists. Ordered rows sort first and are no longer editable here.

If nothing is committed yet, the page says so: “Execution plan is empty — Stage a recommendation to commit it here; the solver will then respect it.”

​

Row actions

Committed (not yet ordered) rows offer three actions:

​

Edit

Opens the movement drawer — the shared editing surface for purchase, transfer, and production movements. Change quantities and dates; the edit is version-guarded so concurrent changes can’t silently clobber each other. Edits show on the planning grids immediately, and count toward the freshness strip’s “N edits since” until the next solve.

​

Order

Opens the order confirmation dialog, which flips the accepted movement to ordered and mints the real transaction:

• Order this purchase — mints the supplier transaction.
• Order this transfer — mints the ship transaction between the lane’s warehouses.
• Order this production run — mints the production transaction at the run’s node, reserving its BOM components.

In every case the committed row stays the source of truth; ordering records the real order. The resulting transaction appears on Transactions.

​

Remove

Removes the row from the execution plan via a two-step inline confirm (Remove → Confirm / Cancel). When the row backs a live recommendation, removal is reversible — the recommendation reappears in the queue. For a directly-entered movement it’s a real delete, which is why the confirm step exists.

​

Creating movements directly

New movement authors a movement that never passed through a recommendation — a purchase, transfer, or production run you know you need. It lands as a committed row like any accepted recommendation, and the solver respects it from the next solve.

​

Best practices

​

Troubleshooting

​

Next Steps