ERP Connections

ERP Connections link your company's ERP to VEXORS. They are available on the Scale plan and managed by company admins under Settings then ERP Connections. VEXORS covers sourcing up to the award; your ERP keeps everything after that.

What a connection does

• Award handoff. When you award a request, VEXORS can create a draft purchase order in your ERP for the awarded supplier and lines. It stays a draft: VEXORS never confirms, approves, releases, submits or sends it to the supplier. Each award is sent once: if a delivery is repeated, VEXORS looks the purchase order up before it tries again; if a response is lost, VEXORS first waits a few minutes for the outcome to settle, then looks the order up by its reference. If your ERP has it, it is linked; if VEXORS cannot find it, it never guesses and never sends it again: the award page asks you to check your ERP (an order there that carries the VEXORS reference is linked on the next check; if there is none, raise the order in your ERP). Your ERP never receives a duplicate from VEXORS.
• Vendor master. VEXORS reads your ERP's vendors into your Connect directory and matches each one to a supplier company already on VEXORS. An exact tax registration match is proposed for you to confirm; anything uncertain is left for you to map by hand. Nothing is matched silently.
• Purchase order status. VEXORS periodically reads back the status of the purchase orders it created (draft, pending approval, approved, rejected, cancelled, closed). The award page shows the ERP, the document (a purchase order), its number, its status and when it was last checked, so you can see where an award stands without opening the ERP.

Everything the ERP supports is selected when you create a connection, and you can untick anything you do not want. A new connection is saved as a draft, does nothing until it has passed a connection test, and only then can be enabled. The test checks what each selected sync needs, so a connection with purchase orders selected passes only once its purchase order setup is complete.

Approval, receiving and payment stay in your ERP

VEXORS stops at the draft purchase order. Your purchasing team reviews it in the ERP, and your ERP's own approval workflow decides whether it becomes a live order. Sending it to the supplier, receiving goods, matching invoices and paying suppliers all happen in your ERP under your own controls; VEXORS never does any of them on your behalf.

What is sent, and what never is

What VEXORS sends to your ERP for an award is limited to the purchase order itself: the request reference and title, the currency, the awarded supplier's ERP vendor number, the requester's name and email, and the awarded lines (description, quantity, unit, unit price, item code and delivery date where the request has them). Each ERP uses the subset its purchase order needs.

VEXORS never sends other bidders, their prices or rankings, your internal comments, chat messages or ratings.

Credentials never leave VEXORS. The credentials you enter are encrypted at rest, are never shown again after you save them (the connection shows only a short preview such as the last four characters of a client id), are never written to logs, and are never returned by any VEXORS API. To change them you enter new ones. Each request to your ERP is made over HTTPS to the public address you registered; addresses on private or internal networks are refused.

Setting up a connection

1. Open Settings then ERP Connections and choose Add connection.
2. Choose the ERP, give the connection a name and pick its environment (sandbox or production). Try a sandbox first.
3. Enter the ERP's address and the credentials you prepared (checklists below).
4. Run the connection test. It checks, in order, that the ERP is reachable, that sign-in works, that the API access VEXORS needs is granted, and that the organisation setup is valid. Each check shows passed or failed with a plain message.
5. Keep the syncs you want (every supported one starts selected) and enable the connection.

A connection can be tested again, disabled and enabled at any time. Disabling stops syncing and cancels queued runs; deleting also removes the stored credentials. A company can hold up to five connections.

If the ERP rejects the credentials later, the connection moves to Sign-in failed and stops until you fix the credentials and pass a new test. A connection that is reachable but failing intermittently shows as Degraded.

Per-provider checklist

Each provider lists what it supports and its live-proof qualification. Everything listed as supported is available: each connection is made safe by its own connection test. The live-proof qualification is information only: it says whether VEXORS has also run the provider end to end on a real customer test environment, in addition to the simulation built from the provider's documentation that every provider is proven against.

Test ERP

A built-in sandbox ERP that behaves like a real one. It is offered only in non-production environments, so you can rehearse the whole flow (create, test, enable, hand off an award, see the draft purchase order and its status) without touching a real ERP. It needs no preparation on the ERP side.

SAP S/4HANA Cloud, Public Edition

Supported: the vendor master (business partners flagged as suppliers) pulled into your Connect directory, award handoff as a held (draft) purchase order, and purchase order status. Live-proof qualification: pending: proven against a simulated SAP built from SAP's published API definitions; the run on a real SAP test tenant is still to come.

