Page Comparison

...

Principles

If the payment is received before the date of taxable supply and the applicable legislation requires VAT to be paid on the received payment, the module Payments Ahead Allows record this payment in a separate register, create for a link to it Tax Invoice (invoice) and then create when settling this payment Tax Credit Memo. 

Taxation of payments received in advance is carried out at a fixed rate, according to the pre-set VAT product posting group of goods.

• Prepayment cannot be created manually, it can only be created:by posting

  • Posting a payment from the Payment Journal

  automatically generated

  • automatic generation when

  settling

  • a payment is settled additionally

  to

  • on the customer's balance

  • Generate a batch job over

  an unapplied or

  • a posted payment that has not yet been applied or that has been partially applied

  posted payment

In principle, the system performs:

• When you receive a payment that is received, which is identified and marked as a prepayment, it creates:

  • An entry in the Payment Ahead Records of the Payment type, where the tax liability from the received payment is quantified

  • If a tax document is requested, it creates (immediately or deferred) a posted sales invoice, the appropriate VAT entries, and general ledger entries

• When applying (matching) a payment in advance, the system creates:

  • An entry in the Records of Payments Ahead Records of the Usage type, where the basis for the tax credit memo note is calculated

  • If a tax invoice has been issued for the payment, the system creates a posted sales credit memo, the appropriate VAT entries, and general ledger entries

• Final Invoice:

  • The document to be applied document (final invoice) is posted in full

  • Printing of a posted sales invoice is not regulated by default.

  • As a customer adjustment, it is possible to add the option to print the final invoice with and without the inclusion of the prepayment included

• When canceling a prepayment payment ahead settlement, the system:

  • Mark a record of the Usage type as canceled

  • If a tax credit memo has already been posted, it is cancelled by issuing a tax debit note

• The creation of tax documents and the actual recording registration of payments in advance can be postponed and performed by a batch job (e.g. at the end of the month), which enables:

  • Generate additional payments in advance 

  • Turn off tax document generation if the case (according to the settings) does not require it

  • Generate missing tax documents if they have not yet been generated  generated yet  

Dependencies and assumptions

• Finance (Accounting) Function Module

• Functionality is available that allows you the customer to use multiple Customer Posting Groups (alternative Posting Groups) for a customer.

• The tax liability for payment in advance prepayment is determined on the basis of a single (fixed) VAT rate.

• If VAT Date as a W1 field and a CZ or SK field exist in the same entity (e.g. on the header of an invoice) at the same time, then the VAT Date as a W1 field is used VAT Date From Version W1 (Currently, All versions of OC (W1, CZ extension, SK extension) work with VAT Date from Version W1 (currently it is a field VAT Reporting Date). It . If the legislation (CZ/SK) uses its own VAT Date field, then these fields are not worked with and it is assumed that these CZ or SK fields will always be filled in 1:1 with a the W1 field. 

• Customer Ledger Entry

  • In version W1, the VAT Date is not on the Customer ItemLedger Entry. Therefore, Payment Ahead is tested against on the VAT Date of the Posted Sales Invoice. If a payment is applied to an Invoice type entry that does not have a header document (e.g., migrated customer ledger entries), then payments to these invoices cannot be identified as prepaymentsadvance payments. In the Payment Journal, the user can manually mark these payments as PrepaymentsPayments Ahead manually.

  • In the CZ version, there is a Czech field VAT Date (11780 VAT Date CZL) field on the Customer Ledger Entry. This field is used by the system in the Payment Ahead test when a the payment is additionally applied to the customer balance.

    • For an item of the type Invoice type, if a Posted Sales Invoice header exists, the VAT date on the invoice header is used

    • For all other types, the VAT Date from Customer Ledger Entry will be is used 

• The module is primarily intended for Czech legislation (extension Core Localization Pack for Czech extension, publisher Microsoft)

• Due to the use of various extensions for processing bank statements in BC, the Payments Ahead module does not include the modification of automatic matching of bank statements.       

...

The settings required for Prepayments Payments Ahead are described in the document Settings For The Payments Ahead Module Nastavení pro modul Platby předem

Below is just an overview of the settings (tables and fields):

• Sales & Receivables Setup

  • Allow Payments Ahead

  • Create Payment Ahead by Period

  • Generate Prepayment Invoice Immediately

  • Generate Prepayment Credit Memo immediately

  • Generate Prepayment Correction Invoice Immediately

  • Payment Posting Method

  • Mark as Payment Ahead

  • Prepayment Invoice Nos.

  • Prepayment Credit Memo NosNo.

  • Prepayment Nos.

  • Prepayment VAT Prod. Posting Group

  • Generate Tax Documents for Payments Ahead without Financing Contract

• VAT Business Posting Groups

  • Block Payment Ahead Tax Document Creation

  • Block Tax Document Creation for Financing Types

• VAT Posting Setup

  • Sales VAT Account

  • Payment Ahead VAT Bal. Account No.)

• Customer Posting Groups

  • Use for Payments Ahead

  • Substitute Posting Group for Payments AheadHead

  • Generate Tax Documents for Payment Ahead

• Setup for printing tax documents and tax credits

  • The report Report for printing tax documents / credit notes / debit notes for Payments Ahead is not set by the user, but is part of the program code