Why does the receipt not come out of our till printer?

Most often because the application talks to the printer as to a page, or not at all: a receipt printer expects a sequence of commands, text, images, cut, over Bluetooth, USB or network, and it has no Arabic font. We build the rendering as commands, Arabic as image, a local queue on the till, and we test on every model actually present in the shops, not the office one.

Why does the PDF invoice show boxes instead of Arabic?

Because the Arabic font was not embedded in the file: the PDF pointed to a server font, and the customer’s machine does not have it. An invoice produced as PDF/A embeds all its fonts, both scripts included, and opens as is in ten years on any machine; it is the archiving standard, and what we produce by default.

How do you guarantee gapless numbering?

The number is set by the server at the moment the event issues the document, in a sequence per branch and per year, once; it is never assigned by a “print” click, which can be made twice or cancelled. A cancellation produces a numbered cancellation document, not a gap. The accountant sees the sequence and its gaps in supervision.

What happens when an invoice is reprinted?

The same archived file comes out, with a “duplicate” watermark, and the log says who asked and when. It is never regenerated from the data, because prices or the address may have changed since: the invoice is a photograph taken at issue time, and its fingerprint proves the file has not moved.

Does the receipt come out if the network is down?

Yes. The sale is recorded on the till, the receipt is rendered as commands and enters a local queue on the till itself, the printer takes it when ready, over Bluetooth or USB; nothing goes through the server. Synchronisation happens when the network returns, and the receipt number stays unique because the till has its own sequence.

How long to set up the documents?

Six weeks: one for the inventory and numbering with the accountant, one for the PDF engine and the invoice, one for receipts on the real printers, one for notes, labels and quotes, one for the archive, reprint and sending, one for on-site acceptance. The first week passes without a document generated, because its decisions cannot change afterwards.

Printing invoices, receipts and labels from your application in Algeria in 2027: bilingual PDF, thermal printer, numbering and archives, what gets built

Short answer. A document is not a view you print, it is an issued object: an event triggers it, a number is set once in a gapless sequence per branch and per year, its data is frozen at that instant, a versioned template renders it, and the produced file is archived with its fingerprint; a reprint brings out the same file, marked duplicate. Three rendering engines for one source: PDF/A with embedded fonts for what must be readable in ten years, the thermal command stream for 80 or 58 mm receipts where Latin text goes as text and Arabic as an image, and the label printer language for barcode labels. The receipt waits in a local queue and comes out even without network; the invoice goes by WhatsApp and e-mail and sleeps in versioned storage. Six weeks, the first without a single document generated.

This guide is for the shopkeeper whose till must print in two seconds, the manager whose accountant demands consecutive numbers, and the founder settled in France who receives the invoice by WhatsApp and must be able to reopen it in five years. It does not repeat how the till takes payment, described in the point-of-sale guide, nor how the interface speaks both languages, described in the bilingual application guide; it describes what is built between the data and the paper, and extends our page on software engineering.

What the references say

A PDF that must be read in ten years has a standard, and it is precise. PDF/A, defined by ISO 19005, is the version of the format “specialized for use in the archiving and long-term preservation of electronic documents”: “all fonts must be embedded”, “encryption is forbidden”, “external content references are forbidden”, scripts too, and standards-based metadata is required. It comes in several parts, PDF/A-1 to PDF/A-4, and conformance levels, including level b for faithful visual reproduction and level u which adds that all text has a Unicode mapping. What this imposes: an invoice issued as PDF/A-2b or 2u with its two-script fonts embedded will open as is in ten years, on a machine that never had those fonts; an ordinary PDF invoice pointing to a server font will show boxes.

Till printers speak a textual command language, not a page language. Epson’s ESC/POS command set is described as “a variant for controlling receipt printers as commonly used at the point of sale”, and “many current thermal receipt printers still continue to use the ESC/POS command set”; all Epson receipt printers support it. What this imposes, and we say it as an observation on the machines we meet in shops: most understand this command set, but almost none has an Arabic font or Arabic letter shaping; Latin text therefore goes as text, forty-eight characters per line on 80 mm, and Arabic lines go as images, rendered by the application with its own font.

What we did not find: a public statistic on till printers installed in Algeria, or on the share of invoices exchanged as PDF; what we see is 80 mm thermal printers over Bluetooth or USB, 50 by 30 mm label printers in warehouses, and PDF invoices sent by WhatsApp in most cases, and we say so as an observation. Invoice content and numbering rules depend on your accountant; this guide describes the mechanics that hold them, not the rules themselves.

