The process for processing payments received in advance may vary based on your settings (internal processes). Individual processing procedures can also be combined with each other. The documentation describes the basic processing procedures:
Generate Prepayment from Payment Journal
Tax documents generated immediately
Tax documents generated deferred – individually or in bulk by batch job
Generating Payment Ahead Retrospectively Based on Balance Payment Settlement
Generating Payment Ahead Retrospectively Without Applying Payment
Payment Journal
The payment journal is used to pre-process data from the statement, identify the counterparty (who sent the payment) and the purpose of the payment (to which receivable the payment relates). Process the payment journal in the usual way so that the correct customer is filled in for the payments received and the payment is settled (if possible) with the open Customer Ledger Entries.
The system identifies and marks payments in advance according to the Record as Payment Ahead setting (Sales and Receivables Setup):
Only Leveled
Identification is triggered:
when applying a payment on a journal line (that is, when inserting the Applies-to Document Number)
when applying in the Apply Customer Ledger Entries window (i.e. with filling in the Applies-to ID), after closing the window by clicking the OK button.
The system determines the payment in advance according to any settled sales invoice (the document must exist in the list of Posted Sales Invoices) - meeting the conditions of payment in advance.
All for Customer
A payment that is not settled and Account Type = Customer will be automatically marked as a payment in advance at the time the customer number is filled in;
For a payment that will be settled, the identification of the payment ahead will be triggered when the Applies-to Document No. or Applies-to ID is filled in. A prepayment is identified if at least one document that is applied to this payment is a sales invoice that meets the conditions for determining a prepayment.
If the payment is only partially settled and there is an overpayment (the payment balance is greater than the allowed payment variance) and Payment ahead has not been indicated according to the settlement, the journal line is also marked as a payment in advance.
If the payment is identified as a payment in advance, the Generate payment in advance flag is set and the following flags are set according to other settings:
Generate invoice for prepayment immediately,
Don't charge a tax invoice for a prepayment.
You can then manually change these flags on the journal line.
A tax document for a prepayment is always created only for the entire payment. If the payment is mass and only part of the received payment is to be taxed, the payment in the journal must be divided into partial payments.
Combination of settings for the resulting marking of payment ahead and the use of the customer's posting group:
Sales & Receivables Setup | Payment Journal | ||||
Payment Billing Method | Mark as Payment Ahead | OUTSTANDING PAYMENTS or REGULAR PAYMENTS Partially Settled | PAYMENTS AHEAD (fully and partially) | ||
Účto sk. | Generate | Účto sk. | Generate | ||
Common Payment | Only Leveled | TUZ | No | TUZ_P | Yes |
Common Payment | All for Customer | TUZ_P | Yes | TUZ_P | Yes |
Payment Ahead | Only Leveled | TUZ_P | No | TUZ_P | Yes |
Payment Ahead | All for Customer | TUZ_P | Yes | TUZ_P | Yes |
New Payment Ahead Fields
For payments received in advance, the journal is extended with three new fields that are available on the journal line when the module is turned on (Allow creating payment ahead = Yes):
Generate Prepayment
This flag specifies that the payment will be Registered in the Payments Ahead module. Automatic marking of the payment on the journal line follows the rules of payment ahead identification - the settlement status of the line using other settings from the Sales and Receivables Setup (Create Payment Ahead by Period and Record as Payment Prepayment).
Before the journal is posted, this flag can be turned on or off manually. If the flag is checked, a Customer Posting group with the Use for Payments Ahead flag = Yes is required for payment.
Generate Prepayment Invoice Immediately
This flag specifies that a tax document will be generated for the registered Payment Ahead immediately When posting a payment in the Payment Journal. The flag is turned on by the system based on the setting in the Sales & Receivables Setup in the Generate Prepayment Invoice Immediately field
Before the journal is posted, this flag can be turned on or off manually. If the flag is turned off and the creation of a tax document is not blocked, the tax document will be generated additionally by a batch job.
Dont Charge VAT for Payment Ahead
This flag specifies that a tax invoice will never be generated for Prepayment. In the journal, this flag can be turned on manually. In addition, the flag can also be set by the system in the background when posting the journal, based on the settings in the VAT business posting group or in the customer's Posting group
Applying Payments in a Journal
Adjustment of applying date
By default, it is possible to settle payments in the Payment Journal only with customer entries whose Posting date is the same or lower than the Posting date of payment. If the Prepayments module is enabled, the system will allow you to select a Customer Ledger Entry with Higher Posting date than the payment date, and then post this settlement.
Payment applied with one entry
The payment can be applied manually by selecting the document (Customer Ledger Entry) on the journal line. During settlement, the system evaluates whether the conditions for generating Payment Ahead are met and, if so, sets the Generate Payment Ahead flag.
Payment applied with multiple entries
To apply multiple entries with one payment, you must use the Apply Entries function.
Marked items must be positive (same adjustment as on the customer's balance, See Chap. 7.5.2.1 Check for signs of applied entries). The signs of the applied entries are checked when the payment is posted. Example of an error message when this rule is violated:
During settlement, the system evaluates whether the conditions for generating Payment Ahead are met for at least one item, and if so, it sets the Generate Payment Ahead flag.
Unapplying of payment ahead (Unapplying of payment ahead)
If a payment has been flagged with Generate Payment Ahead = Yes and a settlement has been made, then the function to identify the payment ahead is restarted when the settlement is deleted or changed (Applies-to Document Numbers or Applies-to IDs). Same when deleting or changing a customer number. The flags are revised and set according to the current state.
Splitting a mass payment
A mass payment can be split using the Split payment by to Applying See Chap. 6.3.6. Split payment in Payment Journal. When splitting a payment, the system evaluates whether the conditions for generating Payment Ahead are met for individual items and if so, it sets the Generate Payment Ahead flag on individual partial payments.
Customer Posting Group in Journal
Default customer posting group
The following is important for the payment to be posted. Customer Posting Group filled in the Payment Journal. The system fills in the customer posting group when creating a journal line after filling it in Customer Numbers, using either the default posting group from the Customer Card (e.g. for receivables account = 311.AU) or its substitute posting group for advance payments (e.g. for accounts receivable = 324.AU). When choosing a posting group, the settings are important Payment Posting Method in Sales & Receivables Setup. At the same time, the system also takes into account whether the Generate prepayment flag is enabled on the line.
Customer posting group from applied entry
If a payment on a journal line is settled, the default customer posting group can be automatically replaced with the customer posting group from the applied entry when it is settled.
If one or more items are associated with a payment and at least one of them meets the conditions for prepayment, then the system marks the payment with the Generate Payment Ahead flag and uses the Customer Posting Group specified for Prepayment.
If there is a change in the settlement or customer on the payment, the posting group on the payment line may change:
When changing a customer, the settlement is deleted and the customer's posting group is set according to Sales & Receivables Setup
When a customer is deleted, the settlement is deleted, but the customer's posting group remains unchanged (BC standard)
When a settlement is changed, the posting group is updated according to the new settlement
When deleting a settlement, the customer's posting group is set up according to Sales and Receivables Setup
Posting a payment journal
Posting of payment journal
As soon as the journal is ready for posting (customers, vendors, or G/L accounts are assigned, payments are settled as far as possible, and advance payments have flags set), you can post the journal.
Posting of applying
If the Payments Ahead module is disabled, the system will not allow you to settle with the payment of a customer item with a higher Posting date. When posting, all posted items have the highest date of the applied items, i.e. the payment date.
If the Prepayments module is enabled and a customer entry with a higher Posting Date than the payment date is matched to the received payment, the system will allow this settlement to be posted, but when posting Changes Posting Date Item transactions:
equalization
Payment Variances
exchange rate differences
This is accomplished by "deferred" payment matching up to the customer balance as part of a payment journal line posting transaction. With this two-phase posting, which is triggered on the condition that:
the Prepayments module is turned on
Account Type or Trade-in Type is Customer
There is an application on the journal line (either Applies-to Document No. or Applies-to ID
It divides the accounting system into two phases:
Post a payment without settlement, and
Subsequent settlement of the payment on the balance with entries that have been selected and marked for settlement in the journal.
An entry that is posted in a journal (Payment) is always populated in the settlement header when you use the balance settlement function.
Thus, the posted payment will have the Posting date taken from the journal, while the settlement (i.e. detailed customer entries of the Settlement type) and the associated payment deviations, exchange rate differences, etc., will have the Posting date taken from the forward-settled invoice.
Notification:
BC Standard: If multiple entries are matched (1:N), the system uses the highest Posting date from the set of entries entering the settlement for settlement.
Therefore, for the correct Payment Ahead settlement date (if the invoices have different Posting Dates), it is necessary to either split the mass payment and match partial payments separately, or post the payment without matching and apply it manually to the balance, or use the Apply Customer Ledger Entries task.
Posted General Journal (Posted general journal)
After you post the Payment Journal, the journal is deleted. If Copy to Posted General Journal = Yes is set on the journal batch, the posted lines are copied to the Posted General Journal, including the new fields Generate Prepayment, Generate Prepayment Invoice Immediately, and Don't Post Invoice for Prepayment.
When a posted line is copied back to the live journal, the line is copied with the listed flags.
Overview of Payments Ahead
If the Generate prepayment flag was checked in the journal on the posted payment, a record of the Payment type was created in the Payments Ahead record.
To view all generated Prepayments, search for Overview of Payments Ahead. You can display the card of a specific Payment Ahead by clicking on the Item number or by clicking on the View button.
A description of the Payments in advance card can be found in the https://iao.atlassian.net/wiki/spaces/OCDOC/pages/77889537/Payment_Ahead_Agenda#Payment-in-advance
Tax documents for prepayment
Tax invoices for Payment Ahead
If the flag Generate invoice for prepayment immediately was checked on the payment in the journal and the creation of the tax document was not suppressed (either manually by the user in the journal or by the system in the background when posting the payment, or when creating the Payment in advance header), a tax document was generated whose number is filled in the Tax document number for received payment field. You can view this document by clicking on the Tax Invoice button or by clicking on the Tax Invoice No. for Received Payment.
Tax invoices generated additionally
If the Generate invoice for prepayment immediately flag is not checked on the payment journal and the creation of the tax document is not suppressed, the tax document is not generated, but the Generate documents and Generate tax document flags are selected on the Prepayment journal.
For these Prepayments, it is possible to generate a tax document additionally:
either individually manually from the Payments Ahead tab using the Action button > Post Invoice,
or Batch Job in Bulk Generated Tax Documents and Credit Memos for Payments Aheadsee https://iao.atlassian.net/wiki/spaces/OCDOC/pages/77660232/Processing+Of+The+Received+Invoice#Generate-Tax-Documents-for-Payment-Ahead-batch-job
or the system generates them automatically in the background when you post any general journal or when you post settlement on the balance. if a prepayment was generated during this posting (applies to already existing Payments in advance with flag Generate Prepayment Invoice Immediately = Yes)
After the tax document is generated, the document number is entered on Payment in advance and the Generate documents and Generate tax invoice for received payment flags are deleted.
Tax document corrections
Generated Prepayment Invoice Cannot use standard features Neither to cancel nor to create a credit memo for them:
An issued tax document can only be cancelled Settlement Customer Ledger Entries (payments), which automatically generates a prepayment tax credit memo.
Prepayment Tax Credit Memos
Tax credit memos generated immediately
If a payment in the Payment Journal has been settled with one or more invoices, Usage records will be created for that Payment in advance at the same time. At the same time, if the Sales & Receivables Setup sets up that tax credit memos should be generated immediately and a tax invoice for prepayment has already been generated, the system generates a tax credit memo whose number is entered in the Prepayment Credit Memo No. field. You can view this document by clicking on the Tax Credit Memo button or by clicking on Credit Memo Number.
Tax credit memos generated additionally
If the Sales & Receivables Setup set Generate Prepayment Credit Memo immediately = No or the tax document has not yet been generated (flag on Prepayment payment type is Generate Prepayment Invoice = Yes), a tax credit memo will not be generated during settlement, but the Generate Documents and Generate Prepayment Credit Memo flags will be checked on Prepayment of the Usage type.
For these Prepayment Usages, it is possible to generate a tax credit memo additionally:
either individually manually from the Payments Ahead tab using the Action button > Post Credit Memo,
or Batch Job in Bulk Generate Tax Documents and Credit Memos for Payment Ahead, see Chap. https://iao.atlassian.net/wiki/spaces/OCDOC/pages/77660232/Processing+Of+The+Received+Invoice#Generate-Tax-Documents-for-Payment-Ahead-batch-job
or the system generates them automatically in the background when you post any general journal or when you post settlement on the balance. if an advance payment was generated during this posting (applies to already existing Payments in advance with flag Generate Tax Credit Memo for Payment Ahead Immediately = Yes)
A tax credit memo that is posted manually from the Payments Ahead card of the Usage type.
When a tax credit memo is generated, the credit memo number is written on Prepayment and the Generate Documents and Generate Prepayment Credit Memo flags are deleted
View Payment Ahead from a Customer Ledger Entry
After posting a payment with the Generate Prepayment flag, a Customer Ledger Entry that is flagged is created on the customer's balance Payment in advance.
From this item, you can then view the Payment in advance (Payment + all related Usages) by clicking on the Prepayment.
Apply a payment manually to a balance
The standard Apply Entries function is used to apply Customer Ledger Entries.
If the Prepayments module is turned on, the following adjustments are activated on the customer's balance:
Check the signs of applied items
Check the same currency in settlement (see Sales and Receivables Setup)
Generate tax documents and tax credit memos for existing Payments Ahead
Reverse generation of Payments Ahead when applying a payment, if the conditions for their creation are met
Check the signs of applied items
If the Payments Ahead module is active, the matching is limited so that only items with the opposite sign can be matched to the applying entry in the settlement header (by default, multiple positive and multiple negative items can be settled in one transaction in BC). The system checks for signs when posting settlements or in the settlement posting preview.
Same Currency Check
Due to the possibility to generate advance payments retrospectively, even if the payment has already been partially settled with an invoice that does not meet the conditions for prepayment, the system will not allow you to apply customer ledger entries in different currencies after the module is turned on. The system checks the settings – if the Payments Ahead module is enabled, the set must be Currency Applies=None.
Settlement on Balance – Payment in advance exists
If a payment with the Generate prepayment flag was posted in the Payment Journal that was not settled, or was only partially settled, you can apply this payment manually to the balance using the standard function Apply Entries.
In the settlement lines, you select the invoice (one or more) that the payment should be applied to, and you mark the line in the Applies-to ID field.
When applying, the check for the sign of the amount must be satisfied.
Post the settlement. Before posting, you can check in the Posting Preview to see if a tax credit memo will be created (a VAT entry and general ledger entries for the tax credit memo are created).
After the settlement is posted, a new record of the Usage type is generated in the Payments Ahead record.
A Prepayment Tax Credit Note is generated for this record, depending on the setting, either immediately or deferred. The condition for generating a credit note is that a Tax Invoice for Payment Ahead has already been generated. A tax credit memo is never generated if the generation of a tax document has been blocked (e.g. by setting it to a VAT business posting group).
Payment Tolerances
A record of the Usage type and the corresponding credit note are generated in the settlement amount. If a payment difference was applied during payment settlement, which closes the payment on the balance, this variance is added to the credit memo so that the sum of the Usage records matches the amount of the advance payment received.
VAT Reporting Date of created Tax Credit Memo
The created tax credit memo will use the Date of VAT earned when the payment was settled:
When a payment is applied to an invoice that has a header (Posted Sales Invoice) and its VAT Date is higher than the Posting Date of Payment, the VAT Date from the invoice header is used
In all other cases, the Settlement Posting Date is used
Balance Settlement – Payment in advance does not exist
If the received payment was posted to the customer's balance, but Payment ahead was not generated (in the Payment Journal it was Generate payment ahead = No), it is possible to do so under certain conditions. Conditions Generate the prepayment additionally, after the payment is settled on the balance:
The payment must have a Customer Posting Group specified for Payments Ahead (Use for Payments Ahead = Yes)
The payment must be applied to an entry of the Invoice type (the header document Posted Sales Invoice exists). When applying to a different type of entry (Blank or Refund) or to an invoice posted in a journal, Prepayment is not generated
The VAT date of the settled invoice must be before the payment date. Depending on the settings, either whole months or individual days are tested (Create Payment in Advance by Period = Yes/No)
For a mass payment settled with multiple invoices, at least one settled invoice must meet the above conditions.
When a payment is partially settled, if the conditions are met, a Payment Ahead is generated for the full amount of the payment received.
Notification:
If an application of customer ledger entries is posted, when a new Prepayment is generated as part of the settlement, the system then runs in the background Generating Tax Documents and Tax Credit Memos,
And that's for all existing Payments Ahead that are waiting for tax documents/credit notes to be generated and at the same time have the "generate" flagimmediately“!
Example of Payment Ahead Reverse Generation – 1:1 Settlement of Payment with Invoice
There are two Customer Entries ready for settlement that meet the conditions for retrospective generation of Payment Prepayment. Payment in advance has not yet been generated (on the Customer Ledger Entry see the field Payment in advance = No).
Apply items with the standard Apply Entries function.
Note: To regenerate Payment Forward, the selection of an item in the settlement header does not matter, both payment and invoice can be selected in the header. However, if a payment variance is to be used in the settlement, the payment (BC standard) must be placed in the settlement header.
Before posting, you can review settlements in the Posting Preview. Already in the preview, you can see whether the generated tax document and tax credit memo (i.e. the generated VAT items are). You can check both the VAT Entries and the G/L Entries of the generated documents. Items are not displayed only if deferred generation of tax documents and/or tax credits is set up.
Post the settlement
When settlement posting runs, the entries are settled. Payment on the balance is marked as Payment in advance.
Two new records will be created in the Payments Ahead records – Payment and Usage.
At the same time, a tax document is generated on the Payment line and a tax credit memo on the Usage line.
Apply Payment Automatically by Batch Job
You can also apply open Customer Ledger Entries in bulk by task Apply Customer Ledger Entries. The pairing method is set on the Customer Card. It is possible to set different pairing parameters for each customer.
Notification:
The automatic application settings on the Customer Card must be in accordance with the other system settings, especially the settings for applying entries in different currencies. For the correct functionality of the Financing module, it is necessary to allow settlement of Customer Ledger Entries only in the same currencies (Sales and Receivables Settings, Settlement Between Currencies = None). With this setting, it is recommended to set the following settings on the Customer Card: Currency as a settlement parameter, otherwise, matching items in different currencies will be evaluated as an error and the customer's matching will be interrupted.
Settings
The settings required for automatic customer entry application are described in Settings For Apply Customer Ledger Entries Batch
Below is just an overview of the settings (tables and fields):
Customer Card
Application Method
Automatic Apply
Type of Apply by Field
Apply by Field (1-8)
Customer Template
Application Method
Automatic Apply
Type of Apply by Field
Apply by Field (1-8)
Apply Customer Ledger Entries task
Batch Job Apply Customer Ledger Entries allows you to match open Customer Ledger Entries in bulk. Only customers who have automatic matching enabled on the Customer Card (Automatic Apply = Yes) and at the same time have at least one matching parameter set (Apply Signs 1 to 8) are processed in the job.
The selection of customers can be further restricted by a user filter in the dialog box when the task runs.
To apply items, the task uses the same function as the user for manual balance matching. This means that the task selects the customer's first open item and sets that item as a "leveling item" (application header). Searches for "applied entries" (settlement rows) to this entry
In the rows, the customer's open entries are with the opposite sign, which correspond to the set matching parameters (Equals 1 to 8) on the Customer Card and the user filters specified in the dialog window when the task is started.
If the task finds only one entry to apply, it marks it (in manual application, this application ID is set by the user in the settlement lines), and posts the settlement.
If the task finds more identical items (e.g. multiple invoices with the same variable symbol), then it sorts these items by Due Date, selects the item with the oldest Due Date and posts this settlement. If the settlement entry (in the settlement header) is still open after application, the next item to apply is selected again. It means that Settlement Transactions Only 2 items are involved at a time. This ensures the correct settlement date, especially for mass payments!
Prepayment
If Payment Ahead is paired, or if the item meets the conditions for retrospective generation of Payment Prepayment, the task proceeds in the same way as for manual matching.
Run the task
Use the search magnifying glass to find the job. After the task runs, you can specify filters in the dialog box.
On the Options It is possible to set filters to Customer Ledger Entries.
Dimension 2 Filter (Contract; Contract)
The task selects only customer entries with specified dimension values for matching, e.g. contracts numbered "from-to", or contracts starting with "FL*", etc.
If the field is empty, all items are entered into the matching, the Global Item Dimension 2 is not taken into account
The filter is valid for both applying entries (settlement header) and applied entries (settlement rows)
Date Filter
The filter is applied only to the applying item (application header)
It is also possible to enter a period "from-to"
This field is not usually filled in; if empty, all items are included in the pairing, the Posting date of the items is not taken into account
Document Type Filter
The filter on Document type is applied only to the settlement entry (settlement header).
For example, if you want to match only payments to an invoice, but not credit memos, you enter the Payment type. The task will then go through only payments and match them with the found items (usually invoices).
The document type must be filled in manually, it cannot be selected from the code list (type ' ' = "empty", Payment, Invoice, Credit Memo, Finance Charge, Reminder, Refund). If the field is not filled in, all items will be included in the processing, regardless of type.
CurrencyCode Filter
The task filters only items with the specified Currency Code to settlement; To enter a filter for the local currency, it is necessary to enter characters (apostrophes) for an empty value:
If the field remains empty, all items are entered into the matching, the item's currency is not taken into account
Note: If applying items in the same currencies is allowed only (see Sales and Receivables Settings) and the matching parameters would be met by items containing different currencies, then the matching of these items is terminated by an error message, which is written into the log and the matching of the customer's items is finished. The task continues by matching the next customer's items.
Customer Posting Group Filter
The task selects only items with the specified customer posting group for settlement (header and rows). Multiple posting groups can be entered into the filter
If the field is empty, all items are included in the matching, the Customer Posting Group on the item is not taken into account
Skip Entries with On Hold not-blank
The filter applies to both header and settlement rows
Fields with Yes/No values
Yes: If the box is checked, then the job will match only items that have the On Hold field Empty. For example, the initial invoice for the sales price for Instalment Sale, or other items manually marked by the user in the Wait field, can be excluded from pairing.
No (No): If the box is cleared, the Wait field on the Customer Ledger Entry is not taken into account. In this case, you can limit the selection of items for specific On Hold values by specifying a filter in the next Filter On Hold field (e.g., exclude only Instalment Sales invoices if they have a unique value in the On Hold field)
Filter for field On Hold
The filter applies to both header and settlement rows
If the field is empty, all items are included in the matching, the Wait field on the customer entry is not taken into account.
If the field is filled in, the job selects only items with the specified On Hold value for matching. Multiple values can be entered into the filter, e.g.
Fill in the filter only if the previous field Exclude items with filled in (non-empty) On Hold is not checked
However, the main goal of this filter is to exclude the sales price invoice for Instalment Sale from matching. On the customer ledger entry for this invoice, you can manually fill in the On Hold field, e.g. code "SP". In this case, the filter would be filled in as follows:
Customer Tab
On this tab, you can enter a user filter for fields that are on the customer card (e.g. Customer number, Name, ID number...). If you do not specify any filter, all customers enter into the matching.
Run settlement
After setting the filters (not mandatory), start leveling with the button OK.
The task iterates through the cards of customers who have auto-matching enabled. For these customers, the individual open Customer Items go through one by one. The first item found is filled into the settlement header and according to the matching parameters on the customer card and the filters entered in the dialog window, it searches for items to be settled. If it finds an item suitable for pairing, it will match the two items. It repeats this process with the next open item. If the item is only partially settled, it enters the next pairing.
If there is a paired payment that has a record in the Payments Ahead organizer (type Payment), a record of the Usage type is generated based on the settlement.
If a payment that meets the conditions for generating a Payment in advance is paired, but the Payment in advance has not yet been generated, then a Payment in Advance is generated retrospectively (record of both Payment and Usage type) during settlement.
If payment variance posting is set up in the General Ledger Setup "on request", then the system automatically confirms the posting of the difference as a difference.
If the task finds items suitable for matching, but this matching ends with an error message during posting, then:
The pairing of this pair of items is broken, the items remain unsettled, and the error is written to the Error Log
The customer's matching is terminated, and the customer's entries applied before the transaction with the error remain settled.
The task continues by matching the next customer.
Cancel settlement
If the payment you received has been applied to an incorrect entry, you can cancel the settlement. If it was a Payment in advance, the Usage record will also be canceled when the settlement is cancelled.
Cancellation of settlement is done by default from Customer Ledger Entries using the Unapply entries. When the function runs, the system displays the settlement entries that will be canceled.
When the settlement is cancelled, the Payment Ahead records are updated.
Record of type Payment Incl. tax document, if generated, remains unchanged. If tax document generation was suppressed when posting a payment (by selecting the Dont post invoice for payment ahead flag in the journal or based on the VAT business posting group used, and possibly Global Dimension 2 on the payment or based on the customer posting group used on the payment), then the flags remain disabled.
Usage Type Record is marked as Cancelled, a new record is not created. When it comes to generating tax documents and credit notes, the following cases may occur:
If the tax document is not and should not be generated (flag Generate Tax Document = No on Payment), then there will be no generation of either tax credit memo or tax debit note on Usage.
If the tax invoice has already been generated or is waiting to be generated and:
if already them generated tax credit memo, then a tax debit note will always be generated (immediately or additionally by a batch job)
If the Tax Credit Memo waits to generate, then a flag to generate a credit note Deletes, only a tax document will remain for the received payment, which is waiting for a new use.
Generate Tax Documents for Payment Ahead batch job
You do not have to generate tax documents for pre-received payments immediately when posting the payment in the journal, but they can be generated in bulk later. That's what a batch job is done for Generate Tax Documents and Credit Memos for Payments Ahead. The task can be accessed by searching through the magnifying glass.
This batch job contains three separate roles:
Additional Generate Prepayments
Checking Flag Settings Before Generating Documents
Generation of Tax Documents (Tax Documents, Tax Credit Memos, Tax Debit Notes)
When the task starts, a dialog box opens that contains three tabs.
Bookmark Options It contains the field:
Perform additional generate Payment Ahead
Options Yes / No
Check the box if task 1 is to be run
From Posting Date for Additional Generate
The date "from" is used in Task 1. The entered date will be used as a filter for the Posting date on the Customer Ledger Entries
optional, if not filled in, takes all items
To Posting Date for Additional Generate
The "to" date is used in Task 1. The entered date will be used as a filter for the Posting date on the Customer Ledger Entries
The default value is Workdate, you can change it
The date "To" is a required field and must be the same or higher than the Date From Posting Date for additional generation
Process Flag Checking before Posting
Options Yes / No
Check the box if task 2 is to be run
Process Tax documents generating
Options Yes / No
Check the box if task 3 is to be run
If none of the three possible tasks is checked on the Options tab, the execution will end with the error message "No option selected".
Bookmark Filter: Customer Ledger Entry (Cust. Ledger Entry):
Filters will be used by task No. 1
Bookmark Filter: Payment Ahead:
Filters will be applied by task No. 2 and 3
Task 1 - Additional generate Payment Ahead
This task generates new records in the Payments Ahead organizer for Customer Ledger Entries that meet the following conditions:
Document Type = Payment
The customer's posting group has the Use for Prepayment flag = Yes
Payment in advance has not yet been generated for this item
Open = Yes
The balance to be settled is greater than the maximum payment variance for the relevant currency in which the payment is posted
For these customer ledger entries, the Payment Ahead task generates type Payment. If the payment is partially settled, then the task will also generate records of type Exploitation. For settlements that have been canceled, Usage is not generated. It marks the customer entry (payment) with the flag Payment in advance = Yes.
Flags for generating tax documents and credit notes are set on the generated records.
Typically, this task is used to tax payments from a customer that have a balance at the end of the month.
Setup flags
On Payment in advance of type Payment, the default value of "generate documents" is set to Yes. Subsequently, the task Deletes flags
according to the VAT setting of the business posting group:
Block Payment Ahead Tax Document Creation = Yes
Block Payment Ahead Tax Document Creation = No and at the same time in Block Tax Document Creation for Financing Types filter is set to Financing Type
according to the settings of the Customer Posting Group
Generate Tax Documents for Payments Ahead = No
Flags on Payment Ahead of type Usage are set/deleted according to the flags on the record of the Payment type (i.e. if tax documents are generated, tax credit memos must also be generated)
After completing task no. 1, the system will move on to other tasks according to the instructions in the dialog window.
Task 2 - Flag Checking before Posting
Task No. 2 goes through Prepayment Type Paymentthat are Waiting to generate tax documents (they have flags Generate documents = Yes and Generate tax document = Yes). It checks two conditions on these payments:
On the Customer Ledger Entry for which the Prepayment is generated, there is a Customer Posting Group that has the flag set Generate Prepayment Tax Documents = No
By Dimension 2 Value (Contract) It wasn't found Financing Contract and at the same time in Sales & Receivables Setup there is a flag "Generate Payment Ahead Tax Documents without Financing Contract Found" = No.
If the payment satisfies at least one condition, flags for generating tax documents delete.
If there is a Exploitation associated with this Payment, the flags will be deleted here as well. However, if a tax document has already been generated, the flags for generating tax credits or debit notes remain.
Task No. 3 – Tax documents generating
In this task, the system goes through the Payments Ahead records. Based on the Generate Prepayment Invoice and Generate Prepayment Credit Memo flags, it generates the relevant documents and their corresponding G/L Entries and VAT entries.
After the task is finished, the system prints an informative message about the completion.
Generating Tax Documents for Payments Ahead in Posting
If Prepayments were generated in the previous steps, but the tax documents/credit notes are still waiting to be generated, then system Automatically generates and posts Tax documents and credit notes for the following events:
when posting a payment journal (CU 13 – OnAfterCode)
When posting application of customer ledger entries (CU 226 - OnAfterPostApplyCustLedgEntry)
The system selects all Payments in advance of the Payment and Usage types that they have set up symptoms:
Payment:
Generate Invoice = Yes
Generate Prepayment Invoice Immediately = Yes
Exploitation:
Generate Prepayment Credit Memo = Yes
Generate Prepayment Credit Memo Immediately = Yes