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:AdvPaymentMngt/Functional Documentation

Contents

Introduction

The intention is to develop a simplified payment workflow that

The new workflow will be developed as a commercial module known as Advanced Payables and Receivables Management. Users of the current payment workflows should be able to continue to use their existing processes without the need for reconfiguration.

This is a strategic development for Openbravo ERP that is believed to have the potential to significantly increase the speed and ease of adoption of the Openbravo solution.

Process

The new simplified payment workflow can be summarized as follows: Payment Workflow.png

General Principles

Access to the Receive Payment, Make Payment and Reconcile workflows must be controlled at a system level by user rights.

It is important that the system be able to support complete segregation of user access to these processes.

Users must be able to enter each workflow at any point in order to complete the process. For example, it must be possible to access the Receive Payment process directly from a sales invoice (or order). Conversely, a user in the Receive Payment screen should be able to find a number of invoices against which a payment can be matched.

The concept of separate payment object (currently supported by Openbravo ERP) is removed from the Advanced Payables and Receivables Management workflows. All payments are managed directly at the invoice and order level.

Accounting is configurable by Payment Method and may optionally include the use of an intermediate account.

The payment workflow supports the use of Automatic Payment Plugins (as commercial modules) to automatically generate payment documents (see "Terminology" below).

Terminology

Receivables Status
  1. Awaiting Payment
  2. Payment Received
  3. Deposited not Cleared
  4. Payment Cleared
Payables Status
  1. Payment Pending
  2. Payment Made
  3. Withdrawn not Cleared
  4. Payment Cleared

Receive-Payments 0026 Accounting-setup-2.png

Accounting

For each Financial Account (whether new or existing) the payment events that are triggered by each payment flow will be configurable to drive the accounting events. It should therefore be possible to associate multiple Payment Methods to single Financial Account (that controls the accounting events) and it should also be possible to associate a Payment Method to an Automatic Payment Plugin (a commercial module that contains the work-flow and user actions necessary to generate a Payment Document). This means that the financial account will control the accounting triggered by the Automatic Payment Plugin associated to a specific Payment Method, and the financial account will also control the accounting triggered by the reconciliation process.

Note that the following screenshot needs to be adjusted slightly as it currently shows an example of the accounting configured via the payment method (cheque). It should be changed to show the accounting being configured in the set-up of the "Chequeing Account" which is then associated to to the Cheque Payment Method. An example of the configuration of the accounting events for each payment events in both the receivables and payables workflows for the Cheque Payment Method is shown. In this case the event for Payment Received drives the posting of the received amount to the Chequeing Intermediate a/c. The act of matching that payment to the cleared amount on the Bank Statement (during the reconciliation process) then drives an automatic reversal out of the Chequeing Intermediate a/c and a posting to the Chequeing a/c.

More complex scenarios exist where two intermediate accounts are used, one for the Received Payment and another for the Deposited not Cleared. The received amount will be moved from one to the next and ultimately posted to the Chequeing a/c upon reconciliation.

Receive-Payments 0027 Accounting-setup-2.png

Below there is the final Accounting Configuration screen showing the accounts which could be used in the new payment flow:

Accounting configuration.png

Bank Statement Posting

It should also be possible to post an imported Bank Statement.

There should be a new flag named "Enable Bank Statement" at the application path, as shown in the screen above:
"Financial Management || Receivables & Payables || Transactions || Financial Account || Account >> Accounting Configuration"
If the flag "Enable Bank Statement" is selected, two new fields must be shown for the:

Above accounts will be used for the Bank Statement Posting.
Bank transitory account should match the "Cleared" payment accounts (payment in/out) in order to get accounting balanced.

Receive Payment

Receive-Payments 0000 Title.png

Receive-Payments 0001 Invoice-Grid.png
Image RP0001: The invoice selection screen showing summary information relating to invoices.

Receive-Payments 0002 Invoice-Header.png
Image RP0002: The invoice header view for the selected invoice.

