Proof-of-Payment Persistence Automation: Paid, With Proof That Vanished on Reload

Updating a screen's own local, in-memory state immediately after an action feels, and often is, the correct way to give someone instant visual feedback that something just happened — a new item appears in a list the moment they finish an action, with no visible delay waiting for a server round-trip. The risk is specific to what happens when that immediate, local update is the ONLY place the new data ever actually lives: a browser tab's own in-memory state is, by its nature, temporary — it disappears the moment the tab is closed or the page is reloaded, and it was never shared with any other device, teammate, or session in the first place. Any piece of data meant to be a durable record of something that happened has to be written somewhere that outlives the specific browser tab that created it, or it is not genuinely a record — it is a temporary illusion of one.

Centriu Gauge's Accounts Payable screen lets a person settle an outstanding bill and, in the same action, attach a proof-of-payment document — a receipt or bank confirmation evidencing that the payment genuinely occurred, an important part of a real financial audit trail for any organization tracking its own payables carefully.

Before this fix, completing this action built a document object entirely in local JavaScript memory: `const newDoc: FinancialDocument = { id: \`doc${Date.now()}\`, payableId, fileName: documentData.file.name, ... }` — an identifier constructed from the current timestamp, with no corresponding row ever written to any database table, and updated the screen's own displayed document list with `setDocuments(prev => [...prev, newDoc])` — a purely local, in-memory state update. The actual file the person had selected — the real receipt or confirmation image or PDF — was never uploaded anywhere; no call to any storage system existed in this path at all. Immediately afterward, the code DID correctly call `payableService.markAsPaid(payableId, paymentDate, accountId)`, which genuinely persisted the bill's own paid status, its payment date, and which cashbox account the payment came from, to the real database.

The practical result: a person settling a bill and attaching proof would see, in that exact moment, both the bill move to "Paid" status and a document appear in the attached-documents list — a completely successful-looking action, end to end, on screen. The bill's paid status genuinely was correct and durable. The attached document, however, existed only in that specific browser tab's own memory: reloading the page, returning to the same bill later, or a colleague opening the identical record from a different session would show no proof document at all, because none had ever actually been written anywhere durable — not to a database table recording its existence, and not to any storage location holding the actual file. The one piece of the action specifically meant to serve as durable evidence that a payment happened was the one piece that was never genuinely saved.

The fix corrects both halves of the persistence gap in sequence. The document's real metadata is now created first, through `documentService.create({ payableId, fileName, fileType, documentType, uploadDate, supplierId })` — a genuine database insert returning a real, permanent row identifier (`savedDoc.id`), rather than a value invented on the client. That real identifier is then used to upload the actual selected file to Supabase Storage, at a path keyed specifically by that database identifier (`gauge-documents/<savedDoc.id>/<fileName>`) — matching the exact path convention the product's own document-download feature already expects elsewhere, so a stored file is genuinely retrievable later, not merely present in storage under some unrelated name. The upload step is treated as best-effort relative to the metadata write that precedes it — a storage failure is logged rather than aborting the whole action, on the reasoning that the document's own record (proving intent and providing basic information) is more important to preserve than blocking the entire payment-settlement action over a transient storage hiccup — but ANY failure in the overall settlement flow now surfaces a visible error message to the person performing the action, replacing a prior behavior where a failure was written only to the browser's own developer console, someplace no one settling a real bill would ever think to check.

Before the fix, a person settling a bill inside Centriu Gauge and attaching a bank confirmation receipt would see the bill move to "Paid" and the receipt appear in the attached-documents list, both immediately and both looking entirely correct. Returning to that same bill the next day — or simply reloading the page — would still show the bill correctly as "Paid," but the attached receipt would be gone, with no record it had ever existed and no actual file to be found anywhere in storage. After the fix, the identical action persists a real document record and uploads the actual file, and the receipt remains genuinely attached and downloadable indefinitely afterward.

Centriu Gauge now genuinely persists a proof-of-payment document's metadata and actual file whenever a bill is settled with a document attached, closing a gap where the bill's own paid status was correctly and durably saved while the attached evidence of that payment existed only in the originating browser tab's temporary memory — gone on reload, and never actually uploaded to storage in the first place.

This automation governs Centriu Gauge's own internal persistence of proof-of-payment documents specifically attached during bill settlement — it does not change the settlement action itself (a bill's paid status was already correctly persisted before this fix), and does not add a new document-management feature beyond making the existing attach-during-settlement flow genuinely durable.

Updating a screen's own local state immediately after an action, before waiting for a server round-trip to confirm it, is a reasonable pattern for responsiveness — most of the time, the local update and the eventual server state agree, and the person sees instant feedback with no perceptible cost. The risk is specific to a case where the local update was never actually followed by a real, durable write at all — the immediate feedback becomes the entire lifespan of the data, rather than a preview of a save already genuinely in progress. Writing the real record first, and reflecting it on screen once that write is confirmed (or, as here, immediately alongside a fire-and-forget write that is independently checked for failure), keeps the responsiveness while ensuring the data the screen shows actually corresponds to something durable.