Wszystkie deklaracje zgłoszeniowe dostępne są w programie z poziomu Listy pracowników (Kadry). Dla każdego pracownika powstanie odrębna lista utworzonych i zapisanych deklaracji.

Deklaracja ZUA

W celu wygenerowania deklaracji zgłoszeniowej należy:

1. wyświetlić listę pracowników w Kadrach (np. wszyscy),
2. kursorem ustawić się na nazwisku pracownika, dla którego zostanie przygotowane zgłoszenie i wybrać z poziomu ikony  Deklaracje zgłoszeniowe ZUS,
3. domyślnie wyświetla się lista deklaracji zgłoszeniowych ZUS. Klawiszem <INSERT> lub przyciskiem dodajemy nową deklarację, podajemy plik KEDU, do którego będzie ona zapisana. Możemy po edycji listy dostępnych KEDU utworzyć nowy plik i następnie wybrać go z listy,
4. podajemy, czego dotyczy zgłoszenie wszystkich ubezpieczeń, czy tylko społecznych/ zdrowotnych, datę wypełnienia,
5. po uzupełnieniu tych danych możemy przystąpić do naliczenia deklaracji. Możemy to zrobić za pomocą klawisza F8 lub przycisku . Po skończonym procesie naliczania deklaracji możemy ZUA: 
   • wyeksportować do Programu Płatnik. Jeśli wycofamy się bez zapisu z formularza ZUA, deklaracja nie zostanie zapisana,
   • zapisać ZUA za pomocą przycisku dyskietki i nie wysyłać jej od razu do Płatnika. Wysłanie nastąpi później z poziomu zapisanej ZUA albo z poziomu Kadry – Pliki KEDU. Wysłana zostanie cała zawartość wybranego KEDU.
   • Zapisać ZUA i od razu przesłać do Programu Płatnik.
6. Przesłanie deklaracji do Programu Płatnik następuje po wciśnięciu przycisku . Warunkiem automatycznego uruchomienia Płatnika wpisanie/wybranie poprawnej ścieżki dostępu do Płatnika w Konfiguracji/ Program/ Płace/ Parametry oraz zaznaczenia parametru Otwórz program Płatnik po wyeksportowaniu na oknie Parametry eksportu deklaracji do Programu Płatnik .

Deklaracja ZCNA

Obecnie ZUS wymaga składania zgłoszenia członków rodzin wyłącznie na deklaracji ZUS ZCNA. ZUS wycofał obowiązek składania deklaracji zgłoszeniowej ZUS ZCZA. Opcja pozostała w programie z uwagi na zapisy historyczne.

1. Wyświetlamy Listę pracowników (Płace i Kadry /Kadry) i kursorem podświetlamy właściwą osobę.
2. Z menu dostępnych opcji przy ikonie  wybieramy Deklaracje zgłoszeniowe ZUS. Domyślnie wyświetli się Lista deklaracji ZUA. Na dole okna w polu Lista wybieramy ZCNA.
3. Klawiszem <INSERT> lub przyciskiem  wywołujemy formularz deklaracji ZCNA. Podajemy nazwę pliku KEDU, w którym ma być zapisana deklaracja, datę aktualności danych oraz datę wypełnienia deklaracji.
4. Przyciskiem wywołujemy  Listę członków rodziny pracownika.
5. Na liście tej kolumna Deklaracja jest pusta. Wybierając polecenie Zmień (pod prawym klawiszem myszy) lub klikając 2-krotnie myszką w tym polu uaktywniamy zawartość kolumny. Mamy do wyboru zgłoszenie/wyrejestrowanie członka rodziny z ubezpieczenia zdrowotnego. Po wybraniu opcji naciskamy <ENTER>.
6. Następnie .
7. Tak przygotowany plik *.xml można zapisać na dysku po naciśnięciu ikony , a następnie zaimportować do Programu Płatnik.
8. Tak przygotowaną deklarację należy ostatecznie zapisać . Po zapisaniu pojawi się ona na Liście deklaracji ZCNA.

Aby wpisać do bazy osobę współpracującą należy: 

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 są 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.

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: 

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: 

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: 

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.

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.

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ć: 

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.

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.

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.

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.

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: 

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.

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: 

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:

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

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:

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: 

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

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:

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.

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:

Rodzaj karty	Prefiks	Długość
MasterCard	51-55	16
VISA	4	13.16
American Express	34.37	15
Dinners Club / Carte Blanche	300-305, 36, 38	14
EnRoute	2014, 2149	15
Discover	6011	16
JCB	3	16
JCB	2131, 1800	15

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.

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 w Konfiguracji Firmy/ Kasa/Bank/ Parametry.

