DNIT — Six-Process Brainstorming Console

◆

How to use this console

Working method · not a deliverable

Each of the six process tabs has the same six panels, so you always know where to look. Open a tab, expand the panels you want, brainstorm in the yellow notes box (it saves as you type), and tick off questions as you resolve them.

Panel	What goes here
01 · The TDR ask	What DNIT literally requires for this process (TO-BE), in plain terms.
02 · Qntrl team's view	Exactly what the Zoho answer document says Qntrl does — the Board, Form, Blueprint stages — plus the fit rating.
03 · TO-BE flow	A stage pipeline for the process, marking where an external component is needed (red).
04 · Questions to resolve	The open decisions. Tick them off as we get answers from DNIT or internally.
05 · How we approach it	Our planned method and the apps assigned. Draft — edit freely.
06 · Gaps & decisions	The external add-ons / integrations to scope and price for this process.

Everything you type in a notes box and every checkbox is stored in this browser only (localStorage). Nothing is uploaded. Use “Print / Save PDF” from the browser to hand a snapshot around — printing expands every panel automatically.

Zoho's own assessment

Qntrl natively covers ≈72% of the automation scope, ≈88% once integrated with Marangatu and two add-ons — but only ≈45–50% of the full RFP. The rest is our consulting work: AS-IS survey, BPMN 2.0 modelling, manuals, regulations, UI/UX, training, change management. Keep that split in view while brainstorming: the platform is the engine, not the bid.

✎ Cross-cutting notes (apply to all six)saved ✓

Electronic File

Expediente Electrónico DNIT · the container process

Fit: good, with add-ons

The ask: receive, manage, process, store and deliver every filing digitally, with guaranteed traceability and document inviolability, real-time status for taxpayer/operator/third party/internal units, and a living catalogue of procedures. Procedures better served on their own (Form 10, payment facilities, non-withholding) split off.

Qntrl stagework/handoffexternal component

Qntrl Blueprint per the Zoho note — Submitted → Under review → Processing → Resolution → Closed, with route-back. Red = not native.

Qntrl answer · pp. 95–96

“Fully achievable as a Qntrl Board: a procedure-type picker form with taxpayer/RUC lookup, dynamic sections per procedure and attachment fields; Blueprint stages Submitted → Under Review → Processing → Resolution → Closed, with route-back for corrections and distinct paths per procedure type via criteria. SLA per stage, auto-acknowledge email, and the Activity/Stage Timeline give real-time status and an inviolable audit trail.”

Board · Blueprint · SLA

dynamic form · catalogue

attachments

e-signature (ext.)

Gap they flag: legally binding digital signature + guaranteed inviolability need an external qualified e-signature provider (API/webhook); very large document volumes may exceed Qntrl's 65 MB per-file attachment limit → external DMS.

How many distinct trámite types exist today, and which stay under “Expediente” vs split into their own automated process? (This defines the whole catalogue.)
What is the realistic max attachment size and total case volume? Do we cross the 65 MB/file limit → is a DMS in scope?
Which MIC-accredited e-signature provider (Ley 4017) do we integrate, and does DNIT already have one?
Which internal DNIT areas receive handoffs, and what SLA per stage does each accept?
What exactly must a taxpayer see as “real-time status” — stage name only, or estimated dates / pending actions too?
Retention & inviolability: what legal retention period and tamper-evidence does DNIT require on stored documents?

Catalogue first. Inventory every current paper trámite; classify keep-in-Expediente vs split-out; this catalogue becomes the Creator picker that drives the whole Board.
Model in BPMN 2.0 the generic file lifecycle + the per-type variations as sub-flows, then translate to one Qntrl Blueprint with criteria-based paths.
Prototype the taxpayer portal in Creator/CRM portal for real-time status; validate the “what does the taxpayer see” question with DNIT early.
Specify the e-signature interface contract against the accredited provider; mark each step where signature is legally required vs optional.
Decide the DMS question on evidence — measure real document sizes in Phase 1 before committing.

Qntrl — orchestration

Creator — catalogue + portal

WorkDrive — custody

