Projects:AdvPaymentMngt/Functional Documentation Matching Student Debtors

Contents 1 Payment Priorities 1.1 Objectives 1.2 Process Overview and Assumptions 1.3 Design Considerations 1.4 User Interface considerations 1.5 New User Interface 1.6 User Interface changes 1.6.1 Payment Plan Lines distribution User Interface changes 1.7 User Stories 1.7.1 Add Payment from Invoice 1.7.2 Add Payment via the "Payment In/Out" 1.7.3 Add Payment via Add Transactions at Financial Account 2 Matching Algorithm 2.1 Matching algorithm following Bank Statement import 2.1.1 Add Payment via reconciliation to Bank Statement 2.2 Issues 2.3 Future Enhancements

Payment Priorities

Objectives

The objective of this project is to allow the distribution of payments received in by an organization from a Business Partner (by example an student or any other debtor) to take into consideration a Payment Priority.

Currently, when payments are received in, the system automatically proposes to distribute the amount received to payment plan lines by due date. The oldest outstanding invoice payment schedule lines are proposed first.

The intention is to also allow the distribution algorithm for received payments to be driven by a "Payment Priority". Payment Priority will always have a higher priority than Due Date.

The logic is that all lines in a Payment Schedule will have a Due Date, but not all will necessarily have a payment priority. Also, if two lines have the same priority (first sort), then they are prioritized by date (second sort).

Process Overview and Assumptions

• The Payment Priority will be maintained in a third party system.
• The Payment Priority will be imported into Openbravo, which implies that there needs to be a database field for Payment Priority in Openbravo.
• The Payment Priority should be editable within Openbravo, which implies that there needs to be UI modifications.
• When payment is received and matched (either manually or automatically) to a Business Parter then the system will return a data set of payment plan lines for open sales invoices and sales orders for that Business Partner.
• The data set will be sorted for display purposes first by Payment Priority then by Due Date (taking into consideration that there may be no Payment Priority).
• The distribution algorithm will first distribute value to lines with a payment priority associated with them (where the line with lowest value Payment Priority gets the first distribution; Payment Priority 1 is higher priority than Payment Priority 2).
• Once complete, the distribution algorithm then starts distributing the balance of the amount received to payment plan lines by due date (current logic).

Design Considerations

It should be possible to define "payment priorities" at client level as required, by having into account below considerations:

• Payment priority is not mandatory
• The lowest priority is "null"
• The highest priority is the lowest payment priority numeric value, which means that a payment priority equal to 1 will always be higher than a payment priority equal to 2

This functional specification also affects the Dunning module.

Invoices with dunning fees are generated by the dunning module (for invoices of 'normal' bpartners). These invoices must be prioritized higher than normal invoices.

Therefore the system should be configurable so that:

• Invoices with dunning fees can be assigned the highest Payment Priority for the Client
• Normal Invoices can be assigned the Payment Priority set up as "Default" for the Client

Besides, the priority of an invoice imported from other modules (like student debtors) should be configurable (as part of the module).

The priority of invoices from the dunning module could also be configurable. This way the configuration of the Payment Priority is managed by the client admin.

User Interface considerations

As described above the system should be configurable so that:

1. Invoices with dunning fees can be assigned a default Payment Priority of 1 by example (in general the highest one)
2. Normal invoices can be assigned a default Payment Priority of 2 by example (in general the default one)
3. Sales Orders can be assigned a default Payment Priority at the Sys Admins discretion as well.

There should also be implemented the UI changes required to grids showing the distribution to payment lines, depending on payment priority.

The payment priority used will be indicated by the sort order of the data set to which that payment is being applied, at least.

New User Interface

A new table/window must be created at the application path:
"Financial Management || Receivables & Payables || Setup || Payment Priority"

This new table will contain below columns:

• Organization
• Name = text field
• Description = text field
• Active = (yes/no) field
• Priority = numeric field
• Color = text field
  by example "blue" linked to High Priority, and "green" linked to Standard Priority.
• Default = (yes/no) field

An example is shown below:

End-user should be able to:

• create as many payment priorities as needed
• set only one of them as "by default Payment Priority", which implies that every sales order and/or sales invoice created in the system but dunning ones imported from the dunning module, will get a default priority which might be changed by the end-user later on as required.

User Interface changes

A new field named "Payment Priority" must be created at the application path:

• "Sales Management || Transactions || Sales Order"

• "Sales Management || Transactions || Sales Invoice"

• Payment Priority field is not a mandatory field.
• Payment Priority field must get a value equal to the highest priority defined at client level, in case of dunning invoices created by dunning module.
• Payment Plan field must get a value equal to the default priority defined at client level, if any, in case of not dunning invoices created in the system.

