Organizacja modułu Kasa/Bank

Rejestry kasowe/bankowe

Każda firma prowadząca działalność gospodarczą rozlicza się ze swoimi kontrahentami, pracownikami i urzędami. Rozliczenia mogą odbywać się na bieżąco – w gotówce, czekami czy kartami płatniczymi lub za pośrednictwem banku (przelewy).

Dla rozliczeń gotówkowych prowadzona jest kasa gotówkowa (w większych organizacjach – kilka kas).

Dla rozliczeń za pośrednictwem banku prowadzone są firmowe rachunki bankowe (konta w banku). Ich również każda firma może posiadać wiele (rachunek bieżący, lokaty, rachunki w różnych bankach…).

Płatności dokonywane firmową kartą płatniczą są związane z określonym bankiem (to bank wydaje karty). Często są, ale nie muszą być związane z określonym rachunkiem bankowym. Dlatego przypadek firmowej karty płatniczej może być potraktowany w Comarch ERP Optima, jako oddzielny rejestr płatności dokonywanych tą kartą.

Odpowiednikiem kas gotówkowych i poszczególnych rachunków bankowych w Comarch ERP Optima rejestry kasowe/bankowe. Każdej kasie (najczęściej jest tylko jedna), każdemu rachunkowi w banku i każdej firmowej karcie płatniczej powinien odpowiadać jeden rejestr.

Przykład
Jeśli firma prowadzi jedną kasę gotówkową oraz posiada rachunek bieżący w banku PKO BP S.A. i kartę płatniczą wydaną przez Bank Przemysłowo-Handlowy S.A. (BPH) – moduł Kasa/Bank powinien składać się z trzech rejestrów kasowych/ bankowych.

Zadaniem każdego z rejestrów jest prowadzenie bieżącej ewidencji wpływów i wydatków w kasie, na rachunku bankowym i zapisów związanych z kartą płatniczą. Otwierając rejestr należy pamiętać o wprowadzeniu Salda B.O. – stanu początkowego gotówki w kasie lub środków na rachunku bankowym.

Raporty kasowe/bankowe

Każdy z rejestrów podzielony jest na raporty kasowe/bankowe. Raport może obejmować zapisy za dzień, tydzień, dekadę (10 dni), miesiąc lub za inny, dowolny okres. Numeracja raportów może być ciągła w obrębie roku kalendarzowego, roku obrachunkowego lub w obrębie poszczególnych miesięcy. Dla każdego z raportów musi być określona data otwarcia i zamknięcia.

Każdy raport składa się z: 

  • bilansu otwarcia – stanu kasy lub konta w chwili otwierania raportu. Dla pierwszego raportu w rejestrze jest to Saldo B.O całego rejestru. Dla kolejnych raportów bilans otwarcia jest równy bilansowi zamknięcia poprzedzającego raportu.
  • Zapisów kasowych/bankowych – przychody (wpłaty) i rozchody (wypłaty).
  • Bilansu zamknięcia – stanu kasy/rachunku na moment zamykania raportu. Bilans zamknięcia ostatniego raportu jest jednocześnie bieżącym stanem środków w danym rejestrze.


Zapisy kasowe/bankowe

Zapis kasowy/bankowy odzwierciedla wpływ lub rozchód środków finansowych w kasie lub na rachunku bankowym. Każdy zapis jest elementem raportu kasowego/bankowego. Zapisy można dodawać tylko w raportach otwartych, jeśli data zapisu mieści się pomiędzy datą otwarcia i datą zamknięcia raportu.

Numeracja zapisów kasowych/bankowych odbywa się na dwa sposoby: 

  • zapisy numerowane są kolejno w obrębie każdego raportu – każdy zapis ma swoją Liczbę Porządkową (Lp.) w raporcie.
  • Zapisy są dokumentami numerowanymi wg schematu określonego podczas konfiguracji programu. Ta numeracja może być ciągła w obrębie roku kalendarzowego, roku obrachunkowego lub miesiąca. Powinna zawierać symbol dokumentu kasowego/bankowego (oznaczający np. czy jest to wpłata, czy wypłata) oraz oznaczenie rejestru, którego zapis dotyczy.
  • Jeśli zapis kasowy/bankowy powstaje, jako dokument wtórny np. do faktury płatnej gotówką, numer tego zapisu jest jednocześnie numerem dokumentu źródłowego (w naszym przykładzie jest numerem faktury).
  • Konfiguracji firmy/Kasa i Bank/Parametry znajduje się parametr Domyślny schemat numeracji dla automatycznych zapisów kasowych. Jeżeli parametr ten zostanie zaznaczony to przy automatycznych zapisach kasowych/bankowych schemat numeracji dokumentów jest pobierany z Konfiguracji firmy/Kasa i Bank/Dokumenty: KP/KW z kolumny Definicja – KP dla zapisów typu Przychód, KW dla zapisów typu Rozchód. Seria dla schematu numeracji pobierana jest z rejestru kasowego/bankowego tak jak przy ręcznym dodawaniu KP/KW.

Przykład
KP/000004/2010/KG oznacza czwartą wpłatę (KP) zapisaną w rejestrze Kasa Gotówkowa (KG) w roku 2010. Inny przykład to KW/000120/04/2010/PKO to dokument wypłaty (KW) o numerze 120 za miesiąc kwiecień (04), rok 2010 w rejestrze (na rachunku) PKO. W przypadku numeracji w obrębie miesiąca po zmianie miesiąca numery zaczną być nadawane od 000001

W zależności od typu rejestru kasowego/bankowego, w którym dokonujemy zapisu możemy mieć do czynienia z różnymi formami operacji kasowych/bankowych.

W rejestrach typu KASA płatności mogą być dokonywane: 

  • gotówką – np. klient płaci gotówką za wystawioną fakturę, pracownik zwraca niewykorzystaną zaliczkę….,
  • kartą płatniczą – klient płaci kartą za otrzymany towar lub wykonaną usługę.

W rejestrach typu KONTO BANKOWE, płatności mogą być dokonywane:

  • gotówką – np. zasilenie rachunku bankowego gotówką,
  • przelewem – zasilenie lub wypłata z rachunku bankowego przelewem,
  • kartą płatniczą – klient płaci kartą, centrum autoryzacyjne przelewa pieniądze na nasze konto.

W rejestrach typu KARTA KREDYTOWA płatności mogą być dokonywane:

  • gotówką – wpłata gotówki na rachunek obsługujący kartę,
  • przelewem – przelew (zasilenie) konta obsługującego kartę,
  • kartą płatniczą – płacimy firmową kartą płatniczą.

Zapisy kasowe/bankowe – kategorie

Bardzo cenną informacją, jaką może zawierać każdy zapis w raporcie kasowym/bankowym jest jego kategoria. Dwupoziomowa lista kategorii, wspólna dla wszystkich modułów programu, służy między innymi do klasyfikowania dokumentów. Zatem, z każdym zapisem w raporcie możemy skojarzyć rodzaj kosztu lub przychodu, z którym jest on związany.

Przykład
Jeśli wszystkie zapisy w raportach bankowych związane z naliczeniem odsetek od lokat oznaczymy kategorią typu przychód, INNE_PRZYCHODY i kategorią szczegółową ODSETKI_Z_LOKAT – w każdej chwili dostępną będziemy mieli informację pokazującą łączne kwoty, które uzyskaliśmy lokując pieniądze w banku.

Kategorie na zapisach kasowych/bankowych można nadawać „ręcznie”, w chwili wprowadzania zapisu. Jeśli zapis jest skojarzony z kontrahentem lub transakcją, która została wcześniej oznaczona kategorią – taka kategoria jest dziedziczona na zapis kasowy/bankowy.

Przykład
Jeśli faktury kosztowe związane z płatnościami za utrzymanie biura oznaczymy kategorią typu koszt, UTRZYMANIE_BIURA i bardziej szczegółowo podzielimy je na płatności za ENERGIĘ, TELEFONY, WYNAJEM, SPRZĄTANIE… to w chwili generowania zapisów kasowych/bankowych związanych z tymi fakturami odpowiednie kategorie zostaną przez nie odziedziczone. Wtedy korzystając wyłącznie z modułu Kasa/Bank możemy wykonać interesującą analizę kosztów w dowolnym okresie czasu.

Preliminarz płatności

Preliminarz płatności to lista wszystkich zaplanowanych na przyszłość zdarzeń związanych z przychodami i rozchodami środków finansowych w firmie.

Preliminarz płatności w swojej strukturze odpowiada podziałowi na rejestry kasowe/bankowe. Planując, zatem przepływ środków finansowych w firmie od razu przypisujemy przyszłe przychody i rozchody do odpowiednich rejestrów (kont bankowych, kas czy firmowych kart płatniczych).

Planowane zdarzenia w Preliminarzu mogą być: 

  • automatycznie dopisywane przez program w chwili wystawiania dokumentu, który pociąga za sobą konieczność uregulowania płatności. Przykładami mogą być: zatwierdzona faktura sprzedaży lub zakupu z odroczoną płatnością, przygotowana, ale jeszcze nie zrealizowana lista płac, związana z wstępnie naliczoną deklaracją VAT7 zapłata podatku VAT do urzędu skarbowego itd. Jak widać więc, zapisy w Preliminarzu mogą pochodzić z różnych modułów systemu Comarch ERP Optima.
  • wprowadzane przez operatora „ręcznie” z poziomu Preliminarza. Przykładami mogą być: planowane zakupy wyposażenia do firmy (nie mamy jeszcze dokumentu zakupu, ale planujemy określony wydatek), planowane wpływy środków finansowych niezwiązane z dokonywanymi transakcjami (np. dopłaty wspólników do kapitału firmy) itd.

