A read-back of your functional requirements and RFI — what we understand you need, what Zoho Creator does natively, what has to be engineered, and the three decisions that shape the whole build.
Prepared for ETRAM Inversiones · attn. Darlington Mars · by Aman Shukla, Zoho Creator Certified Developer · August 2026 Assessed against Documento de Requerimientos Funcionales y RFI, 18 August 2026
Your operating principle, preserved end to end: the manager originates and authorises → the operator executes and documents → the system applies money by age → the manager reviews, approves and reconciles. Nothing advances without evidence, nothing balances by opinion, and every figure traces back to a source document.
What you asked for
Every flow below restates your RFI in plain terms — the conduce, the FIFO rule, the consolidated remittance, the 48-hour clock and the intercontinental replica — traced back to the section it came from.
What it means in the build
Against each requirement, how it would actually be implemented in Zoho Creator, and where the platform does the work for us versus where we have to engineer it ourselves.
Click any step
Tap any stage in a flow to open its detail, and any diagram card to view the full process diagram. Your sixteen RFI questions are answered in full further down.
Feasibility at a glance
Five honest verdicts before anything else.
We would rather tell you now which parts of your RFI are routine and which are not. Four of the five areas are well within Zoho Creator. One is not native to Zoho at all, and it happens to be the one you flagged as critical.
Buildable as specified
Conduces, payments, FIFO, remittances, 48-hour control
The whole transactional core — ledgers, allocation by age, balanced remittances, aging alerts, made-by / reviewed-by / authorised-by — is standard Zoho Creator work using forms, Blueprint and Deluge.
Buildable as specified
Roles, audit trail and reporting
Two named users, stage-gated permissions, no self-approval, an immutable change log and the full dashboard and export set are all native platform capability.
Buildable — needs a defined approach
OCR of the Cumayasa liquidation
Creator's built-in OCR field returns raw text, not a validated table of customer lines. Extracting every line reliably needs a document-AI step plus a mandatory review screen. Accuracy is controlled by the review gate, not promised by the OCR.
Buildable — needs a defined approach
Offline field operation
Creator's mobile app does support offline submission and camera capture, but offline lists are a periodic snapshot. FIFO must therefore be applied server-side on sync, with an idempotency key per record to prevent duplicates.
Not native to Zoho
Replica outside the primary continent
Every Zoho data-centre pair sits inside one continent — US is Quincy and Dallas, Europe is Amsterdam and Dublin. Your requirement cannot be met by Zoho alone; it needs an ETRAM-owned export pipeline to a second continent.
The end-to-end operation
Six stages, from the Cumayasa liquidation to a closed reconciliation.
RFI section 3.1 · made by / reviewed by / authorised by
● View diagram
Flow 01
Liquidation Import & OCR
Powered by
● Click a step for details
1
+
Upload Source
Creator
The manager uploads the capture, image or PDF of the liquidation authorised by Cumayasa — one upload per daily batch
The original file is stored permanently and never overwritten; it becomes the head of the evidence chain for every line it produces
The physical dispatch does not wait on this step — the office continues while the batch is being registered, exactly as RFI section 2 requires
→
2
+
Extract Lines
Document AI
The document is passed to a document-AI extraction step that returns the batch header plus one row per customer line: conduce number, date and time, customer, product, gallons, price, discount and total
Creator's built-in OCR field alone returns unstructured text — sufficient for a single reference number, not for a multi-customer liquidation. We therefore treat extraction as a service call, not a form field
Every extracted value is stored alongside a confidence score so the review screen knows what to highlight
→
3
+
Validate
Deluge
Conduce number mandatory and not already present in the system — duplicate batches are rejected at the door
Date and time cannot be in the future; the 48-hour clock starts from confirmed dispatch, not from upload
Customer matched against the master file, with suggested near-matches when the name is not exact; product must belong to the authorised catalogue
Gallons positive and numeric; price compared against the price in force with a variance alert; discount applied only where permitted
Line total recalculated as quantity × price − discount, and the batch total recalculated as the sum of all lines
→
4
+
Review Screen
Creator
Extracted data is shown to the manager before anything is saved as final — side by side with the original document
The manager can correct any line. The original document, the original extracted value, the corrected value, the user and the timestamp are all retained
This screen is what makes OCR accuracy a manageable risk rather than a promise — nothing reaches the ledger unreviewed
→
5
+
Balance Check
Deluge
The sum of all individual conduces must equal the batch total exactly — the control you asked for in RFI section 5
Where there is any difference between debits and credits, definitive acceptance is blocked. The batch stays in review, it does not pass with a warning
The out-of-balance amount is displayed so the manager can see precisely which line to inspect
→
6
+
Seal Evidence
WorkDrive
Source document, extracted payload, correction history and approval are linked as a single audit chain against the batch
Files are held in a structured folder tree by date and batch, and included in the continuity export described in Flow 06
Nothing in this chain can be deleted by either user role once written
Your requirement
The manager uploads a capture, image or PDF of the daily liquidation and OCR extracts and organises every conduce automatically
Both the header and each customer line must be extracted, reducing manual typing before authorisation
The system validates each field, flags doubtful ones and recalculates every total
The sum of individual conduces must match the day's total settlement exactly
The original document and the traceability of any correction must be preserved
What it means in the build
Batch header and line-detail structure, with the source file stored permanently against the batch
Document-AI extraction called from Deluge, returning structured lines with per-field confidence — not the native OCR field alone
Nine validation rules from RFI section 5 implemented as blocking checks, not warnings
A side-by-side review screen with highlighted doubtful fields and full correction history
Hard balance gate: the batch cannot become an authorised dispatch while any difference exists
Fuzzy customer matching with suggestions, and a price-variance alert against the price in force
Flow 02
Authorisation & Delivery
Powered by
● Click a step for details
1
+
Price in Force
Creator
Current price per fuel and oil, applicable discount, effective date and time, and the user who authorised it
Prices are versioned, never edited in place — a conduce always resolves against the price that was in force at its dispatch time
Only the manager can set or change a price; the operator has no access to pricing at all
→
2
+
Authorise Batch
Blueprint
The manager executes the single transition that moves the batch to Dispatch authorised
The transition is permission-gated to the manager role — the operator cannot see or execute it under any circumstance
The transition cannot fire while the batch is out of balance, contains an unmatched customer, or holds an unresolved doubtful field
→
3
+
Operator Sees It
Creator Mobile
Only authorised dispatches appear on the operator's mobile list — this is the acceptance criterion in RFI section 14
Batches still in import, review or out-of-balance state are invisible to the operator, not merely read-only
The list is ordered by dispatch date so the oldest work surfaces first
→
4
+
Confirm Delivery
Creator Mobile
The operator confirms each conduce as delivered, not delivered, or delivered with an incident
An incident requires a reason and optionally a photograph — it does not silently pass
Drivers and helpers make the physical delivery but never touch the system, exactly as RFI section 3 specifies
→
5
+
Start the Clock
Deluge
Confirmed delivery opens the receivable for that conduce and starts its 48-hour clock
The receivable is registered per customer and per conduce — individual, not aggregated — as required by your accounting model
The corresponding payable to the fuel supplier is registered against the same batch
→
6
+
Exception Tray
Cliq / Email
Anything that did not go to plan — not delivered, incident, unmatched customer, price variance — lands in the manager's exception tray
Management works from exceptions rather than reading every record, which is the control model recommended in RFI section 3.1
Notifications go out by email and optionally WhatsApp-style chat, without requiring either user to sit in the app
Your requirement
The manager reviews, accepts the relation and authorises the release of fuel
The operator may only see and execute dispatches that were previously authorised
Register an individual receivable for each customer and conduce, and the payable to the supplier
Controlled states and transitions must prevent any stage being skipped
Management works primarily from a tray of exceptions
What it means in the build
Blueprint states with role-gated transitions — the operator's screen simply has no authorise action
Versioned price master; conduces resolve against the price in force at dispatch time
Per-conduce receivable ledger plus per-batch payable to the supplier, both posted on delivery confirmation
Delivery confirmation with delivered / not delivered / incident, reason and optional photograph
RFI section 7.3 · RD$60,000 split across five customers
● View diagram
Operator-held cash versus company-received cash
RFI section 7.3 · transitional account treatment
● View diagram
Your requirement
The operator registers one total deposit, attaches a single proof and distributes it across the customers included
The remittance cannot be closed or submitted if the sum of assignments does not match the deposit exactly
Within each customer, the assigned amount is applied by the same oldest-first rule
The same payment or conduce may never be used twice across different remittances
Management can observe a single line without rejecting the whole remittance
Distinguish money the customer paid the operator from money the operator transferred to ETRAM
What it means in the build
Header and detail structure with a live amount left to distribute figure
Hard gate on the submit transition — draft cannot leave draft while out of balance
Cross-remittance uniqueness enforced at save, so double-use is prevented rather than detected
Nested FIFO: distribute to customers, then apply by age within each customer
Transitional account for operator-held funds, with its own pending-transfer report
Line-level observe status, with full version history on any post-submission correction
Six state values on the header: draft, balanced, submitted, observed, validated, reconciled
Flow 05
Review, Reconciliation & the 48-Hour Clock
Powered by
● Click a step for details
1
+
Daily Tray
Creator
One daily tray showing every deposit registered by the operator, with customers included, dates, amounts and proofs
The manager reviews before approving — nothing is auto-approved on the operator's word
The tray is filtered by state so the manager sees only what needs a decision today
→
2
+
Four Outcomes
Blueprint
Approve, observe, return or reject — each with a mandatory reason where the outcome is not a clean approval
The operator can never approve their own record; the transition is not available to their role
Observed and returned records go back to the operator with the reason visible, and retain their full history
→
3
+
Three-Stage Truth
Deluge
The system distinguishes reported, validated and actually reconciled — three different figures, never merged into one
Reconciliation confirms the proof, the reference, the amount, the assignments and the effective receipt by ETRAM Inversiones
Only reconciliation closes the conduce's clock; a reported payment does not stop the countdown
→
4
+
Aging Engine
Deluge
A scheduled job recalculates the age of every open conduce and assigns its band: 0–24, 24–40, 40–48 or over 48 hours
Bands drive colour, priority and escalation — green, yellow, orange, red
The clock runs from confirmed dispatch, not from import, and stops only on reconciliation
→
5
+
Escalate & Block
Cliq / Email
Yellow at 24 hours to operator and management, orange at 40 hours as a priority alert
Beyond 48 hours the customer moves to action required, with a preventive block on any new dispatch to them
The block can be lifted only by an authorised exception, which records who authorised it, when and why
→
6
+
Reports & Export
Analytics
Daily, weekly and monthly views of conduces, gallons, values, collections and deposits
Customer consumption, average payment time and count of 48-hour breaches per customer
Detail of how each payment was applied — conduces settled, partial credits and remainders
Export to Excel, CSV and PDF, with complete traceability of every operation
Process diagrams
The review chain and the aging control from RFI sections 3.1 and 8.
Made by, reviewed by, authorised by
RFI section 3.1 · no stage skipping, no self-approval
● View diagram
48-hour aging, alerts and preventive block
RFI section 8 · 0-24, 24-40, 40-48, over 48
● View diagram
Reported, validated, reconciled — three distinct figures
RFI section 8 · what actually stops the clock
● View diagram
Your requirement
A managerial tray to review, approve, observe or return the charges registered by the operator
Traceability under made by / reviewed by / authorised by across the whole process
Distinguish reported payment, validated payment and effectively reconciled payment
Alerts at 24, 40 and 48 hours, with red status and preventive block beyond 48
Full report set: paid and pending customers, daily, weekly and monthly figures, export and complete traceability
What it means in the build
Daily review tray with four outcomes and mandatory reasons on anything other than approval
Role-gated transitions so the operator has no approval path to their own records
Three separate payment states, with only reconciliation stopping the aging clock
Hourly scheduled aging job driving four bands, colour coding and escalation
Preventive dispatch block beyond 48 hours, lifted only by a recorded authorised exception
Dashboard set plus Excel, CSV and PDF export, and a per-payment application detail report
Immutable log of creation, modification, approval and cancellation across every record
Flow 06
Architecture, Continuity & Audit
Powered by
● Click a step for details
1
+
Primary Platform
Zoho Creator
The application, database and documents live in one Zoho data-centre region, selected by ETRAM at sign-up
Zoho operates each region as a primary and secondary pair — for example Quincy and Dallas in the United States, or Amsterdam and Dublin in Europe
Both members of every pair sit on the same continent. This is the crux of your critical requirement
→
2
+
Export Pipeline
Deluge / Scheduler
A scheduled job exports the full data set — customers, prices, conduces, payments, allocations, remittances and audit log — on a fixed cycle
A second job exports the document store: source liquidations, deposit slips and delivery photographs
Each export carries a manifest and checksum so a restore can prove it is complete before anyone relies on it
→
3
+
Off-Continent Vault
External object storage
Exports land in object storage on a different continent from the Zoho region — for instance a Zoho region in North America paired with European storage
The bucket is owned by ETRAM Inversiones directly, not by the developer, and is versioned and encrypted at rest
Object-lock or immutability protects the archive against deletion, including by a compromised administrator account
→
4
+
Restore Drill
Documented procedure
A written restore procedure, executed and evidenced at least twice a year as your RFI requires
The drill proves the archive is readable, complete and sufficient to rebuild — not merely that files exist
Results are documented with date, operator, duration achieved and any gaps found
→
5
+
Security & Access
Zoho / Creator
Encryption in transit and at rest, multi-factor authentication, least-privilege roles and session control
Separate development and production environments, so nothing is tested against live data
Retention rules applied to both the live system and the off-continent archive
→
6
+
Ownership
Governance
The Zoho account, the application, the data, the storage bucket and the administrative credentials are registered to ETRAM Inversiones
The developer works under a named user inside your account, which you can revoke at any time
Full export of data, attachments, configuration and documentation is possible without the developer's involvement
Process diagrams
The continuity architecture — the one requirement Zoho cannot satisfy on its own.
Why Zoho alone does not meet the requirement
RFI section 10 · verified against Zoho's published data-centre list
● View diagram
Proposed intercontinental continuity architecture
RFI section 10 · export, vault, verify, restore
● View diagram
Three continuity tiers — what each actually protects
RFI section 10 and question 4 · a decision ETRAM must make
● View diagram
Your requirement
Database and documents hosted in the cloud, with a replica or recovery copy in a data centre outside the continent of the primary — two centres inside the United States or North America is explicitly not sufficient
Identify provider, country, region and continent for both primary and replica
State RPO and RTO, encryption, access management, MFA, audit log and retention
Documented restoration tests at least twice a year
Complete, legible export of data, attachments, configuration and documentation
The account, application, data and administrative credentials belong to ETRAM Inversiones
What it means in the build
Honest answer first: Zoho's data-centre pairs are intra-continental, so this requirement is not met natively and no vendor can truthfully claim otherwise
An engineered export pipeline out of Creator into ETRAM-owned object storage on a second continent
Manifest and checksum on every export, with automated verification and an alert when verification fails
Versioning, encryption at rest and object-lock immutability on the archive
RPO and RTO committed by us against the chosen tier, since Zoho publishes no customer SLA for this
Written restore procedure with twice-yearly drills and an evidence pack
All assets registered to ETRAM; the developer operates under a revocable named user
Roles & separation of duties
Two users, three clean boundaries.
Your RFI section 3.1 rejects the model where the operator originates and approves everything. We agree, and the permission model below is what enforces it — the operator does not have a restricted approval button, they have no approval button at all.
Manager-administrator
Web · originates and authorises
Imports the Cumayasa liquidation and reviews the extracted lines
Creates and authorises dispatches; sets and versions prices
Reviews and approves payments and remittances; observes or returns individual lines
Reconciles, authorises exceptions and lifts 48-hour blocks
Consults every report and export
Cannot: delete the audit history, or approve any record without the date, user and evidence being retained alongside it.
Operator-supervisor
Mobile · executes and documents
Consults authorised dispatches only
Confirms delivery, non-delivery or incident
Registers individual payments and creates consolidated remittances
Attaches proofs and captures deposit slips by camera
Consults their own records and pending items
Cannot: create or authorise a dispatch, definitively approve their own payments, delete operations, alter prices, or unblock an overdue customer.
Drivers & helpers
No system access at all
Make the physical delivery
Are not licensed users and hold no credentials
Appear in the system only where a delivery record names them, if you choose to capture that
Cannot: access the application or consult any data — confirmed as an explicit scope boundary in RFI section 3.
The data model behind it
Twelve structures carry the whole operation.
Nothing here is speculative — each one maps directly to a numbered module in RFI section 4. The two that deserve attention are the allocation ledger and the audit log, because they are what make the FIFO rule provable rather than merely calculated.
Customers
Code, name, phone, status, balance and overdue events
Products
Authorised catalogue of fuels and oils
Prices
Versioned price and discount, effective from, authorised by
Dispatch batch
Cumayasa header, source file, totals and state
Conduce
Line detail — customer, product, gallons, price, discount, total
Extraction log
Raw OCR payload, confidence and every correction made
Delivery
Delivered, not delivered or incident, with reason
Receivable ledger
One open balance per customer per conduce
Payments
Amount, date, bank, reference, proof, receiving account, state
Allocations
Payment to conduce, amount applied, balance before and after
Remittances
Header plus customer assignment lines and balance control
Audit log
User, action, record, old value, new value, timestamp
Your sixteen questions, answered
Section 13 of your RFI, taken one at a time.
Answers marked Confirmed are verified against Zoho's published documentation. Those marked To confirm need written confirmation from Zoho or a decision from ETRAM before they can be committed contractually — we have said so rather than guessed. Commercial questions are answered structurally here; figures follow the discovery workshop.
No — and this is the single most important finding in this document. Zoho operates each region as a primary and secondary pair, and every published pair sits within one continent: the United States region is Quincy and Dallas, Europe is Amsterdam and Dublin, India is Mumbai and Chennai, Australia is Sydney and Melbourne, Canada is Toronto and Montreal, Japan is Tokyo and Osaka.
Your document specifically anticipates this by stating that two centres inside the United States or inside North America is not sufficient. That is exactly the situation Zoho's own topology produces. Any supplier who answers this question with an unqualified yes should be asked to put the specific city pair in writing.
What Zoho does provide natively is application backup — the application structure, Deluge scripts and data as CSV files, downloadable as a zip and schedulable at a chosen frequency. That is a genuine and useful capability, but the destination is your download, not another continent. Getting it to another continent is the engineering work described in question 2.
A scheduled export pipeline running out of Creator into object storage owned directly by ETRAM Inversiones on a second continent. If the Creator application sits in the United States region, the archive sits in Europe; the pairing is chosen by you in discovery.
The pipeline has four parts: a scheduled export of all transactional data, a scheduled export of the document store — source liquidations, deposit slips and delivery photographs, which the standard Creator backup does not fully cover — a manifest and checksum written with each export, and an automated verification step that alerts you when an archive fails its integrity check. Storage is versioned, encrypted at rest and protected by object-lock so the archive cannot be deleted even by a compromised administrator account.
Suitable destinations include AWS S3 in Ireland or Frankfurt, Azure Blob Storage in West Europe, Google Cloud Storage in europe-west, or Cloudflare R2. Any of them satisfies the intercontinental test against a North American Zoho region. Storage cost at your data volumes is small; the substance of the cost is the engineering and the drill discipline, and it is quoted after you choose the tier described in question 4.
Zoho does not publish a customer-facing RPO and RTO for Creator that would cover the scenario you are protecting against, so it would be misleading to quote one as if it were theirs. What can be committed is the RPO and RTO of the pipeline we build, because those are determined by design choices you control.
RPO equals the export interval. A daily cycle means a worst-case loss of one day; an hourly incremental cycle for documents and transactions reduces that to roughly one hour. Both are achievable — the choice is a cost and complexity decision, not a technical limit.
RTO depends entirely on the continuity tier you select in question 4. Tier A restores your data but rebuilding a running application still depends on Zoho being available. Tier B holds a drill-tested rebuild package so the application can be recreated in a different Zoho region within an agreed window. Tier C maintains an independent runtime and offers the shortest RTO at the highest ongoing cost.
We would commit these figures contractually against the chosen tier and prove them in the twice-yearly restore drill. Zoho's own platform availability remains governed by Zoho's standard terms, which are separate and should be reviewed by ETRAM directly.
This question deserves a distinction that is easy to blur. An archive of CSV files and documents on another continent guarantees your data survives. It does not, by itself, give you a running system — because restoring into Creator requires Creator to be available.
So the honest answer depends on which failure you are actually insuring against, and there are three tiers:
Tier A — data survivability. Encrypted, verified exports on a second continent. Protects against data loss, corruption, accidental deletion and account compromise. Fastest to deliver and lowest cost. Rebuilding the application still assumes Zoho exists.
Tier B — tested rebuild package. Tier A plus a versioned application definition and import scripts, drill-tested, so the application can be recreated in a different Zoho data centre within an agreed target time. This is the tier we would recommend for an operation of your size.
Tier C — independent runtime. Transactional data mirrored to an independent stack on the other continent that can be brought up if Zoho itself is unavailable as a platform. Shortest RTO, highest cost and permanent additional complexity.
We would rather you choose this deliberately in discovery than discover the distinction during an incident.
Three independent routes, all available to your own administrator:
Native Creator backup — application structure, Deluge scripts and data as CSV, downloadable as a zip, on a manual or scheduled basis, from within your account.
Report-level export — any report exports to Excel, CSV or PDF directly from the interface, including the audit log and the payment application detail.
The off-continent archive — the bucket is registered to ETRAM Inversiones, so you hold the credentials and can download the complete archive at any time without any involvement from us.
One documented caveat: Zoho states that integration field data is not handled by the standard backup and restore. Our export pipeline covers the gap explicitly, which is one of the reasons it exists rather than relying on the native backup alone. Written export and restore procedures are part of the handover documentation.
Structurally the answer is straightforward and the cost base is small, because Zoho Creator is licensed per user and you have named two users — one manager-administrator and one operator-supervisor. Drivers and helpers are not users, so they carry no licence.
The line items that need pricing are: Creator user licences for two users; the AI and OCR call allowance, which is consumed per extraction and is the item most likely to need topping up as volume grows; Creator storage for the document set; the external object storage on the second continent; implementation; and ongoing support.
The two figures we will not guess are the AI call allowance and the plan tier, because both depend on your true daily volume and on which extraction approach is selected in question 7. Those are settled in discovery, and the full commercial proposal follows immediately after — this document is deliberately without pricing so that the scope is agreed before the numbers are attached to it.
No supplier can responsibly quote an accuracy figure before seeing your actual documents, and we will not. What we can tell you is how the number is arrived at and what governs it.
Your Annex C already proposes twenty to fifty representative conduces, and that is the right order of magnitude. The decisive factor is not the count but the consistency: if the Cumayasa liquidation always arrives in the same layout, a modest sample is enough and accuracy on the structured fields is typically high. If the layout varies, or if captures are photographs of paper taken at an angle in poor light, accuracy falls and the review screen carries more of the load.
Which is the deliberate design point. We do not treat OCR accuracy as the control. The control is the mandatory review screen in Flow 01, where the manager confirms extracted lines against the original document before anything reaches the ledger, with doubtful fields highlighted and every total recalculated. That way a poor extraction costs a few seconds of correction; it never produces a wrong receivable.
Give us the twenty to fifty samples and we will run them through the candidate approaches and report measured field-level accuracy before you commit to a build — that is a discovery deliverable, not a promise.
File formats are not the constraint. Zoho Creator's OCR field documentation covers JPG, JPEG, PNG, BMP, TIF, TIFF, WEBP and PDF, and recognises English text. Zoho's intelligent document processing capability covers PDF, PNG, JPG, JPEG and WebP.
The real constraint is structure. Creator's built-in OCR field extracts text from an image — it is well suited to reading a single reference number or a business card. Your liquidation is a multi-row table where every customer line must come back as discrete, validated fields. That is a document-understanding problem, not a text-extraction one, and it needs an engine that returns line items rather than a block of text.
Two viable routes, both of which we would benchmark against your samples in discovery: Zoho's own intelligent document processing, which explicitly supports extracting structured data from tables and invoice line items and keeps everything inside the Zoho estate; or an external document-AI service called from Deluge, which typically handles messy photographic captures better. Zoho also offers custom OCR models that can be trained to a specific layout, which is worth evaluating if your liquidation format is stable.
Your RFI also asks whether direct integration would be superior to OCR if the conduce originates in a structured system at Cumayasa. It categorically would be — a data feed removes the extraction risk entirely. It is worth one conversation with Cumayasa before committing to OCR, and we would raise it in discovery.
Four separate controls, each enforced at the point of saving rather than found later in a report:
Conduce number — unique across the system. A re-uploaded batch is detected and rejected at import, before it can create a second set of receivables.
Bank reference — checked across every payment and every remittance. A repeated reference is blocked and the existing record is shown so the operator can see what they have already registered.
Conduce reuse across remittances — a conduce or payment already consumed by one remittance cannot be assigned to another, enforced at save as your section 7.3 requires.
Idempotency key per record — this is the one that matters for mobile. A record created offline and synced twice, or a form submitted twice on a poor connection, carries the same key and is written once. Without it, offline operation is a duplicate-generation machine.
All three are handled by the same underlying structure: an allocation ledger that records each application separately rather than storing a single paid-or-unpaid flag on the conduce.
Every application writes its own record — which payment, which conduce, how much was applied, the balance before and the balance after. One payment therefore naturally spans several conduces, one conduce naturally receives several partial credits over time, and the outstanding balance is always the arithmetic result of its allocations rather than a figure someone maintained by hand.
A consolidated remittance sits one level above this: it distributes a single deposit across customers, and then within each customer the assigned amount runs through the same allocation logic by age. That is why the remittance in Flow 04 and the single payment in Flow 03 produce identical, consistent ledger entries.
A Deluge routine that runs whenever an amount is assigned to a customer, in five steps: load all outstanding conduces for that customer; sort by dispatch date ascending, then by time, then by the oldest sequential number where a date and time tie; settle each conduce completely before moving to the next; register a partial credit on the first conduce the remainder cannot cover and retain its balance; write one allocation record per application.
Two engineering points are worth stating plainly, because they are where implementations of this pattern usually fail. First, Zoho Creator has no multi-record transaction, so we compute the entire allocation set in memory, validate that it sums exactly to the payment, then commit and verify — and roll back and flag if verification fails, rather than leaving a payment half-applied. Second, the customer ledger is locked during application, so two payments processed close together can never both consume the same conduce balance.
The proposed distribution is displayed to the manager before approval. A manual change to the FIFO result is possible but requires managerial authorisation, a mandatory reason and an audit record — as your section 6.1 specifies. Settled conduces move to status Settled and remain in history; nothing is deleted.
Blueprint models the process as states with explicitly defined transitions, and a record can only move along a transition that exists. There is no path from imported to delivered without passing through dispatch authorised, because no such transition is defined. Stage skipping is prevented structurally rather than by validation rules that could be bypassed.
Self-approval is prevented by binding each transition to a role. The authorise transition belongs to the manager; the operator's interface does not present a disabled approve button, it presents no approve action at all. The same applies in reverse — the manager does not register deliveries on the operator's behalf without it being visible as such.
Every transition records who executed it and when, which is what produces the made by / reviewed by / authorised by chain your section 3.1 requires, with each of the three timestamps stored separately rather than as a single last-modified date.
A scheduled job runs hourly, recalculates the age of every open conduce from its confirmed dispatch time, and assigns one of four bands: 0–24 normal, 24–40 follow-up with a yellow alert to both users, 40–48 close to due with an orange priority alert, and beyond 48 hours customer action required in red.
The red state applies a preventive block on any new dispatch to that customer. The block is a condition on the dispatch authorisation transition, so it cannot be worked around by creating the batch differently — the transition simply will not fire while the customer is blocked.
Lifting it requires an authorised exception from the manager, which records who authorised it, when, why, and for which specific customer and batch. Exceptions are reportable, so a pattern of repeated overrides for one customer is visible rather than buried.
One rule underpins all of this and is worth restating: only a reconciled payment stops the clock. A payment merely reported by the operator, or even validated but not yet effectively received by ETRAM, leaves the countdown running. That distinction is what makes the alert trustworthy.
ETRAM Inversiones, without qualification. The Zoho account is created in ETRAM's name with ETRAM holding the super-administrator credentials. The application, all data, all attachments, the Deluge source, the configuration and the documentation belong to you. The external storage bucket on the second continent is likewise registered to ETRAM.
We work under a named developer user inside your account, which you can revoke at any moment without any effect on the running system. We would recommend that arrangement even if you were not asking for it — it is the only structure where a change of supplier is a non-event.
Deliberately not answered here, and for a reason. Two open items move the number materially: the extraction approach selected in question 7 and 8, which cannot be fixed until we have run your real samples; and the continuity tier selected in question 4, where Tier A and Tier C are genuinely different pieces of work.
What we can commit to now is the shape. Milestones are acceptance-gated, each one ending in a demonstration scored against your own criteria in RFI section 14, with payment released only when you accept that milestone. The natural break points follow your own deliverable list: discovery and design; the transactional core through to FIFO and remittances; extraction and the review screen; continuity, restore drill and handover.
A defect-correction warranty period follows go-live, and ongoing support is quoted as either an hours bank or a monthly retainer, at your preference. The full commercial proposal follows the discovery workshop — at which point the figures are grounded in your documents rather than in assumptions about them.
Zoho Creator Certified Developer, working full-time on Zoho implementations across CRM, Creator, Books, Analytics, Projects and Flow. Directly relevant to this brief: multi-stage approval systems with role-gated Blueprint transitions and immutable audit trails; accounting migrations and reconciliation work involving customer and vendor ledgers, partial settlements and balance integrity; document-extraction pipelines feeding validated records; and mobile-first Creator applications for field operators.
References and comparable case material can be provided on request, and we are happy to walk through a working system rather than a slide deck. For a build with this much accounting logic in it, we would also suggest that the discovery workshop include a short proof of concept on your real conduces — it is the fastest way for you to judge the extraction quality and for us to price it accurately.
The findings that shape this build
Four things worth knowing before anyone quotes.
These are the points where a supplier's answer tells you whether they read your document or skimmed it. We have set out our position on each, including where it costs us something to be straight with you.
Critical · not native to the platform
The intercontinental replica is the one requirement Zoho cannot meet
You anticipated this precisely — you wrote that two centres inside the United States or North America would not be sufficient. Zoho's published topology produces exactly that: Quincy and Dallas, Amsterdam and Dublin, Mumbai and Chennai. Every pair is intra-continental.
It is entirely solvable, but only by building something outside Zoho and registering it to ETRAM. It is not a checkbox in a settings page, and it should not be priced as one.
Our recommendation: decide the continuity tier in discovery before scoping anything else, because Tier A and Tier C are different projects. For an operation of your size we would advise Tier B — a verified off-continent archive plus a drill-tested rebuild package.
Material · affects scope and price
OCR on a multi-customer liquidation is not the OCR field
Creator's built-in OCR field returns text from an image. Your liquidation is a table where each customer line must come back as validated, discrete fields with totals that reconcile. Those are different problems, and conflating them is the most likely way this project gets underquoted.
The approach we would take makes extraction quality a manageable variable rather than a gamble: a document-understanding engine that returns line items, and a mandatory manager review screen with doubtful fields highlighted before anything reaches the ledger.
Our recommendation: send the twenty to fifty samples from your Annex C early. We will benchmark the candidate engines and report measured accuracy before you commit. Also worth one call to Cumayasa — if the liquidation originates in a structured system, a direct feed beats any OCR.
Design decision · easy to get wrong
Offline operation and automatic FIFO have to be reconciled deliberately
Creator's mobile app does support offline form submission and camera capture, and syncs when connectivity returns. But offline lists are a snapshot from the last sync, and the balances an operator sees offline may be stale by the time the record uploads.
FIFO must therefore be applied server-side on sync, against the ledger as it stands at that moment — never calculated on the device against yesterday's balances. And every offline record needs an idempotency key, or a double sync silently applies the same money twice.
Our recommendation: treat offline capture as evidence collection, not as accounting. The operator captures the payment and the proof; the ledger maths happens server-side on arrival and the result is shown back to them.
Strength · your document, not ours
Your control model is already the right one
Section 3.1 of your RFI rejects letting the operator originate and approve everything, and proposes control by stage and by exception instead. That is the correct answer, and it is unusual to receive an RFI that has already worked it out.
It also makes the build cleaner. Because the boundaries are clear, the permission model is simple to enforce and simple to test — and the acceptance criteria in your section 14 are already written as testable statements, which is what a well-run user acceptance phase needs.
Our recommendation: keep section 14 exactly as it is and let it become the acceptance script. We would demonstrate against those criteria one by one at each milestone, including the negative cases — the operator trying to approve their own payment, and the out-of-balance remittance refusing to submit.
What we would need from you
Six inputs turn this analysis into a firm proposal.
Your Annex C already lists most of these — this is simply where each one lands in the assessment, and why it matters.
20–50 real conduce samplesAnonymised if necessary. These decide the extraction approach and are the only honest basis for an accuracy figure or a price.
Deposit slips from Popular and BanreservasTo determine how much can be read automatically from a proof versus keyed by the operator.
Consolidated operator reportsIncluding at least one balanced remittance and one with a difference — the failure cases teach us more than the clean ones.
Customer list, product catalogue and price tableSets the master data volume, the matching rules and the discount logic.
Daily volume figuresConduces per day, customers per batch and payments per day. This drives the AI call allowance and the licensing tier.
Your continuity tier decisionTier A, B or C from question 4. Nothing else in the architecture can be fixed until this one is.
How the work would run
Acceptance-gated, in the order your deliverables list already implies.
01
Discovery on real documents
A working session on your actual conduces, proofs and remittances — not a requirements interview. It ends with a validated process map, a benchmarked extraction approach with measured accuracy, and your continuity tier decided. Only then are figures attached to scope.
02
Build against your own criteria
Each milestone ends in a demonstration scored against RFI section 14, including the negative tests — self-approval refused, out-of-balance remittance refused, duplicate conduce refused. You accept the milestone before the next begins.
03
Handover you can act on alone
Training for both users, written export and restore procedures, an executed and documented restore drill from the off-continent archive, and every credential in ETRAM's name. The definition of done is that you could change supplier without touching the system.
Next step
One working session, on your real documents.
What we propose
Send the sample pack — the conduces, deposit slips and remittance examples from your Annex C. We will work on them before we meet rather than during the meeting.
Hold the validation session — the agenda in your Annex B is well constructed and we would follow it, with one addition: fifteen minutes on the three continuity tiers, since that decision governs the architecture.
Receive a benchmarked extraction report — measured field-level accuracy on your own documents, with a recommendation between Zoho's document processing, an external engine and a direct feed from Cumayasa.
Receive the full commercial proposal — scope, milestones, schedule, licensing, support and warranty, grounded in what the samples showed rather than in assumptions.
This document contains no pricing by design. Two open decisions — the extraction approach and the continuity tier — move the figure materially, and quoting before they are settled would produce a number that changes later. We would rather agree the scope first and price it once, accurately.
AS
Zoho Creator · Análisis de Requerimientos y Propuesta de Solución
ETRAM Fuel Control
Una lectura de vuelta de sus requerimientos funcionales y su RFI — lo que entendemos que necesitan, lo que Zoho Creator hace de forma nativa, lo que hay que construir a la medida, y las tres decisiones que definen todo el proyecto.
Preparado para ETRAM Inversiones · atn. Darlington Mars · por Aman Shukla, Desarrollador Certificado en Zoho Creator · agosto 2026 Evaluado contra el Documento de Requerimientos Funcionales y RFI, 18 de agosto de 2026
Su principio operativo, preservado de principio a fin: el gerente origina y autoriza → el operador ejecuta y documenta → el sistema aplica el dinero por antigüedad → el gerente revisa, aprueba y concilia. Nada avanza sin evidencia, nada cuadra por opinión, y cada cifra se remonta a un documento fuente.
Lo que ustedes pidieron
Cada flujo replantea su RFI en términos claros — el conduce, la regla FIFO, la remesa consolidada, el control de 48 horas y la réplica intercontinental — con referencia a la sección de la que proviene.
Lo que significa en la construcción
Frente a cada requerimiento, cómo se implementaría realmente en Zoho Creator, y dónde la plataforma hace el trabajo por nosotros frente a dónde tenemos que construirlo nosotros mismos.
Haga clic en cualquier etapa
Toque cualquier etapa de un flujo para abrir su detalle, y cualquier tarjeta de diagrama para ver el proceso completo. Sus dieciséis preguntas del RFI están respondidas más abajo.
Factibilidad de un vistazo
Cinco veredictos honestos antes que cualquier otra cosa.
Preferimos decirles desde ahora qué partes de su RFI son rutinarias y cuáles no. Cuatro de las cinco áreas están holgadamente dentro de Zoho Creator. Una no es nativa de Zoho en absoluto, y resulta ser la que ustedes señalaron como crítica.
Construible tal como se especifica
Conduces, pagos, FIFO, remesas, control de 48 horas
Todo el núcleo transaccional — auxiliares, aplicación por antigüedad, remesas cuadradas, alertas de vencimiento, hecho por / revisado por / autorizado por — es trabajo estándar de Zoho Creator con formularios, Blueprint y Deluge.
Construible tal como se especifica
Roles, bitácora de auditoría y reportes
Dos usuarios nombrados, permisos por etapa, sin autoaprobación, una bitácora inalterable y todo el conjunto de tableros y exportaciones son capacidad nativa de la plataforma.
Construible — requiere un enfoque definido
OCR de la liquidación de Cumayasa
El campo OCR incorporado en Creator devuelve texto plano, no una tabla validada de líneas por cliente. Extraer cada línea de forma confiable requiere un paso de IA documental más una pantalla de revisión obligatoria. La precisión se controla con la revisión, no se promete con el OCR.
Construible — requiere un enfoque definido
Operación de campo sin conexión
La app móvil de Creator sí admite envío offline y captura por cámara, pero los listados offline son una fotografía periódica. Por eso el FIFO debe aplicarse del lado del servidor al sincronizar, con una clave de idempotencia por registro para impedir duplicados.
No es nativo de Zoho
Réplica fuera del continente primario
Cada par de centros de datos de Zoho está dentro de un mismo continente — Estados Unidos es Quincy y Dallas, Europa es Ámsterdam y Dublín. Su requerimiento no puede cumplirse solo con Zoho; necesita una tubería de exportación propiedad de ETRAM hacia un segundo continente.
La operación de principio a fin
Seis etapas, desde la liquidación de Cumayasa hasta una conciliación cerrada.
RFI sección 3.1 · hecho por / revisado por / autorizado por
● Ver diagrama
Flujo 01
Importación de Liquidación y OCR
Con
● Clic en una etapa para ver el detalle
1
+
Cargar Documento
Creator
El gerente carga la captura, imagen o PDF de la liquidación autorizada por Cumayasa — una carga por lote diario
El archivo original se conserva de forma permanente y nunca se sobrescribe; encabeza la cadena de evidencia de cada línea que produce
El despacho físico no espera por este paso — la oficina continúa mientras se registra el lote, tal como exige la sección 2 de su RFI
→
2
+
Extraer Líneas
IA documental
El documento pasa a un motor de IA documental que devuelve el encabezado del lote más una fila por cliente: número de conduce, fecha y hora, cliente, producto, galones, precio, descuento y total
El campo OCR incorporado en Creator por sí solo devuelve texto sin estructura — suficiente para un número de referencia, no para una liquidación con múltiples clientes. Por eso tratamos la extracción como una llamada a un servicio, no como un campo de formulario
Cada valor extraído se guarda junto a un nivel de confianza, para que la pantalla de revisión sepa qué resaltar
→
3
+
Validar
Deluge
Número de conduce obligatorio y no existente en el sistema — los lotes repetidos se rechazan en la puerta
La fecha y hora no pueden ser futuras; el reloj de 48 horas arranca con el despacho confirmado, no con la carga
Cliente contrastado con la base maestra, con sugerencias de coincidencia cuando el nombre no es exacto; el producto debe pertenecer al catálogo autorizado
Galones positivos y numéricos; precio comparado con el precio vigente con alerta de diferencia; descuento aplicado solo donde está permitido
Total de línea recalculado como cantidad × precio − descuento, y total del lote recalculado como la suma de todas las líneas
→
4
+
Pantalla de Revisión
Creator
Los datos extraídos se muestran al gerente antes de guardarse en firme — lado a lado con el documento original
Los campos dudosos se resaltan: baja confianza, diferencia de precio, cliente sin coincidencia, descuadre aritmético
El gerente puede corregir cualquier línea. Se conservan el documento original, el valor extraído original, el valor corregido, el usuario y la fecha y hora
Esta pantalla es lo que convierte la precisión del OCR en un riesgo administrable en lugar de una promesa — nada llega al auxiliar sin revisión
→
5
+
Cuadre
Deluge
La suma de todos los conduces individuales debe coincidir exactamente con el total del lote — el control que ustedes piden en la sección 5
Ante cualquier diferencia entre débitos y créditos, la aceptación definitiva queda bloqueada. El lote permanece en revisión, no pasa con una advertencia
Se muestra el monto descuadrado para que el gerente vea con precisión qué línea inspeccionar
→
6
+
Sellar Evidencia
WorkDrive
Documento fuente, datos extraídos, historial de correcciones y aprobación quedan enlazados como una sola cadena de auditoría del lote
Los archivos se guardan en una estructura de carpetas por fecha y lote, e ingresan a la exportación de continuidad descrita en el Flujo 06
Nada de esta cadena puede ser eliminado por ninguno de los dos roles una vez escrito
Su requerimiento
El gerente carga una captura, imagen o PDF de la liquidación diaria y el OCR extrae y organiza automáticamente cada conduce
Deben extraerse tanto el encabezado como cada línea de cliente, reduciendo la digitación antes de la autorización
El sistema valida cada campo, resalta los dudosos y recalcula todos los totales
La suma de los conduces individuales debe coincidir exactamente con la liquidación total del día
Debe preservarse el documento original y la trazabilidad de cualquier corrección
Lo que significa en la construcción
Estructura de encabezado y detalle de líneas, con el archivo fuente conservado permanentemente en el lote
Extracción por IA documental invocada desde Deluge, devolviendo líneas estructuradas con confianza por campo — no el campo OCR nativo por sí solo
Las nueve reglas de validación de la sección 5 implementadas como bloqueos, no como advertencias
Pantalla de revisión lado a lado con campos dudosos resaltados e historial completo de correcciones
Cuadre obligatorio: el lote no puede convertirse en despacho autorizado mientras exista cualquier diferencia
Coincidencia aproximada de clientes con sugerencias, y alerta de diferencia contra el precio vigente
Flujo 02
Autorización y Entrega
Con
● Clic en una etapa para ver el detalle
1
+
Precio Vigente
Creator
Precio vigente por combustible y aceite, descuento aplicable, fecha y hora de vigencia, y el usuario que lo autorizó
Los precios se versionan, nunca se editan en su lugar — un conduce siempre se resuelve contra el precio que estaba vigente al momento de su despacho
Solo el gerente puede fijar o cambiar un precio; el operador no tiene acceso alguno a precios
→
2
+
Autorizar Lote
Blueprint
El gerente ejecuta la única transición que lleva el lote a Despacho autorizado
La transición está restringida al rol de gerente — el operador no puede verla ni ejecutarla bajo ninguna circunstancia
La transición no puede dispararse mientras el lote esté descuadrado, contenga un cliente sin coincidencia o tenga un campo dudoso sin resolver
→
3
+
El Operador lo Ve
Creator Móvil
Solo los despachos autorizados aparecen en el listado móvil del operador — es el criterio de aceptación de la sección 14
Los lotes en importación, revisión o descuadrados son invisibles para el operador, no meramente de solo lectura
El listado se ordena por fecha de despacho para que lo más antiguo aparezca primero
→
4
+
Confirmar Entrega
Creator Móvil
El operador confirma cada conduce como entregado, no entregado o entregado con incidencia
Una incidencia exige un motivo y, opcionalmente, una fotografía — no pasa en silencio
Choferes y ayudantes hacen la entrega física pero nunca tocan el sistema, tal como especifica la sección 3
→
5
+
Arrancar el Reloj
Deluge
La entrega confirmada abre la cuenta por cobrar de ese conduce y arranca su reloj de 48 horas
La cuenta por cobrar se registra por cliente y por conduce — individual, no agregada — como exige su modelo contable
La cuenta por pagar correspondiente al suplidor de combustible se registra contra el mismo lote
→
6
+
Bandeja de Excepciones
Cliq / Correo
Todo lo que no salió según lo previsto — no entregado, incidencia, cliente sin coincidencia, diferencia de precio — llega a la bandeja de excepciones del gerente
La gerencia trabaja por excepción en lugar de leer cada registro, que es el modelo de control recomendado en su sección 3.1
Las notificaciones salen por correo y opcionalmente por chat tipo WhatsApp, sin exigir que ninguno de los dos usuarios esté dentro de la aplicación
Su requerimiento
El gerente revisa, acepta la relación y autoriza la salida del combustible
El operador solo puede ver y ejecutar despachos previamente autorizados
Registrar una cuenta por cobrar individual por cada cliente y conduce, y la cuenta por pagar al suplidor
Estados y transiciones controladas deben impedir que se salte cualquier etapa
La gerencia trabaja principalmente desde una bandeja de excepciones
Lo que significa en la construcción
Estados de Blueprint con transiciones restringidas por rol — la pantalla del operador simplemente no tiene acción de autorizar
Maestro de precios versionado; los conduces se resuelven contra el precio vigente al momento del despacho
Auxiliar de cuentas por cobrar por conduce más cuenta por pagar por lote al suplidor, ambos registrados al confirmar la entrega
Confirmación de entrega con entregado / no entregado / incidencia, motivo y fotografía opcional
Bandeja de excepciones con lotes descuadrados, duplicados, faltantes, vencidos y pagos sin soporte
Alertas por correo y chat para que ninguno de los dos usuarios tenga que vigilar una pantalla para encontrar trabajo
Flujo 03
Pagos y Aplicación Automática FIFO
Con
● Clic en una etapa para ver el detalle
1
+
Registrar Pago
Creator Móvil
El operador selecciona el cliente e indica el monto recibido — no se le exige nada más
El monto debe ser mayor que cero; exceder el saldo del cliente genera una advertencia y exige autorización, en lugar de fallar en silencio
Fecha obligatoria y no futura; banco de origen registrado como Popular, Banreservas u otro
→
2
+
Adjuntar Comprobante
Creator / WorkDrive
Una fotografía o PDF del volante de depósito es obligatoria — un pago no puede registrarse sin ella
Se capturan fecha, banco, monto y número de referencia, con extracción desde el volante cuando es legible
El número de referencia se contrasta contra todos los pagos y remesas ya existentes para detectar duplicados
La cuenta receptora se registra como ETRAM Inversiones o como la cuenta del operador — una distinción que importa en el Flujo 04
→
3
+
Leer el Auxiliar
Deluge
El sistema consulta todos los conduces pendientes de ese cliente — el operador nunca selecciona cuáles saldar
El orden es estrictamente fecha de despacho ascendente; ante empate de fecha se usa la hora, y luego el número secuencial más antiguo
Los conduces ya saldados quedan excluidos pero nunca se borran — permanecen en el historial con estado Saldado
→
4
+
Aplicar por Antigüedad
Deluge
El conduce más antiguo se salda por completo antes de que cualquier monto pase al siguiente
Cuando el remanente no cubre el conduce siguiente, se registra un abono parcial y se conserva el saldo pendiente
Solo el último conduce alcanzado puede quedar parcial — todos los anteriores quedan saldados por completo o intactos
Cada aplicación se escribe como su propio registro: pago, conduce, monto aplicado, saldo antes y saldo después
→
5
+
Mostrar Antes de Aprobar
Creator
La distribución propuesta se muestra al gerente antes de aprobar y conciliar, como exige la sección 6.1
El gerente ve exactamente cuáles conduces quedan saldados, cuál queda parcial y qué permanece pendiente
Cualquier cambio manual al resultado FIFO requiere autorización gerencial, motivo obligatorio y registro de auditoría — es posible, pero nunca silencioso
→
6
+
Confirmar con Seguridad
Deluge
Creator no tiene transacción multi-registro, así que calculamos el conjunto completo de aplicaciones, validamos que sume exactamente el pago, y luego confirmamos y verificamos
El auxiliar del cliente se bloquea durante la aplicación para que dos pagos nunca consuman el mismo saldo
Cada pago lleva una clave de idempotencia, de modo que un reintento o una resincronización offline nunca apliquen el mismo dinero dos veces
Si la verificación falla, la aplicación se revierte y el pago se marca, en lugar de quedar a medio aplicar
Diagramas de proceso
La regla de aplicación de la sección 6.1, desarrollada por completo — clic para abrir.
Aplicación automática FIFO por cliente
RFI sección 6.1 · más antiguo primero, parcial solo en el último
● Ver diagrama
Ejemplo resuelto — RD$20,000 sobre dos conduces
RFI sección 6.1 · el caso exacto de su documento
● Ver diagrama
Registro y validación del pago
RFI sección 6 · campos, reglas y control de duplicados
● Ver diagrama
Su requerimiento
El operador indica únicamente el cliente y el monto — nunca cuáles conduces se están pagando
El sistema consulta el auxiliar del cliente y aplica el pago automáticamente, siempre comenzando por el más antiguo
Cada conduce debe saldarse por completo antes de pasar al siguiente; el faltante se convierte en abono parcial
Empates resueltos por hora, y luego por el número secuencial más antiguo
Los conduces saldados nunca se borran — cambian de estado y permanecen en el historial
La distribución propuesta se muestra al gerente antes de aprobar, y todo cambio manual queda autorizado y auditado
Lo que significa en la construcción
Un auxiliar de aplicaciones dedicado — pago, conduce, monto aplicado, saldo antes y después — un registro por aplicación
Ordenamiento determinista por fecha de despacho, luego hora, luego número secuencial
Patrón calcular-validar-confirmar-verificar con bloqueo del auxiliar del cliente, dado que Creator no ofrece transacción multi-registro
Clave de idempotencia en cada pago para que reintentos y resincronizaciones offline no dupliquen la aplicación
Pantalla de vista previa de la distribución para el gerente, con ruta de motivo y autorización para el cambio manual
Comprobante obligatorio y detección de duplicados por referencia bancaria en pagos y remesas
Flujo 04
Remesas Consolidadas
Con
● Clic en una etapa para ver el detalle
1
+
Encabezado de Remesa
Creator Móvil
Número de remesa generado automáticamente, operador responsable, fecha y hora de la transferencia y monto total transferido
Banco de origen y banco receptor — Popular, Banreservas u otro — más el número de referencia bancaria
Una sola captura o comprobante es obligatoria para todo el depósito, tal como describe su caso de uso
→
2
+
Distribuir
Creator Móvil
El operador agrega una línea por cliente incluido en el depósito, con el monto asignado a cada uno
No elige conduces — solo clientes y montos. La selección del conduce es tarea del sistema
Se muestra en vivo el saldo por distribuir: total del depósito menos la suma de las asignaciones
→
3
+
Control de Cuadre
Deluge
Mientras el saldo por distribuir sea distinto de cero, la remesa permanece en Borrador y no puede enviarse
El mismo conduce o pago nunca puede utilizarse dos veces en remesas distintas — se impide al guardar, no se descubre después
Una asignación que supere el saldo del cliente genera alerta y exige aprobación administrativa
→
4
+
FIFO dentro de cada Cliente
Deluge
Dentro de cada cliente de la remesa, el monto asignado se aplica con la misma regla de antigüedad — conduce más antiguo primero
Se admiten abonos parciales y se muestra el saldo restante del conduce
La distribución propuesta completa, para todos los clientes, se presenta para revisión antes de validar
→
5
+
Quién Tiene el Dinero
Creator
El sistema distingue el cliente pagó al operador de el operador transfirió a ETRAM Inversiones — dos eventos diferentes
El dinero cobrado por el operador y aún no transferido aparece como su propia cifra, para que nunca se confunda con efectivo recibido por la empresa
El débito va a la cuenta bancaria o transitoria correspondiente; el crédito va al auxiliar de cuentas por cobrar del cliente
→
6
+
Revisión por Línea
Creator / Analytics
El gerente puede observar una sola línea sin rechazar toda la remesa — una petición específica de la sección 7.3
Toda corrección posterior a la presentación conserva versión, usuario, fecha, valor anterior y valor nuevo
Al validar, todos los clientes y conduces incluidos se actualizan automáticamente en una sola acción
Diagramas de proceso
El caso de uso obligatorio de la sección 7 — un solo depósito repartido entre varios clientes.
RFI sección 7.3 · RD$60,000 repartidos entre cinco clientes
● Ver diagrama
Efectivo en poder del operador frente a efectivo recibido por la empresa
RFI sección 7.3 · tratamiento de la cuenta transitoria
● Ver diagrama
Su requerimiento
El operador registra un depósito total, adjunta un solo comprobante y lo distribuye entre los clientes incluidos
La remesa no puede cerrarse ni enviarse si la suma de las asignaciones no coincide exactamente con el depósito
Dentro de cada cliente, el monto asignado se aplica con la misma regla de antigüedad
El mismo pago o conduce nunca puede utilizarse dos veces en remesas distintas
La gerencia puede observar una sola línea sin rechazar toda la remesa
Diferenciar el dinero que el cliente pagó al operador del que el operador transfirió a ETRAM
Lo que significa en la construcción
Estructura de encabezado y detalle con la cifra de saldo por distribuir en vivo
Bloqueo estricto en la transición de envío — el borrador no puede salir de borrador estando descuadrado
Unicidad entre remesas aplicada al guardar, de modo que el doble uso se impide en lugar de detectarse
FIFO anidado: distribuir entre clientes, luego aplicar por antigüedad dentro de cada cliente
Cuenta transitoria para fondos en poder del operador, con su propio reporte de pendiente de transferir
Estado de observación por línea, con historial completo de versiones en cualquier corrección posterior
Seis estados en el encabezado: borrador, cuadrada, enviada, observada, validada, conciliada
Flujo 05
Revisión, Conciliación y el Reloj de 48 Horas
Con
● Clic en una etapa para ver el detalle
1
+
Bandeja Diaria
Creator
Una bandeja diaria con todos los depósitos registrados por el operador, con clientes incluidos, fechas, montos y comprobantes
El gerente revisa antes de aprobar — nada se aprueba automáticamente por la palabra del operador
La bandeja se filtra por estado para que el gerente vea solo lo que requiere decisión hoy
→
2
+
Cuatro Resultados
Blueprint
Aprobar, observar, devolver o rechazar — cada uno con motivo obligatorio cuando el resultado no es una aprobación limpia
El operador nunca puede aprobar su propio registro; la transición no está disponible para su rol
Los registros observados y devueltos regresan al operador con el motivo visible, y conservan todo su historial
→
3
+
Tres Verdades Distintas
Deluge
El sistema distingue reportado, validado y efectivamente conciliado — tres cifras diferentes, jamás fundidas en una
La conciliación confirma el comprobante, la referencia, el monto, las asignaciones y la recepción efectiva en ETRAM Inversiones
Solo la conciliación cierra el reloj del conduce; un pago reportado no detiene el conteo
→
4
+
Motor de Antigüedad
Deluge
Una tarea programada recalcula la antigüedad de cada conduce abierto y le asigna su rango: 0-24, 24-40, 40-48 o más de 48 horas
Los rangos determinan color, prioridad y escalamiento — verde, amarillo, naranja, rojo
El reloj corre desde el despacho confirmado, no desde la importación, y se detiene solo con la conciliación
→
5
+
Escalar y Bloquear
Cliq / Correo
Amarillo a las 24 horas al operador y a la administración, naranja a las 40 horas como alerta prioritaria
Pasadas las 48 horas el cliente pasa a cliente a tomar acción, con bloqueo preventivo de cualquier nuevo despacho
El bloqueo solo puede levantarse mediante excepción autorizada, que registra quién la autorizó, cuándo y por qué
→
6
+
Reportes y Exportación
Analytics
Vistas diarias, semanales y mensuales de conduces, galones, valores, cobros y depósitos
Consumo por cliente, tiempo promedio de pago y número de incumplimientos de 48 horas por cliente
Detalle de cómo se aplicó cada pago — conduces saldados, abonos parciales y remanentes
Exportación a Excel, CSV y PDF, con trazabilidad completa de cada operación
Diagramas de proceso
La cadena de revisión y el control de antigüedad de las secciones 3.1 y 8.
Hecho por, revisado por, autorizado por
RFI sección 3.1 · sin saltar etapas, sin autoaprobación
● Ver diagrama
Antigüedad de 48 horas, alertas y bloqueo preventivo
RFI sección 8 · 0-24, 24-40, 40-48, más de 48
● Ver diagrama
Reportado, validado, conciliado — tres cifras distintas
RFI sección 8 · qué detiene realmente el reloj
● Ver diagrama
Su requerimiento
Una bandeja gerencial para revisar, aprobar, observar o devolver los cobros registrados por el operador
Trazabilidad bajo hecho por / revisado por / autorizado por en todo el proceso
Distinguir pago reportado, pago validado y pago efectivamente conciliado
Alertas a las 24, 40 y 48 horas, con estado rojo y bloqueo preventivo pasadas las 48
Conjunto completo de reportes: clientes pagados y pendientes, cifras diarias, semanales y mensuales, exportación y trazabilidad completa
Lo que significa en la construcción
Bandeja diaria de revisión con cuatro resultados y motivos obligatorios en todo lo que no sea aprobación
Transiciones restringidas por rol para que el operador no tenga ruta de aprobación sobre sus propios registros
Tres estados de pago separados, deteniendo el reloj únicamente la conciliación
Tarea programada cada hora que alimenta cuatro rangos, código de color y escalamiento
Bloqueo preventivo de despacho pasadas las 48 horas, levantable solo por excepción autorizada y registrada
Conjunto de tableros más exportación a Excel, CSV y PDF, y reporte de detalle de aplicación por pago
Bitácora inalterable de creación, modificación, aprobación y anulación en cada registro
Flujo 06
Arquitectura, Continuidad y Auditoría
Con
● Clic en una etapa para ver el detalle
1
+
Plataforma Primaria
Zoho Creator
La aplicación, la base de datos y los documentos residen en una región de centros de datos de Zoho, seleccionada por ETRAM al momento del registro
Zoho opera cada región como un par primario y secundario — por ejemplo Quincy y Dallas en Estados Unidos, o Ámsterdam y Dublín en Europa
Ambos miembros de cada par están en el mismo continente. Ahí está el nudo de su requerimiento crítico
→
2
+
Tubería de Exportación
Deluge / Programador
Una tarea programada exporta el conjunto completo de datos — clientes, precios, conduces, pagos, aplicaciones, remesas y bitácora — en un ciclo fijo
Una segunda tarea exporta el repositorio documental: liquidaciones fuente, volantes de depósito y fotografías de entrega
Cada exportación lleva un manifiesto y una suma de verificación, para que una restauración pueda demostrar que está completa antes de que alguien confíe en ella
→
3
+
Bóveda Fuera del Continente
Almacenamiento externo
Las exportaciones aterrizan en almacenamiento de objetos en un continente distinto al de la región Zoho — por ejemplo una región Zoho en Norteamérica con almacenamiento en Europa
El bucket es propiedad directa de ETRAM Inversiones, no del desarrollador, y está versionado y cifrado en reposo
El bloqueo de objetos o inmutabilidad protege el archivo contra borrado, incluso por una cuenta administrativa comprometida
→
4
+
Prueba de Restauración
Procedimiento documentado
Un procedimiento escrito de restauración, ejecutado y evidenciado al menos dos veces al año como exige su RFI
La prueba demuestra que el archivo es legible, completo y suficiente para reconstruir — no simplemente que los archivos existen
Los resultados se documentan con fecha, responsable, duración lograda y cualquier brecha encontrada
→
5
+
Seguridad y Accesos
Zoho / Creator
Cifrado en tránsito y en reposo, autenticación multifactor, roles de mínimo privilegio y control de sesiones
Ambientes separados de desarrollo y producción, para que nada se pruebe contra datos reales
Reglas de retención aplicadas tanto al sistema en vivo como al archivo fuera del continente
→
6
+
Propiedad
Gobernanza
La cuenta de Zoho, la aplicación, los datos, el bucket de almacenamiento y las credenciales administrativas están a nombre de ETRAM Inversiones
El desarrollador trabaja bajo un usuario nombrado dentro de su cuenta, que ustedes pueden revocar en cualquier momento
La exportación completa de datos, adjuntos, configuración y documentación es posible sin intervención del desarrollador
Diagramas de proceso
La arquitectura de continuidad — el único requerimiento que Zoho no puede satisfacer por sí solo.
Por qué Zoho por sí solo no cumple el requerimiento
RFI sección 10 · verificado contra la lista publicada de centros de datos de Zoho
● Ver diagrama
Arquitectura de continuidad intercontinental propuesta
Tres niveles de continuidad — qué protege realmente cada uno
RFI sección 10 y pregunta 4 · una decisión que ETRAM debe tomar
● Ver diagrama
Su requerimiento
Base de datos y documentos alojados en nube, con réplica o copia de recuperación en un centro de datos fuera del continente del primario — dos centros dentro de Estados Unidos o Norteamérica es explícitamente insuficiente
Identificar proveedor, país, región y continente tanto del primario como de la réplica
Indicar RPO y RTO, cifrado, gestión de accesos, MFA, bitácora de auditoría y retención
Pruebas de restauración documentadas al menos dos veces al año
Exportación completa y legible de datos, adjuntos, configuración y documentación
La cuenta, aplicación, datos y credenciales administrativas pertenecen a ETRAM Inversiones
Lo que significa en la construcción
Respuesta honesta primero: los pares de centros de datos de Zoho son intracontinentales, de modo que este requerimiento no se cumple de forma nativa y ningún proveedor puede afirmar lo contrario con veracidad
Una tubería de exportación construida a la medida, desde Creator hacia almacenamiento propiedad de ETRAM en un segundo continente
Manifiesto y suma de verificación en cada exportación, con verificación automática y alerta cuando la verificación falla
Versionado, cifrado en reposo e inmutabilidad por bloqueo de objetos en el archivo
RPO y RTO comprometidos por nosotros contra el nivel elegido, dado que Zoho no publica un SLA de cliente para este escenario
Procedimiento de restauración escrito, con pruebas semestrales y expediente de evidencia
Todos los activos a nombre de ETRAM; el desarrollador opera bajo un usuario nombrado y revocable
Roles y separación de funciones
Dos usuarios, tres fronteras limpias.
Su sección 3.1 rechaza el modelo en el que el operador origina y aprueba todo. Coincidimos, y el modelo de permisos siguiente es lo que lo hace cumplir — el operador no tiene un botón de aprobación restringido, simplemente no tiene botón de aprobación.
Gerente-administrador
Web · origina y autoriza
Importa la liquidación de Cumayasa y revisa las líneas extraídas
Crea y autoriza despachos; fija y versiona precios
Revisa y aprueba pagos y remesas; observa o devuelve líneas individuales
Concilia, autoriza excepciones y levanta bloqueos de 48 horas
Consulta todos los reportes y exportaciones
No puede: eliminar el historial de auditoría, ni aprobar registro alguno sin que se conserven la fecha, el usuario y la evidencia.
Operador-supervisor
Móvil · ejecuta y documenta
Consulta únicamente despachos autorizados
Confirma entrega, no entrega o incidencia
Registra pagos individuales y crea remesas consolidadas
Adjunta comprobantes y captura volantes de depósito con la cámara
Consulta sus propios registros y pendientes
No puede: crear ni autorizar un despacho, aprobar definitivamente sus propios pagos, borrar operaciones, alterar precios, ni desbloquear un cliente vencido.
Choferes y ayudantes
Sin acceso alguno al sistema
Realizan la entrega física
No son usuarios licenciados y no tienen credenciales
Aparecen en el sistema solo si un registro de entrega los nombra, si ustedes deciden capturarlo
No pueden: acceder a la aplicación ni consultar datos — confirmado como frontera explícita de alcance en la sección 3.
El modelo de datos detrás
Doce estructuras sostienen toda la operación.
Nada aquí es especulativo — cada una corresponde a un módulo numerado de la sección 4. Las dos que merecen atención son el auxiliar de aplicaciones y la bitácora de auditoría, porque son las que hacen que la regla FIFO sea demostrable y no solamente calculada.
Clientes
Código, nombre, teléfono, estado, saldo y eventos de vencimiento
Productos
Catálogo autorizado de combustibles y aceites
Precios
Precio y descuento versionados, vigencia, autorizado por
Lote de despacho
Encabezado de Cumayasa, archivo fuente, totales y estado
Conduce
Detalle de línea — cliente, producto, galones, precio, descuento, total
Bitácora de extracción
Datos OCR originales, confianza y cada corrección realizada
Entrega
Entregado, no entregado o incidencia, con motivo
Auxiliar por cobrar
Un saldo abierto por cliente y por conduce
Pagos
Monto, fecha, banco, referencia, comprobante, cuenta receptora, estado
Aplicaciones
Pago a conduce, monto aplicado, saldo antes y después
Remesas
Encabezado más líneas de asignación por cliente y control de cuadre
Bitácora
Usuario, acción, registro, valor anterior, valor nuevo, fecha y hora
Sus dieciséis preguntas, respondidas
La sección 13 de su RFI, una por una.
Las respuestas marcadas Confirmado están verificadas contra la documentación publicada por Zoho. Las marcadas Por confirmar requieren confirmación escrita de Zoho o una decisión de ETRAM antes de poder comprometerse contractualmente — lo decimos en lugar de suponerlo. Las preguntas comerciales se responden aquí de forma estructural; las cifras siguen al taller de descubrimiento.
No — y este es el hallazgo más importante de este documento. Zoho opera cada región como un par primario y secundario, y todo par publicado se encuentra dentro de un mismo continente: la región de Estados Unidos es Quincy y Dallas, Europa es Ámsterdam y Dublín, India es Mumbai y Chennai, Australia es Sídney y Melbourne, Canadá es Toronto y Montreal, Japón es Tokio y Osaka.
Su documento anticipa esto con precisión al establecer que dos centros dentro de Estados Unidos o dentro de Norteamérica no es suficiente. Esa es exactamente la situación que produce la propia topología de Zoho. A cualquier proveedor que responda esta pregunta con un sí sin matices, conviene pedirle que ponga por escrito el par de ciudades.
Lo que Zoho sí provee de forma nativa es respaldo de aplicación — la estructura de la aplicación, los scripts Deluge y los datos en archivos CSV, descargables como zip y programables con la frecuencia que se elija. Es una capacidad real y útil, pero el destino es su descarga, no otro continente. Llevarlo a otro continente es el trabajo de ingeniería descrito en la pregunta 2.
Una tubería de exportación programada que corre desde Creator hacia almacenamiento de objetos propiedad directa de ETRAM Inversiones en un segundo continente. Si la aplicación Creator reside en la región de Estados Unidos, el archivo reside en Europa; el emparejamiento lo eligen ustedes en el descubrimiento.
La tubería tiene cuatro partes: una exportación programada de todos los datos transaccionales; una exportación programada del repositorio documental — liquidaciones fuente, volantes de depósito y fotografías de entrega, que el respaldo estándar de Creator no cubre por completo; un manifiesto y suma de verificación escritos con cada exportación; y un paso de verificación automática que les alerta cuando un archivo no supera su control de integridad. El almacenamiento es versionado, cifrado en reposo y protegido con bloqueo de objetos, de modo que el archivo no pueda eliminarse ni siquiera desde una cuenta administrativa comprometida.
Destinos adecuados incluyen AWS S3 en Irlanda o Fráncfort, Azure Blob Storage en Europa Occidental, Google Cloud Storage en europe-west, o Cloudflare R2. Cualquiera de ellos satisface la prueba intercontinental frente a una región Zoho en Norteamérica. El costo de almacenamiento con sus volúmenes es pequeño; el peso real está en la ingeniería y en la disciplina de las pruebas, y se cotiza una vez elegido el nivel descrito en la pregunta 4.
Zoho no publica un RPO y RTO de cara al cliente para Creator que cubra el escenario del que ustedes se están protegiendo, de modo que citar uno como si fuera suyo sería engañoso. Lo que sí puede comprometerse es el RPO y RTO de la tubería que construimos, porque los determinan decisiones de diseño que ustedes controlan.
El RPO equivale al intervalo de exportación. Un ciclo diario implica una pérdida máxima de un día; un ciclo incremental horario para documentos y transacciones lo reduce a aproximadamente una hora. Ambos son alcanzables — la elección es de costo y complejidad, no un límite técnico.
El RTO depende enteramente del nivel de continuidad que elijan en la pregunta 4. El Nivel A restaura sus datos, pero reconstruir una aplicación en funcionamiento sigue dependiendo de que Zoho esté disponible. El Nivel B mantiene un paquete de reconstrucción probado para recrear la aplicación en otra región Zoho dentro de una ventana acordada. El Nivel C mantiene una ejecución independiente y ofrece el RTO más corto al mayor costo recurrente.
Comprometeríamos estas cifras contractualmente contra el nivel elegido y las demostraríamos en la prueba de restauración semestral. La disponibilidad de la propia plataforma Zoho sigue regida por los términos estándar de Zoho, que son independientes y que ETRAM debería revisar directamente.
Esta pregunta merece una distinción que es fácil de difuminar. Un archivo de CSV y documentos en otro continente garantiza que sus datos sobrevivan. No les entrega, por sí solo, un sistema en funcionamiento — porque restaurar dentro de Creator exige que Creator esté disponible.
Así que la respuesta honesta depende de contra qué falla se están asegurando realmente, y existen tres niveles:
Nivel A — supervivencia del dato. Exportaciones cifradas y verificadas en un segundo continente. Protege contra pérdida de datos, corrupción, borrado accidental y compromiso de cuenta. El más rápido de entregar y el de menor costo. Reconstruir la aplicación sigue asumiendo que Zoho existe.
Nivel B — paquete de reconstrucción probado. El Nivel A más una definición versionada de la aplicación y scripts de importación, probados, de modo que la aplicación pueda recrearse en otro centro de datos de Zoho dentro de un tiempo objetivo acordado. Es el nivel que recomendaríamos para una operación del tamaño de la suya.
Nivel C — ejecución independiente. Datos transaccionales replicados a una plataforma independiente en el otro continente, que puede levantarse si Zoho no está disponible como plataforma. El RTO más corto, el mayor costo y una complejidad adicional permanente.
Preferimos que elijan esto deliberadamente en el descubrimiento y no que descubran la distinción durante un incidente.
Tres rutas independientes, todas disponibles para su propio administrador:
Respaldo nativo de Creator — estructura de la aplicación, scripts Deluge y datos en CSV, descargables como zip, de forma manual o programada, desde dentro de su cuenta.
Exportación a nivel de reporte — cualquier reporte se exporta a Excel, CSV o PDF directamente desde la interfaz, incluidas la bitácora de auditoría y el detalle de aplicación de pagos.
El archivo fuera del continente — el bucket está a nombre de ETRAM Inversiones, de modo que ustedes tienen las credenciales y pueden descargar el archivo completo en cualquier momento sin intervención nuestra.
Una salvedad documentada: Zoho indica que los datos de campos de integración no son manejados por el respaldo y restauración estándar. Nuestra tubería de exportación cubre esa brecha explícitamente, que es una de las razones por las que existe en lugar de depender del respaldo nativo. Los procedimientos escritos de exportación y restauración forman parte de la documentación de entrega.
Estructuralmente la respuesta es sencilla y la base de costo es pequeña, porque Zoho Creator se licencia por usuario y ustedes han definido dos: un gerente-administrador y un operador-supervisor. Choferes y ayudantes no son usuarios, así que no generan licencia.
Las partidas que requieren cotización son: licencias Creator para dos usuarios; la cuota de llamadas de IA y OCR, que se consume por extracción y es la partida con mayor probabilidad de requerir ampliación conforme crezca el volumen; almacenamiento de Creator para el conjunto documental; el almacenamiento externo en el segundo continente; implementación; y soporte continuo.
Las dos cifras que no vamos a suponer son la cuota de llamadas de IA y el nivel de plan, porque ambas dependen de su volumen diario real y del enfoque de extracción que se seleccione en la pregunta 7. Ambas se resuelven en el descubrimiento, y la propuesta comercial completa sigue inmediatamente después — este documento va deliberadamente sin precios para que el alcance se acuerde antes de ponerle cifras.
Ningún proveedor puede cotizar responsablemente una cifra de precisión antes de ver sus documentos reales, y nosotros no lo haremos. Lo que sí podemos decirles es cómo se llega a ese número y qué lo determina.
Su Anexo C ya propone entre veinte y cincuenta conduces representativos, y ese es el orden de magnitud correcto. El factor decisivo no es la cantidad sino la consistencia: si la liquidación de Cumayasa llega siempre con el mismo formato, una muestra modesta basta y la precisión sobre los campos estructurados suele ser alta. Si el formato varía, o si las capturas son fotografías de papel tomadas en ángulo y con poca luz, la precisión baja y la pantalla de revisión asume más carga.
Lo cual es el punto de diseño deliberado. No tratamos la precisión del OCR como el control. El control es la pantalla de revisión obligatoria del Flujo 01, donde el gerente confirma las líneas extraídas contra el documento original antes de que nada llegue al auxiliar, con los campos dudosos resaltados y todos los totales recalculados. Así, una extracción deficiente cuesta unos segundos de corrección; nunca produce una cuenta por cobrar equivocada.
Entréguennos las veinte a cincuenta muestras y las procesaremos con los enfoques candidatos para reportar precisión medida por campo antes de que ustedes se comprometan a construir — eso es un entregable de descubrimiento, no una promesa.
Los formatos de archivo no son la restricción. La documentación del campo OCR de Zoho Creator cubre JPG, JPEG, PNG, BMP, TIF, TIFF, WEBP y PDF, y reconoce texto en inglés. La capacidad de procesamiento inteligente de documentos de Zoho cubre PDF, PNG, JPG, JPEG y WebP.
La restricción real es la estructura. El campo OCR incorporado en Creator extrae texto de una imagen — es adecuado para leer un número de referencia o una tarjeta de presentación. Su liquidación es una tabla de múltiples filas donde cada línea de cliente debe regresar como campos discretos y validados. Ese es un problema de comprensión documental, no de extracción de texto, y requiere un motor que devuelva partidas y no un bloque de texto.
Dos rutas viables, ambas a comparar contra sus muestras en el descubrimiento: el procesamiento inteligente de documentos del propio Zoho, que explícitamente admite extraer datos estructurados de tablas y partidas de facturas y mantiene todo dentro del entorno Zoho; o un servicio externo de IA documental invocado desde Deluge, que normalmente maneja mejor las capturas fotográficas difíciles. Zoho también ofrece modelos OCR personalizados entrenables a un formato específico, que vale la pena evaluar si su liquidación tiene un formato estable.
Su RFI también pregunta si una integración directa sería superior al OCR en caso de que el conduce nazca en un sistema estructurado en Cumayasa. Categóricamente lo sería — una alimentación de datos elimina por completo el riesgo de extracción. Vale una conversación con Cumayasa antes de comprometerse con OCR, y lo plantearíamos en el descubrimiento.
Cuatro controles separados, cada uno aplicado al momento de guardar y no descubierto después en un reporte:
Número de conduce — único en el sistema. Un lote recargado se detecta y se rechaza en la importación, antes de que pueda crear un segundo juego de cuentas por cobrar.
Referencia bancaria — contrastada contra todos los pagos y todas las remesas. Una referencia repetida se bloquea y se muestra el registro existente para que el operador vea lo que ya registró.
Reutilización de conduces entre remesas — un conduce o pago ya consumido por una remesa no puede asignarse a otra, aplicado al guardar como exige su sección 7.3.
Clave de idempotencia por registro — este es el control que importa en móvil. Un registro creado sin conexión y sincronizado dos veces, o un formulario enviado dos veces con mala señal, lleva la misma clave y se escribe una sola vez. Sin ella, la operación offline es una máquina de generar duplicados.
Los tres casos se resuelven con la misma estructura de fondo: un auxiliar de aplicaciones que registra cada aplicación por separado, en lugar de guardar una marca de pagado o no pagado sobre el conduce.
Cada aplicación escribe su propio registro — qué pago, qué conduce, cuánto se aplicó, el saldo antes y el saldo después. Así, un pago abarca naturalmente varios conduces, un conduce recibe naturalmente varios abonos parciales en el tiempo, y el saldo pendiente es siempre el resultado aritmético de sus aplicaciones y no una cifra que alguien mantiene a mano.
Una remesa consolidada se sitúa un nivel por encima de esto: distribuye un solo depósito entre clientes, y luego, dentro de cada cliente, el monto asignado pasa por la misma lógica de aplicación por antigüedad. Por eso la remesa del Flujo 04 y el pago individual del Flujo 03 producen asientos idénticos y consistentes.
Una rutina en Deluge que se ejecuta cada vez que se asigna un monto a un cliente, en cinco pasos: cargar todos los conduces pendientes de ese cliente; ordenar por fecha de despacho ascendente, luego por hora, y luego por el número secuencial más antiguo ante empate; saldar cada conduce por completo antes de pasar al siguiente; registrar un abono parcial en el primer conduce que el remanente no alcance a cubrir y conservar su saldo; y escribir un registro de aplicación por cada aplicación.
Dos puntos de ingeniería merecen decirse con claridad, porque es donde suelen fallar las implementaciones de este patrón. Primero, Zoho Creator no tiene transacción multi-registro, así que calculamos el conjunto completo de aplicaciones en memoria, validamos que sume exactamente el pago, y luego confirmamos y verificamos — revirtiendo y marcando si la verificación falla, en lugar de dejar un pago a medio aplicar. Segundo, el auxiliar del cliente se bloquea durante la aplicación, de modo que dos pagos procesados casi al mismo tiempo nunca consuman el mismo saldo.
La distribución propuesta se muestra al gerente antes de aprobar. Un cambio manual al resultado FIFO es posible pero exige autorización gerencial, motivo obligatorio y registro de auditoría — como especifica su sección 6.1. Los conduces saldados pasan a estado Saldado y permanecen en el historial; nada se elimina.
Blueprint modela el proceso como estados con transiciones definidas de forma explícita, y un registro solo puede desplazarse por una transición que exista. No hay ruta de importado a entregado sin pasar por despacho autorizado, porque tal transición no está definida. El salto de etapa se impide estructuralmente y no mediante reglas de validación que podrían eludirse.
La autoaprobación se impide vinculando cada transición a un rol. La transición de autorizar pertenece al gerente; la interfaz del operador no presenta un botón de aprobar deshabilitado, no presenta acción de aprobar en absoluto. Lo mismo aplica a la inversa — el gerente no registra entregas en nombre del operador sin que quede visible como tal.
Cada transición registra quién la ejecutó y cuándo, que es lo que produce la cadena hecho por / revisado por / autorizado por que exige su sección 3.1, con las tres marcas de tiempo almacenadas por separado y no como una sola fecha de última modificación.
Una tarea programada corre cada hora, recalcula la antigüedad de cada conduce abierto desde su hora de despacho confirmado, y le asigna uno de cuatro rangos: 0-24 normal, 24-40 seguimiento con alerta amarilla a ambos usuarios, 40-48 próximo a vencer con alerta naranja prioritaria, y más de 48 horas cliente a tomar acción en rojo.
El estado rojo aplica un bloqueo preventivo sobre cualquier nuevo despacho a ese cliente. El bloqueo es una condición sobre la transición de autorización de despacho, de modo que no puede sortearse creando el lote de otra manera — la transición simplemente no se dispara mientras el cliente esté bloqueado.
Levantarlo requiere una excepción autorizada por el gerente, que registra quién la autorizó, cuándo, por qué, y para qué cliente y lote específicos. Las excepciones son reportables, de modo que un patrón de anulaciones repetidas para un mismo cliente queda visible en lugar de enterrado.
Una regla sostiene todo esto y conviene repetirla: solo un pago conciliado detiene el reloj. Un pago meramente reportado por el operador, o incluso validado pero aún no recibido efectivamente por ETRAM, deja el conteo corriendo. Esa distinción es lo que hace confiable la alerta.
ETRAM Inversiones, sin matices. La cuenta de Zoho se crea a nombre de ETRAM, con ETRAM en posesión de las credenciales de superadministrador. La aplicación, todos los datos, todos los adjuntos, el código fuente Deluge, la configuración y la documentación les pertenecen. El bucket de almacenamiento externo en el segundo continente queda igualmente a nombre de ETRAM.
Nosotros trabajamos bajo un usuario de desarrollador nombrado dentro de su cuenta, que ustedes pueden revocar en cualquier momento sin efecto alguno sobre el sistema en funcionamiento. Recomendaríamos ese esquema incluso si no lo estuvieran pidiendo — es la única estructura en la que un cambio de proveedor no representa un evento.
Deliberadamente no respondido aquí, y por una razón. Dos asuntos abiertos mueven la cifra de forma material: el enfoque de extracción que se seleccione en las preguntas 7 y 8, que no puede fijarse hasta haber procesado sus muestras reales; y el nivel de continuidad que se seleccione en la pregunta 4, donde el Nivel A y el Nivel C son trabajos genuinamente distintos.
Lo que sí podemos comprometer ahora es la forma. Los hitos están sujetos a aceptación, y cada uno termina con una demostración evaluada contra sus propios criterios de la sección 14, liberándose el pago solo cuando ustedes aceptan ese hito. Los cortes naturales siguen su propia lista de entregables: descubrimiento y diseño; el núcleo transaccional hasta FIFO y remesas; extracción y pantalla de revisión; continuidad, prueba de restauración y entrega.
Un periodo de garantía por corrección de defectos sigue a la salida a producción, y el soporte continuo se cotiza como bolsa de horas o retainer mensual, según su preferencia. La propuesta comercial completa sigue al taller de descubrimiento — momento en el que las cifras se apoyan en sus documentos y no en suposiciones sobre ellos.
Desarrollador Certificado en Zoho Creator, dedicado a tiempo completo a implementaciones Zoho en CRM, Creator, Books, Analytics, Projects y Flow. Directamente pertinente a este encargo: sistemas de aprobación multietapa con transiciones de Blueprint restringidas por rol y bitácoras inalterables; migraciones contables y trabajo de conciliación con auxiliares de clientes y suplidores, liquidaciones parciales e integridad de saldos; tuberías de extracción documental que alimentan registros validados; y aplicaciones Creator móviles para operadores de campo.
Podemos aportar referencias y casos comparables a solicitud, y con gusto recorremos un sistema en funcionamiento en lugar de una presentación. Para una construcción con esta carga de lógica contable, también sugeriríamos que el taller de descubrimiento incluya una prueba de concepto breve sobre sus conduces reales — es la vía más rápida para que ustedes juzguen la calidad de la extracción y para que nosotros la coticemos con precisión.
Los hallazgos que definen este proyecto
Cuatro cosas que conviene saber antes de que alguien cotice.
Estos son los puntos donde la respuesta de un proveedor revela si leyó su documento o lo hojeó. Fijamos nuestra posición en cada uno, incluso donde ser francos nos cuesta algo.
Crítico · no es nativo de la plataforma
La réplica intercontinental es el único requerimiento que Zoho no puede cumplir
Ustedes lo anticiparon con precisión — escribieron que dos centros dentro de Estados Unidos o Norteamérica no serían suficientes. La topología publicada de Zoho produce exactamente eso: Quincy y Dallas, Ámsterdam y Dublín, Mumbai y Chennai. Todo par es intracontinental.
Es enteramente resoluble, pero solo construyendo algo fuera de Zoho y registrándolo a nombre de ETRAM. No es una casilla en una pantalla de configuración, y no debería cotizarse como tal.
Nuestra recomendación: decidan el nivel de continuidad en el descubrimiento antes de dimensionar cualquier otra cosa, porque el Nivel A y el Nivel C son proyectos distintos. Para una operación del tamaño de la suya aconsejaríamos el Nivel B — archivo verificado fuera del continente más un paquete de reconstrucción probado.
Material · afecta alcance y precio
El OCR sobre una liquidación de múltiples clientes no es el campo OCR
El campo OCR incorporado en Creator devuelve texto de una imagen. Su liquidación es una tabla donde cada línea de cliente debe regresar como campos validados y discretos con totales que cuadren. Son problemas distintos, y confundirlos es la vía más probable para que este proyecto quede subcotizado.
El enfoque que tomaríamos convierte la calidad de extracción en una variable administrable y no en una apuesta: un motor de comprensión documental que devuelva partidas, y una pantalla de revisión gerencial obligatoria con los campos dudosos resaltados antes de que nada llegue al auxiliar.
Nuestra recomendación: envíen pronto las veinte a cincuenta muestras de su Anexo C. Compararemos los motores candidatos y reportaremos precisión medida antes de que se comprometan. También vale una llamada a Cumayasa — si la liquidación nace en un sistema estructurado, una alimentación directa supera a cualquier OCR.
Decisión de diseño · fácil de errar
La operación offline y el FIFO automático deben reconciliarse deliberadamente
La app móvil de Creator sí admite envío de formularios sin conexión y captura por cámara, y sincroniza al recuperar conectividad. Pero los listados offline son una fotografía de la última sincronización, y los saldos que el operador ve sin conexión pueden estar desactualizados cuando el registro suba.
Por eso el FIFO debe aplicarse del lado del servidor al sincronizar, contra el auxiliar tal como esté en ese momento — nunca calculado en el dispositivo contra los saldos de ayer. Y cada registro offline necesita una clave de idempotencia, o una doble sincronización aplicará el mismo dinero dos veces en silencio.
Nuestra recomendación: traten la captura offline como recolección de evidencia, no como contabilidad. El operador captura el pago y el comprobante; la aritmética del auxiliar ocurre del lado del servidor al llegar y el resultado se le muestra de vuelta.
Fortaleza · de su documento, no del nuestro
Su modelo de control ya es el correcto
La sección 3.1 de su RFI rechaza que el operador origine y apruebe todo, y propone en su lugar control por etapas y por excepción. Esa es la respuesta correcta, y es inusual recibir un RFI que ya lo tenga resuelto.
También hace más limpia la construcción. Como las fronteras están claras, el modelo de permisos es sencillo de aplicar y sencillo de probar — y los criterios de aceptación de su sección 14 ya están redactados como afirmaciones verificables, que es justo lo que necesita una fase de aceptación bien llevada.
Nuestra recomendación: conserven la sección 14 exactamente como está y conviértanla en el guion de aceptación. Demostraríamos contra esos criterios uno por uno en cada hito, incluyendo los casos negativos — el operador intentando aprobar su propio pago, y la remesa descuadrada negándose a enviarse.
Lo que necesitaríamos de ustedes
Seis insumos convierten este análisis en una propuesta en firme.
Su Anexo C ya enumera la mayoría — esto es simplemente dónde encaja cada uno en la evaluación, y por qué importa.
20 a 50 conduces realesAnonimizados si es necesario. Deciden el enfoque de extracción y son la única base honesta para una cifra de precisión o un precio.
Comprobantes de Popular y BanreservasPara determinar cuánto puede leerse automáticamente de un comprobante frente a lo que digita el operador.
Reportes consolidados del operadorIncluyendo al menos una remesa cuadrada y una con diferencia — los casos que fallan enseñan más que los limpios.
Listado de clientes, catálogo y tabla de preciosDefine el volumen de datos maestros, las reglas de coincidencia y la lógica de descuentos.
Cifras de volumen diarioConduces por día, clientes por lote y pagos por día. Determina la cuota de llamadas de IA y el nivel de licenciamiento.
Su decisión de nivel de continuidadNivel A, B o C de la pregunta 4. Nada más en la arquitectura puede fijarse hasta que se resuelva esto.
Cómo se ejecutaría el trabajo
Por hitos con aceptación, en el orden que su lista de entregables ya implica.
01
Descubrimiento sobre documentos reales
Una sesión de trabajo sobre sus conduces, comprobantes y remesas reales — no una entrevista de requerimientos. Termina con un mapa de proceso validado, un enfoque de extracción comparado con precisión medida, y su nivel de continuidad decidido. Solo entonces se ponen cifras al alcance.
02
Construcción contra sus propios criterios
Cada hito termina en una demostración evaluada contra la sección 14, incluidas las pruebas negativas — autoaprobación rechazada, remesa descuadrada rechazada, conduce duplicado rechazado. Ustedes aceptan el hito antes de que comience el siguiente.
03
Entrega sobre la que puedan actuar solos
Capacitación para ambos usuarios, procedimientos escritos de exportación y restauración, una prueba de restauración ejecutada y documentada desde el archivo fuera del continente, y cada credencial a nombre de ETRAM. La definición de terminado es que ustedes podrían cambiar de proveedor sin tocar el sistema.
Próximo paso
Una sesión de trabajo, sobre sus documentos reales.
Lo que proponemos
Envíen el paquete de muestras — los conduces, comprobantes y ejemplos de remesas de su Anexo C. Trabajaremos sobre ellos antes de reunirnos, no durante la reunión.
Realicemos la sesión de validación — la agenda de su Anexo B está bien construida y la seguiríamos, con una adición: quince minutos sobre los tres niveles de continuidad, ya que esa decisión gobierna la arquitectura.
Reciban un informe de extracción comparado — precisión medida por campo sobre sus propios documentos, con una recomendación entre el procesamiento documental de Zoho, un motor externo y una alimentación directa desde Cumayasa.
Reciban la propuesta comercial completa — alcance, hitos, cronograma, licenciamiento, soporte y garantía, fundamentados en lo que mostraron las muestras y no en suposiciones.
Este documento no contiene precios por diseño. Dos decisiones abiertas — el enfoque de extracción y el nivel de continuidad — mueven la cifra de forma material, y cotizar antes de resolverlas produciría un número que después cambia. Preferimos acordar el alcance primero y cotizarlo una sola vez, con precisión.
What happens at this stage
100%
Drag to pan · Ctrl + scroll to zoom · + / − / 0 keys