A customer's purchase order should reach Microsoft Dynamics 365 Business Central as the seller's sales order, with the correct company, customer and item references. Reading the document is the preparation stage. The implementation must still decide which Business Central records to create and which business actions remain with the order team.
This guide focuses on that design work. Business Central installations differ in extensions, permissions and required fields, so validate the actual customer environment. The official API references describe useful building blocks; they do not establish that a generic connector already covers the customer's complete order process.
Start with company context and order identity
Microsoft's salesOrder API reference separates the ERP record ID and sales-order number from externalDocumentNumber. It also exposes customer identity, currency, delivery and address fields. Write down where the buyer's PO number belongs rather than treating every order identifier as interchangeable.
Agree the target company and customer mapping before importing lines. The same buyer name can appear in several operating entities, and the receiving company may use a different account code. Keep the original PO reference and the chosen ERP customer together in the review record. Test an order for the wrong company deliberately and confirm it is held before any write.
Design the header and line mapping together
The documented salesOrderLine resource includes its parent document, item reference, line type, sequence, unit of measure, quantity, price, variant and location. These fields make line identity more specific than a product description and an amount. A mapping should identify which values are required by the customer's workflow and which Business Central calculates.
Create a small mapping worksheet with the source field, reviewed value, target field and owner of any default. Include a case with two lines for the same item but different delivery requirements. Preserve line order and do not merge repeated items unless the business has explicitly agreed that the resulting order remains equivalent.
Resolve items, variants and units before sending values
Ask the Business Central administrator which product identifier should be used for matching and how customer-specific part numbers are maintained. A customer alias may identify a product family while the ERP requires a particular variant. Keep those distinctions visible instead of allowing description similarity to choose an item silently.
Use a test order with a box-versus-piece discrepancy and another with two locations. Establish the permitted unit conversion and the rule for choosing a location. Then compare the reviewed line with the resulting ERP line. If the ERP applies different defaults or pricing, explain the difference before calling the handoff accepted.
Treat authentication as an integration component
Microsoft documents service-to-service access through a Microsoft Entra application and the OAuth 2.0 client-credentials flow. The application must also be enabled and assigned appropriate permissions in Business Central. The same guidance calls for least privilege and excludes assigning the SUPER permission set to applications.
A field that accepts a bearer token is not a complete OAuth lifecycle. The implementation must obtain fresh tokens, restrict the app's access and handle expiry without exposing credentials to reviewers. Record who owns the app registration and how access is removed. Test loss of authorization as an ordinary failure case, with a clear pause and recovery path.
Keep order creation separate from fulfilment actions
Microsoft lists sales-order creation and a distinct shipAndInvoice action. Decide which action the project is authorized to perform and test that boundary explicitly. A document-import integration should not gain shipment or invoicing authority merely because the API exposes those capabilities.
Agree how a created order enters the customer's existing review process. After a timeout, reconcile the buyer's reference and the stored ERP record ID before retrying. Also test a changed PO: the team needs a controlled decision about amendment, replacement or rejection, rather than an automatic second sales order.
Run a batch that exercises the real exceptions
Use representative customer orders with ordinary lines, unknown aliases, alternative delivery addresses, price disagreements and a repeated PO. Include at least one customer-specific required field from an extension. For each case, compare the saved reviewed values with the actual Business Central record, including all lines and defaults.
Have both the order-desk owner and Business Central administrator sign off the mapping. Record required manual steps, permissions and the exact import or API route used. Keep a rejected case in the acceptance pack; proving that the process can stop an invalid order is part of proving that it works.
Define the Business Central work explicitly
Ordinon currently prepares reviewed orders and exports the approved version as CSV. Its compatible HTTPS connector supports manual product catalog pulls; it does not implement Microsoft Entra token management or automatic Business Central order creation. A Business Central import or adapter needs separate configuration, implementation and testing against the customer's environment.