Formularz ponaglenia zapłaty

Na formularzu ponaglenia zapłaty użytkownik wprowadza informacje na temat kontrahenta oraz daty dokumentu. Dodatkowo może zadecydować, czy od kwot, które nie są zapłacone mają być naliczane odsetki ustawowe od zaległości, od zaległości w transakcjach handlowych, podatkowe lub indywidualne.

Przed przystąpieniem do wyliczania pozycji na dokumencie należy określić, jakiej waluty ponaglenie ma dotyczyć. Jeśli ponaglenie ma obejmować dokumenty w walucie obcej, należy określić typ kursu oraz notowanie zgodnie, z którym zostanie wyliczona wartość w PLN (bliżej w rozdziale dotyczącym rejestracji dokumentów w walutach obcych).

Na formularzu działają następujące przyciski:

 – Edytuj  – pozwala na zmianę pozycji,

Formularz ponaglenia zapłaty

 – Usuń lub <DELETE> – usuwa pozycję,

 – Generuj elementy – pozwala na wybór zapisów, które chcemy wydrukować na ponagleniu zapłaty. Po naciśnięciu przycisku pojawiają się w oknie dokumenty, które nie zostały zapłacone. Lista jest zawężona do dokumentów w wybranej walucie. W oknie dokumentów proponowanych przy generowaniu ponaglenia zapłaty do wyboru są dodatkowe kolumny Data dokumentu oraz Po terminie, które domyślnie są ukryte. Istnieje możliwość sortowania dokumentów po wybranej kolumnie. Użytkownik ma także możliwość filtrowanie listy proponowanych do ponaglenia dokumentów po terminie płatności, dacie dokumentu, oraz powyżej wskazanej ilości dni. W przypadku, gdy operator ma założone blokady do rejestrów kasowych/bankowych na liście dokumentów proponowanych do ponaglenia pojawią się wyłącznie dokumenty z rejestrów do których operator nie ma zakazów.  Ponaglenie zapłaty może być drukowane dla wszystkich dokumentów (kombinacja klawiszy <CTRL> + <A>) lub dla zaznaczonych. Akceptacja zapisów następuje po naciśnięciu przycisku .

Istnieje również możliwość wygenerowania ponagleń zapłaty z poziomu Ogólne/Kontrahenci dla zaznaczonych kontrahentów. W tym celu należy wybrać z paska menu dla Listy kontrahentów przycisk:  .




Ponaglenia zapłaty

Funkcja w programie umożliwiająca wydruk ponaglenia zapłaty dla przeterminowanych i nierozliczonych należności. Opcjonalnie na ponagleniu można podać kwotę kosztów dodatkowych i wygenerować płatność w preliminarzu tak dla kosztów jak i dla odsetek.

Podobnie jak w przypadku not odsetkowych można wyłączyć naliczanie odsetek od wybranych płatności na zdarzeniu poprzez zaznaczenie parametru Nie naliczaj odsetek.

Informacje o naliczonych na ponagleniu kosztach dodatkowych i odsetkach są przekazywane do wydruku. W związku z funkcjonalnością generowania płatności dla kosztów i odsetek istnieje możliwość ich zaksięgowania z poziomu listy ponagleń.

Lista ponagleń zapłaty

Opcja jest dostępna z poziomu Kasa/Bank/ Ponaglenia zapłaty. Lista ponagleń zapłaty pozwala na wygenerowanie nowych dokumentów, ich zapamiętanie oraz wydruk.

Listę obsługują standardowe przyciski, opisane szczegółowo w rozdziale Standardy w programie niniejszego podręcznika.

Funkcje Dodaj, Zmień, Usuń są również dostępne w menu kontekstowym (uruchamianym poprzez jednokrotne kliknięcie prawym klawiszem myszy na wybranym zapisie).

 




Formularz noty odsetkowej

Formularz noty odsetkowej składa się z dwóch zakładek: [Ogólne] i [Płatności].

Na zakładce [Ogólne] wybieramy rodzaj dokumentu, kontrahenta, rodzaj odsetek (ustawowe od zaległości, od zaległości w transakcjach handlowych, podatkowe oraz indywidualne), datę dokumentu, formę płatności, termin płatności.

Rodzaj odsetek ustawia się domyślnie w zależności od rodzaju i statusu podmiotu wybranego na formularzu:

  • Ustawowe od zaległości dla: kontrahentów, którzy na karcie, na zakładce [Handlowe], mają zaznaczony status Osoba fizyczna oraz pracowników, wspólników oraz urzędów.
  • Od zaległości w transakcjach handlowych dla: kontrahentów, którzy na karcie, na zakładce [Handlowe], mają zaznaczony status Podmiot gospodarczy oraz banków.

Przy wyliczaniu odsetek bierzemy pod uwagę dni zwłoki. W sytuacji, gdy termin płatności przypadał w sobotę lub w dniu ustawowo wolnym od pracy do wyliczenia ilości dni zwłoki przyjmujemy dzień roboczy przypadający bezpośrednio po sobocie lub dniu wolnym.

