Log in / create account
Openbravo.com
Issues
Forge
View source | View content page | Page history | Printable version   

Projects:Remittances/User Documentation

Contents

Introduction

"Remittance" is a community module which adds remittance support to the existing "Advanced Payables and Receivables Management" (APRM) functionality.

A remittance is a group of "payments" (in/out) or "orders/invoices" which can be remitted to the bank for its payment. The bank will then manage either the collection of the money from the customers or the payment to the vendors/suppliers.

This module supports several remittance types:

This module also provides the ability to print a remittance as well as the infrastructure to define a "remittance" file generation logic.

Workflow overview

The diagram below shows a common remittance scenario:
Remesas.png

It is important to highlight that the same remittance can include at the same time:

but single payment remittances can only include either

It is important to have into account that:

Terminology

Configuration

Please refer to the Configuration Manual for guidance on how to installa and configure remittance feature.

Business scenario/s

F&B is an enterprise making business with several Business Partners: Vendors, Suppliers, Customers, etc.

Every Business Partner can have a "by default" Payment Method such as:

and a "by default" Payment Terms such as:

Sales Staff issues sales orders and then sales invoices and Purchase Staff registers purchase orders and then purchase invoices, as required.

Accounting Staff registers payments in/out as well in the system if any and creates, process, print and post Remittances which could include any of the transactions described above, regardless the payment method as well as the payment terms.

Above means that a Remittance might include a mix of sales & purchase transactions & payments in/out for several payment methods and payment terms.

Purchase Order/Invoices & Payment Out

(Prepayment) Remittance

Accounting Staff must be able to remit purchase orders in case a prepayment is required for the Goods to be sent to F&B company.

For getting the above done:

for the system only to show purchase order transactions.

End-user could also select any purchase order, regardless its payment method by selecting the flag "Show payments for alternative payment methods"

End-user could also select any purchase order, regardless its currency by selecting the flag “Show payments for alternative currencies”.
This is allowed only if the remittance payment method related to the remittance type and financial account being used allows making payments in other currency than financial account currency.

Once the corresponding purchase orders have been selected, end-user must press "Process" button. After that the system will generate as many lines as transactions selected in the "Lines" tab.

Back in the "Remittance" window, the end-user can press the header button "Process", by doing that it is possible:

In this case, it does make sense to group by business partner in order to save payment fees/remittances fees or group by business partner and due date.
Openbravo will create as many payments as applicable taking into account "grouping" criteria, in other words:

Finally, the remittance must be posted. Posting will be sucessfull only in case vendor does have a "prepayment" account setup in the business partner window, vendor accounting tab.

Posting looks like:

(40700) Vendor prepayment account DEBIT
(40100) Remittance Type - Sent Account CREDIT

Later on and once the bank has made the payments on its due date, the remittance lines must be "Settled" in the "Settle / Protest Remittances" window, by:

Back in the remittance window, Openbravo shows for a given remittance, all the lines settled, in the "Settled" tab.
The very last step is to post those "Settled" lines.

Posting looks like:

(40100) Remittance Type - Sent Account DEBIT
(57200) Remittance type - Settlement Account CREDIT

(Payment) Remittance

Accounting staff must be able to remit purchase invoices for the bank to manage the payments on its due date.

For getting the above done:

Please note that it is possible to mix purchase invoices and orders in a remittance together with existing payments by selecting those payments through the process button "Select Payments".

End-user can select any purchase invoice, regardless its payment method by selecting the flag "Show payments for alternative payment methods"

End-user can select any purchase invoice, regardless its currency by selecting the flag “Show payments for alternative currencies”.
This is allowed only if the remittance payment method related to the remittance type and financial account being used allows making payments in other currency than financial account currency.

PaymentOut Remittance2.png

Once the corresponding purchase invoices have been selected, end-user must press the "Process" button.

After that Openbravo generates as many remittance lines as transactions selected, do not referred to any payment if remittance just includes orders and/or invoices, otherwise payment number is shown in "Payment" field.

