Saved Simulations and History

Once a seller presses Save the simulation, the operation stops being a form on their phone and becomes a record that AltScore keeps. That record has a status that moves over time, mostly because of what an operator does in the Hub. It has a printable document the customer signs, and it shows up in the seller's history, where the seller can find it again, review it or pick it up where they left off.

This page follows a simulation from that moment on. How the plan is built before the save is covered in Operation Data and Payment Plan. How it is approved is covered in Own Financing in the Hub.

Whose Simulations a Seller Sees

A seller only ever sees the simulations they created. The history is always filtered to them, and if they open a link to another seller's simulation, the portal behaves as if that simulation did not exist: the detail page shows the generic error, the same one a simulation that was never saved would give. Two sellers who work the same route, or the same customer, do not see each other's work. The operator sees every simulation in the Hub.

Everything a seller does with a saved simulation, from opening it to discarding it, also depends on the organization still letting sellers build operations: the Build an operation capability in the Hub (see Configuring the Portal). If the operator turns it off, sellers can no longer open, edit, reactivate, discard, print or send the onboarding for what they saved, and the history page shows the generic error. The simulations themselves are untouched: they stay in the Hub, and the seller finds them again as soon as the capability is turned back on.

The Simulation Document

The document is the sheet the customer signs. The seller gets it with Print or save as PDF, which is on the summary right after saving and on the simulation's detail page. The button opens the browser's print dialog, and saving as PDF is one of that dialog's options, so the seller can print the sheet at the counter or keep a file to send. While the sheet is being prepared the button reads Preparing the document…, and if it cannot be prepared the seller sees "We could not prepare the document."

The browser draws the document from the saved simulation, not from what is on the screen. If the seller changes a field and does not save again, the document still shows the saved values. Most of the content is the simulation itself. A few texts come from the organization: the customer's legal name as AltScore has it, the product name and its terms and conditions (both from the credit product), and the document footer and the logo (both set in the Hub, under the portal's Branding). If one of those texts cannot be found, the document prints without it: the customer and product rows show a dash, and the terms, the footer or the logo are simply left out.

Operators can also download the same document as a PDF from the simulation in the Hub, with the PDF button, once it has a payment plan. That copy fills in the customer's personal details AltScore has on file, such as address, phone, DNI and CUIT. The sheet the seller prints never includes them: the customer writes them in by hand.

What the Document Contains

From top to bottom:

• The header: the organization's logo, Credit simulation, the simulation ID and Issued on {date}.
• A status chip: Financing status followed by the simulation's current status, so a sheet printed before approval says so.
• The rejection legend, only when the prequalification did not approve the customer: THIS CUSTOMER WAS REJECTED BY THE VERIFICATION, followed by the decision word the evaluation returned. A rejection does not stop the sale (see Prequalification), so it travels on the document instead.
• The operation data: Customer, Product, Financed amount, Origination fee, Principal to amortize, Nominal annual rate, Tax on interest (the VAT rate on interest), Maximum term, Operation number, Operation date, Branch and Issued on (the issue date).
• The payment plan, under Payment plan, with the columns No., Due date, Principal, Interest, Interest tax and Instalment, one row per installment and a Totals row. An installment that needs credit authorization has (*) next to its due date.
• The currency line: Amounts in {currency}., followed, when some installment is marked, by the legend (*) Exceeds the term. Requires credit authorization.
• The terms and conditions of the credit product, under Terms and conditions.
• Two boxes side by side. Customer signature, with blank lines for Name:, ID / Tax ID: and Date:. Conditions, which reads: "I acknowledge and accept the conditions of this simulation. Interest on balance, actual days / 365. Amounts in {currency}, subject to the final approval of the financing entity."
• The organization's footer, when the Hub has one.

The Simulation Detail

Each simulation has a detail page. The seller reaches it with View simulation on the summary, or by tapping the simulation in the history drawer. At the top it shows Simulation with the amount as the title, a status badge, and a prequalification badge when a prequalification ran. That badge reads Prequalification: followed by the evaluation's own decision word, or by Approved or Not approved when the evaluation returned no word. Next to the badges is Created on {date}, and a New simulation button opens a blank simulator.

