Projects/AdvPaymentMngt/Configuration Manual

Languages:

English Template This sub-template doesn't display properly when not included. Please see Template:Languages for the complete version. Usage This template is designed to simplify Template:Languages, by allowing a simpler syntax for adding new languages. Each language is included by calling this template with the following parameters: Language code (e.g. fr) (optional) Page name - if not supplied the page is automatically worked out based on where the language template is included. This template should not be used anywhere except in the Languages template. </noinclude> | Translate this article...

Document Status

Final: This document has been published.

Introduction

This document describes how to install and configure Advanced Payables and Receivables on top of a standard Openbravo ERP 2.50 instance.

Note: Advanced Payables & Receivables is also available through templates (either Openbravo QuickStart or Openbravo ERP 3.0) that automate the configuration of the module eliminating the need for many of the steps here documented. This manual refers exclusively to an installation on top of a standard 2.50 instance.

Advanced Payables and Receivables delivers an alternate set of flows for managing financial accounts and payments. These new flows replace the ones supported in Openbravo ERP Core.

From a high perspective, in order to use the new functionality, the following steps are needed:

1. Install the Advanced Payables & Receivables module
2. Deploying the new document types and default matching algorithm
3. Hide the core functionality that is being replaced
4. Configure Payment Methods
5. Configure Financial Accounts
6. Configure the Business Partner to use a Payment Method and a Financial Account

Installing Advanced Payables & Receivables

To install the module:

• Login as System Administrator
• Navigate to General Setup -> Application -> Module Management
• Click the Add Modules tab
• Find the Advanced Payables and Receivables module within the list of available modules
• Click on Install Now and follow the guided installation flow.

A detailed guide on how to install a new module can be found in the Install Module video.

NOTE: When installing APRM module, moduleScript is run to give "FIN_Finacc_Transaction" table access to existent roles. If you create role after installing the module, access to "FIN_Finacc_Transaction" table should be given manually.

Deploying the new document types and default matching algorithm

Advanced Payables and Receivables introduces new transactions in the system that require new document types to be defined in every client. Additionally, the bank reconciliation flow requires the definition of a matching algorithm.

Both sets of reference data are installed with the module but need to be applied to each client, new or existing, in the system.

To do so:

• Login as Client Administrator
• Navigate to General Setup -> Enterprise -> Enterprise Module Management
• For the * organization, choose the Advanced Payables and Receivables Management reference data set
• Click OK
• Repeat for every client.

Note: Future versions of Initial Client Setup will allow you to select reference data at the time of creation of a client, allowing you to perform this step at the time of new client creation.

"Reversal" Document Types

"AP/AR Credit Memo" and "Storno Sales/Purchase Invoice" document types must be setup as "Reversal" at the application path:
"Financial Management || Accounting || Setup || Document Type || Document Definition "
for them to properly work through the Advanced Payment Management workflow.

Those "reversal" document type implies a "negative" Payment In/Out as described below:

• AP Credit Memo and Storno Purchase Invoice document types imply a "negative" Payment Out
• AR Credit Memo and Storno Sales Invoice document types imply a "negative" Payment In"

Report Templates for Payments

Note: you should manually create the templates if you performed the Initial Client Setup in a MP18 or earlier maintenance pack. In other case the Initial Client Setup will populate needed data or you will be able to apply again the updated core dataset.

Go to Financial Management || Accounting || Setup || Document Type and add a new Report Template and Email Definitions for the following Document Types:

AR RECEIPT		AP PAYMENT
Report Templates		Report Templates
Organization	*	Organization	*
Name	AR Receipt Report template	Name	AP Payment Report template
Template Location	@basedesign@/org/openbravo/erpReports	Template Location	@basedesign@/org/openbravo/erpReports
Template Filename	RptFIN_Payment.jrxml	Template Filename	RptFIN_Payment.jrxml
Report Filename	Payment In-@our_ref@	Report Filename	Payment Out-@our_ref@
Show Logo	If selected the logo will be printed.	Show Logo	If selected the logo will be printed.
Show Company Data	If selected the company data will be printed.	Show Company Data	If selected the company data will be printed.
Header Margin	Margin size in the top of the document.	Header Margin	Margin size in the top of the document.
Email Definitions		Email Definitions
Organization	*	Organization	*
Default	Yes	Default	Yes