Dzięki zdarzeniom zapisanym w Preliminarzu uzyskujemy możliwość:

  • dokładnego śledzenia bieżącego stanu naszych zobowiązań i należności,
  • dużą łatwość rozliczania planowanych płatności z zapisami potwierdzającymi ich realizację,
  • możliwość kompensowania ze sobą zdarzeń,
  • prognozowania na przyszłość przepływu i stanu środków finansowych w firmie,
  • oceny planowanych wydatków w podziale na poszczególne kategorie – prognozy dla kategorii, które przyniosą nam największe zyski i największe koszty.

Rozliczenia i kompensaty

Rozliczenia: funkcja rozliczeń umożliwia kojarzenie ze sobą otrzymanych bądź dokonanych zapłat z należnościami lub zobowiązaniami. Innymi słowy umożliwia powiązanie dokonanych zapisów kasowych/bankowych z planowanymi zdarzeniami z Preliminarza płatności.

Rozliczanie dokumentów może być dokonywane z poziomu każdego z nich oddzielnie (zarówno z poziomu nierozliczonego zdarzenia w Preliminarzu, jak i nierozliczonego zapisu w kasie), jak również automatycznie z poziomu listy nierozliczonych dokumentów dla wskazanego kontrahenta.

Przykład

Planowaną zapłatę za fakturę sprzedaży FA/000234/2010 na kwotę 1200 zł rozliczamy z otrzymanym wyciągiem bankowym WB/00433/2010/BPH potwierdzającym wpłatę klienta na nasze konto.
Preliminarz płatnościZapisy kasowe/bankowe

Przykład
Dwie niezapłacone faktury kontrahenta na kwoty 800 i 2500 zł rozliczamy na podstawie jednej wpłaty klienta potwierdzonej wyciągiem bankowym, na kwotę 3300 zł.

Przykład
Niezapłaconą fakturę zakupu FZ/001111/2010 na 5700 zł regulujemy dwoma wpłatami – 700 zł gotówką i 5000 zł przelewem na konto dostawcy.

Powyższe, proste przykłady pokazują podstawowe schematy, jakie można stosować podczas rozliczania nieuregulowanych płatności zapisanych w Preliminarzu i zapisów kasowych/bankowych potwierdzających wpływ lub rozchód środków finansowych. Rozliczenia mogą być wykonywane w stosunku jeden do jeden, jeden do wielu i wiele do wielu.

Po dokonaniu rozliczenia zarówno zdarzenia z Preliminarza jak i zapisy w rejestrach kasowych/bankowych otrzymują status rozliczonych (lub częściowo rozliczonych, jeśli płatność nie jest zrealizowana w całości).

Kompensaty: innym sposobem rozliczania dokumentów są kompensaty. Kompensować ze sobą można np. dwa zapisy kasowe/bankowe lub dwa planowane zdarzenia z Preliminarza, pod warunkiem, że kierunki przepływu środków finansowych na kompensowanych dokumentach są przeciwne.

Uwaga
Wydruk potwierdzenia kompensaty w systemie jest dostępny w Preliminarzu płatności, po wybraniu w filtrze podmiotu oraz rozliczone częściowo/całkowicie.

Przykład

W Preliminarzu płatności wprowadzone są dwa zdarzenia. Pierwsze, to przewidywana realizacja płatności za fakturę sprzedaży, na kwotę 1230 zł. Drugie zdarzenie w Preliminarzu to planowany zwrot 1230 zł ponieważ kontrahent zwrócił zakupiony towar. Obydwa zdarzenia można ze sobą skompensować zanim nastąpi faktyczny przepływ środków finansowych (np. zanim zostaną zrealizowane przelewy).
Preliminarz płatności:

Przykład
 Jeden z kontrahentów jest naszym dostawcą i jednocześnie odbiorcą. Dokonaliśmy u niego zakupu potwierdzonego fakturą FZ/00234/2010/WYP na kwotę 5420 zł. FZ z odroczoną płatnością utworzyła zapis w Preliminarzu planujący realizację płatności. Kontrahent dokonał u nas dwóch zakupów, na które wystawiliśmy faktury sprzedaży z odroczonymi płatnościami na kwoty 1500 zł i 1320 zł.
Preliminarz płatności:

Kompensata tych trzech zdarzeń spowoduje, że nierozliczona kwota na fakturze zakupu FZ pozostanie równa 2600 zł. Faktury sprzedaży zostaną rozliczone całkowicie. Tak więc jedyną operacją finansową, którą należy przeprowadzić w odniesieniu do tych trzech dokumentów jest wykonanie przez naszą firmę przelewu na kwotę 2600 zł.

Przykład
Na liście zapisów kasowych odnotowaliśmy wypłatę zaliczki dla jednego z pracowników – KW/000222/2010/KG na kwotę 500 zł. Następnego dnia pracownik zwraca całość zaliczki, na podstawie KP/004323/2010/KG.
Zapisy kasowe/bankowe:

Obydwa zapisy kasowe można ze sobą skompensować. Po dokonaniu kompensaty obydwa otrzymają status rozliczonych. 

Zasady numeracji dokumentów

Numeracja dokumentów w systemie Comarch ERP Optima jest dosyć elastyczna. Rozpoczynając pracę z programem, w chwili jego konfiguracji, można dla podstawowych typów dokumentów zdefiniować sposób, w jaki będą numerowane. W module Kasa/Bank dotyczy to raportów kasowych/bankowych numerowanych w obrębie rejestrów i zapisów kasowych/bankowych numerowanych w obrębie raportów kasowych/bankowych. Określenie schematów numeracji umożliwia funkcja Lista definicji dokumentów.

Maksymalnie numer dokumentu może składać się z pięciu sekcji. Zawartość sekcji mogą stanowić:

SYMBOL DOKUMENTU – to maksymalnie 5 znakowe oznaczenie typu dokumentu. Symbol musi obowiązkowo występować w schemacie numeracji dokumentu. Może zawierać wyłącznie litery lub cyfry (w szczególności nie może zawierać znaków „/” oraz „@”).

REJESTR – tu można wykorzystać np. nazwę rejestru bankowego lub kasowego. Maksymalna długość sekcji REJESTR to 5 znaków (liter lub cyfr).

NUMER – to zmienna część pełnego numeru dokumentu. Dla każdego kolejno wystawianego dokumentu danego typu program sekcję z numerem będzie zwiększał o jeden. Maksymalny numer (a więc maksymalna ilość dokumentów wystawiona w danym ciągu numerów) może składać się z sześciu cyfr (999 999).

MIESIĄC – dwa znaki (cyfry) określające miesiąc. Jeśli w numerze dokumentu umieścimy miesiąc – wraz ze zmianą miesiąca numeracja rozpoczyna się od 1.

ROK KALENDARZOWY – czterocyfrowy rok kalendarzowy pobierany z daty systemowej komputera.

ROK OBRACHUNKOWY – wykorzystywany tylko w przypadku, gdy system Comarch ERP Optima zawiera moduł do obsługi pełnej księgowości. Rok obrachunkowy może być różny od roku kalendarzowego. Jego długość oraz datę rozpoczęcia można określić w konfiguracji programu.

SEKCJA PUSTA – może wystąpić tylko jako pierwsza lub ostatnia w numerze.

Przykład
Jeśli symbolem oznaczającym raporty kasowe/bankowe jest skrót RKB, numeracja dotyczy raportów w rejestrze związanym z rachunkiem w banku BPH i numeracja raportów w tym rejestrze ma być ciągła w obrębie roku kalendarzowego – schemat numeracji może wyglądać tak: RKB/000023/2010/BPH. Kolejność sekcji w numerze jest dowolna.

Przykład
Jeśli typ zapisów kasowych/bankowych oznaczających przychód oznaczymy przez KP (wpłata) i definiujemy schemat numeracji zapisów w rejestrze BPH oraz zależy nam na numeracji ciągłej, ale w obrębie miesiąca, przykładowy numer zapisu może wyglądać tak: KP/000345/06/2010/BPH. Jest to 345 wpłata w czerwcu 2010, w rejestrze BPH. Ponieważ w numerze został użyty miesiąc, zmiana miesiąca spowoduje rozpoczęcie numeracji od 1.

Formy płatności

W systemie Comarch ERP Optima zdefiniowanych jest 5 podstawowych form płatności: czek, gotówka, inna, kredyt, przelew. Dostępne są również 4 typy form płatności: Gotówka, Przelew, Karta, Kompensata. Użytkownik programu może na ich podstawie zdefiniować własne formy płatności. Np. przelew – 7 dni oznacza płatność przelewem z automatycznie ustawianym siedmiodniowym terminem płatności. Gotówka – standardowo oznacza płatność realizowaną przy wystawianiu faktury, ale gotówka – 3 dni może oznaczać zapłatę odroczoną na trzy dni.

Z każdą formą płatności można skojarzyć rejestr kasowy/bankowy, do którego program będzie domyślnie zapisywał operację wpłaty lub wypłaty.

Lista banków

Lista banków jest pomocniczym słownikiem, w którym zbierane są informacje o bankach właściwych naszej firmie, firmom naszych kontrahentów i urzędów. Pełni rolę pomocniczą – jest dostępna z każdego modułu programu, w każdym miejscu, w którym dane na temat banku mogą być potrzebne.

Listę banków można uzupełniać na bieżąco lub skorzystać z automatu importującego.

Uwaga
Import banków z bazy KIR jest dostępny wyłącznie dla Klientów z aktualną gwarancją.

Jeśli lista banków została raz zaimportowana – kolejny import może tylko uzupełnić dane o nieistniejących do tej pory bankach (trwa to znacznie krócej niż powtórny import pełnej listy).

Informacją jednoznacznie określającą bank jest Numer Rozliczeniowy Banku (NRB). W systemie Comarch ERP Optima dodatkowo każdy bank posiada swój Akronim, który również nie może się powtarzać.

