View source | View content page | Page history | Printable version   

Projects:AdvPaymentMngt/Functional Documentation Matching Student Debtors

Contents

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

Design Considerations

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

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:

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:

An example is shown below:

Relation view of Payment Priority window
Edition view of Payment Priority window

End-user should be able to:

User Interface changes

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

New field in Sales Order tab
New field in Sales Invoice tab

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

New field in Sales Order - Payment Plan tab
New field in 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:

Add payment.png

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:

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:

Add payment PaymentIn.png

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:


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:

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:

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.


Future Enhancements

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

Retrieved from "http://wiki.openbravo.com/wiki/Projects:AdvPaymentMngt/Functional_Documentation_Matching_Student_Debtors"

This page has been accessed 2,392 times. This page was last modified on 8 June 2012, at 05:26. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.