Zoho Premium Partner

Consola de Análisis de los Seis Procesos — DNIT SDP N.° 02/2026

Un escritorio de trabajo para los seis procesos punta a punta. Cada pestaña reúne la consigna del TDR, la visión de la plataforma del equipo Zoho/Qntrl, un flujo TO-BE, preguntas abiertas por resolver, nuestro enfoque y las brechas a cotizar. Colapse lo que no necesite; sus notas y casillas se guardan en este navegador.

DOCUMENTO DE TRABAJO INTERNO · NO PARA PRESENTACIÓN A LA DNIT · NOTAS GUARDADAS LOCALMENTE EN SU NAVEGADOR
◆

Cómo usar esta consola

Método de trabajo · no es un entregable

Cada una de las seis pestañas de proceso tiene los mismos seis paneles, así siempre sabe dónde mirar. Abra una pestaña, expanda los paneles que quiera, haga lluvia de ideas en el cuadro amarillo de notas (se guarda mientras escribe) y marque las preguntas a medida que las resuelve.

PanelQué va aquí
01 · La consigna del TDRLo que la DNIT exige literalmente para este proceso (TO-BE), en términos claros.
02 · Visión del equipo QntrlExactamente lo que el documento de respuesta de Zoho dice que hace Qntrl — el Board, el Formulario, las etapas del Blueprint — más la calificación de ajuste.
03 · Flujo TO-BEUna secuencia de etapas del proceso, marcando dónde se necesita un componente externo (rojo).
04 · Preguntas por resolverLas decisiones abiertas. Márquelas a medida que obtengamos respuestas de la DNIT o internamente.
05 · Cómo lo abordamosNuestro método previsto y las apps asignadas. Borrador — edite libremente.
06 · Brechas y decisionesLos complementos / integraciones externas a dimensionar y cotizar para este proceso.

Todo lo que escriba en un cuadro de notas y cada casilla se guarda solo en este navegador (localStorage). Nada se sube. Use «Imprimir / Guardar PDF» del navegador para compartir una copia — la impresión expande todos los paneles automáticamente.

Evaluación de la propia Zoho
Qntrl cubre nativamente ≈72% del alcance de automatización, ≈88% una vez integrado con Marangatu y dos complementos — pero solo ≈45–50% del RFP completo. El resto es nuestro trabajo de consultoría: relevamiento AS-IS, modelado BPMN 2.0, manuales, reglamentos, UI/UX, capacitación, gestión del cambio. Tenga presente esa división al analizar: la plataforma es el motor, no la oferta.
✎ Notas transversales (aplican a los seis)saved ✓
1

Expediente Electrónico DNIT

Electronic File · proceso contenedor
Ajuste: bueno, con complementos
La consigna: recibir, gestionar, procesar, almacenar y entregar cada trámite digitalmente, con trazabilidad garantizada e invulnerabilidad documental, estado en tiempo real para contribuyente/operador/tercero/unidades internas, y un catálogo de trámites vivo. Los trámites que conviene automatizar por separado (Formulario 10, facilidades de pago, no retención) se delimitan aparte.
nuevo Presentadoportal + RUC + anexos En revisióncatálogo → ruta En procesohandoffs · SLA Resoluciónfirma electrónica Cerradonotifica · cronología devolución EXT · firma electrónica EXT · DMS si >65 MB/archivo
etapa Qntrltrabajo/handoffcomponente externo
Blueprint de Qntrl según la nota de Zoho — Presentado → En revisión → En proceso → Resolución → Cerrado, con devolución. Rojo = no nativo.
Qntrl answer · pp. 95–96
«Totalmente realizable como un Board de Qntrl: un formulario selector de tipo de trámite con búsqueda de contribuyente/RUC, secciones dinámicas por trámite y campos de adjuntos; etapas del Blueprint Presentado → En revisión → En proceso → Resolución → Cerrado, con devolución para correcciones y rutas distintas por tipo de trámite mediante criterios. SLA por etapa, correo de acuse automático y la Cronología de Actividad/Etapa dan estado en tiempo real y una pista de auditoría inviolable.»
Board · Blueprint · SLA formulario dinámico · catálogo adjuntos firma electrónica (ext.)
Brecha que señalan: la firma digital con valor legal y la invulnerabilidad garantizada requieren un prestador externo de firma electrónica acreditado (API/webhook); volúmenes documentales muy grandes pueden superar el límite de adjunto de 65 MB por archivo de Qntrl → DMS externo.
  1. Primero el catálogo. Inventariar cada trámite en papel actual; clasificar mantener-en-Expediente vs separar; este catálogo se vuelve el selector en Creator que gobierna todo el Board.
  2. Modelar en BPMN 2.0 el ciclo de vida genérico del expediente + las variaciones por tipo como subflujos, luego traducir a un Blueprint de Qntrl con rutas por criterios.
  3. Prototipar el portal del contribuyente en Creator/portal CRM para el estado en tiempo real; validar temprano con la DNIT la pregunta «qué ve el contribuyente».
  4. Especificar el contrato de interfaz de firma electrónica contra el prestador acreditado; marcar cada paso donde la firma es legalmente requerida vs opcional.
  5. Decidir la cuestión del DMS con evidencia — medir tamaños reales de documentos en la Fase 1 antes de comprometerse.