PaymentOut Remittance3.png

Back to the "Remittance" window, end-user can press the header button "Process". Below list of actions can be taken:

PaymentOut Remittance4.png

Finally, the remittance can be "Post"

Posting looks like:

(40000) Vendor liabilities DEBIT
(40100) Remittance type - Sent Account CREDIT

In the case of a remittance including USD transactions (orders, invoices and or payments) the conversion rate (USD to EUR) to be used while posting the remittance to a General Ledger in EUR is:

(Payment) Remittance Print

It is possible to print a remittance by using the "Print" menu button.
Printed remittance can be sent to the bank for the bank to pay the vendors on purchase invoice due date, as shown in the image below:

PaymentOutRemittance Print.png

(Payment) Settle / Protest Remittance

Accounting Staff is able to later on either Settle or Protest "Remittance" lines by navigating to the "Settle / Protest Remittances" window.
Those payments which were paid on its due date must be settled and those payments which were not paid because of any reason, must be protested.

For doing that and once in the "Settle / Protest Remittances" window, the end-user needs to follow below steps:

Dated on July 30th 2015, all remittance lines but the one related to Vendor USA 2 can be settled.

End-user can select those lines one by one and enter 30-07-2015 as accounting date and press the button "Settle" each time.
Above lines will then be removed from the window one by one.

Settle Protest 01.png

Remittance line with due date July 20th 2015 was not paid, therefore must be protested:

End-user can select it, enter 30-07-2015 as accounting date and press the button "Protest" this time.
That line will then be removed from the window.

Settle Protest 02.png

Finally, it is possible to see the status of each payment belonging to a Remittance in the Remittance window.

In this case there will be 3 payments listed in the "Settled" tab of the Remittance window

Settled tab.png

and 1 payment listed in the "Protested" tab of the Remittance window.

Protested tab.png

End-user needs to post each of the ones settled, to get that the amount is booked to the Remittance Settlement Account.

Settlement posting of the remittance line related to Vendor USA for instance looks like:

1000.00 (XXXXX) Remittance type - Sent Account DEBIT
1000.00 (XXXXX) Remittance type - Settle Account CREDIT

950.00 (40100) Proveedores efectos comerciales DEBIT
800.00 (66800) Diferencias negativas de cambio DEBIT
1750.00 (57200) Bancos e instituciones de credito - CREDIT

The conversion rate used at the time of posting Vendor USA invoice was 0.95 USD/EUR. That conversion rate was manually entered in the "Exchange Rates" tab of the invoice window. A balance of 950.00 € was accounted as Accounts Payable.

The conversion rate used at the time of posting the remit of that invoice was as well 0.95, therefore a balance of 950.00 € was accounted also at that time.

The conversion rate used at the time of posting the settlement of that invoice/payment was July USD to EUR conversion rate, that is 1.75, therefore the amount booked at bank account turns into 1750.00.

Bank revaluation loss is also created as accounting entry to reflect the conversion rate change.

Settlement posting of the remittance line related to Vendor USA 2 (in USD currency) looks like:

Protest posting looks like:

5000.00 (XXXXX) Remittance type - Sent Account DEBIT
5000.00 (XXXXX) Vendor Liabilites CREDIT

6800.00 (40100) Proveedores efectos comerciasles DEBIT
6800.00 (40000) Proveedores CREDIT

The conversion rate used at the time of posting Vendor USA 2 invoice was 1.36 USD/EUR. That conversion rate is the one defined at system level at the time of invoice accounting (May 2015). A balance of 6800.00 € was accounted as Accounts Payable.

The conversion rate used at the time of posting the remit of that invoice was as well 1.36, therefore a balance of 6800.00 € was accounted also at that time.

The conversion rate used at the time of posting the protest (July) is the one used at the time of posting the invoice and the remittance, therefore a balance of 6800.00 is once again booked back as Accounts Payable in the credit.

(Payment) Remittance Redraw

Later on, by mid August, unpaid Vendor USA 2 invoice can be redraw to be paid ending August.