Receive-Payments 0003 Expected-Payments.png
Image RP0003: From the invoice header it is possible to select the Payment Plan tab in order to view all scheduled payments:

Receive-Payments 0004 Payment-History.png
Image RP0004: Clicking on a specific scheduled payment shows the detail of the payments received against it.

Receive-Payments 0005 Invoice-Header-copy.png
Image RP0005: Returning to the invoice header the user can click on Add Payment in order to receive a payment against this invoice.

Receive-Payments 0006 Add-Payments-Pop.png
Image RP0006: On this screen it is possible to enter the the payment against the invoice:

The system should automatically allocate the Amount Received against the oldest scheduled payments, however this is editable.

Where the amount can not be matched exactly to a number of scheduled payments then there may be a difference. This is managed using the options below the grid which are dynamically displayed depending on whether there is an under or over payment. This first scenario deals with the case of an underpayment.

There is a difference of:

Note: The definition of "insignificant" should be configurable at a system level and the rule displayed on the screen. For example, if the difference is in the range of (-0.01 to +0.01) then the system should automatically offer to "Write off the difference". Amounts outside of this range must be allocated against a settlement line or held on the Business Partners account as an unmatched payment.

Comment: The user may choose not to allocate the amount to any existing document or leave a portion of the payment unallocated. This situation is described in the overpayment example below.

Once the user is happy with the allocation of the payment they click on "Process Payment".

Receive-Payments 0007 Processing2.png
Image RP0007: The user confirms that they wish to process the payment.

Receive-Payments 0008 Invoice-Header-copy-3.png
Image RP0008: The user is returned to the Invoice Header and is informed that the payment has been successfully processed.

Receive-Payments 0009 Expected-Payments-copy.png
Image RP0009: Clicking on the Payment Plan tab confirms that the Payment Plan has been updated correctly.

Receive-Payments 0010 Expected-Payments-copy-2.png
Image RP0010: The user can click on any of the payment lines in order to see the detail of the payment received.

Receive-Payments 0011 Payment-History-copy-2.png
Image RP0011: This activates the Payment Detail tab.

Receive-Payments 0012 Payment-Details.png
Image RP0012: The details of the payment matched against this scheduled payment are shown in read only mode. The user can click on the Payment Document Number link in order to see the detail of the associated payment document.

Receive-Payments 0013 Payments-Left-Nav.png
Image RP0013: The detail of the Payment Document are viewable in read only mode.

If the user wishes to change the scheduled payments against which this payment was matched then they can click on "Reactivate".

The user can click on the Lines tab in order to view how this payment was allocated.

Receive-Payments 0014 Payments-Left-Nav-Lines.png
Image RP0014: This shows the scheduled payments against which this payment was allocated.

Receive-Payments 0015 Payments-Left-Nav-copy.png
Image RP0015: The user returns to the header of the payment document and clicks on the "New" icon in order to enter a new payment.

Receive-Payments 0016 Payment-New.png
Image RP0016: As previously the user enters the detail of the payment received and clicks on Select Sales Orders or Sales Invoices in order to match the payment against the selected documents.

Receive-Payments 0017 Payment-select-invoices-POP.png
Image RP0017: In this example the user decides to change the proposed matching, and the result is an unallocated amount of 4 EUR.

In this case the area below the grid dynamically prompts to manage the overpayment.

There is a difference of:

Note: The definition of "insignificant" should be configurable at a system level and the rule displayed on the screen. For example, if the difference is in the range of (-0.10 to +0.01) then the system should automatically offer to "Write off the difference". Amounts outside of this range must be allocated against a settlement line or held on the Business Partners account as an unmatched payment.

The user clicks on "OK" to accept the allocation of the payment.

Receive-Payments 0018 Payment-New-copy-2.png
Image RP0018: The user is given the detail of the payment. Assuming the user does not want to make any more changes the user then clicks on "Process Payment".