Here more information about how to customize document printable templates.

Hiding core functionality

Removing obsolete functionality

The following menu entries are no longer needed once Advance Payables & Receivables is installed and should be removed from the Openbravo menu.

• Financial Management
  • Receivables & Payables
    • Transactions
      • Bank Statement
      • Cash Journal
      • Funds Transfer
      • Remittance
      • Payment Status Management
      • Manual Settlement
      • Settlement
      • Remittance Cancellation/Return
      • Change Payment Status
    • Analysis Tools
      • Bank Report
      • Cash Report
      • Cashflow Forecast
      • Payment Report
      • Payment Aging Balance
      • Payment Tracker
    • Setup
      • Bank
      • Cashbook
      • Remittance Type
      • Promissory Note Format

This can be achieved by either:

1. Marking these entries as not active in the menu (please ensure to put your system in configuration mode first)
2. Defining a new role that does not have access to these functions

Hiding the obsolete Payment tab

The new payment flows no longer use what previous version of Openbravo used to call the "Payment" object (the table C_DEBT_PAYMENT). Consequently, the corresponding tab can be hidden in the following windows:

• Sales Order
• Sales Invoice
• Purchase Order
• Purchase Invoice

To achieve this:

• Login as System Administrator
• Navigate to Application Dictionary -> Windows, Tabs and Fields
• Select the record corresponding to each of the above windows and for each of them, click on Tab
• Select the Payment tab and mark it as not active.

Saving Configuration

Once local changes in AD has been made do not forget exporting database to reflect such changes in your source files (XML).

In previous section some tabs and menu items may have been hidden. Those changes are AD changes that require them to be exported or reverted before installing or updating a module.

To do so you need to perform an ant task as follows:

First make sure you are the openbravo system user:
sudo su - openbravo

Then make sure you are in the Openbravo directory:
cd /opt/OpenbravoERP-2.50/openbravo-erp

Lastly run the ant task:
ant export.database export.config.script -Dforce=true

Configuring Payment Methods

Payment methods represent means of payment employed by your enterprise or by a business partner, such as cash, check, money order, or credit card with order or upon invoicing.

Payment methods are associated to Financial Accounts in order to control which payment methods can be used with a Financial Account. It is possible to associate multiple payment methods to a single Financial Account. For example, a single Financial Account may be used for both checking and for electronic payments.

To define payment methods:

Login as client administrator Navigate to Financial Management -> Receivables & Payables -> Setup -> Payment Method Define your payment methods by entering a record with a name and an optional description. If you wish this Payment Method to be active immediately, please ensure that the 'Active' option is selected. If you wish this Payment Method to allow "Other currencies" than "Financial Account default currency", while either making/receiving payments in a "Financial Account", enable below parameters which can be found in the sections "Defaults Payment In" & "Defaults Payment Out": "Receive payments in other currencies" "Make payments in other currencies" The remaining options in the Payment Method window are described in the following section on Payment Workflow Automation.

File:PaymentMethod.png View larger

Payment Workflow Automation

There are various options available to support automation of the workflow for each payment method.

Note: These options are the defaults for this payment method. Each Financial Account also allows workflow options to be define. Any variation in workflow associated with a Financial Account takes precedent over the default workflow.

Defaults Payment IN

• Payment In Allowed: If checked then the payment method is enabled to receive payments.
• Automatic Receipt: On completion of a Sales Invoice the payment is automatically received. You can use for example for cash over the counter transactions.
• Receive Payments in Other Currencies: Checking this option results in receiving payments in other currencies than the Financial Account default currency.
  "System" conversion rate for a given date is used while receiving a payment in that date unless it is manually updated by the end-user.
• Automatic Deposit: Checking this option results in a payment received using this payment method being automatically deposited in the Financial Account. You can use this for example for credit card receipts.
• Execution Type
  • Manual: The receipt of payment is a manual event.
  • Automatic: The system will automate the receipt of payment by launching a process to support receipt. An example might be a credit card interface being launched to record a receipt of payment by credit card.
    • Execution Process: Select the process to be launched to automate the receipt.
    • Deferred: If this execution process should be used to automate the process, but it will be triggered at a later point in time (by someone launching the execution process manually), then please ensure this option is selected.
