View source | View content page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Show collection (0 pages)
Collections help

Search

Projects:Editable Payment Plan/Technical Documentation

Contents

Editable Payment Plan

Overview

In order to cause the lowest impact to existing modules and pieces of functionality in the erp, the information about the actual payment plan will continue to be stored in the same database table: fin_payment_schedule.

New tables will be created to store the information about the archived payment plan.

When creating the new payment plan, both tables will be filled in: fin_payment_schemdule and new one for the archived payment plan. If the plan is modified, the fin_payment_schedule is modified. A third table will link, when payments are processed, the payment schedule detail elements with the archived payment plan.


Concepts

Data Model

Data model needs to be enhanced with two new tables:


FIN_ORIG_PAYMENT_SCHEDULE
Column Name Type Description
Fin_Orig_Payment_Schedule_Id ID ID
Ad_Client_ID TableDir Client
Ad_Org_ID TableDir Organization
isActive yesno Active
created date audit
createdBy Table (Ad_User_ID) audit
updated date audit
updatedBy Table (Ad_User_ID) audit
c_Invoice_ID TableDir invoice
c_Order_ID TableDir order
dueDate date date planned for this payment plan line
fin_PaymentMethod_ID TableDir payment method of the payment plan
c_Currency_ID TableDir currency
amount Amount total amount of the payment plan line
paidAmount Amount amount that has been paid for this payment plan line
outstandingAmount Amount amount pending to be paid (outstandingAmount + pendingAmount = amount)
fin_Payment_Priority_ID TableDir priority of this payment plan line
update_Payment_Plan yes is it used??


FIN_ORIG_PAYM_SCHEDDETAIL
Column Name Type Description
Fin_Orig_Paym_SchedDetail_Id ID ID
Ad_Client_ID TableDir Client
Ad_Org_ID TableDir Organization
isActive yesno Active
created date audit
createdBy Table (Ad_User_ID) audit
updated date audit
updatedBy Table (Ad_User_ID) audit
fin_Orig_Payment_Schedule_id TableDir archived payment plan line paid (partial or totally) with a payment
fin_Payment_ScheduleDetail_ID TableDir payment plan line paid (partial or totally) with a payment
amount Amount amount of a payment used to pay the referenced payment plan line
writeOffAmount Amount written off amount of a payment used to pay the referenced payment plan line
isCanceled yesno true in case the payment plan line is fully paid

Creation of a Payment Plan

Current Flow

Right now, when completing an invoice, the payment plan is created, creating new lines in the fin_Payment_Schedule table.

To Develop

In order to keep the archived payment plan information, at this moment, in the fin_Orig_Payment_Schedule table, it must be saved the same information that is nowadays saved in the fin_Payment_Schedule table.

Furthermore, if the invoice is reactivated, the same way that fin_Payment_Schedule table content is deleted, same will happen with the rows in the fin_Orig_Payment_Schedule table.

Let's have a look to the whole process through an example through all this document:

Example. Step 1

Let's take as an example, an invoice with grand total amount of 200, with a payment plan of two lines of 100 each:

EditablePaymentPlanExampleI.png

All the information about the payment plan is also stored in the fin_Orig_Payment_Schedule table; apart from the fin_Payment_Schedule, as it is doing as of now.

Modification of a Payment Plan

To Develop

If user modifies a payment plan, the new payment plan will be stored in fin_Payment_Schedule table, overwriting previous payment plan information. Not all payment plan lines are suitable to be modified:

When a payment plan is modified, all the not paid payment plan lines are shown (all of them with outstanding amount not 0). User will be able to modify, for each line, it's amount, and due date. Also delete existing lines, and create new ones.

There exists two different options: modifying the archived payment plan, or creating a new version for it:

In any case, when modifying a payment plan, the sum of amounts before modifying, and after modifying, must be the same.

Let's have a look to all this stuff with our example:

Example. Step 2

Now, a new version of the payment plan is is saved, so the two lines of 100 each are transformed into two lines: one of amount 25, and other one of 175.

EditablePaymentPlanExampleII.png

In case the archived payment plan is modified, the difference will be that, only in this case, the archived payment plan information is also modified.

EditablePaymentPlanExampleIIPrima.png

Payment completed against Payment Plan line/s

