Goods movement¶
Delivery notes and digital goods movement.
Must delivery notes (9.3) be transmitted through a certified e-invoicing provider, or can they go directly to AADE?
This is a tax and accounting question that depends on the business's obligations, and it must be confirmed with its accountant. In Novus's view, once a client has declared a Provider, it should issue everything through the Provider. The Provider API supports notes 9.1, 9.2, 9.3 and 10.x, as well as an invoice or receipt that is also a delivery note (isDeliveryNote), at 1 credit per note.
With the digital delivery note, does issuing notes through the Provider change? Can the Provider call the transport methods (/RegisterTransfer to /ConfirmDeliveryReturn) on my behalf?
Issuing and transmitting movement documents (9.x, 10.x, invoice/receipt – delivery note) continues as before through the Provider, with MARK and QR, with no change to the integration. The transport events (pickup/transshipment, delivery, confirmation or rejection by the recipient, return completion) are declared by the ERP directly to AADE, through the myDATA ERP channel. It uses the credentials (aade-user-id, ocp-apim-subscription-key) of the business acting each time: issuer, carrier or recipient. These methods do not exist in the provider channel, so the Provider cannot call them. As a reference, use the MARK / qrUrl of the note that the Provider returns to you.
Why does a sales invoice – delivery note (1.1 with isDeliveryNote: true) appear in RequestTransmittedDocs with isDeliveryNote = false?
Usually because the movement fields are not inside the invoiceHeader object. isDeliveryNote, dispatchDate, dispatchTime, vehicleNumber, movePurpose and otherDeliveryNoteHeader (with loadingAddress and deliveryAddress) all belong in invoiceHeader. If invoiceHeader closes too early (e.g. right after currency), the fields end up at the root of the document, are not recognized, and the document goes through as a plain invoice. Compare your structure with the ready-made example "1.1 — Sales invoice - delivery note".
Why is a delivery note with movePurpose = 6 rejected, and which movement purpose do I use instead?
Movement purpose 6 (Safekeeping) has been abolished by AADE and is no longer accepted, even if the sender and the recipient have the same VAT number (ΑΦΜ). The same applies to 15, 16, 17 and 18. Choose an active code from the "Movement purpose" table according to the actual transaction, e.g. 14 (Storage at third parties) or 19 (Other movements, with otherMovePurposeTitle). Which code fits a consignment is decided by the business with its accountant.
See: Goods movement
Can I retrieve through the Provider API the incoming documents (e.g. delivery notes) issued to the business's VAT number?
No. The Provider API has no endpoint for incoming documents, and RequestTransmittedDocs only returns documents that you issued through your account. Your software retrieves incoming documents for a VAT number directly from AADE's myDATA API, with the business's myDATA credentials.
See: Other endpoints
Is a TARIC / Combined Nomenclature code per line supported for the unified item coding?
Yes. The line field invoiceDetails[].TaricNo (10 characters) is accepted and transmitted to myDATA, together with itemCode / itemDescr. For unified item coding on all documents, we will announce anything needed in the Changelog once AADE publishes the final specifications.
See: SendInvoices
Does the Provider support the new myDATA 2.0.2 movement types (9.1, 9.2, 10.1, 10.2), or do I need to wait for a new version of the integration?
They are all supported already: 9.1, 9.2, 9.3, 10.1 and 10.2, as well as 1.1 / 11.1 as invoice/receipt – delivery note (isDeliveryNote: true with otherDeliveryNoteHeader). They are issued with the same SendInvoices, and you get the MARK and UID in the response, without sending them separately to myDATA. In 10.1 / 10.2, receivingNotePurpose is required. The current documentation (version 3.0) is aligned with myDATA 2.0.2, and every new AADE change is announced in the changelog before it takes effect.