• Upon Receipt Use: Account to be used upon receipt. Would normally be either left blank (if financial transaction is to be created later in the workflow), an Intransit Payment Account or a Financial Account
• Upon Deposit Use: Account to be used upon deposit. Would normally be left blank (if no financial transaction required for the Deposit event) or a Deposited Payment Account
• Upon Reconciliation Use: Account to be used upon clearing. Would normally be the Financial Account, but could be left blank if the receipt has been posted to the Financial Account earlier in the process (perhaps upon receipt or upon deposit).

Defaults Payment OUT

• Payment Out Allowed: If checked then the payment method is enabled to make payments.
• Automatic Payment: On completion of a Purchase Invoice the payment is automatically made. You can use for example for cash over the counter transactions.
• Make Payments in Other Currencies: Checking this option results in making payments in other currencies than the Financial Account default currency.
  "System" conversion rate for a given date is used while receiving a payment in that date unless it is manually updated by the end-user.
• Automatic Withdrawal: Checking this option results in a payment made using this payment method being automatically withdrawn from the Financial Account. You can use this for example for credit card payments.
• Execution Type
  • Manual: The creation of a payment is a manual event. For example, payment by cash.
  • Automatic: The system will automate the creation of a payment document by launching a process to support payment. An example might be a check printing utility that automatically prints checks, or a credit card interface to make payment by credit card.
    • Execution Process: Select the process to be launched to automate the payment process.
    • Deferred: If this execution process should be used to automate the process, but it will be triggered at a later point in time (by someone launching the execution process manually), then please ensure this option is selected. As an example, you may wish to print all checks in a batch run at the end of the day.
• Upon Payment Use: Account to be used upon payment. Would normally be either left blank (if financial transaction is to be created later in the workflow), an Intransit Payment Account or a Financial Account
• Upon Withdrawal Use: Account to be used upon withdrawal. Would normally be left blank (if no financial transaction required for the Withdrawal event) or a Withdrawn Payment Account
• Upon Reconciliation Use: Account to be used upon clearing. Would normally be the Financial Account, but could be left blank if the receipt has been posted to the Financial Account earlier in the process (perhaps upon payment or upon withdrawal).

Note: Automatic Receipt and Automatic Payment require a Financial Account to be associate with the Business Partner. Please refer to the section on Configuring Business Partners.

Configuring Financial Accounts

Financial Accounts are used in Openbravo to represent accounts at financial institutions such as bank accounts, credit cards, electronic payment services, as well as cash and petty cash registers.

Defining additional Financial Account Types

Financial accounts represent the nature of the account (bank account, cash, credit card, etc.). The module pre-defines the following two account types:

• Bank
• Cash

You can define additional account types by extending the list Financial account type.

Remember that, prior to extending a Core list, you need to register a extension module to house your additional entries. The module needs to be in development mode and have a valid DB prefix associated to it.

Finally, please ensure to persist your changes to the file system by running the ant export.database command.

Defining Financial Accounts

To define financial accounts: Navigate to Financial Management -> Receivables & Payables -> Transactions -> Financial Account. In this window: The top section is used to populate general information about the account, such as: Name and description Currency of the account Type Whether this is the default account to be used in transactions A business partner associated to this bank account (for example, the Financial Institution holding the account) The next section Bank is visible only for accounts of type Bank and are used to specify the bank account number. It includes information such as: Bank Code Branch Code ... as well as the matching algorithm to be used during the reconciliation process.

File:FinancialAccount.png View larger

• In the last section named "Amounts", you can specify:
  • A Initial Balance = this field will only be editable when creating the financial account.
    This is the "real" initial balance of the Bank.
  • A Current Balance = this field will only be editable when creating the financial account.
    This is the initial balance of the Bank in the "old" "financial" system, and it is going to be the balance of the Openbravo Financial Account.
    In the case of a full match the Initial Balance must be the same as the Current Balance.
    Openbravo will update the current balance of the financial account as appropiate.

File:FinancialAccountInitialBalance.png View larger

Financial Account Configuration

