| Table of Contents | ||
|---|---|---|
|
Postup při zpracování plateb přijatých předem se může lišit na základě nastavení (dle interních procesů). Jednotlivé postupy při zpracování lze také vzájemně kombinovat. V dokumentaci jsou popsány základní postupy při zpracování:
Generování Platby předem z Deníku plateb
daňové doklady generované ihned
daňové doklady generované odloženě – jednotlivě nebo hromadně dávkovou úlohou
Generování Platby předem dodatečně na základě vyrovnání platby na saldu
Generování Platby předem dodatečně bez vyrovnání platby.
Deník plateb
Deník plateb slouží k předzpracování dat z výpisu, identifikaci protistrany (kdo platbu poslal) a účelu platby (k jaké pohledávce se platba vztahuje). Deník plateb zpracujte obvyklým způsobem, tak aby pro přijaté platby byl vyplněný správný zákazník a platba byla vyrovnána (pokud je to možné) s otevřenými Položkami zákazníka.
Systém identifikuje a označuje platby předem dle nastavení Evidovat jako platbu předem (Nastavení prodeje a pohledávek):
Jen vyrovnané
Identifikace se spouští:
při vyrovnání platby na řádku deníku (tj. při vložení Čísla vyrovnání dokladu)
při vyrovnání v okně Vyrovnat položky zákazníka (tj. s vyplněním ID vyrovnání), po zavření okna tlačítkem OK.
Systém platbu předem stanoví podle libovolné vyrovnávané prodejní faktury (doklad musí existovat v seznamu Účtovaných prodejních faktur) - splňující podmínky platby předem.
Všechny na zákazníka
Platba, která nebude vyrovnána a Typ účtu = Zákazník, bude automaticky označená jako platba předem v okamžiku vyplnění čísla zákazníka;
U platby, která bude vyrovnána, se spustí identifikace platby předem při vyplnění Čísla vyrovnání dokladu, případně ID vyrovnání. Platba předem je identifikována, pokud alespoň jeden doklad vyrovnaný s touto platbou je prodejní faktura, splňující podmínky pro určení platby předem.
Pokud je platba vyrovnána jen částečně a vzniká přeplatek (zůstatek platby je větší než je povolená odchylka platby) a podle vyrovnání nebyla indikována Platba předem, označí se řádek deníku rovněž jako platba předem.
Pokud je platba identifikována jako platba předem, nastaví se příznak Generovat platbu předem a dle dalších nastavení příznaky:
Generovat daňový doklad k platbě předem ihned,
Neúčtovat daňový doklad u platby předem.
Tyto příznaky můžete následně na řádku deníku ručně změnit.
Daňový doklad k platbě předem vzniká vždy jen k celé platbě. Pokud je platba hromadná a zdanit se má pouze část přijaté platby, je nutné platbu v deníku rozdělit na dílčí platby.
Kombinace nastavení pro výsledné označení platby předem a použití účto skupiny zákazníka:
...
Nastavení prodeje a pohledávek
...
Deník plateb
...
Způsob účtování plateb
...
Evidovat jako platbu předem
...
PLATBY NEVYROVNANÉ
nebo PLATBY BĚŽNÉ částečně vyrovnané
...
PLATBY vyrovnané DOPŘEDU (plně i částečně)
...
Účto sk.
...
Generovat
...
Účto sk.
...
Generovat
...
Běžná platba
...
Jen vyrovnané
...
TUZ
...
Ne
...
TUZ_P
...
Ano
...
Běžná platba
...
Všechny na zákazníka
...
TUZ_P
...
Ano
...
TUZ_P
...
Ano
...
Platba dopředu
...
Jen vyrovnané
...
TUZ_P
...
Ne
...
TUZ_P
...
Ano
...
Platba dopředu
...
Všechny na zákazníka
...
TUZ_P
...
Ano
...
TUZ_P
...
Ano
Úpravy v Deníku plateb
Nová pole pro platby předem
Pro platby přijaté předem je deník rozšířen o tři nová pole, která jsou na řádku deníku dostupná po zapnutí modulu (Povolit tvorbu platby předem = Ano):
Generovat platbu předem (Generate Prepayment)
Tento příznak určuje, že daná platba bude zaevidována v modulu Platby předem. Automatické označení platby na řádku deníku se řídí pravidly identifikace platby předem - stavem vyrovnání řádku s použitím dalších nastavení z Nastavení prodeje a pohledávek (Vytvořit platbu předem dle období a Evidovat jako platbu předem).
Před zaúčtováním deníku lze tento příznak zapnout nebo vypnout ručně. Pokud je příznak zaškrtnutý, je pro platbu vyžadována Účto skupina zákazníka s příznakem Použít pro platby předem = Ano.
Generovat daňový doklad k platbě předem ihned (Generate Prepayment Invoice Immediately)
Tento příznak určuje, že k zaevidované Platbě předem bude vygenerovaný daňový doklad ihned při účtování platby v Deníku plateb. Příznak zapne systém na základě nastavení v Nastavení prodeje a pohledávek v poli Generovat daňový doklad k přijaté platbě ihned
Před zaúčtováním deníku lze tento příznak zapnout nebo vypnout ručně. Pokud je příznak vypnutý a tvorba daňového dokladu není blokována, bude se daňový doklad generovat až dodatečně dávkovou úlohou.
Neúčtovat daňový doklad u platby předem (Dont Charge VAT for Payment Ahead)
Tento příznak určuje, že k Platbě předem nebude daňový doklad nikdy generován. V deníku lze tento příznak zapnout ručně. Příznak může navíc nastavit i systém na pozadí při účtování deníku, a to na základě nastavení na DPH obchodní účto skupině nebo na Účto skupině zákazníka
Vyrovnávání plateb v deníku
Úprava data vyrovnání (Adjustment of applying date)
Standardně je možné v Deníku plateb vyrovnávat platby pouze s položkami zákazníka, jejichž Zúčtovací datum je stejné nebo nižší než Zúčtovací datum platby. Pokud je zapnutý modul Platby předem, umožní systém vybrat pro vyrovnání platby i Položku zákazníka s vyšším Zúčtovacím datem, než je datum platby a toto vyrovnání následně i zaúčtovat.
Vyrovnání platby s jednou položkou (Payment applied with one entry)
Platbu lze vyrovnat ručně výběrem dokladu (Položky zákazníka) na řádku deníku. Při vyrovnání systém vyhodnocuje, zda jsou splněny podmínky pro generování Platby předem a pokud ano, nastaví příznak Generovat platbu předem.
Vyrovnání platby s více položkami (Payment applied with multiple entries)
...
Pro vyrovnání více položek s jednou platbou je nutné použít funkci Vyrovnat položky.
...
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:
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 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 chapterhttps://iao.atlassian.net/wiki/spaces/OCDOC/pages/edit-v2/32637019#Kontrola-znam%C3%A9nek-vyrovn%C3%A1van%C3%BDch-polo%C5%BEek . Znaménka vyrovnávaných položek se kontrolují při účtování platby. Příklad chybové hlášky při porušení tohoto pravidla:
...
Při vyrovnání systém vyhodnocuje, zda jsou alespoň u jedné položky splněny podmínky pro generování Platby předem a pokud ano, nastaví příznak Generovat platbu předem.
...
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)
Pokud byla platba označená příznakem Generovat platbu předem = Ano a bylo provedeno vyrovnání, pak se při smazání nebo při změně vyrovnání (Čísla dokladu vyrovnání nebo ID vyrovnání) znovu spouští funkce na identifikaci platby předem. Totéž při smazání nebo změně čísla zákazníka. Příznaky se revidují a nastaví se dle aktuálního stavu.
Rozdělení hromadné platby
...
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 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 . Při rozdělení platby systém u jednotlivých položek vyhodnocuje, zda jsou splněny podmínky pro generování Platby předem a pokud ano, nastaví na jednotlivých dílčích platbách příznak Generovat platbu předem.
Účto skupina zákazníka v deníku
Výchozí účto skupina zákazníka (Default customer posting group)
Pro zaúčtování platby je důležitá Účto skupina zákazníka vyplněná v Deníku plateb. Účto skupinu zákazníka vyplní systém při založení řádku deníku po vyplnění čísla zákazníka,přičemž použije buď výchozí účto skupinu z Karty zákazníka (např. pro účet pohledávky = 311.xxx) nebo její náhradní účto skupinu pro platby předem (např. pro účet pohledávky = 311.xxx). Při výběru účto skupiny je důležité nastavení Způsobu účtování plateb v Nastavení prodeje a pohledávek. Současně systém přihlíží i na to, zda je na řádku zapnutý příznak Generovat platbu předem..Účto skupina zákazníka z vyrovnávané položky (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)
Pokud je platba na řádku deníku vyrovnána, může být výchozí účto skupina zákazníka při vyrovnání automaticky nahrazena účto skupinou zákazníka z vyrovnávané položky.
Jestliže je k platbě připárována jedna nebo více položek a alespoň jedna splňuje podmínky pro platbu předem, pak systém platbu označí příznakem Generovat platbu předem a použije Účto skupinu zákazníka určenou pro platbu předem.
Jestliže na platbě dojde ke změně vyrovnání nebo zákazníka, může dojít ke změně účto skupiny na řádku platby:
Při změně zákazníka je smazáno vyrovnání a účto skupina zákazníka se nastaví dle Nastavení prodeje a pohledávek
Při smazání zákazníka je smazáno vyrovnání, ale účto skupina zákazníka zůstává beze změny (standard BC)
Při změně vyrovnání se účto skupina aktualizuje dle nového vyrovnání
Při smazání vyrovnání se účto skupina zákazníka nastaví dle Nastavení prodeje a pohledávek.
Účtování deníku plateb
Účtování Deníku plateb (Posting of payment journal)
Jakmile je deník připravený k zaúčtování (jsou přiřazení zákazníci, dodavatelé nebo finanční účty, platby jsou dle možností vyrovnané, platby předem mají nastavené příznaky), můžete deník zaúčtovat.
Účtování vyrovnání platby (Posting of applying)
Jestliže je modul Platby předem vypnutý, systém nedovolí vyrovnat s platbou položky zákazníka s vyšším Zúčtovacím datem. Při účtování pak všechny účtované položky mají nejvyšší datum z vyrovnávaných položek, tj. datum platby.
Pokud je modul Platby předem zapnutý a k přijaté platbě je párována položka zákazníka s vyšším Zúčtovacím datem, než je datum platby, systém umožní toto vyrovnání zaúčtovat, ale při účtování změní Zúčtovací datum transakce položek:
vyrovnání
odchylky platby
kurzových rozdílů
Toho je dosaženo „odloženým“ párováním platby až na saldu zákazníka v rámci transakce účtování řádku deníku plateb. Při tomto dvoufázovém účtování, které se spouští za podmínky, že:
je zapnutý modul Platby předem
Typ účtu nebo Typ protiúčtu je Zákazník
na řádku deníku je vyrovnání (buď Číslo vyrovnání dokladu nebo ID vyrovnání)
rozdělí systém účtování na dvě fáze:
zaúčtování platby bez vyrovnání a
následné vyrovnání platby na saldu s položkami, které byly vybrané a označené k vyrovnání v deníku.
Položka, která je účtovaná v deníku (Platba), je při použití funkce pro vyrovnání na saldu vždy naplněna do hlavičky vyrovnání.
Zaúčtovaná platba tak bude mít Zúčtovací datum převzaté z deníku, zatímco vyrovnání (tj. detailní položky zákazníka typu Vyrovnání) a s ním spojené odchylky platby, kurzové rozdíly apod. budou mít Zúčtovací datum převzaté z faktury vyrovnávané dopředu.
Upozornění:
Standard BC: Pokud je párováno více položek (1:N), použije systém pro vyrovnání nejvyšší Zúčtovací datum ze sady položek vstupujících do vyrovnání.
Pro správné datum vyrovnání platby předem (pokud mají faktury různá Zúčtovací data) je tedy potřeba buď hromadnou platbu rozdělit a párovat samostatně dílčí platby, nebo zaúčtovat platbu bez párování a vyrovnat ji ručně na saldu nebo použít úlohu Vyrovnat položky zákazníka.
Účtovaný finanční deník (Posted general journal)
Po zaúčtování Deníku plateb se deník smaže. Pokud je na listu deníku nastaveno Kopírovat do Účtovaného finančního deníku = Ano, účtované řádky se propisují do Účtovaného finančního deníku, včetně nových polí Generovat platbu předem, Generovat daňový doklad k platbě předem ihned a Neúčtovat daňový doklad u platby předem.
Při zpětném kopírování zaúčtovaného řádku do živého deníku je řádek zkopírován včetně uvedených příznaků.
Platby předem.
Přehled plateb předem
Jestliže byl na účtované platbě v deníku zaškrtnutý příznak Generovat platbu předem, vytvořil se v evidenci Plateb předem záznam typu Platba.
Pro zobrazení všech vygenerovaných Plateb předem vyhledejte Přehled plateb předem. Kartu konkrétní Platby předem zobrazíte rozkliknutím Čísla položky nebo tlačítkem Zobrazit.
Popis karty Platby předem najdete v
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 https://iao.atlassian.net/wiki/spaces/OCDOC/pages/32636989/Evidence+Platby+p+edem#Platba-p%C5%99edem
Daňové doklady k platbě předem
...
Tax documents for prepayment
Tax invoices for Payment Ahead)
Jestliže byl na platbě v deníku zaškrtnutý příznak Generovat daňový doklad k platbě předem ihned a tvorba daňového dokladu nebyla potlačena (buď ručně uživatelem v deníku nebo systémem na pozadí při účtování platby, resp. při založení hlavičky Platby předem), vygeneroval se daňový doklad, jehož číslo je vyplněno v poli Číslo daňového dokladu k přijaté platbě. Tento doklad můžete zobrazit tlačítkem Daňový doklad nebo rozkliknutím Čísla daňového dokladu k přijaté platbě.
Daňové doklady generované dodatečně (Tax invoices generated additionally)
Jestliže na platbě v deníku příznak Generovat daňový doklad k platbě předem ihned nebyl zaškrtnutý a tvorba daňového dokladu není potlačena, daňový doklad se nevygeneruje, ale na Platbě předem se zaškrtnou příznaky Generovat doklady a Generovat daňový doklad.
Pro tyto Platby předem je možné vygenerovat daňový doklad dodatečně:
...
buď jednotlivě ručně z karty Platby předem tlačítkem Akce > Zaúčtovat daňový doklad (Post Invoice),
...
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 Ahead), vizseehttps://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 nebo je systém vygeneruje automaticky na pozadí při účtování libovolného finančního deníku nebo při účtování vyrovnání na saldu,pokud při tomto účtování byla generována platba předem (platí pro již existující Platby předem s příznakem Generovat daňový doklad k platbě předem ihned = Ano).
Po vygenerování daňového dokladu se na Platbu předem zapíše číslo dokladu a příznaky Generovat doklady a Generovat daňový doklad k přijaté platbě se smažou.
Opravy daňového dokladu (Tax document corrections)
Vygenerovaný daňový doklad k platbě předem nelze standardními funkcemi ani stornovat, ani k nim vytvořit opravný dobropis:
...
Vystavený daňový doklad lze zrušit pouze vyrovnáním Položky zákazníka (platby), čímž je automaticky vygenerován daňový dobropisu k platbě předem.
Daňové dobropisy k platbě předem
Daňové dobropisy generované ihned (Tax credit memos generated immediately)
Jestliže byla platba v Deníku plateb vyrovnána s jednou nebo více fakturami, vzniknou pro danou Platbu předem současně záznamy typu Využití. Jestliže je současně v Nastavení prodeje a pohledávek nastaveno, že se daňové dobropisy mají generovat ihned a daňový doklad k platbě předem je již vygenerován, systém vygeneruje daňový dobropis, jehož číslo zapíše v poli Číslo dobropisu k přijaté platbě. Tento doklad můžete zobrazit tlačítkem Daňový dobropis nebo rozkliknutím Čísla dobropisu k přijaté platbě.
Daňové dobropisy generované dodatečně (Tax credit memos generated additionally)
Jestliže v Nastavení prodeje a pohledávek je nastaveno Generovat dobropis k přijaté platbě ihned = Ne nebo daňový doklad dosud nebyl vygenerovaný (příznak na Platbě předem typu Platba je Generovat daňový doklad k přijaté platbě = Ano), daňový dobropis se při vyrovnání nevygeneruje, ale na Platbě předem typu Využití se zaškrtnou příznaky Generovat doklady a Generovat dobropis k přijaté platbě.
Pro tato Využití platby předem je možné vygenerovat daňový dobropis dodatečně:
buď jednotlivě ručně z karty Platby předem tlačítkem Akce > Zaúčtovat daňový dobropis (Post Credit Memo),
nebo hromadně dávkovou úlohou Generovat daňové doklady a dobropisy 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:
...
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), viz kapsee 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 nebo je systém vygeneruje automaticky na pozadí při účtování libovolného finančního deníku nebo při účtování vyrovnání na saldu,pokud při tomto účtování byla generována platba předem (platí pro již existující Platby předem s příznakem Generovat daňový dobropis k platbě předem ihned = Ano)
Daňový dobropis účtovaný ručně z karty Platby předem typu Využití:
...
Po vygenerování daňového dobropisu se na Platbu předem zapíše číslo dobropisu a příznaky Generovat doklady a Generovat dobropis k přijaté platbě se smažou
Zobrazení Platby předem z položky zákazníka
Po zaúčtování platby s příznakem Generovat platbu předem vznikne na saldu zákazníka Položka zákazníka, která je označená příznakem Platba předem.
Z této položky si pak můžete Platbu předem (Platbu + všechna související Využití) zobrazit tlačítkem Platby předem.
Vyrovnání platby ručně na saldu
Pro vyrovnávání Položek zákazníka se používá standardní funkce Vyrovnat položky.
Pokud je zapnutý modul Platby předem, jsou na saldu zákazníka aktivovány tyto úpravy:
Kontrola znamének vyrovnávaných položek
Kontrola stejné měny při vyrovnání (viz Nastavení prodeje a pohledávek)
Generování daňových dokladů a daňových dobropisů k existujícím Platbám předem
Zpětné generování Plateb předem při vyrovnání platby, pokud jsou splněny podmínky pro jejich tvorbu
Kontrola znamének vyrovnávaných položek
Je-li modul Platby předem aktivní, je párování omezeno tak, že k vyrovnávací položce v hlavičce vyrovnání mohou být párované pouze položky s opačným znaménkem (standardně lze v BC vyrovnávat v jedné transakci více kladných a více záporných položek). Systém kontroluje znaménka při účtování vyrovnání nebo v náhledu účtování vyrovnání.
Kontrola stejné měny
Vzhledem k možnosti generovat platby předem zpětně, a to i v případě, že platba již byla částečně vyrovnána s fakturou, která nesplňuje podmínky pro platbu předem, neumožní systém po zapnutí modulu vyrovnávat položky zákazníka v různých měnách. Systém kontroluje nastavení – pokud je zapnutý modul Platby předem, musí být nastaveno Vyrovnání mezi měnami = Žádné.
Vyrovnání na saldu – Platba předem existuje
Pokud byla v Deníku plateb zaúčtovaná platba s příznakem Generovat platbu předem, která nebyla vyrovnaná, případně byla vyrovnaná jen částečně, můžete tuto platbu vyrovnat ručně na saldu standardní funkcí Vyrovnat položky.
V řádcích vyrovnání vyberete fakturu (jednu nebo více), se kterou má být platba vyrovnána, a řádek označíte v poli ID vyrovnání.
Při vyrovnání musí být splněna kontrola na znaménko částky.
Vyrovnání zaúčtujte. Před zaúčtováním můžete zkontrolovat v Náhledu účtování, zda bude vytvořen daňový dobropis (je vytvořena DPH položka a věcné položky pro daňový dobropis).
Po zaúčtování vyrovnání se v evidenci Platby předem vygeneruje nový záznam typu Využití.
Pro tento záznam se generuje Daňový dobropis k platbě předem, a to dle nastavení buď ihned nebo odloženě. Podmínkou pro vygenerování dobropisu je, že Daňový doklad k platbě předem již byl vygenerován. Daňový dobropis se nikdy negeneruje, pokud bylo generování daňového dokladu zablokováno (např. nastavením na DPH obchodní účto skupině).
Odchylky platby (Payment Tolerances)
Záznam typu Využití a jemu odpovídající dobropis je vygenerován ve výši vyrovnání. Jestliže při vyrovnání platby byla uplatněná odchylka platby, která uzavírá platbu na saldu, je tato odchylka připočtena k dobropisu tak, aby součet záznamů typu Využití odpovídal částce přijaté platby 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)
Na vytvořeném daňovém dobropisu se použije Datum DPH získané při vyrovnání platby:
Když je platba vyrovnaná s fakturou, která má hlavičku (Účtovanou prodejní fakturu) a její Datum DPH je vyšší než Zúčtovací datum platby, použije se Datum DPH z hlavičky faktury
Ve všech ostatních případech se použije Zúčtovací datum vyrovnání
Vyrovnání na saldu – Platba předem neexistuje
Pokud byla přijatá platba zaúčtovaná na saldo zákazníka, ale Platba předem se negenerovala (v Deníku plateb bylo Generovat platbu předem = Ne), lze za určitých podmínek Platbu předem vygenerovat dodatečně, až po vyrovnání platby na saldu:
Platba musí mít Účto skupinu zákazníka určenou pro Platby předem (Použít pro platby předem = Ano)
Platba musí být vyrovnána s položkou typu Faktura (hlavičkový doklad Účtovaná prodejní faktura existuje). Při vyrovnání s položkou jiného typu (prázdný nebo Refundace) nebo s fakturou účtovanou v deníku se Platba předem negeneruje
Datum DPH vyrovnávané faktury musí být před datem platby. Dle nastavení se testují buď celé měsíce nebo jednotlivé dny (Vytvořit platbu předem dle období = Ano/Ne)
U hromadné platby vyrovnávané s více fakturami musí výše uvedené podmínky splňovat alespoň jedna vyrovnávaná faktura.
Při částečném vyrovnání platby, pokud jsou podmínky splněné, se vygeneruje Platba předem v plné výši přijaté platby.
Upozornění: Pokud se účtuje vyrovnání položek zákazníka, kdy je v rámci vyrovnání vygenerovaná nová Platba předem, spouští systém následně na pozadí generování daňových dokladů a daňových dobropisů,
a to pro všechny existující Platby předem, které čekají na vygenerování daňových dokladů/dobropisů a současně mají příznak generovat „ihned“!
Příklad zpětného generování Platby předem – vyrovnání platby s fakturou 1:1
K vyrovnání jsou připraveny dvě Položky zákazníka splňující podmínky pro zpětné generování Platby předem. Platba předem dosud nebyla vygenerována (na Položce zákazníka viz pole Platba předem = Ne).
Položky vyrovnejte standardní funkcí Vyrovnat položky.
Poznámka: Pro zpětné generování Platby předem na výběru položky do hlavičky vyrovnání nezáleží, do hlavičky může být vybrána jak platba, tak i faktura. Pokud se však má při vyrovnání použít odchylka platby, musí být v hlavičce vyrovnání umístěna platba (standard BC).
Před zaúčtováním můžete zkontrolovat vyrovnání v Náhledu účtování. Již v náhledu je vidět, zda je generovaný daňový doklad a daňový dobropis (tj. jsou vygenerované DPH položky). Můžete zkontrolovat jak Položky DPH, tak i Věcné položky generovaných dokladů. Položky nejsou zobrazené pouze v případě, že je nastaveno odložené generování daňových dokladů a/nebo daňových dobropisů.
Vyrovnání zaúčtujte
Po spuštění účtování vyrovnání dojde k vyrovnání položek. Platba na saldu je označená jako Platba předem.
V evidenci Plateb předem vzniknou dva nové záznamy – Platba a Využití.
Současně je vygenerován daňový doklad na řádku Platba a daňový dobropis na řádku Využití.
Vyrovnání Platby automaticky dávkovou úlohou
Otevřené Položky zákazníka také můžete vyrovnávat hromadně úlohou Vyrovnat položky zákazníka. Způsob párování je nastaven na Kartě zákazníka. Pro každého zákazníka tak je možné nastavit jiné parametry párování.
Upozornění: Nastavení automatického vyrovnání na Kartě zákazníka musí být v souladu s ostatním nastavením systému, zejména pak s nastavením vyrovnání položek v různých měnách. Pro správnou funkčnost modulu Financování je nutné povolit vyrovnávání Položek zákazníka pouze ve stejných měnách (Nastavení prodeje a pohledávek, Vyrovnání mezi měnami = Žádné). Při tomto nastavení je pak doporučeno na Kartě zákazníka nastavit měnu jako parametr vyrovnání, jinak bude párování položek v různých měnách vyhodnoceno jako chyba a párování daného zákazníka bude přerušeno.
Nastavení
Nastavení požadované pro automatické vyrovnání položek zákazníka je popsané v Nastavení pro úlohu Vyrovnat položky zákazníka
Níže je uveden pouze přehled nastavení (tabulky a pole):
Karta zákazníka (Customer Card)
...
Metoda vyrovnání (Application Method)
...
Automatické vyrovnání (Automatic Apply)
...
Způsob vyrovnání dle znaku (Type of Apply by Field)
...
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.
Note: For 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 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))
Šablona zákazníka (Customer Template)
Metoda vyrovnání (Application Method)
Automatické vyrovnání (Automatic Apply)
Způsob vyrovnání dle znaku (Type of Apply by Field)
Znaky vyrovnání (1-8) (Apply by Field (1-8))
Úloha Vyrovnat položky zákazníka
Dávková úloha Vyrovnat položky zákazníka (Apply Customer Ledger Entries) umožňuje hromadně párovat otevřené Položky zákazníka. V úloze se zpracovávají pouze zákazníci, kteří mají na Kartě zákazníka povoleno automatické párování (Automatické vyrovnání = Ano) a současně mají nastavený alespoň jeden parametr párování (Znaky vyrovnání 1 až 8).
Výběr zákazníků je možné dále omezit uživatelským filtrem v dialogovém okně při spuštění úlohy.
Pro vyrovnání položek úloha používá stejnou funkci jako uživatel při ručním párování na saldu. To znamená, že úloha vybere první otevřenou položku daného zákazníka a tuto položku nastaví jako „vyrovnávací položku“ (hlavičku vyrovnání). K této položce hledá „vyrovnávané položky“ (řádky vyrovnání)
V řádcích jsou otevřené položky daného zákazníka s opačným znaménkem, které odpovídají nastaveným párovacím parametrům (Vyrovnávacím znakům 1 až 8) na Kartě zákazníka a uživatelským filtrům zadaným v dialogovém okně při spuštění úlohy.
Pokud úloha najde pouze jednu položku k vyrovnání, označí ji (při ručním vyrovnání toto ID vyrovnání nastavuje uživatel v řádcích vyrovnání), a vyrovnání zaúčtuje.
Pokud úloha najde více shodných položek (např. více faktur se stejným variabilním symbolem), pak tyto položky setřídí podle Data splatnosti, vybere položku s nejstarším Datem splatnosti a toto vyrovnání zaúčtuje. Pokud je vyrovnávací položka (v hlavičce vyrovnání) po vyrovnání stále otevřená, znovu se provádí výběr další položky k vyrovnání. Znamená to, že se transakce vyrovnání vždy účastní pouze 2 položky. Tím je zabezpečeno správné datum vyrovnání zejména u hromadných plateb!
Platby předem
Pokud je párována Platba předem, případně položka splňuje podmínky pro zpětné generování Platby předem, postupuje úloha stejně jako u ručního párování.
Spuštění úlohy
Úlohu vyhledejte pomocí vyhledávací lupy. Po spuštění úlohy je možné v dialogovém okně zadat filtry.
Na záložce Možnosti (Options) je možné nastavit filtry na Položky zákazníka (Customer Ledger Entries).
Filtr dimenze 2 (Dimension 2 Filter) (Smlouva; Contract)
Úloha vybírá do párování pouze položky zákazníka se zadanými hodnotami dimenze, např. smlouvy číslo „od-do“, nebo smlouvy začínající „FL*“ apod.
Pokud je pole prázdné, vstupují do párování všechny položky, na Globální dimenzi 2 položky se nepřihlíží
Filtr je platný jak pro vyrovnávací položku (hlavičku vyrovnání), tak i pro vyrovnávané položky (řádky vyrovnání)
Filtr data (Date Filter)
Filtr se použije pouze pro vyrovnávací položku (hlavičku vyrovnání)
Lze zadat i období „od-do“
Toto pole se obvykle nevyplňuje; je-li prázdné, vstupují do párování všechny položky, na Zúčtovací datum položek se nepřihlíží
Filtr typu dokladu (Document Type Filter)
Filtr na Typ dokladu se použije pouze pro vyrovnávací položku (hlavičku vyrovnání).
Pokud např. chcete párovat s fakturou pouze platby, ale ne dobropisy, zadáte typ Platba. Úloha pak bude procházet pouze platby a ty bude párovat s nalezenými položkami (obvykle fakturami).
Typ dokladu musíte vyplnit ručně, nelze ho vybrat z číselníku (typ ' ' = „prázdný“, Platba, Faktura, Dobropis, Penále, Upomínka, Refundace). Pokud nebude pole vyplněné, budou do zpracování zahrnuté všechny položky bez ohledu na typ.
Filtr kódu měny (CurrencyCode Filter)
Úloha filtruje do vyrovnání pouze položky se zadaným Kódem měny; pro zadání filtru na lokální měnu je potřeba zadat znaky (apostrofy) pro prázdnou hodnotu:
Pokud pole zůstane prázdné, vstupují do párování všechny položky, na měnu položky se nepřihlíží
Poznámka: jestliže je povoleno vyrovnávání položek pouze ve stejných měnách (viz Nastavení prodeje a pohledávek) a párovací parametry by splnily položky obsahující různou měnu, pak je párování těchto položek ukončeno chybovou hláškou, která se zapíše do logu a párování položek daného zákazníka je ukončeno. Úloha pokračuje párováním položek dalšího zákazníka.
Filtr účto skupiny zákazníka (Customer Posting Group Filter)
Úloha vybírá do vyrovnání (do hlavičky i do řádků) pouze položky se zadanou účto skupinou zákazníka. Do filtru lze zadat i více účto skupin
Pokud je pole prázdné, vstupují do párování všechny položky, na Účto skupinu zákazníka na položce se nepřihlíží
Vyloučit položky s vyplněným Vyčkat (Skip Entries with On Hold not-blank)
Filtr platí jak pro hlavičku, tak i pro řádky vyrovnání
Pole s hodnotami Ano/Ne
Ano (Yes): Pokud je pole zaškrtnuté, pak úloha bude párovat pouze položky, které mají pole Vyčkat prázdné. Z párování je tak možné vyloučit např. počáteční fakturu na prodejní cenu u Splátkového prodeje, případně další položky ručně označené uživatelem v poli Vyčkat.
Ne (No): Pokud pole není zaškrtnuté, na pole Vyčkat na Položce zákazníka se nepřihlíží. V tomto případě můžete omezit výběr položek pro konkrétní hodnoty Vyčkat zadáním filtru v dalším poli Filtr vyčkat (např. vyloučit jen faktury Splátkového prodeje, pokud budou mít v poli Vyčkat jedinečnou hodnotu)
Filtr pole Vyčkat (Filter for field On Hold)
Filtr platí jak pro hlavičku, tak i pro řádky vyrovnání
Pokud je pole prázdné, vstupují do párování všechny položky, na pole Vyčkat na položce zákazníka se nepřihlíží.
Pokud je pole vyplněné, vybírá úloha do párování pouze položky se zadanou hodnotou Vyčkat. Do filtru lze zadat i více hodnot, např.
Filtr vyplňujte pouze v případě, že předchozí pole Vyloučit položky s vyplněným (neprázdným) Vyčkat není zaškrtnuté
Hlavním cílem tohoto filtru je však vyloučit z párování fakturu na prodejní cenu u Splátkového prodeje. Na položce zákazníka pro tuto fakturu můžete ručně vyplnit pole Vyčkat, např. kód „SP“. Filtr v tomto případě by byl vyplněný následovně:
Záložka Zákazník (Customer Tab)
Na této záložce můžete zadat uživatelský filtr polí, která jsou na kartě zákazníka (např. Číslo zákazníka, Název, IČO…). Pokud nezadáte žádný filtr, do párování vstupují všichni zákazníci.
Spuštění vyrovnání
Po nastavení filtrů (není povinné) spusťte vyrovnání tlačítkem OK.
Úloha prochází karty zákazníků, kteří mají povoleno automatické párování. Pro tyto zákazníky prochází postupně jednotlivé otevřené Položky zákazníka. První nalezenou položku vyplní do hlavičky vyrovnání a dle párovacích parametrů na kartě zákazníka a filtrů zadaných v dialogovém okně hledá položky k vyrovnání. Pokud najde položku vhodnou ke spárování, tyto dvě položky vyrovná. Tento postup opakuje s další otevřenou položkou. Jestliže je položka vyrovnaná jen částečně, vstupuje do dalšího párování.
Jestliže je párovaná platba, která má záznam v evidenci Platby předem (typ Platba), vygeneruje se na základě vyrovnání záznam typu Využití.
Pokud se páruje platba, která splňuje podmínky pro generování platby předem, ale Platba předem dosud vygenerovaná není, pak se při vyrovnání generuje Platba předem zpětně (záznam typu Platba i Využití).
Je-li v Nastavení financí nastaveno účtování odchylky platby „na dotaz“, pak systém automaticky potvrdí zaúčtování rozdílu jako odchylku.
Jestliže úloha najde položky vhodné ke spárování, ale toto párování skončí při účtování chybovou hláškou, pak:
Párování této dvojice položek je přerušeno, položky zůstávají nevyrovnané a chyba je zapsána do Chybového logu (Error Log)
Párování daného zákazníka je ukončeno, přičemž položky tohoto zákazníka vyrovnané před transakcí s chybou zůstávají vyrovnané.
Úloha pokračuje párováním dalšího zákazníka.
Zrušení vyrovnání
Pokud byla přijatá platba vyrovnána s nesprávnou položkou, můžete vyrovnání zrušit. V případě, že se jednalo o Platbu předem, bude při zrušení vyrovnání stornován i záznam Využití.
Zrušení vyrovnání se provádí standardně z Položek zákazníka pomocí funkce Zrušit vyrovnání položek. Po spuštění funkce systém zobrazí položky vyrovnání, které budou zrušeny.
Při zrušení vyrovnání se aktualizuje evidence Platby předem.
Záznam typu Platba vč. daňového dokladu, pokud byl vygenerovaný, zůstává beze změny. Jestliže bylo generování daňového dokladu potlačeno při účtování platby (zaškrtnutím příznaku Neúčtovat daňový doklad u platby předem v deníku nebo na základě použité DPH obchodní účto skupiny a případně Globální dimenze 2 na platbě nebo na základě použité Účto skupiny zákazníka na platbě), pak příznaky zůstávají vypnuté.
Záznam typu Využití se označí jako Stornovaný, nový záznam nevzniká. Pokud jde o generování daňových dokladů a dobropisů, mohou nastat tyto případy:
Jestliže daňový doklad není a nemá být generovaný (příznak Generovat daňový doklad = Ne na Platbě), pak na Využití nebude žádné generování, ani daňového dobropisu, ani daňového vrubopisu.
Jestliže daňový doklad již je vygenerovaný nebo čeká na vygenerování a:
jestliže již je vygenerovaný daňový dobropis, pak se bude vždy generovat daňový vrubopis (ihned nebo dodatečně dávkovou úlohou)
jestliže daňový dobropis čeká na vygenerování, pak se příznak pro generování dobropisu smaže, k přijaté platbě tak zůstane pouze daňový doklad, který čeká na nové využití.
Dávková úloha Generovat daňové doklady k platbám předem
Daňové doklady k předem přijatým platbám nemusíte generovat ihned při účtování platby v deníku, ale je možné je hromadně vygenerovat až dodatečně. K tomu slouží dávková úloha Generovat daňové doklady k platbám předem (Generate Tax Documents and Credit Memos for Payments Ahead). Úloha je dostupná vyhledáním přes lupu .
Tato dávková úloha obsahuje tři samostatné úlohy:
Dodatečné generování Plateb předem
Kontrola nastavení příznaků před generováním dokladů
Generování daňových dokladů (Daňových dokladů, Daňových dobropisů, Daňových vrubopisů)
Po spuštění úlohy se otevře dialogové okno, které obsahuje tři záložky.
Záložka Možnosti (Options) obsahuje pole:
Provést dodatečné generování Plateb předem (Perform additional generate Payment Ahead)
Volby Ano / Ne
Pole zaškrtněte, pokud se má spustit úloha č. 1
Od zúčtovacího data pro dodatečné generování (From Posting Date for Additional Generate)
Datum „od“ používá úloha č. 1. Zadané datum se použije jako filtr Zúčtovacího data na Položkách zákazníka
nepovinné, pokud není vyplněno, bere všechny položky
Do zúčtovacího data pro dodatečné generování (To Posting Date for Additional Generate)
Datum „do“ používá úloha č. 1. Zadané datum se použije jako filtr Zúčtovacího data na Položkách zákazníka
Výchozí hodnota je Pracovní datum, můžete ho změnit
Datum „do “je povinné pole a musí být stejné nebo vyšší než datum Od zúčtovacího data pro dodatečné generování
Provést kontrolu nastavení příznaků před generováním dokladů (Process Flag Checking before Posting)
Volby Ano / Ne
Pole zaškrtněte, pokud se má spustit úloha č. 2
Provést generování daňových dokladů (Process Tax documents generating)
Volby Ano / Ne
Pole zaškrtněte, pokud se má spustit úloha č. 3
Pokud nebude na záložce Možnosti zaškrtnuta žádná ze tří možných úloh, skončí spuštění chybovou hláškou „Nebyla vybrána žádná volba“.
Záložka Filtr: Položka zákazníka (Cust. Ledger Entry):
Filtry použije úloha č. 1
Záložka Filtr: Platba předem (Filter: Payment Ahead):
Filtry použije úloha č. 2 a 3
Úloha č. 1 – Dodatečné generování Plateb předem (Task 1 - Additional generate Payment Ahead)
Tato úloha generuje nové záznamy do evidence Plateb předem, a to pro Položky zákazníka, které splňují podmínky:
Typ dokladu = Platba
Účto skupina zákazníka má příznak Použít pro platbu předem = Ano
Platba předem dosud není k této položce vygenerovaná
Otevřená = Ano
Zůstatek k vyrovnání je vyšší než maximální odchylka platby pro příslušnou měnu, ve které je platba zaúčtována
Pro tyto položky zákazníka vygeneruje úloha Platbu předem typu Platba. Pokud je platba částečně vyrovnaná, pak úloha vygeneruje i záznamy typu Využití. Pro vyrovnání, které bylo zrušeno, se Využití negeneruje. Položku zákazníka (platbu) označí příznakem Platba předem = Ano.
Na vygenerovaných záznamech se nastaví příznaky pro generování daňových dokladů a dobropisů.
Typicky se tato úloha používá pro dodanění plateb od zákazníka, které mají na konci měsíce zůstatek.
Nastavení příznaků (Setup flags)
Na Platbu předem typu Platba se jako výchozí hodnota „generovat doklady“ nastaví Ano. Následně úloha smaže příznaky
dle nastavení DPH obchodní účto skupiny:
Blokovat vytvoření daňového dokladu platby předem = Ano
Blokovat vytvoření daňového dokladu platby předem = Ne a současně v Blokovat vytvoření daňového dokladu pro typy financování je nastavený filtr na Typ financování
dle nastavení Účto skupiny zákazníka
Generovat daňové doklady k platbám předem = Ne
Příznaky na Platbě předem typu Využití jsou nastaveny/smazány dle příznaků na záznamu typu Platba (tj. pokud jsou generovány daňové doklady, musí být generovány i daňové dobropisy).
Po ukončení úlohy č.1 přejde systém na další úlohy dle zadání v dialogovém okně.
Úloha č. 2 – Kontrola nastavení příznaků před generováním dokladů (Task 2 - Flag Checking before Posting)
Úloha č. 2 prochází Platby předem typu Platba, které čekají na vygenerování daňových dokladů (mají příznaky Generovat doklady = Ano a Generovat daňový doklad = Ano). Na těchto platbách provede kontrolu dvou podmínek:
Na Položce zákazníka, ke které je Platba předem vygenerována, je uvedena Účto skupina zákazníka, která má nastavený příznak Generovat daňové doklady k Platbám předem = Ne
Podle hodnoty dimenze 2 (Smlouva) nebyla nalezena Smlouva o financování a současně v Nastavení prodeje a pohledávek je příznak "Generovat daňové doklady k Platbám předem bez nalezené smlouvy o financování” = Ne.
Pokud platba splňuje alespoň jednu podmínku, příznaky pro generování daňových dokladů se smažou.
Pokud existuje Využití spojené s touto Platbou, smažou se příznaky i zde. Jestliže však již byl daňový doklad vygenerovaný, příznaky pro generování daňových dobropisů nebo vrubopisů zůstávají.
Úloha č. 3 – Generování daňových dokladů (Tax documents generating)
V této úloze systém prochází evidenci Plateb předem. Na základě příznaků Generovat daňový doklad k přijaté platbě a Generovat dobropis k přijaté platbě vygeneruje příslušné doklady a jim odpovídající Věcné položky a DPH položky.
Po doběhnutí úlohy systém vypíše informativní hlášku o ukončení.
...
Dogenerování daňových dokladů k Platbám předem při účtování
Jestliže v předchozích krocích byly vygenerované Platby předem, ale daňové doklady/dobropisy stále čekají na vygenerování, pak systém automaticky dogeneruje a zaúčtuje daňové doklady a dobropisy při těchto akcích:
při účtování deníku plateb (CU 13 – OnAfterCode)
při účtování vyrovnání položek zákazníka (CU 226 - OnAfterPostApplyCustLedgEntry)
Systém vybírá všechny platby předem typu Platba a Využití, které mají nastavené příznaky:
Platba:
Generovat daňový doklad = Ano
Generovat daňový doklad k platbě předem ihned = Ano
Využití:
...
Generovat dobropis k přijaté platbě = Ano
...
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.