Implement a full loan contracting workflow with calculations, quotes and offers

[bosue]

Before customers may actually apply for a loan, they need either a (binding) offer or at least a (non-binding) quote how the loan might look like and how much it would cost.

A simplified workflow may look like this:

Note that I focussed on business needs, not data structures.

Some lenders may only offer standardized products in the low-risk segment, others won’t have standardized products at all, so will consider every loan request individually. But all in all I’m quite positive about this being more or less how it’s handled everywhere.

Now we need to figure out how many separate doctypes we really need and which of this may instead be solved by building upon the basic workflow as proposed in #23.

To accommodate for such and similar workflows, there are (at least) three ways to go forward:

Variant A: one doctype

Consolidate all steps into a single Loan doctype. Finally, the fields needed are more or less all the same, just a few status fields, assignments and permissions have to be updated, various inputs and actions enabled resp. disabled

1. Remove “Loan application” doctype
2. Instead model the whole process using the Workflow module

Variant B: three doctypes

There may be a point or two in keeping a finalized Loan contract separate from ay preliminary stages:

• Reduce DX complexity
• Fields may be similar, but tasks and “Connections” are way different
• Signature handling and increased document security is only needed for (unilaterally binding) loan offers, (unilaterally binding) loan applications, and (bilaterally binding) loan contracts.
• Simplify handling of lists and reports
• …

Also, the timespan after which data may or even has to be deleted, varies a lot:

• Very early stages such as initial requests or mere quotes that never led to an actual (unilaterally binding) loan offer or loan application may be archived and deleted after a few years (and may even have to be deleted on a recurring basis, per GDPR)
• Once an approval process has taken place, no matter what the outcome may be, all collected data however needs to be stored for some 5 years (per regulatory law), so the quality of risk assessment, including rejections, may be analyzed by regulatory authorities.
• Once a legally (unilaterally binding) application resp. offer has been received resp. extended, the general document retention requirements, usually five to ten years, have to be observed.
• Once a contract has been signed, it has to be kept at least for the duration of the loan plus the general document retention requirements, usually five to ten years. If there are several contracts, this is extended to at least five years after the business relationship with the particular customers ended altogether.

Moreover, it makes a lot of sense to keep the Loan Contract even in its final stage as a mere contractual matter separate from the resulting material fact of an actual Loan. The contract, bilaterally binding as it may be, may be cancelled for various reasons, while an actual loan creates monetary and accounting facts. Once the actual Loan is disbursed, in (hopefully) most cases noone will care about the underlying contract anymore. Once disbursed, the actual Loan will be the relevant perspective and will constitute the perfect dashboard for all subsequent tasks.

In this case we would:

1. Add a Loan Request doctype with a Loan Calculation child doctype (1:n to a given loan request) that allows creation of mere loan quotes as a PDF
2. Turn the Loan Application doctype into a Loan Contract doctype (naming is up for discussion) that takes the data from a Loan Request and the preferred Loan Calculation.

• The latter may initially represent a Loan Application (unilaterally binding to the customer) or a Loan Offer (unilaterally binding to the bank)
• In the case of a Loan Application by the customer subsequently, in the submitted stage, it may be approved or denied by the bank.
• In the case of a Loan Offer by the bank it may be approved or denied in the draft stage, before being sent to the customer.
• Once submitted, it will constitute an actual contract that may only be cancelled or amended with bilateral agreement (a choice of amendments on the one hand and on the other hand cancelling while duplicating the values to a new draft Loan Contract should be present)
• Once signed by both parties, it may be used as a basis for (non-technically speaking: it may be “turned“ into) the actual Loan doctype.

Variant C: five doctypes

Of course, we could also have a separate DocType for each and every document (status):

1. Loan Request with the 1:n Loan Calculation child doctype
2. Loan Application (unilaterally binding to the customer)
3. Loan Offer (unilaterally binding to the bank)
4. Loan Contract (as a result of either 3 or 4 being approved and signed by the other party)
5. the actual Loan

Effectively there would be two more doctypes than in variant B.

Conclusion

From what I can see, both for DX and UX reasons, variant B seems the best way to go in terms of balancing simplicity of the whole doctype workflow with simplicity of each single doctype.

I would therefore propose working on an implementation of variant B, tied into Frappes Workflow module. Only in the case unforeseen problems arise, we might want to consider switching to either of variant A or variant C.

(edit: refined flowchart)