The fields are Issue date, Annual nominal rate, Origination fee, VAT on interest, Operation no., Order date, Branch and Refinancing (Yes or No). Order date is the operation date the seller entered in the simulator under Operation date. Two more fields appear only when they have a value: Expires on and Approved on.

Expires on is the expiry date of the simulation's operation in the credit system. AltScore creates that operation only when an approval starts, so most simulations, saved and waiting for an operator, have none and do not show the field. If the approval does not go through by that date, the credit system cancels the operation, and a simulation still pending approval becomes Expired. Editing or reactivating a simulation sets its operation aside, so the field disappears until the next approval creates a new one.

Under the fields is the Schedule, the payment plan in read-only form. A simulation saved without a calculation shows This simulation has no calculated schedule. instead. The detail never shows the credit system's identifiers or internal error details, and AltScore does not send the portal a note explaining why a status changed: the seller reads the status itself, and the reasons stay on the operator's side, in the Hub.

The simulation actions the operator configured also appear on this page, except on a discarded simulation.

If the simulation cannot be loaded, the page shows the error and a Back to the simulator button. If a command fails, the page shows the error and then reloads the simulation, because its status may have changed in the meantime. An operator may have approved it in the Hub while the seller had it open, for example.

Statuses

A simulation is in one of six statuses. The portal shows each one as a colored badge.

In Spanish, the portal calls the expired status Vencida and the Hub calls it Expirada. Both words name the same status.

A status can only move along these paths:

Sellers never approve. An operator approves in the Hub, or a workflow the organization configured can approve or discard the simulation linked to a deal. The retry of an incomplete approval is done in the Hub. Both are described in Own Financing in the Hub.

Editing, Discarding and Reactivating

The buttons on the detail page depend on the status:

Approved, approving and discarded simulations have no Edit, Discard or Reactivate.

Editing

Edit reopens the simulator at the Customer and operation step with a banner: "You are editing an existing simulation: saving updates it instead of creating a new one." Every field, every installment row and the last calculation come back as they were saved. The prequalification is skipped and does not run again. The save button reads Save changes, and saving updates the same simulation rather than creating a second one.

Only a simulation in Pending approval or Expired can be edited or have its operation number changed, and saving an edit always puts it back in Pending approval, including when it was Expired. If the simulation is no longer editable when the seller saves (for example, because an operator approved it in the meantime), the portal shows "This simulation cannot be edited in its current state."

Discarding

Discard first asks for confirmation: Discard this simulation?, with "The simulation is cancelled and no longer available. This cannot be undone." AltScore allows a discard from Pending approval or Expired, and never from Approved. Discarding frees the simulation's operation number, so another simulation can use it.

The portal also shows Discard on an Approval incomplete simulation, but AltScore refuses it there, and the seller sees "This action does not apply to the simulation's current state." (listed in Errors, Warnings and Limits). The approval on that simulation has already gone part of the way, so the operator finishes it from the Hub instead.

Reactivating

Reactivate appears only on an Expired simulation and runs without confirmation. It returns the simulation to Pending approval with the same values, ready for an operator to approve it again.

The History

The history is the seller's list of everything they saved. It has two views: a drawer for a quick look and a full page for reviewing past work.

The Drawer

Inside the simulator and on a simulation's detail, the History button in the header opens a drawer. On a phone it takes the whole screen; on wider screens it is up to 380 px wide. Its title, History, carries the number of simulations in the list, which is the number of matches while a search is typed (for example History (12)), and is a link to the history page. The drawer has a close button, labeled Close the register for screen readers, and a search box.

Each row shows the amount, the status badge, the issue date and the number of installments (for example "6 installments"). Tapping a row opens that simulation's detail. The drawer shows 15 simulations per page, with arrows to move between pages.

The History Page