Next you need to configure the default accounts to be used for transactions related to financial accounts: Click on the 'Accounting Configuration' tab of the Financial Account window. Create a new record for each accounting schema.

File:FinancialAccountConfiguration 1.png View larger

In the General section you can define the following default accounts:

• Bank revaluation gain account: used to credit any exchange rate gain in transactions involving multiple currencies;
  • In case of a "Cash" Financial Account type, the ledger account used to credit any exchange rate gain in transactions involving multiple currencies is the "Bank Revaluation Gain" account, which can be found in the Accounting Schema - Defaults tab.
• Bank revaluation loss account: used to debit any exchange rate loss in transactions involving multiple currencies.
  • In case of a "Cash" Financial Account type, the ledger account used to debit any exchange rate loss in transactions involving multiple currencies is the "Bank Revaluation Loss" account, which can be found in the Accounting Schema - Defaults tab.
• Bank fee account: used to debit any expense for bank fees or related charges;

Besides, the end-user can define the accounts to be used in case of Bank Statements posting if the "Enable Bank Statement" flag is selected:

• Bank asset account
• Bank transitory account

When posting bank statements, the "Bank Transitory Account" must match the accounts used upon clearing for all the payment methods in order to ensure properly balanced accounting.

Above means that the "Bank Transitory Account" must be the same one as the "Cleared Payment Account" for both "Payments In" and "Payments Out"; the system will guide us through the accounting configuration process to allow above mentioned matching:

• As soon as the "Bank Transitory Account" has been defined by the end-user, the system will show us an information warning stating:
  "When posting Bank Statements, the Bank Transitory Account should match the account used upon clearing for all payment methods in order to ensure properly balanced accounting.Do you want to propagate this value to all payment methods? (YES)
• Once the end-user press (YES), the system will fill-in the Bank Transitory Account as "Cleared" payment accounts for both Payment In/Out.

In the Payment IN section you can define the following default accounts:

• In Transit Payment Account: Account used for in transit status of incoming payments.
• Deposit Account: Deposit Account used by the financial account
• Cleared Payment Account: Account used for payment IN when clearing

Defining these three accounts is not mandatory. User can configure the system to use one single account and assign it to one of the given steps. In addition system as well can be configured to move balances between accounts for the three steps and that is why there are three accounts available.

In the Payment OUT section you can define the following default accounts:

• In Transit Payment Account: Account used for in transit status of outgoing payments.
• Withdrawal Account: Withdrawal Account used by the financial account.
• Cleared Payment Account: Account used for status cleared of outgoing payments

Again defining these three accounts is not mandatory. User can configure the system to use one single account and assign it to one of the given steps. In addition system as well can be configured to move balances between accounts for the three steps and that is why there are three accounts available.

Payment Method Configuration

Next you need to define which payment methods can be used for each finacial account you have created. In order to configure the payment methods to be used for transactions related to financial accounts: Click on the 'Payment Methods' tab of the Financial Account window. Create a new record for each payment method that you would like to associate with the Financial Account. From the 'Organization' drop down list select the organization for which this combination of Financial Account and Payment Method will be available. From the 'Payment Method' drop down list select the payment method that you would like to associate with the Financial Account. This automatically populates the subsequent options in this window with the default workflow configured for that payment method. Any change to the payment method workflow configuration in this window will not change the default configuration, but will create a specific workflow for this Financial Account.

File:FinancialAccountPaymentMethod.png View larger

Defining alternate matching algorithms

During the reconciliation process, Openbravo uses a matching algorithm to automatically match transactions in a financial account with transactions contained in a bank statement.

You can develop alternate matching algorithms as a Java class implementing the interface org.openbravo.advpaymentmngt.utility.FIN_MatchingAlgorithm. Once developed, you can register that class for usage in the Matching Algorithm window, available at Financial Management' -> Receivables & Payables -> Setup -> Matching Algorithm.

Configuring Business Partners

Payment Methods

Once you have defined payment methods you can then associate the default payment method to be used on orders or invoices by business partner:

• Login as client administrator
• Navigate to Master Data Management -> Business Partner
• Query your customers and, in the Customer tab, specify
  • the default means of payment in the Payment Method field and
  • the Financial Account to which you will automatically receive payment (for sales transactions where the payment method is set to automatically receive payment). For more information see the Financial Account section.
