UPnGO EDIEnterprise build specification
UPnGO EDI for Dynamics 365 Finance & Supply Chain Management
The implementation blueprint for building UPnGO EDI as a native D365 F&SCM extension using X++ extensions, data entities, business events, Azure Integration Services and the Power Platform.
1. Executive Summary
UPnGO EDI is a native Dynamics 365 Finance & Supply Chain Management extension that automates inbound and outbound EDI across order-to-cash and procure-to-pay, built entirely on supported extensibility patterns.
Objectives
Eliminate manual re-keying of trading partner documents, deliver touchless PO, ASN and invoice processing, and provide a single operational view of every EDI transaction flowing through D365 F&SCM.
Scope
X12 and EDIFACT document sets for purchase orders, order responses, despatch advice, invoices and credit/debit notes; partner onboarding; SSCC/LPN generation; transport status and proof of delivery.
Business Drivers
Retailer compliance mandates and chargeback avoidance, reduced order-to-cash cycle time, auditable transaction history, and lower cost per document versus VAN-only processing.
Success Criteria
≥ 98% straight-through processing on 850/ORDERS, < 5 minute end-to-end latency, zero unsupported over-layering (100% extension model), and full replay capability for any failed document.
2. Business Requirements
Requirements are grouped by process area so each maps cleanly onto a D365 module and a set of data entities.
Order-to-Cash
Inbound 850/ORDERS creates sales orders; 855/ORDRSP returns acknowledgement; 856/DESADV publishes the ASN; 810/INVOIC issues the invoice. Pricing, trade agreements and item cross-references resolve against D365 master data.
Procure-to-Pay
Outbound 850/ORDERS to suppliers, inbound 855 confirmations, inbound 856 for receiving, and inbound 810 for three-way match against PurchTable, PackingSlip and VendInvoice.
Trading Partners
Per-partner profiles hold qualifiers and IDs, envelope settings, document enablement, item and UoM cross-references, connection type (AS2 / SFTP / VAN / API) and compliance rules.
EDI Standards
ANSI X12 (4010/5010) and UN/EDIFACT (D96A onward), with 997/CONTRL functional acknowledgements and partner-specific implementation guidelines held as versioned mapping definitions.
3. Enterprise Solution Architecture
A layered architecture: trading partners connect to Azure Integration Services, which normalise documents and call D365 through OData/custom services; D365 pushes state changes back out via Business Events.
Context Diagram
Trading partners and VANs ⇄ Azure API Management ⇄ Logic Apps / Functions ⇄ Service Bus ⇄ UPnGO EDI extension inside D365 F&SCM, with Key Vault and Application Insights as cross-cutting services.
High-Level Architecture
Edge (AS2/SFTP/API ingress) → Translation (X12/EDIFACT to canonical JSON) → Orchestration (Service Bus topics per document type) → D365 (data entities and X++ services) → Observability (App Insights, transaction log).
Integration Strategy
Asynchronous by default. High-volume documents use the Data Management Framework recurring integrations; low-latency documents use custom services. Every message carries a correlation ID from ingress to posting.
Deployment Topology
Separate resource groups per environment (DEV/TEST/UAT/PROD), private endpoints for Service Bus and Key Vault, and D365 deployable packages promoted through Azure DevOps release pipelines.
4. D365 Extension Design
All customisation is extension-based. No over-layering, no changes to Microsoft models, and every integration point uses a supported extensibility mechanism.
Extension Models
UPnGOEDICore (tables, EDTs, enums, base classes), UPnGOEDIIntegration (services, contracts, business events) and UPnGOEDIExtensions (CoC and event handlers against ApplicationSuite / SCM).
Packages
One deployable package per release, with model dependencies limited to ApplicationPlatform, ApplicationFoundation, ApplicationSuite and ApplicationCommon to keep upgrade impact low.
Chain of Command
CoC wrappers on SalesTableType.insert, PurchTableType.update and WHSShipmentTable confirmation to raise UPnGO EDI status transitions without modifying base logic; every wrapper calls next().
Event Handlers
Pre/post handlers on posting classes (SalesFormLetter, PurchFormLetter, WHSPostEngine) and DataEventHandler subscriptions for inserted/updated rows that must trigger outbound documents.
Data Entities
UPnGOEDITradingPartnerEntity, UPnGOEDITransactionEntity, UPnGOEDIMappingEntity and composite entities for inbound order headers plus lines, all exposed via OData and DMF.
Business Events
UPnGOPurchaseOrderCreated, UPnGOSalesOrderConfirmed, UPnGOASNPublished, UPnGOInvoicePosted and UPnGOTransactionFailed, consumed by Service Bus and Logic Apps subscriptions.
Security
Duty- and privilege-level security: UPnGOEDIOperator (process and replay), UPnGOEDIAdministrator (partner and mapping maintenance), UPnGOEDIViewer (read-only), each mapped to explicit table permissions.
Batch Framework
RunBaseBatch/SysOperation services for polling, retry sweeps, acknowledgement matching and archive purging, with batch bundling and configurable thread counts per document type.
5. Business Modules
Ten functional modules cover the full document lifecycle from purchase order through proof of delivery to credit note.
Purchase Orders
850 / ORDERS inbound and outbound against PurchTable and PurchLine, with confirmation matching on 855 / ORDRSP.
Sales Orders
Inbound customer orders create SalesTable/SalesLine with partner-specific pricing, item cross-reference and delivery term validation.
ASN
856 / DESADV generated from the warehouse shipment, including hierarchical pack structure (shipment / order / pack / item).
Warehouse
Wave and load events drive outbound document timing; WHS shipment confirmation is the trigger point for ASN publication.
Inventory
846 / INVRPT stock advice on a scheduled batch, sourced from on-hand by site and warehouse.
SSCC/LPN
GS1-compliant SSCC allocation with per-warehouse ranges, exhaustion alerts and license plate linkage to the ASN pack structure.
Transport
204/990/214 tender, response and status messages integrated with D365 Transportation Management loads and shipments.
POD
Proof of delivery capture (214 / IFTSTA plus signature payload) closing the load and releasing the invoice.
Invoices
810 / INVOIC generated from posted customer invoice journals with tax, allowance and charge segments mapped from D365 charges.
Credit/Debit Notes
Credit and debit adjustments raised from return orders and price corrections, cross-referenced to the original invoice control number.
6. Azure Integration
Azure Integration Services provide ingress, translation, buffering and observability outside the D365 boundary.
API Management
Fronts all partner and internal APIs with subscription keys, IP allow-lists, rate limits, JSON schema validation and request/response logging.
Service Bus
Topics per document type with subscriptions per direction, sessions for ordering by partner, dead-letter queues and duplicate detection on control number.
Azure Functions
Stateless translation and mapping workers (X12/EDIFACT ⇄ canonical JSON), SSCC allocation helper and acknowledgement reconciliation.
Logic Apps
Long-running partner orchestrations: AS2 send/receive with MDN handling, SFTP polling, retries with exponential backoff and escalation notifications.
Key Vault
Certificates for AS2 signing/encryption, SFTP keys, D365 service principal secrets, all accessed via managed identity with no secrets in configuration.
Application Insights
Distributed tracing keyed on correlation ID, custom metrics for throughput and latency per partner, and alert rules on dead-letter depth and failure rate.
7. Technical Specifications
Data structures, contracts and cross-cutting technical services shared by every module.
Database Schema
UPnGOEDITradingPartner, UPnGOEDIDocumentSetup, UPnGOEDITransaction, UPnGOEDITransactionLog, UPnGOEDIMapping, UPnGOEDISSCCRange, UPnGOEDIRetryQueue.
Entity Relationships
TradingPartner 1—n DocumentSetup; TradingPartner 1—n Transaction; Transaction 1—n TransactionLog; Transaction 0..1—1 D365 source document (PurchTable / SalesTable / WHSShipmentTable / CustInvoiceJour).
API Contracts
Canonical JSON envelope: { correlationId, partnerCode, direction, docType, controlNumber, receivedUtc, payload }, versioned with a schemaVersion field and validated at API Management.
EDI Mapping
Declarative mapping records per partner and document version: segment/element path → canonical field → D365 entity field, with qualifier lookups and value cross-reference tables.
Logging
Every state transition writes a TransactionLog row (event type, message, user, UTC timestamp) and emits a matching App Insights trace under the same correlation ID.
Retry Framework
Classified failures: transient (auto-retry with exponential backoff, max 3), data (queued for operator correction and replay) and fatal (dead-lettered with alert). Replay is idempotent on control number.
8. Development Guide
How the team builds, tests, ships and upgrades the extension.
Coding Standards
Microsoft X++ best practices: no direct SQL, label files for all user-facing text, ttsbegin/ttscommit around writes, Chain of Command over event handlers where both are possible.
Project Structure
One Visual Studio project per model, folders by artefact type (Tables, Classes, Entities, Forms, Security), and a shared canonical contract library referenced by Azure Functions.
CI/CD
Azure DevOps: build pipeline compiles and runs unit tests on a build VM, produces the deployable package, and a release pipeline promotes it through TEST, UAT and PROD with approvals.
Testing
SysTest unit tests for mapping and service classes, integration tests using recorded partner payloads, and a regression suite executed against a Tier-2 environment before each release.
Deployment
Deployable packages applied through LCS with a documented downtime window; Azure resources deployed as Bicep templates from the same repository.
Upgrade Strategy
Track Microsoft One Version releases, run the extensibility analyser on every platform update, and keep all customisation extension-based so upgrades remain non-breaking.
Appendices
- UML class diagrams for the X++ class catalogue
- Entity relationship diagram for the UPnGO EDI schema
- Sequence diagrams per document flow (850, 855, 856, 810)
- Trading partner data mapping workbooks
- JSON and XML schema definitions for the canonical envelope
- Azure architecture and network topology diagrams
- Test case catalogue and acceptance criteria