Full workflow: Odoo deliveries from pool to shipment
Odoo owns orders, stock and reservations. DG owns dispatch, reports and release intent. The DG module executes shipment in Odoo and stores a result receipt.
Prepare the Odoo delivery
Use self-hosted Odoo 19 Community with the DG module, an authorized bot, one-step delivery and full reservations. Odoo.sh remains under verification; Odoo Online is unsupported. A sales-order number alone is not dispatch-ready work.
Batch and dispatch in DG
Select deliveries in the Odoo pool, create a configured batch and dispatch. Work quantities are Odoo reservations, not native DG supply allocation. Check original ERP demand against reservations in Odoo.
Report and release
After App synchronization, a supervisor checks actual quantities, review and remainder policy. In the ordered 40/work 30/actual 25 example, DG requests shipment of 25; the relevant remainder depends on Odoo delivery/reservation lines. BACKORDER retains remainder; DROP does not. Verify the actual Odoo outcome.
Verify shipment and receipt
After APPLIED and SHIPPED, verify the related Odoo delivery, actual quantities and backorder. If Odoo committed but its response was lost, DG first checks the same command's receipt. UNKNOWN does not permit another shipment. Printing is created after posting confirmation.
When the source changes
Odoo reservation, version or delivery-state changes after batching may cause CONFLICT. Compare references and source changes with a supervisor/administrator. Do not ship again directly in Odoo or create duplicate DG tasks.
Can DG supplement an insufficient Odoo reservation?
No. Odoo reservations determine work; prepare the source in Odoo. Investigate existing tasks and conflicts before changing anything.
What if Odoo is done but DG remains UNKNOWN?
Keep the original command and use Check now to read its receipt. Have an administrator verify references/connectivity; do not ship again.