Elsewhere in the portal, History goes straight to the history page. At the top are a Back link to the simulator, the eyebrow Register, the title Queries made, the help line "Every query keeps the terms it reached and its outcome. Tap one to pick it up where you left off." and a New consultation button, which opens a blank simulator. Below come a search box and a grid of cards, 15 per page.

Each card shows the customer's name (or the amount, when the customer cannot be read), their document number, a progress badge and Credit line, the product's name (a dash when there is none). A card with a payment plan also shows APR, Amount and Plan. A card without a plan shows Limit instead: No limit when the customer was rejected, and a dash otherwise. The footer shows the progress label, the creation date and Resume; tapping anywhere on the card does the same as Resume.

Progress Badges

The card's badge says how far the consultation got. This is not the simulation's status: a card can say Simulated while the simulation is Pending approval or Approved.

Onboarding is not stored anywhere. After a reload, the card goes back to Simulated even though the onboarding was sent. See Customer Onboarding.

Searching

The search box, on both the drawer and the page, has the placeholder Sales slip, tax ID or customer name, where "sales slip" means the operation number. It searches 300 ms after the seller stops typing, and Escape clears it (the clear button is Clear the search). What the seller types decides how it searches:

• A simulation ID finds exactly that simulation.
• Exactly 11 digits are read as a CUIT and matched exactly against any identity of the organization with that value. If none matches, the page comes back empty.
• Anything else is free text. It matches part of an operation number, ignoring case, or the customer, using the same rules as the Customer Book search: words of the name in any order, the digits of the document and the customer number. It only considers customers within the seller's reach (their routes, or the whole organization when the Hub's Search scope is Every customer in the organization), and at most 200 of them.

Because the CUIT rule needs exactly 11 digits, a CUIT typed with dashes, such as 20-00000000-0, is searched as free text, not as a CUIT. It usually still finds the customer, because free text compares the digits of the document, but only among customers within the seller's reach. Whatever the search, the history only ever contains the seller's own simulations, newest first.

An empty history shows "No consultations recorded yet." A search with no match shows "No simulation matches that search." If the history page cannot be loaded, the seller sees the generic error, "We could not complete the operation. Please try again." The drawer has no error line of its own: a failed load there looks like an empty history.

Resuming a Consultation

Resume reopens a consultation where it stopped. With a payment plan, the seller lands on the summary, where what is left to do is the document and, when the Hub has Send the bot to the customer turned on, the onboarding. Without one, they land on the Customer and operation step. The prequalification result comes back, but the approved limit does not, because it is never stored, so the amount is not checked against this customer's limit.

Saving after resuming updates the same simulation; it never creates a second one. If the simulation can no longer be edited, the seller sees "This simulation cannot be edited in its current state."

Things to Know

A progress badge is not a status. The badge on a history card describes how far the seller got (prequalified, simulated, sent). The status on the detail and in the drawer describes where the operation stands with the operator. Read the status to know whether something was approved.

The document prints what was saved. The browser draws it from the stored simulation. An unsaved change on screen does not reach the sheet, so save first, then print.

Editing sends the simulation back to the queue. Any saved edit returns the simulation to Pending approval, even from Expired. An operator who was about to approve it is now looking at new values.

Discard cannot be undone, and it frees the operation number. Once discarded, the number can go on a new simulation. Discard on Approval incomplete is offered on screen but refused by AltScore; the operator resolves that case in the Hub.

Turning off Build an operation hides the seller's saved simulations. With the capability off, sellers cannot open, print, edit, reactivate, discard or send the onboarding for what they created, and their history page shows the generic error. Nothing is deleted: the simulations stay in the Hub and come back for the seller when the capability is turned on again.

A resumed consultation is not checked against the customer's limit. The approved limit is never stored, so after Resume the amount is not compared with it. If the cap matters, run the prequalification again with New consultation.

The onboarding badge is short-lived. Only one card can show it: the consultation whose onboarding the seller just sent. It goes back to Simulated as soon as the seller leaves that summary with View simulation or Back to start, starts a New consultation or any other new prequalification, or reloads the page. The onboarding itself was sent; only the badge forgets it.