End-user could create a new "payment" remittance in order to remit once again the unpaid vendor invoice to the bank; this time the option "Select Payments" must be chosen instead of "Select Orders/Invoices", as shown in the screen below:

Select Payments 01.png

All payment outs having an "Awaiting Execution" status are shown.

PaymentOut Remittance Redraw.png

End-user can select Vendor USA 2 one and then process and post the remittance.

The payment out which had an "Awaiting Execution" status, will then change to a "Remitted" status.

once paid, end-user needs to navigate to "Settle / Protest Remittance" window and get that one remaining settled, payment status will the change to "Withdrawn not Cleared".

Finally, end-user needs to navigate to the Remittance window in order to post the settled remittance line.

(Payment) Remittance Write-off

The end-user is also able to either write-off an "Awaiting Execution" payment or to include it in an existing or new remittance in order to redraw it.

An "Awaiting Execution" payment in the case of remittance, is a protested payment which was included in a remittance.

For doing that end-user needs to execute the payment (in awaiting execution status) from the "Payment Out" window by clicking on the "Execute Payment" process button.
The system shows up two options:

  1. Write off total amount.
    1. this option must be selected in the case end-user needs to write-off the payment
    2. Write-off amount field of the payment will be then filled-in with the purchase invoice amount and the payment status will be changed to "Payment Made".
  2. Include in existing remittance or create a new one
    1. this option must be selected in the case end-user needs to remit the payment once more.
    2. In case of existing an open remittance of the same type, that payment will be included there, otherwise a new remittance will be created.

Single Payment Out Remittance

Accounting staff must be able to remit several purchase invoices or orders for the bank to manage the payments on its due date, by creating a single payment out.

For getting the above done:

End-user could also select any purchase invoice/order, regardless its payment method by selecting the flag "Show payments for alternative payment methods".

Once the corresponding purchase invoices have been selected, end-user must press the "Process" button. After that the system will generate and show in "Lines" tab as many lines as transactions selected, all of them linked to the same payment out number.

Back in the "Remittance" window, the end-user press the header button "Process", this time grouping options are not applicable at all.

It is possible for the accounting staff to print a single payment out remittance. Printed remittance will show a single transaction date and expected date for all the remittance lines, as shown in the image below:

PaymentOutRemittance SinglePayment.png

Please note that it is not possible to use "Single Payment" option in case of a remittance:

Sales Orders/Invoices & Payments In

Remittance for collection

Accounting staff must be able to remit sales invoices for the bank to manage to collect the money from the customers on sales invoice due date.

For getting the above done:

Please note that it should be possible to mix sales invoices and sales orders in a remittance, as well as payment in.

End-user can also select any sales invoice to be included in the remittance, regardless its payment method by selecting the check-box "Show payments for alternative payment methods", or its currency by selecting the check-box "Show payments for alternative currencies" whenever the payment method related to the remittance type allows to do so.

Select Orders or Invoices PaymentIn.png

Once the corresponding sales invoices have been selected, end-user must click on the "Process" button. After that the system will generate and show in the "Lines" tab as many lines as transactions selected.

Back in the "Remittance" window, the end-user press the header button "Process", once more it is possible:

Finally, the remittance can be "Post"

Posting looks like:

(43120) Remittance type - Sent Account DEBIT
(43000) Accounts Receivable CREDIT

In the case of a remittance including USD transactions (orders, invoices and or payments) the conversion rate (USD to EUR) to be used while posting the remittance to a General Ledger in EUR is:

Remittance for collection - Remittance Print

It is possible to print a remittance by using the "Print" menu button.
Printed remittance can be sent to the bank for the bank to manage the collection of the money from the customers on sales invoice due date, as shown in the image below:

Remittance Print PaymentIn.png

Remittance for collection - Remittance Settlement & Protest

Accounting Staff is able to later on either Settle or Protest "Remittance" lines by navigating to the "Settle / Protest Remittances" window.
Those collections which were paid on its due date must be settled and those collections which were not paid because of any reason, must be protested.