How the draft works in SAP. SAP offers no way to create a purchase order as a draft through its API. VEXORS therefore creates the purchase order on hold (SAP shows it as Held): saved but not complete, not released and not sent to the supplier. Your buyer opens it in the Manage Purchase Orders app, checks it and completes it; from then on your approval workflow and output settings apply as usual. If SAP ever answers with an order that is not on hold, VEXORS stops, names the order and never changes it, so your team can check it in SAP. Your tenant should therefore have a purchase order approval workflow in place before you enable award handoff.

Your SAP administrator prepares the following in SAP Fiori:

1. A communication user (Maintain Communication Users) with a password. This is the user name and password you enter in VEXORS. Certificates and OAuth are not used.
2. A communication system (Communication Systems) for VEXORS, with that communication user as its inbound user.
3. Communication arrangements (Communication Arrangements) for two scenarios: SAP_COM_0008 "Business Partner, Customer and Supplier Integration" (required) and SAP_COM_0053 "Purchase Order Integration" (needed for award handoff).
4. The API host of your tenant, for example https://my300000-api.s4hana.cloud.sap. That is the ERP address you enter: host only, no path.
5. Organisation values for purchase orders: company code (always), and, for award handoff, purchasing organisation, purchasing group, plant, the material group used for free-text lines, the account assignment category (for example K) with its cost center and G/L account, and optionally the purchase order document type (NB by default). Set all of the purchase order values or none.
6. A unit-of-measure map from your VEXORS units to SAP units (SAP units are at most 3 characters, for example PC, EA, KG) and, if you quote in a currency SAP names differently, a currency map.

No custom field is needed in SAP: VEXORS writes a 12-character reference that starts with VX into the purchase order's standard Your Reference field (CorrespncExternalReference) and finds the order there again, so a lost reply does not lead to a second purchase order: VEXORS looks the reference up before it ever creates again. Keep that field unchanged until the order shows its number on the award page. This is proven against a simulated SAP today; the run on a real tenant is part of SAP's live-proof qualification.

What the SAP connection test checks. Reachable; sign-in with the communication user; the Business Partner API answers (SAP_COM_0008); and, with purchase orders selected: the purchase order values are set, the Purchase Order API answers (SAP_COM_0053), the Your Reference field can be searched on your tenant, and the service lets VEXORS create a purchase order on hold with that reference. With purchase orders selected but values missing, the test fails and names them; untick purchase orders for a vendor-master-only connection.

Limitations to know. Sign-in is user name and password only. Line descriptions longer than 40 characters are shortened in the item text. Incremental vendor reads use SAP's change date, so a vendor changed on the day of the last read is read again (harmless). SAP does not publish a request-rate limit; VEXORS backs off on SAP's "too many requests" and "unavailable" answers.

Microsoft Dynamics 365 Finance & Supply Chain Management

Supported: vendors of the configured legal entity pulled into your Connect directory, award handoff as a draft purchase order, and purchase order status. Live-proof qualification: pending: proven against a simulated Dynamics 365 built from a real environment's published metadata; the run on a real Dynamics 365 test environment is still to come.

How the draft works in Dynamics 365. A purchase order is a Draft in Dynamics 365 only when change management applies to it. VEXORS asks for change management on every purchase order it creates and checks that the order really is a Draft before it adds any line. Before it creates anything, VEXORS reads the awarded vendor: if change management is neither activated for that vendor nor allowed per purchase order, nothing is created and the award page names the vendor and the setting to change. If your environment still makes an order approved straight away, VEXORS stops before adding lines and names the empty order so your administrator can cancel or delete it. In Procurement and sourcing parameters, switch on change management (and allow it per vendor where needed) before you enable award handoff.

Your Dynamics 365 administrator prepares:

1. A Microsoft Entra application (app registration) in your tenant with a client secret. Note the Directory (tenant) ID, the Application (client) ID and the secret value. In VEXORS you enter them as the token URL https://login.microsoftonline.com/<tenant id>/oauth2/v2.0/token, the client id, the client secret, and the scope https://<your environment host>/.default. Certificates are not used.
2. The Dynamics 365 application registration: in finance and operations, System administration > Setup > Microsoft Entra applications, add the client id and map it to a dedicated service-account user that holds the security roles for reading vendors and, for award handoff, creating purchase orders.
3. The environment URL, for example https://contoso-test.sandbox.operations.dynamics.com. That is the ERP address you enter: host only, no path.
4. The legal entity (company id, for example usmf). Every vendor read and every purchase order VEXORS creates is scoped to it.
5. For award handoff: the procurement category VEXORS should use for award lines (lines are created as category lines, not item lines), and optionally a receiving site and warehouse.
6. A unit-of-measure map from your VEXORS units to Dynamics 365 unit symbols (for example ea, pcs, kg) and, if needed, a currency map.