Sign — workflow (cert. external)

Catalyst — OCR / index

Qualified e-signature provider — integration + per-signature/licensing cost.
External DMS — only if the 65 MB limit is hit; decide after Phase 1 measurement.
OCR / classification engine — see Process-wide §07 options (in-house vs AWS/Google/Azure).
BPMN modelling tool — the diagrams are a required deliverable Qntrl can't produce.

✎ Brainstorm — Electronic Filesaved ✓

Operational Tax Procedures

Trámites Operativos Tributarios · ex-Form 10 & public certificates

Fit: good, with add-ons

The ask: let taxpayers file electronically and get automatic/semi-automatic processing of the Form 10 operations (DJ application/annulment/correction, doc copies, RUC unblocking, account clean-up, compliance certificate under dispute…), plus a public track for persons/entities requesting statements, RUC certs, etc. — individually or in bulk, with confidentiality review for third-party requests.

automaticmanual/officergatewayexternal

Registered → Auto-validation → (Auto-approve | Manual analysis) → Approved/Rejected → Posted, branching by operation type.

Qntrl answer · pp. 96–97

“A single Qntrl Board can replicate Form 10 as a multifunctional form with a line-item table for multiple operations per request and a Public Form for portal submission… Business Rules auto-route simple cases and Deluge validates against rules; bulk requests are handled via table line items or the REST API.”

Public Form · portal

line-item table · Deluge

3rd-party access

Gap they flag: real-time verification of filing/compliance status and current-account effects requires Marangatu integration; the native bulk-entry UI is limited and best complemented by the REST API.

Full list of operations in scope — the TDR gives examples (“…y otros que la consultoría identifique”). What's the confirmed set?
Which operations can be fully auto-approved vs always need an officer? (Defines the gateway rules.)
What Marangatu endpoints exist today for compliance status / posting — or must DNIT build them? Who owns that API?
Bulk requests: expected volume per submission? Does the line-item table suffice or do we need an API/file-upload path?
Third-party / public-entity requests: what confidentiality rules govern access, and what legal review does the TDR expect us to propose?
Is the “Tercero Autorizado” mandate applicable to each operation? (Must be reflected in specs & use cases.)

Decompose Form 10 operation by operation; for each, define inputs, validation rules, auto vs manual, and current-account effect.
Two tracks, one model: authenticated taxpayer track + public-request track (statements, RUC certs). Model both, share the certificate-issuance sub-flow with Process 4.
Nail the Marangatu contract early — this is the critical dependency; specify each read (compliance status) and write (posting) as a Catalyst function.
Design bulk deliberately — line items for small batches, REST/file path for large; decide threshold with DNIT.
Confidentiality by design — Directory roles + legal review deliverable for third-party access.

Qntrl

Creator

Forms

Catalyst → Marangatu

Payment Facilities

Facilidades de Pago · installment plans

Fit: good — heaviest integration

The ask: systematise, automate and digitalise for all operation types — including foreign-trade obligations that today need an in-person visit — from intake through approval to current-account posting. Risk criteria for non-standard requests, plus a subprocess monitoring compliance and applying lapse on default.

automaticofficer/risksubprocessexternal

Requested → Validation → (General auto | Non-standard risk analysis → Approval) → Initial payment → Approved → Posted, with a compliance/lapse subprocess.

Qntrl answer · pp. 97–99

“Board: obligation selector, installment-plan fields, initial-payment date, domestic/foreign-trade flag and supporting documents… Deluge computes/validates the plan; criteria-based routing handles non-standard cases; scheduled actions monitor installment compliance and trigger lapse.”

Deluge — plan calc

criteria routing · scheduled actions

Marangatu/customs

Gap they flag: installment-schedule generation, current-account posting and foreign-trade/customs linkage depend on Marangatu + customs integration; advanced risk scoring beyond rule-based criteria would need an external risk/AI engine.