Split payment – metoda podzielonej płatności

1 lipca 2018 roku weszła 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.

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.

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.

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:

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

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

Wydruki przelewów

Z poziomu zdarzenia w Preliminarzu istnieje możliwość wydrukowania przelewu wg zapisanych na formularzu informacji (bank, nr rachunku, kwota). Informacje o naszym rachunku bankowym pobierane są z rejestru, w którym zapisane jest zdarzenie.

Generując wydruk przelewu dla pracowników można w parametrach przed wydrukiem wskazać adres zamieszkania pracownika. Gdy na przelewie ma być drukowany adres zameldowania wówczas parametr nie powinien być zaznaczany.

Po wciśnięciu bezpośrednio przycisku , na drukarkę kierowany jest Pełny X 2.

Z poziomu menu dostępnego po wciśnięciu widocznej obok strzałki możliwe są wydruki:

W chwili wydruku można podać datę przelewu (podczas wpisywania daty można skorzystać z kalendarza wyświetlanego po wciśnięciu prawego przycisku myszy w polu). Aby data nie pojawiła się na przelewie należy odznaczyć parametr Drukuj datę na formularzu.

Istnieje również możliwość wydruku drugiej linii nazwy beneficjenta: 

Podział zdarzenia – funkcja Podziel

Jeśli okaże się, że wprowadzone zdarzenie nie jest zgodne z rzeczywistymi wpłatami (np. za fakturę wprowadzoną, jako jedno planowane zdarzenie klient płaci w dwóch ratach) istnieje możliwość podziału na dwa niezależne zdarzenia.

Funkcja podziału dostępna jest z poziomu menu kontekstowego (pod prawym klawiszem myszy) wyświetlanego na liście zdarzeń.

Aby dokonać podziału zdarzenia należy:

Wyświetlone zostanie okno, w którym podać należy informacje nt. zdarzenia oryginalnego oraz nowego (wprowadzanego).

W części dotyczącej zdarzenia oryginalnego należy podać kwotę, która powinna pozostać na już istniejącym formularzu. Proponowana jest kwota nierozliczona ze zdarzenia. Informacje o terminie i formie płatności nie podlegają edycji.

W części dotyczącej nowego zdarzenia program automatycznie proponuje wartość dopełniającą kwotę do zapłaty (suma wartości z oryginalnego i nowego zdarzenia musi być równa pierwotnej wartości pozostającej do zapłaty). Można również zmienić termin i formę płatności.

Podczas podziału zdarzenia istnieje możliwość zadeklarowania czy nowe zdarzenie ma mieć określony termin płatności czy nie. Obok pola Termin znajduje się parametr, którego wyłączenie powoduje, że dla zdarzenia nie określa się terminu płatności.

Na nowe zdarzenie przepisywane są ze zdarzenia oryginalnego wszystkie pozostałe informacje: priorytet, dopuszczalna zwłoka, kategoria, opis, stan

Jeśli zdarzenie pierwotne związane jest z dokumentem (np. fakturą zakupu) wystawionym w innym module:

Realizacja zdarzenia – funkcja Realizuj

W systemie Comarch ERP Optima w module Kasa/Bank istnieje możliwość wpisania płatności za planowane zdarzenia (np. planowany zakup komputera, planowany wpływ z tytułu realizacji kontraktu itp.). Takie zdarzenia mogą (choć nie muszą) mieć określony podmiot czy szacunkowy termin realizacji.

W momencie, gdy zdarzenie jest realizowane otrzymujemy odpowiedni potwierdzający to dokument. Wraz z jego rejestracją w systemie zdarzenie w Preliminarzu powinno zostać zastąpione nowym – związanym z wprowadzonym dokumentem.

Aby rozwiązać tego typu sytuacje w module wprowadzono nową funkcję Realizuj zdarzenie. Funkcja wywoływana jest z poziomu menu kontekstowego dostępnego pod prawym klawiszem myszy na liście zdarzeń w Preliminarzu.

Wybór opcji powoduje wyświetlenie listy zdefiniowanych typów dokumentów klasy:

Wybór odpowiedniej pozycji z menu spowoduje otworzenie nowego formularza określonego dokumentu. Podmiot wpisany na zdarzenie jest automatycznie przepisany na otwarty dokument. Dodatkowo użytkownik ma możliwość wyboru rejestru kasowego/ bankowego, do którego ma być dodane zdarzenie (np. planujemy zdarzenie płatne gotówką, ale w momencie realizacji okazuje się, że jednak płacimy z naszego konta bankowego).