No custom field is needed in Dynamics 365: VEXORS writes its reference into the purchase order's Vendor reference field (VX:<award id>:L<number of lines>) and finds the order there again within your legal entity. Keep that value unchanged while the order is in Draft.

What the Dynamics 365 connection test checks. Sign-in with the Entra application; the environment's OData metadata exposes the vendor, company and (with purchase orders selected) purchase order entities with the fields VEXORS uses, including the vendors' change management settings, and that the vendor reference and the change management request can be written on create; the legal entity exists; and, with purchase orders selected: the procurement category is set, purchase orders can be searched by vendor reference on your environment, and at least one vendor of the legal entity can receive draft purchase orders (change management activated or allowed per order). With purchase orders selected but the category missing, the test fails and names it.

Limitations to know. Dynamics 365 vendors carry no change timestamp, so every vendor pull is a full read of the legal entity. A purchase order is written as a header followed by its lines; if a line is refused after the header exists, the handoff fails with the Dynamics 365 purchase order number and the reason, and the next attempt completes the same order instead of creating another. If the attempts run out first, the award page shows the hand-off as failed, or says the purchase order exists but is not complete; either way re-send the award and VEXORS completes that same order. Microsoft throttles heavy integrations with "too many requests" and a wait time; VEXORS honours it.

Oracle Fusion Cloud ERP (Procurement)

Supported: the suppliers your requisitioning business unit can buy from pulled into your Connect directory, award handoff as a draft purchase order, and purchase order status. Live-proof qualification: pending: proven against a simulated Oracle Fusion built from Oracle's published REST documentation; the run on a real Oracle test environment is still to come.