W chwili wyboru wskazanego banku z listy pobierane są jego dane wraz z numerem rozliczeniowym, który stanowi pierwszy człon numeru każdego konta bankowego.

Obsługa pól związanych z bankiem

Podczas uzupełniania danych o banku na formularzu (np. zapisu bankowego, zdarzenia w Preliminarzu) program działa niejako dwuetapowo: 

  • po wprowadzeniu banku, w zależności od jego ustawień, proponuje schemat numeru rachunku bankowego prawdopodobny dla tego banku. Uwzględniane są tutaj wszystkie zasady obowiązujące dla danego schematu numeracji (standardowa lub IBAN).
  • Po wprowadzeniu pełnego numeru konta – sprawdza jego poprawność w zależności od ustawień flagi IBAN na formularzu (dziedziczonej z formularza banku).

Numeracja rachunków bankowych

W systemie Comarch ERP Optima obsługiwane jest zarówno stosowany dotychczas w Polsce standard numeracji rachunków bankowych, jak i system numeracji IBAN. Należy pamiętać, że od lipca 2004 obowiązuje w Polsce system numeracji IBAN.

Uwaga

Format rachunku bankowego rozpoznawany jest przez system w oparciu o wartość parametru IBAN na formularzu. Wartość ta jest dziedziczona z formularza banku (parametr Bank prowadzi numerację w standardzie IBAN) – można ją jednak zmienić dla danego formularza.
Jeśli parametr jest aktywny – numer rachunku jest traktowany, jako IBAN i jego poprawność jest sprawdzana wg algorytmu stosowanego dla tej numeracji. Poprawnośc numeru IBAN jest sprawdzana dla polskich numerów rachunków.
Jeśli parametr nie jest aktywny – numer traktowany jest jako numer standardowy i sprawdzana jest poprawność segmentu NRB (wg algorytmu modulo).

Numeracja IBAN

Walidacja (sprawdzanie poprawności) numerów IBAN wykonywane jest wg algorytmu obowiązującego dla tego systemu.

Ogólnie Numer IBAN składa się z: 

  • 2 znaków alfanumerycznych (kod kraju),
  • 2-cyfrowej sumy kontrolnej,
  • członu BBAN (Basic Bank Account Number). Człon BBAN zawiera kod kraju, kod zawierający cyfry i/lub znaki alfanumeryczne, który jest specyficzny dla banku oraz numer konta. Teoretyczna maksymalna długość członu BBAN wynosi 30 znaków.
  • W przypadku polskich banków numer IBAN składa się z czterech segmentów:
    • sygnatury kraju (PL),
    • dwucyfrowej liczby kontrolnej,
    • ośmiocyfrowego numeru rozliczeniowego banku,
    • numeru konta klienta, który może mieć długość do 16 znaków.

Jak więc widać powyżej całkowita długość numeru konta w systemie IBAN będzie wynosić 26 znaków (nie licząc separatorów) plus opcjonalnie dwa znaki na sygnaturę kraju (podawanie sygnatury kraju nie będzie obowiązkowe w transakcjach krajowych).

Nowe numery mogą wystąpić w następujących postaciach:

02 10201055 1234567891234567 lub

02102010551234567891234567 lub

PL02-1020-1055-1234-5678-9123-4567, gdzie:

  • 02 – oznacza przykładową liczbę kontrolną,
  • 10201055 – przykładowy numer oddziału PKO BP S.A.,
  • 1234567891234567 – przykładowy identyfikator rachunku klienta PKO BP S.A.

Dwa ostatnie człony razem są określane mianem numeru BBAN.

Ostatnia postać numeru (separator co 4 cyfry) może być stosowana w celu ułatwienia ustnego przekazania numeru rachunku.

Banki zagraniczne

Na formularzu banku (zakładka [Dodatkowe]) znajduje się parametr Bank zagraniczny. Jeśli parametr jest aktywny – numery rachunków w takim banku nie są walidowane (pod warunkiem, że nie jest równocześnie zaznaczony parametr IBAN).

Uwaga
Jeśli, na karcie banku zaznaczony jest zarówno parametr Bank zagraniczny, jak i Bank prowadzi rachunki w standardzie IBAN – program sprawdza poprawność numeracji rachunków dla takiego banku wg algorytmu stosowanego dla numeracji IBAN dla polskich numerów rachunków (bez domyślnego uwzględniania sygnatury PL).

Propozycja numeru rachunku bankowego

Po wybraniu banku program sprawdza, czy bank ten prowadzi numerację w standardzie IBAN (parametr na formularzu banku).

Jeśli TAK – sprawdza czy dany bank jest bankiem zagranicznym i w zależności od wartości parametru Bank zagraniczny na formularzu:

  • dla banku zagranicznego nie proponuje żadnego numeru rachunku,
  • dla banku krajowego wstawia schemat @@-NRB- (właściwy dla numeracji IBAN). Po wpisaniu numeru konta zamiast @@ pojawia się wyliczona suma kontrolna.

Kontrola poprawności numerów kont bankowych

Po wpisaniu numeru rachunku bankowego program sprawdza jako pierwsze czy dany numer jest numerem IBAN (na podstawie zaznaczenia parametru na danym formularzu).

Dla numerów IBAN: 

  • dla banku zagranicznego – sprawdza zgodność wpisanego numeru ze standardem IBAN dla polskich numerów rachunków,
  • dla banku krajowego sprawdza zgodność ze standardem IBAN. Podczas sprawdzania (wyliczania) sumy kontrolnej zakładane jest, że numer zaczyna się od sygnatury kraju PL. Następnie z numeru wyodrębniany jest Numer Rozliczeniowy Banku i sprawdzana jest jego zgodność z algorytmem modulo. [/su_link]

Elektroniczna wymiana danych z bankiem

Elektroniczna wymiana danych z bankami staje się coraz bardziej popularną formą przekazywania do banków zleceń przelewów i uzyskiwania informacji o dokonanych przez bank transakcjach (wyciągi bankowe).

System Comarch ERP Optima pozwala na elektroniczną wymianę danych z bankiem zarówno poprzez eksport przelewów do pliku tekstowego, jak również import zrealizowanych przelewów z pliku dostarczonego przez bank. Użytkownik może sam zdefiniować format w oparciu o informacje dostarczone przez bank. W programie są predefiniowane standardowe formaty:

  • Alior Bank WebService
  • BANKZKH,
  • BGŻ BNP Paribas WebService,
  • BPH BusinessNet (import)/PekaoBIZNES24 (import),
  • CitiBank,
  • CitiDirect,
  • Elixir-O BPH,
  • Elixir-O BPH (split payment),
  • Elixir-O iBRE,
  • ING WebService,
  • KASABUF.TXT i BANKBUF.TXT (import),
  • KASAZKH,
  • KB24 – Kredyt Bank (eksport),
  • Pekao WebService,
  • Przelewy krajowe (xml),
  • Przelewy SEPA (xml),
  • Przelewy SEPA BZWBK (xml),
  • Przelewy walutowe (xml),
  • Raiffeisen WebService,
  • US – Bank Śląski,
  • Videotel,
  • ZUS - Bank Śląski.

Standardowe formaty tekstowe można zaimportować z serwera firmy Comarch. Import powoduje nadpisanie formatu standardowego zaktualizowanym formatem z serwera.

Uwaga
Import formatów przelewów z serwera COMARCH jest dostępny wyłącznie dla Klientów z aktualną gwarancją.

Uwaga
Bank Śląski wydał certyfikat dla systemu Comarch ERP Optima potwierdzający generacje danych o płatnościach zgodnie ze standardami systemów bankowości elektronicznej oferowanych przez Bank Śląski, lidera wśród banków w zakresie obsługi elektronicznej firm.

Karty płatnicze

Dokonywanie płatności za pomocą kart płatniczych staje się coraz bardziej popularne. Dlatego moduł Kasa/Bank systemu Comarch ERP Optima stwarza możliwość zarówno obsługi transakcji wykonywanych własną (firmową) kartą płatniczą jak i ewidencji i rozliczeń płatności kartami dokonywanymi przez kontrahentów firmy.

Firmowe karty płatnicze

Dla każdej z firmowych kart płatniczych warto założyć oddzielny rejestr kasowy/bankowy typu KARTA. Zwłaszcza w przypadku kart płatniczych, które nie są związane z żadnym rachunkiem bankowym, prowadzenie osobnej ewidencji płatności kartą pozwoli na otrzymywanie bieżących danych o stanie zadłużenia karty i wymaganych przez bank spłatach.

Karta płatnicza klienta

Klienci mogą regulować płatności kartami płatniczymi wydanymi w różnych systemach (np. VISA, MasterCard) i przez różne banki. W programie zdefiniowana jest lista najczęściej spotykanych kart płatniczych i do nich należą:

MasterCard, VISA, American Express, Dinners Club / Carte Blanche, enRoute, Discover i JCB.

W chwili, gdy nasz kontrahent płaci kartą – program wymaga wpisania typu karty, jej numeru i daty ważności. Dla wyżej wymienionych kart sprawdzane są algorytmy badające poprawność wprowadzonego numeru.

Do listy kart płatniczych standardowo obsługiwanych przez program użytkownik może dopisać inne pozycje.

Walidacja kart kredytowych

Walidacja numerów kart na rejestrach kasowych

Podczas zakładania rejestru kasowego typu karta płatnicza nie jest podawany konkretny typ karty. Podawany jest natomiast bank powiązany z kartą oraz numer karty.

Walidacja numeru karty na tym poziomie przebiega podobnie jak w przypadku rachunków bankowych:

  • pierwszy segment (opcjonalny) traktowany jest jako NRB i sprawdzany wg algorytmu modulo,
  • drugi segment (wymagany) traktowany jest jako właściwy numer karty i sprawdzany wg algorytmu Luhna.