An application’s documents, in five layers

Before the invoice, the five layers, and the one that avoids the two most frequent failures.

Figure 1 · The accented layer is what avoids the two most frequent failures: a different PDF on every click, because it rereads data that changed, and an Arabic version in boxes, because the font was not embedded. A versioned template with its fonts, applied to a frozen snapshot, produces the same document today and in ten years.

Document data: a snapshot frozen at issue time, lines, prices, addresses, rates, and the number set in a gapless sequence; the document is a photograph, not a view on data that moves, and a price changed tomorrow does not change yesterday’s invoice. Templates: one per document, bilingual or per language, versioned in the repository with fonts covering both scripts; every document says which version produced it, and this layer is what avoids the different PDF on every click and the Arabic version in boxes. Rendering: three engines for one source, PDF/A for what is kept, the command stream for receipts, the label language for label printers.

Output: local printing through a queue, WhatsApp and e-mail sending through the channels described in the notifications guide, download, and versioned archive with fingerprint; the file sent is the file archived, and a reprint regenerates nothing. Supervision: the print queue and its errors, printers present per site, reprints and by whom, month-end batches, numbering gaps; the accountant reads the numbers, the manager reads the reprints, per the rights described in the roles guide.

One invoice, from validated order to archived PDF

The invoice is not understood on a template but on its path, in seven stations.

Figure 2 · The invoice is not “printed”, it is issued: an event triggers it, a number is set once in a gapless sequence, its data is frozen, a versioned template renders it as PDF/A with embedded fonts, and its fingerprint is computed before sending and archiving. Ten years later, the archived file is the file sent, and a reprint carries a watermark. Numbers and amounts are an example.

The order is validated: an event, payment confirmed per the payment guide or delivery, triggers the invoice; never a “print” click, because a click can be made twice. The number is assigned: SET-2027-000418, one sequence per branch and per year, gapless, set once and never reused; it is the line the accountant checks first. The snapshot is frozen: lines, prices, addresses, rates at that instant, copied into the document and never reread from the catalogue. Template v3, bilingual, renders it, with its two-script fonts, and the invoice carries the template version number.

The PDF/A is produced with embedded fonts, and its fingerprint is computed before any sending; ten years later the same file opens and the same fingerprint proves it has not changed. It is sent and archived: WhatsApp and e-mail to the customer, versioned and locked storage per the backups guide; the invoice sent and the invoice archived are the same file. The reprint brings out that file with a “duplicate” watermark, and the log says who asked for it and when; it is never regenerated, because an invoice regenerated from data that moved is no longer the same invoice. Numbers and amounts are a constructed example.

«An invoice is not printed, it is issued: an event triggers it, a number is set once, its data is frozen, and the file sent is the file archived.»

Six documents, and the output each one demands

Six documents we build on almost every project, and for each what it must be and how it comes out.

Figure 3 · Six documents, three rendering engines and one rule: the source is a frozen snapshot, the template is versioned, the output is logged. The receipt is the only one that does not wait for the network; the invoice is the only one that must be readable in ten years; the label is the only one a machine reads before a human.

The invoice: bilingual, gaplessly numbered, frozen, readable in ten years; PDF/A with fingerprint, sent by WhatsApp and e-mail, archived, reprinted as duplicate. The receipt: it comes out in two seconds, with or without network, on the till printer; thermal command stream, Arabic as image, local queue, QR to the invoice, drawer if cash. The delivery note: signed by the customer at the door with the parcel photo; PDF generated on the courier’s phone, signature and photo embedded, timestamped, synced when network returns per the synchronisation guide; it is the proof of the delivery platform.

The label: stuck on the parcel or the shelf, read by a scanner, 50 by 30 mm; the label printer’s language, barcode or QR, short text in both scripts, batch of labels per preparation. The quote: dated, with a validity and versions; one PDF per version, v1 v2 v3 kept, acceptance recorded, and the accepted quote becomes the invoice’s base. The monthly statement: one document per customer, generated in a batch on the night of the first, PDF/A per customer, grouped sending, batch errors read in the morning supervision; it is the document the B2B portal sends to every retailer.

The receipt, from till to printer

The receipt is the simplest document and the one that blocks the most tills; six steps get it out.

