Projects/AdvPaymentMngt/Functional Documentation

From InfiniteERP Wiki
Jump to: navigation, search

Introduction

The intention is to develop a simplified payment workflow that

  • is natural to use
  • is flexible enough to be configured to for use in different country and vertical markets
  • supports segregation of duties between the receivables process and the payables process.

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

  • Payment: A payment event. The actual event of either making or receiving a payment.
  • Payment Transaction: The accounting event driven by a payment event.
  • Payment Document: A legal document authorizing a payment transaction. For example a cheque or an electronic file containing an instruction to a bank to make a payment. The Payment Document ID is the ID of the actual document or instruction (e.g., the cheque number).
  • Payment Plan: The list of Scheduled Payments expected against a particular invoice. If an invoice has only one Due Date then there will be only one scheduled payment expected in the Payment Plan. If there are multiple due dates associated with an invoice then there will be multiple scheduled payment events in the Payment Plan associated with that invoice.
  • Scheduled Payment: An event in the Payment Plan defined by its amount and Due Date. The sum of all Scheduled Payments in the Payment Plan must add up to the gross value of the invoice.
  • Payment Proposal: A mechanism by which a user can make a payment by selecting scheduled payment events for a particular payment method by due date. The system "proposes" what should be paid based on the selection criteria provided by the user.
  • Payment Method: What is currently referred to as Form of Payment in Openbravo. It is the method by which payment is expected to be made or received. Please note that the Payment Method
    • Must have a currency associated with it. A single Payment Method works with a single currency.
    • Must have a Financial Account associated with it.
    • May have an Automatic Payment Plugin (see below) associated with it.
    • The list of payment methods supported will be extensible to support the following payment methods:
      • Cash
      • Credit Card
      • PayPal
      • Cheque (Requires Cheque Register showing Cheque #, Payee, Amount, Status, etc)
      • Direct Debit
      • Standing Order
      • Bank Transfer
      • Note Payable
  • Automatic Payment Plugin: A module that contains the workflow and user actions necessary to generate a Payment Document in local format. Examples might include modules for "US Check Printing", "Finnish Domestic BACS Payment", etc.
  • Automatic Reconciliation Plugin: A module that contains the matching algorithms and user actions necessary to import an electronic bank statement and match the contents to transactions in Openbravo during the bank reconciliation workflow.
  • Open Invoice: An invoice that has not received full settlement. It may have been partially paid, but remains open until payment has been received in full.
  • Closed Invoice: An invoice that has been fully settled.
  • Financial Account: An account used to hold cash or near cash. The currency of the financial account is configurable (and once defined can not be changed). Payment events that use a financial account will automatically default to the currency of that financial account. Financial accounts in foreign currency must account in the currency of the schema to which they are associated using the exchange rate ruling at the transaction date. The balance of the account must be maintained in both the currency of the associated schema and the selected currency of the financial account. It should be possible to see the balance of a foreign currency account in the schema currency as at a selected date (using the exchange rate ruling at that date) and any exchange rate gain or loss displayed.
  • Intermediate Account: A system managed account associated with a Financial Account.
    • It must have the same currency as the Financial Account it is associated with.
    • Whether an Intermediate Account is used is configured in the accounting associated with each Payment Method.
    • In the example below, the "Cheque" payment method has an Intermediate Account associated with the "Receive Payment" event. During the reconciliation of a Financial Account that has an intermediate account associated to it, the system should automatically display the contents of both the Financial Account and its associated Intermediate Account for reconciliation. The act (either manual or automatic) of matching items in the bank statement to items in the Intermediate Account should automatically trigger a movement from the Intermediate Account to its associated Financial Account. For more information on this see the section on reconciliation below.
  • Approval Status: Whether an invoice is approved for payment or not. Can be either "On Hold" or "Approved". This will be configurable at the Business Partner level (as a default), but will also be editable at the invoice level and at the Payment Plan line level. No payment will be included in the Payment Proposal unless it has an "Approved" status.
  • Payment Status: For each Payment Method the payment events in the payment flow will drive the payment status.
    • The terminology used in the receivables and payables workflows differs slightly. Each side (Receivables Status and Payables Status) has 4 options (so 8 in total) with which you can configure the accounting process by Payment Method.
    • This means that there should be complete control (and visibility) by Payment Method of the accounting that is taking place (for example, whether an intermediate account is used and what event causes the reversal out of the intermediate account).
    • The configurable options are:
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
    • In both cases the "Payment Cleared" status will be driven by the Reconciliation Process (i.e, marking items as cleared).
    • The mapping of the payment status to the payment events in both the receivables and payables workflows is shown in the following image:

800px

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.

800px

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

800px

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:

  • Bank Asset Account
  • Bank Transitory Account

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

800px

800px
Image RP0001: The invoice selection screen showing summary information relating to invoices.

  • Due Date: The Due Date of the oldest scheduled payment. Also the default sort order of this screen.
  • Invoice: The invoice number.
  • Business Partner: The Business Partner associated with the invoice.
  • Total Invoiced: The total gross amount of the invoice.
  • Received: Total amount received against the invoice.
  • Pending: Total outstanding against the invoice.
  • Overdue: The number of days overdue of the oldest scheduled payment.
  • Overdue Amount: The sum of all overdue scheduled payments.

800px
Image RP0002: The invoice header view for the selected invoice.

800px
Image RP0003: From the invoice header it is possible to select the Payment Plan tab in order to view all scheduled payments:

  • Due Date: The Due Date of the oldest scheduled payment. Also the default sort order of this screen.
  • Invoice: The invoice number.
  • Payment Method: The method by which payment is expected.
  • Expected: The gross amount of the scheduled payment.
  • Received: Total amount received against the scheduled payment.
  • Outstanding: The gross amount outstanding against the scheduled payment.
  • Last Payment Date: The date of the last payment received against this scheduled payment.
  • Number of payments: The number of payments received against each scheduled payment.
  • Currency: The currency of the scheduled payment.

800px
Image RP0004: Clicking on a specific scheduled payment shows the detail of the payments received against it.

  • Date Received: The date the payment was received (driven by the Receive Payment event).
  • Payment Method: The method used to receive payment.
  • Amount: The amount received.
  • Currency: The currency of the amount received.
  • Payment: The payment document number associated with the payment. This is the cheque number, the number of the cash slip from the cash book, etc.

800px
Image RP0005: Returning to the invoice header the user can click on Add Payment in order to receive a payment against this invoice.

800px
Image RP0006: On this screen it is possible to enter the the payment against the invoice:

  • Payment Document Number: The payment document number associated with the payment. This is the cheque number, the number of the cash slip from the cash book, etc.
  • Received From: The business partner from which the payment is received. Read only as inherited from the invoice document.
  • Payment Method: The method by which payment was actually received. Selectable.
  • Deposit to: The account against which payment should be received.
  • Currency: The currency of the actual payment. Read only as it is taken from the configuration of the financial account.
  • Expected Payment: The sum of all payments due (where the Due Date of the Scheduled Payment is less than or equal to the payment date).
  • Actual Payment: The amount received in the currency it was received. Note: For payment received in a foreign currency there should also be a view of the value of the payment received in the currency of the schema.
  • Payment Date: The date the payment was received. Should default to the system date.
  • Selection criteria for filtering of documents to display (default is no filters):
    • Date date from
    • Due Date to
    • Document type
  • Grid (default sorting on Due Date of scheduled payment):
    • Sales Order Nr: The number of the sales order.
    • Sales Invoice Nr: The number of the sales invoice and the number of the scheduled payment in the Payment List. "2/3" means the second payment of three scheduled payments.
    • Due Date: The due date of the scheduled payment.
    • Invoiced Amount: The total gross amount of the invoice.
    • Expected Amount: The amount of each scheduled payment.
    • Payment: The amount allocated to each scheduled payment from the total received.

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:

  • Leave this as an underpayment. The amount received leaves a significant balance received for a scheduled payment and that payment needs to be received in the future.
  • Write of the difference. The amount received leaves an insignificant difference that should be written off as it is not worth collecting it.

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".

800px
Image RP0007: The user confirms that they wish to process the payment.

800px
Image RP0008: The user is returned to the Invoice Header and is informed that the payment has been successfully processed.

800px
Image RP0009: Clicking on the Payment Plan tab confirms that the Payment Plan has been updated correctly.

800px
Image RP0010: The user can click on any of the payment lines in order to see the detail of the payment received.

800px
Image RP0011: This activates the Payment Detail tab.

800px
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.

800px
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.

800px
Image RP0014: This shows the scheduled payments against which this payment was allocated.

800px
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.

800px
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.

800px
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:

  • Leave the credit to be used later. This is to support cases where you have received payment, but you do not yet have an order or an invoice against which to match it (for example you have insisted on a prepayment before you will accept an order). This is held as an unallocated payment against the Business Partners account. When a Sales Order or Invoice is subsequently entered the user should be alerted to the fact that there is an unallocated payment and invited to match that unallocated payment against the document they are entering.
  • Refund amount to customer. If this option is selected then the amount will be proposed in the next payment proposal using the payment method associated with the Business Partner account. Please see the section describing the process to Make Payment.
  • Write off difference. The amount received leaves an insignificant difference that should be written off as it is not worth collecting it.

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.

800px
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".

800px
Image RP0019: The user confirms the action by clicking on "OK".

800px
Image RP0020: The user is provided with a summary view of the payment entered and can click on the Lines tab.

800px
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).