For doing that and once in the "Settle / Protest Remittances" window, the end-user needs to follow below steps:

Dated on August 20th 2015, the remittance line related to Alimentos y Supermercados customer was paid.

End-user can select this line, enter 20-08-2015 as accounting date and press the button "Settle". Above lines will then be removed from the window.

Settle Protest PaymentIn 01.png

However dated on August 20th, 2015 the remittance line related to Customer USA 2 which should have been paid dated on July 20th, 2015 is not paid.

End-user can select it, enter 20-08-2015 as accounting date and press the button "Protest". That line will then be removed from the window.

Settle Protest PaymentIn 02.png

Finally, it is possible to see the status of each payment beloging to a Remittance in the Remittance window.
In this case there will be 1 payment listed in the "Settled" tab of the Remittance window and 1 payment listed in the "Protested" tab of the Remittance window.

End-user needs to post settlement remittance line, to get that the amount is booked to the Remittance Settlement Account .

Settlement posting looks like

1089.00 (57200) Remittance Type - Settle Account DEBIT
1089.00 (43120) Remittance Type - Sent Account CREDIT

End-user needs to post the one protested, to get that the amount is booked back to the Accounts receivable account.

Protest posting looks like:

10000.00 (XXXXX) Account Receivable DEBIT
10000.00 (XXXXX) Remittance Type - Sent Account CREDIT

12500.00 (43000) Clientes - DEBIT
12500.00 (43120) Efectos comerciales en gestión de cobro - CREDIT

The conversion rate used is the one used while posting the corresponding Customer USA 2 invoice.

Accounting Logic for Remittance Protest

It has not been implemented yet an "automatic" accounting logic for Remittance Protest.

End-user will have to manually create that kind of posting by using a GL Journal.
Posting will look like as shown below:

Manual booking after a "Remittance Protest", for a given amount :
(43150) Protest Remittance DEBIT
(43000) Account Receivable CREDIT


Manual booking before a "Remittance Protest" redraw, for a given amount :
(43000) Account Receivable DEBIT
(43150) Protest Remittance CREDIT

Remittance for collection - Redraw & Write off

Later on, by mid August, unpaid Customer USA 2 invoice can be redraw to be paid ending August.

Remittance Redraw:

End-user can create a new "collection" remittance in order to remit once again the unpaid sales invoice.

It is also possible to redraw payments with status "payment received" and/ or "awaiting execution"

This time the option "Select Payments" must be chosen instead of "Select Orders/Invoices" as shown in the screen below:

Remittance Redraw PaymentIn 01.png


Remittance Redraw PaymentIn 02.png

Then, the new remittance needs to be processed and posted, that implies that the Payment In, previously generated which currently has an "Awaiting Execution" or "Payment Received" status, will then change to "Remitted".

Redraw posting looks like:

10000.00 (XXXXX) Remittance Type - Sent Account (DEBIT)
10000.00 (XXXXX) Account Receivable (CREDIT)

12500.00 (43120) Efectos comerciales en gestión de cobro - DEBIT 12500.00 (43000) Clientes - CREDIT

The conversion rate used while posting is the valid one at Customer USA 2 invoice accounting date.

After that, end-user needs to navigate to "Settle / Protest Remittance" window and get that one settled, payment status will change then to "Deposit not Cleared".

Finally, end-user needs to navigate to the Remittance window in order to post remittance settlement.


Redraw or Write-off

The end-user is also able to either write-off an "Awaiting Execution" Payment In, or to include it in an existing or new remittance in order to redraw it.

An "Awaiting Execution" payment in, in the case of remittances, is a protested payment in which was included in a collection remittance.

For doing that end-user needs to execute the payment (in awaiting execution status) from the "Payment In" window by clicking on the "Execute Payment" process button.
The system shows up two options:

  1. Write off total amount.
    1. this option must be selected in the case end-user needs to write-off the payment in
    2. Write-off amount field of the payment will be then filled-in with the sales invoice amount and the payment in status will be changed to "Payment Made".
  2. Include in existing remittance or create a new one
    1. this option must be selected in the case end-user needs to remit the payment in once more.
    2. In case of existing an open remittance of the same type, that payment in will be included there, otherwise a new remittance will be created.