Nota może być wyliczona tylko dla dokumentów w takiej samej walucie. Przed przystąpieniem do wyliczania dokumentu należy określić walutę, której będzie dotyczyć.

Jeśli ustalona jest inna waluta niż systemowa – należy określić typ kursu oraz notowanie.

Na formularzu działają następujące przyciski:

 – Edytuj – pozwala na zmianę pozycji,

 – Usuń lub <DELETE> – usuwa pozycję,

 – Generuj elementy – pozwala na wybór zapisów, dla których chcemy naliczyć odsetki. Po naciśnięciu przycisku pojawiają się w oknie dokumenty, które zostały rozliczone po terminie. W oknie dokumentów proponowanych przy generowaniu noty odsetkowej jest możliwość sortowania po kolumnach. Wśród kolumn dostępna jest dodatkowa kolumna Data dokumentu, która domyślnie jest ukryta. Okno z dokumentami proponowanymi do noty w panelu filtra umożliwia dodatkowo zawężenie listy po terminie płatności, dacie dokumentu czy dacie rozliczenia. W sytuacji, gdy operator posiada zakazy do rejestrów kasowych/bankowych to na liście dokumentów proponowanych do noty odsetkowej pojawią się wyłącznie dokumenty z rejestrów do których operator nie ma blokad. Nota odsetkowa może być drukowana dla wszystkich dokumentów (kombinacja klawiszy <CTRL> + <A>) lub dla zaznaczonych. Akceptacja zapisów następuje po naciśnięciu przycisku .

Formularz noty odsetkowej

Na zakładce [Płatności] znajdują się informacje związane z generowaniem płatności w module kasowo/bankowym: termin płatności, forma płatności, kwota płatności oraz ewentualna kwota rozliczona. Jeżeli dany kontrahent wpłaca kwoty zaliczki, to są one również widoczne na tej zakładce. Pole Opis stanowi miejsce na ewentualne uwagi dodatkowe, które są później drukowane na notach odsetkowych.

Na karcie kontrahenta na zakładce [Płatności] dostępny jest parametr Nie naliczaj odsetek dla płatności. Po zaznaczeniu tego parametru, dla danego kontrahenta na zdarzeniu w preliminarzu zostanie zaznaczony parametr Nie naliczaj odsetek z możliwością odznaczenia. Zaznaczony parametr na zdarzeniu daje możliwość wyłączenia naliczania odsetek od wybranych płatności na notach odsetkowych.

Uwaga
 W Konfiguracji firmy /Kasa/Bank /Parametry znajduje się parametr Nie naliczaj odsetek dla płatności do ponagleń zapłaty i not odsetkowych. Po zaznaczeniu tego parametru – generując płatności dla wymienionych w nazwie parametru dokumentów, a związanych z kosztami dodatkowymi oraz odsetkami na ponagleniu zapłaty i odsetkami na nocie odsetkowej automatycznie na zdarzeniu zaznaczy się parametr Nie naliczaj odsetek. Wybierając na kolejnym ponagleniu czy nocie np. tą płatność związaną z kosztami dodatkowymi nie zostaną do niej naliczone odsetki nawet, jeśli na formularzu ponaglenia czy noty będzie zaznaczone naliczanie odsetek.

(Płatności powstałe do not odsetkowych nigdy nie są uwzględniane na kolejnych notach, niezależnie od ustawień parametru.)

Po wybraniu zapisów i wygenerowaniu noty odsetkowej można ją zapisać. Nota może być wprowadzona w pierwszej kolejności do bufora i dopiero potem zatwierdzona po odznaczeniu parametru w buforze.

Przy zatwierdzaniu noty odsetkowej z formą płatności: gotówka i wpisaniu kwoty zapłaty w polu Potwierdzenie wpłaty gotówki, jeżeli nie ma otwartego raportu kasowego, do którego ma zostać dodany rozliczający zapis kasowy pojawia się pytanie: Brak otwartego raportu, do którego można dodać zapis. Czy otworzyć nowy raport?. Po jego akceptacji program automatycznie zakłada odpowiedni raport kasowy.

Nie jest możliwe całkowite usunięcie noty odsetkowej, która została zatwierdzona. Istnieje jednak możliwość anulowania noty odsetkowej (anulowana nota jest wyświetlana na liście w kolorze szarym) po wybraniu opcji Anuluj w menu kontekstowym. Wszystkie dokumenty uwzględnione na anulowanej nocie odsetkowej mogą zostać uwzględnione na nowym zapisie.

Istnieje również możliwość wygenerowania noty odsetkowej z poziomu Ogólne/Kontrahenci dla zaznaczonych kontrahentów.  W tym celu należy wybrać z paska menu dla Listy kontrahentów przycisk:  .




Noty odsetkowe

Kryterium wystawienia noty jest zapłata dokonana po terminie płatności. Noty można wystawiać również dla dokumentów rozliczonych częściowo. Istnieje możliwość naliczenia odsetek ustawowych od zaległości, od zaległości w transakcjach handlowych, podatkowych oraz wg stopy indywidualnej.