Receive-Payments 0019 Processing2-copy.png
Image RP0019: The user confirms the action by clicking on "OK".

Receive-Payments 0020 Payment-New-copy.png
Image RP0020: The user is provided with a summary view of the payment entered and can click on the Lines tab.

Receive-Payments 0021 Lines.png
Image RP0021:The details of the allocation of the payment to the payment plan lines (the scheduled payments) are shown, including the unallocated payment (which is not yet matched to a scheduled payment).

Receive-Payments 0022 Payment-New-copy-3.png
Image RP0022: Returning to the Payment header the user can optionally click on "Mark as Deposited" in order to change the status of the payment to "Deposited not Cleared". This could be an optional manual step for payment methods where the deposit is instantaneous (such as an electronic transaction). Alternatively the payment method could be configured so that the act of receiving payment automatically sets the status to "Deposited not cleared"


Make Payment

Make-Payment 0000 Title.png

Make-Payment 0001 start.png
Image MP0001: The user starts the payment process by first generating a payment proposal for a selected payment method based on a number of criteria:

Once the user has entered the selection criteria they can then click on the Select Expected Payments button.

Make-Payment 0002 make-proposal-1.png
Image MP0002: The system returns a proposal of all scheduled payments from all invoices meeting the payment proposal criteria.

There are a number of secondary filters that the user can use to review the proposal:

The grid contains all the proposed payments:

Note: The definition of "insignificant" should be configurable at a system level and the rule displayed on the screen. For example, if the difference is in the range of (-0.01 to +0.01) then the system should only allow an overpayment of +0.01 to allow for cases where 10.00 cash is paid to settle a 9.99 value. Conversely an underpayment of -0.01 will also be considered as fully settled using this rule. For insignificant values the system will automatically offer to "Write off the difference".

Below the grid the total value of the proposed payment is displayed.

Information about the expected balance on the financial account being used is also displayed (as some users have financial accounts that are not allowed to go overdrawn). The user can then manually check that the proposed payment will not take the account overdrawn.

Security Considerations: There are two scenarios where a user may be granted rights to edit the payment proposal:

  1. to exclude a proposed payment from the payment proposal
  2. to adjust the proposed payment amount (the user may wish to reduce the proposed amount for some reason).

Access to make these edits will be configurable via user rights. For example, it should be possible to configure a user's rights so that they have no rights no remove payments from the proposal or edit the payment value.

Make-Payment 0003 make-proposal.png
Image MP0003: In this screen the user has deselected two lines. This will remove the line from this payment proposal.

Please note that this does not permanently block the line for payment; it will be proposed in the next payment proposal for this payment method.

The user has also modified the payment amounts:



Make-Payment 0004 selected-copy.png
Image MP0004: The user is shown a warning about the existence of underpayments and overpayments.

Once the user is happy with the selection and values proposed they click on the "OK" button.

Make-Payment 0005 form.png
Image MP0005: The user is provided with the header screen for the payment proposal they have created. If they wish to review the detail the user can click on the "Lines" tab.