Remittance for discount

Accounting staff must be able to remit sales invoices for the bank to manage to collect the money from the customers before due date.

For getting the above done:

Note that it should be possible to mix sales invoices and sales orders in a remittance, as well as payments.

End-user could also select any sales invoice, regardless its payment method by selecting the flag "Show payments for alternative payment methods". Besides that, end-user can also select any sales invoice, regardless its currency, by selecting the flag "Show payments for alternative currencies", whenever payment method related to remittance type allows to do so.

PaymentIn Select Orders or Invoices.png

Once the corresponding sales invoices have been selected, end-user must click on the "Process" button.
After that the system will generate and show in the "Lines" tab as many lines as transactions selected.

Back in the "Remittance" window, the end-user press the header button "Process", once more it is possible:

Back in the Remittance window, another "Payment In" is also shown in the "Remittance" header.

Discount Payment.png

This payment is the "Discount Payment" dated on August 15th, 2015.
This payment can be post to the ledger from the "Payment In" window.

Discount Payment posting looks like:

For F&B España Euro:

81920,90 (57200) Banco e instituciones de crédito - DEBIT
81920,90 (52080) Deudas por efectos descontados - CREDIT

Above amount is the sum of 79120,90 € + (1600.00 USD * 1.75 USD/€)

1.75 USD/€ is the conversion rate valid at accounting discount date (15-08-2015)

For F&B International Group Dollar:

46811,98 (XXXX) Bank Payment Method - Upon Receipt Use account or Upon Deposit Use account DEBIT
(*) 46811,98 (XXXXX) Remittance Type - G/L item account CREDIT

Above amount is the sup of 1600,00 USD + 79120,90 € * 0,571429 €/USD)

0,571429 €/USD is the conversion rate valid at accounting discount date (15-08-2015)

(*) Above posting would depend on how the "Discount" Payment Method has been setup. For more information take a look into the "Configuration Manual".

Finally, remittance can be post to the ledger.

Remittance posting looks like:

For F&B España Euro:

80400.90 (43110) Efectos comerciales descontados - DEBIT
80400.90 (43000) Clientes - CREDIT

Above amount is the sum of 79120,90 € + (1600.00 USD * 0.8 USD/€)

0.8 USD/€ is the conversion rate valid at invoice accounting date

For F&B International Group Dollar:

52318.55 (XXXXX) Remittance Type - Sent Account DEBIT
52318.55 (XXXXX) Account Receivables CREDIT

Above amount is the sup of 1600,00 USD + (79120,90 € * 0.641026 €/USD)

0.641026 €/USD is the conversion rate valid at invoice accounting date

Bank fees accounting

At the end of the day the money get from the bank will be less than the remittance for discount total amount.
For doing so, Peter will have to book the corresponding "Fee" in the Financial Account used for the remittance discount.
Those "Fees" will have to be added as a new transaction in the "Financial Account", as described below:

Fees posting looks like:

150,00 Financial Account - Bank Fee Account DEBIT
150,00 Financial Account - Withdrawal Account CREDIT

Once we do have the corresponding bank statement line to match, it will be possible to match that single bank statement line with both the remittance payment and the fee by using bank statement split feature.

Remittance for discount - Remittance print

It is possible to print a remittance by using the "Print" menu button.
Printed remittance can be sent to the bank for the bank to manage the collection of the money from the customers on the given discount date, as shown in the image below:

Discount Remittance Print.png

Remittance for discount - Remittance Settement & Protest

Accounting Staff is able to later on either Settle or Protest "Remittance" lines by navigating to the "Settle / Protest Remittances" window.
Those collections which were final paid must be settled and those collections which were not paid for any reason, must be protested.