A new field/column named "Payment Priority" and a new button named "Update Payment Plan" must be created at the application path:

• "Sales Management || Transactions || Sales Order >> Payment Plan tab"

• "Sales Management || Transactions || Sales Invoice >> Payment Plan tab"

Therefore each "Payment Plan" would inherit the "Payment Priority" defined at sales order/invoice level.

This new button will allow the end-user to change either the "Due Date" or the "Payment Priority" for an existing "Payment Plan Line". The button will be shown only if the payment plan is not fully paid (outstanding <> 0).

Note: same applies to Purchase Order/Purchase Invoices

Payment Plan Lines distribution User Interface changes

There should also be implemented the UI changes required to grids showing the payment distribution, depending on payment priorities as shown below:

As shown above the grid is showing two different colours one per each priority defined. End-user should know the colors he has setup for each priority, therefore he knows that the blue one placed the fist one, is the one having the higher priority.

As a summary, the payment priority used will be indicated by the sort order of the data set to which that payment is being applied and besides by the colour setup and linked to a specific payment priority.

User Stories

Add Payment from Invoice

Process remains as currently implemented. Only the distribution algorithm is modified.

In summary:

• the user opens a Sales Invoice and once it is completed, clicks on "Add Payment".
• The payment distribution window will display the current invoice the first one by default, as shown in the screen below
• The payment distribution window will display the rest (sales order/sales invoice) sorted as described above, based on payment priority (first round) and then based on due date (second round), as shown in the screen below
  
• Finally, the payment distribution window will display the rest (sales order/sales invoice) sorted by amount (higher amount first), in case of same payment priority and same due date.

Same applies to Purchase Invoices

Add Payment via the "Payment In/Out"

Process remains as currently implemented. Only the distribution algorithm is modified.

In summary:

• The user opens a "Payment In" by selecting at least a Received from BP, a Payment Method and a Deposit to Financial account.
• Then cliks on "Add Payment Details"
• User specifies whether they want to receive payment against "invoices", "orders" or "both".
• Once the user has made their selection the lower portion of the window is populated with the data set as described in the distribution logic above, see below:

Same applies to Payment Out

Add Payment via Add Transactions at Financial Account

Process remains as currently implemented. Only the distribution algorithm is modified.

In summary:

• From a financial account, the user clicks on "Add Transaction" button at "Transactions" tab.
• Once there, end user cliks on "Add Payment" button
• User specifies the "Received From" BP and whether they want to receive payment against "invoices", "orders" or "both", in case of a Payment In.
• or user specifies the "To be Paid To" BP and whether they want to enter a payment against "invoices", "orders" or "both", in case of a Payment Out.
• Once the user has made their selection the lower portion of the window is populated with the data set as described in the distribution logic above

Matching Algorithm

Matching algorithm following Bank Statement import

From Financial Account => Transactions window the user imports a bank statement. Once successfully imported the user clicks on the "Match Using Imported Bank Statement" button.
The system displays all the imported bank statement lines on the left, and any automatically matched lines on the right.
The matching logic should be customizable in the matching algorithm.
The matched lines should include matches to:

• Financial Account transactions (current behaviour)
• Open sales invoice payment plan lines (new behaviour)
• Open sales orders payment plan lines(new behaviour)
• Open credit memos payment plan lines (new behaviour).

Strong matches should already be highlighted in Dark Green and already checked as Matched.
Weak matches should be highlighted in Light Green (and not checked as matched). User reviews proposed strong matches and may accept additional weak matches. Unmatched items follow existing "find" or "add" processes.
It should be possible to "unmatch" a proposed match and then manually rematch that line using the existing "find" or "add" processes.
Once the user has completed the matching process they click on the "Reconcile" button. This then triggers the accounting events defined by the accounting workflow.

Add Payment via reconciliation to Bank Statement

Process remains as currently implemented. Only the distribution algorithm is modified.

In summary:

• From a financial account, the user clicks on "Match Using Imported Bank Statement"
• Once there, end user cliks on "Add" link as shown below
  File:Add link.png
• Once the user has made their selection the lower portion of the window is populated with the data set as described in the distribution logic above.

Issues

Please initiate a new discussion thread in the Forum for this project.

Remember that you will need to be logged in to the Openbravo Forge to do this.

All new discussion threads will be added to the Open Items list below by the Project Owner.

When it is agree in the Discussion Forum that it is closed (by the Functional Specification being updated, or the issue being deferred or rejected) then the link will be moved to Closed Items.

• Open Items:

• Closed Items:

Future Enhancements

Please describe here any enhancements to this process that could be considered for future development.