...
...
...
...
...
Table of Contents | ||
---|---|---|
|
Principy
Zpracování bankovních výpisů (Bank Statements) and automation of the processing process.
The dependency is a completely set up bank account card.
A prerequisite is that the corresponding BV import format is set in the bank account card, including defined network directories for importing and archiving files. Another prerequisite is Saved Bank Statement in the appropriate format from the bank in the corresponding/set network directory for each bank.
For more information on how to set up a bank account card, see Finance Setup
This documented area describes the modifications to the import of bank statements for OCs and the procedures for their processing.
A new task "Preparation of Bank statements" has been added to the Bank Account Card (T370). An automated task consists of processing a bank statement in several steps, which are manual processing steps. Each manual processing step is part of an automated task until the Payment Journal is created. Manual processing is a sequence of steps that are processed by user intervention. The same steps are in an automated task, but these steps happen automatically, without user intervention.
In the new task dialog window, it is possible to select the code of the bank for which the statement is to be imported. After running the task, the system will find import files according to the specified path in the BV import format settings for the selected bank code. In BC, it creates a new BV and imports the found file into it. It then issues the statement and creates Payment Journals. When you create a reconciliation journal, BV items are automatically matched according to the set matching rules. If there are more files in the folder, they will be processed one by one from the oldest (file name with BV in XXX_RRRRMMDD format). If a file is processed by a task with an error, the system creates an entry in the error log and continues processing the next file. Error logs are written into a new log table "Import Bank Statement Log". The log stores information about whether the file is successfully processed, into which BV it was imported and any errors that occurred during processing.
There is also information in the Log about the number of rows that were imported from the file. It is important to keep track of this information. In case the BV file does not contain any row, the issued bank statement is not created and the processing does not end in an error. In case the BV file has not been saved to the correct folder, the system will import it with zero rows, due to bank account validation, which in this case will reveal a mismatch. The system will then send such a file to the archive!
After the import of the BV file is successfully processed, the task moves it to another network folder used for archiving BV import files. BC provides processed files with a timestamp where the date and time of processing are appended to the file name.
The result of the job is a released BV and a prepared payment journal for further user processing.
The task can also be run separately via the system search magnifying glass.
Task – Prepare bank statements
A task has been added to the OC Preparation of Bank statements for automatic import and archiving of bank statements. After the BV import is successful, the job prepares Payment Reconciliation Journals for processing and posting the bank statement.
You can search for a job using the system magnifier, or you can find it located in:
Bank Account List (371, List) in the Process menu
Account Card (370, Card) in the Actions menu
When you press the task button, the system displays a dialog box that contains:
Field for selecting a bank account with the option to search for the Bank account for which BV is to be processed, after calling the Look up value, the Bank Account (270)) table opens
OK button to start the task
If the task is run from the list or from the BV card, the BV selection field is automatically filled with the code of the bank from which the task is called.
The task is started using the OK button.
Job Processing Process
When you run the task by clicking OK from the dialog box, the system performs the following steps:
...
a automatizace procesu zpracování.
Platební příkazy (Payment Orders), jejich vytvoření a odeslání do banky ke zpracování.
V této dokumentované oblasti jsou popsány úpravy importu bankovních výpisů pro OC a postupy při jejich zpracování.
Na kartu Bankovního účtu (T370, Bank Account Card) je přidána nová úloha „Příprava bankovních výpisu“ (Preparation of Bank statements). Automatizovaná úloha spočívá ve zpracování bankovního výpisu v několika krocích, které představují kroky ručního zpracování. Každý krok ručního zpracování je součástí automatizované úlohy až do bodu, kdy se vytvoří Deník plateb (Payment Journals). Ruční zpracování představuje určitou posloupnost kroků, které se zpracovávají zásahem uživatele. Stejné kroky jsou i v automatizované úloze, ale tyto kroky probíhají automaticky, bez zásahu uživatele.
V dialogovém okně nové úlohy je možné zvolit kód banky, pro kterou se má výpis importovat. Systém po spuštění úlohy najde importní soubory podle zadané cesty v nastavení formátu importu BV pro zvolený kód banky. V BC vytvoří nový BV a do něj naimportuje nalezený soubor. Následně výpis vydá a vytvoří Deník plateb (Payment Journals). Při tvorbě deníku odsouhlasení dochází k automatickému párování položek BV dle nastavených pravidel párování. V případě, že bude ve složce více souborů, budou zpracovávány po jednom od nejstarších (název souboru s BV ve formátu XXX_RRRRMMDD). Pokud u některého souboru skončí zpracování úlohou s chybou, systém založí záznam do error logu a pokračuje ve zpracování dalšího souboru. Error logy se zapisují do nové logovací tabulky „Log importu bankovních výpisů“ (Import Bank Statement Log). Do logu se ukládají informace o tom, zda je soubor úspěšně zpracován, do jakého BV byl naimportován a případné chyby, které při zpracování nastaly.
Dále je v Logu informace o počtu řádků, které byly ze souboru naimportovány. Tuto informaci je důležité sledovat. V případě, kdy soubor BV neobsahuje žádný řádek se nevytvoří vydaný bankovní výpis a zpracování neskončí chybou. V případě, že soubor BV nebyl uložen do správné složky, systém jej naimportuje s nulovým počtem řádků, a to z důvodu validace bankovního účtu, která v tomto případě odhalí nesoulad. I takovýto soubor systém pak odešle do archivu!
Úloha po úspěšném zpracování importu souboru BV tento přesune do jiné síťové složky sloužící pro archivaci importních souborů BV. Zpracované soubory BC opatřuje časovou značkou, kdy ke jménu souboru připojí datum a čas zpracování.
Výsledkem úlohy je vydaný BV a připravený deník plateb pro další uživatelské zpracování.
Úloha je spustitelná i samostatně přes systémovou vyhledávací lupu.
Závislosti a předpoklady
Závislostí je kompletně nastavená karta bankovního účtu.
Předpokladem je nastavený odpovídající formát importu BV v kartě bankovního účtu včetně nadefinovaných síťových adresářů pro import a archivaci souborů. Dalším předpokladem je uložený bankovní výpis v odpovídajícím formátu z banky v odpovídajícím / nastaveném síťovém adresáři pro každou banku.
Více informací o nastavení karty bankovního účtu je popsáno v Nastavení Finance
Úloha – Příprava bankovních výpisů
Do OC je doplněná úloha Příprava bankovních výpisů (Preparation of Bank statement) pro automatický import a archivaci bankovních výpisů. Po úspěšném importu BV úloha připraví Deníky odsouhlasení plateb (Payment Reconciliation Journals) sloužící pro zpracování a zaúčtování bankovního výpisu.
Úlohu lze vyhledat pomocí systémové lupy, nebo ji lze najít umístěnou v:
Přehledu Bankovní účty (Bank Account List (371, List)) v nabídce Proces (Process)
Kartě Bankovního účtu (Account Card (370, Card)) v nabídce Akce (Actions).
Po stlačení tlačítka úlohy systém zobrazí dialogové okno, které obsahuje:
Pole pro výběr bankovního účtu s možností vyhledat Bankovní účet pro který se mají zpracovávat BV, po vyvolání Vyhledat hodnotu se otevře tabulka Bankovní účty (Bank Account (270))
Tlačítko OK pro spuštění úlohy.
Jestliže je úloha spouštěna z přehledu nebo z karty BV, je pole pro výběr BV automaticky naplněno kódem banky, ze které je úloha vyvolána.
Spuštění úlohy se provede pomocí tlačítka OK.
Proces zpracování úlohy
Po spuštění úlohy tlačítkem OK z dialogového okna systém vykoná následující kroky:
V tabulce Bankovní účet (Bank Account (270)) podle nastaveného kódu v poli Formát importu bankovního výpisu (Bank Statement Import Format (113, Code)) najde Výchozí cestu ke složce v tabulce Nastavení Exportu/Importu banky (Bank Export/Import Setup (1200)) table
Creates a new BV for the selected bank code in the Založí nový BV pro vybraný kód banky v tabulce Hlavička bankovního výpisu (Bank Statement Header (11704)) table
In case of incorrect processing, the error log is written into the log table and the header of the created BV is removed
The found file with BV is imported into the created BV, fills in the header and rows of the created BV with data from the imported file
In case of incorrect processing, the error log is written into a new log table, the created BV remains for manual import of BV and subsequent manual processing (In case the user uploads a file of another bank to the folder, the system imports it with the number of rows 0 and sends it to the archive. An issued BV will not be created due to the validation of the bank account number)
In case of successful processing of item No. 4, BV will issue by selecting "Release and create payment journal"
In case of incorrect processing, the error log is written into the log table, the created BV remains for manual import of BV and subsequent manual processing
After the correct processing of point No. 6, the file with BV is moved to the archive, the path to archiving is looked in the Archive Folder Path field in the
V případě chybného zpracování zapíše error log do logovací tabulky a odstraní se hlavička založeného BV
Nalezený soubor s BV naimportuje do založeného BV, vyplní hlavičku a řádky založeného BV daty z importovaného souboru
V případě chybného zpracování zapíše error log do nové logovací tabulky, založený BV zůstane pro ruční import BV a následné ruční zpracování (V případě, kdy uživatel nahraje do složky soubor jiné banky, systém jej naimportuje s počtem řádků 0 a pošle jej do archivu. Nevytvoří se vydaný BV, a to z důvodu validace čísla bankovního účtu)
V případě úspěšného zpracování bodu č. 4, BV vydá volbou „Vydat a vytvořit deník plateb“
V případě chybného zpracování zapíše error log do logovací tabulky, založený BV zůstane pro ruční import BV a následné ruční zpracování
Po bezchybném zpracování bodu č. 6 se soubor s BV přesune do archivu, na cestu k archivaci se podívá do pole Složka pro archivaci výpisů (Archive Folder Path) v tabulce Nastavení Exportu/Importu Banky (Bank Export/Import Setup (1200) table in the corresponding code of the bank export/import settings on the card of the selected bank account
In case of incorrect processing, the error log is written into the log table
After archiving, the system checks to see if there is another file in the default folder. If so, the process goes back to step 2 and repeats until it has processed all the files in the default folder. If not, move on to step 11
At the end of the process, an information window will appear announcing success / failure and the number of the issued BV will be entered into the log table with the possibility of opening it directly.
The created Payment Reconciliation Journal can be opened from the BV or separately from the Payment Reconciliaton Journals overview. In the journal, the entries are further processed according to standard procedures.
The task can also be run separately via the search magnifying glass.
Import Bank Statement by Format
Imports of daily statements are supported in OC, where each file contains one statement of one account per day.
Default import formats supported in OC:
...
Object
...
Number
...
Title
...
Notes
...
)) v odpovídajícím kódu nastavení exportu/importu banky na kartě vybraného bankovního účtu
V případě chybného zpracování zapíše error log do logovací tabulky
Po archivaci se systém podívá, zda se ve výchozí složce nachází další soubor. Pakliže ano, proces se vrátí na krok č. 2 a opakuje se, dokud nezpracuje všechny soubory v dané výchozí složce. Pakliže ne, přejde ke kroku č. 11
Po skončení procesu se objeví informační okno s oznámením úspěchu / neúspěchu a do logovací tabulky se zapíše číslo vytvořeného vydané BV s možností jeho přímého otevření.
Vytvořený Deník odsouhlasení plateb lze otevřít z vytvořeného BV nebo samostatně z přehledu Deníku odsouhlasení plateb (Payment Reconciliaton Journals). V deníku se s položkami dále pracuje standardními postupy.
Úloha je spustitelná i samostatně přes vyhledávací lupu.
Import bankovního výpisu dle formátu
V OC jsou podporovány importy denních výpisů, kdy každý soubor obsahuje jeden výpis jednoho účtu za jeden den.
Výchozí formáty importů podporované v OC:
Objekt | Číslo | Název | Poznámky |
report | 50050 | MT940:IM |
|
Reportreport | 50053 | GPC:IM |
|
Reportreport | 50056 | ZIBA/GEMINI:IM |
|
Reportreport | 50059 | CLEARING:IM |
|
Reportreport | 50060 | GEMINI4.1:IM |
|
Reportreport | 50061 | MT940:IM, HSBC |
|
Reportreport | 50062 | GPC:IM, CSOB |
|
Reportreport | 50063 | MT940:IM, UNICREDIT |
|
Reportreport | 50064 | GPC:IM, RB |
|
Reportreport | 50066 | MT940:IM, Commerzbank |
|
Reportreport | 50069 | GPC:IM, RB DECODE |
|
Reportreport | 50070 | ČSOB CSOB MT940:IM |
|
Reportreport | 50073 | MT940:IM TATRABANKA |
|
Reportreport | 50074 | MT940:IM, Citibank |
|
Reportreport | 50076 | MT940:IM OBER |
|
Reportreport | 50077 | MT940:IM, ING |
|
Reportreport | 50078 | MT940:IM, ENCS |
|
Default objects usually need to be modified according to the requirements of a particular bank.
The task reads the extract rows from the import file for the selected bank account and at the same time creates the BV header.
...
Finds the beginning of the statement (bank account number, statement number, statement date)
...
According to the bank account number from the statement, it will search for a Bank Account Card with the same value in the Bank Account No. field.
...
Výchozí objekty je obvykle potřeba upravit dle požadavků konkrétní banky.
Úloha načte řádky výpisu z importního souboru pro zvolený bankovní účet a zároveň založí hlavičku BV.
Najde počátek výpisu (číslo bankovního účtu, číslo výpisu, datum výpisu)
Dle čísla bankovního účtu z výpisu vyhledá Kartu bankovního účtu se stejnou hodnotou v poli Číslo bankovního účtu.
Dle nalezené Karty bankovního účtu hledá v hlavičce Bankovního výpisu (Bank Statement Header (11704)) and the header of the a hlavičce Vydaného bankovního výpisu (Issued Bank Statement Header (11706)) whether the header of the statement with the same bank account number and date is not already created, i.e. it checks the fields:
Bank Account No. (3)
External Document No. (35) = Imported Statement No.
Document Date (6) = Statement Date
If there is a bank statement header where the same External Document No. or Document Date exists for the same Bank Account No. as in the imported file, the system will skip this header generation and make a log entry
If it does not find a Bank Statement or Issued Bank Statement header (with the same External Document No. and Document Date), it searches for an empty Bank Statement header of the processed Bank Account Card (i.e. the header has the Bank Account No. field filled in)
If it finds a blank Bank Statement header for the Bank Account Card,
fills in the data from the file into the header
Bank Account No. (3)
External Document No. (35) = Imported Statement No.
Document Date (6) = Statement Date
Other data, e.g. Currency Code, Account No., Bank Account No. are validated in a standard way when creating a header.
For a created and filled header, it creates bank statement lines in the standard way
If it does not find an empty header for the Bank Account Card,
create a new header (i.e. assign the Bank Statement No. according to the number series set on the bank account card in the Statement Numbers field (11727) and fill in the Bank Account No. Other data, e.g. Currency Code, Account No., Bank Account No. are validated in the standard way when creating a header).
From the file, it then fills in the created header
External Document No. (35) = Imported Statement No.
Document Date (6) = Statement Date.
For a created and filled header, it creates bank statement lines in the standard way. Individual lines are taken from the bank statement file, decoded, and populated into the corresponding lines of the Bank Statement. I.e. it tries to assign equivalent values from the file to each field of the row (amount, VS, account number / IBAN, description, ...).
Archiving an import file with a bank statement
...
, zda hlavička výpisu se stejným číslem bankovního účtu a datem již není založena, tj. kontroluje pole:
Číslo bankovního účtu (3)
Číslo externího dokladu (35) = Číslo importovaného výpisu
Datum dokladu (6) = Datum výpisu
Pokud existuje hlavička bankovního výpisu, kde ke stejnému Číslu bankovního účtu existuje stejné Číslo externího dokladu nebo Datum dokladu jako v importovaném souboru, systém generování této hlavičky přeskočí a provede záznam do logu
Pokud nenalezne založenou hlavičku Bankovního výpisu nebo Vydaného bankovního výpisu (se stejným Číslem externího dokladu a Datem dokladu), hledá založenou prázdnou hlavičku Bankovního výpisu zpracovávané Karty bankovního účtu (tj. hlavička má vyplněné pole Číslo bankovního účtu)
Pokud nalezne pro Kartu bankovního účtu prázdnou hlavičku Bankovního výpisu,
vyplní ze souboru do hlavičky údaje
Číslo bankovního účtu (3)
Číslo externího dokladu (35) = Číslo importovaného výpisu
Datum dokladu (6) = Datum výpisu
Ostatní údaje např. Kód měny, Číslo účtu, Číslo bankovního účtu se validují standardním způsobem při založení hlavičky.
Pro založenou a vyplněnou hlavičku založí standardním způsobem řádky bankovního výpisu
Pokud nenalezne pro Kartu bankovního účtu prázdnou hlavičku,
založí novou hlavičku (tj. přiřadí Číslo bankovního výpisu dle číselné řady nastavené na kartě bankovního účtu v poli Čísla výpisů (11727) a vyplní Číslo bankovního účtu. Ostatní údaje např. Kód měny, Číslo účtu, Číslo bankovního účtu se validují standardním způsobem při založení hlavičky).
Ze souboru pak doplní do založené hlavičky údaje
Číslo externího dokladu (35) = Číslo importovaného výpisu
Datum dokladu (6) = Datum výpisu.
Pro založenou a vyplněnou hlavičku založí standardním způsobem řádky bankovního výpisu. Vezmou se jednotlivé řádky ze souboru bankovního výpisu, dekódují se a naplní do odpovídajících řádků Bankovního výpisu. Tj. K jednotlivým polím řádku se snaží přiřadit ekvivalentní hodnoty ze souboru (částku, VS, číslo účtu / IBAN, popis, …).
Archivace importního souboru s bankovním výpisem
V nastavení tabulky Nastavení exportu/importu banky (Bank Export/Import Setup (1200)) in the new field Archive folder path v novém poli Cesta k archivní složce (Archive Folder Path) The user sets the directory to which they will be
Processed files to be transferred. These directories are defined by the user for each bank separately. These paths will be set once and then the system will take the paths from the settings to work with.
The file in the directory with processed dumps will have the following structure:
OriginalfilenameYYYMMDDHHMMSS.originalextension
YYYY-year
MM – Month
DD – day
HH – hour
MM-minute
SS Second
Archiving a BV file is part of the automated task.
Bank Statement Import Log
A new table and the Import Bank Statement Log page are created in the OC. The log is searchable via the system magnifier. In addition, the Log is available:
...
uživatel nastaví adresář, do něhož se budou
zpracované soubory přenášet. Tyto adresáře nadefinuje uživatel pro každou banku zvlášť. Tyto cesty se nastaví jednou a potom už si systém bude z nastavení brát cesty, se kterými má pracovat.
Soubor v adresáři se zpracovanými výpisy bude mít následující strukturu:
PůvodnínázevsouboruRRRRMMDDHHMMSS.původnípřípona
RRRR – rok
MM – měsíc
DD – den
HH – hodina
MM – minuta
SS – sekunda
Archivace souboru s BV je součástí automatické úlohy.
Log importu bankovních výpisů
V OC je vytvořena nová tabulka a stránka Log importu bankovních výpisů (Import Bank Statement Log). Log je vyhledatelný přes systémovou lupu. Dále je Log dostupný:
z přehledu Bankovních účtů (Bank Account List (371, List) in the Process menufrom )) v nabídce Proces (Process)
z Karty bankovního účtu (Account Card (370, Card) in the Process menu
Entering data into table fields is performed automatically by the system at each step of the bank statement import task.
Log table fields:
Entry No.)) v nabídce Proces (Process)
Zapisování údajů do polí tabulky provádí systém automaticky při každém kroku úlohy na import bankovních výpisů.
Pole logovací tabulky:
Číslo položky (Entry No.)
Integer, PK,
Automatic numbering
automatické číslování
ID uživatele (User ID)
Code 50,
automatic completion of data about the user who started the task
automatické doplnění údajů o uživateli, který úlohu spustil
Operace (Operation)
Option, optionsvolby:
Import souboru (File Import)
Vydání bankovního výpisu (Bank Statement Issue)
Invoicing Fakturace (Posting)
Výsledek (Result)
Option, optionsvolby:
Úspěch (Success)
Chyba (Error)
Detail chyby (Error Detail)
Text 250,
The text is written in the language in which the language of the user who started the task was set
Date and Time
DateTime
Exact date and time when the job started
text se zapisuje v takovém jazyku, v jakém bylo nastavení jazyku uživatele, který úlohu spustil
Datum a čas (Date and Time)
DateTime
přesný datum a čas spuštění úlohy
Číslo bankovního výpisu (Bank Statement No.)
Automatic matching of payments in the Payment Journal is performed according to the Search Rules corresponding to the set Search Rules Code on the Bank Account Card.
The automatic payment settlement feature is based on matching priority criteria.
Search rules for matching bank statement entries:
Each row in the Search Rule Card represents a payment settlement rule. Rules are settled in order from top to bottom, or by line No.
Account Mapping
The text mapping of accounts allows you to set up mapping according to the text found in the Description field on the lines of the Bank Statement and to specific debit accounts, credit accounts, and offset accounts so that payments are posted to specific accounts when the Payment Journal is posted.
It is used to account for payments that have not been settled automatically according to the Search Rules.
The search rules are set by the customer according to their own needs.
Unpaired payments must be manually processed (unmatched) in the journal, or you can preset the G/L account (e.g. 395000) to which the unallocated payments should be posted by setting the Non Associated Payment Account field on the bank account card.
Splitting a mass payment in the Payment Journal
If you do not want to charge the received mass payment from the customer with one item (e.g. due to different dimensions of matched invoices), you can split the payment using the Split payment by to Applying function.
Split Mass Payment by Applies-to ID
To split a mass payment, proceed as follows:
On a mass payment line, use the Apply Entries function () to select and mark the customer ledger entries to apply
Make sure that Applies-to ID is filled in on the payment line
Run Split payment by to Applying function
This feature at startup:
Retrieves the processed Applies-to ID (Document No. and line number from the journal line where the cursor rests when the job is run)
Filters customer ledger entries that have the appropriate Applies-to ID filled in
Divides the payment into separate lines.
Settles each partial payment on a journal line
To split and settle a payment:
On the original journal line, fills in the Applies-to Type and Applies-to Document No. from the first entry in the set of marked customer entries (in the order of key: Due Date + Posting Date + Entry Number) and adjusts the payment amount according to the current balance of the customer entry being applied. Deletes the applies-to ID on the entry
Creates a new payment line for each additional applied item. On the new lines, it proceeds in a similar way, i.e. it gradually settles the individual entries on the journal line, adjusts the payment amount, and deletes the applies-to ID on the entry.
To fill in the fields on a new line:
Data such as Posting Date, Document Number, Description, Counter-Account Type and Number, Variable Symbol and External Document No. are copied from the original payment
Copies the customer's posting group from the customer's card
Dimension copied from the applied entry (if Dimension from paired entry = Yes is set on the Bank Account card)
Fills in Parent Line No. – A non-editable field that identifies that the payment has been split by the Split payment by settlement function. Parent line number = 0 remains on the original journal line. All new lines resulting from splitting the payment will have the Line number from the original payment filled in the Parent Line No. field. The field is used by the system when splitting is cancelled, when journal lines are deleted, when rematching using search rules, and when posting a journal.
If the total payment is greater than the current balance of all items to be settled (overpayment), the last partial payment based on the customer remains unsettled. The data on the line are filled in similarly to the lines with settlement, including the Variable Symbol copied from the original payment line.
Note: Dimensions are added in the standard way, if they were set up on the customer card or on the bank account card, they would be copied to the line from the relevant card.
If an underpayment is detected at the end of the split, then the system adjusts the amount on the last line of the split payment so that the sum of the partial payments is equal to the payment amount before the split
Payment Variances
To detect the discrepancy, both when checking the current balance and when splitting the payment itself, the system uses the variance that is set on the bank account card (Matching Tolerance Type and Matching Tolerance Value fields)
Any payment discrepancy is applied only to the last applied item
However, to post the variance, the system uses the variance that is specified on the customer ledger entry (the Maximum payment variance field). Therefore, even when splitting a payment, if a variance is set "on request" in the General Ledger Setup, it is necessary to confirm whether the difference should be posted as a payment difference or whether an open item should remain on the balance
If no entries with a matching settlement ID are found when the function runs, or the current item balances of that application ID are zero, the payment will not be split and the line will remain unchanged.
The function cannot be run on a line that has been split (neither on the original line nor on newly created rows):
Delete split payment lines
By default, journal lines can be deleted using either the Delete function or the keyboard shortcut CTRL+DEL.
The deletion of payment lines that have been split is restricted. You can only delete all of the split payment lines at once. Because the original split payment line does not contain a parent line number, it may be more difficult to identify or filter this line, so it is recommended that you cancel the split first, and then delete the journal lines.
To delete rows:
Select (mark) the journal lines that you want to delete. If these are split payment lines, you must mark all split payment lines, including the original line
Run the Delete function (or CTRL+DEL)
When the system function starts:
If the selected rows group does not contain any split rows, these rows are deleted in the standard way
If at least one of the lines marked for deletion comes from a split payment (original or new line), the system checks whether all lines of that split are in the selection.
If so, it will delete all rows
If not, it won't delete any row. This is true even if there are other lines between the marked lines, even unsplit payments or other split payments completely marked. The deletion ends with an error message and the lines remain in the journal.
Split-payment re-matching
In the Payment Journal, there is a standard function Match by search rule ().
This feature allows you to re-run automatic matching over marked journal lines. For repeated automatic matching, the Search Rule code must be filled in on the journal line (a non-editable field, it is filled in by the system when generating the journal from the Issued bank statement). New matching will take place only for customer entries (vendors, etc.) that are filled in on the journal line, by rules that are filled in on the journal line.
It is not possible to run this function on lines that come from a split payment (original or new), the task will end with an error message. You must either select only the rows without splitting, or cancel the split, and then restart the rematching.
Cancel a mass payment split
If the journal line was split by Split payment by to applying, you can cancel the split by using Cancel payment splitting
To cancel a split:
Select (mark) any split payment line. You can also select multiple rows at once.
Run the Cancel Split Rows function
System
For the current line, it searches for all lines of the split payment according to the number of the parent line and retrieves the total amount from these lines. Deletes rows with the Parent Line No. filled in. It keeps the original line (Parent Line No. = 0) but corrects the line amount to the original payment value (sum of the amounts of the deleted lines + the amount from the parent line).
If an applies-to ID was filled in on the deleted line (e.g., a user changed the matching after splitting a payment), this applies-to ID will be deleted on the customer's ledger entries.
If the application is on the original line (either in the Applies-to Document No. field or the Applies-to ID field), the applies-to are not changed when you cancel the split.
If there were multiple split payments between the selected lines, the system will cancel all splits one by one
- If a non-split line has been marked, the system skips that line
Code 20
The number of the bank statement created during the task is entered, in case of a successful result, the number of the issued bank statement is entered and it is possible to open it by clicking on the number
File Name
Text 250
the name of the file with which the task worked, including its location before archiving
Bank Account No.
Code 20
The code of the bank account for which the job processed the import is written
No. of Lines
Integer
The number of rows from the statement is written
Issued Bank Statement
Releasing a BV and Creating a payment journal is part of the automated job.
The issued bank statement is not editable and cannot be deleted/deleted. It serves as an archive. If the statement has been posted, you can view the posted entries from it using the Find Entries function in the Process option. If a payment journal is not created from this statement, e.g. due to incorrect processing of an automatic task, it is possible to create it manually from the issued bank statement and post it after all entries have been processed.
Bank Statement Matching
...
zapíše se číslo bankovního výpisy, který při úloze vznikl, v případě úspěšného výsledku se zapíše číslo vydaného bankovního výpisu a je možné je kliknutím na číslo otevřít
Název souboru (File Name)
Text 250
název souboru se kterým úloha pracovala, vč. jeho umístění před archivací
Číslo bankovního účtu (Bank Account No.)
Code 20
zapíše se kód bankovního účtu, pro který úloha zpracovávala import
Počet řádků (No. of Lines)
Integer
zapíše se počet řádků z výpisu
Vydaný bankovní výpis
Vydání BV a Vytvoření deníku plateb je součástí automatické úlohy.
Vydaný bankovní výpis není editovatelný a nelze jej smazat / odstranit. Slouží jako archiv. Pokud byl výpis zaúčtován, lze si z něj zobrazit zaúčtované položky pomocí funkce Najít položky (Find Entries) ve volbě Proces. Pokud není vytvořen z tohoto výpisu deník plateb, např. z důvodu chybného zpracování automatické úlohy, tak je možné ho z vydaného bankovního výpisu vytvořit ručně a po zpracování všech položek zaúčtovat.
Párování bankovních výpisů
Nastavení Pravidel hledání (Search Rules) je popsánov Nastavení Finance
Automatické párování plateb v Deníku plateb probíhá dle Pravidel hledání odpovídajícím nastavenému Kódu pravidel hledání na Kartě bankovního účtu.
Funkce automatického vyrovnání plateb se zakládá na kritériích dle priority párování.
Pravidla hledání pro párování položek bankovního výpisu:
Každý řádek v kartě Pravidla hledání (Search Rule Card) představuje pravidlo vyrovnání plateb. Pravidla se vyrovnávají v pořadí od shora dolů, respektive podle čísla řádku (Line No.)
Textové mapování účtů (Account Mapping)
Textové mapování účtů umožňuje nastavit mapování podle textu nalezeného v poli Popis v řádcích Bankovního výpisu a konkrétními účty MD, účty DAL a protiúčty tak, že jsou platby při zaúčtování Deníku plateb zaúčtovány na konkrétní účty.
Používá se k předkontaci plateb, které nebyly vyrovnány automaticky dle Pravidel hledání.
Pravidla hledání si zákazník nastaví sám podle vlastních potřeb.
Nespárované platby se musí v deníku ručně zpracovat (vypárovat) nebo lze přednastavit finanční účet (např. 395000), na který se mají nepřiřazené platby zaúčtovat, pomocí nastavení pole Účet nepřiřazených plateb (Non Associated Payment Account) v kartě bankovního účtu.
Rozdělení hromadné platby v Deníku Plateb
Jestliže nechcete přijatou hromadnou platbu od zákazníka účtovat jednou položkou (např. kvůli různým dimenzím párovaných faktur), můžete platbu rozdělit pomocí funkce Rozdělit platbu dle vyrovnání (Split payment by to Applying).
Rozdělení hromadné platby dle ID vyrovnání
Pro rozdělení hromadné platby postupujte následovně:
Na řádku s hromadnou platbou pomocí funkce Vyrovnat položky () vyberte a označte položky zákazníka k vyrovnání
Zkontrolujte, že je na řádku platby vyplněno ID vyrovnání
Spusťte funkci Rozdělit platbu dle vyrovnání (Split payment by to Applying)
Tato funkce při spuštění:
Načte zpracovávané ID vyrovnání (Číslo dokladu z řádku deníku, na kterém stojí kurzor při spuštění úlohy)
Zafiltruje položky zákazníka, které mají vyplněno příslušné ID vyrovnání
Rozdělí platbu do samostatných řádků.
Jednotlivé dílčí platby vyrovná na řádku deníku
Rozdělení a vyrovnání platby:
Na původním řádku deníku vyplní Typ vyrovnání a Číslo vyrovnání dokladu z první položky v sadě označených položek zákazníka (v pořadí dle klíče: Datum splatnosti + Zúčtovací datum + Číslo položky) a upraví částku platby dle aktuálního zůstatku vyrovnávané položky zákazníka. Na položce smaže ID vyrovnání
Pro každou další vyrovnávanou položku založí nový řádek platby. Na nových řádcích postupuje obdobně, tj. postupně vyrovnává jednotlivé položky na řádku deníku, upravuje částku platby a maže ID vyrovnání na položce.
Vyplnění polí na novém řádku:
Údaje jako Zúčtovací datum, Číslo dokladu, Popis, typ a číslo protiúčtu, Variabilní symbol a Číslo externího dokladu zkopíruje z původní platby
Účto skupinu zákazníka zkopíruje z karty zákazníka
Dimenze zkopíruje z vyrovnávané položky (pokud je na kartě Bankovního účtu nastaveno Dimenze z párované položky = Ano)
Vyplní Číslo nadřazeného řádku (Parent Line No.) – needitovatelné pole, které identifikuje, že platba byla rozdělena funkcí Rozdělit platbu dle vyrovnání. Na původním řádku deníku zůstane Číslo nadřazeného řádku = 0. Všechny nové řádky vzniklé rozdělením platby budou mít v poli Číslo nadřazeného řádku vyplněno Číslo řádku z původní platby. Pole využije systém při zrušení rozdělení, při mazání řádků deníku, při opakovaném párování pomocí pravidel hledání a při účtování deníku.
Pokud je celková platba větší než aktuální zůstatek všech položek k vyrovnání (přeplatek), zůstane poslední dílčí platba založená jen na zákazníka bez vyrovnání. Údaje na řádku jsou vyplněné obdobně jako u řádků s vyrovnáním, včetně Variabilního symbolu zkopírovaného z původního řádku platby.
Pozn. Dimenze se doplňují standardním způsobem, pokud by byly nastaveny na kartě zákazníka nebo na kartě bankovního účtu, zkopírují se do řádku z příslušné karty.
Pokud je na konci rozdělení zjištěn nedoplatek, pak systém upraví částku na posledním řádku rozdělené platby tak, aby součet dílčích plateb se rovnal částce platby před rozdělením
Odchylky platby
Pro zjištění odchylky jak při kontrole aktuálního zůstatku, tak při samotném rozdělení platby systém používá odchylku nastavenou na kartě bankovního účtu (pole Typ tolerance párování a Hodnota tolerance párování)
Případná odchylka platby je uplatněna pouze u poslední vyrovnávané položky
Pro zaúčtování odchylky však používá systém odchylku uvedenou na položce zákazníka (pole Maximální platební odchylka). Proto je nutné i při rozdělení platby, pokud je v Nastavení financí nastavená odchylka „na dotaz“, potvrdit, zda se má rozdíl zaúčtovat jako odchylka platby nebo má zůstat otevřená položka na saldu
...
Pokud při spuštění funkce nebudou nalezeny žádné položky s odpovídajícím ID vyrovnání, nebo aktuální zůstatky položek daného ID vyrovnání budou nulové, platba se nerozdělí a řádek zůstane beze změny.
Funkci nelze spustit na řádku, který byl rozdělený (ani na původním řádku, ani na nově vzniklých řádcích):
...
Odstranění řádků rozdělené platby
Řádky deníku lze standardně smazat buď funkcí Odstranit (Delete) nebo klávesovou zkratkou CTRL+DEL.
Odstranění řádků platby, která byla rozdělena, je omezeno. Řádky rozdělené platby můžete odstranit pouze všechny najednou. Protože původní řádek rozdělené platby neobsahuje číslo nadřazeného řádku, může být složitější tento řádek identifikovat nebo filtrovat, je doporučeno nejdříve zrušit rozdělení a pak řádky deníku mazat.
Postup při odstranění řádků:
Vyberte (označte) řádky deníku, které chce smazat. Pokud se jedná o řádky rozdělené platby, musíte označit všechny řádky rozdělení včetně původního řádku
Spusťte funkci Odstranit (nebo CTRL+DEL)
Po spuštění funkce systém:
Pokud skupina označených řádků neobsahuje žádné rozdělené řádky, smažou se tyto řádky standardním způsobem
Pokud alespoň jeden z řádků označených ke smazání pochází z rozdělené platby (původní nebo nový řádek), systém zkontroluje, zda jsou ve výběru všechny řádky daného rozdělení.
Pokud ano, smaže všechny řádky
Pokud ne, nesmaže žádný řádek. To i v případě, že mezi označenými řádky budou jiné, i nerozdělené platby nebo jiné rozdělené platby kompletně označené. Mazání skončí chybovou hláškou a řádky zůstávají v deníku.
Opakované párování rozdělené platby
V Deníku plateb je standardní funkce Párovat dle vyhledávacího pravidla.
Tato funkce umožňuje znovu spustit automatické párování nad označenými řádky deníku. Pro opakované automatické párování musí být na řádku deníku vyplněný kód Pravidla hledání (needitovatelné pole, vyplňuje ho systém při generování deníku z Vydaného bankovního výpisu). Nové párování proběhne jen nad položkami zákazníka (dodavatele atd.), který je vyplněný na řádku deníku, pravidly, která jsou vyplněná na řádku deníku.
Na řádcích, které pocházejí z rozdělené platby (původní nebo nové), není možné tuto funkci pouštět, úloha skončí chybovou hláškou. Musíte buď vybrat jen řádky bez rozdělení, nebo rozdělení zrušit a pak znovu spustit opakované párování.
Zrušení rozdělení hromadné platby
Pokud byl řádek deníku rozdělený funkcí Rozdělit platbu dle vyrovnání (Split payment by to applying), je možné rozdělení zrušit pomocí funkce Zrušit rozdělené řádky (Cancel payment splitting)
Pro zrušení rozdělení:
Vyberte (označte) libovolný řádek rozdělené platby. Můžete označit i více řádků najednou.
Spusťte funkci Zrušit rozdělené řádky
Systém:
k aktuálnímu řádku dohledá dle čísla nadřazeného řádku všechny řádky rozdělené platby a načte celkovou částku z těchto řádků. Řádky s vyplněným Číslem nadřazeného řádku smaže. Původní řádek (Číslo nadřazeného řádku = 0) ponechá, ale opraví částku na řádku na původní hodnotu platby (součet částek odstraněných řádků + částka z nadřazeného řádku).
Pokud na odstraněném řádku bylo vyplněno ID vyrovnání (např. uživatel po rozdělení platby změnil párování), bude toto ID vyrovnání na položkách zákazníka smazáno.
Pokud bude vyrovnání na původním řádku (ať už v poli Číslo vyrovnání dokladu nebo ID vyrovnání), při zrušení rozdělení se toto vyrovnání nemění.
Jestliže bylo mezi označenými řádky více rozdělených plateb, systém postupně zruší všechna rozdělení
Pokud byl označen nerozdělený řádek, systém tento řádek přeskočí.