Where does the installment schedule get computed — Deluge, or must Marangatu remain authoritative and we just display/confirm?
Foreign-trade path: what's the exact current customs-dispatch dependency, and can it truly go paperless end-to-end?
What defines “non-standard” (cuota inicial %, nº cuotas, periodicidad)? These become the routing criteria.
Do we need real risk scoring here, or do rule-based criteria suffice for v1? (Ties to §07 risk options.)
Lapse subprocess: what are the exact caducidad rules on missed installments, and what current-account action do they trigger?
Initial-payment confirmation — how do we detect payment in real time (bank/Marangatu webhook)?

Separate the three intake variants (DJ-origin, non-standard, foreign-trade) in the AS-IS, then unify them into one TO-BE Blueprint with branches.
Keep computation where it's authoritative. If Marangatu owns the plan maths, Qntrl orchestrates and displays; if not, Deluge computes and posts. Decide with DNIT — don't assume.
Model the lapse subprocess explicitly as scheduled Catalyst functions against installment due-dates.
Start rule-based on risk; design the gateway so a real scoring engine can slot in later without reopening the flow.
Kill the in-person foreign-trade step — this is the headline “win” to showcase; map the customs linkage carefully.

Qntrl

Creator/Deluge

Catalyst — Marangatu+Aduanas

Analytics — monitoreo

Marangatu integration — plan posting + current-account effects.
Customs system integration — foreign-trade obligations (unique to this process).
Payment-detection webhook — bank / collection network.
External risk engine — optional, if scoring beyond rules is wanted.
E-signature — on the approval document.

✎ Brainstorm — Payment Facilitiessaved ✓

Non-Withholding Certificate

Constancia de No Retención · VAT / Income

Fit: good, with add-ons

The ask: unify both taxpayer situations (no active obligation vs active with credit balances) into one digital process — intake with annexes, requirement validation, analysis, issuance. Validity redefined by tax type & closing month (not fixed 31 Dec). Risk criteria to speed resolution; full case log.

fast pathfull analysisgatewayexternal

Submitted → (fast path if no active obligation | requirement validation → analysis) → Certificate issued → Notified.

Qntrl answer · pp. 99–100

“Board: tax-type selection (VAT/Income), taxpayer condition, credit-balance fields, mandatory attachments and closing-month field for validity… Business Rules plus risk criteria route cases; a full case log of actors, dates, comments and documents is retained natively; email notifies the outcome.”

form · risk criteria

case log native

issue + sign (ext.)

Gap they flag: actually issuing the certificate as a formatted PDF (with dynamic validity) needs a custom function paired with an external PDF/document-generation service; e-signature again external.

Exact rule for dynamic validity by tax type & closing month — get the table from DNIT.
What documentary annexes are required for the “active obligation + credit balance” case, and can any be auto-verified?
Which PDF/doc-generation approach — Zoho Writer merge, Catalyst function, or external service? (Cost + fidelity.)
What risk criteria legitimately speed resolution here without creating an appealable adverse decision?
Does the certificate need qualified e-signature to be legally valid, or is a sealed PDF enough?

Model the two taxpayer conditions as one flow with a fast path — the “no active obligation” case auto-resolves; the credit-balance case gets full analysis.
Encode validity as data, not a hard-coded date — a rule table keyed by tax type + closing month.
Reuse the certificate-issuance sub-flow shared with Process 2's public certificates — one PDF+signature component, many callers.
Test Writer merge first for the PDF; fall back to an external service only if fidelity/volume demands it.

Qntrl

Creator

Writer — PDF merge?

Sign (ext. cert.)

PDF / certificate generation — shared component with Process 2.
Qualified e-signature — if legally required on the certificate.
Marangatu read — to verify obligation status & credit balances.

✎ Brainstorm — Non-Withholding Certificatesaved ✓

Administrative Litigation Tracking

Seguimiento de Juicios

Fit: strongest native — our showcase

The ask: one platform replacing spreadsheets, auto-linked to precedent processes (audit, sumarios, recursos, créditos), with counsel assignment, event log (date/time/user), document repository, deadline control with escalating alerts, and performance/statistics dashboards. Avoid missed procedural deadlines.

precedentrecurring eventsdeadline (native strength)

Registered → Counsel assigned → Event tracking (recurring) → Deadline monitoring → Resolved/Closed, auto-linked to precedent cards. Almost entirely native.

