Skip to Content

Lesson 6 — The archive, the hash, and the cost of regenerating

The specification says the user must not be able to modify any value in the file. Odoone honours that after the fact as well as at the moment of writing: every Generate & Download stores an immutable archive record alongside the download, so the file that left your system is still described inside it.

The click path. Past exports live at Accounting → Configuration → FTA Audit File (FAF) → Generated FAF Files. Open one and you see its SHA-256 hash — a 64-character fingerprint of the exact bytes — together with the per-section counts and control totals. The file name embeds the TRN and the period, so an auditor can tell at a glance which registrant and which quarter they are holding.

Two permission statements have to be read together before you set anyone up. A User can view archived files and the tax-code mapping, and the configuration submenu that holds both is visible to Managers only. If someone needs to reach the archive from the menu as part of their routine work, give them Manager; a User who only ever runs the wizard, previews and downloads does not need it.

Regeneration is a Manager action and it has a consequence worth stating in one sentence, because it is the thing this lesson exists for. Regenerating creates a fresh hash and drops the previous file. Not a new version alongside the old one — the earlier file is gone, and with it your ability to reproduce the bytes whose hash you may already have quoted to someone.

Follow it through. Al Quoz generated its Q2 file on 5 July 2026 and sent it to the FTA. On 19 July a colleague posted a backdated June invoice, and a manager, being helpful, regenerated the file so the archive "matched the books". The archive now holds a 19 July file with a 19 July hash. The file the FTA is reading was produced on 5 July, and nothing in the system can now prove what it contained.

Generated 5 July 2026 Generated 19 July 2026
SHA-256 hash the hash you quoted a different hash
Still in the archive no — dropped on regeneration yes
Held by the auditor yes no

So build three habits and the problem disappears. Record the SHA-256 hash and the generation date at the moment you send a file, in whatever you use to log correspondence. Keep the exact bytes you sent outside the system as well as in it. And when the underlying data genuinely has changed, regenerate deliberately, then tell the auditor plainly that a second file exists for that period and which of the two you are asking them to read.

The failure mode: two files for one period, told apart by nothing. The file name embeds the TRN and the period, so a regenerated file is named like the one it replaced — same registrant, same quarter, same filename shape. The hash and the generation date are the only things that distinguish them, which is a good reason to record both before anyone is tempted to press Regenerate.

Commenting is not enabled on this course.