Możliwe jest również wpisanie jedynie numeru karty (bez Numeru Rozliczeniowego Banku). Segment odpowiadający właściwemu numerowi karty na rejestrze może zawierać trzy kreski grupujące cyfry numeru karty w cztery sekcje lub może nie zawierać żadnej kreski (jedna sekcja). Podobnie jak w przypadku numeru rachunku – numer karty nie może rozpoczynać się od kreski natomiast w odróżnieniu od numeru rachunku – nie mamy tu subkont, z czego wynika, że pełny numer karty składa się z co najwyżej dwóch segmentów: NRB oraz właściwego numeru konta, z których tylko numer konta jest wymagany.

Uwaga
Konfiguracji firmy/ Kasa i Bank/ Parametry znajduje się parametr Kontrola numerów kart kredytowych, który włącza/ wyłącza mechanizm sprawdzania poprawności karty. Jeśli parametr nie jest aktywny program nie sprawdza poprawności wpisanego numeru karty.

Algorytm sprawdzania numerów kart na zapisach kasowych/bankowych

Numery kart kredytowych składają się z 13 do 16 cyfr. Pierwsze sześć to numer identyfikujący bank, który wydał kartę. Kolejne ustala bank wydający kartę. Ostatnia cyfra jest cyfrą kontrolną.

Numer karty kredytowej jest numerem, który sam w sobie jest w stanie weryfikować poprawność. Weryfikacja poprawności numeru jest warunkiem koniecznym, aczkolwiek niewystarczającym do stwierdzenia, czy karta jest ważna. Jeżeli numer nie przechodzi algorytmu weryfikacji, wiadomo, że po prostu nie jest prawdziwym numerem karty. Jeżeli przechodzi weryfikację, oznacza to, że może on być numerem karty, dalsze sprawdzanie należy wykonać poprzez kontakt z centrum autoryzacyjnym kart kredytowych.

Podczas walidacji numeru karty kredytowej sprawdzane są kolejno:

  • Czy numer składa się tylko z cyfr.
  • Poprawność wg tzw. algorytmu Luhn’a.
  • Czy numer wskazuje na podany typ karty płatniczej.

Rodzaj kartyPrefiksDługość
MasterCard51-5516
VISA413.16
American Express34.3715
Dinners Club / Carte Blanche300-305, 36, 3814
EnRoute2014, 214915
Discover601116
JCB316
JCB2131, 180015

Jak to działa?

To zależy od karty, która jest weryfikowana. Numer może przejść algorytm Luhn’a, ale musi on być również zgodny z określonym typem karty. Na przykład numer karty VISA musi zaczynać się od cyfry 4 i składać się z 13 lub 16 cyfr, np. 4111111111111111. Poprawny numer MasterCard musi się zaczynać od cyfry 5, a jego druga cyfra musi być z przedziału od 1 do 5 oraz cały numer musi składać się z 16 cyfr, np. 5500000000000004. Numery kart JCB zaczynają się od 3 i mają 16 cyfr albo zaczynają się od 2131 lub 1800 i mają 15 cyfr.

Uwaga
Comarch ERP Optima nie pozwala na wpisanie niepoprawnego numeru karty. Program nie pozwoli również zaakceptować zapisu kasowego jeśli wpisany numer karty nie spełnia warunków ustalonych dla wybranego typu karty (np. nr karty VISA 4444444444444448 i wybrany typ Master Card). Wyświetlony zostanie komunikat o nie spełnieniu algorytmu walidacji dla konkretnego, predefiniowanego typu karty płatniczej.

Uwaga
Konfiguracji firmy/ Kasa i Bank/ parametry znajduje się parametr Kontrola numerów kart kredytowych, który odpowiada za działanie mechanizmu sprawdzania poprawności karty. Jeśli parametr nie jest zaznaczony – numer karty nie jest sprawdzany algorytmem Luhna. Nie są również sprawdzane warunki zdefiniowane dla określonego typu karty.

Płatność kartą kredytową

Ze względu na różny sposób rozliczania płatności kartą kredytową w firmach wprowadzono parametr Automatycznie generuj dokumenty zapłaty kartą kredytową: 

  • jeśli parametr jest aktywny – po zatwierdzeniu dokumentu z formą płatności typu karta program tworzy zapis kasowy/bankowy w raporcie.
  • Jeśli parametr nie jest aktywny – płatność kartą, niezależnie od terminu, powoduje powstanie zapisu w Preliminarzu płatności o statusie Nierozliczony

Parametr jest dostępny w Konfiguracji firmy/ Kasa i Bank/ Parametry.

Aby automatyczne rozliczanie płatności kartą zadziałało dla dokumentów dodawanych do rejestru VAT/ ewidencji dodatkowej, muszą być również zaznaczone parametry Automatyczna generacja kasy dla rejestrów VAT/ Automatyczna generacja kasy dla ewidencji dodatkowej Konfiguracji Firmy/ Kasa/Bank/ Parametry.

Dotyczy wersji: 2018.6.1

Split payment – metoda podzielonej płatności

Od 1 lipca 2018 roku wchodzi w życie ustawa z 15 grudnia 2017 roku o zmianie ustawy o podatku od towarów i usług oraz niektórych innych ustaw (Dz.U. 2018 poz. 62). Pozwala ona na stosowanie mechanizmu podzielonej płatności (tzw. split payment). Metoda ta polega na tym, że płatność za towar lub usługę może być realizowana na dwa konta:

  • konto VAT dostawcy, na które zostanie przekazana kwota podatku VAT,
  • konto rozliczeniowe dostawcy, na które zostanie przekazana kwota netto za nabyte towary czy usługi

Mechanizm ten ma chronić nabywcę przed solidarną odpowiedzialnością w przypadku wystąpienia ‘karuzeli VAT’. Nabywca dokonując płatności zastrzega sobie, że część przelanej kwoty ma zostać zablokowana na specjalnym rachunku VAT dostawcy. Dostęp do środków zgromadzonych na rachunku VAT jest ograniczony.

Stosowanie metody split payment jest dobrowolne i może dotyczyć wybranych kontrahentów lub wskazanych dokumentów.  W sytuacji, gdy wszystkie transakcje z danym kontrahentem będą realizowane z zastosowaniem metody split payment proponujemy odnotować taką informację na formularzu kontrahenta.

Formularz kontrahenta – zakładka Płatności

Zaznaczenie tego parametru powoduje, że płatności złotówkowe trafiające do rejestru bankowego mają automatycznie ustawioną metodę podzielonej płatności.

Dotyczy to dokumentów handlowych i ich korekt:

  • faktury sprzedaży,
  • faktury zakupu,
  • faktury zaliczkowej,
  • faktury finalnej

oraz dokumentów wprowadzanych bezpośrednio do rejestru VAT

Uwaga
Parametr dotyczący podzielonej płatności (Split payment) zaznaczymy na formularzu kontrahenta o statusie Podmiot gospodarczy, dla którego parametr Nie rozliczaj płatności jest niezaznaczony.

Zmiana ustawienia tego parametru może być wykonana z poziomu formularza danego kontrahenta lub możemy ją wykonać seryjnie dla zaznaczonych kontrahentów. Służy do tego operacja seryjna – Zmień warunki płatności.

Lista kontrahentów – seryjna zmiana warunków płatności

Metoda podzielonej płatności dostępna jest na zdarzeniach, które znajdują się w rejestrach bankowych i dotyczą kontrahentów lub urzędów.

Jeżeli płatność podlega metodzie split payment (parametr Split payment jest zaznaczony) to na zdarzeniu pojawiają się dodatkowe pola: Kwota VAT, NIP i Numer dokumentu. Na zdarzeniach, które nie mają zaznaczonego parametru Split payment pola są niewidoczne.

W przypadku dokumentów handlowych (faktury zakupu, faktury sprzedaży, faktury zaliczkowej, faktury finalnej i wystawionych do nich korekt) oraz dokumentów wprowadzonych do rejestru VAT parametr dziedziczony jest z karty kontrahenta, dla którego został wystawiony dokument. Parametr dziedziczony jest na wszystkie płatności związane z tym dokumentem. Wyjątek stanowią dokumenty wystawione w innej walucie. Jeśli na dokumencie walutowym parametr Płatność VAT w PLN jest:

  • zaznaczony – powstają dwa zdarzenia, pierwsze w walucie dokumentu (kwota netto) i parametr Split payment nie jest zaznaczony oraz drugie zdarzenie w PLN (równowartość kwoty VAT) z zaznaczonym parametrem o podzielonej płatności.
  • niezaznaczony – powstaje płatność w walucie, parametr związany z podzieloną płatnością nie jest zaznaczony.

Jeżeli dokument został wystawiony dla podmiotu znajdującego się na liście Urzędy parametr Split payment zaznacza się na płatności automatycznie. Pozostałe pola odczytywane są z dokumentu powiązanego z daną płatnością.

Na płatnościach do transakcji związanej z kontrahentem, który ma zaznaczony parametr Split payment program automatycznie:

  • zaznacza Split payment – parametr odczytany jest z karty kontrahenta, który został wskazany jako główny kontrahent na fakturze/w rejestrze VAT. Nie ma znaczenia ustawienie tego parametru na płatniku (kontrahencie), który występuje na tym dokumencie,
  • uzupełnia Numer dokumentu – pobiera go z dokumentu, z którym związana jest płatność,
  • uzupełnia Numer NIP kontrahenta – numer NIP pobierany jest z dokumentu, z którym związana jest dana płatność (numer NIP wpisany na zakładce 2. Kontrahent na fakturze/w rejestrze VAT),
  • przenosi łączną kwotę VAT.

Jakie czynności należy wykonać, aby w programie korzystać z metody podzielonej płatności (split payment)?

  • Założyć rejestr bankowy w PLN i zaznaczyć na nim parametr Rachunek VAT dla split payment. Otworzyć raporty bankowe.
  • Na formularzu kontrahenta, z którym rozliczenia będziemy prowadzić z uwzględnieniem metody split payment zaznaczyć parametr Split payment.
  • Jeśli podzielona płatność ma dotyczyć tylko wybranych płatności w Preliminarzu płatności na wybranych zdarzeniach zaznaczamy metodę split payment oraz uzupełnić informację o numerze dokumentu i kwocie VAT.
  • Tworząc zlecenia przelewów do banku wskazać właściwy format dla przelewów split payment.

Więcej informacji na temat split payment w tym tworzenia zleceń przelewu do banku znajdziecie Państwo na naszym portalu.

 




Dokumenty w walucie obcej

Wielowalutowość obejmuje możliwość rejestracji płatności w walucie oraz rozliczania tych płatności poprzez wpłaty dokonywane w kasie gotówkowej (lub rachunku bankowym).

Na podstawie dokonanych rozliczeń program potrafi wyliczyć oraz zaksięgować kwotę różnic kursowych.

W Preliminarzu istnieje możliwość rejestracji płatności w walucie. Zdarzenie w Preliminarzu ma możliwość określenia kwoty walutowej, waluty dokumentu, waluty rozliczenia, kursu i kwoty złotówkowej.

Zapisy kasowe/bankowe umożliwiają realizację zapłat za zdarzenia walutowe. Należy tu zaznaczyć, że nie jest to równoznaczne z rejestracją operacji prowadzonych w kasie walutowej, a jest to jedynie możliwość rozliczania zdarzeń walutowych zapisami złotówkowymi. Typową operacją obsługiwaną w tym modelu jest zlecenie bankowi dokonania zapłaty w walucie na konto kontrahenta, za co bank obciąża nasz rachunek prowadzony w złotówkach. Zapisy mają możliwość określenia waluty rozliczenia, kursu i kwoty w walucie do rozliczenia.

Program pozwala na dokonanie rozliczenia pomiędzy dwoma dokumentami kasowymi/ bankowymi mającymi identyczną walutę rozliczenia.

Fakt rozliczenia powoduje powstanie różnicy kursowej. Dla potrzeb księgowych rozliczenie walutowe jest równoznaczne z dokumentem różnicy kursowej – dokument taki podlega księgowaniu.

Uwaga
W przypadku, gdy użytkownik prowadzi kasy bądź rachunki walutowe i chce tam rejestrować automatycznie płatności związane z dokumentami wystawionymi w innych modułach, powinien takie rachunki skojarzyć z formami płatności w Konfiguracji. Zasady kojarzenia rejestrów walutowych z wykorzystywanymi formami płatności zostały opisane w rozdziale poświęconym współpracy z innymi modułami systemu Comarch ERP Optima.

Konfiguracja

Listę walut definiuje użytkownik w Konfiguracji programu/ Ogólne/ Waluty.

Aby możliwe było wystawianie i prawidłowe przeliczanie wartości dokumentu dla każdej waluty należy zdefiniować kurs. W systemie może funkcjonować kilka typów kursów (np. kurs w banku PKO BP S.A., kurs średni NBP itp.). Rodzaje kursów, które są wykorzystywane w firmie definiuje użytkownik z poziomu Konfiguracji programu/ Ogólne/ Typy kursów walut. Jeden z nich musi być kursem domyślnym i jest proponowany na każdym nowym dokumencie w walucie.

Określenie notowania na dany dzień jest możliwe z poziomu listy walut po wciśnięciu przycisku .

Uwaga
Notowania powinny być uaktualniane każdego dnia. W innym wypadku proponowany jest ostatnio wprowadzony kurs lub kurs 1:1 (w zależności od ustawienia parametru Pobieraj ostatnio ustalony kurs waluty w Konfiguracji firmy/ Ogólne/ Parametry).

Jeśli parametr jest aktywny – program proponuje ostatnio ustalony kurs, jeśli nie – przy próbie wystawienia dokumentu w walucie informuje użytkownika o braku aktualnego kursu i proponuje kurs ręczny 1:1. 

Zapisy kasowe/bankowe

Na liście zapisów kasowych/bankowych dostępne jest pole Waluta, w którym można wybrać:

  • Jedną ze zdefiniowanych walut – wówczas lista zostanie zawężona do zapisów w danej walucie (w tym również PLN).
  • Wszystkie – lista zawiera wszystkie zapisy kasowe, niezależnie od waluty.

Uwaga
Jeśli rejestr jest rejestrem walutowym, wtedy istnieje możliwość wyboru tylko pomiędzy walutą rejestru a opcją wszystkie.

W zależności od wybranej opcji różnie działa funkcja sumowania wyfiltrowanych zapisów:

  • Jeśli wybrana jest konkretna waluta – w nagłówku kolumny pojawia się suma wyfiltrowanych zapisów w walucie oraz w przeliczeniu na PLN wg kursu zadeklarowanego na poszczególnych zapisach.
  • Jeśli wyświetlane są wszystkie zapisy (niezależnie od waluty) – w nagłówku kolumny pojawia się suma wyfiltrowanych zapisów w PLN wyliczona wg kursów podanych na poszczególnych zapisach.

Na Formularzu zapisu kasowego/bankowego istnieje możliwość zadeklarowania waluty. Przy dodawaniu zapisu do rejestru w PLN, jako waluta dokumentu podpowiadana jest domyślna waluta przypisana na karcie kontrahenta wybranego na zapisie. W przypadku dodawania zapisu do rejestru walutowego, na dokumencie zawsze ustawiana jest waluta tego rejestru.

Na zapisach bankowych importowanych z pliku z banku oraz za pomocą usługi sieciowej (webservice) waluta dokumentu ustawiana jest zgodnie z walutą rejestru, do którego jest wykonywany import (działanie jest niezależne od domyślnej waluty przypisanej na karcie kontrahenta).

Uwaga
Należy pamiętać, że do rejestrów złotówkowych mogą być wprowadzane zapisy w dowolnych walutach. Zmiana waluty jest możliwa z poziomu zakładki [Rozliczenia]. W przypadku rejestrów walutowych można w nich wprowadzać tylko zapisy w walucie zgodnej z walutą rejestru.

Jeśli użytkownik wprowadza zapis w walucie obcej lub wybierze walutę obcą jako walutę rozliczenia, wówczas na zakładce [Rozliczenia] pojawiają się pola:

Niezależnie od tego, czy dokument jest wprowadzany do rejestru złotówkowego czy walutowego, dla każdego wprowadzonego zapisu oraz płatności zapamiętywane są dwie wartości: w walucie oraz w PLN. Na podstawie wartości złotówkowych w trakcie rozliczania dokumentów program wylicza różnice kursowe (niezależnie od tego, w jakim rejestrze zostały wprowadzone).

Uwaga
Przy ustawionym kursie nieokreślonym istnieje możliwość dodawania zapisów z wartością zero w walucie na dowolną wartość w PLN.

Typ kursu – typ kursu waluty (podstawowy, NBP, ręczny itp.) można wybrać po rozwinięciu listy. Lista dostępnych typów jest pobierana z Konfiguracji programu. Po wybraniu rodzaju kursu obok wyświetlana jest jego wartość na dzień wystawienia zapisu. Wartość kursu nie jest dostępna dla Użytkownika (pobierana jest z konfiguracji programu).

Wyjątkiem jest kurs ręczny, dla którego można wpisać notowanie bezpośrednio z poziomu formularza.

Jeśli użytkownik wybierze kurs nieokreślony – nie musi podawać konkretnego przelicznika (notowania), ale może wpisać wartość kwoty w walucie przeliczonej na PLN bezpośrednio w przeznaczone na to pole:

Kwota – kwota w walucie pobierana jest z pola kwota w górnej części formularza. Obok widoczna jest wartość w PLN wyliczona wg podanego kursu waluty. Istnieje możliwość zmiany zarówno kwoty w walucie (wówczas przeliczona zostanie kwota w PLN), jak i kwoty w PLN (wówczas przeliczona zostanie wartość w walucie). Wyjątek stanowi kurs nieokreślony, gdzie program nie stosuje żadnego przelicznika.

Pola RozliczonoPozostaje nie są dostępne dla użytkownika, a widoczne tam wartości są wyliczane na podstawie wprowadzonych rozliczeń.

Preliminarz płatności

Obsługa walut w Preliminarzu płatności została wprowadzona w sposób analogiczny jak w przypadku zapisów kasowych/ bankowych.

Na zakładkach zawierających listę zdarzeń dostępne jest pole Waluta, które umożliwia filtrowanie zdarzeń w zależności od waluty.

Na Formularzu zdarzenia, z poziomu zakładki [Rozliczenia], istnieje możliwość zdefiniowania waluty dokumentu i rozliczenia dla zdarzenia oraz:

  • Typu kursu – w przypadku podania zdefiniowanego wcześniej typu kursu,
  • Notowania – w przypadku kursu ręcznego,
  • Wartości w przeliczeniu na PLN – w przypadku kursu nieokreślonego.

Rozliczenia i kompensaty

Rozliczenie/ kompensata dokumentów jest możliwa tylko w sytuacji, gdy obydwa dokumenty mają taką samą walutę rozliczenia. Podczas dodawania zapisu rozliczającego lista proponowanych dokumentów jest domyślnie zawężana do zapisów/ zdarzeń dla danego kontrahenta w takiej samej walucie rozliczenia, jaką posiada dokument rozliczany.

Uwaga
Podczas rozliczania lub kompensowania dokumentów program kontroluje zgodność waluty rozliczenia na dokumentach, niezależnie od rejestrów, w których je wprowadzono. Umożliwia to rozliczanie dokumentów wprowadzonych w rejestrach złotówkowych oraz walutowych.

Uwaga
Zmiana waluty rozliczenia jest możliwa tylko na zapisach nierozliczonych i złotówkowych (Waluta dok. to PLN).

Podczas automatycznego rozliczania dokumentów kasowych (Kasa/Bank/ Dokumenty nierozliczone) – należy wybrać walutę rozliczenia obowiązującą na dokumentach, które będą rozliczane.

Podczas rozliczania dokumentów wystawionych w walucie obcej automatycznie wyliczane są różnice kursowe.

Różnice kursowe

Różnice kursowe są wyliczane przez program automatycznie.

Lista różnic dostępna jest w menu Kasa/ Bank/ Różnice kursowe.

Listę różnić kursowych można zawęzić do dokumentów z określonego zakresu dat. W tym celu należy zaznaczyć parametr Zakres dat oraz wskazać odpowiednie daty Od – Do

Lista obsługiwana jest przez standardowe przyciski obsługi listy, opisane szczegółowo tutaj. 

Uwaga
Na rozliczonych zapisach można zmienić notowanie – automatycznie zmieni się wtedy wartość wyliczonej różnicy kursowej. Możliwość zmiany kursu jest blokowana w chwili zaksięgowania dokumentu różnicy kursowej

Różnice kursowe – formularz

Dodatkowo dostępne są m. in. następujące przyciski:

 – Księguj dokumenty – istnieje możliwość zaksięgowania dokumentu różnicy kursowej (w zależności od rodzaju prowadzonej księgowości do Księgi Podatkowej, Księgi Handlowej lub Ewidencji Ryczałtowej).

Uwaga
Po zaksięgowaniu dokumentu nie ma możliwości usunięcia rozliczeń dla zapisów/ zdarzeń na podstawie, których została wyliczona różnica.  

Na Formularzu dokumentu wyliczone kwoty nie są edytowalne. Jedyne, co użytkownik może zmienić (do chwili zaksięgowania dokumentu), to schemat numeracji dokumentu i numer kolejny.

Z poziomu formularza możliwe jest podglądnięcie dokumentów, na podstawie których wyliczone zostały różnice kursowe. Obok konkretnych dokumentów znajdują się przyciski z lupką, których wciśnięcie spowoduje wyświetlenie odpowiedniego formularza.

W przypadku korzystania z Księgowości kontowej, na formularzu różnicy kursowej istnieje możliwość wskazania kont Wn oraz Ma, które mogą zostać wykorzystane podczas tworzeniu schematów księgowych.

Po zaksięgowaniu dokumentu różnicy kursowej (dotyczy to zarówno księgowości kontowej, jak i podatkowej), na formularzu pojawia się odwołanie do zaksięgowanego dokumentu – użytkownik ma możliwość podglądu.

Zasady powstawania dokumentów różnic kursowych:

  • Różnica kursowa jest wyliczana automatycznie w chwili rozliczenia dwóch dokumentów kasowych w takiej samej walucie i innym notowaniem.
  • Dokument nie jest edytowalny – wartości są wyliczane przez program.
  • W chwili zmiany kursu na rozliczanym zapisie kasowym – automatycznie zmienia się wartość wyliczonej różnicy kursowej.
  • W chwili usunięcia rozliczenia z poziomu zapisu kasowego/ zdarzenia – automatycznie kasowany jest dokument różnicy kursowej.
  • Zmiana notowania oraz usuwanie rozliczeń jest blokowane w chwili zaksięgowania dokumentu różnicy kursowej.
  • Jeśli płatność jest rozliczana w kilku ratach (np. jedna Faktura Sprzedaży jest rozliczana kilkoma wpłatami KP) – dla każdego rozliczenia tworzony jest odrębny dokument różnicy kursowej.

Inne dokumenty kasowe

Istnieje również możliwość generowania innych dokumentów w walutach obcych: Not odsetkowych, Ponagleń zapłaty oraz Potwierdzeń salda.

Dokumenty te są wyliczane na podstawie wprowadzonych wcześniej zapisów i zdarzeń. Należy pamiętać, że:

  • Dokumenty te mogą być generowane tylko na podstawie zapisów/ zdarzeń zarejestrowanych w takiej samej walucie.
  • Jeśli dokumenty te są generowane w walucie obcej – oprócz jej symbolu należy podać typ kursu oraz notowanie.
  • Wyliczona na tej podstawie wartość PLN jest przenoszona do księgowości (w przypadku Not odsetkowych).




Rejestry kasowe/bankowe

Cel ćwiczenia: przygotowanie bazy do pracy pod kątem modułu Kasa/Bank: założenie rejestru bankowego, utworzenie formy płatności oraz otworzenie raportu bankowego.

Lista banków jest już wprowadzona. Teraz pora na założenie rejestrów kasowych/bankowych.

Rejestr KASA jest definiowany w chwili zakładania nowej bazy danych. Na liście raportów rejestru KASA został otwarty domyślny raport z datą otwarcia zgodną z datą stworzenia bazy danych.

Założony został też pierwszy rejestr bankowy dla rachunku w banku PKO I O./KRAKÓW. Proszę sprawdzić, czy podane dla rachunku dane są prawidłowe oraz uzupełnić saldo otwarcia.

  • Z menu wybieramy Kasa/Bank/ Rejestry Kasowe/Bankowe. Edytujemy rejestr:
    • Rejestr: PKO
    • odznaczony parametr Numery obce
    • okres raportów: miesięczny (raz na miesiąc otrzymujemy wyciąg bankowy)
    • Saldo B.O.: 24 500 zł
    • zatwierdzamy formularz
  • Otwieramy pierwszy raport bankowy w rejestrze PKO:
    • ustawiamy kursor na liście rejestrów, na rejestrze PKO,
    • naciskamy ikonę z paska zadań „Raporty kasowe/bankowe”, która otworzy listę raportów powiązanych ze wskazanym rejestrem. W naszym przypadku lista jest pusta:
    • dodajemy nowy raport: Data otwarcia i Data zamknięcia – obejmują bieżący miesiąc.
    • zatwierdzamy formularz
    • na liście raport jest widoczny w kolorze zielonym – raport jest otwarty i można w nim wprowadzać zapisy
  • Jeśli jeszcze raz podglądniemy zatwierdzony raport. Wypełnione zostało pole Stan poprzedni. Przyjęło wartość 24 500 zł, ponieważ taki był B.O. na rachunku w banku PKO.

Załóżmy, że nasza firma prowadzi jeszcze jeden rachunek bankowy w Banku BPH (akronim na liście banków BPH I O./KRAKÓW, numer rozliczeniowy: 10601376). Bieżący stan rachunku wynosi 28 000 zł. Co tydzień z banku otrzymujemy wyciąg bankowy z wykazem zarejestrowanych transakcji.

Ponieważ z poziomu kreatora widocznego przy pierwszym uruchomieniu bazy możliwe jest zdefiniowanie tylko jednego rachunku bankowego firmy – drugi rejestr musimy założyć bezpośrednio w module Kasa/Bank. Na liście banków są już wpisane dane banku BPH, w którym rachunek jest prowadzony. Teraz należy założyć związany z nim rejestr:

  • Z menu wybieramy Kasa/Bank/ Rejestry kasowe/bankowe. Dodajemy nowy rejestr:
    • Akronim: BPH
    • Rejestr: BPH
    • Nazwa: Rachunek bieżący w banku BPH
    • Typ rejestru: Konto bankowe
    • Bank: wpisujemy akronim: BPH I O./KRAKÓW lub NRB: 10601376 lub wyszukujemy z listy
    • Numer rachunku: wprowadzamy numer rachunku 31 10601376 1234 1234 1234 1234
    • Okres raportów: Tygodniowy (ponieważ raz na tydzień otrzymujemy wyciąg bankowy)
    • Saldo B.O.: 28 000 zł
    • zatwierdzamy formularz

Podczas zatwierdzania formularza rachunku program pozwala na:

  • Otwarcie pierwszego raportu bankowego w rejestrze BPH:
    • należy zaznaczyć parametr Otworzyć nowy wyciąg z datą.
    • raport będzie obejmował okres tygodnia zawierającego wskazaną datę.
    • raport jest widoczny na liście raportów KB.
    • na liście wypełniona została kolumna Stan poprzedni. Przyjmie wartość 28 000 zł, ponieważ taki był B.O. na rachunku w banku BPH.
  • Zdefiniowanie formy płatności związanej z rejestrem BPH
    • należy zaznaczyć parametr Dodać nową formę płatności dla rachunku
    • program automatycznie doda formę płatności o nazwie przelew_BPH, typu przelew, skojarzoną z rejestrem BPH (jeśli Użytkownik nie zaznaczy parametru to nową formę może dopisać z poziomu System/ Konfiguracja/ Firma/ Kasa/Bank/ Formy płatności).
    • w firmie będą funkcjonowały dwie formy płatności dla przelewów:
      • przelew skojarzony z rachunkiem w PKO
      • przelew_BPH skojarzony z rachunkiem w banku BPH.




Moduł Kasa/Bank – informacje ogólne

Sprawnie zarządzana firma to taka, której kadra zarządzająca ma w każdej chwili dostęp do aktualnych informacji na temat kondycji finansowej firmy, rzeczywistych źródeł uzyskiwanych przychodów, ponoszonych kosztów (może niektóre da się zmniejszyć?) czy stanu bieżących należności i zobowiązań.

Dlatego system Comarch ERP Optima wyposażony został w moduł Kasa/Bank, którego zadaniem jest nie tylko prosta ewidencja wydatków i wpływów.

Korzystając z tego modułu można między innymi znaleźć odpowiedzi na pytania:

  • Jak wygląda przepływ środków pieniężnych w firmie? Odpowiedź może dotyczyć zarówno przeszłości – to raporty z dokonanych już zapisów kasowych/bankowych, jak i przyszłości – to analiza planowanych wpływów i wydatków.
  • Jak wygląda Preliminarz naszych płatności? Do Preliminarza trafiają zarówno planowane terminy spłat należności przez naszych kontrahentów i spłaty naszych zobowiązań, daty płatności podatków (np. zaakceptowane do realizacji deklaracje VAT), zatwierdzone listy płac, planowany wpływ odsetek z lokat bankowych, daty spłat kolejnych rat kredytów czy miesięczne płatności za energię, telefony, itd. Preliminarz płatności pozwala, więc przewidzieć przychody i wydatki w nadchodzącym czasie i na tej podstawie podjąć odpowiednie decyzje finansowe.
  • Jak wyglądają rozliczenia z dłużnikami i wierzycielami? To wykonywane w różnych przekrojach zestawienia niezrealizowanych płatności, listy największych dłużników i wierzycieli, zaległości wg typów dokumentów itd.
  • Co tak naprawdę przynosi nam zysk? W co inwestujemy? Co i dlaczego nas tak dużo kosztuje? – z każdym zapisem kasowym/bankowym skojarzona jest kategoria, której zapis dotyczy. Każdy zapis niesie, więc w sobie informację, jakiego rodzaju kosztu dotyczy lub jakiego typu przychód zwiększa nasze zyski. Na tej podstawie można wykonać bardzo pomocne zestawienia pokazujące rozkład kosztów i przychodów w firmie.

Funkcjonalność modułu Kasa/Bank obejmuje również:

  • Rozliczenia ze wszelkimi podmiotami prawnymi – kontrahentami i urzędami, a także z pracownikami.
  • Bankowość elektroniczną – a więc komunikację z systemami typu Home-Banking obejmującą zlecanie wykonania operacji do banku (przelewy wychodzące) oraz import zrealizowanych przelewów z pliku dostarczonego przez bank.
  • Słownik banków, który można uzupełnić ręcznie lub importując informacje o wszystkich bankach w Polsce z plików dostarczanych przez Krajową Izbę Rozliczeniową (KIR).
  • Słownik urzędów (US, ZUS…), który raz uzupełniony jest dostępny ze wszystkich pozostałych modułów systemu Comarch ERP Optima.
  • Inne słowniki – kontrahenci, pracownicy, wspólnicy, banki, urzędy, kategorie, formy płatności…
  • Definiowalne schematy numeracji dokumentów.
  • Import części danych z programów serii Comarch ERP Klasyka – np. lista kontrahentów, wspólników, rejestry VAT, listy płac, ewidencja samochodów, spis z natury…

Moduł Kasa/Bank ze swoją funkcjonalnością i zawartymi w nim ewidencjami zawiera, więc kompletne dane o ruchu środków pieniężnych w przedsiębiorstwie. Kompletność danych pozwala nie tylko na bieżące analizy wpływów i wydatków, ale również na generowanie precyzyjnych prognoz dotyczących przepływu środków pieniężnych. Takie prognozy stanowić mogą bardzo mocny instrument w rękach planistów, menedżerów i właścicieli firm, pozwalając skutecznie i z dużym wyprzedzeniem planować krótkofalową i długofalową strategię finansową.

Uwaga
Program Comarch ERP Optima umożliwia użytkownikom korzystanie z modułu Kasa/Bank Plus, który w porównaniu do modułu Kasa/Bank daje dodatkowo możliwość obsługi magazynu walut, rozliczania delegacji pracownika oraz zaawansowanych blokad do rejestrów kasowych/bankowych. Wszystkie informacje o module Kasa/Bank dotyczą również modułu Kasa/Bank Plus




Współpraca z modułem Płace i Kadry

System Comarch ERP Optima automatycznie generuje płatności w module Kasa/Bank dla wyliczanych list płac

Zasady generowania płatności dla modułu Płace i Kadry:

  • Przez zatwierdzenie listy płac rozumiane jest zamknięcie list za dany okres.
  • Dla niezamkniętych list płac powstaje zdarzenie w Preliminarzu niezależnie od formy płatności. Nie ma jednak możliwości jego rozliczenia do chwili zamknięcia listy.
  • Po zamknięciu listy płac (parametr dostępny na formularzu listy płac) powstaje zdarzenie w Preliminarzu o statusie nierozliczone, można je rozliczyć z zapisem kasowym/bankowym.

W programie istnieje również funkcja automatycznego generowania płatności do wyliczonych deklaracji podatkowych i ZUS. W Konfiguracji firmy/ Dane firmy / Deklaracje wybieramy formę płatności. Forma ta dotyczy wszystkich wygenerowanych w programie deklaracji.

Typ dokumentu dla płatności deklaracji – użytkownik wybiera rodzaj dokumentu zapisu kasowego/ bankowego związanego z podatkiem.

Forma płatności do deklaracji – wybieramy formę płatności dla podatków np. przelew.

Po wyliczeniu i zapamiętaniu deklaracji PIT-4, PIT-8A i DRA, gdy w danym miesiącu powstaje obowiązek przekazania kwot do zapłaty, generowany jest zapis w module Kasa/Bank zależny od parametru w Konfiguracji/Dane firmy/ Deklaracje Forma płatności do deklaracji. Odroczona forma płatności np. przelew generuje zapis w Preliminarzu płatności, do którego, po zablokowaniu deklaracji przed zmianami (parametr dostępny na formularzu deklaracji), można wystawić przelew bankowy lub wysłać do banku w odpowiednim formacie. Gotówka (zerowy termin płatności) – też w pierwszej kolejności zapis trafia do Preliminarza Płatności (kolor zielony). W momencie zablokowania deklaracji przed zmianami, zapis związany z podatkiem Do zapłaty w Preliminarzu płatności a płatny gotówką, powoduje automatycznie wygenerowanie zapisu w odpowiednim raporcie kasowym i otrzymuje status zapisu rozliczonego.

Domyślnie dla płatności związanych z deklaracjami proponowany jest typ dokumentu DEK i forma płatności – przelew.

Dodatkowo lista urzędów (Ogólne/ Inne/ Urzędy/ Urzędy ZUS) uzupełniona została o ZUS, dla którego zdefiniowane zostały trzy konta związane ze składkami na ubezpieczenia społeczne, zdrowotne i Fundusz Pracy wraz z FGŚP.

Uwaga
Aby wykasować deklaracje z listy deklaracji należy w pierwszej kolejności rozpiąć rozliczenia danego zapisu. W tym celu należy wejść z menu w Kasa/Bank/ Rozliczenia podmiotu na zakładkę Rozliczone i usunąć zapis rozliczający.

W programie jest możliwość zablokowania dostępu do rozliczeń pracowników poprzez zaznaczenie parametru w Konfiguracji programu/ Użytkowe/ OperatorzyBlokada dostępu do rozliczeń pracowników. Zaznaczenie parametru zablokuje dostęp do modułu kadrowo-płacowego zarówno w Comarch ERP Optima Płace i Kadry jak i Comarch ERP Optima Płace i Kadry Plus oraz dodatkowo do danych płacowych dostępnych w innych modułach, i tak:

  • W module Kasa/Bank – po zaznaczeniu parametru blokady ukryte zostaną na listach dokumentów rozliczonych i nierozliczonych te dokumenty kasowe/ bankowe, które są wystawione na podmiot typu pracownik. Na listach rozliczonych zapisów, gdy zostaną rozliczone ze sobą dokumenty, z których jeden jest wystawiony na pracownika, a drugi na inny podmiot, formatka rozliczenia będzie miała ukryte dane dotyczące dokumentu wystawionego na pracownika.

Uwaga
Nie jest zablokowane rozliczanie faktur zaliczkami pracowników nawet wtedy, gdy Operator ma włączoną blokadę. Będzie widział wszystkie nierozliczone zapisy k/b, będzie mógł pobrać z nich kwoty do rozliczenia dokumentu, który wprowadza. Będzie mógł usunąć rozliczenie z poziomu Preliminarza lub rozliczeń podmiotu wychodząc od zdarzenia jeżeli zdarzenie nie będzie wystawione na pracownika.

  • W modułach księgowych blokada spowoduje ukrycie w menu Księgowość gałęzi Wynagrodzenia oraz w Dokumentach źródłowych pozycji Listy płac.
  • W module Analizy – dla włączonego modułu z parametrem Pełne menu dla modułu Analizy, przy zaznaczonej blokadzie ukryte zostaną w głównym menu pozycja Kadry/Płace oraz w  Panelu analiz gałąź Kadry i Płace.
  • Praca rozproszona – wysyłane będą wszystkie zapisy, również te wystawione na pracownika. Dotyczy to także ręcznie wprowadzonych płatności do Preliminarza Płatności. Można zablokować Operatorowi eksport w modelu Pracy rozproszonej zakładając odpowiednią blokadę.
  • Eksport raportów kasowych/bankowych do Comarch ERP Klasyka – przez plik kasadokh.txt lub bankdokh.txt. W tej sytuacji należy założyć blokadę do funkcji skryptowych, które realizują ten eksport.

Rozliczanie wypłat w różnych walutach

Z uwagi na coraz częściej występującą sytuację zatrudniania pracowników poza Polską i wypłacania im wynagrodzeń w walucie obcej (przy zachowaniu polskich przepisów podatkowych i składkowych przy naliczaniu wypłat) wprowadzono w module Kasa/Bank/ Preliminarz płatności zmianę. Dodano funkcję przeliczenia wypłaty (kwoty netto) na inną walutę, niż wynika z dokumentu źródłowego, według kursu aktualnego na dany dzień. Oznacza to, że wypłaty są policzone w walucie PLN, tym samym powstają zdarzenia w walucie PLN, a w Preliminarzu płatności jest możliwość przeliczenia wypłaty na wybraną – przez użytkownika – walutę obcą.

W Konfiguracji programu/Ogólne/Waluty należy dodać waluty, które będą potrzebne do przeliczeń wynagrodzenia. Należy uzupełnić kurs waluty (np. przez import z NBP). Następnie trzeba sprawdzić, czy są naliczone wypłaty. Jeśli nie ma, należy je naliczyć i zamknąć. Po wykonaniu wymienionych czynności, można przejść do modułu Kasa/Bank/ Preliminarz płatności i dokonać zmiany waluty w płatnościach z PLN na inną.

Uwaga
Funkcja przeliczania wypłaty na inną walutę dostępna jest tylko dla wypłat o statusie Zamknięta. Płatność (w Preliminarzu Płatności) ma status Do realizacji.

W module Kasa/Bank/ Preliminarz płatności można zmienić walutę na inną niż PLN dla pojedynczej wypłaty lub seryjnie:

  • Zmiana waluty na pojedynczej płatności pracownika – należy edytować płatność poprzez użycie ikony lupy lub dwukrotnie klikając, przejść na zakładkę [Rozliczenia]. W polu Waluta rozl. wybrać z rozwijanej listy walutę.
  • Seryjna zmiana waluty rozliczenia – funkcja działa dla zaznaczonych zdarzeń. Po zaznaczeniu płatności należy nacisnąć prawy klawisz myszy, pojawi się menu kontekstowe i wybieramy opcję Zmień walutę rozliczenia. Pojawi się pytanie, które potwierdzamy TAK, następnie podajemy informacje dotyczące wybranej waluty (innej niż PLN).

Uwaga
W przypadku, gdy na dany dzień nie będzie podanego kursu wybranej waluty, należy kurs wprowadzić „ręcznie”.

W danej płatności, na zakładce [Rozliczenia], pole Waluta rozliczenia aktywne jest tylko wtedy, gdy w polu Waluta dokumentu wybrano walutę PLN. W przeciwnym wypadku będzie nieaktywne (wyszarzone).

Pole Waluta rozliczenia będzie nieaktywne również wtedy, gdy dokument został już rozliczony przynajmniej częściowo.

Po zmianie waluty w płatnościach – wszystkie wydruki płacowe z kwotami płatności: gotówka i ROR drukowane są zawsze w PLN (w walucie systemowej). Dotyczy to wydruków:

  • Kwitek wypłaty (oba wydruki – z formularza listy płac i z listy Wypłaty pracowników),
  • Lista płac skrócona (obydwa – j.w.),
  • Lista płac szczegółowa (z czasem pracy i bez),
  • Lista ROR,
  • Lista wypłat gotówkowych,
  • Zestawienia list płac (z formularza listy płac i z listy list płac).

Współpraca modułów standardowych z modułami w wersji Plus

Moduł Kasa/Bank Plus daje dodatkowo możliwość:

  • prowadzenia wyceny środków pieniężnych w kasie i na rachunku bankowym (więcej w rozdziale Magazyn walut),
  • zakładania zaawansowanych blokad do rejestrów kasowych/bankowych (więcej w rozdziale Zakazy do rejestrów w module Kasa/Bank Plus).
  • rozliczania delegacji pracowników (więcej w rozdziale Delegacje).

Magazyn walut może być prowadzony na jednym ze stanowisk przy czym operatorzy logujący się do bazy danych z pobranym modułem Kasa/Bank nie będą mogli korzystać z funkcjonalności Magazynu walut, a w szczególności dodawać/usuwać zapisów w rejestrach, które obsługują Magazyn walut.

W przypadku korzystania z funkcjonalności zaawansowanych blokad do rejestrów kasowych/bankowych zalecane jest posiadanie modułu Kasa/Bank Plus na wszystkich stanowiskach. W przypadku założenia w module Kasa/Bank Plus blokady np. tylko do zmiany zapisów kasowych w danym rejestrze, operator, który pobierze moduł Kasa/Bank będzie miał całkowitą blokadę to takiego rejestru.




Moduł Kasa/Bank w systemie Comarch ERP Optima

Ponieważ zadaniem modułu Kasa/Bank jest ujęcie wszelkich zagadnień związanych z przepływem środków pieniężnych w firmie – oznacza to, że musi on gromadzić również informacje pochodzące z innych modułów systemu Comarch ERP Optima. Innymi słowy moduł Kasa/Bank musi „wiedzieć” o każdym zdarzeniu finansowym, które ma miejsce w przedsiębiorstwie. Tylko wtedy jest w stanie zarządzać finansami i generować kompletny obraz finansowy firmy (stan przeszły, bieżący i prognozy).

Informacje gromadzone w module Kasa/Bank mogą pochodzić z:

  • modułu fakturującego. Wystawienie każdej transakcji z kontrahentem jest związane z płatnością. Może to być natychmiast realizowana płatność gotówką, czekiem czy kartą kredytową – wtedy odpowiedni zapis pojawi się w rejestrze kasowym, lub płatność odroczona – wtedy informacja o planowanej zapłacie (np. przelewem) trafi do Preliminarza planowanych płatności.
  • Modułów naliczających podatki. Zatwierdzone do realizacji deklaracje podatkowe (np. VAT, PIT-36 czy CIT-8…) również zapisane zostaną w pierwszej kolejności do Preliminarza płatności, a w chwili ich realizacji przeniesione do zapisów w odpowiednich rejestrach kasowych.
  • Modułu płacowego. Zatwierdzone do wypłaty listy płac, najpierw trafią do Preliminarza planowanych płatności, a w chwili ich realizacji zostaną zapisane w odpowiednich rejestrach kasowych/ To samo dotyczy zaliczek na poczet pensji czy wypłat wszelkich dodatkowych świadczeń dla pracowników.

Oczywiście w samym module Kasa/Bank można bezpośrednio wprowadzać zapisy i mogą to być między innymi:

  • wszelkie operacje finansowe, które nie są związane z transakcjami wykonywanymi w innych modułach. Np. bezpośrednie wypłaty/wpłaty gotówki do kasy, spłaty rat kredytów czy naliczone odsetki od lokat bankowych, zasilanie rachunków bankowych, przelewy między własnymi rachunkami bankowymi itd.
  • Rozliczenia niezapłaconych transakcji, dokumentów.
  • Planowane wydatki i wpływy zapisywane bezpośrednio do Preliminarza planowanych płatności

Jeszcze jednym sposobem wprowadzania danych do tego modułu jest import danych z aplikacji/plików zewnętrznych:

  • HOME BANKING, czyli możliwość eksportu przygotowanych przelewów do aplikacji komunikujących się z bankiem i importu wyciągów bankowych.
  • Import i aktualizacja listy banków z plików udostępnianych przez Krajową Izbę Rozliczeniową (KIR).

Na podstawie danych zgromadzonych w module Kasa/Bank można wykonać szereg zestawień i raportów obrazujących w różnych przekrojach kondycję finansową firmy. Są to między innymi:

  • kalendarz planowanych płatności,
  • zestawienia dłużników i wierzycieli,
  • raport wpływów i wydatków wg kategorii przychodów i kosztów.



Dokumenty w walucie obcej – scenariusze

Rozliczenie Faktury Sprzedaży

  • Wystawiamy Fakturę Sprzedaży na kwotę 100 EURO płatną przelewem. W dniu wystawienia FS obowiązywał kurs 1 EURO = 4 PLN, tak więc wartość faktury w złotówkach to 400 PLN. Powstaje odpowiednie zdarzenie w Preliminarzu.
  • Po pewnym czasie otrzymaliśmy zapłatę za fakturę 100 EURO. W tym dniu jednak obowiązywał kurs 4.05 PLN i taki zapis został wprowadzony do raportu bankowego. Wartość zapisu w złotówkach to 405 PLN.
  • Rozliczamy ze sobą zapis i zdarzenie w Preliminarzu. Rozliczana kwota w EURO jest taka sama, jednak wartość w PLN dla obu dokumentów jest różna. Program automatycznie wyliczy różnicę kursową na kwotę 5 PLN.

Rozliczenie Faktury Zakupu

  • Otrzymaliśmy Fakturę Zakupu na kwotę 400 EURO płatną przelewem. W dniu wpływu FZ obowiązywał kurs 1 EURO = 4 PLN, tak więc wartość faktury w złotówkach to 1600 PLN. Powstaje odpowiednie zdarzenie planujące rozchód w Preliminarzu.
  • Płacimy część kwoty 100 EURO. Wprowadzamy zapis KW na kwotę 100 EURO, ale w dniu zapłaty obowiązywał już kurs 1 EURO = 4.05 PLN. Rozliczamy zapis (całkowicie) i zdarzenie (częściowo).
  • Program wyliczy różnicę kursową na kwotę -5 PLN (100 x 4 – 100 x 4.05 = – 5).

Księgowanie różnic kursowych do modułu Księga Podatkowa

W przypadku współpracy z modułem Księga Podatkowa istnieje możliwość zaksięgowania różnic kursowych do różnych kolumn księgi. Na formularzu różnicy kursowej widoczne jest pole, służące do określenia kolumny KP. Pole to, do chwili zaksięgowania, jest edytowalne i może podlegać modyfikacji.

  • Na dodatnich różnicach kursowych automatycznie podstawiana jest kolumna 8.Pozostałe, natomiast na ujemnych różnicach kursowych kolumna 13.Inne.
  • Program rozpoznaje, czy dana różnica ma zwiększać przychód. Jeśli użytkownik zmieni na Formularzu różnicy uzupełnioną przez program kolumnę księgi z przychodowej na kosztową, to różnica zostanie zaksięgowana w kwocie ujemnej, która pomniejszy koszty i odwrotnie w przypadku różnicy, która ma pomniejszać przychód.
  • Program rozpoznaje, czy dana różnica ma zwiększać rozchód, jeśli użytkownik zmieni na Formularzu różnicy uzupełnioną przez program kolumnę księgi z kosztowej na przychodową, to różnica zostanie zaksięgowana w kwocie ujemnej, która pomniejszy odpowiednio przychody i odwrotnie w przypadku różnicy, która ma pomniejszać rozchód.