Dominican Republic DGII Sworn Declaration of Motor Vehicle Transfer (Declaración Jurada de Transferencia de Vehículos de Motor, Formulario FI-VHM-308)

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-15

Why this schema and why now (GOV-3166)

GOV-3152 (2026-07-15) independently scouted and live-verified all four of the Dominican Republic's then-remaining verticals in parallel with authoring tz/nida/application-form-2a. GOV-3158 picked up the Passport candidate (do/mirex/passport-application) and delegated the other four as standalone child issues, disclosing this candidate's source URL, its two-option choice (FI-VHM-308 vehicle-transfer vs. GRCIV-011 vehicle-removal), and a confirmed dead end (INTRANT driver's-license first-issuance, SSO-gated). This cycle (GOV-3173) picked up GOV-3166 directly and re-verified the source from scratch rather than trusting the prior scouting note as-is, per this registry's standing convention. FI-VHM-308 was chosen over GRCIV-011 because a sale/transfer declaration is the closer functional analogue to the title-transfer transactions already modeled elsewhere in this registry's DMV vertical (cl/sii/aviso-venta-vehiculo, br/mg/detran/comunicacao-de-venda-de-veiculo). The Dominican Republic already has two published documents (Taxes and Passport); this document is its third, opening the DMV vertical (1 of 6 for that vertical, 3/6 verticals overall for the jurisdiction).

Sources examined

• Document (id, version): do/dgii/vehicle-transfer-sworn-declaration-fi-vhm-308 / 1.0.0
• Spec version: GovSchema 0.3.0
• Authority: Dirección General de Impuestos Internos (DGII), Departamento de Vehículos de Motor.
• Primary source: https://dgii.gov.do/vehiculosMotor/formularioVehiculosMotor/Documents/FI-VHM-308.zip — fetched fresh this cycle with a plain curl (no browser User-Agent or session needed): HTTP 200, Content-Type: application/zip, 45,504 bytes, sha256 21e4f72d6f2fb2454ab4b60f6c379f7e24d6a12e0e10aaf66ed5c651a0881932.
• Archive contents: one file, FI-VHM-308 Formulario Declaración Jurada de Transferencia de Vehículos de Motor.xlsx, 56,408 bytes, sha256 945addf62d6d5e0b326a73afce9bafd33d39fa7339169bdacff3f0b45b14b74f, a single-worksheet OOXML .xlsx (xl/worksheets/sheet1.xml, no embedded VBA project, unlike the legacy .xls IR-2 workbook).
• Sibling forms on the same DGII page (not modeled this version): GRCIV-011 (Solicitud de Eliminación de Vehículos de Motor), FI-VHM-312 (Solicitud Reembolso del Impuesto de Circulación Vehicular), FI-ADML-007 (Solicitud de Certificaciones) — each a separate, distinct form with its own field set, left as disclosed backlog candidates for a future cycle rather than modeled here.

Structure independently confirmed

Parsed directly via Python's stdlib zipfile/xml.etree.ElementTree (no openpyxl/pip available or needed in this environment) against the workbook's own xl/sharedStrings.xml (39 shared strings) and xl/worksheets/sheet1.xml parts, cross-referenced by cell reference (e.g. C16, K16) and the sheet's 58 mergeCell ranges to reconstruct the print layout's field grid section by section, top to bottom:

• Header (row 7-10): "Departamento de Vehículos de Motor" (office label, not a field) and the declaration's own title; Fecha (día/mes/año, row 9-10) — no printed asterisk.
• I. DATOS DEL VENDEDOR (rows 14-31): Cédula/RNC\*, Nombre/Razón Social\*, Teléfono, Celular\*, then a "Dirección\*" subsection: Calle, Número/Edif., Urb./Barrio/Res. (no per-field asterisks), Sector\*, Municipio\*, Provincia\*.
• II. DATOS DEL COMPRADOR (rows 33-40): Cédula/RNC, Nombre/Razón Social, Teléfono, Celular — none carry an asterisk. Row 40 carries the form's own footnote (shared-string index 34): "\* Si no conoce los datos del comprador continuar en la casilla III" ("If you don't know the buyer's data, continue at box III").
• III. DATOS DEL VEHICULO (rows 47-56): Placa\*, Marca\*, Modelo\*, Chasis (no asterisk), Año\*.
• IV. DATOS DE LA VENTA (rows 58-61): Monto de la Venta (RD$)\*, Fecha de la Venta (no asterisk).
• V. DECLARACION DE VENTA SIN DATOS DEL COMPRADOR (rows 64-73): "Yo, ___, Declaro bajo Fe de juramento que el vehículo indicado en el presente formulario fue vendido por mi en la fecha antes indicada y que desconozco los datos del comprador y/o poseedor actual del mismo..." (a fallback sworn statement for when Section II can't be completed), "Firma del Declarante" (wet-ink signature, excluded — see Scope decisions), and the closing "(\*) Datos Obligatorios" legend.

A genuine reverse-engineering finding: no dataValidations, requiredness from a stray asterisk cell

Unlike the xlsx forms handled in GOV-3104 (Pakistan IT-1B) and GOV-3114 (this same jurisdiction's IR-2), this workbook carries no dataValidations element at all — confirmed by a direct string search of the raw xl/worksheets/sheet1.xml XML for the literal substring dataValidation (absent). It is a plain print-and-fill layout with no cell-level validation rules to decode. Requiredness instead follows the form's own printed * convention, applied cell-by-cell.

One genuine ambiguity was found and resolved by direct inspection rather than assumption: the label "Teléfono" in Section I (cell C21) carries no asterisk character within its own string — but a separate, single-character shared-string cell (F21, string index 26, literal ) sits immediately adjacent to it on the same row, between the "Teléfono" label and the "Celular\" label (cell J21, which does carry its own asterisk concatenated into the string). A full-sheet scan for every cell whose resolved string is exactly * found this to be the only such cell on the entire sheet. Section II's own "Teléfono"/"Celular" labels (row 39) carry no equivalent adjacent marker. Taken together, this confirms Section I's Teléfono is required (the source's typesetting simply placed its asterisk in a neighboring cell rather than the same string as the label), while Section II's Teléfono/Celular are genuinely unmarked and optional — consistent with Section II being conditionally skippable per the footnote quoted above. This is disclosed as a genuine layout quirk resolved by direct cell-level inspection, not glossed over or guessed.

Scope decisions

1. Cédula / RNC (seller and buyer) is modeled as a single unconstrained string field per the source's own combined label, since the same box accepts either an 11-digit individual cédula or a shorter company RNC and no per-format split or pattern is printed on the form itself — the same treatment given the equivalent ambiguity in do/mirex/passport-application's identityDocumentNumber.
2. Section II (buyer data) is modeled entirely optional, per the form's own footnote directing the filer to skip to Section III when the buyer's data is unknown.
3. Section V's declarantFullName is modeled required: false, not gated by a requiredWhen condition on Section II's fields. The form itself provides no boolean/enum field marking "buyer data unknown" — only a footnote directing the filer's behavior — so no cross-field rule is fabricated to enforce this computationally; the conditional relationship is disclosed here instead, the same disclosed-rather-than-fabricated approach used for cl/sii/aviso-venta-vehiculo's conditionally-mandatory Sección D/E fields.
4. Three fields carry no asterisk despite apparent practical necessity and are modeled required: false strictly per the source's own convention, not overridden by domain judgment: the top-of-form declaration date (declarationDate), vehicleChassis (Chasis/VIN), and saleDate (Fecha de la Venta). Each is disclosed here rather than silently upgraded to required.
5. sellerAddressStreet/sellerAddressNumber/sellerAddressNeighborhood are modeled optional even though the "Dirección" subsection header itself carries an asterisk — the same header-level-vs-per-field asterisk distinction already established in do/mirex/passport-application's Section 2 (identity-document grid).
6. Excluded from this version, disclosed rather than silently omitted:
   • "Departamento de Vehículos de Motor" — an office/department header label, not applicant data.
   • "Firma del Declarante" — a wet-ink signature captured in person, consistent with this registry's treatment of physical signature capture elsewhere (do/mirex/passport-application, il/mot/medical- examination-driving-license-renewal).
   • The "(\*) Datos Obligatorios" legend and Section II's own footnote — instructional text, not fields.
   • The three sibling DGII forms on the same page (GRCIV-011, FI-VHM-312, FI-ADML-007) — each a distinct form, left as disclosed backlog for a future cycle.

Conformance fixtures (Phase 3)

7 fixtures committed under conformance/do/dgii/vehicle-transfer-sworn-declaration-fi-vhm-308/1.0.0/: 2 valid scenarios plus 5 mutation-control fixtures, each derived from one of the valid fixtures by a single targeted mutation. All 7 were run against a from-scratch, ephemeral field-by-field conformance checker (derived directly from this schema's own fields[], not committed to the repo) before being finalized:

• valid-known-buyer-full-transfer.json (seller and buyer both fully identified via Section I/II, all required fields present) — 0 errors.
• valid-unknown-buyer-section-v-declaration.json (Section II buyer fields omitted entirely; declarantFullName completed instead, per Section V) — 0 errors.
• mutation-control-missing-required-field.json (drops sellerCedulaRnc) — exactly 1 error.
• mutation-control-missing-seller-phone.json (drops sellerPhone, testing the stray-asterisk-derived requiredness finding) — exactly 1 error.
• mutation-control-negative-sale-amount.json (sets saleAmount to a negative value, testing minimum: 0) — exactly 1 error.
• mutation-control-invalid-vehicle-year.json (sets vehicleYear to 1850, outside minimum: 1900) — exactly 1 error.
• mutation-control-missing-vehicle-plate.json (drops vehiclePlate) — exactly 1 error.

Structural validation

• node tools/validate.mjs registry/do/dgii/vehicle-transfer-sworn-declaration-fi-vhm-308/1.0.0/schema.json — ok.
• node tools/validate-ajv.mjs registry/do/dgii/vehicle-transfer-sworn-declaration-fi-vhm-308/1.0.0/schema.json (ajv 2020-12 against spec/v0.3) — ok.
• Full-registry re-run after adding this document: node tools/validate.mjs → 478/478 (477 documents + this one, plus 3 mapping.json companions unaffected); node tools/validate-ajv.mjs → 478/478.
• node tools/verify-sources.mjs registry/do/dgii/vehicle-transfer-sworn-declaration-fi-vhm-308/1.0.0 — 1 directory, 3 URLs checked, 0 warnings, 0 failures.
• npm run build-index re-run in tools/govschema-client/ to regenerate registry-index.json with this document included.

Maturity

structural-reference: the source form's own printed field grid (Sections I-V) is fully transcribed from the genuine, currently-served workbook, with the one layout ambiguity found (the Teléfono stray-asterisk cell) independently resolved by direct cell-level inspection rather than guessed. No live filing through DGII's Departamento de Vehículos de Motor was attempted and no independent second reviewer has yet passed over this field list. GovSchema is an independent, non-profit standards body and is not affiliated with, endorsed by, or operated by the Dominican Republic or the Dirección General de Impuestos Internos.