For doing that and once in the "Settle / Protest Remittances" window, the end-user needs to follow below steps:

Dated on August 25th 2015, the remittance line for Customer USA was collected; and therefore can be settled

End-user can select it, enter 25-08-2015 as accounting date and press the button "Settle". Above lines will then be removed from the window.

Dated on August 30th 2015, the remittance line for Restaurantes Luna Llena was finally not collected; and therefore must be protested.

End-user can select it, enter 30-08-2015 as accounting date and press the button "Protest". That line will then be removed from the window.

It is possible to see the status of each payment belonging to a Remittance in the Remittance window.
In this case there will be 1 payment listed in the "Settled" tab of the Remittance window and 1 payment listed in the "Protested" tab of the Remittance window.

End-user needs to post the one settled, to get that the amount is booked to the Remittance Settlement Account.

Settlement posting looks like:

For F&B International Group US Dollar general ledger

1600.00 (XXXXX) Remittance type - G/L item account DEBIT
1600.00 (XXXXX) Remittance Type - Sent Account CREDIT


For F&B España Euro general ledger

2800.00 (52080) Deudas por efectos descontados DEBIT
1280.00 (43110) Efectos comerciales descontados CREDIT
1520.00 (76800) Diferencias positivas de cambio CREDIT

The amount in the debit is 1600.00 USD * 1.75 USD/€ (conversion rate valid at 25-08-2015)

The first amount in the debit is 1600.00 USD * 0.8 USD/€ (conversion rate valid at invoice accounting date)

The second amount in the debit is the bank revaluation gain accounting caused by the conversion rate change.

End-user needs to post the one protested, to get that the amount is booked back to the Account Receivables account.

Protest posting looks like:

For F&B España Euro general ledger

79120.90 (43000) Clientes DEBIT
79120.90 (43110) Efectos comerciales descontados

For F&B International Group US Dollar general ledger

50718.55 (XXXXX) Account Receivable DEBIT
50718.55 (XXXXX) Remittance Type - Sent Account CREDIT

The amount protested in USD is 79120,90 € * 0.641026 €/USD (that is the conversion rate valid at invoice accounting date)


Finally, it is also required to create a new "Payment Out" for the unpaid Payment In amount, as the bank did paid it to us on the discount date:

For doing that the end-user needs to navigate to the Financial Account window.
Once there find the Financial Account used for the Remittance for Discount, and then add a new transaction by using a GL item as described below:

The posting will look like:

(52080) Remittance type - G/L item account DEBIT
(57200) Financial Account - Withdrawal Account CREDIT

Accounting Logic for Remittance Protest

It has not been implemented yet an "automatic" accounting logic for Remittance Protest.

End-user will have to manually create that kind of posting by using a GL Journal.
Posting will look like as shown below:

Manual booking after a "Remittance Protest", for a given amount :
(43150) Protest Remittance DEBIT
(43000) Account Receivable CREDIT

Manual booking before a "Remittance Protest" redraw, for a given amount :
(43000) Account Receivable DEBIT
(43150) Protest Remittance CREDIT

Remittance for discount - Redraw & Write-off

Later on, by mid September, it is possible to collect the money from the Customer which did not paid.

Remittance Redraw:

End-user could create a new "collection" remittance in order to remit to the bank once again the unpaid sales invoice; this time the option "Select Payments" must be chosen instead of "Select Orders/Invoices".

Then, the new remittance needs to be processed and posted, that implies that the Payment In, previously generated which currently has "Awaiting Execution" status, will then change to "Remitted".

PaymentIn Redraw.png

Redraw posting looks like:

For F&B España Euro general ledger

79120.90 (43110) Efectos comerciales descontados DEBIT
79120.90 (43000) Clientes CREDIT

For F&B International Group US Dollar general ledger

50718.55 (XXXXX) Remittance Type - Sent Account DEBIT
50718.55 (XXXXX) Account Receivable DEBIT

The amount once again remitted in USD is 79120,90 € * 0.641026 €/USD (that is the conversion rate valid at invoice accounting date)

