An Italian supplier receives an electronic purchase order successfully. The integration dashboard reports a green delivery status. In the warehouse, one requested item has a different internal code, another is unavailable, and the delivery location does not match the default customer address. Someone exports the document and starts a spreadsheet. The transport worked; the commercial workflow has barely begun.
A useful NSO integration connects the incoming order to a controlled supplier response and a fulfilment decision. If your team is buying development services, ask the supplier to demonstrate what happens when the order cannot be accepted exactly as received. That is where an integration proves whether it supports operations or simply moves documents.
Understand which ordering process you are buying
Italy's Agency for Digital Italy describes how electronic orders use NSO and the Peppol network. It identifies simple, complete and pre-agreed ordering processes. These are distinct scopes for an implementation. The phrase “NSO connection” does not tell a buyer which commercial conversations the proposed system will support.
Identify the process used by the relevant customers, the receiving channel and the responsibilities of your access-point or integration provider. Your development partner may connect the ERP to an existing provider rather than implement transport infrastructure. The statement of work should explain that boundary and name the party responsible when a message is rejected or delayed.
The Italian complete-ordering specification distinguishes acknowledgement, acceptance, rejection and responses with changes. It also describes relationships between response lines and order lines. Those capabilities matter because receiving an order is a different event from agreeing to supply it.
Preserve the customer's line before mapping your product
Keep the original order and its line references. Link each line to the internal item, unit, quantity and fulfilment decision without replacing the customer's original description. A human reviewer should be able to inspect both sides of the mapping.
For example, a customer may describe a product in free text or use a catalogue reference that differs from your warehouse code. That does not justify selecting the nearest name automatically. Build an approved mapping where possible and a review queue where ambiguity remains. Record who approved a new relationship and when it becomes valid.
Units deserve an explicit demonstration. A carton, pack and individual item can refer to the same product family while implying different quantities. The application should show the conversion and its source. A supplier responding to an order needs a reliable commercial quantity, not a technically valid number copied between two fields.
Keep responses and warehouse release separate
Design the internal workflow around decisions: received for review, mapping incomplete, ready for commercial response, response prepared and released to fulfilment. The exact labels can follow your existing operations. What matters is that a transport acknowledgement does not silently advance the warehouse into an irreversible action.
The permitted response depends on the process and customer's requirements. If a line cannot be supplied as requested, the interface should show the supported choices and the information required for each. Do not invent an informal response outside the agreed electronic process simply because it is easier to display.
Stock reservation also needs a policy. Decide whether capacity is provisionally held while the response is prepared and when that hold expires. If an order changes during review, show which previous decision is affected. Staff should not be able to release an older version while assuming they are looking at the current request.
Carry the references into delivery and invoicing
The integration should preserve the chain between customer order, internal sales order, fulfilment records and invoice references. Finance must be able to trace the source of a reference without retyping it from a downloaded document. At the same time, the application should distinguish a customer ordering identifier from an internal dispatch number.
Ask your accounting and procurement specialists to approve the exact mappings required for the customers in scope. An integration project is not complete when it produces syntactically valid XML if the receiving organisation cannot associate the resulting document with its purchase. Test the downstream document in the actual agreed process rather than assuming any successful upload is sufficient.
For partial deliveries, the system needs a clear account of what has been allocated, dispatched and still remains open. A response and a physical shipment can describe different points in time. Do not overwrite the original requested quantity with the amount in the latest van simply to make a dashboard balance.
Make uncertainty visible without duplicating work
Network interruption creates an important buying question: if your ERP does not receive a final acknowledgement, does the connector send the same business message again or first determine its current state? Require the supplier to explain the recovery mechanism supported by the chosen transport and provider.
Your internal processing should also tolerate repeated delivery of information. Re-reading an order must not create a second sales order or reserve the same inventory twice. Store durable correlations between the external document and the internal effects already applied. Provide a controlled way to retry incomplete work.
Operations needs a queue that distinguishes unknown outcome, rejected content, missing item mapping and business approval pending. Each item should have an owner and a next action. A single red “integration failed” badge leaves purchasing, IT and the warehouse guessing who should intervene.
A first project worth commissioning
Choose one customer relationship, one ordering process and one ERP destination. Use a small but representative set of products and units. Include an exception your staff currently resolves manually; an entirely predictable order can hide the most expensive integration gap.
Ask the vendor to demonstrate the following acceptance journey:
- ▸Receive an order and retain the original document and line references.
- ▸Resolve one deliberately ambiguous product mapping.
- ▸Prepare the supported response for an unavailable or changed line.
- ▸Stop release when the underlying order version changes during review.
- ▸Repeat a delivery event without creating another internal order.
- ▸Trace a resulting fulfilment or invoice reference back to the accepted source.
The handover should include mapping ownership, provider contacts, test fixtures, recovery instructions and monitoring responsibilities. Keep a clear distinction between documents used for testing and production customer traffic. Agree how upcoming format or provider changes will be reviewed before they affect live operations.
Compare development with the connector you already have
An existing ERP module or managed connection may already provide adequate document transport. Investigate that first. Custom development becomes useful when the commercial decisions, product mapping or cross-system references remain manual despite a functioning connection.
Evaluate proposals against the same order set and exception list. Record how often staff must repair mappings, how long unresolved orders wait and whether references survive into the next system. Those are measurable outcomes from your operation. They provide a better basis for scope decisions than unsupported promises about national adoption or automatic revenue growth.
Our integration statement-of-work guide helps specify the system boundary. The software handover guide explains what your team should receive to operate the result independently.
TuniCyberLabs builds custom software and business-system integrations. To scope an NSO supplier integration, share your ERP, current connection provider, ordering process and an anonymised difficult order. We can define a first delivery around the decision your team still handles outside the system.