Qntrl — orquestación Creator — catálogo + portal WorkDrive — custodia Sign — flujo (cert. externo) Catalyst — OCR / índice
  • Prestador de firma electrónica acreditado — integración + costo por firma/licenciamiento.
  • DMS externo — solo si se alcanza el límite de 65 MB; decidir tras la medición de la Fase 1.
  • Motor de OCR / clasificación — ver las opciones del §07 (propio vs AWS/Google/Azure).
  • Herramienta de modelado BPMN — los diagramas son un entregable requerido que Qntrl no puede producir.
✎ Lluvia de ideas — Expediente Electrónicosaved ✓
2

Trámites Operativos Tributarios

Operational Procedures · ex-Formulario 10 y constancias públicas
Ajuste: bueno, con complementos
La consigna: permitir que los contribuyentes presenten electrónicamente y obtengan procesamiento automático/semiautomático de las operaciones del Formulario 10 (aplicación/anulación/corrección de DJ, copias de documentos, desbloqueo de RUC, depuración de cuenta, certificado de cumplimiento en controversia…), más una vía pública para personas/entidades que soliciten estados de cuenta, constancias de RUC, etc. — individuales o masivas, con revisión de confidencialidad para solicitudes de terceros.
nuevo Registradoformulario público · líneas AutovalidarDeluge · reglas ¿simple? Autoaprobar Análisis manual Aprob./Rech.notifica Registrado→ Marangatu síno / confidencial → revisión EXT · Marangatu tiempo real
automáticomanual/funcionariocompuertaexterno
Registrado → Autovalidación → (Autoaprobar | Análisis manual) → Aprobado/Rechazado → Registrado en sistema, ramificando por tipo de operación.
Qntrl answer · pp. 96–97
«Un solo Board de Qntrl puede replicar el Formulario 10 como un formulario multifuncional con una tabla de líneas para múltiples operaciones por solicitud y un Formulario Público para envío por el portal… Las Reglas de Negocio enrutan automáticamente los casos simples y Deluge valida contra reglas; las solicitudes masivas se manejan por líneas de tabla o la API REST.»
Formulario Público · portaltabla de líneas · Delugeacceso de terceros
Brecha que señalan: la verificación en tiempo real del estado de presentación/cumplimiento y los efectos en cuenta corriente requieren integración con Marangatu; la interfaz nativa de carga masiva es limitada y conviene complementarla con la API REST.
  1. Descomponer el Formulario 10 operación por operación; para cada una, definir entradas, reglas de validación, auto vs manual, y efecto en cuenta corriente.
  2. Dos vías, un modelo: vía del contribuyente autenticado + vía de solicitud pública (estados de cuenta, constancias de RUC). Modelar ambas, compartir el subflujo de emisión de constancias con el Proceso 4.
  3. Fijar temprano el contrato con Marangatu — es la dependencia crítica; especificar cada lectura (estado de cumplimiento) y escritura (registro) como una función de Catalyst.
  4. Diseñar lo masivo deliberadamente — líneas para lotes pequeños, vía REST/archivo para grandes; definir el umbral con la DNIT.
  5. Confidencialidad por diseño — roles de Directory + entregable de revisión normativa para el acceso de terceros.