Po zapisaniu dokumentu realizowane zdarzenie zostaje zastąpione przez nowe – powiązane z nowo wprowadzonym dokumentem.

Rozliczanie zdarzeń – Rozlicz pojedynczo

Istnieje możliwość rozliczenia zdarzenia w Preliminarzu tak, aby tworzony zapis KP/KW automatycznie pobierał informacje z formularza zdarzenia, które będzie rozliczał.

W Preliminarzu płatności w menu kontekstowym (pod prawym klawiszem myszy) dostępna jest opcja Rozlicz pojedynczo. Funkcja służy do rozliczenia jednej podświetlonej pozycji. Po wyborze Rozlicz pojedynczo z menu kontekstowego, z kolejnego podmenu należy wybrać typ tworzonego zapisu (schemat numeracji zapisu – np. DEK/RVZ/KW), a następnie wybrać rejestr, do którego ma trafić powstający zapis kasowy/bankowy.

Wyświetlony zostanie formularz zapisu kasowego/bankowego, na którym przepisane będą informacje ze zdarzenia:

Podczas generowania zapisu kasowego/bankowego automatycznie rozliczane są zarówno zdarzenie jak i zapis (powiązanie dokumentów widoczne jest z poziomu zakładki [Rozliczenia] zarówno na zdarzeniu jak i zapisie).

Seryjne rozliczanie zdarzeń – funkcja Rozlicz

Funkcja Rozlicz dostępna w Preliminarzu płatności z poziomu menu kontekstowego (pod prawym klawiszem myszy) i pod ikoną operacji seryjnych  daje możliwość seryjnego rozliczania zdarzeń. Po zaznaczeniu kilku dokumentów i użyciu funkcji Rozlicz generowane są zapisy kasowe/bankowe rozliczające wybrane płatności. Podczas generowania zapisu kasowego/bankowego automatycznie rozliczane jest zarówno zdarzenie jak i zapis (powiązanie dokumentów widoczne jest z poziomu zakładki [Rozliczenia] zarówno na zdarzeniu, jak i zapisie).

Funkcja Rozlicz działa również dla jednego podświetlonego zdarzenia.

Zasady rozliczania zdarzeń przez funkcję Rozlicz: 

W polu Dokument należy wybrać odpowiedni schemat numeracji zapisów kasowych/bankowych.

W polu Rejestr należy wskazać rejestr, do którego mają być generowane zapisy KP/KW.

Na oknie dostępny jest również parametr Zapisy zbiorczo dla poszczególnych podmiotów. Po jego zaznaczeniu dla zdarzeń na ten sam podmiot i w tej samej walucie utworzony zostanie jeden zbiorczy zapis KP/KW na łączną kwotę pozostającą do rozliczenia. Jeżeli jako data zapisów KP/KW wybrana zostanie data dokumentu, termin płatności lub data realizacji to utworzonych zostanie tyle zbiorczych zapisów KP/KW ile unikalnych dat jest na zaznaczonych zdarzeniach.

Przy zbiorczym rozliczaniu zdarzeń walutowych program sprawdza, czy wszystkie zaznaczone zdarzenia mają ten sam typ kursu, jeżeli tak to jest on przenoszony na powstały zbiorczy zapis KP/KW (wyjątkiem są zapisy o kursie ręcznym i nieokreślonym, dla których na zapis KP/KW podstawiany jest typ kursu ustawiony na formularzu rejestru K/B). Jeżeli na zdarzeniach są różne typy kursów, wówczas na rozliczającym je zbiorczym zapisie KP/KW ustawiany jest typ kursu z formularza rejestru K/B.

Do pola Opis na zbiorczym zapisie KP/KW przenoszone są numery wszystkich dokumentów biorących udział w rozliczeniu.

Na oknie z parametrami seryjnego rozliczania dostępny jest również parametr Inny podmiot – po jego zaznaczeniu pojawi się opcja wskazania podmiotu, który będzie wybrany na utworzonych zapisach KP/KW.

Jest również możliwość wskazania daty z jaką mają zostać utworzone zapisy KP/KW. Do wyboru jest data dokumentu, termin płatności, data realizacji (pobierane z formularza zdarzenia w preliminarzu płatności) oraz inna – z możliwością wskazania dowolnej daty (domyślnie podpowiadana jest zawsze data bieżąca). Przy wybranej dacie inna rozliczanie odbywa się wg kolejności zaznaczania.

Ustawienia na oknie Parametry seryjnego rozliczania są zapamiętywane i podpowiadane przy rozliczaniu kolejnych zdarzeń.

