What LunoLake EDI is
A module inside your own Dynamics 365 that exchanges business documents with your trading partners, and a service that carries them. No middleware to learn, and no second place where the truth lives.
Most EDI for Dynamics 365 works by standing outside it. A separate platform holds the partner agreements, the mappings and the message history, and it talks to Dynamics through an integration. That arrangement works, and it leaves you with two systems that both believe they know the state of an order, an integration between them to keep healthy, and a support question that starts with finding out which of the two is wrong.
LunoLake EDI is a module in Dynamics 365 Finance and Supply Chain Management. Partners, agreements and message history are records in your own database, next to the customers and vendors they belong to. A despatch advice is produced from the packing slip you posted, not from a copy of it. When you want to know whether the invoice reached the customer, you look at the invoice.
What it covers
The order to invoice flow, in both directions, in three wire formats. An order that arrives as an EDIFACT ORDERS becomes a sales order like any other; the invoice that answers it can go out as an EDIFACT INVOIC, an X12 810 or a UBL Invoice, depending on what that one partner reads.
| Business document | EDIFACT | X12 | UBL |
|---|---|---|---|
| Order | ORDERS | 850 | Order |
| Order change | ORDCHG | 860 | None |
| Order confirmation | ORDRSP | 855 | OrderResponse |
| Despatch advice | DESADV | 856 | DespatchAdvice |
| Invoice and credit note | INVOIC | 810 | Invoice, CreditNote |
| Project invoice and credit note | None | None | ProjectInvoice, ProjectCreditNote |
| Receipt for the envelope | CONTRL | 997 | MessageLevelResponse |
| Receipt for the document | APERAK | 824 | ApplicationResponse |
Every one of those travels both ways where the business document does. The despatch advice you send from a packing slip is the same document type as the one a supplier sends you, read the other way round, so adding the purchase side later is not a second product.
Behind each type is an Electronic Reporting configuration that renders your records into that file, and another that reads one back. EDIFACT is D96A, X12 is 4010, and UBL is PEPPOL BIS3 with OIOUBL 2.1 beside it for Denmark. The whole list, with the direction each type travels, is on Documents and formats.
Which part is yours and which part is ours
The module is yours. It runs in your environment, its data is your data, and you can read every line of what it did. Carrying the document to the partner is ours: the service takes what the module produced, speaks the transport the partner requires, and hands back what came the other way.
| Yours, in Dynamics 365 | Ours, as a service |
|---|---|
| Partners, agreements, identifiers | AS2, AS3, AS4 and plain file connections over SFTP, FTP or FTPS |
| What a document contains | The certificates we supply, and keeping them valid |
| When a document is sent | Delivery, retries and receipts |
| The order, the packing slip, the invoice | Network directories, where a network has one |
You do not configure the service. What this manual describes is every point where it touches you: what leaves, what comes back, and what you see when something does not arrive. One certificate is yours. NemHandel is signed for with an OCES3 certificate issued to your own legal entity, which you buy and renew.
The copy the service holds is a working copy and not an archive. A document is deleted thirty days after it last moved. The authoritative copy is the one in your own Dynamics 365, and it stays there as long as you keep it.
What it looks like in use
A partner is a card in Dynamics, beside the customers and vendors it trades as, carrying the identifiers it is known by on the wire and one agreement per document per direction. After that, ordinary work does the sending. Confirm a sales order and a confirmation goes out. Post a packing slip and a despatch advice goes out. Post an invoice and an invoice goes out. Nobody has to press send.
Inbound is the mirror of it. A partner order arrives, is checked against what you actually sell them, and becomes a sales order. What was compared, and what did not match, is kept.
Every document that an order touched shows up on the order itself, in the flow tracker, in the order it happened, with the state of each. That is usually the whole of a support question.
When it does not fit
Some partners ask for a document nobody else uses, or a format of their own. That is expected, and it is why the module has a published extension surface rather than a settings page with a text box. You add a document type in your own model, keyed to your own enum value, and the module finds it. It is a handler class and a couple of Electronic Reporting configurations, and it does not fork anything.
The LunoLakeEDIExample model in the product repository is a complete worked example: an invented format called SIMPLEDI with its own goods received note, its own acknowledgements and its own reporting configurations. It is built in a separate model that is deliberately not a friend of the main one, so if it compiles, the published surface is enough on its own. There is no private door we use and you do not get.
What you need before starting
- Dynamics 365 Finance and Supply Chain Management, with Electronic Reporting available.
- A trading partner who has told you what they send, in which format, over which transport.
- An identifier they address you by. In Denmark that is usually a GLN or a CVR number.
- A connection to the LunoLake service, which we set up with you.
That is the shape of it. How a document travels follows one document all the way out and one all the way in, and the flows after it take each business document on its own.