QntrlCreatorFormsCatalyst → MarangatuDirectory
  • Integración con Marangatu — lecturas de estado de cumplimiento + escrituras de registro (la grande para este proceso).
  • API masiva / ingesta de archivos — más allá de la carga nativa por tabla.
  • Firma electrónica — donde los documentos emitidos la requieran.
  • Revisión normativa de las reglas de acceso confidencial de terceros (entregable de consultoría).
✎ Lluvia de ideas — Trámites Operativossaved ✓
3

Facilidades de Pago

Payment Facilities · planes de cuotas
Ajuste: bueno — la integración más pesada
La consigna: sistematizar, automatizar y digitalizar para todos los tipos de operación — incluidas las obligaciones de comercio exterior que hoy exigen presencia física — desde el ingreso pasando por la aprobación hasta el registro en cuenta corriente. Criterios de riesgo para solicitudes fuera del régimen general, más un subproceso que controla el cumplimiento y aplica caducidad por incumplimiento.
sol. Solicitadointerno/ext · marca ValidaciónDeluge · plan régimengeneral? Auto (gral.) Análisis de riesgo Pago inicialconfirmado Aprobado Registradocuenta corriente Subproceso: cumplimiento de cuotas · caducidad EXT · Marangatu + Aduanas EXT · motor de riesgo (opc.)
automáticofuncionario/riesgosubprocesoexterno
Solicitado → Validación → (Régimen general automático | Análisis de riesgo fuera de régimen → Aprobación) → Pago inicial → Aprobado → Registrado, con un subproceso de cumplimiento/caducidad.
Qntrl answer · pp. 97–99
«Board: selector de obligación, campos del plan de cuotas, fecha de pago inicial, marca comercio interno/exterior y documentos de respaldo… Deluge calcula/valida el plan; el enrutamiento por criterios maneja los casos fuera de régimen; las acciones programadas controlan el cumplimiento de cuotas y disparan la caducidad.»
Deluge — cálculo del planenrutamiento por criterios · acciones programadasMarangatu/aduanas
Brecha que señalan: la generación del cronograma de cuotas, el registro en cuenta corriente y el enlace con comercio exterior/aduanas dependen de la integración con Marangatu + aduanas; un scoring de riesgo avanzado más allá de criterios por reglas requeriría un motor externo de riesgo/IA.
  1. Separar las tres variantes de ingreso (origen DJ, fuera de régimen, comercio exterior) en el AS-IS, luego unificarlas en un solo Blueprint TO-BE con ramas.
  2. Mantener el cálculo donde es autoritativo. Si Marangatu es dueño de la matemática del plan, Qntrl orquesta y muestra; si no, Deluge calcula y registra. Definir con la DNIT — no asumir.
  3. Modelar explícitamente el subproceso de caducidad como funciones programadas de Catalyst contra los vencimientos de cuotas.
  4. Empezar por reglas en el riesgo; diseñar la compuerta para que un motor de scoring real pueda incorporarse luego sin reabrir el flujo.
  5. Eliminar el paso presencial de comercio exterior — este es el «logro» destacado a mostrar; mapear con cuidado el enlace aduanero.
QntrlCreator/DelugeCatalyst — Marangatu+AduanasAnalytics — monitoreo
  • Integración con Marangatu — registro del plan + efectos en cuenta corriente.
  • Integración con el sistema aduanero — obligaciones de comercio exterior (exclusivo de este proceso).
  • Webhook de detección de pago — red bancaria / de recaudación.
  • Motor externo de riesgo — opcional, si se desea scoring más allá de reglas.
  • Firma electrónica — en el documento de aprobación.
✎ Lluvia de ideas — Facilidades de Pagosaved ✓
4

Constancia de No Retención