W pierwszej kolejności użytkownik powinien uzupełnić aktualnie obowiązujące stopy odsetkowe. Wprowadzamy je w Konfiguracji programu/ Kasa/Bank/ Odsetki od zaległości w transakcjach handlowych lub Odsetki podatkowe lub Odsetki ustawowe od zaległości. Dodatkowo w tym samym miejscu ustalamy datę obowiązywania stopy procentowej. W przypadku zmiany stopy procentowej, w danym okresie wartości odsetek wyświetlane są oddzielnie, zgodnie z danymi wprowadzonymi w konfiguracji.

Lista not odsetkowych

Opcja jest dostępna z poziomu Kasa/Bank/ Noty odsetkowe. Lista not odsetkowych pozwala na wygenerowanie nowych not, zapamiętanie oraz wydruk.

Listę obsługują standardowe przyciski, opisane szczegółowo w rozdziale Standardy w programie niniejszego podręcznika.

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

 – Księgowanie – wg wybranego schematu do modułu Księga Handlowa.

Funkcje Dodaj, Zmień, Usuń, Wybierz są również dostępne w menu kontekstowym (uruchamianym poprzez jednokrotne kliknięcie prawym klawiszem myszy na wybranym zapisie).

Zasady dotyczące obsługi list, grupowania, sortowania, wyszukiwania pozycji (filtrowania) i ogólnie przystosowywania wyglądu list do indywidualnych potrzeb użytkownika zostały opisane w rozdziale Standardy w programie.




Jak rozpocząć pracę z modułem Księga Handlowa?

Rozdział ten przedstawia w kolejnych punktach informacje istotne dla użytkownika, który rozpoczyna pracę w programie Comarch ERP Optima.

Przystępując do pracy w module Księga Handlowa należy wykonać następujące czynności:

  • Określić podstawowe parametry związane z prowadzeniem księgowości
  • W przypadku korzystania z Księgi Handlowej Plus należy ustawić dodatkowo parametry związane z obsługą kont walutowych (Start/Konfiguracja firmy/ Księgowość/ Księgowość kontowa)
  • Ustalić nazewnictwo stron kont księgowych: Debet/Credit lub Winien/Ma (Konfiguracja programu/Księgowość/Parametry)
  • Założyć dzienniki księgowe  (Start/Konfiguracja firmy/Księgowość/Dzienniki)
  • Założyć, jeśli jest to konieczne, blokady dostępu odpowiednim Użytkownikom programu (Start/Konfiguracja programu/ Użytkowe/ Operatorzy/ zakładka Blokady dostępu); (Start/Konfiguracja firmy/ Księgowość/ Dziennikizakładka Zakazy)
  • Dokonać ustawień konfiguracyjnych pod kątem obsługi: modułu Kasa/Bank; modułu Środki Trwałe oraz Rejestrów VAT

Uzupełnianie tych list nie jest konieczne od razu w chwili rozpoczęcia pracy z systemem. Wpisywanie koniecznych informacji może być wykonywane na bieżąco podczas pracy programu. 




Księgowanie delegacji

Księgowanie do KPiR

W przypadku baz z rodzajem księgowości Księga podatkowa na formularzu etapu delegacji dostępna jest ikona  Kwoty dodatkowe, gdzie wykazywane jest jakie kwoty mają być zaksięgowane do poszczególnych kolumn książki przychodów i rozchodów.

Ikona Kwot dodatkowych dostępna jest zarówno na etapach krajowych, jak i zagranicznych.

W przypadku etapów krajowych widoczne są następujące rodzaje wydatków: Diety, Ryczałty za dojazdy, Ryczałty za noclegi i Koszty używania pojazdu.

W przypadku etapów zagranicznych widoczne są następujące rodzaje wydatków: Diety, Ryczałty za dojazdy, Ryczałty za noclegi,  Ryczałty za dojazdy z/do dworca, lotniska i Koszty używania pojazdu.

Dla każdego rodzaju wydatku domyślnie ustawiana jest kolumna 13.Inne, z możliwością zmiany.

Wartości w kolumnie Kwota są uzupełniane automatycznie, z możliwością zmiany. Jeżeli na etapie delegacji nastąpi zmiana wartości, np. kwoty diet, wartości w Kwotach dodatkowych zostaną automatycznie zaktualizowane. W kwocie Diet wykazywana jest suma wartości diet i za pobyt w szpitalu. Na etapach zagranicznych kwoty wykazywane są w PLN, przeliczone po kursie poniesienia kosztu.

W polu Kwota dokumentu (widocznym w prawym górnym rogu) jest widoczna kwota z pola Suma wydatków na zakładce [Podsumowanie rozliczenia] pomniejszona o kwotę wydatków podpiętych na zakładce [Wydatki], przemnożona przez kurs poniesienia kosztu.

W momencie księgowania delegacji ikoną  tworzony jest zapis KPiR z datą księgowania równą dacie rozliczenia delegacji. Powstaje jeden zbiorczy zapis KPiR na łączną kwotę kosztów (sumowane są koszty z wszystkich etapów delegacji, w ramach danej kolumny KPiR).