Wykorzystując funkcję Rozlicz nie dla kilku zaznaczonych, a dla jednej podświetlonej/zaznaczonej pozycji również pojawi się okno Parametry seryjnego rozliczania jednak bez widocznej opcji Zapisy zbiorczo dla poszczególnych podmiotów. W polu Dokument będzie można wybrać tylko taki typ dokumentu, jaki wynika ze zdarzenia (kierunek Wpłata lub Wypłata).

Seryjna zmiana waluty rozliczenia

Seryjna zmiana waluty rozliczenia w Preliminarzu płatności jest to dodatkowa możliwość, która jest dostępna poprzez użycie funkcji Zmień walutę rozliczenia z menu kontekstowego (pod prawym klawiszem myszy) na liście zdarzeń. Seryjna zmiana waluty rozliczenia może być wykorzystana np. do zmiany waluty rozliczenia dla wypłat pracowników (patrz poniżej).

Będąc na liście zaznaczonych dokumentów w Preliminarzu płatności użycie funkcji Zmień walutę rozliczenia powoduje wyświetlenie komunikatu Czy na pewno chcesz dokonać seryjnej zmiany waluty rozliczenia na zaznaczonych płatnościach? po zatwierdzeniu pojawi się poniższe okno Parametry seryjnej zmiany waluty na płatnościach.

Aby dokonać seryjnej zmiany waluty należy wybrać:

Rozliczanie dokumentów w różnych walutach

W programie Comarch ERP Optima można rozliczyć ze sobą dokumenty wystawione w różnych walutach – przy czym jeden z tych dokumentów musi być wystawiony w PLN (pole Waluta dok.), a drugi w walucie obcej. Dodatkowym wymogiem jest, aby obydwa dokumenty posiadały tą samą walutę rozliczenia (pole Waluta rozl.). Walutę rozliczenia można zmieniać tylko wtedy, gdy waluta dokumentu to PLN. Ponadto warto wspomnieć, iż walutę rozliczenia można zmieniać na zapisach kasowych/bankowych oraz na zdarzeniach kasowych/bankowych.

Przenoszenie zdarzeń między rejestrami

W przypadku, gdy zdarzenie zostało wprowadzone do jednego rejestru kasowego/bankowego, ale okazało się, że jednak będzie płatne z innego rejestru (np. innego konta bankowego), program posiada funkcjonalność pozwalającą na przenoszenie między rejestrami.

Funkcja Zmień rejestr jest dostępna z poziomu menu kontekstowego (pod prawym klawiszem myszy) wyświetlanego na liście zdarzeń.

Aby przenieść zdarzenie należy:

Seryjne dodawanie/zmiana kategorii

Funkcja jest dostępna w menu kontekstowym pod prawym klawiszem myszy na liście zdarzeń w Preliminarzu płatności. Działa na wszystkie zaznaczone zdarzenia inne niż o statusie Zrealizowane oraz Całkowicie rozliczone.

Seryjna zmiana statusu

Seryjna zmiana statusu zdarzenia z Nie podlega na Do rozliczenia oraz odwrotnie jest dostępna z menu kontekstowego (prawy przycisk myszy) na liście zdarzeń w preliminarzu. Funkcję seryjnej zmiany statusu można również wybrać z listy operacji seryjnych .

Seryjna zmiana stanu

W menu kontekstowym (prawy przycisk myszy) dostępna jest seryjna zmiana stanu na do realizacji (ze stanu wysłane/ zrealizowane), na wysłane (ze stanu do realizacji) oraz na zrealizowane (ze stanu do realizacji). Funkcję seryjnej zmiany statusu można również wybrać z listy operacji seryjnych.

Seryjna zmiana formy płatności

W menu kontekstowym (prawy przycisk myszy) dostępna jest seryjna zmiany formy płatności (wraz z terminem płatności i datą realizacji) na zdarzeniach niezrealizowanych i nierozliczonych całkowicie. Funkcje dostępne są również z poziomu operacji seryjnych.

Seryjna zmiana podmiotu – aktualizacja rachunku /parametru split payment

W menu kontekstowym pod prawym przyciskiem myszy dostępna jest funkcja Zmień podmiot. Wraz z podmiotem możemy zaktualizować numer rachunku bankowego oraz informację o split payment. Zmiana podmiotu możliwa jest na zdarzeniach nierozliczonych o stanie Bufor lub Do realizacji.

Aktualizacja informacji o split payment dotyczy zdarzeń znajdujących się w rejestrze bankowy, wystawionych w walucie systemowej (PLN). W przypadku zdarzeń znajdujących się w innych rejestrach, np. kasowym w logu z przebiegu operacji pojawi się komunikat: Nie ma możliwości oznaczenia przelewu jako split payment. Przelew znajduje się w rejestrze innym niż bankowy

