Vendor Central & Dropship EDI Connector

The problem

Selling wholesale to a large marketplace is a different business from selling on one. In the seller model you list product, you own the customer, and you integrate against a public commerce API. In the vendor model the marketplace buys from you: it issues a purchase order, expects a structured acknowledgement within a contractual window, expects an advance ship notice before the freight arrives at the fulfilment centre, and expects an invoice that matches the shipment exactly. Miss the acknowledgement window and the order is cancelled. Get a case pack or a carton label wrong and the receiving centre charges you back. Send an invoice that does not reconcile to the ASN and you wait months to be paid.

Dropship compounds it. The same trading partner sends orders that ship direct to a consumer, with the partner's branding on the packing slip, a shipping label drawn from the partner's carrier account, tight ship-by windows and per-order tracking that must be returned before the window closes. Operationally it is a sales order, but commercially it arrives on the same EDI channel as the wholesale purchase orders.

Dynamics 365 Finance & Operations has the pieces — sales orders, direct delivery, warehouse work, packing slips, customer invoices, the electronic reporting framework — but it has no opinion about the vendor EDI cycle. So the work goes to a person: someone opens the partner portal, reads the new orders, keys them into F&O, and when the goods ship, keys the tracking numbers back. That person is the reason your acknowledgement compliance is a lottery and your chargebacks are a line item.

What ECOSIRE builds

We build an X++ extension model deployed into your Dynamics 365 Finance & Operations environment as a separate package — extension classes, chain-of-command, table and form extensions, no overlayering.

Inbound order intake

We build a transmission layer that collects inbound documents from the channel your trading partner actually uses: AS2, SFTP, an API, or a value-added network drop. Each document lands in a staging table with its raw payload preserved, then is parsed by a partner-specific mapping into a normalised internal structure. Every document keeps its control numbers and its raw form, because when a partner disputes what you received, the raw payload is the only thing that settles it.

A purchase order from the partner becomes a sales order in F&O, created through the standard sales order APIs so pricing, trade agreements, delivery terms, ledger dimensions and the rest of your setup apply normally. Cross-references between the partner's item identifier and your item number are held in a mapping table with case pack and inner pack quantities, so a partner ordering twelve cases becomes the right quantity in your unit of measure rather than a units mismatch discovered at the fulfilment centre.

Acknowledgement, ASN and invoice

Acknowledgements are generated automatically from the created sales order — accepted, rejected, quantity changed, backordered, price changed — within a per-partner window enforced by a batch job, so the deadline is met by the system rather than remembered by a person. Where a line cannot be confirmed, the acknowledgement carries the reason code your partner requires.

The advance ship notice is generated from the actual shipment. We build it from the packing structure recorded in warehouse management — license plates, containerisation, carton contents, SSCC labels where required — so the ASN describes what physically left the building rather than what the order said. Carton and pallet labels are produced through the electronic reporting framework or your existing label solution to the partner's specification, which is where most chargebacks originate.

Invoices are generated from the posted customer invoice and reconciled against the ASN before transmission, so quantity and price mismatches are caught on your side rather than by the partner's accounts payable. Inbound remittance and chargeback documents are parsed and matched back to the invoice, with unmatched deductions surfaced in a workspace instead of dissolving into a suspense account.

Dropship

Dropship orders route to a separate flow. They can be fulfilled from your own warehouse — creating warehouse work, picking, and a packing slip rendered in the partner's required branding through electronic reporting — or via the standard direct delivery mechanism to your own supplier where that is the model. Ship-by windows are tracked per order with a batch job flagging orders approaching their cut-off. Tracking numbers and carrier detail are returned to the partner automatically on shipment confirmation, and where the partner requires you to draw a label from their carrier account, the label request and response are handled in the same transmission layer.

Control, reprocessing and visibility

Every inbound and outbound document has a status, a control number, a timestamp and a full error record. A monitoring workspace shows documents in flight, documents in error, acknowledgements approaching their deadline and dropship orders approaching ship-by. Failed documents can be corrected and reprocessed from the workspace without re-requesting them from the partner. All transmission work runs as batch jobs in the standard batch framework with task splitting, and all document tables are exposed as data entities in the data management framework with OData for reporting.

Partner setup is data, not code: each trading partner has its own configuration record for identifiers, qualifiers, endpoints, credentials, acknowledgement windows, required document types and label specification, scoped by legal entity so a group with several selling entities runs them independently.

Who this is for

Brands and manufacturers running Dynamics 365 Finance & Operations who sell wholesale into large marketplaces or big-box retailers under a vendor arrangement, and who also take dropship orders on the same relationship. Companies whose EDI compliance is currently a person with a portal login. Multi-entity groups where more than one legal entity trades with the same partner under different identifiers. If your entire relationship with a marketplace is as a third-party seller using its public commerce API, this is the wrong shape of solution.

How delivery works

Scoping call. We identify each trading partner, the transmission channel and document set each one requires, their acknowledgement windows, their ASN packing and labelling specification, their chargeback rules, and how dropship differs from wholesale in your operation. We confirm your F&O version, warehouse configuration, environment topology and LCS ownership.

Fixed quote. A written scope naming each partner and each document type individually, stating the dropship flow, and giving a fixed price and delivery window. Additional partners or document types are quoted separately before work begins.

Build. ECOSIRE develops against a build environment on your version, with source access, a mid-build demonstration and a pre-handover demonstration.

Install in test. The deployable package goes to your LCS project and into your sandbox. We configure partner records, item cross-references and label specifications, then run the full cycle against your partner's test environment — order in, acknowledgement out, ASN out, invoice out, remittance in — and iterate until your partner's own validation passes. Certification against the partner's test process happens before production, not after.

Production. After acceptance, the package is promoted through your normal release process, partner endpoints are switched to production, and we attend the cutover while the first live orders flow.

Support. A defined support window after go-live covering defect correction, mapping adjustments when a partner changes a specification, and questions from your operations team.

Build-to-order means the mappings, labels and flows are written for your partners and your warehouse setup. Typical delivery is two to four weeks from a signed quote, extended where a partner's own certification process is the long pole.