Make-Payment 0006 lines.png
Image MP0006: This shows the lines included in the payment proposal (with the Payment status "Unpaid". If the user is comfortable with the detail of the proposal then they can return to the header to generate the payment.

Make-Payment 0007 form.png
Image MP0007: The user can click on "Generate Payments". Please note that it should be possible for one user to generate the proposal and for another user to review the proposal and actually generate the payment. In some organizations this is an important segregation of duties reducing the opportunity for fraud.

Make-Payment 0008 Process.png
Image MP0008: If the user is happy to proceed they can click on "OK" to trigger the automatic payment plugin.

Note:



Make-Payment 0009 form-copy.png
Image MP0009: The user receives confirmation that the payment has been successfully generated. This event should also drive the payment status for all lines that were paid.

Make-Payment 0010 lines-copy.png
Image MP0010: The detail of all lines paid by the automatic payment plugin is shown. In this case the cheque numbers are shown in the right hand column. Please note that the payment workflow MUST capture the identification number of the payment document (cheque number, electronic instruction ID, etc) as this is the reference that the bank will use on the bank statement (for each transaction cleared) and is therefore the reference that will be used in the reconciliation process. Please also do not confuse the Payment Proposal ID with the Payment Document ID (as one payment proposal may generate multiple payment documents).

Transactions

Transactions 0000 Title-Slide.png

Transactions 0001 Accounts-header.png
Image TR0001: The user can select a Financial Account to view. In this example the user selects the Checkings account by double-clicking on it.

Transactions 0002 Transactions.png
Image TR0002: This provides the user with a view of the transactions associated with this financial account.

The user can add a payment line to the account by clicking on the "Add Payment" button.

Transactions 0003 Layer-Comp-1.png
Image TR0003: On this screen the user can add a payment.

In this example the user wants to add a Bank Fee to the Financial Account, as the bank fee is shown on the bank statement. The user therefore clicks on the "Payment Type" and selects "Bank Fee" from the drop down list.

Transactions 0004 Layer-Comp-2.png
Image TR0004: For the Payment Type "Bank Fees" the grid is dropped from the screen as it is not required. The business partner is automatically populated with the bank associated with this bank account. The payment method is automatically populated with "Bank Transfer" (as the bank has already made this charge; it is shown on the bank statement).

The user enters the amount of the bank fee in the "Actual Payment" field, selects the "Payment Date" that the bank fee was charged, and enters a "Description" of the transaction. The user then clicks on "OK".

Transactions 0005 Added-transaction.png
Image TR0005: The user is returned to the transactions screen where they can see the bank fee line just added. Note that this transaction is also marked as "Cleared" (the check box in the right hand column is automatically completed as "true") because the amount is matched to a transaction shown on the bank statement. This results in a credit to the Financial Account (in this example 10100 - Checking).

Transactions 0006 Clear.png
Image TR0006: While the user is manually reviewing the bank statement they notice that the first two lines are shown (and therefore have been cleared by the bank). The user therefore clicks on the "Cleared" check box for each item. This results in the displayed count of items to match being automatically reduced (in this example from 6 to 4).

In this example the user wants to reconcile the financial account to the bank statement, so they click on the "Reconcile" button.

Manual Reconciliation from a paper Bank Statement

Transactions 0007 ManMatch1.png
Image TR0007: Here the user can manually reconcile other items shown on the bank statement and starts by manually entering the "End Balance Bank Statement" from the bank statement.

Transactions 0008 ManMatch3.png
Image TR0008: The user establishes that all the transactions shown in the financial account appear on the bank statement. A tick in the "Clear All" check box would have done the same: this marks all lines as cleared.

The "read only"values below the grid are automatically updated.

The user then clicks on the "Reconcile" button.

Transactions 0009 Reconciling-copy.png
Image TR0009: The user is invited to confirm the action.

Transactions 0010 Discrepancy.png
Image TR0010: At this point the system informs the user that there is a difference between the balance on the financial account and the end balance of the statement.

The user clicks on "Add Payment".

Transactions 0011 Add-Payment.png
Image TR0011: The user has established that the difference is due to a payment received from Mafalda that has not been matched to an invoice. The user enters the details of the payment, but is unable to match the amount to a particular invoice so simply accepts the amount as a debit to the bank account and a credit against the Business Partner's account. The user is presented with guidance on the screen about matching the payment at a later date. The user clicks on "OK".

Transactions 0012 Reconcile-4.png
Image TR0012: In the reconciliation screen the transaction for Mafalda is automatically shown as "cleared". The user clicks on "Reconcile" to complete the reconciliatation.

Transactions 0013 Reconciling.png
Image TR0013: The user is invited to confirm the action. The workflow associated with this financial account (please see Open Issues below) triggers a posting from the intermediate account to the financial account for each of the reconciled items (with the exception of the bank fees as that has already been posted directly into the financial account.

Transactions 0014 Grid-cleared.png
Image TR0014: The user receives confirmation that the reconciliation has been completed successfully. Please note that the "Starting Balance" and "Present Balance" have been updated to reflect the reconciled balance.

Automatic Reconciliation using Imported Bank Statement

Transactions 0015 1-month-later.png
Image TR0015: The following month the user again wants to reconcile the financial account, but this time using an imported bank statement.

The user clicks on "Import Bank Statement".

Transactions 0016 Import.png
Image TR0016: The user is invited to browse to the location of the bank statement to be imported. Note: For each user the system should automatically offer the last location that the user browsed to in this window.

The user clicks on "Save" to import the bank statement.

Transactions 0017 1-month-later-copy.png
Image TR0017: The "Bank Statement Date" is automatically updated from the imported bank statement. It also shows the number of unmatched items on the bank statement.

The user wants to confirm that the bank statement has been imported, so clicks on the "Imported Bank Statements" tab.

Transactions 0018 Statements-tab.png
Image TR0018: The user is presented with a list of previously imported bank statements and whether they have been reconciled or not.



Transactions 0019 1-month-later-copy-2.png

The user might want to post the imported bank statement, so clicks on the "Post" process button. The system will show a posting such as:

Negative Bank Statement:
Let's imagine a bank statement with a single line for an amount of -100,00, that would mean a payment OUT: (Debit Amount = Payment OUT= Paid)

Bank Statement Posting:
Bank Transitory account (Debit)
Bank Asset account (Credit)

Upon bank statement line clearance posting:
Vendor liabilities (Debit)
Bank Transitory account (Credit)

Therefore the complete set of posting will look like:

Invoice posting:
Expense (Debit)
Vendor liabilities (Credit)

Bank Statement Posting:
Bank Transitory account (Debit)
Bank Asset account (Credit)

Bank statement line clearance posting:
Vendor liabilities (Debit)
Bank Transitory account (Credit)

Positive Bank Statement:
Let's imagine a bank statement with a single line for an amount of +100,00, that would mean a payment IN: (Credit Amount = Payment IN = Received)

Bank Statement Posting:
Bank Asset account (Debit)
Bank Transitory account (Credit)

Upon bank statement line clearance posting:
Bank Transitory account (Debit)
Customer (Credit)

Therefore the complete set of posting will look like:

Invoice posting:
Customer (Debit)
Income (Credit)

Bank Statement Posting:
Bank Asset account (Debit)
Bank Transitory account (Credit)

Bank statement line clearance posting:
Bank Transitory account (Debit)
Customer (Credit)


Image TR0019: The user returns to the financial account header and clicks on "Match using imported Bank Statement".

Transactions 0020 Matching-New.png
Image TR0020: The system has found two matches:

Note: The logic of matching (what constitutes a strong match vs a weak match) needs to be configured as part of the setup of the import of the bank statement file.

The system automatically places a tick in the check box for all matched lines. If the user does not agree with the match then they can unclick the checkbox.

The user is happy with the proposed match and now wants to find a match for the transaction shown on the bank statement as 100 EUR paid to Gelati Gianni. This is a payment generated by a payment instruction created by the system, so it should be able to find the payment in the system. The user therefore clicks on "find"...

Transactions 0021 Matching-Gianni.png
Image TR0021: ...which opens up a search screen (using the new search mechanism).

Transactions 0022 Matching-Gianni-2.png
Image TR0022: The user enters a search for "Gianni" and the screen is automatically filtered on the results. The user can choose a match by clicking on the matching line and then clicks on "OK".

Transactions 0023 Matching-New-copy.png
Image TR0023: The user is returned to the matching screen which has been updated to show the new match. This time the user wants to match the payment received from Fritz Finkelstein. This is a payment that we have received directly into the bank account so its appearance on the bank statement is the first we know about it. We therefore need to add the receipt of the payment to the financial account. The user therefore clicks on "add"...

Transactions 0024 Add-Payment-on-fly.png
Image TR0024: ...which opens up the "Add a Payment" screen. Where the system is able to match the name to a business partner then the business partner field is automatically filled. If not the user simply selects the business partner. There is an expected payment for 150 EUR for an order and the actual payment amount is automatically added to the payment line for the order. The user makes a mental note to have the Sales Order number added to the list of auto-matching criteria.

The user is happy with the matching of the payment to this order and clicks on "OK".

Transactions 0025 Matching-New-copy-2.png
Image TR0025: The user is returned to the matching screen which has been updated to reflect the match just made. The user decides not to add the payment received from Miss X at this point and clicks on "Save".

Transactions 0026 backtogrid.png
Image TR0026: The user is returned to the transaction screen where they decide to reconcile the account to the imported statement by clicking the Reconcile button.

Transactions 0027 Reconciliation-2nd-round.png
Image TR0027: The reconciliation screens appears.

Note: In this situation the reconciliation screen should only show transactions up to the date of the statement date. For this, the filter check box "Hide transactions after the statements date" could be selected.

The user clicks on "Reconcile"...

Transactions 0028 Renconcile-pop.png
Image TR0028: ...and is invited to confirm the action.

Transactions 0029 discrep.png
Image TR0029: The user is presented with a warning that there are unreconciled items.

Note: the "Create Adjustment" button is to manage situations where the bank has made an error and the user wants to adjust the imported bank statement to remove the error. Any adjustments must be stored against the bank statement and the adjusting value and description displayed on the reconciliation statement.

In this case the user decides to leave the transaction as unmatched and clicks on the "Leave as Unmatched" button.

Transactions 0030 Reconciled.png
Image TR0030: The user is returned to the transactions screen where they receive confirmation that the process has successfully completed.

Transactions 0031 Statements-update.png
Image TR0031: Clicking in the "Imported Bank Statement" tab the user can see that the bank statement recently used has been marked with the date of the reconciliation. Note:



Transactions 0032 Statements-Details.png
Image TR0032: Clicking on the Statement Details tab the user can see the detail of the imported statement.

Transactions 0033 Grid.png
Image TR0033: Returning to the Transactions screen the user sees the unreconciled transactions. The message "8 items to match" refers to all unmatched items for today in the grid. The user wants to view the reconciliation summary and clicks on the "Reconciliation" tab.

Transactions 0034 Reconciliations.png
Image TR0034: This opens a summary view of the reconciliation. This shows:

The user decides to print the most recent reconciliation statement so clicks on the most recent line.

Transactions 0035 Reconciliations-Form.png
Image TR0035: This opens a summary screen. The user clicks on one of the "Publish" options...



Transactions 0036 Report.png
Image TR0036: ...and the Reconciliation Report is generated. In this case it is the "Publish Detail" option.



Transactions 0037 Report-Summary.png
Image TR0037: The "Publish Summary" does not show the line detail.

Issues

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

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.

Enhancements

Payment Priorities

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.

For additonal information, please take a look at the "Payment Priorities" Project in the Forge

Reversal Documents

A Sales Invoice Payment generates a "Payment In" and a Purchase Invoice Payment generates a "Payment Out", therefore any "Reversal Invoice" such as an "AP Credit Memo" or a "Storno Purchase Invoice" must behave opposite:

To get that any new document type behaves as a "Reversal" document in the Advanced Payment Management functionality, a new field has been created at the application path:
"Financial Management || Accounting || Setup || Document Type || Document Definition "

This new field is named "Reversal" and it can be properly setup at Document Type level, as shown in the screens below:

Reversal APCreditMemo.png

Reversal Storno Sales.png

Future Enhancements

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

This page has been accessed 9,377 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.