Skip to Content

PMIS Federation Stock

Alpha License: LGPL-3 PMISuite/federation Version: 18.0

Exchange validated outbound deliveries and review receiver-owned receipts in Odoo 18 Community. Each side retains its own warehouse, products, units, and stock decisions, independently of shared login and messaging.

Features

  • Reviewed warehouse, receipt operation type, and source/destination locations.

  • One active stock approval per operating company, counterparty, instance pair, and document capability through its exact reviewed route.

  • Separate receiving configuration for deliveries and customer returns.

  • Internal receiving locations within the approved warehouse, including input locations used by multi-step receipts.

  • Frozen native settings, administrator attribution, and approval time.

  • Archive-and-replace corrections that retain the original approval history.

  • Stock approval evidence included in incoming document verification.

  • Renewed receiver review when approvals or relevant native settings change.

  • Explicit Send after outbound validation, using actual shipped quantities.

  • Immutable queued delivery revisions and explicitly selected supporting files.

  • Separate partial deliveries against the original order exchange.

  • Reviewed local receipt demand linked to counterpart purchase lines.

  • Reuse of eligible order-generated receipts, with unshipped demand retained in linked native backorders.

  • Company-scoped picking and move correspondence, exact retries, and permanent application evidence for each accepted revision.

  • Explicit revision review and acknowledgment of receiver edits.

  • Explicit validated buyer returns with actual quantities and exact original delivery/move references. Acceptance creates unvalidated customer return pickings.

  • Partial returns retain native original-move links and account for already allocated return quantities. Completed stock remains protected from revisions.

  • Separately identified replacement documents retain exact replaces-references. Returns never create or send credit notes automatically.

Configuration

For buyer returns, approve a separate Returns route and outgoing connection. On the seller, approve that route's receiving warehouse, customer source location, internal destination, operation type, and independent product/unit mappings. Validate the buyer's native return, select Send via Federation, and choose the Returns connection. The seller opens Review Delivery on the incoming return and accepts draft demand; native validation remains manual. Original deliveries and order dependencies must have exact applied correspondence first. If a native return already exists, explicitly select Reuse Local Return in the review dialog. Only a matching, unprocessed return with current review evidence can be linked. Unclaimed local returns prevent allocating duplicate demand; conflicting or completed native returns require local resolution. For a replacement delivery, select Replaces Document in the Send dialog.

Install pmis_federation_stock alongside Federation Orders. The addon uses native sale_stock and purchase_stock and requires no additional Python packages or external OCA addons.

In Federation > Document Routes, approve the exact operating company, instance pair, counterparty, and Deliveries or Returns capability as described in the Exchange setup guide.

Administrators need Inventory access and both operating company and Directory Owner access. Directory visibility alone grants no stock use. A delivery approval does not authorize returns or another counterparty.

Usage

  1. Open Federation > Stock Mappings and create a mapping.

  2. Select the reviewed Document Route and its operating company's Warehouse.

  3. Select an incoming Receipt Operation Type belonging to that warehouse.

  4. Choose the Source Location: a supplier location for deliveries or a customer location for customer returns. Shared external locations are allowed.

  5. Choose an internal Destination Location within the selected operating company and warehouse.

  6. Enter the human approval evidence in Verification Reference and save.

Saving freezes the selected targets and relevant native settings with the acting administrator and approval time. Approved Native Settings shows the original configuration. Each route permits one active stock approval.

Sending deliveries

Send the originating sales order through Federation Orders first. After validating its outbound delivery in Inventory, select Send via Federation, the reviewed outgoing Deliveries connection, and any supporting files. Send queues frozen document evidence; transport dispatch and status use the shared Exchange services. Each partial picking has its own document identity within the same order exchange. Send the original delivery before sending its backorder.

Receiving deliveries

Open the incoming document and select Review Delivery. Resolve its exact order dependencies, approve local stock product and unit mappings for the Deliveries route, and confirm the local purchase order before accepting receipt demand. Missing dependencies or ambiguous receipt candidates remain for receiver review. No document name or remote native ID establishes correspondence.

An order-generated draft is updated in place. Existing pending order receipts remain visible to duplicate prevention even when their operation type differs from the approved targets or their demand is already linked to another delivery. These conflicts require receiver review instead of creating another draft. Separate partial deliveries consume the order's remaining backorder demand.

Review Delivery Changes, enter Review Evidence, and select Accept Receipt Demand. An eligible order-generated receipt is reused; a partial shipment keeps the unshipped demand in a local backorder. Otherwise, acceptance creates a draft receipt. Received quantities become local demand; receipt validation, lots, serials, and stock execution remain manual. Reject rejects the exact document revision without canceling the local picking or purchase order.

Use the picking's Federation button to inspect its document and move links. Revisions always require explicit review. Reopen the review after any local edits and acknowledge replacements with Replace Reviewed Local Values. Independently processed, completed, or canceled stock cannot be overwritten by a revision.

Each side owns its picking lifecycle independently. Canceling or replacing a local picking does not require a notice, peer approval, or a matching action on the other side. Cancellation notices are optional and never sent automatically or enabled by default. Local replacements retain their own native identity while the original exchange correspondence stays with the original picking and moves. Normal Odoo stock rules still govern cancellation and returns of completed stock operations.

Approval ownership

Receiving targets and relevant native settings are frozen with the administrator and approval time. To change them, archive the original approval and create a reviewed replacement. History retains the original targets. Restoring an archived approval requires its original configuration to remain valid and unchanged.

Incoming delivery and return verification includes the exact stock approval. Missing approvals remain unresolved. Added or replaced approvals, archived targets, changed operation defaults, and changed destination hierarchy require renewed receiver verification. Frozen documents and their original verification remain unchanged; no route successor or substitute warehouse is selected automatically.

Current boundaries

The same adapter handles deliveries and buyer returns through separate route, stock, and commercial approvals. Replacements retain separate document identities and require receiver review. Optional cancellation notices are handled by Exchange without canceling native stock records. Receiving never validates stock automatically or creates accounting documents.

Bug Tracker

Bugs are tracked on PMISuite Repository Issues.

Credits

Authors

Contributors

  • Matjaž Mozetič

Maintainers

LUXIM MATMOZ

Current maintainer:

sysadminmatmoz

Luxim is an independent R&D and deployment company focused on solving complex problems in the Odoo ecosystem.

Odoo Community Association

Luxim is an active member of OCA (Odoo Community Association).