Figure 4 · The third step is what separates a till that holds from a till that blocks: the receipt waits in a local queue, the printer takes it when ready, and a paper jam does not lose the sale. The last step is what keeps reprints from being invisible.

The sale is validated: the receipt is created in the database with its number, even without network, because the till works offline. It is rendered as commands: Latin text as text, Arabic lines as image, QR code, cut order. It enters the local queue: a queue on the till itself, not on the server; the printer takes it when ready, a paper jam does not lose the sale, and the next receipt waits behind. It goes to the printer: Bluetooth, USB or network, and the printer status is read before sending, paper, cover, error.

Cut and drawer: the cut comes after the QR, never before the last line, and the drawer opens only if payment is in cash, because a drawer that opens on every receipt is a drawer nobody watches any more. The status is written: printed, failed, reprinted and by whom; visible in supervision, so the manager knows how many receipts were reprinted this month and why. The choice between a native and a web application to talk to the printer over Bluetooth is described in the dedicated guide: the printer is one of the criteria that impose native.

The 80 mm receipt, as the printer receives it

What the printer receives is not a page: it is a sequence of commands and images, and each has a reason.

Figure 5 · An 80 mm receipt holds forty-eight characters per line and comes out of a printer that understands a textual command set, Epson’s, which most till printers accept: Latin text goes as text, Arabic lines go as an image because the printer has neither the font nor the shaping, the QR links to the invoice, the cut comes after, and the drawer opens only when paid in cash.

Initialise the printer on every receipt, to start from a known state whatever the previous receipt. Centre, bold, double size for the shop name and the total: Latin text goes as text, because the printer has the font and holds forty-eight columns on 80 mm, thirty-two on 58. Send Arabic lines as an image: most printers have neither an Arabic font nor letter shaping, and an Arabic line sent as text comes out as unknown characters or disconnected letters; the application therefore renders it with its own font, at the right width, and sends it as a monochrome image.

The QR code links to the PDF invoice and the loyalty programme; the customer scans it, and the receipt becomes a door to the full document. The partial cut comes after the QR, never before the last line, because a cut too early separates the total from the rest. The drawer opening is sent only if payment is in cash, and it is logged. The same command stream, replayed from the local queue, produces the same receipt identically, even without network; that is what allows reprinting without regeneration.

«Latin text goes as text, Arabic goes as an image, and the same receipt reprints identically from the local queue, even without network.»

Seen elsewhere: the archiving standard and the printer command set, and what transposes

Two sources say the essentials. The PDF/A standard says an archivable document embeds its fonts, has no encryption, external reference or script, and carries standard metadata; what transposes is that the invoice is produced as PDF/A with both scripts embedded, and its fingerprint computed before sending. Epson’s command set says how you talk to a receipt printer, in text, images and cut orders; what transposes is that the receipt is a replayable command sequence from a local queue, and that Arabic goes as an image because the printer cannot write it.

What these sources do not say: which documents your company issues, who reads them, in which language, and how your accountant wants them numbered; the project’s first week answers that, and the accountant signs the list with the manager.

The rules of a document you can issue without fear

Six rules, written in week one. A document is issued by an event, never by a click. The number is set once, in a gapless sequence per branch and per year. Data is frozen at issue; the document never rereads the catalogue. The template is versioned with its two-script fonts, and the document says which version produced it. The file sent is the file archived, with its fingerprint; a reprint is a marked duplicate. The receipt comes out without network, from a local queue, on the printer that is there.

A seventh rule concerns the quote: “PDF invoice generation and receipt printing” is not a requirement, it is a sentence; the requirement reads “list of documents with reader and language; issue by event; gapless numbering sequences per branch and per year; frozen snapshot; versioned bilingual templates with embedded fonts; PDF/A with fingerprint for kept documents; versioned and locked archive; logged duplicate reprint; receipts as thermal command stream with Arabic as image, local queue, test on every printer present; labels in the label printer’s language; supervised month-end batches”, and it is checked as the specification guide recommends. A quote that writes “PDF export” has planned a button, not a document.

Six companies, and the document that mattered

Six companies we often equip, and for each the document that decided the architecture.

