DarwinX - Anticipated, or improvised?

Legal compliance · reading the scheme's own text

Anticipated, or improvised?

Before building anything on top of a public scheme, one question decides whether you are implementing it or inventing beside it: does its own text already provide for what you are about to do? Answering it honestly means reading the requirements rather than the summary, and being willing to find both answers in the same document.

anticipated · we are inside the text

Offline operation, event tracing, archival

All three are provided for explicitly, in detail, with their own requirement numbers. Anyone building here is implementing the scheme, not extending it. Twelve references, listed below.

improvised · the text is silent

How the archive travels, and how fast it can be produced

No transport is specified and retrieval latency is never addressed - yet latency is the property the archival requirement actually cares about. Ours to decide, and it should be argued rather than quoted.

1 · what the text explicitly provides for

Twelve references, and none of them ambiguous

Ref	What it establishes
`H0102`	each ticket is associated with a unique identifier issued by the platform, and the module must assure this in two modes
`H0105`	electronic signature in offline mode, using an identifier from the last batch retrieved
`H0106`	synchronisation after offline use: authenticate, transmit everything recorded while disconnected, record what returns
`H0108`	local storage support, plus an encryption mechanism for stored data
`E0901`	trace every operation and event - mode hors connexion named explicitly, beside access, encaissement, archivage, purge, sauvegarde, restauration and unavailability
`E1205`	counters continue to increment without being reset to zero; the value is stored at each cloture
`E1301`	an archive covers no more than one year or one fiscal exercise
`E1302`	open format, timestamped, exploitable without the originating software
`E1304`	archives conserved so the data is available during a fiscal control, throughout the regulatory period
`E1402`	purge may not delete cumulative data or operation traceability
`E1601`	backup and restore, where they exist, are each recorded in the traceability
`E1702`	a manual describing how to save into archives on an external removable support connected to the till

Read together, this is not a scheme that tolerates disconnection. It is one that designed for it. Two modes named inside a single requirement, offline signature given its own procedure, post-offline synchronisation given another, and offline mode itself listed as a traceable event. Nobody building an offline path here is improvising.

2 · the layer above

The decree carries the obligation the technical text implements

Art. 3 — defines the caisse enregistreuse installed at the enterprise, and the module de caisse enregistreuse

Art. 5 — which transactions require the register, proforma and refund operations included

Art. 6 — the characteristics the register must carry

Art. 9 — the competent services fix the list of accredited suppliers, and the conditions they must meet

Art. 13 — the enterprise must obtain an electronic certificate for each register used, from an accredited supplier

Art. 14 — every user, whatever their function, must have a specific identifier permitting identification

Art. 15 — the register must be used in a permanent manner

Art. 16 — technical failures repaired exclusively by accredited suppliers; the enterprise informs the competent services

Art. 17 — sanctions

Art. 18 — classification criteria, and the deadlines for bringing into conformity

Article 15 is the one to hold beside the offline question. A permanent obligation to use the register, in a country where coverage is not permanent, is precisely what forces the scheme to provide an offline mode rather than treat disconnection as an excuse. Article 15 and H0105 are only consistent with each other because H0105 exists. That is the clearest evidence in the whole document that offline was designed rather than conceded.

3 · where we are improvising

The text says what the archive must be, never how it moves

Three things the requirements establish, and one they do not:

established

What an archive is

Open format, timestamped, bounded to a year or an exercise, exploitable without the software that produced it.

established

How long it must last

Available in the event of a fiscal control, throughout the regulatory period.

not established

How it travels, and how fast it comes back

No transport is named. Retrieval latency is never addressed - and latency is exactly what E1304 depends on in practice. A control visit does not wait.

So bulk transfer, remote archival and fast retrieval are engineering choices made to satisfy E1301, E1302 and E1304 - not requirements quoted from the text. Presenting them as mandated would be the same overreach this whole series exists to reject. E1702 points at a removable support connected to the till, which is what production adopted, and which fails the inspector who asks for eleven months.

4 · why the transport choice is not neutral

One property, on one object

I keep a small FTP transfer client of my own, built directly on the .NET FtpWebRequest and WebClient APIs: connect, list the remote directory, upload, download, credentials supplied at runtime. I reopened it today for exactly this question.

// what it sets
request.Method      = WebRequestMethods.Ftp.ListDirectoryDetails;
request.Credentials = new NetworkCredential(user, pass);
request.UsePassive  = profile.ConnPassiveMode;

// what it never sets
request.EnableSsl   = true;   // absent - plain FTP

credentials and payload cross the network in the clear

As a demonstration of the protocol that is entirely fine, and it was written to demonstrate the protocol. As a transport for a taxpayer's entire day of trade it is not, and the difference is one property on one object. That is the whole argument for treating transport as a decision made deliberately, rather than inherited from whatever already worked.

the verdict, in two sentences

Inside the text on offline. Outside it on transport.

Not improvising on offline operation, event tracing or archival: the scheme anticipated all three in detail, and anyone building there is implementing its provisions. Improvising on how the archive travels and how quickly it can be produced during a control - a real gap, ours to close, and one that should be argued on engineering merit rather than quoted as compliance.

Requirement references and decree articles are read from the published text. The verdict, the tables and the transport argument are mine. No implementation was examined to produce this page, and no figure here belongs to any named product or counterparty.