Paraguay SUACE Formulario N°1 — Apertura y/o Formalización de Empresa Unipersonal y EIRL (Business Formalization, Individual/EIRL)

Candidate selection

GOV-4435 ("GovSchema Standard Research", child of GOV-4433). The GOV-4424 cycle scouted Paraguay as a brand-new jurisdiction alongside Namibia and Tajikistan and found it the strongest of the three (4 of 6 verticals STRONG — Taxes, Business Formation, DMV, Visa — the strongest new-jurisdiction showing since Botswana; see CATALOG.md's Known Gaps entry 0i). Taxes was authored first as GOV-4427 (py/dnit/individual-income-tax-return@1.0.0, opening Paraguay as the registry's 85th jurisdiction); this issue authors Business Formation as Paraguay's second vertical (2 of 6), via the SUACE Formulario N°1 candidate the same scouting cycle already banked. DMV and Visa remain open STRONG backlog for future cycles; Passport/National ID (cédula) are confirmed dead ends per the scouting cycle's own findings.

Reaching the live source

The scouting cycle's own note already gave the exact document URL and byte count; both were independently re-verified rather than trusted at face value:

• https://suace.gov.py/wp-content/uploads/2020/02/FORMULARIO-FISICA-03.02.2020.pdf
• HTTP 200, Content-Type: application/pdf, 4,295,121 bytes — matching the banked figure exactly.
• No login, CAPTCHA, or WAF gate — a plain unauthenticated curl request with no session/cookie state reached it cleanly.
• sha256 6f7871d378138220cec3f66856a42180ce53b999036c00f6cf70099844bac02c.

Extraction method