W numerze dowodu wpisywany jest numer delegacji, a w Opisie Rozliczenie delegacji: [Numer delegacji].

Księgowanie do księgowości kontowej

Na pozycji schematu księgowego do księgowania delegacji, w polu kwota dostępne są m.in. następujące makra:

  • Kwota – w ramach, której dostępne są Kwota diety, Kwota ryczałtu za nocleg, Kwota ryczałtu za dojazdy, Kwota kosztów używania pojazdu, Kwota ryczałtu za dojazdy z/do dworca, lotniska, Kwota razem.

Tymi makrami księgowane są kwoty po kursie do rozliczenia z pracownikiem, z zakładki [Podsumowanie rozliczenia] na elemencie delegacji.

Makro Kwota razem (@Razem) księguje kwotę widoczną w polu Suma wydatków na zakładce [Podsumowanie rozliczenia] pomniejszoną o kwotę wydatków podpiętych na zakładce [Wydatki].

  • Kwota kosztu – w ramach, której dostępne są Kwota diety, Kwota ryczałtu za nocleg, Kwota ryczałtu za dojazdy, Kwota kosztów używania pojazdu, Kwota ryczałtu za dojazdy z/do dworca, lotniska, Kwota razem.

Tymi makrami księgowane są kwoty po kursie poniesienia kosztu, z zakładki [Podsumowanie rozliczenia] na elemencie delegacji.

Makro Kwota razem (@KRazem) księguje kwotę widoczną w polu Suma wydatków na zakładce [Podsumowanie rozliczenia] pomniejszoną o kwotę wydatków podpiętych na zakładce [Wydatki].

  • Różnica kursowa – w ramach, której dostępne są Różnica kursowa dodatnia i Różnica kursowa ujemna.

Tymi makrami księgowana jest różnica kursowa delegacyjna, widoczna na zakładce [Podsumowanie rozliczenia] na elemencie delegacji.

Makr @RoznicaPlus/ @RoznicaMinus dotyczących różnicy kursowej nie należy łączyć z innymi makrami dotyczącymi kwoty. Różnice kursowe powinny być księgowane w osobnej pozycji schematu.




Formularz rejestru kasowego/bankowego: zakładka Ogólne

Nowy rejestr kasowy/bankowy zakładamy z poziomu listy rejestrów przyciskiem  lub z klawiatury klawiszem <INSERT>.

Formularz zawierający szczegółowe dane na temat rejestru składa się z pól:

Akronim – krótkie (do 20 znaków) określenie rejestru.

Rejestr – symbol rejestru, krótki (maksymalnie 5 znaków) symbol rejestru, wykorzystywany w numeracji raportów i zapisów właściwych temu rejestrowi. z tego względu warto symbol rejestru skonstruować tak, aby przeglądając raporty lub zapisy kasowe/bankowe łatwo było zidentyfikować do jakiego rejestru należą.

Nazwa – dłuższa nazwa rejestru (maksymalnie 40 znaków).

Typ rejestru – rozróżniane są trzy typy rejestrów kasowych/bankowych: kasa – odpowiadający kasom gotówkowym, konto bankowe – odpowiadający prowadzonym przez firmę kontom (rachunkom) bankowym oraz karta kredytowa – to typ rejestrów odpowiadających firmowym kartom kredytowym.

Bank – dla rejestrów typu kasa pole nie jest aktywne. Dla rejestrów typu konto bankowe lub karta kredytowa oznacza bank, w którym otwarty jest rachunek lub który wystawił kartę. Akronim banku lub jego numer rozliczeniowy można wpisać z klawiatury lub wspomóc się listą banków dostępną po uruchomieniu przycisku Bank. Jeśli potrzebnego banku nie ma na liście banków, można go z tego poziomu dopisać.

Numer rachunku – dla rejestrów typu konto bankowe i karta kredytowa jest to numer rachunku lub numer karty kredytowej. Obydwa numery podlegają walidacji wg algorytmów stosowanych przez instytucje bankowe. Oznacza to, że program nie pozwoli na wpisanie błędnych numerów.

W przypadku kont bankowych obok numeru rachunku pojawia się parametr IBAN. Jego wartość jest dziedziczona z formularza wpisanego wcześniej banku (można ją oczywiście zmienić).

Rachunek VAT dla MPP – parametr ten pojawia się tylko dla raportów bankowych, prowadzonych w walucie systemowej (PLN). Przeznaczony jest do obsługi podatku VAT.

Dokładnie zasady obsługi pól związanych z bankiem zostały opisane w artykule Banki.

W przypadku kart kredytowych – oprócz banku i numeru karty kredytowej należy wprowadzić jeszcze typ karty (możliwość wyboru z listy kart zdefiniowanych w Konfiguracji firmy/Kasa i Bank/Karty płatnicze) oraz określić jej datę ważności. Poprawność numeru karty kredytowej jest sprawdzana w oparciu o algorytm Luhna i nie zależy od wybranego typu karty (jak np. na zapisie kasowym/bankowym).

