myDATA receipt demo
AADE myDATA XML to an 80 mm receipt PDF, in the browser.
Live demoSource on GitHubSource and demo are public.
Problem
myDATA XML has a strict element order, VAT that must add up to the cent, and fields that must not appear for Greek parties. Getting any of it wrong means a rejected document.
What I built
- A typed TypeScript library that builds InvoicesDoc XML (schema v2.0.2) for a retail receipt (11.1) and a sales invoice (1.1).
- Integer money and an explicit rounding rule. Element order taken from the official XSD.
- Validation against the AADE XSD, in tests and in the browser.
- A static Next.js page that parses the XML back and renders the receipt PDF from it, so the XML is the single source of truth.
How it works
Integer money
Amounts are integer cents from the moment input is parsed. VAT is computed per line with one documented rounding rule, so the totals in the XML always equal the sum of the lines.
The XML is the source of truth
The receipt is not drawn from form state. The page builds the XML, parses it back with a strict parser into a typed object, and renders the receipt from that object. If the XML is wrong, the receipt shows it.
Issuer name and address are not allowed in the XML for a Greek issuer. AADE already knows them from the tax number. The printout takes them from a fixed letterhead profile instead.
Nothing leaves the page
It is a demo. Nothing is transmitted to AADE or anywhere else. The issuer is fictional and every printout carries a watermark.
Data flow
Form input
raw strings
Validated, typed input
VAT computed
integer cents
InvoicesDoc XML
checked against AADE XSD v2.0.2
Parsed back
strict parser, typed object
Receipt
- HTML preview
- PDF, 80 mm
Screens
The form, and the receipt rendered from the XML
Stack
TypeScript · Next.js · XSD validation · React PDF · AADE myDATA