Non-Withholding Certificate · IVA / Renta
Ajuste: bueno, con complementos
La consigna: unificar ambas situaciones del contribuyente (sin obligación activa vs activa con saldos a favor) en un solo proceso digital — ingreso con anexos, validación de requisitos, análisis, emisión. Vigencia redefinida por tipo de impuesto y mes de cierre (no fija al 31 dic). Criterios de riesgo para agilizar la resolución; registro completo del caso.
nuevo PresentadoIVA/Renta · anexos obligaciónactiva? Vía rápida Valid. requisitosanálisis · riesgo AnálisisAprob./Rech. Constancia emitidavigencia dinámica Notificadoregistro completo sin obligación → rápido EXT · gen. PDF + firma
vía rápidaanálisis completocompuertaexterno
Presentado → (vía rápida si no hay obligación activa | validación de requisitos → análisis) → Constancia emitida → Notificado.
Qntrl answer · pp. 99–100
«Board: selección de tipo de impuesto (IVA/Renta), condición del contribuyente, campos de saldo a favor, adjuntos obligatorios y campo de mes de cierre para la vigencia… Las Reglas de Negocio más criterios de riesgo enrutan los casos; se conserva nativamente un registro completo del caso con actores, fechas, comentarios y documentos; el correo notifica el resultado.»
formulario · criterios de riesgoregistro de caso nativoemitir + firmar (ext.)
Brecha que señalan: emitir efectivamente la constancia como PDF con formato (con vigencia dinámica) requiere una función personalizada junto a un servicio externo de generación de PDF/documentos; la firma electrónica nuevamente externa.
  1. Modelar las dos condiciones del contribuyente como un solo flujo con vía rápida — el caso «sin obligación activa» se resuelve automáticamente; el caso de saldo a favor recibe análisis completo.
  2. Codificar la vigencia como dato, no como fecha fija — una tabla de reglas indexada por tipo de impuesto + mes de cierre.
  3. Reutilizar el subflujo de emisión de constancias compartido con las constancias públicas del Proceso 2 — un componente de PDF+firma, muchos invocadores.
  4. Probar primero la combinación con Writer para el PDF; recurrir a un servicio externo solo si la fidelidad/volumen lo exige.
QntrlCreatorWriter — ¿combinar PDF?Sign (cert. ext.)
  • Generación de PDF / constancia — componente compartido con el Proceso 2.
  • Firma electrónica cualificada — si es legalmente requerida en la constancia.
  • Lectura de Marangatu — para verificar estado de obligaciones y saldos a favor.
✎ Lluvia de ideas — Constancia de No Retenciónsaved ✓
5

Seguimiento de Juicios en lo Contencioso Administrativo

Administrative Litigation Tracking
Ajuste: el mejor nativo — nuestra vitrina
La consigna: una plataforma única que reemplaza planillas, enlazada automáticamente con los procesos precedentes (fiscalización, sumarios, recursos, créditos), con designación de abogado, registro de eventos (fecha/hora/usuario), repositorio documental, control de plazos con alertas escalonadas, y tableros de desempeño/estadísticas. Evitar el vencimiento de plazos procesales.
Fiscalización Sumarios · Recursos Créditos fiscales procesos precedentes → enlace autom. reg. Abogado designadopor materia Seguim. eventosrecurrente · docs Control de plazosSLA · alertas Resuelto/Cerrado bucle de eventos hasta resolución Tablerosindicadores · estadísticas NATIVO · SLA + escalamiento
precedenteeventos recurrentesplazos (fortaleza nativa)
Registrado → Abogado designado → Seguimiento de eventos (recurrente) → Control de plazos → Resuelto/Cerrado, enlazado automáticamente a las cards precedentes. Casi enteramente nativo.
Respuesta Qntrl · pp. 100–101 · «el mejor ajuste nativo de Qntrl»
«Los SLA por etapa con recordatorios de vencimiento, anticipados y del día, y las alertas de escalamiento satisfacen directamente el requisito de control de plazos; la Cronología de Actividad centraliza todos los eventos en una plataforma; los Informes y Tableros proveen los indicadores y estadísticas solicitados.»
SLA · recordatorios · escalamientorepositorio doc.informes · tableros
Brecha que señalan (pequeña): solo la firma electrónica y cualquier interacción con la cuenta corriente necesitan un componente externo; ingerir datos de procesos previos puede requerir una integración ligera.
  1. Liderar aquí nuestra demostración de Qntrl. Integración casi nula, y resuelve visiblemente el dolor que la DNIT más siente (plazos vencidos).
  2. Construir el modelo de plazos con el especialista en legislación tributaria — duraciones legales → definiciones de SLA → escalera de escalamiento.
  3. Diseñar el enlace con precedentes primero como enlace blando (referencia + adjunto manual) y endurecerlo a integración solo donde exista una fuente digital.
  4. Co-diseñar el tablero con el área de juicios de la DNIT — los indicadores no sirven si no son los que usan los responsables.