Numeracja raportów – wybór schematu numeracji, który będzie wykorzystywany do numeracji raportów kasowych/bankowych w obrębie tego rejestru. Schematy numeracji można definiować posługując się funkcją Lista definicji dokumentów.

Okres raportów – domyślna długość raportu w danym rejestrze, na podstawie której proponowana jest data zamknięcia dodawanego, nowego raportu. Do wyboru mamy okres niestandardowy, dzienny, tygodniowy, dekadowy i miesięczny.

Numery obce – parametr odpowiada za możliwość wpisania dla raportów otwieranych w ramach danego rejestru numerów obcych (czyli np. oryginalnego numeru wyciągu bankowego). Jeśli parametr jest aktywny – podczas zakładania raportu użytkownik ma dostęp do pola Numer obcy.

Poniżej można uzupełnić informacje o walucie, w jakiej prowadzony jest rachunek/ kasa. W przypadku wybrania waluty obcej pojawiają się dodatkowe pola związane z przeliczaniem (na potrzeby księgowości) zapisów w walucie na PLN.

Saldo B.O. – stan początkowy, z którym rozpoczynamy pracę w danym rejestrze: kasie gotówkowej lub rachunku bankowym. Wpisane tutaj saldo B.O. Przeniesione zostanie, jako stan początkowy pierwszego raportu otwartego w tym rejestrze.

Jeśli rejestr jest walutowy obok waluty pojawia się możliwość wybrania typu kursu, według którego powinna być przeliczona kwota w walucie wprowadzona, jako Bilans Otwarcia. Jeśli użytkownik nie jest w stanie wskazać konkretnego kursu – może wybrać opcję kurs Nieokreślony. W takim przypadku podaje bezpośrednio kwotę w walucie i kwotę w PLN, bez przelicznika.

W przypadku rejestrów walutowych dodatkowo na formularzu rejestru należy wskazać typ kursu odpowiedni dla zapisów rozchodowych (Typ kursu zakupu) oraz przychodowych (Typ kursu sprzedaży). Będą one wykorzystywane podczas wprowadzania dokumentów bezpośrednio w module Kasa/Bank (niezwiązane z dokumentami zarejestrowanymi w innych modułach).

Uwaga
Jeśli, rejestr jest prowadzony w PLN – można wprowadzać do niego zapisy w dowolnej walucie. Jeśli rejestr jest prowadzony w walucie obcej to można do niego wprowadzać zapisy/ płatności tylko w takiej samej walucie.

W przypadku rejestrów złotówkowych salda wykazywane są zawsze w PLN, niezależnie od waluty dokumentu. Natomiast w przypadku rejestrów walutowych – salda są wykazywane w walucie, w jakiej prowadzony jest rejestr.

Poniżej znajdują się pola, gdzie można wpisać informacje dodatkowe:

Limit kredytu – limit kredytu związany z rachunkiem bankowym lub firmową kartą kredytową.

Kara za przekroczenie – kara (najczęściej kwota potrącana z rachunku) za przekroczenie limitu kredytu.

Oprocentowanie rachunku – stopa oprocentowania rachunku.

Oprocentowanie kredytu – stopa oprocentowania kredytu.

Oprocentowanie karne – oprocentowanie karne rachunku.

W górnej części okna widoczny jest parametr Nieaktywny. Służy on do zaznaczania rejestrów, które nie są już w firmie wykorzystywane (np. stare konta bankowe). Jego zaznaczenie spowoduje, że:

  • nie będzie on widoczny na listach wyświetlanych z poziomu innych okien (np. podczas zakładania nowej formy płatności, określania rejestru na liście zapisów kasowych/bankowych itp.),
  • nie będzie wyświetlany na liście rejestrów zawężonej tylko do rejestrów aktywnych.

Formularz obsługują standardowe przyciski, opisane szczegółowo w rozdziale Standardy w programie niniejszego podręcznika. Dodatkowo dostępne są m. in. następujące przyciski:

– lista raportów kasowych/ bankowych związanych z danym rejestrem,

– lista zapisów kasowych/ bankowych rejestru,

– lista płatności rejestru w Preliminarzu płatności.




Lista rejestrów kasowych/bankowych

Rejestry kasowe/bankowe w systemie Comarch ERP Optima są odpowiednikiem prowadzonych przez firmę kas gotówkowych, rachunków bankowych lub firmowych kart kredytowych. Każdej kasie, rachunkowi lub karcie kredytowej powinien odpowiadać jeden rejestr. W skład każdego z rejestrów wchodzą raporty kasowe, bankowe lub raporty związane z przychodami i wydatkami dokonywanymi kartą kredytową.

Lista rejestrów kasowych/ bankowych dostępna jest z menu Kasa/Bank/Rejestry kasowe/bankowe.

Dla każdego z rejestrów należy określić między innymi kwotę początkową (Saldo B.O.), z którą rozpoczynamy pracę z programem oraz okres raportów – czyli częstotliwość, z jaką raporty będą zamykane (nieokreślony, dzienny, tygodniowy, dekadowy lub miesięczny). Każdy zamknięty raport wpływa na stan bieżący środków w rejestrze kasowym/bankowym.