How the draft works in Oracle. VEXORS creates a draft purchase order (Oracle's draft purchase orders are created but not yet communicated to the supplier) and leaves it Incomplete. Your buyer reviews it in Oracle, adds the supplier site and anything else your process needs, and submits it; Oracle's approval decides from there.

Your Oracle administrator prepares:

1. A dedicated integration user in Oracle Fusion (Security Console) with a password, holding the roles that read suppliers and, for award handoff, the Procurement REST Service duty (ORA_PO_PROCUREMENT_REST_SERVICE_DUTY) with the privilege to create purchase orders; the user must be a procurement agent of the procurement business unit. VEXORS signs in with that user name and password (HTTP Basic over HTTPS). OAuth client registrations are not used.
2. The pod URL, for example https://acme-test.fa.em2.oraclecloud.com. That is the ERP address you enter: host only, no path. VEXORS calls the Procurement REST resources under /fscmRestApi/resources/11.13.18.05/.
3. The requisitioning business unit id (the numeric RequisitioningBUId). Every supplier read uses it (suppliers are listed through Oracle's "find by requisitioning BU" finder).
4. For award handoff: the procurement business unit id, the buyer (procurement agent person id), the purchasing document style id, the purchasing category VEXORS should use for award lines (lines are created as non-catalogue "Goods" lines with an item description, not item numbers), and optionally ship-to and deliver-to location codes.
5. A unit-of-measure map from your VEXORS units to Oracle UOM names (for example Each) and, if needed, a currency map.

No custom field or flexfield is needed in Oracle: VEXORS starts the purchase order description with its reference (VX:<award id>:BU<business unit id>:L<number of lines>, where the business unit is the procurement business unit), followed by the request reference and title, and finds the order there again. Keep the start of that description unchanged while the order is a draft.

What the Oracle connection test checks. Sign-in with the integration user and that suppliers can be read; that suppliers can be listed for your requisitioning business unit (Oracle's finder); and, with purchase orders selected: the handoff values are set and draft purchase orders can be read and searched by description inside your procurement business unit. With purchase orders selected but values missing, the test fails and names them. An unknown business unit id is expected to answer with an empty supplier list rather than an error (to be confirmed on a real Oracle pod), so verify the id in Oracle.

Limitations to know. Oracle's supplier resource cannot be filtered by last-update date, so every supplier pull is a full read. Supplier emails are not read (contacts are a separate resource). A purchase order is sent with all its lines in one request; if the response is lost, the next attempt looks the order up by its description before creating anything, so a second purchase order is never created by VEXORS. Of Oracle's purchase order statuses only "Incomplete" is confirmed from the documentation; the others are mapped by their user-guide names and an unfamiliar status is shown as unknown until confirmed on a real pod.

Odoo (16–20)

Supported: the vendors of the configured Odoo company (and the vendors shared across companies) pulled into your Connect directory, including an incremental pull of recently changed vendors; award handoff as a draft purchase order; and purchase order status. Live-proof qualification: pending: proven on real Odoo Community 16.0, 17.0, 18.0, 19.0 and 20.0 servers (the official builds) in VEXORS' own test lab; the run on a customer's own Odoo test database is still to come, and the first real connections will be watched closely.

How the draft works in Odoo. VEXORS creates a purchase order in the draft state, addressed to the awarded vendor, and never confirms or sends it. Odoo itself labels a draft purchase order "RFQ" and lists it under Requests for Quotation until someone confirms it: that is Odoo's name for an unconfirmed purchase order, not a second sourcing round. Your buyer reviews it, confirms it, and Odoo's own approval rules (for example double validation above an amount) apply from there.

Supported Odoo versions and deployments: Odoo 16.0, 17.0, 18.0, 19.0 and 20.0. VEXORS asks your server which version it runs and uses that version's own external API — the external JSON-RPC API on 16, 17 and 18, the External JSON-2 API on 19 and 20 — so there is nothing to choose; you may enter the version you expect, and the connection then stops — its test and every sync — if the server reports a different one (after an upgrade, update or clear that field). All five versions are tested on real Community servers. Enterprise (self-hosted or on Odoo.sh) uses the same external API and the same purchase and contact records, so it is expected to behave the same way, but it has not been tested on an Enterprise server yet. Odoo Online runs Odoo's own intermediate releases (for example saas~18.3), which VEXORS reads as the version they come from; they have not been tested, and if one already differs the connection test stops before anything is created. There the external API is available on the Custom plan only (not One App Free or Standard), and Odoo Online's own request limits have not been measured. Versions before 16 and after 20 are refused by name.

Your Odoo administrator prepares:

1. A dedicated bot user (Settings > Users) with access to Contacts for the company you will connect and, for award handoff, the Purchase: User right, and ideally no other rights; Odoo recommends disabling password sign-in for such users.
2. An API key for that user: Preferences > Account Security > New API Key, with a description (from Odoo 18, also a duration). Copy the key once — Odoo does not show it again. In VEXORS you enter the bot user's login as the user name and the API key as the password (on 16, 17 and 18 VEXORS signs in with both; on 19 and 20 the key alone identifies the user). VEXORS accepts only an Odoo API key there and refuses the user's password. On Odoo 20, use a key created in Odoo 20 itself: Odoo 20 only accepts keys with the "RPC" scope its own key screen gives them, and refuses a key without a scope. When a key expires or is deleted, the connection stops with an authentication error until a new key is entered and the test passes.
3. The instance URL, for example https://acme.odoo.com. That is the ERP address you enter: host only, no path. Enter the database name as well: it is required on Odoo 16, 17 and 18 (every call names it), and on 19 and 20 needed only when one server hosts several databases.
4. The company id (the numeric id of the company under Settings > Companies, visible in the page address). Every vendor read and every purchase order is scoped to that company; the bot user must be allowed to work in it.
5. For award handoff: the Purchase app, one purchasable product VEXORS writes every award line against (the award text becomes the line description; a service product creates no receipt), a unit-of-measure map from your VEXORS units to Odoo units of measure, and the award currency active in Odoo (or a currency map).

No custom field is needed. VEXORS writes its reference into the purchase order's Source Document (VX:<award id>:C<company id>:L<number of lines>) and finds the order there again, so a lost reply does not lead to a second purchase order. The Invoicing or Purchase app must be installed for the vendor sync (it provides the vendor rank the sync relies on; the connection test says so when it is missing). A contact counts as a vendor when it has been used as one in Odoo (its vendor rank is above zero — it was created from the Purchase app or has received a bill); a contact created by hand that never had a purchase or bill is not pulled until it is used as a vendor.

What the Odoo connection test checks. That the address answers as an Odoo server, which version it runs (and that it is the version you entered, if you entered one); sign-in with the bot user's API key; that the company exists and the bot user may work in it; that contacts can be read under that company; and, with purchase orders selected: the product is set, purchase orders can be read and searched by Source Document in that company, the bot user is allowed to create purchase orders, the purchase order line has your version's unit-of-measure field, and the chosen product can be bought in that company. With purchase orders selected but the product missing, the test fails and names it.

Limitations to know. Only Odoo 16.0 to 20.0. API keys can be deleted at any time and, from Odoo 18, they expire. Recently changed vendors are pulled incrementally by their last-modified time; a full pull is always available, and it also picks up a vendor that has no last-modified time (one written into the database outside Odoo). Country codes are resolved through Odoo's country list; a vendor without a country has none. Award lines are not matched to your Odoo products: every line uses the one product you chose.

Nothing on this page is a promise of a date. Every provider above is available with everything listed as supported; its live-proof qualification says whether VEXORS has also run it on a real customer test environment (today: pending for all four). Other ERPs, such as NetSuite and Infor, are not available yet.