Vendor Collaboration Portal

The problem

Procurement runs on email. A purchase order is emailed to a supplier, who replies with a confirmation in prose — sometimes agreeing to the dates, sometimes proposing different ones, sometimes not replying at all. A buyer reads that reply and retypes the confirmed quantities and dates into Dynamics 365 Finance & Operations, or doesn't, and the demand picture quietly drifts from reality. Advance shipping notices arrive as attachments that the warehouse never sees. Invoices arrive as PDFs to a shared mailbox and get keyed in by AP, where a mismatch against the PO surfaces days later. Insurance certificates and quality accreditations sit in a spreadsheet with a reminder column nobody owns.

None of this is a data problem. F&O already holds the purchase order, the confirmed receipt expectations, the product receipt, the pending vendor invoice and the vendor master. What is missing is a controlled surface where the supplier can act on that data directly, without a licensed ERP seat and without a buyer acting as a transcription service.

What ECOSIRE builds

ECOSIRE builds a supplier-facing collaboration portal and the Dynamics 365 Finance & Operations extension layer behind it. This is build-to-order work: we scope against your procurement configuration, your approval workflows and your vendor master conventions, then build, deploy and hand over the source. Nothing is pre-packaged.

ERP-side architecture

The F&O side ships as X++ extension models — event handlers, chain-of-command classes, table and form extensions and extended data entities — with no overlayering. The model is compiled against your platform version, packaged as a deployable package and promoted through your own LCS/sandbox pipeline.

Read operations run over OData against data entities for purchase orders, purchase lines, vendor master, product receipts and pending vendor invoices. Write operations that carry business logic — confirming a PO, proposing a revised date, submitting an ASN, posting an invoice into the pending queue — run through custom service groups so validation, number sequences and workflow behave exactly as they do inside F&O. Suppliers authenticate against the portal as external identities mapped to a VendTable account; they are never licensed F&O users and never touch the F&O client.

Purchase order confirmation

The supplier sees each open purchase order line with the requested quantity, price and delivery date, and responds line by line: accept, propose a different date, propose a different quantity, or reject with a reason. An accepted PO is confirmed in F&O so the confirmed delivery date drives your master planning rather than an optimistic requested date. A proposed change is routed to the buyer — optionally through the workflow framework so it lands in the right approver's work item queue — and only updates the order once approved. Every response is stamped with who responded and when, so the audit trail lives in the ERP rather than in a mailbox.

ASNs, receipts and the warehouse

Suppliers submit advance shipping notices against confirmed PO lines, including quantities, pack structure, carrier and expected arrival. Where you run advanced warehousing, the ASN can create the inbound load and shipment so the receiving team sees the arrival before the truck does, and the warehouse mobile app receiving flow scans against a known expected shipment rather than an open PO. Where you use item batch or serial tracking, the ASN can carry the supplier's batch identifiers and expiry dates so they arrive with the goods instead of being captured at the dock.

Invoice submission and matching

Suppliers upload invoices with a PO reference and line detail. The submission lands as a pending vendor invoice in F&O, where your existing three-way matching policy, tolerances and invoice approval workflow apply unchanged. The supplier sees the matching outcome — matched, price variance, quantity variance, awaiting receipt — and the payment status once posted, which removes the majority of "has my invoice been paid" calls to AP.

Onboarding and compliance documents

Prospective suppliers complete an onboarding submission that creates a vendor request routed through workflow for approval, rather than an email to the vendor master team. Existing suppliers maintain their own remit-to details, contacts and bank information as change requests that require internal approval before they touch VendTable — deliberately, since unapproved bank detail changes are a fraud vector. Certificates (insurance, quality accreditations, tax residency) are uploaded with expiry dates, and a batch job raises reminders and flags expired documents to the responsible buyer.

Data flow and operations

Interactive reads use OData with paging. Bulk operations — an initial vendor load, a catalogue publication, a nightly document sync — use the data management framework, driven by recurring batch jobs so they never sit on an interactive request. Where you already run Dual-write or the Power Platform, supplier identity and document storage can be sourced there instead of duplicated; that is a scoping decision.

Who this is for

Organisations running Dynamics 365 Finance & Operations with a supplier base large enough that PO chasing has become a job in itself: manufacturers with a long inbound tail, distributors managing dropship and direct suppliers, and any procurement function under pressure to evidence on-time-in-full performance or supplier compliance. Multi-legal-entity groups benefit particularly, since one supplier often trades with several of your entities and expects one login.

It is a weaker fit where you buy almost everything through a handful of contracted suppliers on standing orders, or where purchase orders are not confirmed in F&O at all today — the portal formalises a process, it does not invent one.

How delivery works

1. Scoping call. We review your procurement setup, confirmation policy, matching and tolerance configuration, warehousing model, workflow approvals and vendor onboarding process, and agree the exact portal scope. 2. Fixed quote. A written scope and a fixed price, agreed before any build begins. Later changes are quoted as change requests. 3. Build. Typically 2–4 weeks depending on scope, built against a copy of your configuration. 4. Install in test. The deployable package is deployed to your sandbox through your LCS pipeline, configured with your team, and validated against agreed scenarios with real supplier data. 5. Production. After sign-off, the same package is promoted through your normal release process, under your controls. 6. Support. A defined post-go-live support window for defects in what we built, with full source handed over so your team can maintain it independently.