Registry entry

Uruguay (Montevideo) Vehicle Registration (Formulario F19 — Empadronamiento de Vehículos Nacionales/Importados)

Register a nationally-manufactured or imported motor vehicle for the first time with the Intendencia de Montevideo's (IMM) Servicio de Contralor y Registro de Vehículos, using Formulario F19, "Empadronamiento de Vehículos," per Ley Nº 19.061 and Decreto Nº 187/014. Filing this form assigns the vehicle its Uruguayan license plates (chapas matrículas) and vehicle-circulation booklet (libreta de circulación). Opens Uruguay's DMV vertical (2 of 6), following the Business Formation vertical opened by `uy/dgi/inscripcion-actualizacion-empresas-formulario-0351`. The single-form, 2-page AcroForm covers: the identity of whoever physically files the request (gestionante — always a natural person on this form), the identity of the vehicle's seller/importer (vendedor, who may be a natural person or a RUT-bearing entity), the vehicle's technical data (make, model, year, fuel, chassis/engine numbers, body type, displacement, horsepower, cylinder count, passenger/cargo capacity, gross weight, axles, tires, insurance company and policy validity), a checkbox pair recording whether the vehicle is imported or domestic and new (cero km) or used, a checkbox pair recording whether the vehicle's use is "particular" or some other declared affectation, and up to two vehicle owners (titular #1, required; titular #2, an optional second/co-owner using the same field set). Vehicle registration in Uruguay is administered at the departmental (Intendencia) level, not nationally — this document is scoped to Montevideo specifically, the same way this registry already scopes `br/mg/detran/comunicacao-de-venda-de-veiculo` and `ca/on/mto/vehicle-registration` to their own subnational authorities; Uruguay's other 18 departments would each need their own future schema, since each Intendencia runs its own vehicle registry and (per Ley Nº 19.061) its own SUCIVE-integrated circulation-permit process. Out of scope for v1.0.0, and disclosed rather than silently dropped, are: four AcroForm text-field widgets under the printed header row labeled "ID" / "CÓDIGO NACIONAL" whose internal AcroForm field names (`NumTelGestor_2` through `NumTelGestor_5`) are duplicated, unrelated copy-paste artifacts of the unrelated gestionante-phone-number field family, and whose exact semantic scope (an applicant-entered national vehicle-catalog lookup code vs. an office-assigned reference) could not be confidently determined from the source PDF alone; and the "RECIBE DOCUMENTOS" and "FUNCIONARIOS ACTUANTES" sections (plate/D.I.V. receipt acknowledgment boxes and staff-only signature/stamp fields), which record the outcome of the in-person appointment rather than applicant-supplied input to the registration request. See VERIFICATION.md for the full field inventory, the coordinate-correlation extraction method, and every disclosed scoping and naming-anomaly judgment call.

Registry entry

uy/imm/empadronamiento-vehiculos-nacionales

Jurisdiction
Uruguay · Montevideo (subnational)
Version
1.0.0
Verification
draft
Authority
Intendencia de Montevideo, Servicio de Contralor y Registro de Vehículos