Lista rejestrów bankowych

Rejestry walutowe użytkownik powinien otworzyć tylko w przypadku, gdy posiada rachunek w walucie. Na rachunkach walutowych mogą być wprowadzane tylko zapisy w danej walucie. Zarówno bilans otwarcia jak i zamknięcia są zawsze wykazywane w walucie.

Ponadto istnieje możliwość oznaczenia rejestrów nieaktywnych, czyli takich, które nie są już w firmie wykorzystywane (np. stare konto bankowe).

Na liście rejestrów widoczny jest parametr Pokazuj też nieaktywne:

  • jeśli jest zaznaczony – na liście widoczne są wszystkie rejestry (również te nieaktywne),
  • jeśli nie jest zaznaczony – na liście widoczne są tylko rejestry aktywne.

Listę obsługują standardowe przyciski, opisane szczegółowo w rozdziale Standardy w programie niniejszego podręcznika. Dodatkowo dostępne są m. in. następujące przyciski:

lista raportów kasowych/ bankowych związanych z rejestrem.

lista zapisów kasowych/ bankowych rejestru.

– lista płatności rejestru w Preliminarzu płatności.

-funkcja dostępna w module Kasa Bank Plus, została opisane w artykule Magazyn walut.

-funkcja dostępna dla rejestrów bankowych, obsługujących automatyczną wymianę danych z bankiem (webservice). Szczegóły znajdziecie Państwo w artykule Wymiana danych z bankami online

Zasady dotyczące obsługi list, grupowania, sortowania, wyszukiwania pozycji (filtrowania) i ogólnie przystosowywania wyglądu list do indywidualnych potrzeb użytkownika zostały opisane Tutaj.




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 8  podstawowych form płatności: bon, czek, gotówka, inna, karta, kredyt, mobilna, 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,
  • BNP Paribas WebService,
  • BPH BusinessNet (import)/PekaoBIZNES24 (import),
  • Citi Handlowy - API,
  • Citi Handlowy - Przelewy krajowe (CDFF),
  • Citi Handlowy - Przelewy krajowe (Elixir),
  • Citi Handlowy - Przelewy krajowe, w tym MPP (xml),
  • Citi Handlowy - Przelewy międzynarodowe (CDFF),
  • Citi Handlowy - Przelewy międzynarodowe (xml),
  • Citi Handlowy - Przelewy MPP (CDFF),
  • Citi Handlowy - Przelewy MPP (Elixir),
  • Citi Handlowy - Przelewy podatkowe (CDFF),
  • Citi Handlowy - Przelewy podatkowe (Elixir),
  • Citi Handlowy - Przelewy podatkowe (xml),
  • Citi Handlowy - Przelewy SEPA (CDFF),
  • Citi Handlowy - Przelewy SEPA (xml),
  • CitiBank,
  • CitiDirect,
  • Elixir-O BPH,
  • Elixir-O BPH (mechanizm podzielonej płatności),
  • Elixir-O iBRE,
  • ING WebService,
  • KASABUF.TXT i BANKBUF.TXT (import),
  • KASAZKH,
  • KB24 – Kredyt Bank (eksport),
  • mBank WebService,
  • Millennium WebService,
  • Pekao WebService,
  • PKO BP WebService,
  • Przelewy krajowe (xml),
  • Przelewy SEPA (xml),
  • Przelewy SEPA BZWBK (xml),
  • Przelewy walutowe (xml),
  • Santander 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 (w nowych bazach domyślnie niezaznaczony), 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 zapisu na liście 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.

MPP – mechanizm podzielonej płatności

W Polsce mechanizm podzielonej płatności był wprowadzony w dwóch terminach:

  • Pierwszy termin to 1 lipca 2018 roku, gdy 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. MPP).
  • Drugi termin to 1 listopada 2019 roku, gdy zaczęła obowiązywać Ustawa z dnia 9 sierpnia 2019 roku o zmianie ustawy o VAT oraz niektórych innych ustaw (Dz.U. poz.2751).

W obu przypadkach 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.

O ile pierwotnie stosowanie metody podzielonej płatności było dobrowolne i mogło dotyczyć wybranych kontrahentów lub wskazanych dokumentów, o tyle od 1 listopada 2019 roku mechanizm podzielonej płatności w niektórych przypadkach jest obowiązkowy.

Obowiązkowy mechanizm podzielonej płatności  stosujemy, gdy:

  • sprzedaż dotyczy towarów i usług wymienionych w załączniku nr 15 do ustawy o VAT,
  • wartość brutto transakcji wynosi ponad 15 000 PLN lub równowartość tej kwoty,
  • sprzedawca i odbiorca są podatnikami VAT.