• Query your vendors and, in the Vendor/Creditor tab, specify
  • the default means of payment in the PO Payment Method field and
  • the Financial Account from which you will automatically make payment (for purchase transactions where the payment method is set to automatically make payment). For more information see the Financial Account section.

Financial Account

Once you have defined Financial Accounts you can then associate the default Financial Account when receiving payment from or making payment to a business partner. Please note that in order for a payment method to automatically receive from or pay to a Business Partner, the default Financial Account needs to be defined. If no Financial Account is defined then an invoice posting for that Business Partner will complete without the payment being automatically received or paid.

In order to associate the default Financial Account:

• Login as client administrator
• Navigate to Master Data Management -> Business Partner
• Query your customers and, in the Customer tab, specify the default Financial Account in the Financial Account field
• Query your vendors and, in the Vendor/Creditor tab, specify the default Financial Account in the Financial Account field

Accounting Process

Bank Statement Posting

We will illustrate Bank Statement posting concept with an example.

Example: bank statement posting after being imported

Let's consider a scenario where a bank statement containing 3 bank statement lines for a total amount of -5627.42€ is imported. The system will show below ledger entries after posting the bank statement imported.

Account	Dr	Cr
Bank transitory account	5627.42
Bank asset account		5627.42

Negative Bank Statement Lines:

Let's imagine that one of the bank statement lines has an amount = -4.627,42 that would mean a payment OUT: (Debit Amount = Payment OUT= Paid)

Bank statement line clearance posting:

Account	Dr	Cr
Vendor liabilities	4627.42
Bank Transitory account		4627.42

Therefore the complete set of posting will look like:

Invoice posting:

Account	Dr	Cr
Expense	4627.42
Vendor liabilities		4627.42

Bank Statement Posting:

Account	Dr	Cr
Bank transitory account	4627.42
Bank asset account		4627.42

Bank statement line clearance posting:

Account	Dr	Cr
Vendor liabilities	4627.42
Bank Transitory account		4627.42

Positive Bank Statement:

Let's imagine that one of the bank statement lines has an amount = + 1000,00, that would mean a payment IN: (Credit Amount = Payment IN = Received)

Bank statement line clearance posting:

Account	Dr	Cr
Bank Transitory account	1000.00
Customer		1000.00

Therefore the complete set of posting will look like:

Invoice posting:

Account	Dr	Cr
Customer	1000.00
Income		1000.00

Bank Statement Posting:

Account	Dr	Cr
Bank Asset Account	1000.00
Bank Transitory Account		1000.00

Bank statement line clearance posting:

Account	Dr	Cr
Bank transitory account	1000.00
Customer		1000.00

And Finally, the last bank Statement line for an amount = -2000.00, that would mean a payment OUT: (Debit Amount = Payment OUT= Paid)

Bank statement line clearance posting:

Account	Dr	Cr
Vendor liabilities	2000.00
Bank Transitory account		2000.00

Therefore the complete set of posting will look like:

Invoice posting:

Account	Dr	Cr
Expense	2000.00
Vendor liabilities		2000.00

Bank Statement Posting:

Account	Dr	Cr
Bank transitory account	2000.00
Bank asset account		2000.00

Bank statement line clearance posting:

Account	Dr	Cr
Vendor liabilities	2000.00
Bank Transitory account		2000.00

Payment Posting

The remaining sections determine how accounting is created for payment events occurring in this account.

In general, a payment goes through a life cycle consisting of three steps:

1. Payment: represents the moment when the payment event is recorded. For instance, it represents the moment in which you receive a check from one of your customers.
2. Deposit / Withdrawal: represents the moment in which the payment is deposited in your account. For example, it represents the moment in which you deposit a customer check in your bank and the funds become available.
3. Reconciliation: represents the moment in which the payment is marked as reconciled and you confirm that your books match those of the financial institution holding the account. For example, it represents the moment in which you reconcile your system with a bank statement confirming the proper deposit of your customer check.

These steps represent diminishing stages of risk in the payment life cycle and you can use this screen to control at which step your payments are accounted for and how you can represent the diminishing risk from an accounting perspective:

