Tunisia Declaration of Existence (تصريح بالوجود)

Candidate selection

GOV-4659 ("GovSchema Standard Research"). GOV-4638 (a prior cycle of the same recurring routine) scouted Tunisia's Business Formation candidate as STRONG: "a 'Déclaration d'existence' tax-registration-trigger form, finances.gov.tn, 254KB — the Registre National des Entreprises' own site offers only document checklists, not a fillable form" — but banked it rather than authoring it, since that cycle's scope was the new-jurisdiction opening itself (Tunisia's Passport vertical, via a companion DGSN form). This cycle re-scouted and independently re-fetched the candidate before authoring it, opening Tunisia's Business Formation vertical (3 of 6: Passport, National ID, now Business Formation). Tunisia's remaining two verticals (Taxes, Visa — both scouted STRONG or near-STRONG by GOV-4638) and DMV (weak) are unchanged open backlog.

Reaching the live source

Found via web search for the form's own Arabic/French name, landing on the Ministry of Finance's own document page, https://www.finances.gov.tn/fr/document/declaration-dexistence-0, which links the PDF at a site-relative path.

• Plain unauthenticated curl request (realistic desktop User-Agent header; -k to skip TLS verification, no session/cookie state, no CAPTCHA/WAF challenge).
• Direct PDF URL: https://www.finances.gov.tn/sites/default/files/2019-08/dclaration_dexistence_contribuable_0.pdf — HTTP 200, 254,216 bytes retrieved, matching GOV-4638's own banked estimate ("254KB") almost exactly.
• sha256 of the retrieved bytes: 6387c21130005c29b5a44a1c5696a46a0b637e65666edfca54cea30fe1199add.
• 2 pages, confirmed via pdfjs-dist's numPages.
• getAnnotations() returned 0 annotations on both pages — a flat, print-and-fill specimen, not an interactive AcroForm.

Authority attribution

Page 1's own header carries two seals side by side: "الإدارة العامة للأداءات / DGI / DIRECTION GÉNÉRALE DES IMPÔTS" (top-left) and "الجمهورية التونسية / وزارة المالية / MINISTÈRE DES FINANCES" (top-right). authority is modelled as the Direction Générale des Impôts, abbreviated DGI, under the Ministry of Finance — a new authority for this registry's Tunisia entries (the existing Passport and National ID schemas are both DGSN, Ministry of the Interior). finances.gov.tn is modelled as both the issuing authority's own domain and the hosting portal (unlike the DGSN forms, which are hosted on the multi-ministry sicad.gov.tn portal).

Extraction method

pdfjs-dist's getTextContent() extracted a text layer on both pages, but unlike every prior Tunisian specimen in this registry, the extracted string order did not reassemble into readable Arabic — words and letter clusters came back visually scrambled (e.g. a line that should read "تسجيل القانون الأساسي" extracted as disordered fragments). This is a distinct PDF-extraction failure mode from this registry's other three documented patterns (missing ToUnicode CMap on Cyprus's EE1; zero-text-layer vector checkboxes on Belgium's passport form; clean RTL extraction needing only right-to-left reading-order resolution on Tunisia's own DGSN forms) — here the text layer exists and decodes to real Unicode Arabic codepoints, but the glyph-paint order embedded in this specimen's content stream does not correspond to logical reading order strongly enough to reconstruct the source by string manipulation alone.

Resolution: the same node-canvas-at-3x-scale rendering technique this registry has used before for checkbox-layout confirmation was used here as the primary reading method, not a supplementary one — every field label, checkbox group, and footnote below was read directly off the rendered PNG (/tmp/decl-page1.png, /tmp/decl-page2.png during this cycle's own session), not off the raw getTextContent() string order. This is a new circumstance for this registry's Tunisian sources: prior DGSN forms could be extracted and read directly from the text layer; this DGI form requires the rendered image as the authoritative reading, with the text layer serving only as confirmation that genuine Arabic Unicode text (not a private-use-area font encoding) underlies the visible glyphs.

Document structure

Page 1 — header (DGI seal, form title "تصريح بالوجود", Ministry of Finance seal); a declaration-nature checkbox pair (أوّلي / تحيين) plus a declaration-code box; an office/category code block (رمز المصلحة, رمز الفرع الثانوي, رمز الصنف, رمز الأداء على القيمة المضافة, المعرف الجبائي); an identity-numbers block (رقم الانخراط في الضمان الاجتماعي; رقم بطاقة التعريف الوطنية أو رقم بطاقة الإقامة للأجانب أو رقم جواز السفر با its own code/number/issue-date columns; رقم السجل التجاري; المحكمة); then the main applicant-facing body: name/company-name; business-activity address; phone/ fax/nationality/legal-form/activity-start-date; exchange regime; share capital; founding-act registration reference; natural-person birth details (date of birth, sex); primary and secondary business activity (each with its own code and start date); the natural-persons-only tax-regime election block (two income-category groups, each with its own regime checkboxes); VAT status and election dates; personal/registered-office address; elected notification address; secondary-branches question; two tax-incentive entries; an incentivized-activity location/headcount block; and the fiscal year-end date (month/year only).

Page 2, headed "خاص بالأشخاص المعنويين" (specific to legal persons) — a "هوية الممثل القانوني للشركة" (identity of the company's legal representative) table with two printed rows; a "هوية صاحب المؤسسة بالنسبة لشركات الشخص الواحد ذات المسؤولية المحدودة" (identity of the founder, for single-member LLCs/SUARL) table with one printed row; the closing attestation ("إني الممضي أسفله... أصرّح بصحة البيانات...") with place/date blanks and a stamp-and-signature line; and a block of unnumbered footnotes (referenced throughout both pages by a bare "( )" marker, not a numbered superscript system) spelling out who must file this declaration, the identity-code vocabulary, the VAT-status vocabulary, the legal-representative-capacity vocabulary, and which boxes are administration-only.

Scope: the isLegalEntity discriminator

This form has no single explicit checkbox toggling between a natural-person and a legal-person filing — instead, page 1 prints natural-person-specific fields (date of birth, sex, the natural-persons-only tax-regime block) alongside fields that read naturally for either kind of declarant, and page 2 is headed specifically "خاص بالأشخاص المعنويين" (specific to legal persons). This schema introduces isLegalEntity (boolean) as its own discriminator, matching this registry's own isBodyCorporate precedent (see zm/pacra/company-incorporation) for forms that print natural-person and legal-person sections side by side with no explicit either/or signal. individualFirstName/individualFamilyName are requiredWhen isLegalEntity equals false; companyName and every page-2 legal-representative field are requiredWhen isLegalEntity equals true.

Scope: sections and fields excluded from v1.0.0

• The office/category code block (رمز المصلحة, رمز الفرع الثانوي, رمز الصنف, رمز الأداء على القيمة المضافة, المعرف الجبائي on a genuine initial filing) is excluded — one of this block's own footnotes reads "قسيمة تتولى تعميرها الإدارة" (box completed by the administration), confirming at least رمز المصلحة is office-assigned; the remaining codes in the same visually-grouped block are excluded on the same reasoning (categorization/VAT-registration codes assigned once DGI processes the filing, not entered by the applicant at intake). المعرف الجبائي is re-admitted as existingTaxId, but only for UPDATE-nature filings, where the taxpayer already holds one and must supply it to identify their file.
• رمز التصريح ( ) is not excluded with the block above — a distinct footnote ("تلقائي - اكتشاف", spontaneous / discovered-by-audit) ties it to a genuine two-value classification of why this declaration is being filed, modelled as declarationTrigger. Whether this box is completed by the taxpayer or by the processing officer is not stated by the source; it is modelled optional (not required) to avoid overclaiming either reading.
• The single-member-LLC (SUARL) founder-identity table on page 2 is excluded from v1.0.0 — it applies only to the subset of legal entities organized specifically as a SUARL, a distinction this schema's legalForm free-text field does not structurally capture, and gating it on isLegalEntity alone would wrongly require it for every company. Banked as an open companion-schema/minor-version candidate for a future cycle.
• The second legal-representative row (page 2's own table prints two) is excluded from v1.0.0 for the same reason as prior bounded-repeating-group precedents where the source gives no companion "number of representatives" count field to gate a second slot's requiredness on — banked as the most likely next PATCH/minor-version candidate, alongside the SUARL block above.

Scope: judgment calls on requiredness and modelling

This source has no global asterisk/mandatory marking convention (the several bare "( )" markers throughout are footnote references, not required-field indicators), so requiredness was assigned by engineering judgment:

1. declarationNature required — the applicant must indicate whether this is an initial filing or an update to an existing one.
2. Core identity/address fields modelled required (individualFirstName/individualFamilyName/companyName per the isLegalEntity gate; activityStreet/activityCity/ activityGovernorate/activityDelegation; nationality; activityStartDate; exchangeRegime; headOfficeStreet/ headOfficeCity/headOfficeGovernorate/headOfficeDelegation; hasSecondaryBranches; primaryActivity; declarationDate; applicantSignature) — the minimum data DGI needs to register any declarant and route correspondence.
3. nationality modelled as a two-value enum, not free text — a page-2 footnote ("الرقم بالبلاد التونسية - الجنسية - تونسية - أجنبية") confirms this box is a Tunisian/Foreign checkbox, not a nationality-name field.
4. vatStatus modelled as a three-value enum — a page-2 footnote ("إجباري - جزئي - اختياري") confirms this box's vocabulary is mandatory/partial/optional VAT liability, not free text.
5. representativeCapacity modelled as a three-value enum — a page-2 footnote spells out "رئيس مدير عام" / "وكيل" / "ممثل قانوني آخر" verbatim.
6. legalForm modelled as free text despite a "specific to companies" footnote — the footnote ("خاص بالشركات") confirms this box's audience but names no closed vocabulary of legal forms anywhere on the source.
7. shareCapital/legalForm gated requiredWhen isLegalEntity — capital and a formal legal form are meaningful only for an incorporated entity, not an individual professional or sole trader filing under this same form.
8. The tax-regime block (taxRegimeCategory/professionalTaxRegime/ commercialTaxRegime) gated requiredWhen isLegalEntity equals false — this block's own printed header reads "النظام الجبائي بالنسبة إلى الأشخاص الطبيعيين" (tax regime for natural persons), an explicit audience restriction rather than this registry's own inference.
9. professionalTaxRegime/commercialTaxRegime each gated on taxRegimeCategory rather than modelling one combined enum, since the source prints two structurally distinct checkbox groups (professional income vs. industrial/commercial income), each with its own regime vocabulary that would otherwise collide in a single flat enum.
10. tradeRegisterNumber/court left unconditional-optional, not gated on isLegalEntity — the source's own filer list includes "every natural person who practices an activity subject to control by a professional body," a category that is not necessarily commercially registered; conversely not every company detail is known to require this pairing disclosed independent of entity type. Modelled optional for either path.
11. fiscalYearEndDate modelled as a string, not this schema's date type — the source prints only month and year boxes for this one field (every other date on the form prints day/month/year), and this schema's date type implies day-level precision the source does not carry.
12. The incentivized-activity location/headcount block's tie to the tax-incentives section above it is this registry's own reading, not an explicit source label — disclosed in the field-level description fields rather than asserted as certain.
13. notEquals "" is never used as a requiredWhen gate against an optional field, per this registry's own standing lesson (see the notequals-empty-string-absent-field-bug reference) — every gate in this schema keys off a boolean or enum field's own discrete value.

Conformance

4 mock scenarios (2 positive, 2 negative) were run programmatically via a small one-off Node script evaluating this schema's own fields[]/ documents[] requiredWhen conditions directly (not committed as fixture files, following this registry's own precedent for single flat-PDF schemas): (1) an individual non-commercial professional (a lawyer) electing the real regime, no secondary branches — 0 errors; (2) a legal entity (SARL) with two secondary branches, its legal representative, and the branch-list document attached — 0 errors; (3) a negative case, the same company omitting both the now-required branch-list document and the representative's first name — correctly flags exactly those two errors, nothing else; (4) a negative case, a legal entity omitting companyName — correctly flags it, and does not spuriously require any natural-person-only field. Every requiredWhen gate in this schema (isLegalEntity, declarationNature, taxRegimeCategory, hasSecondaryBranches) was exercised true and false at least once across the four scenarios.

Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (ajv 2020-12 against spec/v0.3/govschema.schema.json). registry-index.json regenerated via npm run build-index in tools/govschema-client/.

Models 85 fields[] across 14 steps, 1 documents[] entry.