Authoritative source Formulario F19, "Empadronamiento de Vehículos" (edition "Formulario agosto 2024", per the Intendencia de Montevideo's own trámite pages)

Machine access

Schema document
registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

53 fields, read from the published schema.json, with names, types, requiredness, and validation as the document states them. The live government form remains the authoritative source.

Fields

  • fechaSolicitud date required

    Date this registration request is filed. Consolidated from the source's separate Día/Mes/Año boxes into a single date field, per this registry's date-consolidation convention.

  • tipoOrigen enum required

    Whether the vehicle being registered is imported or of domestic (Uruguayan) manufacture. The source's own printed form, filename, and both of IMM's trámite landing pages ("Empadronamiento de Vehículos Nacionales" and "Empadronamiento de Vehículos Importados") confirm this single form/AcroForm serves both paths via this one checkbox pair.

    enum: importado | nacional
  • tipoCondicion enum required

    Whether the vehicle is brand new (cero kilómetros) or used at the time of registration.

    enum: cero_km | usado
  • gestionanteTipoDocumento enum required

    Identity-document type of the person physically filing this request (gestionante). Unlike the vendedor/titular document-type fields below, this checkbox group has no RUT option — the gestionante is always modeled as a natural person on this form.

    enum: CI | PASAPORTE | CARNE_DIPLOMATICO
  • gestionanteNombre string required

    Full name of the person physically filing this request.

    classification: pii
  • gestionanteTelefono string

    Contact phone number of the gestionante. Not marked as obligatory by the source.

    classification: pii
  • gestionanteNumeroDocumento string required

    Identity-document number of the gestionante, for the document type selected in gestionanteTipoDocumento. Modeled as a plain string rather than a single fixed pattern, since the field is shared across CI/Pasaporte/Carné diplomático formats.

    classification: pii
  • gestionantePaisDocumento string

    Country that issued the gestionante's identity document. Not marked as obligatory by the source.

  • vendedorNombre string required

    Full name or company name (razón social) of the vehicle's seller/importer.

    classification: pii
  • vendedorTelefono string

    Contact phone number of the seller/importer. Not marked as obligatory by the source.

    classification: pii
  • vendedorTipoDocumento enum required

    Identity-document type of the seller/importer. Unlike gestionanteTipoDocumento, this checkbox group adds a fourth option, RUT, since a seller is commonly a business entity (e.g. a dealership or importer).

    enum: CI | PASAPORTE | CARNE_DIPLOMATICO | RUT
  • vendedorNumeroDocumento string required

    Identity-document (or RUT) number of the seller/importer.

    classification: pii
  • vendedorPaisDocumento string

    Country that issued the seller/importer's identity document. Not marked as obligatory by the source.

  • vendedorDomicilio string required

    Address of the seller/importer, as a single free-text field (the source does not split it into street/number/locality sub-boxes).

    classification: pii
  • vendedorCodigoPostal string

    Postal code of the seller/importer's address. Not marked as obligatory by the source.

  • vendedorDomicilioElectronico string

    Email address of the seller/importer. Not marked as obligatory by the source.

    pattern
  • vehiculoMarca string required

    Vehicle make/brand.

  • vehiculoModelo string required

    Vehicle model.

  • vehiculoAnio integer required

    Vehicle model/manufacture year.

    range: 1900–2100
  • vehiculoCombustible string required

    Vehicle fuel type (e.g. nafta, diésel, eléctrico, híbrido). Modeled as free text rather than a closed enum, since the printed form provides only a blank, not a checkbox list.

  • vehiculoChasis string required

    Vehicle chassis number (VIN or national chassis identifier).

  • vehiculoMotor string required

    Vehicle engine number.

  • vehiculoTipo string required

    Vehicle body/category type (e.g. automóvil, camioneta, moto, remolque).

  • vehiculoCilindrada integer

    Engine displacement in cubic centimeters. Not marked as obligatory by the source.

    range: 0–∞
  • vehiculoPotencia number

    Engine power in horsepower. Not marked as obligatory by the source.

    range: 0–∞
  • vehiculoCilindros integer

    Number of engine cylinders. Not marked as obligatory by the source.

    range: 0–∞
  • vehiculoPasajeros integer

    Passenger seating capacity. Not marked as obligatory by the source.

    range: 0–∞
  • vehiculoCarga number

    Cargo capacity in kilograms. Not marked as obligatory by the source.

    range: 0–∞
  • vehiculoPbt number

    Peso Bruto Total (gross vehicle weight) in kilograms. Not marked as obligatory by the source.

    range: 0–∞
  • vehiculoEjes integer

    Number of axles. Not marked as obligatory by the source.

    range: 0–∞
  • vehiculoCubiertas integer

    Number of tires. Not marked as obligatory by the source.

    range: 0–∞
  • vehiculoAtributos string

    Free-text field for additional declared vehicle attributes (e.g. color, special equipment). Not marked as obligatory by the source; the printed form gives no closed list for this box.

  • seguroEmpresa string

    Name of the insurance company providing the vehicle's mandatory third-party liability insurance (SOA). IMM's own "Empadronamiento de Vehículos Importados" trámite page requires a valid SOA policy at filing time for imported vehicles; the "Empadronamiento de Vehículos Nacionales" page instead describes SOA being arranged afterward, during a five-day provisional circulation permit — a disclosed distinction, see VERIFICATION.md.

  • seguroVigencia date

    Expiry/validity date of the insurance policy. Consolidated from the source's separate Día/Mes/Año boxes into a single date field. See seguroEmpresa for the requiredWhen disclosure.

  • tipoAfectacion enum required

    Declared use of the vehicle: private/personal use (particular) or some other declared affectation (e.g. commercial, rental, official).

    enum: particular | otro
  • afectacionDetalle string

    Free-text description of the declared affectation, only completed when tipoAfectacion is "otro".

  • titular1Nombre string required

    Full name or company name of the vehicle's first (primary) owner, the person or entity the vehicle is being registered to.

    classification: pii
  • titular1Telefono string

    Contact phone number of titular #1. Not marked as obligatory by the source.

    classification: pii
  • titular1TipoDocumento enum required

    Identity-document type of titular #1 (natural person or RUT-bearing entity).

    enum: CI | PASAPORTE | CARNE_DIPLOMATICO | RUT
  • titular1NumeroDocumento string required

    Identity-document (or RUT) number of titular #1.

    classification: pii
  • titular1PaisDocumento string

    Country that issued titular #1's identity document. Not marked as obligatory by the source.

  • titular1Domicilio string required

    Address of titular #1, as a single free-text field.

    classification: pii
  • titular1CodigoPostal string

    Postal code of titular #1's address. Not marked as obligatory by the source.

  • titular1DomicilioElectronico string

    Email address of titular #1. Not marked as obligatory by the source.

    pattern
  • titular2Presente boolean required

    Whether a second vehicle owner (co-titular) is being registered in the source's second, structurally identical "IDENTIFICACIÓN DEL TITULAR #2" block. The source form provides no explicit yes/no checkbox for this — it is simply an optional repeated block — so this schema adds a synthetic gating boolean, per this registry's established convention (cf. `uy/dgi/inscripcion-actualizacion-empresas-formulario-0351`'s own `segundoTitularPresente`).

  • titular2Nombre string

    Full name or company name of the vehicle's second (co-)owner.

    classification: pii
  • titular2Telefono string

    Contact phone number of titular #2. Not marked as obligatory by the source.

    classification: pii
  • titular2TipoDocumento enum

    Identity-document type of titular #2.

    enum: CI | PASAPORTE | CARNE_DIPLOMATICO | RUT
  • titular2NumeroDocumento string

    Identity-document (or RUT) number of titular #2.

    classification: pii
  • titular2PaisDocumento string

    Country that issued titular #2's identity document. Not marked as obligatory by the source.

  • titular2Domicilio string

    Address of titular #2, as a single free-text field. This schema field is sourced from the AcroForm widget internally named `MailTit2_2` — a mislabeled/copy-paste artifact of the unrelated email-field family, confirmed by coordinate correlation against the printed "Domicilio" label (the genuine email field for titular #2 is the separate, correctly-named `MailTit2` widget) — see VERIFICATION.md.

    classification: pii
  • titular2CodigoPostal string

    Postal code of titular #2's address. Not marked as obligatory by the source.

  • titular2DomicilioElectronico string

    Email address of titular #2. Not marked as obligatory by the source.

    pattern

Verification record

This file is the source-review record for this document version, per the manual-source-review-v1 practice. It documents the provenance of the published fields/documents and states the current verification claim honestly.

Current claim

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

This is a GovSchema Standard Research cycle (GOV-2456), tasked with opening Uruguay's DMV vertical (2 of 6) via the Intendencia de Montevideo's (IMM) vehicle registration form, Formulario F19. Uruguay had only Business Formation modelled prior to this cycle (uy/dgi/inscripcion-actualizacion-empresas-formulario-0351, GOV-2449).

Why this candidate, and why municipal/departmental scope

Vehicle registration in Uruguay is not run by a national ministry — it is administered separately by each of Uruguay's 19 departmental governments (Intendencias), each of which operates its own vehicle registry and its own SUCIVE-integrated circulation-permit process under Ley Nº 19.061. This schema is therefore scoped to Montevideo, IMM's own Servicio de Contralor y Registro de Vehículos, and modeled as jurisdiction.level: "subnational" with subdivision: "UY-MO" — the same tier this registry already uses for br/mg/detran/comunicacao-de-venda-de-veiculo (BR-MG) and ca/on/mto/vehicle-registration (CA-ON), rather than "municipal" (which this registry reserves for a sub-division-of-a-subdivision body, e.g. Miami County within Florida state, per GSP-0021 and requires a locality object). Montevideo department is itself the top subnational tier, analogous to a Brazilian state or Canadian province, not a county-like body nested inside one. Any of Uruguay's other 18 departments would need their own future schema.

Sources examined

Source 1 (primary source, the AcroForm PDF)
  • Authority: Intendencia de Montevideo (IMM), Servicio de Contralor y Registro de Vehículos — División Tránsito, Unidad 4750
  • Document: Formulario F19, "Empadronamiento de Vehículos" (per Ley Nº 19.061, Decreto Nº 187/014)
  • URL: https://tramites.montevideo.gub.uy/sites/tramites.montevideo.gub.uy/files/tramites/documentos/F19%20-%20EmpadronamientoVehiculosImportados-cp-V6_10.pdf
  • Access: fetched directly (curl), HTTP 200, Content-Type: application/pdf, no login/CAPTCHA/WAF gate of any kind.
  • File identity: sha256:a6e5bd2b53304dab88dd15afc7d742033008127665a8c6881823b37849397fec, 138,349 bytes, PDF 1.6, Producer: LibreOffice 7.3, Creator: Writer, Author: Rafael Goicoechea, CreationDate: D:20240727102341-03'00' (2024-07-27). IsAcroFormPresent: true, IsXFAPresent: false.
  • Currency corroboration: the HTTP Last-Modified header on this exact URL is Sat, 24 Aug 2024 18:29:39 GMT, and both of IMM's own trámite landing pages that link this file (see Sources 2 and 3) list "Formulario agosto 2024" as the current download — all three signals (PDF internal creation date, HTTP header, and the authority's own labeled download link) agree on a 2024-07/08 vintage, with no more recent revision found.
  • Extraction method: pdfjs-dist v3.11.174 (Node, pdfjs-dist/build/ pdf.js), page.getAnnotations({ intent: "display" }) filtered to subtype === "Widget" for the AcroForm inventory, and page.getTextContent() (items sorted by descending y then ascending x) for the printed text layer, since every widget's own alternativeText (tooltip) is empty on this form — every field label below was recovered by correlating each widget's rect against the nearest printed text item's transform coordinates, not by reading tooltips.
  • Widget/field inventory (independently re-derived this cycle, matching this cycle's own prior scouting pass exactly): 81 AcroForm widgets across 2 pages (49 on page 1, 32 on page 2), resolving to 65 uniquely named fields (some fields are radio-button groups sharing one field name across 2-4 widgets: ImpoSINO×2, CEROSINO×2, TipoDocGes×3, TipoDocVen×4, TipoAfe×2, TipoDocTit1×4, TipoDocTit2×4, MATSINO×2, MATSINO_2×2; every other named field is a single text-field widget).
  • Retrieved / reviewed: 2026-07-12
Source 2 (trámite landing page, domestic-vehicle path)
  • URL: https://tramites.montevideo.gub.uy/tramites-y-tributos/solicitud/empadronamiento-de-vehiculos-nacionales
  • Access: fetched directly, HTTP 200, no gate.
  • Content used: the "Documentación a presentar" and "Casos especiales" / "Otras opciones de actuación" sections, which this schema's documents[] block is sourced from (see below). Confirms the same F19 PDF ("Formulario agosto 2024") is the download for this trámite, and that the form's own IMPORTADO/NACIONAL checkbox lets one PDF serve both the "nacionales" and "importados" trámites.
  • Retrieved / reviewed: 2026-07-12
Source 3 (trámite landing page, imported-vehicle path)
  • URL: https://tramites.montevideo.gub.uy/tramites-y-tributos/solicitud/empadronamiento-de-vehiculos-importados
  • Access: fetched directly, HTTP 200, no gate.
  • Content used: cross-checked against Source 2's requisitos list. Mostly identical, with one material divergence used in this schema (see the seguroEmpresa/seguroVigencia/seguroObligatorioDocumentFile requiredWhen gate below): this page states a mandatory, already-valid SOA (Seguro Obligatorio Automotor) policy is required documentation ("Seguro obligatorio (SOA) vigente con los datos del vehículo según artículo 27 Ley 18.412") for the imports path, whereas Source 2 instead describes SOA being arranged only after filing, during a five-day provisional circulation permit ("Se entregará un provisorio de circulación por cinco días para que se gestione el seguro obligatorio (SOA)").
  • Retrieved / reviewed: 2026-07-12

Field inventory (Phase 3)

All 53 modeled fields, the printed section and label they come from, and the underlying AcroForm field name(s):

| Field (schema name) | Label (source) | Section | AcroForm field(s) | |---|---|---|---| | fechaSolicitud | Fecha | Header | Dia/Mes/Anio | | tipoOrigen | Importado / Nacional | Header | ImpoSINO | | tipoCondicion | Cero KM. / Usado | Header | CEROSINO | | gestionanteTipoDocumento | Tipo del documento | Identificación del Gestionante | TipoDocGes | | gestionanteNombre | Nombre y apellido | Identificación del Gestionante | NomGestor | | gestionanteTelefono | Teléfono | Identificación del Gestionante | NumTelGestor | | gestionanteNumeroDocumento | Número del documento | Identificación del Gestionante | NumDocGestor | | gestionantePaisDocumento | País del documento | Identificación del Gestionante | PaisDocGestor | | vendedorNombre | Nombres y apellidos o Razón social | Identificación del Vendedor | NomVen | | vendedorTelefono | Número de teléfono | Identificación del Vendedor | NumTelVen | | vendedorTipoDocumento | Tipo de documento | Identificación del Vendedor | TipoDocVen | | vendedorNumeroDocumento | Número del documento | Identificación del Vendedor | NumDocVen | | vendedorPaisDocumento | País del documento | Identificación del Vendedor | PaisDocVen | | vendedorDomicilio | Domicilio | Identificación del Vendedor | DomVen | | vendedorCodigoPostal | Código postal | Identificación del Vendedor | CodPosVen | | vendedorDomicilioElectronico | Domicilio electrónico | Identificación del Vendedor | MailVen | | vehiculoMarca | Marca | Datos del Vehículo | Marca | | vehiculoModelo | Modelo | Datos del Vehículo | Modelo | | vehiculoAnio | Año | Datos del Vehículo | Anio_2 | | vehiculoCombustible | Combustible | Datos del Vehículo | Combustible | | vehiculoChasis | Número de chasis | Datos del Vehículo | Chasis | | vehiculoMotor | Número de motor | Datos del Vehículo | Motor | | vehiculoTipo | Tipo | Datos del Vehículo | Tipo | | vehiculoCilindrada | C.C. | Datos del Vehículo | CC | | vehiculoPotencia | H.P. | Datos del Vehículo | HP | | vehiculoCilindros | Cilindros | Datos del Vehículo | Cilindros | | vehiculoPasajeros | Pasajeros | Datos del Vehículo | Pasajeros | | vehiculoCarga | Carga | Datos del Vehículo | Carga | | vehiculoPbt | P.B.T. | Datos del Vehículo | PBT | | vehiculoEjes | Ejes | Datos del Vehículo | Ejes | | vehiculoCubiertas | Cubiertas | Datos del Vehículo | Cubiertas | | vehiculoAtributos | Atributo | Datos del Vehículo | Atributos | | seguroEmpresa | Empresa seguro | Datos del Vehículo | Empresa Seguro | | seguroVigencia | Vigencia seguro | Datos del Vehículo | DiaS/MesS/AnioS | | tipoAfectacion | Tipo de afectación | Header (p.2) | TipoAfe | | afectacionDetalle | (blank beside OTRO) | Header (p.2) | Afectacion | | titular1Nombre | Nombres y apellidos o Razón social | Identificación del Titular #1 | NomTit1 | | titular1Telefono | Número de teléfono | Identificación del Titular #1 | NumTelTit1 | | titular1TipoDocumento | Tipo de documento | Identificación del Titular #1 | TipoDocTit1 | | titular1NumeroDocumento | Número del documento | Identificación del Titular #1 | NumDocTit1 | | titular1PaisDocumento | País del documento | Identificación del Titular #1 | PaisDocTit1 | | titular1Domicilio | Domicilio | Identificación del Titular #1 | DomTit1 | | titular1CodigoPostal | Código postal | Identificación del Titular #1 | CodPosTit1 | | titular1DomicilioElectronico | Domicilio electrónico | Identificación del Titular #1 | MailTit1 | | titular2Presente | (synthetic gating field) | Identificación del Titular #2 | (none — see judgment call 3) | | titular2Nombre | Nombres y apellidos o Razón social | Identificación del Titular #2 | NomTit2 | | titular2Telefono | Número de teléfono | Identificación del Titular #2 | NumTelTit2 | | titular2TipoDocumento | Tipo de documento | Identificación del Titular #2 | TipoDocTit2 | | titular2NumeroDocumento | Número del documento | Identificación del Titular #2 | NumDocTit2 | | titular2PaisDocumento | País del documento | Identificación del Titular #2 | PaisDocTit2 | | titular2Domicilio | Domicilio | Identificación del Titular #2 | MailTit2_2 (mislabeled widget name — see judgment call 4) | | titular2CodigoPostal | Código postal | Identificación del Titular #2 | CodPosTit2 | | titular2DomicilioElectronico | Domicilio electrónico | Identificación del Titular #2 | MailTit2 |

53 fields total, covering 70 of the 81 AcroForm widgets (56 of the 65 uniquely named fields — 52 mapped 1:1 or as a consolidated radio/date group, plus 1 synthetic gating field with no underlying widget of its own).

Access notes and judgment calls

  1. 9 named fields (11 widgets) excluded, disclosed rather than guessed. Two clusters:
    • NumTelGestor_2/_3/_4/_5 (4 widgets, page 1 header row). These sit directly under printed labels "ID" and "CÓDIGO NACIONAL" (confirmed by coordinate correlation: the "ID" text item sits above NumTelGestor_2's rect, and "CÓDIGO NACIONAL" spans above the combined rects of NumTelGestor_3/_4/_5), but their AcroForm field names are verbatim duplicates of the unrelated "gestionante phone number" field family (NumTelGestor) — a clear copy/paste artifact from the PDF's authoring in LibreOffice. Whether these boxes are an applicant-entered lookup value (e.g. a national vehicle-catalog code the importer/gestor already has on hand) or an office-assigned reference number could not be confidently determined from the source PDF alone, so — per this cycle's brief instruction to disclose rather than guess — they are excluded from this v1.0.0 rather than modeled under a name that implies a confident semantic reading.
    • The "RECIBE DOCUMENTOS" section (page 2, 7 widgets: MATSINO×2, MATSINO_2×2, MatLetEnt, MatNumEnt, RECIBIDIV). Coordinate correlation places these against "Recibí matrículas.:" / "Recibí D.I.V.:" labels with their own SI/NO checkboxes and plate-letter/ plate-number/D.I.V.-number blanks — this is a receipt acknowledgment of physical plates and the D.I.V. (Documento de Identificación Vehicular) handed over during the in-person appointment, i.e. an output of the transaction rather than applicant-supplied input to the registration request itself, matching this registry's established convention of excluding office-interaction/receipt-acknowledgment boxes (cf. pe/mtc/solicitud-licencia-conducir-012-17's exclusion of its own "Uso de Mesa de Partes" box).
    • The "FUNCIONARIOS ACTUANTES" section (Funcionario/Sector Ingresos/Sector Control, firma y sello) and the "RECUERDE" legal notice block carry zero AcroForm widgets of their own — they are pure print layout (staff signature lines and a citation of Artículo 239 of the Código Penal) — so they require no explicit exclusion from the widget count, but are noted here for completeness.
  2. gestionanteTipoDocumento has no RUT option (3 widgets); the vendedor and both titular document-type fields do (4 widgets each). Coordinate correlation confirms the printed checkbox rows themselves differ in length: the gestionante (whoever physically files the paperwork) is modeled by this form as always a natural person, while the vendedor and titular(es) may be a RUT-bearing business entity — consistent with the trámite pages' own "Cuando el titular del vehículo es una empresa..." guidance.
  3. titular2Presente is a synthetic gating field with no corresponding source widget. The printed form simply repeats its entire "Identificación del Titular" block a second time with no yes/no checkbox of its own controlling whether it applies; this schema adds a boolean gate so a consumer can determine whether the second block's requiredWhen-gated fields apply, following the identical precedent set by uy/dgi/inscripcion-actualizacion-empresas-formulario-0351's own segundoTitularPresente.
  4. titular2Domicilio is sourced from the AcroForm widget internally named MailTit2_2, not from any widget containing "Dom" in its name. Coordinate correlation is unambiguous here: for Titular #1, the printed "Domicilio" label sits 6.2pt above the top edge of the DomTit1 widget's rect; for Titular #2, the printed "Domicilio" label sits 6.1pt above the top edge of MailTit2_2's rect (the same offset, confirming the correlation) — while the genuinely well-named MailTit2 widget instead aligns with the printed "Domicilio electrónico" (email) label lower in the same block. This is a second, distinct copy-paste/mislabeling artifact in the same PDF as judgment call 1, disclosed here rather than silently "corrected" into a differently-named schema field, so a future reader auditing this schema against the raw PDF via pdfjs-dist can find the same widget under the same internal name.
  5. seguroEmpresa/seguroVigencia (insurance company/policy validity) and the seguroObligatorioDocumentFile document are requiredWhen tipoOrigen == "importado". This is sourced from a genuine divergence between IMM's own two trámite pages (see Source 3 above): the imports page requires a valid SOA policy as filing documentation, while the domestic page describes SOA being arranged only after a provisional permit is issued. The AcroForm's own required widget attribute is unset (false) on every widget on this form, so this schema follows the trámite pages' own prose over the PDF's (uninformative) internal required-flags, consistent with this registry's established practice (cf. pe/mtc/solicitud-licencia-conducir-012-17).
  6. documents[] — sourced from both trámite landing pages' own "Documentación a presentar" / "Casos especiales" / "Otras opciones de actuación" sections, not modeled exhaustively. This form's requisitos branch heavily by seller type (private individual vs. business), by whether the vehicle was self-built, by classic/collector-vehicle import regimes (Ley 17.887, Ley 19.996), by municipal-fleet or Interior/Defensa-fleet vehicles, and by who is signing (the titular directly, a minor's parent/tutor/curador, an attorney-in-fact, or a company representative). This v1.0.0 models the five requisitos that apply broadly across the common individual-registrant path (gestionante's own ID, one of the three standard origin-proof documents, the conditionally-required SOA policy, the private-seller ID+receipt combination, and the general non-titular-representative ID copy) and discloses the narrower special-case documents (self-built-vehicle sworn declaration, minor/tutor/curador/power-of-attorney packets, classic-import ministerial resolutions, municipal/Interior-Defensa fleet paperwork) as out of scope for this version, following the same scoping-and-disclosure convention as br/mg/detran/comunicacao-de-venda-de-veiculo's own documents[] entry.
  7. No signature/fingerprint fields are modeled, consistent with this registry's established convention (cf. pe/mtc, uy/dgi) — the "Firma del gestionante" / "Firma del vendedor o representante" / "Firma del titular o representante" lines and the seller's company stamp box are physical marks on the printed form with no corresponding AcroForm widget in this PDF (this form has no signature-widget annotations at all, unlike e.g. fi/traficom/luovutuskirja-ajoneuvon-omistusoikeuden-siirrosta's genuine fillable signature-line widgets).

Test run (Phase 4)

No live submission was attempted: F19 is filed in person at IMM's Servicio de Contralor y Registro de Vehículos (Pedernal 2219) with the physical vehicle presented, per both trámite pages ("Debe presentar el vehículo al momento de realizar el trámite") — there is no unauthenticated online endpoint to submit fabricated data against.

Instead, two independent worked mock records were built from this document's own field inventory (one domestic/used/single-titular, one imported/cero-km/two-titulares) and checked with a purpose-written script (_tmp_validate_instance.mjs, not committed — mirrors the approach used by pe/mtc/solicitud-licencia-conducir-012-17 and uy/dgi/inscripcion-actualizacion-empresas-formulario-0351): compiles schema.json's fields[] into a JSON Schema draft 2020-12 document checked with ajv (ajv/dist/2020.js, matching tools/validate-ajv.mjs's own draft selection), plus a from-scratch evaluator for the shared Condition grammar that checks fields[].requiredWhen:

``` $ node tools/_tmp_validate_instance.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json \ conformance/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/nacional-usado-un-titular.json Static (required/type/pattern/enum) validation: PASS requiredWhen conditional validation: PASS OVERALL: PASS

$ node tools/_tmp_validate_instance.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json \ conformance/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/importado-cero-km-dos-titulares.json Static (required/type/pattern/enum) validation: PASS requiredWhen conditional validation: PASS OVERALL: PASS ```

Mutation controls — three negative fixtures, each targeting a distinct validation rule, each verified to raise exactly one validation error:

``` $ # mutation-control-missing-required-field.json: 'vehiculoChasis' (required: true) removed Static (required/type/pattern/enum) validation: FAIL - (root) must have required property 'vehiculoChasis' requiredWhen conditional validation: PASS OVERALL: FAIL

$ # mutation-control-email-pattern-violation.json: 'vendedorDomicilioElectronico' set to 'not-an-email' Static (required/type/pattern/enum) validation: FAIL - /vendedorDomicilioElectronico must match pattern "^[^@\s]+@[^@\s]+\.[^@\s]+$" requiredWhen conditional validation: PASS OVERALL: FAIL

$ # mutation-control-missing-conditional-titular2-field.json: 'titular2Presente' is true $ # but 'titular2NumeroDocumento' (requiredWhen titular2Presente == true) removed Static (required/type/pattern/enum) validation: PASS requiredWhen conditional validation: FAIL - field 'titular2NumeroDocumento' is required (requiredWhen matched) but not provided OVERALL: FAIL ```

The third case specifically exercises fields[].requiredWhen (as opposed to the plain static-required case in mutation-control-missing-required-field.json) — a validator that only checks static required: true fields and ignores conditional requiredWhen rules would incorrectly accept this fixture, which is exactly the gap this fixture exists to catch.

Both meta-schema validators were run against the finished document and pass clean:

``` $ node tools/validate.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json ok registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json

1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json ok registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json [v0.3]

1/1 document(s) validated against the meta-schema (ajv 2020-12). ```

A full-registry run of both validators also passed clean (372/372, up from 371 before this document), tools/verify-sources.mjs re-fetched all 3 cited URLs with 0 failures/warnings, and tools/govschema-client/registry-index.json was regenerated via npm run build-index (in tools/govschema-client/, after npm ci --include=dev since a plain npm ci under a local NODE_ENV=production skips ajv's devDependency install) to include this document's entry.

How to re-verify

  1. curl -sO "https://tramites.montevideo.gub.uy/sites/tramites.montevideo.gub.uy/files/tramites/documentos/F19%20-%20EmpadronamientoVehiculosImportados-cp-V6_10.pdf" and confirm sha256sum matches a6e5bd2b53304dab88dd15afc7d742033008127665a8c6881823b37849397fec.
  2. npm install pdfjs-dist@3.11.174 in a scratch directory, then run page.getAnnotations({ intent: "display" }) per page to confirm 81 widgets / 65 unique field names (49 widgets on page 1, 32 on page 2), and page.getTextContent() to re-derive the coordinate correlation described in the judgment calls above (in particular, MailTit2_2's rect sits under the printed "Domicilio" label, not "Domicilio electrónico").
  3. Fetch both trámite landing pages (.../empadronamiento-de-vehiculos-nacionales and .../empadronamiento-de-vehiculos-importados) and confirm the "Documentación a presentar" wording behind documents[] and the SOA-insurance divergence behind seguroEmpresa/seguroVigencia's requiredWhen gate.
  4. Run node tools/validate.mjs and node tools/validate-ajv.mjs (after cd tools && npm ci --include=dev) against registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json.
  5. Run node tools/verify-sources.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0.

Uruguay's other verticals (screened this cycle)

Uruguay now stands at 2 of 6 verticals (Business Formation, DMV). This cycle also screened Uruguay's Passport (DNIC, an authenticated appointment-scheduling portal only, no unauthenticated form) and National ID (DNIC cédula de identidad, in-person biometric enrollment only) verticals and confirmed both are dead ends for now — see CATALOG.md's "Known Gaps & Opportunities" section. Visa and Taxes were not screened this cycle.

View the raw record (VERIFICATION.md)

Version history

  • 1.0.0 draft latest this page has verification record schema.json

Independent and non-affiliated

GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by Intendencia de Montevideo, Servicio de Contralor y Registro de Vehículos or any government. The authoritative source is always the live government form and its official instructions.