Processing Of The Received Invoice

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 Payment Ahead from Payment Journal

  • Tax documents generated immediately

  • Tax Documents Generated Deferred – Individually or Collectively by Batch Job

• Generate Payment Ahead Retrospectively Based on Balance Payment Settlement

• Generate Payment Ahead retrospectively 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 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 per 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 in advance will start when filling in the Applies-to Document No. or Applies-to ID field. A prepayment is identified if at least one document 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 Prepayment Invoice Immediately,

• 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 into partial payments.

A combination of settings for the resulting payment ahead marking and the use of the customer's posting group: 

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 after the module is turned on (Allow 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 chapter Zpracování přijaté platby | Kontrola znamének vyrovnávaných položek . The signs of applied entries are checked when the payment is posted. Example of an error message when this rule is violated:

Open

• 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

Mass payment can be split using the Split payment by to Applying see chapter Bankovní výpisy | Rozdělení hromadné platby v Deníku Plateb . When splitting a payment, the system evaluates whether the conditions for generating Payment Ahead are met for individual items and, if so, 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 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.xxx) or its substitute posting group for advance payments (e.g. for receivable account = 311.xxx). 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 assigned to the payment and at least one of them meets the conditions for prepayment, then the system marks the payment with the Generate prepayment flag and uses the customer's 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 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)

• When a settlement is changed, the posting group is updated to reflect the new settlement

• When deleting a settlement, the customer's posting group is set up according to Sales & 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 prepayments have flags set), you can post the journal.

Posting of applying

If the Prepayments module is disabled, the system does not allow 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's balance as part of a payment journal line posting transaction. With this two-phase posting, which 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)

divides the billing system into two phases:

• Post a payment without settlement, and

• Subsequently, apply a payment to the balance with entries that have been selected and marked for settlement in the journal.

The entry that is posted in the 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 date of applying the Payment Ahead (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.  

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 you copy a posted line back to a live journal, the line is copied with the flags listed.

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 Payment Ahead organizer.

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 Prepayments card can be found in the Evidence Platby předem | Platba předem

Tax documents for prepayment

Tax invoices for Payment Ahead

If the flag Generate prepayment invoice 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 ahead header), a tax document was generated whose number is filled in the Tax document number for received payment field. You can display this document by clicking on the Tax Invoice button or by clicking on Tax Invoice No. for Received Payment.

Tax invoices generated additionally

If the flag Generate tax invoice for prepayment immediately is not checked on the payment in the journal and the creation of a tax document is not suppressed, the tax document will not be generated, but the flags Generate documents and Generate tax document will be selected on the Prepayment journal.

For these Payments in advance, it is possible to generate a tax document additionally:

• either individually manually from the Payments Ahead tab using the Actions button > Post Invoice,

• or Batch Job Generated Tax Documents and Credit Memos for Payments Aheadsee Zpracování přijaté platby | Dávková úloha Generovat daňové doklady k platbám předem

• 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 Payment Ahead was generated during this posting (applies to already existing Payments Ahead with flag Generate Tax Document for Prepayment Immediately = Yes).

After the tax document is generated, the document number is written on the Payment in advance and the flags Generate Documents and Generate Tax Document for Received Payment are deleted.

Tax document corrections

Generated prepayment invoice Not standard features Neither to cancel nor to create a credit memo for them:

Open

An issued tax document can only be cancelled Settlement Customer Ledger Entries (payments), which automatically generates a 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 Ahead at the same time. If, at the same time, the Sales & Receivables Setup sets up that tax credit memos should be generated immediately and a tax document for prepayment has already been generated, the system generates a tax credit memo, 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 Numbers for Received Payment.

Tax credit memos generated additionally

If the Sales & Receivables Setup sets Generate credit memo for received payment immediately = No or the tax document has not been generated yet (flag on Prepayment type Payment is Generate tax document for received payment = Yes), a tax credit memo will not be generated during settlement, but the flags Generate documents and Generate credit memo for received payment will be checked on Prepayment of type Usage.

For these Prepayment Usages, it is possible to generate a tax credit memo additionally:

• either individually manually from the Payments Ahead tab using the Actions button > Post Credit Memo,

• or Batch Job Generate Tax Documents and Credit Memos for Payment Ahead, see Chap. Zpracování přijaté platby | Dávková úloha Generovat daňové doklady k platbám předem

• 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 Payment Ahead was generated during this posting (applies to already existing Payments Ahead flag Generate Tax Credit Memo for Prepayment Immediately = Yes)

A tax credit memo posted manually from the Payments Ahead card of the Usage type:

After the tax credit memo is generated, the credit memo number is written on the Payment in advance, and the Generate documents and Generate credit memo for received payment flags are deleted

View Payment Ahead from a Customer Ledger Entry

After you post a payment with the Generate Prepayment flag, a Customer Ledger Entry that is flagged 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) button 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 entries

• Check Same Currency in Settlement (see Sales and Receivables Setup)

• Generate tax documents and tax credits for existing Payments Ahead

• Retrospective generation of Payments in advance when 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 settlement entry in the settlement header (by default, multiple positive and multiple negative entries can be applied in one transaction in BC). The system checks for signs when posting settlements or in the posting preview of settlements.

Same Currency Check

Due to the possibility to generate 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 Prepayments module is enabled, the setting must be Currency applies=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 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 met.

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, a new record of the Usage type is generated in the Payments Ahead record.