800px
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

800px

800px
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:

  • Proposal Document Nr: The number of the payment proposal document taken from a configurable document series.
  • Description: A free form text field allowing the user to add a comment relating to the payment proposal.
  • To be paid to: If the payment is to a particular business partner then they can be selected from a drop down list here. Most commonly this would be left blank (select all).
  • Payment Method: Drop down selector for the payment method. This is MANDATORY for this screen.
  • Take from: The financial account from which the payment will be made.
  • Currency: The currency in which the payment is to be made. The currency should be taken from the financial account used and is read only.
  • Expected balance after payment of the above: Information about the expected balance on the financial account being used after payment.
  • Due Date: The due date of the payments to be selected. Could be a date in the future (for example if you need to trigger a payment that needs to be received by your supplier in 3 days time). Please note that there is an error in the graphic as this field is missing.
  • Payment Date: The date to be used for the payment transaction. Should default to the system date.
  • Payment status: Populated with the payment status for the proposal after it is processed.

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

800px
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:

  • Due Date from: Start range of the secondary filter
  • Due Date to: End range of the secondary filter.
  • Supplier filter: For viewing the proposal for a particular supplier.
  • Currency: Please note that there is an error in the graphic as this must be a read only field for information purposes only. There can be only one currency for a proposal and that is defined by the payment method.

