Application detail

/applications/<id> is the credit file for one application. It loads GET /v1/supplier/applications/:id. The page reads by default; every change starts from a button and finishes in a dialog.

Who can use it#

• Vendor-side users with applications.view in the organization that owns the application. Another organization's application shows "Access denied".
• Recording a decision needs applications.decide; without it the decision panel says so and shows no buttons (see Credit decision).
• Reminders and update requests to references need references.remind.
• Sending messages needs messages.send on the server.

Layout#

• Header: applicant, status chip (the shared application vocabulary), requested limit and payment terms in days, progress. Message applicant and Export PDF sit here.
• Decision panel and reference evidence come first, so the decision inputs are next to the decision. On a phone a bottom bar keeps Decline and Review approval within reach.
• Tabs (text tabs with counts where they have them): Overview, Application (answers, signature, bank, principals and guarantors, documents), References (responded of total), Messages, Activity. The decision history is below. Reference chips use the shared reference vocabulary (Not sent, Awaiting response, Opened, Responded, Declined, No response).

Where writing happens#

Related#

• Credit decision
• Credit applications list
• References list
• Messages inbox

Credit agreement card#

On the Overview tab of an approved application, for roles with signatures.view: a card named Credit agreement with the stage in words and the date it last changed, and four steps in the customer's own wording (Approved, Customer signs, You countersign, Signed). "Waiting for your countersignature" is marked as your turn. An application that was approved but never sent an agreement says "Agreement not sent" with a Send the agreement button. The button opens the Signatures tab. Declined, expired, failed, needs review and voided agreements show their label without the steps. The newest agreement request is the one shown, so a voided request that was sent again reads as the new one.

Principals and guarantors#

The Application tab lists the owners and officers the customer named, when the supplier's form asked for them: name, title, ownership %, email and the SSN shown as its last 4 digits only. A pill in the section header says when the customer acknowledged the personal guaranty with the application's signature. The Personal guaranty column says Signed once a guaranty request for that principal is sealed in the Signatures tab, and Unsigned before. Choosing a principal in the Signatures tab pre-fills the link address from the principal's email. The same list, without SSN digits, is in the application PDF.

Signatures tab#

Shown to staff who hold signatures.view. Lists the credit agreement and personal guaranty requests with each signer's status. With signatures.send the credit team sends the agreement or a guaranty for a named principal (an address for the link is required), and reminds signers. With signatures.void they cancel an open request with a reason. With signatures.review they accept or cancel a signed copy that failed its automatic check. Signed and unsigned files open through a short-lived link, and each open is audited. See Signatures.

The tab also holds the supplier's Signed paperwork setting (not used, optional, required before activation; needs documents.requirements.manage) and, for an approved application, Activate credit line (applications.decide). When the setting is required and the agreement or a guarantor's request is not sealed, activation is refused with a message; a holder of signatures.review can go ahead with a written reason, which is audited. Activation is final and notifies the customer.

Forms#

Below the tabs, a Forms panel appears for roles that hold forms.request (the credit team). Pick one of your published forms and Ask to request it from the applicant; the request shows in the applicant's application and in their activity. Once the applicant submits, the answers open in the panel (file answers are listed as attached documents; open them under Documents). Until then the row reads "waiting for the applicant". You can ask for the same form again once the earlier request is answered; while one is waiting, a second request is refused. Each request keeps its own answers. Requests are refused once a decision is recorded. Build the forms under Forms.