• For each step, you can specify the default account for the receivables and payables cycles independently.
• Each financial account involved in an accounting schema must have at least one default account for both the receivables and payables cycle at either step 1, step 2 or step 3.
• Both on the payables and receivables side, the first step containing an account represents the moment in which the supplier liability or customer receivables are cancelled. For example, if you leave the Receive Payment Account empty and you specify a Deposit Account, the customer receivables is cancelled at the moment of the deposit, not at the time of recording of the payment.
• Any subsequent step having an account would offset the account in the previous step with the account in that step to represent the diminishing of the risk.

At each stage we could potentially have a different currency or at least a different conversion rate. In practice:

• all payments will be in the same currency as the invoice. e.g. if invoice is in USD, you would pay/receive a USD amount.
• withdrawals & deposits are recorded in the currency of the financial account.

Current version works based on the "System" conversion rates wich can be found at the application path:
General Setup // Application // Conversion Rates.

We will illustrate these concepts with a few examples:

Customer receivables cancelled at the time of payment receipt with no risk management

Let's consider a scenario where you decide to cancel your open receivables whenever your record a payment receipt and you consider that all recorded payments are safe and do not represent any significant risk.

In this case you would setup your default accounts as follow:

• Receive Payment Account: Bank
• Deposit Account: no value
• Debit Account: no value

With this configuration, when you receive a payment of 100€, Openbravo will generate the following accounting entry:

Account	Dr	Cr
Bank	100
Receivables		100

Customer receivables cancelled at the time of payment receipt with risk management up to payment deposit

Let's consider a scenario where you decide to cancel your open receivables whenever your record a payment receipt and you consider that all recorded payments are safe and do not represent any significant risk.

In this case you would setup your default accounts as follow:

• Receive Payment Account: Payment in transit
• Deposit Account: Bank
• Debit Account: no value

With this configuration, when you receive a payment of 100€, Openbravo generates the following accounting entry:

Account	Dr	Cr
Payment in transit	100
Receivables		100

When you deposit the payment, Openbravo generates the following accounting entry:

Account	Dr	Cr
Bank	100
Payment in transit		100

Vendor payables in other currency (e.g USD), than the Accounting Schema and Financial Account currency (e.g EUR)

This scenario implies in relation to the purchase/sales invoice in USD:

• to apply the USD/EUR exchage rate while getting it posted.

This scenario implies in relation to the payment out/payment in USD:

• to apply the USD/EUR exchage rate while getting them posted and withdrawn/deposited in the financial account.

Invoice

On the 1st January receive an invoice for $1100 USD (including $100 tax).

Exchange rates

• System (USD->EUR) = 0.9 (1 USD = 0.9 EUR)

Account	Debit	Credit	Calculation
Accounts Payable		990 EUR	1100 USD * 0.9 USD/EUR
Purchase Expense	900 EUR		1000 USD * 0.9 USD/EUR
Tax	90 EUR		100 USD * 0.9 USD/EUR

First Payment

On the 16th January make a payment of $550 USD, using the system exchange rate

Exchange rates

• System (USD->EUR) = 0.8 (1 USD = 0.8 EUR)

Payment posting:

Account	Debit	Credit	Calculation
Accounts Payable	495 EUR		550 USD * 0.9 USD/EUR (exchange rate at invoice date)
Bank In Transit		440 EUR	550 USD * 0.8 USD/EUR
Currency Gain		55 EUR	495 EUR - 440 EUR

Note: The A/P entry must be caculated using the same exchange rate as the a/p credit in the original invoice journal. Otherwise the a/p account will not balance properly.

On the 16th January post the transaction in the bank account.

Financial Account transaction posting:

Account	Debit	Credit	Calculation
Bank In Transit	440 EUR
Bank		440 EUR

Second Payment

On the 23th January make a payment of $550 USD, using a custom exchange rate

Exchange rates

• System (USD->EUR) = 0.75 (1 USD = 0.75 EUR)
  which is manually changed by the end-user to (USD->EUR) = 0.7 (1 USD = 0.7 EUR)

Payment posting:

Account	Debit	Credit	Calculation
Accounts Payable	495 EUR		550 USD * 0.9 USD/EUR (exchange rate at invoice date)
Bank In Transit		385 EUR	550 USD * 0.7 USD/EUR (exchange rate entered manually by end user)
Currency Gain		110 EUR	495 EUR - 385 EUR