Qntrl — núcleoWorkDriveAnalytics
  • Integración ligera con los procesos precedentes — solo donde ya sean digitales.
  • Firma electrónica — si los documentos del juicio la requieren.
  • Lectura de cuenta corriente — donde los importes sean relevantes.
  • El menor conjunto de brechas de los seis — por eso es la vitrina.
✎ Lluvia de ideas — Seguimiento de Juiciossaved ✓
6

Cuenta Corriente DNIT

Current Account · transversal
Ajuste: solo orquestador — respetar el límite
La consigna: cada proceso TO-BE registra sus eventos de obligación en la Cuenta Corriente; registrar/actualizar automáticamente las obligaciones, detectar el incumplimiento en tiempo real (Cumplido/Incumplido), integrar los registros y garantizar la trazabilidad completa de cada obligación desde su generación hasta su extinción.
Expediente Trámites Oper. Facilidades de Pago No Retención Juicios cada proceso emite eventos de obligación QNTRL hub Evento recibido → Consolidado → Transmitido MARANGATU sistema de registro saldos · compensación · prescripción Confirmaciónestado → procesos Cumplido/Incumplidotiempo real Trazabilidadgeneración → extinción SISTEMA DE REGISTRO — permanece aquí
orquestación QntrlMarangatu = librolímite
Evento recibido → Consolidado → Transmitido → Confirmación → Estado actualizado. Qntrl registra y enlaza; Marangatu sigue siendo el sistema de registro.
Qntrl answer · pp. 101–103
«Qntrl actúa como concentrador de orquestación, no como el libro de registro… Las Funciones Personalizadas consolidan múltiples acciones en una sola transmisión; los webhooks/REST envían y traen del libro autoritativo.»
funciones personalizadas · consolidarwebhooks enviar/traerconciliación
Límite estricto que declaran: el cálculo de obligaciones, los saldos en tiempo real, la compensación y la prescripción deben permanecer en Marangatu — Qntrl registra y enlaza pero no es, ni debe ser, el sistema de registro de la Cuenta Corriente.
  1. Tratar esto como una especificación de integración, no un proceso a automatizar. Nuestro entregable es el contrato de eventos que emite cada uno de los otros cinco procesos, y la lógica de consolidación.
  2. Respetar el límite con claridad. En la propuesta, declarar que Marangatu sigue siendo el libro de registro — señala que entendemos el dominio y reduce el riesgo de la oferta.
  3. Definir un esquema canónico de eventos de obligación que reutilicen los cinco procesos, para que la firma de automatización construya una integración, no cinco.
  4. Hacer de las capacidades reales de Marangatu una prioridad de relevamiento en la Fase 1 — todo lo posterior depende de ello.
Catalyst — funciones/webhooksQntrl — captura de eventosDataPrep — conciliarAnalytics — estado de cuenta
  • Integración con Marangatu — la mayor dependencia técnica de todo el trabajo; probablemente abarca nuestro alcance y el contrato de automatización.
  • Esquema de eventos y lógica de consolidación — nuestro entregable de diseño.
  • Herramienta de conciliación — DataPrep o equivalente.
  • Sin firma electrónica ni PDF aquí — este proceso es pura integración.
✎ Lluvia de ideas — Cuenta Corrientesaved ✓