Retail, described in the point-of-sale guide. The 80 mm receipt in two seconds, with or without network, on the three different printers of the three shops; the local queue settled what the server could not.
The wholesaler and its portal, described in the dedicated guide. The monthly statement per retailer, generated in a batch on the night of the first, bilingual, sent by WhatsApp; three hundred PDF/A every month without a hand.
The delivery platform, described in the dedicated guide. The delivery note signed on the courier’s phone with the parcel photo, generated offline and synced at the depot; the proof the customer demands.
Field sales, described in the dedicated guide. The order form printed at the customer’s on a 58 mm Bluetooth printer, thirty-two columns, Arabic as image.
The property developer, described in the dedicated guide. Buyers’ deposit receipts as bilingual PDF/A, numbered, archived ten years and locked; the document a buyer in France will reopen in 2036.
The company migrating, described in the migration guide. The list of documents printed every day by the old software is the first inventory of week one; the new one produces them all before the switch-over, and the accountant compares the numbers.

The 2027 calendar

The calendar is that of an application’s documents delivered in six weeks, the first without a single document generated.

Figure 6 · Six weeks, and the first passes without a single document generated: you write the list of documents, who reads them, in which language, and how they are numbered, because those decisions cannot change once the first invoice is issued. Final acceptance is done on site, on the printers that are there.

Week 0 to 1 takes the inventory and writes the numbering: the list of documents, who reads them, in which language; sequences per branch and per year; templates signed by the manager and the accountant, because those decisions cannot change once the first invoice is issued. Week 1 to 2 builds the PDF engine and the invoice: frozen snapshot, versioned bilingual template, embedded fonts, PDF/A, fingerprint, and the first invoice reviewed by the accountant. Week 2 to 3 handles receipts: rendering as commands, Arabic as image, local queue, and a test on every printer actually present in the shops, not the office one.

Week 3 to 4 handles notes, labels and quotes: signature and photo on the phone, label printers, versions. Week 4 to 5 installs the versioned archive, the marked reprint, WhatsApp and e-mail sending, and the month-end batch. Week 5 to 6 is on-site acceptance: every printer, every document, both languages, and the accountant validating the numbers; it is the acceptance the delivery guide describes, done in front of the machines. When the application must also send its documents to accounting, the integration guide takes over.

What makes an application’s documents fail

The documents we take over almost always failed for one of these reasons.

The PDF regenerated on every click. The price changed meanwhile; the customer’s invoice and the accountant’s no longer say the same thing.
The number set at print time. Two clicks, two numbers; a cancelled click, a gap.
The font not embedded. Boxes instead of Arabic on the customer’s machine.
Arabic sent as text to the printer. Unknown characters or disconnected letters on the receipt.
The receipt waiting for the server. The network drops, the till blocks, the queue at the counter grows.
Tested on the office printer. The three shops have three models, and two do not cut in the same place.
The invisible reprint. The same receipt printed five times, and nobody knows why.

Frequently asked questions

The questions we receive from shopkeepers, managers and accountants.

Why does the receipt not come out of our till printer?: Most often because the application talks to the printer as to a page, or not at all: a receipt printer expects a sequence of commands, text, images, cut, over Bluetooth, USB or network, and it has no Arabic font. We build the rendering as commands, Arabic as image, a local queue on the till, and we test on every model actually present in the shops, not the office one.
Why does the PDF invoice show boxes instead of Arabic?: Because the Arabic font was not embedded in the file: the PDF pointed to a server font, and the customer’s machine does not have it. An invoice produced as PDF/A embeds all its fonts, both scripts included, and opens as is in ten years on any machine; it is the archiving standard, and what we produce by default.
How do you guarantee gapless numbering?: The number is set by the server at the moment the event issues the document, in a sequence per branch and per year, once; it is never assigned by a “print” click, which can be made twice or cancelled. A cancellation produces a numbered cancellation document, not a gap. The accountant sees the sequence and its gaps in supervision.
What happens when an invoice is reprinted?: The same archived file comes out, with a “duplicate” watermark, and the log says who asked and when. It is never regenerated from the data, because prices or the address may have changed since: the invoice is a photograph taken at issue time, and its fingerprint proves the file has not moved.
Does the receipt come out if the network is down?: Yes. The sale is recorded on the till, the receipt is rendered as commands and enters a local queue on the till itself, the printer takes it when ready, over Bluetooth or USB; nothing goes through the server. Synchronisation happens when the network returns, and the receipt number stays unique because the till has its own sequence.
How long to set up the documents?: Six weeks: one for the inventory and numbering with the accountant, one for the PDF engine and the invoice, one for receipts on the real printers, one for notes, labels and quotes, one for the archive, reprint and sending, one for on-site acceptance. The first week passes without a document generated, because its decisions cannot change afterwards.