Extracted with pdfjs-dist (vendored at /tmp/node_modules/pdfjs-dist, CommonJS build at legacy/build/pdf.js). getAnnotations() found 80 /Widget annotations on page 1 and 46 on page 2 (126 total) — a genuine AcroForm specimen, but one built by a form-authoring tool (the naming pattern strongly resembles LibreOffice's auto-generated field names) that assigns each widget a meaningless auto-incrementing name (Texto1, Casilla de verificación1_12_12, etc.) with zero semantic relationship to what the field actually captures.

Because field names carried no signal, every widget had to be correlated to its meaning geometrically: getTextContent() read every text item's raw string and its transform x/y position across both pages, and a purpose-built correlation script joined each widget's rect midpoint against the nearest text on the same row (for inline value boxes) and the nearest text above it (for section/row headers). This is the same x/y-position + geometric-join technique this registry has used on other auto-generated or non-standard AcroForm specimens (e.g. kg/gns/unified-tax-declaration, ge/napr/llc-founding-agreement).

Several groupings were genuinely ambiguous from x/y position alone and were resolved by rendering both pages to 2.5x-scale PNGs via pdfjs-dist + node-canvas and visually inspecting the result (with a further zoomed-in crop for the Section 10 Tipo de Documento row specifically):

• Whether the "Tipo de Dirección" row's second line of checkboxes (Interior/Departamento/Casa/Oficina) was a continuation of the same field as the first line (Avenida/Calle/Autopista/Carretera/Callejón) or an independent second field — the rendered image showed no independent header or asterisk introducing the second line, confirming it is one field (see Disclosed Finding 2 below).
• Whether "ACTIVIDAD ECONÓMICA SECUNDARIA" printed one Código/Descripción row or two — the raw text extraction showed two candidate row-groups only ~15pt apart, which the rendered image confirmed are two distinct, full-width printed input boxes (see Disclosed Finding 3).
• Whether Section 10's "Cédula de Identidad" and "Pasaporte" checkboxes carry their own adjacent number boxes the way Section 3 and Section 9's equivalent rows do — a zoomed crop of the rendered row confirmed only "Carnet de Migración" has a number box in this section; the other two are checkbox-only (see Disclosed Finding 4).

Document structure

Page 1: Section 1 (Tipo de Trámite: Apertura/Formalización), Section 2 (Tipo de Empresa: Persona Física/EIRL, plus RUC N°), Section 3 (Datos Personales — name, birth date, nationality, one of three ID-document types with its own number box, primary email, Razón Social/Nombre Fantasía), Section 4 (Domicilio Fiscal — administrative address fields plus a combined 9-value Tipo de Dirección), Section 5 (Datos de Constitución EIRL, printed "Completar solo en caso de EIRL", plus an unmarked-required Datos del Escribano sub-block), Section 6 (Actividad Económica Principal — required — and Actividad Económica Secundaria — two optional Código/Descripción slots), Section 7 (Operaciones — Importador/Exportador checkboxes), and Section 8 (Obligaciones Tributarias, printed "Completar solo en caso de Apertura de la Sociedad" — a start date, a closing-month choice, and an 11-row tax-regime checkbox grid each with its own "Fecha desde" date).

Page 2: Section 9 (Datos del Representante Legal — a full identity/contact/backing-document block, structurally a near-duplicate of Section 3's ID-document pattern but with all three of its own number boxes present), Section 10 (Gestor Autorizado o Persona a Notificar — see Disclosed Finding 4 for its incomplete ID-number boxes), Section 11 (Información Patrimonial de la Empresa/MIPYMES — Total Activo/Pasivo Patrimonial, expressed in guaraníes), Section 12 (Observaciones — a printed Ley 132/98 copyright-declaration jurat and a Código Penal Paraguayo Art. 243 false-declaration jurat, with zero associated widgets), an unnumbered "Solicitante por la Empresa" signer block (name, ID type/number, role, and a physical "Firma" line with no AcroForm field behind it), and a "PARA USO EXCLUSIVO DEL SUACE" office-use block (mesa de entrada number, reception date/time, approval date, reception staff name/signature).

Scope: excluded blocks

• Section 12 ("Observaciones") — a printed jurat/legal-notice block with zero associated widgets; there is nothing to model.
• "PARA USO EXCLUSIVO DEL SUACE" — internal government tracking data (mesa de entrada number, reception date/time, approval date, reception staff name/signature) supplied by SUACE personnel after submission, not applicant input. The same class of exclusion this registry's py/dnit/individual-income-tax-return (Finding 5) and jm/taj/individual-income-tax-return (Finding 8) already draw around their own "for official use" blocks.
• The "Firma" line in the "Solicitante por la Empresa" block — no AcroForm widget exists behind it, consistent with the form's own printed instruction that it "deberá llenarse en forma electrónica, impresa y firmada por el representante legal" (must be filled electronically, then printed and signed by hand).

Disclosed findings and interpretation choices

1. Three separate applicant/representante-level ID-document number boxes are collapsed into one documentNumber/representanteDocumentNumber field each, rather than modelled as three parallel visibleWhen-gated fields. The source prints an independent number box directly after each of C.I. N°, Pasaporte N°, and Carnet de Migración N° in both Section 3 and Section 9, but exactly one is ever filled in per submission (whichever documentType/representanteDocumentType is checked) — the same collapsing this registry's at/bmeia/schengen-visa-application already applies to its own travelDocumentType/travelDocumentNumber pair for an analogous single-choice-of-N-document-types row.
2. tipoDireccion is modelled as a single 9-value enum, not two separate fields, even though the source prints its nine options (Avenida/Calle/Autopista/Carretera/Callejón, then Interior/Departamento/Casa/Oficina) across two visual rows. Rendering the page to an image confirmed there is no independent header, asterisk, or field label introducing the second row as anything other than a continuation of the same "*Tipo de Dirección" field above it — this registry's own "spec precision over cleverness" convention favors one field over a speculative two-field split the source itself does not indicate.
3. Actividad Económica Secundaria is modelled as two independently-named Código/Descripción slots (actividadSecundaria1*/actividadSecundaria2*), confirmed by rendering the page to an image after the raw x/y text extraction showed two candidate row-groups only ~15pt apart under one "ACTIVIDAD ECONÓMICA SECUNDARIA" header — the rendered image confirmed two full-width printed boxes, not one wrapped/duplicate box. Neither slot carries a required marker (unlike Actividad Económica Principal's own required Código/Descripción, which the source marks with asterisks).
4. Section 10's gestorDocumentType has a value box only for Carnet de Migración (gestorCarnetMigracionNumero, requiredWhen carnet-migracion) — Cédula de Identidad and Pasaporte print only a checkbox each, with no adjacent number field, confirmed both from the raw widget/text correlation (no Tx widget in that x-range at that y-band) and from a zoomed-in crop of the rendered page. This is a genuine gap in the source form itself (unlike Sections 3 and 9, which give all three document types their own number box) and is modelled faithfully rather than papered over with an invented field.
5. fechaInicioActividadesEirl (Section 5) and fechaInicioActividadesApertura (Section 8) are two distinct fields sharing the identical printed label "Fecha de inicio de actividades" under two different conditional sections ("Completar solo en caso de EIRL" vs "Completar solo en caso de Apertura de la Sociedad") — kept separate rather than merged, since a Formalización-EIRL filer and an Apertura filer are answering genuinely different questions even though the printed words are identical.
6. Each of the 11 Section 8 tax-regime rows is modelled as an independent boolean plus its own requiredWhen-gated FechaDesde date, rather than a single multi-select field, since spec v0.3's enum type is a flat scalar with no array/multi-value construct (the same constraint this registry's kg/gns/unified-tax-declaration and py/dnit/individual-income-tax-return already work within). No exclusivity constraint is asserted across the 11 regimes (e.g. IRE GENERAL vs IRE SIMPLE vs IRE RESIMPLE) since the source form itself prints them as independent checkboxes with no radio-button grouping or explicit mutual-exclusivity marker.
7. totalActivoPatrimonial/totalPasivoPatrimonial are modelled type: integer with validation.minimum: 0, since the Paraguayan guaraní (ISO 4217 PYG) has no minor currency unit (exponent 0) — the same guaraní-amount convention this registry's py/dnit/individual-income-tax-return already applies, though that schema's own source additionally prints an explicit "sin céntimos" instruction this SUACE form does not.
8. Section 12 and the "PARA USO EXCLUSIVO DEL SUACE" block are excluded in their entirety and the "Firma" line has no field behind it — see "Scope: excluded blocks" above.

Conformance

3 valid mock scenarios:

• valid-apertura-persona-fisica-single-regime — an Apertura filing for a Persona Física with one Section 8 tax regime selected (700 - IRE GENERAL) and no EIRL-only fields.
• valid-formalizacion-eirl-full-constitucion — a Formalización filing for an EIRL exercising every Section 5 constitution field, the Escribano sub-block, both secondary economic activities, and a Carnet de Migración gestor.
• valid-apertura-eirl-multi-regime-otros-respaldo — an Apertura filing for an EIRL selecting three Section 8 regimes with three FechaDesde dates, and a representante Documento de Respaldo of otros exercising the conditional Especificar field.

9 mutation-control fixtures (one missing statically-required field each from tramiteType, businessType, ruc, fullName, documentType, documentNumber, primaryEmail, actividadPrincipalCodigo, totalActivoPatrimonial) and one unknown-field-rejected fixture, all committed under conformance/py/suace/business-formalization-individual/1.0.0/.

An ephemeral, from-scratch conformance checker (deriving required/requiredWhen rules directly from this schema's own fields[], discarded after use, not committed) ran all 13 fixtures: all 3 valid scenarios at 0 errors, all 9 mutation controls each raising exactly 1 error, and the unknown-field fixture correctly rejected.

Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs, individually and as part of the full registry run. registry-index.json regenerated via npm run build-index in tools/govschema-client/.