Note: The A/P entry must be caculated using the same exchange rate as the a/p credit in the original invoice journal. Otherwise the a/p account will not balance properly.

On the 25th January record the transaction in the bank account.

Financial Account transaction posting:

Account	Debit	Credit	Calculation
Bank In Transit	385 EUR
Bank		385 EUR

Vendor payables in the same currency (e.g USD) than the Accounting Schema (e.g USD) but in other currency than the Financial Account (e.g EUR)

This scenario implies in relation to the Bank (Financial Account) in EUR:

• to apply the USD/EUR exchange rate, to get the "Deposit Amount"
• to apply the EUR/USD exchange rate, to get the "Foreing Amount"

Besides, this scenario implies in relation to the Bank transaction posting:

• to apply the EUR/USD exchage rate

Invoice

On the 1st January receive an invoice for $1100 USD (including $100 tax).

Exchange rates

• System (USD->EUR) = 0.9 USD/EUR

Account	Debit	Credit	Calculation
Accounts Payable		1100 USD
Purchase Expense	1000 USD
Tax	100 USD

First Payment

On the 16th January make a payment of $550 USD.

The Financial Account in EUR is used as the source of the payment.
In this scenario:

• the Deposit Amount will be in (EUR)
• the Foreign Amount will be in (USD)

Exchange rates

• System (USD->EUR) = 0.8 (0.8 USD/EUR)
• System (EUR->USD) = 1.25 (1.25 EUR/USD)

Payment posting:

Account	Debit	Credit	Calculation
Accounts Payable	550 USD
Bank In Transit		550 USD	550 USD 0.8 USD/EUR = 440 EUR (Deposit Amount) 440 EUR * 1.25 EUR/USD = 550 USD (Foreign Amount)

On the 16th January record the transaction in the bank account.

Financial Account transaction posting:

Account	Debit	Credit	Calculation
Bank In Transit	550 USD
Bank		550 USD	440 EUR * 1.25 EUR/USD

Second Payment

On the 23th January make a payment of $550 USD, using a custom exchange rate

Exchange rates

• System (USD->EUR) = 0.75 (0.75 USD/EUR) which implies
• System (EUR->USD) = 1.333333333333 (1.33333 EUR/USD)

End user update the exchange rate to:

• Transaction (USD->EUR) = 0.7 (0.7 USD/EUR) which implies
• Transaction (EUR->USD) = 1.428571 (1.428571 EUR/USD)

while adding the payment, either from the Purchase Invoice or from the Financial Account.

Payment posting:

Account	Debit	Credit	Calculation
Accounts Payable	550 USD
Bank In Transit		550 USD	550 USD * 0.7 EUR/USD = 385 EUR (Deposit Amount) 385 EUR * 1.428571 EUR/USD = 550 USD (Foreign Amount)

On the 25th January record the transaction in the bank account.

Financial Account transaction posting:

Account	Debit	Credit	Calculation
Bank In Transit	550 USD
Bank		550	385 EUR * 1.25 EUR/USD

Special notes for Spanish users

Users of the Spanish Localization Pack should be using the following accounts coming from the Spanish statutory chart of accounts:

• Bank fee account: 62600
• Bank revaluation gain account: 76800
• Bank revaluation loss account: 66800

Payment Execution Process

The Payment Execution Process controls:

• the format of the payment documents / files to be created by the payment run, for example, cheque printing formats or electronic bank file layouts.
• the interaction with the user in order to ensure that the system has enough information to execute a payment run effectively. For example, asking the user to provide the number of the next cheque on the printer.

It is not possible to change the configuration of the payment run execution processes from the Openbravo user interface. It is, however, possible to view available payment methods:

Navigate to Financial Management -> Receivables & Payables -> Setup -> Execution Process where Openbravo provides two example payment processes: Simple Execution Process Print Check Simple Process. Each payment process is associated with an Execution Process that is a Java class containing the logic necessary to correctly complete the payment process. In order to change the behaviour of these example processes (or add additional payment formats) it is necessary to edit the example Java class objects or add new execution processes.

File:ExecutionProcess.png View larger