Projects/AdvPaymentMngt/Configuration Manual
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:
- Install the Advanced Payables & Receivables module
- Deploying the new document types and default matching algorithm
- Hide the core functionality that is being replaced
- Configure Payment Methods
- Configure Financial Accounts
- 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
- Transactions
- Receivables & Payables
This can be achieved by either:
- Marking these entries as not active in the menu (please ensure to put your system in configuration mode first)
- 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:
|
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:
In this window:
|
- 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.
- A Initial Balance = this field will only be editable when creating the financial account.
Financial Account Configuration
Next you need to configure the default accounts to be used for transactions related to financial accounts:
|
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:
|
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:
- 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.
- 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.
- 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:
|