Refer to documentation Implementation
Presentation
This is the bank assigned to the payments to be processed and thus the bank where the doubtful entries are posted.
The processing of doubtful entries can only be carried out on one bank at a time in the original payment currency.
This is the accounting date that is given to accounting entries created by the process. By default, this field is initialized with the current date.
You can enter a description specific to a doubtful receipt or keep the one suggested by default (BANK doubtful receipt on ACCOUNTING DATE).
You can manually enter a payment number. A selection screen (called by the contextual menu) is used to suggest a group of payments corresponding to the defined criteria.
The selection proposed is made based on the following criteria:
The Bank field in the selection screen is automatically initialized because only the payments recorded for the bank defined in the header can be processed.
Define the doubtful receipt reason here. All the possible reasons are defined in miscellaneous table no. 310 and are represented by their own numeric code.
You can enter a description on the line. The header description is used by default at the line.
This field depends on the DCLVATPAY - VAT on collections parameter (CPT chapter, VAT group):
If the field RTZ declared sales tax is set to Yes, then behaviors are the following:
If the check is submitted to collection, it is assigned on entry to a payment entered as doubtful:
If the field RTZ declared sales tax is set to No, then behaviors are the following:
This defines if the customer is doubtful or not. This information has an impact on the account types that will be used at the time of posting the doubtful receipt entry.
According to whether the company manages or not VAT on collections (DCLVATPAY parameter), the fact that the customer is considered as doubtful or not, leads to different matching behavior (see Introduction).
Enter the amount of expenses generated by the doubtful receipt. The amount is expressed in the currency displayed in the header (bank currency).
If the expenses are expressed in a currency different from the payment, two entries are generated in accounting:
If the cost account is analytically tracked the posting fields must be entered.
In addition, the charges can be generated either in the doubtful receipt entry or a separate entry based on the value of the TAXUNPAY - Unpaid items on distinct entry parameter (TRS chapter, UNP group).
The doubtful receipt entry expenses are subject to VAT. It is therefore necessary to define the appropriate tax code. The VAT amount is automatically calculated.
The Re-invoicing field is used to determine whether the doubtful receipt expenses are allocated to the BP or to the company. This information also has an impact on the doubtful receipt posting: doubtful receipt expenses are posted (or not) as a charge for the company. If doubtful receipt expenses are charged to the customer, these expenses can be subject to an automatic re-invoicing by creating a customer BP invoice.
This customer BP invoice is created automatically with:
This customer BP invoice can then be posted to accounting or deleted.
If the expenses are analytically tracked, define the analytical allocation linked to the expense.
You can define the due date for the journal entries generated by the process.
Close
Fields
The following fields are present on this tab :
Block number 1
| Code of the bank for which the doubtful receipts and the bank charges are posted. |
| Posting date of all the accounting documents that will be generated from doubtful receipts entered in the grid. The date of the current day is suggested. |
Block number 2
|   |
| Header description of the accounting entries that are generated from the entry of doubtful receipts. This description is repeated in the lines description of the doubtful receipts entries. |
Grid Details
| It is possible to manually enter a payment number. A selection screen (called by the contextual menu) is used to propose a group of payments corresponding to defined criteria. The selection proposed is made based on the following criteria:
|
| Doubtful receipt reason to chose in the list. |
| Description for each line of the entry generated when the payment is unpaid. You can enter a description specific to doubtful receipts or keep the one suggested by default (Doubtful receipt entry BANK for ACCOUNTING DATE). |
| This field depends on the DCLVATPAY - VAT on collections parameter (CPT chapter, VAT group):
If this field is set to Yes, then behaviors are the following:
If the check is submitted to collection, it is assigned on entry to a payment entered as doubtful:
If this field is set to No, then behaviors are the following:
|
| The doubtful receipt entry is posted on the customer account if this field is set to No, or on the "doubtful customer" control account if the field is set to Yes. This information has an impact on the account types that will be used at the time of posting the doubtful receipt entry.
The behavior for the matching is different depending on whether the company manages the VAT on collections (DCLVATPAY parameter) and whether the customer is considered as doubtful. |
| This is the amount of charges invoiced by the bank and caused by a doubtful receipt entry or unpaid items. The amount is expressed in the currency displayed in the header (bank currency). If the charges are expressed in a different currency to the payment, two entries are generated in accounting:
If the cost account is analytically tracked the posting fields must be entered. Charges can either be generated:
|
| VAT code that will be applied to the charges. Entering this field is mandatory if charges have been recorded. |
| Amount of the VTA on the charges. This field is calculated but can be modified. |
| This field is used to define whether the unpaid charges are allocated to the BP or the company. The values of this field are as follows: No
Yes
|
The setup determines if the analytical dimensions can be modified. They are initialized based on the setup of the default dimension.
In creation mode, as in modification mode, if an order line is entered and the project code is modified, the analytical dimensions are not reset. |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |
Block number 4
| Due date of all the generated accounting entries. The due date of the payment that has been entered first in the grid is suggested. |
Close
The matching and unmatching process executed during doubtful receipt entry relies on information entered in Payment receipt/entry (GESPAY) in the Allocations grid. This applies to companies whether they are managing VAT on payments or not. That is, the DCLVATPAY – Manage VAT on collections parameter (CPT chapter, VAT group) is set to Yes or No and the RTZ of declared sales tax field is Yes or No.
A payment is entered and matched to an invoice, INV01. Then, the payment and invoice can be unmatched using the Manual matching (LETTRAGE) or Unmatching (DELETTRAGE) functions. Finally, the payment is matched to a different invoice, INV02. The doubtful receipt entry process considers information stored in Payment receipt/entry (GESPAY), that is to say INV01. Therefore, the matching/unmatching process then executed cannot work as described for standard use cases.
In addition to the generic error messages, the following messages can appear during the entry :
The user profile does not authorize access to the Doubtful receipt entry function for the selected bank.
The user does not have access rights.
The entered bank does not exist. You have to create the bank.
This payment number cannot be found in the PAYMENTH file.
The payment has already been entered in the grid.
The payment has already generated a doubtful receipt entry.
The payment must be processed in one of the three stages (cash management, intermediate deposit, bank deposit) to be entered as a doubtful receipt.
A different bank to that entered on the screen has been assigned to the payment.
The BP entered is not a customer.
If the charges are posted, it is necessary to enter the VAT code to be applied.
You do not have access to the payments carried out for this site.
The account entry related to the payment does not exist. It has been deleted or the entry number is incorrect.