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:
- 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).
- W 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.
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.
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ć: Dzięki zdarzeniom zapisanym w Preliminarzu uzyskujemy możliwość: 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. 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. 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. 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). 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ł. Obydwa zapisy kasowe można ze sobą skompensować. Po dokonaniu kompensaty obydwa otrzymają status rozliczonych. 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.
Rozliczenia i kompensaty
Preliminarz płatności – Zapisy kasowe/bankowe
Preliminarz płatności:
Preliminarz płatności:
Zapisy kasowe/bankowe:
Zasady numeracji dokumentów
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:
- 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.
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).
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,
- BNP Paribas WebService,
- BNP Paribas WebService (dawniej Raiffeisen),
- 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),
- mBank WebService,
- Millennium WebService,
- Pekao WebService,
- Przelewy krajowe (xml),
- Przelewy SEPA (xml),
- Przelewy SEPA BZWBK (xml),
- Przelewy walutowe (xml),
- 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.
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.
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 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.
![](https://pomoc.comarch.pl/optima/pl/2019_5/wp-content/uploads/2018/06/form-platn.png)
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
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.
![](https://pomoc.comarch.pl/optima/pl/2019_5/wp-content/uploads/2018/06/lista-kontr.png)
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.