View source | Discuss this page | Page history | Printable version   

ERP 2.50:Functional Documentation/Financial Management/Receivables and Payables


Contents

Introduction

Receivables and Payables groups all the management of the money transfers with business partners (providers and customers).

This is the typical cycle of receivables and payables with Openbravo:

  1. Generate, complete and post an invoice. This invoice will generate one or more payments.
  2. Optionally create one settlement with one or more payments.
  3. Collect or pay the invoice's amount through a bank statement, or a cash journal.
A payment has three "flags" associated

Payments

A payment is a credit pending to collect from a customer (then it will be marked as receipt), or an obligation to pay some amount to a supplier.

Apart from the receipt characteristic, there exist three flags associated to a payment in Openbravo:

  1. Cancelled: if the payment is divided or grouped through a settlement, the cancelled tag is activated
  2. Paid: if the debt associated to a payment is paid off, even if the money transfer does not take place, the paid flag is activated.
  3. Bank statement/Cash journal: if a bank statement or a cash journal includes a payment, then the flag bank statement\cash journal is activated.

Payments Created From Invoices

An invoice consists of some lines (with products, amounts, etc.), taxes and payments. When an invoice is filled in and passes to the completed state, taxes are recalculated automatically and the grand total amount of the invoice (the sum of the lines, plus the sum of the taxes) is calculated.

An invoice will have a concrete payment term. When completing the invoice, the corresponding payments are automatically created, according to those payment terms, with its corresponding dates. The sum of the payments amounts will always be equal to the grand total amount of the invoice. Before completing the invoice, a payment can be manually created for it. If one or more payments were created manually for the invoice, two things can occur:

  1. The grand total amount of the invoice is equal to the sum of the created payments amounts. Then no action is taken.
  2. Otherwise, one or more new payments are created automatically, so the sum of the automatically and manually created payments are equal to the grand total amount of the invoice.

In any case, all the payments (automatic and manual ones) will be created with all the “flags” deactivated.

Example 1

A new purchase order (PO) is created. Some lines are added to this PO, so the total cost is $1,000. Products included in the PO have 15% of associated taxes, so the grand total amount is $1,150. The payment term says that 50% must be paid immediately and the other 50% after one month. A payment of $650 is created manually in the PO, because the supplier requires that we pay that amount when sending the purchase order.

When the supplier's invoice arrives, and the invoice is created in the system from the PO, when completing the invoice, two more payments will be created automatically, apart from the $650 manually created one: one of $250 with the same date of the invoice and another one of $250 for a month later.

Other payment operations

The most common way to add payments to the system is through invoices, but it is not the only one. Payments can also be created through manual settlements and bank statement lines: we will see afterwards.

A payment will be pending in the system until the debt is paid off, that is, until a money transfer takes place through a bank statement or a cash journal. There is an exception: a payment can be transformed (grouped with some other payments into only one payment, or divided into smaller payments) through a settlement, so the original payment is settled, and some new ones are created. All these situations are controlled through the three flags associated to a payment.

Since release 2.50 it would be available a new payment operation: Payment in Advance. Using this process the user would be able to generate/update all the needed documents in one step and prone to mistakes. The output for this process would be:

Settlements

A settlement is an operation with one or more payments. Using a settlement, one or more payments are marked as cancelled, and some others created. This is useful, for example, for grouping some payments into only one payment, or dividing a payment into some smaller ones. Only payments with no flag activated are suitable to be transformed through a settlement.

The way this operation is done, is to activate the “Cancelled” flag in the original payments, and to generate new ones that are equivalents in value to the cancelled ones.

Example 2 (part I)

On March 1st, Company A issues one invoice to the Customer C. Grand total amount of the invoice is $10,000. Payment term is immediate, so when completing the invoice, one payment of $10,000 is created.

On March 5th, Company A negotiates with Customer C that $6,000 will be paid now, and $4,000 in two months. A settlement cancels the $10,000 payment and create two new payments, of $6,000 and $4,000.

Cancelled payments Created payments
Settlement Payment10000.png
Payment6000.png Payment4000.png

On March 6th, the $6,000 payment is included in a bank statement, so debt is over, and payment is over.

Payment6000paid.png


The $4,000 payment will remain pending in the system until a bank statement or a cash journal takes place.

Settlement types

Two types of settlements exist in Openbravo: transformation and cancellation settlements.

  1. A transformation settlement is the one shown in example 2.
  2. A cancellation settlement is automatically created when a payment is included in a bank statement or a cash journal. This settlement changes the flags of the payment to "paid", "cancelled" and "bank/cash":

Example 2 (part II)

On May 1st, a bank statement is created in the application, the $4,000 payment included in it, and the bank statement processed:

Cancelled payments Created payments
Settlement Payment4000paid.png

Payments situations

A payment can be in one of these situations:

Cancelled Paid Bank/Cash Image Description Possible actions
No No No PaymentNNN.png It has been created from an invoice, or a settlement. It was not ever included in a bank s., cash j. nor settlement Include in a Settlement, Bank S. or Cash J.
Yes No No PaymentYNN.png Has been cancelled None
Yes Yes No PaymentYYN.png Has been cancelled and marked up as paid in a settlement Include in a Bank Statement or Cash Journal
Yes Yes Yes PaymentYYY.png Has been included in a bank statement or cash journal None


Example 3

On 1st January, Company A issues one invoice of $21,500 to Customer C, with payment term “90 days”. When completing it, a payment P1 of $21,500 with date 1st of April is created.

On 10th January, Customer C phones Company A advising that there was an error in the invoice's prices. Company A checks that the customer is in the right and issues a credit note to Customer C for -$6,500. When completing it, a payment P2 of -$6,500 is created.

RecAndPayEx3-1.png

On 10th January, a settlement is created. Both payments are chosen to be cancelled and a new one of $15,000 is created.

Cancelled payments Created payments
Settlement RecAndPayEx3-2.png RecAndPayEx3-3.png

On 1st April, a bank check arrives at Company A from Customer C and is sent to the bank, is then collected by the bank and the money deposited in the bank account. A bank statement is created and the Payment P3 is added to the bank statement. Once the bank statement is processed, the “cancelled”, ”paid” and “bank/cash” flags of the payment P3 are activated and the payment is settled.

RecAndPayEx3-5.png

Bank Reconciliation

The last step in the receivables and payables process is to perform a bank reconciliation: this is the process of matching and comparing figures from accounting records against those presented on a bank statement (Wikipedia). In this process some differences may appear, highlighting the bank statements not registered in the system. Then the bank statements left are created, locating the payments paid or collected in that bank statement.

When creating a bank statement or a cash journal element in the system, a payment must be associated to it. Only two types of payments are able to be included in a bank statement or a cash journal:

  1. a payment that has been marked as cancelled and as paid through a settlement (all flags active in except of the bank/cash flag).
  2. a payment with no flag activated, such as those generated when an invoice is completed. In this case, a settlement will be automatically created in order to activate the cancelled and paid flags of the payment.

Once the bank statement is processed, the payment involved in it will have the three flags activated, so the payment will be settled.

Payment Creation in the Bank Statement

When a bank statement is created in the system, one or more existing payments have to be included in the bank statement. If the payment that we want to pay or collect in the bank statement does not exist already, it can be created. Notice that this is only possible in the case of the bank statement and no with a cash journal.

Example 4

Company A sends a purchase order to Supplier S, and Supplier S advices that goods must be paid completely before the goods shipment takes place. The grand total amount of the invoice is $10,000.

Company A performs a bank transfer of $10,000 and creates a bank statement in the system. There is no payment to be included in this bank statement, because the invoice has not arrived yet. A payment is then created by user with next data:

Then system will create two payments, through an automatically created settlement:

  1. Payment P1, of $10,000, with no flag activated.
  2. Payment P2, of -$10,000, with no flag activated.

When the bank statement is processed, all the flags of the payment P1, of $10,000, are activated. This is done through another automatically created settlement. The payment P1, then, is settled.

Some days later, the invoice from the Supplier S arrives. When it is introduced in the system and completed, one payment P3 of $10,000 is created, as in any other purchase invoice.

The System recognizes that two payments from the same business partner exist (Supplier S), one of -$10,000 (P2), and the other of $10,000 (P3), and then cancels both, through an automatically created settlement, when completing the invoice.

Manual Settlements

A manual settlement is a document that creates a new payment in the system. It is the way of creating a payment that does not have an invoice associated, for example, the payrolls payments, or the tax payments.

When defining a manual settlement, some information about the new payment is needed (business partner, amount, etc.), but also the accounting entry information is required (amount and account combination to the debit, amount and account combination to the credit, description, etc.).

There is one option in a manual settlement called direct posting. When this option is not activated, the manual settlement will not be able to be posted (if posted, it's status will turn to "Document Disabled for Posting"). The accounting entry associated to this operation will be created in the cancellation settlement.

On the other hand, if direct posting is activated, then the manual settlement will be able to be posted and an accounting entry will be generated.

Example 5

On January, 21st, Company A creates payrolls in the system as manual settlements. The payroll of one of the employees is as follows:

This manual settlement has the direct posting activated, against the Employees payments account. This manual settlement is posted, and generates the next entry:

Payroll Expenses $3,000
Social Security $500
Taxes $700
Employee's payments $1,800

Example 6

Company A's partner decide to perform a capital increase operation, so a $1,000,000 investment is performed through a bank transfer.

A manual settlement is created with these values:

Notice that this accounting entry is not balanced. This is because the manual settlement has not got direct posting, so the amount necessary to make entry balanced coincides with the payment amount.

When the payment is included in a bank statement in the system, and the bank statement is posted, the generated accounting entry will be as follows:

Net Worth $1,000,000
Bank Account $1,000,000

Payments Status

When the payment was explained, some characteristics where reviewed, such as the three flags for "cancelled", "paid" and "bank\cash", whether it was a receipt or not, and the status. This status can be changed through a remittance, or through the payment status management.

Remittances

A remittance is a group of payments sent to the bank, for it to manage the money collection from customers, or the money payment to providers.

There exist two types of remittances: consolidated or non-consolidated:

In a non-consolidated remittance, payments are treated independently and no special action is taken.

When a consolidated remittance is created with some payments, a settlement will be created automatically. In this settlement no payment is cancelled, but some others are created. The business partner associated to these payments created will be the bank where the remittance is sent. The way this payments are created is:

If one or more of the payments included in the remittance had got a withholding amount, then in the created settlement, one more new payment is created for each of those payments that had a withholding amount. The amount for this payment will be zero, and the withholding amount will be same than the one in the original payment.

All the created payments sums zero amount, and zero withholding amount, so settlement can be processed.

If any of the remittanced payments had got withholding, then a new settlement will cancel as paid the created payments with no amount, but withholding amount. This way, the withholding amount is posted in the moment of processing the remittance. If the remittanced payment with withholding is finally returned, then the withholded amount will be balanced.

In a consolidated remittance, it can occur that the bank makes a checking deposit, but a collection from a client can not be done. Then, the bank will return this payment and debit the money of that payment.

Once a remittance is processed (consolidated or non-consolidated), a file can be generated. This file contains all the data of the payments to be collected or paid. It can be sent to the bank to automatize the remittance process.

Example 7

There are two pending payments of $1,000 that corresponds to two sales invoices of the customer “C”. A consolidated remittance is created, with these two payments. The remittance is processed.

A settlement will be created automatically in which three payments are created:

The business partner of this settlement will be the bank.

When the bank makes the checking deposit, the created $2,000 payment will be cancelled. When the bank advises us that the collections from the customer have been performed successfully, both of the $-1,000 payments are cancelled with the originals $1,000 payments.

Payment Status Management

The payment status management is a document that allows to change the status of the pending payments in the system.

A payment has always a status associated. Some examples of possible status of payments are:

Notice that, apart from the status, a payment can be cancelled or not, and can be paid or not.

When processing a payment management document, the status of the payments in it will be changed, and when posting it, a new account can be established for the payments.

Example 8

On 1st June, Company A receives a purchase invoice from the Supplier S, for a grand total amount of $15,000. A payment P, of $15,000 is created.

On 20th June, Company A sends a bank check to the Supplier S, for $15,000. Through a payment status management operation, the status of the payment P is changed from “--” to “Sent”. When posting the change status management operation, an accounting entry like this is generated:

Customers $15,000
Pending payments $15,000

Example

This is a global example of some usual operations that a company can perform along a period of time.

On January 1st, Company A receive two invoices from supplier S1, both with 15 days payment terms.

On January 15th, Company A creates a settlement for supplier S1 that combines the payments for the two invoices and pays it via bank deposit.

Also, on January 1st, Company A issues 3 invoices, one to customer C1 with payment terms immediate and payment method check, and two to customer C2, one with payment terms immediate, the other with payment terms 15 days and payment method bank deposit.

On January 2nd, Company A receives a check from C1.

On January 2nd, Company A registers that the first payment from C2 has been received and on January 15th registers that the second payment from C2 has been received as well.

On January 16th, Company A issues an invoice to customer C3 with payment terms immediate and payment method check. The check is received that same day.

On January 20th, Company A deposits the two checks it received (from C1 and from C3) to the bank using a remittance.

On January 25th, Company A issues an invoice to customer C4 with payment terms immediate and payment method check. The check is never received.

Additionally, on a weekly basis (on January 5th, 12th, 19th and 26th), they pay their employees, in some cases with cash, in other cases with bank deposit. In both cases a manual settlement is performed.

On each of these occasions, Company A withdraws cash from the bank and puts in a petty cash register and finally disburses to the employees who are paid cash.

Finally on January 31st, Company A receives a bank statement for the activity of the month and discovers that on January 26th, the company had received an electronic payment from C4 corresponding to the amount of the invoice from January 25th. It is therefore clear that C4 had paid via electronic payment rather than check but that the invoice has been settled and the debt can be cancelled.

Retrieved from "http://wiki.openbravo.com/wiki/ERP_2.50:Functional_Documentation/Financial_Management/Receivables_and_Payables"

This page has been accessed 34,231 times. This page was last modified on 3 April 2012, at 11:00. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.