...
...
...
...
...
| Table of Contents | ||
|---|---|---|
|
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 Payment Ahead from Payment Journal
Tax documents generated immediately
Tax documents generated deferred – individually or in bulk by batch job
Documents Generated Deferred – Individually or Collectively by Batch Job
Generate Payment Ahead Retrospectively Based on Balance Payment SettlementGenerating
Generate Payment Ahead Retrospectively Without Applying Paymentretrospectively without applying the 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 with 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 Customerper 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 Customer number is filled in;
For a payment that will be settled, the identification of the payment ahead in advance will be triggered start when filling in the Applies-to Document No. or Applies-to ID is filled infield. 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 immediatelyPrepayment Invoice Immediately,
Don't charge a tax invoice for a Do not charge VAT for 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, it is necessary to divide the payment in the journal must be divided into partial payments.
Combination A combination of settings for the resulting marking of payment ahead marking and the use of the customer's posting group:
Sales & Receivables Setup | Payment Journal | ||||
Payment | |||||
Posting Method | Mark as Payment Ahead | PAYMENTS OUTSTANDING | |
or REGULAR PAYMENTS |
partially settled | PAYMENTS MADE AHEAD (fully and partially) |
Posting group | Generate |
Posting group | Generate | ||||
Common Payment | Only Leveled | TUZ | No | TUZ_P | Yes |
Common Payment | All |
per customer | TUZ_P | Yes | TUZ_P | Yes | |
Payment Ahead | Only Leveled | TUZ_P | No | TUZ_P | Yes |
Payment Ahead | All |
per customer | TUZ_P | Yes | TUZ_P | Yes |
Adjustments in the Payment Journal
New
...
Prepayment Fields
For payments received in advance, the journal is extended with three new fields that are available on the journal line when after the module is turned on (Allow creating create payment ahead = Yes):
Generate Prepayment
This flag specifies that the payment will be Registered in the
...
Prepayments module.
...
The automatic marking of
...
a payment on
...
a journal line
...
is governed by the rules of payment ahead identification - the settlement status of the line using other settings from
...
Sales and Receivables Setup (Create Payment Ahead by Period and Record as Payment
...
Advance).
Before you post the journal
...
, this flag can be turned on or off manually. If the flag is
...
selected, a Customer Posting
...
Group with
...
flag Use for Payments Ahead
...
= Yes is required for payment.
Generate Prepayment Invoice Immediately
This flag specifies that a tax document will be generated for the
...
recorded Payment Ahead immediately When posting a payment in the Payment Journal. The flag is turned on by the system based on the setting in
...
Sales & Receivables Setup in the Generate Invoice for Received Prepayment
...
Immediately field
Before you post the journal
...
, 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
...
Apply journal payments
Adjustment of applying date
By default, it is possible to settle payments in the Payment Journal only with customer entries whose Posting date is
...
equal to or lower than the Posting date of payment. If the Prepayments module is enabled, the system will also 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 (the same adjustment as
...
for the customer's balance,
...
see chapterhttps://iao.atlassian.net/wiki/spaces/OCDOC/pages/edit-v2/32637019#Kontrola-znam%C3%A9nek-vyrovn%C3%A1van%C3%BDch-polo%C5%BEek . The signs of 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
...
the payment
...
was flagged
...
Generate
...
payment ahead = Yes and a settlement
...
was made, then the function to identify the payment ahead is restarted when deleting or changing the settlement
...
(Applies-to Document Numbers or Applies-to
...
ID). Same when deleting or changing a customer number. The flags are revised and set according to the current state.
...
Mass payment splitting
A mass Mass payment can be split using the Split payment by to Applying See Chap. 6.3.6. Split payment in Payment Journal. see chapter https://iao.atlassian.net/wiki/spaces/OCDOC/pages/31621401/Bankovn+v+pisy#Rozd%C4%9Blen%C3%AD-hromadn%C3%A9-platby-v-Den%C3%ADku-Plateb . 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's posting group when creating you create 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.AUxxx) or its substitute posting group for advance payments (e.g. for accounts receivable account = 324311.AUxxx). 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.
...
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 assigned to the payment and at least one of them meets the conditions for prepayment, then the system marks the payment with the Generate Payment Ahead prepayment flag and uses the Customer customer's Posting Group group specified for Prepaymentprepayment.
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 the 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 (standard BC standard)
When a settlement is changed, the posting group is updated according to reflect the new settlement
When deleting a settlement, the customer's posting group is set up according to Sales and & Receivables Setup 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 prepayments have flags set), you can post the journal.
Posting of applying
If the Payments Ahead Prepayments module is disabled, the system will does 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.
...
This is accomplished by "deferred" payment matching up to the customer's balance as part of a payment journal line posting transaction. With this two-phase posting, which is triggered runs on the condition that:
the Prepayments module is turned on
Account Type or Trade-in Account Type is Customer
There is an application on the journal line (either Applies-to Document No. or Applies-to ID)
It divides the accounting billing system into two phases:
Post a payment without settlement, and
Subsequent settlement of the payment on Subsequently, apply a payment to the balance with entries that have been selected and marked for settlement in the journal.
An The entry that is posted in a the journal (Payment) is always populated in the settlement header when you use the balance settlement function.
...
Therefore, for the correct date of applying the Payment Ahead settlement date (if the invoices have different Posting Dates), it is necessary to either split the mass payment and match the partial payments separately, or post the payment without matching and apply it manually to the balance, or use the Apply Customer Ledger Entries task.
...
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 you copy a posted line is copied back to the a live journal, the line is copied with the flags listed flags.
Prepayment.
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 Payment Ahead recordorganizer.
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 Prepayments card can be found in the https://iao.atlassian.net/wiki/spaces/OCDOC/pages/32636989/Evidence+Platby+p+edem#Platba-p%C5%99edem
Tax documents for prepayment
Tax invoices for Payment Ahead
If the flag Generate prepayment 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 ahead header), a tax document was generated whose number is filled in the Tax document number for received payment field. You can view display 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 flag Generate tax invoice for prepayment immediately flag is not checked on the payment in the journal and the creation of the a tax document is not suppressed, the tax document is will not be generated, but the flags Generate documents and Generate tax document flags are will be selected on the Prepayment journal.
For these PrepaymentsPayments in advance, it is possible to generate a tax document additionally:
either individually manually from the Payments Ahead tab using the Action Actions button > Post Invoice,
or Batch Job in Bulk Generated Tax Documents and Credit Memos for Payments Aheadseehttps://iao.atlassian.net/wiki/spaces/OCDOC/pages/32637019/Zpracov+n+p+ijat+platby#D%C3%A1vkov%C3%A1-%C3%BAloha-Generovat-da%C5%88ov%C3%A9-doklady-k-platb%C3%A1m-p%C5%99edem
or the system generates them automatically in the background when you post any general journal or when you post a settlement on the balance.,if a prepayment Payment Ahead was generated during this posting (applies to already existing Payments in advance Ahead with flag Generate Tax Document for Prepayment Invoice Immediately = Yes).
After the tax document is generated, the document number is entered written on the Payment in advance and the flags Generate documents Documents and Generate tax invoice for received payment flags Tax Document for Received Payment are deleted.
Tax document corrections
Generated Prepayment Invoice Cannot use prepayment invoice Not 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 for the prepayment.
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 Ahead at the same time. At If, at the same time, if the Sales & Receivables Setup sets up that tax credit memos should be generated immediately and a tax invoice document for prepayment has already been generated, the system generates a tax credit memo whose , the number of which 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 NumberNumbers for Received Payment.
Tax credit memos generated additionally
If the Sales & Receivables Setup set Generate Prepayment Credit Memo sets Generate credit memo for received payment immediately = No or the tax document has not yet been generated yet (flag on Prepayment payment type Payment is Generate Prepayment Invoice tax document for received payment = Yes), a tax credit memo will not be generated during settlement, but the flags Generate Documents documents and Generate Prepayment Credit Memo flags credit memo for received payment will be checked on Prepayment of the type 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 Actions 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/32637019/Zpracov+n+p+ijat+platby#D%C3%A1vkov%C3%A1-%C3%BAloha-Generovat-da%C5%88ov%C3%A9-doklady-k-platb%C3%A1m-p%C5%99edem
or the system generates them automatically in the background when you post any general journal or when you post a settlement on the balance.if an advance payment ,if a Payment Ahead was generated during this posting (applies to already existing Payments in advance with Ahead flag Generate Tax Credit Memo for Payment Ahead Prepayment Immediately = Yes)
A tax credit memo that is posted manually from the Payments Ahead card of the Usage type.When a :
...
After the tax credit memo is generated, the credit memo number is written on Prepayment the Payment in advance, and the Generate Documents documents and Generate Prepayment Credit Memo credit memo for received payment flags are deleted
View Payment Ahead from a Customer Ledger Entry
After posting you post a payment with the Generate Prepayment flag, a Customer Ledger Entry that is flagged is will be 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 button Prepayment.
Apply a
...
Payment Manually to a
...
Balance
The standard Apply Entries function is used to apply Customer Ledger Entries.
...
Check the signs of applied itemsentries
Check the same currency in settlement Same Currency in Settlement (see Sales and Receivables Setup)
Generate tax documents and tax credit memos credits for existing Payments Ahead
Reverse Retrospective generation of Payments Ahead in advance when applying a payment is settled, if the conditions for their creation are met
Check the signs of applied
...
entries
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 settlement entry in the settlement header (by default, multiple positive and multiple negative items entries can be settled applied in one transaction in BC). The system checks for signs when posting settlements or in the settlement posting preview of settlements.
Same Currency Check
Due to the possibility to generate advance payments prepayments 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 Prepayments module is enabled, the set setting must be Currency Appliesapplies=None.
Settlement on Balance –
...
Prepayment 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 you want the payment should to 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 satisfiedmet.
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 posting the settlement is posted, a new record of the Usage type is generated in the Payments Ahead record.
A Prepayment Tax Credit Note Memo for Payment in Advance is generated for this record, depending on the setting, settings either immediately or deferred. The condition for generating a credit note is that a Tax Invoice Document for Payment Ahead in Advance 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 on the VAT business posting group).
...
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 note so that the sum of the Usage records matches corresponds to the amount of the advance payment received.
...
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 of settlement is used
Settlement on Balance
...
– Payment in advance does not exist
If the received payment was posted to the customer's balance, but the Payment ahead Ahead was not generated (in the Payment Journal it was Generate payment ahead Payment Ahead = No), it is possible to do so under certain conditions. Conditions Generate the prepayment a payment in advance 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 type Invoice type (the header letterhead document Posted Sales Invoice exists). When applying to a different entry type of entry (Blank or Refund) or to an invoice posted in a journal, Prepayment Payment Ahead is not generated
The VAT date of the invoice being settled invoice must be before the payment date. Depending on the settings, either whole months or individual days are tested (Create Advance Payment in Advance by Period = Yes/No)
For a mass payment payments 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 will be 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 MemosCredits,
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 "flag to generate " flagimmediately“!
Example of Payment Ahead Reverse Generation – 1:1 Settlement of Payment with Invoice
There are two Customer Entries ready for settlement that , which meet the conditions for retrospective generation of Payment Prepayment. Payment in advance has not yet been generated yet (on the Customer Ledger Entry see the field Payment in advance = No field on the Customer Ledger Entry).
Apply items with the standard Apply Entries function.
Note: To regenerate Payment ForwardFor retrospective Payment Ahead generation, 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 the settlement in the Posting Preview. Already in the preview , you can see whether the generated tax document and tax credit memo note (i.e. the are 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 settledapplied. Payment on the balance is marked as Payment in advance.
...
You can also apply open Customer Ledger Entries in bulk by with a 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 settings of automatic application settings on the Customer Card must be in accordance with the other settings of the system settings, especially with the settings for applying entries in different currencies. For the correct functionality of the Financing module, it is necessary to allow settlement of applying 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 Cardcard: 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.
...
The settings required for automatic application of customer entry application entries are described in Nastavení pro úlohu Vyrovnat položky zákazníka
...
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 pair 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 Characters 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 job runs.
To apply itemsentries, 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 settlement header). Searches for "applied entriesitems" (settlement rows) to for this entry
In the rows, there are open entries for 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 to the user filters specified in the dialog window when running 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 settlementapplication.
If the task finds more multiple identical items entries (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 selection of the next item to apply is selected performed again. It means that Settlement Transactionstransactions Only 2 items are involved at a time. This ensures the correct settlement date, especially for mass payments!
...
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 job
Use the search magnifying glass to find the jobtask. After the task runsstarts, you can specify filters in the dialog box.
...
Dimension 2 Filter (Contract; Contract)
The task selects only customer entries with specified entered dimension values for matching, e.g. contracts numbered contract number "from-to", or contracts starting with "FL*", etc.
If the field is empty, all items are entered into the matchingmatched, the Global Item Dimension 2 is items are not taken into account
The filter is valid for both applying entries (settlement the application entry (application header) and the applied entries (settlement rows)
Date Filter
The filter is applied only to the applying application item (application header)
It is also possible to enter a period "from-to"
This field is usually not usually filled in; if empty, all items are included in entered into the pairing, the Posting date of the items is not taken into account
Document Type Filter
The filter on Document type Type is applied only to the settlement application 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 is left empty, all items are entered into the matchingmatched, the item's currency is not taken into account
Note: If applying it is allowed to apply items only 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 rowsline). Multiple posting groups can be entered into the filter
If the field is empty, all items are included in entered into 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 the header and the settlement rows
Fields with Yes/No values
Yes: If the box is checked, then the job will match only items that have the a On Hold field Empty. For example, the initial opening invoice for the sales price for in the Instalment Sale , or other items manually marked by the user in the Wait Hold field , can be excluded from pairing.
No (No): If the box is cleared, the Wait On Hold field on the Customer Ledger Entry is not taken into accountdisregarded. In this case, you can limit restrict the selection of items for to 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 the header and the settlement rows
If the field is empty, all items are included in entered into the matching, the Wait On Hold 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 The filter 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, Company ID number...). If you do not don't specify any filter, all customers enter into the matchingmatch.
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 specified in the dialog window, it searches for items to be settled. If it finds an item suitable for pairing, it will match align the two items. It repeats Repeat 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 will be generated based on the settlementapplication.
If a payment that meets the conditions for generating a Payment in advance Ahead is paired, but the Payment in advance has not yet been generated, then a Payment in Advance Ahead is generated retrospectively (record of both Payment and Usage type) during settlement.
If payment variance posting Payment Difference Posting is set up in the General Ledger Setup "on request", then the system will automatically confirms confirm the posting of the difference as a difference.
...
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.
...
Undo settlement
If the payment you received has been was applied to an incorrect the wrong entry, you can cancel the settlement. If it was application. In the case of a Payment in advance, the Usage record will also be canceled cancelled 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 cancelledyou cancel an application, 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 flag Don't 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.
...
If the tax document is not and should not be generated (flag Generate Tax Document tax document = No on Payment), then there will be no generation of either tax credit memo or tax debit note on Usage.
If the a tax invoice document has already been generated or is waiting to be generated and:
if already them generated tax credit memonote, 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 the flag to generate a the credit note memo Deletes, only a tax document will remain for the received payment, which is waiting for a new use.
Batch Job Generate Tax Documents for
...
Payments Ahead
...
You do not don't have to generate tax documents for pre-received prepaid payments immediately when posting the payment in the journal, but they you can be generated generate them in bulk later. That's what subsequently. To do this, you can use a batch job is done for Generate Tax Documents and Credit Memos for Payments Ahead. The task can be accessed is available by searching through the magnifying glass.
This batch job contains three separate roles:
Additional Generate PrepaymentsPayment Ahead Generation
Checking Flag Settings Before Generating Documents
Generation of Tax Documents (Tax Documents, Tax Credit Memos, Tax Debit Notes)
...
Bookmark Options It contains the fieldfields:
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" date is used in Task 1. The entered date will be used as a filter for the Posting date on the Customer Ledger Entries
optionalOptional, 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 WorkdateWork Date, 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
...
Filters will be used by task No. 1
Bookmark Filter: Payment Ahead:
Filters will be applied by task Nono. 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 flag Use for Prepayment flag = Yes
Payment in advance Prepayment 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 a type Payment. If the payment is partially settled, then the task will also generate records of type the Exploitation. For settlements that have been canceled, Usage is not generated. It marks Flag the customer entry (payment) with the flag Payment in advance = Yes.
...
Typically, this task is used to tax payments from a customer that have a balance at the end of the month.
Setup flags
On the Payment in advance of the Payment type Payment, the default value of "generate documents" is set to Yes. Subsequently, the task Deletes flags
according to the VAT setting settings 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 in advance of the Usage type Usage are set/deleted according to the flags on the Payment record of the Payment type (i.e. if tax documents are generated, tax credit memos must also be generated as well).
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 Documents = Yes and Generate tax document Tax Document = Yes). It checks will check these payments for 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 a flag set Generate Prepayment Tax Documents for Payments Ahead = No
By Dimension Value 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 for Payments Ahead without Financing Contract Found" = No.
If the payment satisfies meets the at least one condition, flags for generating tax documents with delete.
If there is a Exploitation associated with this Payment, the flags will be deleted here as well. However, if a tax document invoice 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 entriesEntries.
After the task is finished, the system prints an informative message about the completionend.
...
Generating Tax Documents for Payments Ahead in Posting
If Prepayments Payments Ahead 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:
...
The system selects all Payments in advance of the Payment and Usage types that they have set up symptoms:
Payment:
Generate Tax Invoice = Yes
Generate Prepayment Invoice Immediately = Yes
Exploitation:
Generate Prepayment Credit Memo for Received Prepayment = Yes
Generate Prepayment Credit Memo Immediately credit memo for received payment immediately = Yes.