Visma and Orderful integration

What moves between them

Purchase orders and supplier invoices flow from Visma into Orderful. ml-connector polls Visma on a configurable schedule (or via webhooks if enabled), retrieves purchase orders and invoices with lastModifiedDateTime, formats them as EDI 850 and 810 transactions, and delivers them through Orderful's API. The ISA identifiers map your Visma supplier/customer entities to trading partner profiles in Orderful. Incoming purchase order changes (860 EDI documents) can flow back through Orderful webhooks into Visma. All other EDI documents (ship notices, invoices from partners) flow one way: into Orderful for delivery, not back to Visma.

How ml-connector handles it

ml-connector obtains a Visma access token via OAuth 2.0 client_credentials, caches it until expiry, and refreshes by re-requesting when a call returns 401. Every GET and PUT call includes the ipp-company-id header. When polling, ml-connector queries purchase orders and invoices with lastModifiedDateTime filters to pull only changes since the last run. For writes back to Visma (such as updating a purchase order status after an 860 acknowledgment), ml-connector reads the ETag from the prior GET, includes it in the If-Match header on the PUT, and retries with an exponential backoff if a 412 Precondition Failed is returned (meaning another process updated the record first). On the Orderful side, ml-connector translates Visma purchase orders to 850 and invoices to 810 format, maps the supplier/customer name and account to ISA identifiers, sets the stream field to live in production (test in development), and POSTs to Orderful's /v4 create endpoint. Orderful webhook signature verification requires support contact for full details; in the interim, ml-connector does not validate webhook signatures and relies on polling. If an Orderful 429 rate limit is hit, ml-connector backs off exponentially and retries.

A real-world example

A Nordic food distributor runs Visma.net ERP for purchasing, payables, and accounting across three regional warehouses. They ship to retail chains in five countries, each requiring purchase order and invoice data in their own EDI formats (X12 in the US, EDIFACT in Europe). Before the integration, the supply chain team exported purchase orders from Visma as CSV, manually formatted them into EDI, and uploaded them to each retailer's EDI portal. Invoice translation was done the same way. With Visma and Orderful connected, each purchase order and invoice created in Visma automatically translates to EDI and routes to the correct partner network through Orderful. The supply chain team no longer needs to touch EDI files; they work in Visma, and Orderful handles routing to all partners.

What you can do

• •Pull purchase orders and invoices from Visma and translate them to EDI 850 and 810 format.
• •Route translated EDI documents through Orderful to multiple trading partner networks (AS2, SFTP, VAN, HTTP).
• •Map Visma suppliers and customers to Orderful ISA identifiers and trading partner profiles.
• •Handle Visma OAuth token refresh, ETag-based optimistic locking on updates, and delta polling via lastModifiedDateTime.
• •Receive incoming EDI change documents (860 PO changes) from Orderful and apply them back to Visma purchase orders.

Questions

Which direction does data flow between Visma and Orderful?

Purchase orders and invoices flow from Visma into Orderful for translation and delivery to trading partners. Incoming purchase order change documents (860 EDI) can flow back from Orderful into Visma. All other inbound EDI documents (invoices, ship notices from partners) are read-only and do not update Visma.

How does ml-connector handle Visma's OAuth tokens and ETag locks?

ml-connector obtains a token via OAuth 2.0 client_credentials and caches it until expiry, then refreshes on the next 401 response. When updating a purchase order in Visma after receiving an EDI 860 change, ml-connector reads the ETag from the prior GET, includes it in the If-Match header on PUT, and retries with exponential backoff if the record was changed by another process (412 Precondition Failed).

How does polling work if Visma has webhooks enabled?

Visma webhooks are one-time delivery with no automatic retry, so ml-connector prefers polling via the lastModifiedDateTime query parameter on purchase order and invoice list endpoints. This ensures no records are missed if a webhook fails. If webhook enablement is configured in Visma company settings, ml-connector can register a subscription but will still poll as the primary method.