Qntrl answer · pp. 100–101 · “Qntrl's strongest native fit”

“Stage SLAs with deadline, early and day-of reminders and escalation alerts directly satisfy the deadline-monitoring requirement; the Activity Timeline centralizes all events on one platform; Reports and Dashboards supply the indicators and statistics requested.”

SLA · reminders · escalation

doc repository

reports · dashboards

Gap they flag (small): only e-signature and any current-account interaction need an external component; ingesting data from prior processes may require light integration.

How are precedent processes stored today — are they even digital yet? “Auto-link” assumes a source to link to.
What are the procedural deadline types & legal durations that drive the alerts? (Get the list from the legal team.)
Escalation ladder: who gets alerted at early / day-of / overdue, and through which channel?
Which performance indicators & statistics does DNIT actually want on the dashboard?
Should this be our live demo for DNIT? (Lowest integration, highest native impact — strong candidate.)

Lead our Qntrl demonstration here. Near-zero integration, and it visibly solves the pain DNIT feels most (missed deadlines).
Build the deadline model with the tax-law specialist — legal durations → SLA definitions → escalation ladder.
Design the precedent-link as a soft link first (reference + manual attach) and harden to integration only where a digital source exists.
Co-design the dashboard with DNIT's litigation area — indicators are worthless if they're not the ones managers use.

Qntrl — core

WorkDrive

Analytics

Light integration to precedent processes — only where they're already digital.
E-signature — if litigation documents require it.
Current-account read — where amounts are relevant.
Smallest gap set of all six — which is exactly why it's the showcase.

✎ Brainstorm — Litigation Trackingsaved ✓

Current Account

Cuenta Corriente DNIT · cross-cutting

Fit: orchestrator only — respect the boundary

The ask: every TO-BE process records its obligation events in the Current Account; auto-register/update obligations, detect non-compliance in real time (Cumplido/Incumplido), integrate records, and guarantee full traceability of each obligation from generation to extinction.

Qntrl orchestrationMarangatu = ledgerboundary

Event received → Consolidated → Transmitted → Confirmation → Status updated. Qntrl records and links; Marangatu stays the system of record.

Qntrl answer · pp. 101–103

“Qntrl acts as an orchestration hub, not the ledger of record… Custom Functions consolidate multiple actions into a single transmission; webhooks/REST push to and pull from the authoritative ledger.”

custom functions · consolidate

webhooks push/pull

reconciliation

Hard boundary they state: obligation computation, real-time balances, offsetting and statute-of-limitations must remain in Marangatu — Qntrl records and links but does not, and should not, become the system of record for the Current Account.

What exactly does Marangatu expose today — read APIs? write APIs? webhooks? Or nothing, and DNIT must build them?
This is the make-or-break dependency for four of the six processes. Who on DNIT's side owns the Marangatu integration, and is it funded in the separate automation contract or ours?
For each process: which obligation events must post, and can they be consolidated into one transmission (as the TDR allows)?
Real-time Cumplido/Incumplido — is that computed in Marangatu and pushed to us, or must we derive it?
Traceability generation→extinction: what event schema does DNIT want, and does Marangatu already hold the link keys?

Treat this as an integration specification, not a process to automate. Our deliverable is the event contract each of the other five processes emits, and the consolidation logic.
Respect the boundary loudly. In the proposal, state that Marangatu remains the ledger — it signals we understand the domain and de-risks the bid.
Define one canonical obligation-event schema that all five processes reuse, so the automation firm builds one integration, not five.
Make Marangatu's real capabilities a Phase-1 discovery priority — everything downstream depends on it.

Catalyst — functions/webhooks

Qntrl — event capture

DataPrep — reconcile

Analytics — account statement

Marangatu integration — the single largest technical dependency in the whole engagement; likely straddles our scope and the automation contract.
Event schema & consolidation logic — our design deliverable.
Reconciliation tooling — DataPrep or equivalent.
No e-signature or PDF here — this process is pure integration.

✎ Brainstorm — Current Accountsaved ✓