W sytuacji, gdy wszystkie transakcje z danym kontrahentem będą realizowane z zastosowaniem metody podzielonej płatności 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 ustawiony mechanizm 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 (MPP – podzielona płatność) 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 podzielonej płatności (parametr MPP podzielona płatność jest zaznaczony) to na zdarzeniu pojawiają się dodatkowe pola: Kwota VAT, NIP i Numer dokumentu. Na zdarzeniach, które nie mają zaznaczonego parametru MPP – podzielona płatność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 dokumentu źródłowego. 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 MPP podzielona płatność 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 MPP 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 MPP program automatycznie:

  • zaznacza MPP – podzielona płatność – parametr odczytany jest z dokumentu źródłowego
  • 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 (MPP)?

  • Założyć rejestr bankowy w PLN i zaznaczyć na nim parametr Rachunek VAT dla MPP. Otworzyć raporty bankowe.
  • Na formularzu kontrahenta, z którym rozliczenia będziemy prowadzić z uwzględnieniem metody podzielonej płatnościzaznaczyć parametr MPP – podzielona płatność
  • Jeśli podzielona płatność ma dotyczyć tylko wybranych płatności w Preliminarzu płatności na wybranych zdarzeniach z wykorzystaniem operacji seryjnej zaznaczyć parametr MPP – podzielona płatność 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 MPP.

Więcej informacji na temat metody podzielonej płatności, w tym tworzenia zleceń przelewu do banku znajdziecie Państwo na naszym portalu.

Wykaz podatników VAT – weryfikacja rachunków bankowych

Od września 2019 roku Ministerstwo Finansów udostępniło bezpłatny, jednolity Wykaz podatników VAT. Wykaz ten zawiera podmioty, które zostały zarejestrowane, niezarejestrowane, wykreślone i przywrócone do rejestru VAT. Wykaz zawiera dane pozwalające na weryfikację podatnika, w tym listę zgłoszonych przez niego rachunków bankowych. Rachunki są pobierane z bazy KAS i są to numery rachunków rozliczeniowych lub imiennych rachunków w SKOK otwarte w związku z prowadzeniem działalności gospodarczej i podane przy zakładaniu firmy.  Jeśli Twoje rachunki bankowe są inne niż w momencie zakładania firmy powinieneś je zaktualizować w urzędzie skarbowym (spółki zarejestrowane w KAS) lub CEIDG (jednoosobowa działalność gospodarcza).

Do 31 grudnia 2019 roku korzystanie z tego Wykazu jest dobrowolne.

Od 1 stycznia 2020 roku zapłata za fakturę wystawioną przez podatnika VAT czynnego o wartości przekraczającej 15 000 zł powinna być dokonana na rachunek, który jest zamieszczony w Wykazie podatników VAT.

W programie Comarch ERP Optima mamy możliwość pobrania rachunków bankowych kontrahenta z Wykazu podatników VAT. Rachunki te są automatycznie pobierane przy dodawaniu nowego kontrahenta, można je też zaimportować dla kontrahentów istniejących już w programie. Importowane rachunki są automatycznie weryfikowane.
Weryfikacja rachunków bankowych dostępna jest z poziomu listy kontrahentów, listy dokumentów w rejestrze VAT, listy dokumentów w ewidencji dodatkowej, w preliminarzu płatności oraz na liście zapisów kasowych\bankowych.

W module Kasa/Bank rachunek kontrahenta weryfikujemy automatycznie przy eksporcie przelewów. Dodatkowo na liście zdarzeń i liście zapisów kasowych\bankowych mamy możliwość weryfikacji rachunków dla wskazanych przez nas płatności.

Uwaga
Weryfikacja rachunków bankowych z poziomu listy zapisów kasowych/bankowych dostępna jest od wersji 2020.2.1 programu Comarch ERP Optima

Uwaga
Weryfikacja rachunków bankowych jest dostępna wyłącznie dla Klientów z aktualną gwarancją.

W przypadku, kiedy Klient nie posiada aktualnej gwarancji bądź pracuje na wersji Demo w momencie weryfikacji  pojawia się komunikat: Wystąpił błąd: Usługa dostępna tylko dla programów na gwarancji.

Standardowo w Preliminarzu płatności weryfikacji podlegają zdarzenia, które spełniają wszystkie wymienione poniżej warunki:

  • płatność znajduje się w rejestrze bankowym,
  • na płatności podano numer rachunku bankowego,
  • jest to zdarzenie rozchodowe,
  • płatność jest nie rozliczona lub rozliczona częściowo,
  • podmiotem płatności jest kontrahent posiadający polski numer NIP.
  • kwota płatności jest większa niż 15 000 zł. Sprawdzana jest łączna kwota płatności na dokumencie źródłowym, np. na fakturze zakupu.
  • przy seryjnej weryfikacji rachunków bankowych sprawdzany jest status zdarzenia, weryfikujemy płatności o statusie: Bufor lub Do realizacji

W przypadku operacji seryjnej Zweryfikuj rachunek bankowy, która wykonywana jest z poziomu listy zapisów, listy zdarzeń, weryfikowane są wszystkie zaznaczone dokumenty niezależnie od kwoty transakcji. Pozostałe warunki pozostają bez zmian.

Przy eksporcie przelewów oraz weryfikacji wykonywanej za pomocą operacji seryjnej dla zaznaczonych dokumentów na liście w rejestrze VAT i ewidencji dodatkowej oraz na formularzach dokumentów standardowo obowiązuje warunek na kwotę transakcji (15 000 zł). Istnieje możliwość wyłączenia tego warunku, co zostało opisane w dalszej części dokumentu.