The grid contains all the proposed payments:

  • Business Partner: this can be either a supplier or a customer (e.g., for a refund of overpayment).
  • PO nr: The original purchase order matched to the supplier invoice.
  • Invoice: The number of the document being proposed for payment. If there are multiple payments scheduled for a particular invoice then this field will also display which payment line in the payment plan is being proposed. For example (1/2) means that it is the first payment of two scheduled payments.
  • Check box: Shows that the item is selected for payment. By default all items are checked. If a user wishes to remove a payment from the proposal then they can uncheck the line.
  • Due Date: The due date of the scheduled payment.
  • Invoiced: The total gross value of the invoice.
  • Expected: The value of the due payment in the payment plan
  • Payment: The amount proposed for payment. As a default the system will automatically propose the full value of the expected payment. A user with sufficient permissions can edit this value. Normally the user will only be able to reduce the value proposed. If an overpayment is allowed it must be configured at a system level as an insignificant value. If the user reduces the value to zero then the line will automatically be deselected from the payment proposal (and will be included in the next payment proposal for this payment method).

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.

800px
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:

  • On the first line the user has reduced the proposed payment so that there is an underpayment of 5 EUR. This is a significant value (outside the range of (-0.01 to +0.01)) that is simple underpayment.
  • On the fourth and sixth lines the use has made an overpayment that is within the bounds of insignificance. The system has therefore automatically suggested that the difference be written off (the "Write off" option is checked).



800px
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.

800px
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.

800px
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.

800px
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.

800px
Image MP0008: If the user is happy to proceed they can click on "OK" to trigger the automatic payment plugin.

Note:

  • The "Action" is shown as an example of a user interaction that may be required by the automatic payment plugin.
    • As an example, a payment method of "Cheque" may also prompt the user to enter the number of the first cheque portfolio that is on the printer.
    • Each cheque number consumed by the printer can then be recorded in the system against the payment line that it settled.
  • Different automatic payment plugins will require different actions to complete them.
  • It is envisaged that the automatic payment plugins will be provided as commercial modules. If the user does not have a workflow module installed and associated with the payment method then they should be invited to purchase it.
  • Automatic Payment Plugins are associated with Payment Methods.
  • It is envisaged that we will:
    • Convert any existing Spanish Form of Payment, that generate payment documents, to Automatic Payment Plugin modules.
    • Work with an existing partner to support their development of a commercial Automatic Payment Plugin module for another market (Germany?)



800px
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.

800px
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

800px

800px
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.

800px
Image TR0002: This provides the user with a view of the transactions associated with this financial account.

  • Account: The account number and name of the financial account.
  • Last reconciliation: The date of the last time this account was reconciled to the bank statement from the bank. A count of the number of unmatched items is shown for the date of today.
  • Starting Balance: This is the balance resulting from the last reconciliation (could also be called "Last Reconciled Balance"..
  • Present Balance: The current balance of the account.
  • Hide reconciled transactions: By default the grid only shows unreconciled transactions.
  • HIde transactions in intermediate account: Check box option to hide the transactions held in the (system managed) intermediate account associated to this financial account. The reason this is needed is because of the possibility to configure the payment workflow to use an intermediate account. The effect of this is that the transactions in the Financial Account are driven by the reconciliation process; the reconciliation process triggers the transfer from the intermediate account to its associated financial account. This configuration implicitly means that:
  • Hide transactions after the statements end date: a filter that is useful when a statement date is known, either via importing a statement or entering it via the reconciliation screen.
    • all transactions in the Financial account are cleared (as they wouldn't be there if they weren't cleared)
    • in order to view uncleared transactions the user needs to be able to view the transactions in the intermediate account
    • the balance of the financial account is always equal to the balance as at the last reconciliation (as the balance is driven by the reconciliation).
    • the difference between the bank statement and the financial account will be largely explained by the transactions in the intermediate account (plus unaccounted for bank fees and charges shown on the latest statement).
  • Clear all: Check box option to mark all transactions in the grid below as cleared (i.e., they have all been manually matched to the bank statement).
  • Grid:
    • Date: The transaction date.
    • Business Partner: The name of the business partner.
    • Inv/Order Ref: The reference to the original supporting invoice or order document.
    • Payment Ref: The reference to the Payment Document (e.g., the cheque number)
    • Description: The text added to the payment transaction on entry.
    • Paid: The amount of the payment made.
    • Received: The amount of the payment received.
    • Bal.: The balance on the account resulting from this transaction.
    • Cleared: Whether the transaction has been matched to a transaction on the Bank Statement.

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

800px
Image TR0003: On this screen the user can add a payment.

  • Payment Document Nr: The reference number of the payment document (e.g., the cheque number)
  • Payment Type: Drop down selector offering an extensible list of payment types. Default should be "Business Partner Deposit"
  • Business Partner: The business partner making the payment.
  • Payment Method: How the payment was made / received.
  • Financial Account: The Financial Account that will ultimately be debited with this payment. For example, if this is a receipt of a payment by cheque then the workflow states that an intermediate account should be used (and the actual accounting for this event should therefore result in a posting to the intermediate account). The reversal out of the intermediate account and the transfer to the 10100 - Checking account will be driven by the reconciliation process.
  • Currency: The currency of the transaction. Note: This is a view only field as the currency is driven by the financial account.
  • Expected Payment: Used when this screen is linked to from a specific invoice. It is then populated automatically with the next payment due from the payment list associated with the invoice.
  • Actual Payment: The amount of the payment received.
  • Payment Date: The date of the payment (should default to the system date).
  • Description: Free format text field allowing descriptive text to be added by the user.
  • Filters: Allow the user to filter the data set of Sales Orders / Invoices
    • Due Date from: filter to set date range
    • Due Date to: filter to set date range
    • Document type: Whether the user wants to see "Sales Invoices", Sales Orders" or "Both Orders and Invoices". Default should be "Invoices".
  • Grid:
    • Sales Order Nr.: The number of any Sales Orders meeting the selection and filter criteria above.
    • Sales Invoice Nr.: The number of any Sales Invoices meeting the selection and filter criteria above.
    • Due Date: The Due Date of the document.
    • Invoiced Amount: The total Gross Value of the Invoice.
    • Expected Amount: The expected amount of any due lines in the payment plan for the invoice.
    • Payment: The amount of the payment assigned to the line item.

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.

800px
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".

800px
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).

