When Tunisia's tax authority publishes a TTN or TEIF schema change, Hesabi customers should not discover it only because clearance failed on a Friday afternoon. DarDev runs an internal TTN update watch: we track regulatory notices, reproduce changes in a controlled environment, ship tested releases on hesabi.tn, and notify finance teams before mandatory cutover dates. This article explains that pipeline—process, testing, and customer communications—so PME owners and accountants know what to expect when compliance rules move.
Hesabi is built for Tunisian VAT, TEJ-oriented exports, and TTN El Fatoora workflows on hesabi.tn—Tunisia-only today. We write from production operations, not hypotheticals. Binding tax interpretation still belongs to your expert-comptable or DGI advisor; our job is to ship software that matches published technical requirements on a documented schedule.
What TTN update watch monitors
Regulatory change arrives through several channels: official TTN portal bulletins, TEIF XSD or validation rule updates, clearance error patterns that spike across customer workspaces, and feedback from accountant partners who see the same rejection code in multiple cabinets. The watch owner—product plus platform engineering—maintains a single internal changelog keyed by effective date, affected invoice types, and whether action is informational or blocking.
- Schema and field validation changes (mandatory elements, code lists, QR metadata)
- Clearance endpoint behavior (timeouts, new error codes, retry semantics)
- Certificate and enrollment prerequisites that block submission
- Export formats accountants rely on for TEJ and monthly closes
We classify each bulletin as hotfix, scheduled, or advisory—that drives testing depth and how loudly we communicate.
From spec diff to Hesabi release
Once a change is confirmed, engineering branches from the current Hesabi production baseline—not from experimental features. The diff is scoped: mapping layer for TEIF XML, validation rules in the invoice editor, clearance client, PDF and audit exports. We avoid bundling unrelated product work into compliance releases so rollback stays one revert, not a forensic exercise.
- Parse and trace
Link each regulatory requirement to a ticket: which screens, API calls, and export jobs touch the field or rule.
- Implement behind flags
New validation or clearance behavior ships toggled off in staging until regression passes.
- Staging clearance
Run sample invoices—including edge cases from ttn-submission-errors playbooks—against TTN test paths where available.
- Production rollout
Enable flags per environment; monitor clearance success rate and support queue for 48 hours after go-live.
- Post-release audit
Update internal runbooks and public help articles; archive before/after TEIF samples for accountant review.
If you are new to El Fatoora mechanics, our TTN El Fatoora SME guide explains enrollment and clearance vocabulary—the update watch assumes that baseline and focuses on how we ship when the rules themselves change.
Testing before customers feel it
Compliance testing is boring on purpose. Automated suites cover TEIF generation: required parties, tax lines, currency formatting, and signature hooks. Manual scenarios include credit notes, partial corrections, multi-rate lines, and invoices created on mobile then cleared from finance roles—the paths that break when a new mandatory attribute appears mid-quarter.
We replay anonymized failure payloads when DGI adds error codes, and re-check audit exports so accountant handoffs still match hesabi-audit-trails-exports after clearance changes.
How we communicate TTN changes
Customer communications follow the severity tier. Advisory updates land in release notes and the news archive on news.dardev.net. Scheduled mandatory changes trigger in-app banners for workspace admins, email to registered finance contacts, and—where customers opted in—product update messages routed through our CRM-to-newsletter pipeline on send.dardev.net (never from @dardev.net marketing domains).
- Effective date and whether action is required before that date
- What changes in the invoice UI or clearance flow
- Whether existing cleared invoices are unaffected
- Link to step-by-step verification (test invoice checklist)
- Support channel if clearance errors persist after deploy
Cabinet partners get portfolio-level notes when a rule spans client workspaces. We never auto-migrate master data that changes legal meaning without admin confirmation.
What your team should do when we announce
Assign an owner, read the effective date, refresh master data if new fields are mandatory, and submit one test clearance before peak invoicing. When clearance fails after a deploy, capture error text and invoice UUID—our TTN submission errors guide maps common codes to fixes.
Questions about a notice or post-release regression? Contact hesabi.tn support or news.dardev.net—we route TTN issues to the engineering queue that owns update watch.
How fast does Hesabi ship after a TTN bulletin?
Hotfixes target hours to days when clearance breaks; scheduled dates get releases before the mandatory window when the spec is stable.
Will you auto-update my historical invoices?
No. Cleared invoices stay as issued; updates affect new submissions and corrections per published rules.