Full Payment

Current Flow

If a payment do totally pay a payment plan line (this is: a payment detail is linked to the payment plan line and the amount of the payment detail is equals to the amount of the payment plan line), system updates the fin_Payment_Schedule table to set new values for

only in case there exists a write-off amount, fin_Payment_ScheduleDetail row is modified to set new values for

To Develop

In this case, some code must be added when completing the payment (bellow this line) to reflect this payment in the archived payment plan information.

In the fin_Orig_Payment_Schedule table, there will already exist some rows, created when completing the invoice (or when modifying the archived payment plan). The code to be developed, will modify these rows to set following values:

Furthermore, one row will have to be created in fin_Orig_Paym_SchedDetail table with these values:

Example. Step 3

Let's now, before modifying the payment plan, think about a total payment for a payment plan line:

EditablePaymentPlanExampleIIITot.png

A new element in fin_Orig_Paym_SchedDetail table will link the fin_Payment_ScheduleDetail row and the fin_Orig_Payment_Schedule one. In this case all the amounts are 100, so no other adjustment is required. Let's see now what happens in case the payment is not complete, but partial.

Partial Payment

Current Flow

In addition to the actions taken for a full payment, some other actions are taken in case the payment amount is lower that the payment plan amount, and users wants the difference, not to be written off, but to still as outstanding amount for the payment plan line.

In this case, a new row is added to the fin_Payment_ScheduleDetail table, as a copy of the line associated to the payment plan line that has been partially paid, with the only difference that the amount will be the outstanding amount of the payment plan line.

To Develop

In case a partial payment takes place, the piece of code that is going to be developed bellow this line, and will create the entries in the fin_Orig_Paym_SchedDetail table, will need to do some calculations for each of the fin_Payment_ScheduleDetail entries processed when completing a payment:

This process will continue until all the amount in the fin_Payment_ScheduleDetail entries is distributed through the archived payment plan, through the fin_Orig_Paym_SchedDetail entries.

Please notice that both tables are slightly different:


Let's continue with our example.

Example. Step 4

Let's think now that a new version of the payment plan has been created. Now let's create a Payment for 75:


EditablePaymentPlanExampleIII.png

In this case, the 75 payment detail needs to be detailed in the payment plan detail table, as 25 do pay the 25 payment plan line, and the other 50 do pay part of the 100 payment plan line.

Furthermore, each of these payment plan detail elements (25 and 50) do have it's corresponding archived payment plan detail entries: both of them related to the first 100 archived payment plan element.

Example. Step 5

The last step of the example completes another payment for 100:

EditablePaymentPlanExampleIV.png

In this case, the 100 payment do provoke the split of the 125 payment plan detail element, into one of 100 and other one of 25. The one of 100 is linked to TWO records in the archived payment plan detail elements: one for 25 that paids the last 25 pending of the first 100 archived payment plan elements. The rest (75) partially paids the second 100 archived payment plan element.

Payment reactivation

If a payment is reactivated, same way payment schedule detail lines are deleted, when possible, original payment plan detail lines must be also deleted.

Development Phases and Status

Phase I

While Pick and Execute development is ready, these are the steps that can be implemented:

Id Requirement Importance Status
1.1 Tables Creation Must have Done
1.2 Application Dictionary Elements Must have Done
1.3 Archived Payment Plan table population when processing the invoice Must have Done
1.4 Archived Payment Plan table delete when reactivating the invoice Must have Done
1.5 Dummy Payment Plan modification process (new version or archived payment plan modification) Must have Done
1.6 Process to be launched when completing a payment: update payment monitor information, populate the original payment plan details table Must have Done
1.7 Process to be launched when reactivating a payment: update payment monitor information, delete the original payment plan details table rows Must have Done
1.8 Payment monitor modifications Must have Done
1.9 Module-script development Must have Done

Phase II

Once Pick and Execute development is ready, these are the steps that will be implemented:

Id Requirement Importance Status
2.1 Pick And Execute AD elements Must have Done
2.2 Validation of expected amounts Must have Done
2.3 Execute function development Must have Done
2.4 Modify Original Payment Plan implementation Must have Done

Retrieved from "http://wiki.openbravo.com/wiki/Projects:Editable_Payment_Plan/Technical_Documentation"

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