After that, end-user needs to navigate to "Settle / Protest Remittance" window and get that one settled, payment status will change then to "Deposit not Cleared".

Finally, end-user needs to navigate to the Remittance window in order to post the settled remittance.


Redraw or Write-off

The end-user is also able to either write-off an "Awaiting Execution" Payment In, or to include it in an existing or new remittance in order to redraw it.

An "Awaiting Execution" payment in, in the case of remittances, is a protested payment in which was included in a discount remittance.

For doing that end-user needs to execute the payment (in awaiting execution status) from the "Payment In" window by clicking on the "Execute Payment" process button.
The system shows up two options:

  1. Write off total amount.
    1. this option must be selected in the case end-user needs to write-off the payment in
    2. Write-off amount field of the payment will be then filled-in with the sales invoice amount and the payment in status will be changed to "Payment Made".
  2. Include in existing remittance or create a new one
    1. this option must be selected in the case end-user needs to remit the payment in once more.
    2. In case of existing an open remittance of the same type, that payment in will be included there, otherwise a new remittance will be created.

Single Payment In Remittance

Accounting staff must be able to remit sales invoices for the bank to manage to collect the money from the customers on its expected date (due date); and in a single payment.

For getting the above done:

End-user could also select any sales invoice/order, regardless its payment method by selecting the flag "Show payments for alternative payment methods".

Please note that this option does not work while mixing transactions in different currencies. In other words, it is not possible to create a remittance single payment if remittance lines currency is not the same.

Once the corresponding sales invoices have been selected, end-user must press the "Process" button. After that the system will generate and show in the "Lines" tab as many lines as transactions selected, all of them linked to the same payment in, which in our example is the payment in nº 400148.

SinglePaymentIn.png

Back in the "Remittance" window, the end-user press the header button "Process", this time grouping options are not applicable at all.

Finally, the remittance must be posted.

Posting looks like:

28.897,36 (43120) Remittance Type - Sent Account DEBIT
28.897,36 (43000) Account Receivables CREDIT

It should be possible for the accounting staff to print a single payment out remittance. Printed remittance will show a single transaction date for the payment out, as shown in the image below:

SinglePaymentIn Print.png

Promissory note In Remittance

Accounting staff must be able to remit a promissory note for the bank which previously has been deposited in a "cash drawer" (Financial account)

The payment should have been set up, as shown in the screen below:

Rem3.png

End-user could also select the payment, regardless its payment method and financial account in witch the promissory note has been deposited by clearing the implicit filters applied (by clicking in the funnel icon.)

As shown in the screen below:

Rem4.png]

Invoice Paid Status Control with Remittances

Invoice Paid Status Control provide a configuration option to be able to decide which status for each payment determines that an invoice is paid or not.

For additional information about it, visit the wiki article: How to Configure Invoice Paid Status Control.

Overall invoice paid status deposit not cleared is the payment status considered as the one that sets sales invoices as paid.

Same way, invoice paid status withdrawn not cleared is the payment status considered as the one that sets purchase invoices as paid.

However, while using Remittances as payment method, the invoice is not considered paid until the remittance is settled.

To get the above working Remittance Payment Method, for instance "Payment In Remittance", needs to be related to the corresponding Financial Account and then configured
as shown in the screen below:

Invoice Paid Status PaymentInRemittance.png

For instance, a sales invoice booked and paid by using "Check" as payment method for instance, gets a "Payment Received" payment status.

At that point the sales invoice is not considered as paid.

Unpaid SalesInvoice.png

A new remittance is created to remit above created payment, by entering below information:

Invoice Paid Status Remittance 01.png

After that the end-user must press the button "Select Payments"

When the remittance is processed, the invoice is not set as paid.

When the remittance is settled, the invoice is set as paid.

Invoice Paid.png

Retrieved from "http://wiki.openbravo.com/wiki/Projects:Remittances/User_Documentation"

This page has been accessed 13,036 times. This page was last modified on 21 July 2015, at 10:32. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.