800px
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

800px
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.

800px
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.

800px
Image TR0009: The user is invited to confirm the action.

800px
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".

800px
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".

800px
Image TR0012: In the reconciliation screen the transaction for Mafalda is automatically shown as "cleared". The user clicks on "Reconcile" to complete the reconciliatation.

800px
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.

800px
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

800px
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".

800px
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.

800px
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.

800px
Image TR0018: The user is presented with a list of previously imported bank statements and whether they have been reconciled or not.

  • "Import date" shows the date the file was imported
  • "Statement Date" shows the date the statement represents
  • "Reconciliation Date" should show the date that the reconciliation was completed.



800px

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".

800px
Image TR0020: The system has found two matches:

  • Strong Match (highlighted in dark green) matched on:
    • Name
    • Reference
    • Amount
  • Weak Match (highlighted in light green) matched on:
    • Partial on name
    • Amount

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"...

800px
Image TR0021: ...which opens up a search screen (using the new search mechanism).

800px
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".

800px
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"...

800px
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".

800px
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".

800px
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.

800px
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"...

800px
Image TR0028: ...and is invited to confirm the action.

800px
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.

800px
Image TR0030: The user is returned to the transactions screen where they receive confirmation that the process has successfully completed.

800px
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:

  • "Import date" shows the date the file was imported
  • Statement Date shows the date of the bank statement.
  • "Reconciliation Date" should show the date that the reconciliation was completed.



800px
Image TR0032: Clicking on the Statement Details tab the user can see the detail of the imported statement.

800px
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.

800px
Image TR0034: This opens a summary view of the reconciliation. This shows:

  • Statement Date: Shows the date that the reconciliation was based on.
  • End Balance: The statement end balance.
  • Items reconciled: The number of items reconciled.
  • Unreconciled Statement Lines: Number of unreconciled items (Miss X)
  • Outstanding Payments: Number of outstanding payments (Mari Cleaning Services).
  • Outstanding Deposits: Number of outstanding deposits (Priscilla Pirelli).

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

800px
Image TR0035: This opens a summary screen. The user clicks on one of the "Publish" options...



800px
Image TR0036: ...and the Reconciliation Report is generated. In this case it is the "Publish Detail" option.



800px
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:

  • a "Storno Purchase Invoice" Payment must generate a negative (-) "Payment Out"
  • an "AP Credit Memo" Payment must generate a negative (-) "Payment Out""
    and
  • a "Storno Sales Invoice" Payment must generate a negative (-) "Payment In"
  • an "AR Credit Memo" Payment must generate a negative (-) "Payment In"

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:

File:Reversal APCreditMemo.png

File:Reversal Storno Sales.png

Future Enhancements

  • Anticipated Date (priority / statistical / manual)
  • Anticipated Value (Doubtful Debt)
  • Cash Flow Forecasting (Absolute vs Statistical)
Retrieved from "https://wiki.infinite-erp.co.id/index.php?title=Projects/AdvPaymentMngt/Functional_Documentation&oldid=2736"