A Tax Credit Memo for Payment in Advance is generated for this record, depending on the settings either immediately or deferred. The condition for generating a credit note is that a Tax Document for Payment 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 on the 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 note so that the sum of the Usage records corresponds to 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 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 was not generated (in the Payment Journal it was Generate Payment Ahead = No), it is possible to Conditions Generate 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 type Invoice (letterhead document Posted Sales Invoice exists). When applying to a different entry type (Blank or Refund) or to an invoice posted in a journal, Payment Ahead is not generated

• The VAT date of the invoice being settled must be before the payment date. Depending on the settings, either whole months or individual days are tested (Create Advance Payment by Period = Yes/No)

• For mass 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 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 Credits,

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 "immediately“!

Example of Payment Ahead Reverse Generation – 1:1 Settlement of Payment with Invoice

There are two Customer Entries ready for settlement, which meet the conditions for retrospective generation of Prepayment. Payment in advance has not been generated yet (see the Payment in advance = No field on the Customer Ledger Entry).

Apply items with the standard Apply Entries function.

• Before posting, you can review the settlement in the Posting Preview. Already in the preview you can see whether the generated tax document and tax credit note (i.e. are generated VAT items). You can check both VAT Entries and G/L Entries of 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 applied. 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 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 on the Customer Card must be in accordance with the other settings of the system, especially with the settings for applying entries in different currencies. For the correct functionality of the Financing module, it is necessary to allow 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 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 application of customer entries are described in Nastavení pro úlohu Vyrovnat položky zákazníka

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 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 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 job runs.

To apply entries, 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" (settlement header). Searches for "applied items" (settlement rows) for this entry

In the rows, there are open entries for the customer 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.

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 application.

If the task finds multiple identical entries (e.g. multiple invoices with the same variable symbol), then 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 performed 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 job  

Use the search magnifying glass to find the task. After the task starts, 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 entered dimension values, e.g. contract number "from-to", or contracts starting with "FL*", etc.

  • If the field is empty, all items are matched, Global Dimension 2 items are not taken into account

  • The filter is valid for both the application entry (application header) and the applied entries (settlement rows) 

• Date Filter

  • The filter is applied only to the application item (application header)

  • It is also possible to enter a period "from-to"

  • This field is usually not filled in; if empty, all items are entered into 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 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 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 is left empty, all items are matched, the item's currency is not taken into account

    • Note: If it is allowed to apply items only in the same currencies (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 line). Multiple posting groups can be entered into the filter

  • If the field is empty, all items are 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 a On Hold field Empty. For example, the opening invoice for the sales price in the Instalment Sale or other items manually marked by the user in the Hold field can be excluded from pairing.      

    • No (No): If the box is cleared, the On Hold field on the Customer Ledger Entry is disregarded. In this case, you can restrict the selection of items 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 entered into the matching, the 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".  The filter in this case 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...). If you don't specify any filter, all customers enter into the match.

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 specified in the dialog window, it searches for items to be settled. If it finds an item suitable for pairing, it will align the two items. 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 will be generated based on the application.

If a payment that meets the conditions for generating a Payment Ahead is paired, but the Payment in advance has not yet been generated, then a Payment Ahead is generated retrospectively (record of both Payment and Usage type) during settlement.

If Payment Difference Posting is set up in the General Ledger Setup "on request", then the system will automatically confirm 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.

Undo settlement

If the payment you received was applied to the wrong entry, you can cancel the application. In the case of a Payment in advance, the Usage record will also be 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 you 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 flag Don't post invoice for payment ahead 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 a tax document has already been generated or is waiting to be generated and:

  • if already them generated tax credit note, 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 the flag to generate the credit 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 don't have to generate tax documents for prepaid payments immediately when posting the payment in the journal, but you can generate them in bulk subsequently. To do this, you can use a batch job Generate Tax Documents and Credit Memos for Payments Ahead. The task is available by searching through the magnifying glass.

This batch job contains three separate roles:

• Additional Payment Ahead Generation

• 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 fields:

• 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 "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

  • 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 Work 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

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 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 for Customer Ledger Entries that meet the following conditions:

• Document Type = Payment

• The customer's posting group has flag Use for Prepayment = Yes

• 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 the Exploitation. For settlements that have been canceled, Usage is not generated. Flag the customer entry (payment) 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 the Payment in advance of the Payment type, the default value of "generate documents" is set to Yes. Subsequently, the task Deletes flags

• according to the VAT 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 in advance of the Usage type are set/deleted according to the flags on the Payment record (i.e. if tax documents are generated, tax credit memos must 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 2 goes through Prepayment Type Paymentthat are Waiting to generate tax documents (they have flags Generate Documents = Yes and Generate Tax Document = Yes). It will check these payments for two conditions:

• On the Customer Ledger Entry for which the Prepayment is generated, there is a Customer Posting Group that has a flag set Generate Tax Documents for Payments Ahead = No

• By Dimension Value 2 (Contract) It wasn't found Financing Contract and at the same time in Sales & Receivables Setup there is flag "Generate Tax Documents for Payments Ahead without Financing Contract" = No.

If the payment meets the at least one condition, flags for generating tax documents with delete.

If there is Exploitation associated with this Payment, the flags will be deleted here as well. However, if a tax invoice has already been generated, the flags for generating tax credits or debit notes remain.

Task 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 end.

Generating Tax Documents for Payments Ahead in Posting

If Payments Ahead were generated in the previous steps, but 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 Tax Invoice = Yes

• Generate Prepayment Invoice Immediately = Yes

Exploitation:

• Generate Credit Memo for Received Prepayment = Yes

• Generate credit memo for received payment immediately = Yes.