Przy eksporcie przelewów do banku weryfikacji nie podlegają przelewy MPP. W przypadku dokonania zapłaty z zastosowaniem mechanizmu podzielonej płatności na rachunek spoza Wykazu podatników VAT nie wystąpią negatywne konsekwencje w zakresie CIT i PIT w kwestii solidarnej odpowiedzialności w VAT.

 

Weryfikacja numerów rachunków bankowych przy eksporcie przelewów

W Preliminarzu płatności weryfikacja odbywa się automatycznie w momencie eksportu przelewów do banku, (przelewów zwykłych, nie objętych procedurą MPP), ponieważ istotne jest aby w momencie zlecania przelewu rachunek kontrahenta znajdował się w Wykazie podatników VAT czynnych. Jeśli w wyniku weryfikacji otrzymamy informację, że zlecenie dotyczy niepoprawnego numeru rachunku pojawi się odpowiedni komunikat  a proces eksportu przelewów zostanie zatrzymany.

Wygląd komunikatu zależy od wybranego formatu eksportu. Poniżej na pierwszym rysunku przedstawiono komunikat jaki może pojawić się przy zastosowaniu formatu eksportu, który zapisuje dane do pliku xml oraz webservice. Drugi prezentuje komunikat jaki może pojawić się przy eksporcie płatności formatem generującym plik ‘płaski’ np. Elixir-0.

Eksport przelewów do pliku xml – walidacja rachunku bankowego

Eksport przelewów – walidacja rachunku bankowego

Dotyczy wersji: 2020.2.1
Przy eksporcie przelewów do banku program sprawdza kwotę transakcji (warunek na 15 000 zł). Użytkownik ma możliwość ustalenia weryfikacji rachunku bankowego bez względu na kwotę transakcji.

W tym celu należy wejść do Konfiguracji firmy/ Ogólne/ Parametry i w sekcji Automatyczna weryfikacja numerów rachunków w Wykazie podatników VAT zaznaczyć parametr Niezależnie od kwoty dokumentu.

Parametr ten ma wpływ na weryfikację jaka ma miejsce przy eksporcie przelewów oraz na weryfikację na formularzu faktury zakupu, korekcie faktury sprzedaży, dokumencie w rejestrze VAT zakupu, dokumencie korekty w rejestrze VAT sprzedaży, dokumencie w ewidencji dodatkowej kosztów, korekcie dokumentu w ewidencji dodatkowej przychodów oraz przy weryfikacji wybranych dokumentów w rejestrze VAT i ewidencji dodatkowej (operacja seryjna Zweryfikuj rachunek bankowy).

Konfiguracja firmy /Ogólne/ Parametry – weryfikacja rachunku

Uwaga
W przypadku rozpoznania rachunków bankowych, których nie ma w Wykazie podatników VAT to od decyzji Użytkownika zależy czy wszystkie przelewy zostaną wyeksportowane do banku.

Operacje seryjne – Zweryfikuj numer rachunku

Dla zapisów bankowych oraz zdarzeń zapisanych w Preliminarzu płatności wprowadziliśmy możliwość seryjnego sprawdzenia rachunków bankowych. Służy do tego funkcja: Zweryfikuj numer rachunku.Weryfikacja wykonywana jest dla zaznaczonych zapisów (zdarzeń) niezależnie od kwoty transakcji. W logu z przebiegu tej operacji pojawiają się informacje o weryfikacji numerów rachunków bankowych oraz ewentualne komunikaty dotyczące problemów z połączeniem się z serwerem Ministerstwa Finansów czy brakiem połączenia sieciowego.

Preliminarz płatności – operacje seryjne

Dotyczy wersji: 2020.2.1
Uwaga
W Preliminarzu płatności weryfikacja zdarzeń (operacja seryjna, eksport przelewów) wykonywana jest zawsze wg daty bieżącej. Nie mają znaczenia daty dokumentów.Na liście zapisów bankowych weryfikacja wykonywana jest wg daty zapisu

Wynik weryfikacji zapisywany jest na karcie kontrahenta dla każdego rachunku bankowego oddzielnie (data weryfikacji, numer NIP, wynik, Identyfikator wyszukiwania).
Zapis wykonywany jest bez względu na wynik weryfikacji. Zapisujemy zarówno pozytywny jak i negatywny wynik weryfikacji.
W przypadku seryjnej weryfikacji zapisu/zdarzenia na którym wpisano rachunek bankowy, którego nie ma na karcie kontrahenta to rachunek ten zostanie dodany do listy rachunków bankowych tego kontrahenta wraz z informacją o jego weryfikacji.
W momencie weryfikacji w pierwszej kolejności sprawdzamy czy rachunek został już zweryfikowany (istnieje wpis w Comarch ERP Optima na karcie kontrahenta), jeśli nie to uruchamiamy wyszukiwanie w Wykazie podatników VAT i jego wynik zapisujemy na karcie kontrahenta.




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.