W sytuacji, gdy operacja zmiany podmiotu z aktualizacją split payment wykonywana jest dla zdarzeń niemających powiązania z dokumentem źródłowym w sekcji Split payment należy uzupełnić kwotę VAT. Numer NIP pobierany jest z karty kontrahenta, jako numer dokumentu wstawiany jest numer obcy ze zdarzenia.

Zmiana podmiotu na zdarzeniu, które związane jest z dokumentem handlowym (faktura zakupu, sprzedaży, zaliczkowa, finalna lub ich korekta) lub z dokumentem wprowadzonym do rejestru VAT powoduje aktualizację podmiotu na płatności, informacja o split payment pobierana jest z kontrahenta głównego wskazanego na dokumencie źródłowym. Numer NIP i kwota VAT zawsze odczytywane są z dokumentu źródłowego. W przypadku zmiany rodzaju podmiotu z kontrahenta na pracownika/ wspólnika/ bank sekcja split payment nie będzie widoczna.

Seryjne ustawianie parametru Split payment

W menu kontekstowym (pod prawym przyciskiem myszy) oraz w Operacjach seryjnych dostępna jest funkcja

Seryjne usuwanie rozliczenia

W menu kontekstowym (pod prawym klawiszem myszy) oraz w Operacjach seryjnych dostępna jest opcja Usuń rozliczenia. Opcja działa zarówno dla podświetlonej, jak i dla zaznaczonych pozycji.

Przy próbie usunięcia rozliczeń opcją Usuń rozliczenia jeżeli przynajmniej jednego z rozliczeń danego dokumentu nie uda się usunąć, pojawia się odpowiedni komunikat np. Operacja nie została pomyślnie wykonana z powodu błędów. FA/10/2017: Nie można usunąć rozliczeń płatności. Co najmniej jedno z nich zostało wybrane na dokumencie kompensaty. i żadne z rozliczeń dokumentu nie jest usuwane.

W przypadku, gdy zdarzenie rozliczane jest z kilkoma zapisami kasowymi/bankowymi, istnieją dwa sposoby wskazania tych zapisów: 

Na zakładce [Rozliczenia] w dolnej części okna widoczny jest parametr Uzgodnij kwotę zapisu z wartością rozliczanych dokumentów. Służy on do synchronizacji kwoty zdarzenia z sumą dokumentów rozliczających to zdarzenie.

Domyślnie parametr jest aktywny na wszystkich nowo otwieranych zdarzeniach (do chwili wpisania kwoty zdarzenia). Po wpisaniu kwoty – parametr jest automatycznie wyłączany. Podobnie parametr nie jest aktywny podczas powtórnej edycji zdarzenia.

Jeśli parametr nie jest aktywny – rozliczanie dokumentu przebiega w ten sposób, że suma rozliczanych dokumentów musi być mniejsza lub równa kwocie do rozliczenia na zdarzeniu, przy czym kwota na zdarzeniu jest nadrzędna.

Jeśli parametr jest aktywny – rozliczanie dokumentu przebiega w ten sposób, że kwota zdarzenia jest przyrównywana do sumy rozliczanych zapisów. Wprowadzenie rozliczenia powoduje zmianę kwoty na zdarzeniu.

Kiedy można wykorzystać funkcję synchronizacji kwot?

Planowaliśmy zakup sprzętu biurowego za kwotę 1500 zł. Zdarzenie zostało wprowadzone w Preliminarzu płatności. Następnie okazało się, że faktura zakupu ma wartość 1550 zł. (mamy na jej podstawie wprowadzony zapis kasowy). W związku z tym podczas rozliczania zdarzenia włączamy synchronizację kwot. Teraz wskazanie odpowiedniego zapisu bankowego do rozliczenia powoduje zmianę kwoty zdarzenia z 1500 zł na 1550 zł.

Może zdarzyć się, że sprzęt został zakupiony na dwie różne faktury 1000 zł i 550 zł. Wtedy dodajemy do rozliczeń pierwszą fakturę – kwota zdarzenia zostaje zmieniona na 1000 zł. Po dodaniu kolejnej faktury na kwotę 550 zł – wartość zdarzenia zostaje zmieniona na 1550 zł.

Edycja danych na zdarzeniu dotycząca podmiotu, kwoty czy terminu płatności nie jest możliwa dla zdarzenia z nadanym stanem zrealizowano (niezależnie od sposobu nadania tego stanu).

Przypomnijmy, że stan zrealizowano można nadać zdarzeniu: