Zestawienie aplikacji, z którymi współpracuje Comarch ERP XL 2026.0

Aplikacja	Wersja	Uwagi
Comarch IBARD	6.19.0
Comarch e-Sklep	2026.5
Comarch B2B	Informacja w dokumentacji nowej wersji
Comarch Mobile (Zarządzanie, Sprzedaż, Monitorowanie, Serwis)	2026.2.0
Comarch WMS (Zarządzanie, Magazynier)	2026.0
Comarch Magazynier
Comarch ERP XL HR	2026.5.1
Comarch HRM	2026.5.1
Comarch BPM (stacjonarny, WWW)	2026.1.1
Comarch ERP XL Business Intelligence (Księga raportów, Panel zarządzania, Konfigurator)	2026.0
Comarch ERP XL Business Intelligence (BI Point)	2026.2
Migracja danych XL2XML	14
Comarch MES	2026.0
Comarch e-Sprawozdania	2026.2
Comarch POS	2026.5
Comarch Shipping	Aktualna wersja shipping.comarch.com
Comarch sPrint	2026.0.0
Comarch APS	2026.2

Logistyka

Zmiany w zakresie wysyłki faktur do KSeF

Poniżej umieszczono podstawowe informacje dotyczące zmian w zakresie wysyłki faktur do KSeF. Więcej informacji na ten temat znajduje się w biuletynie technicznym: Mapowanie danych na strukturę logiczną schematu FA(3) e-faktury KSeF w wersji 2026.0.

Zmiany w zakresie danych identyfikacyjnych Podmiotu2 [Nabywca]

Zmianie uległy zasady przesyłania identyfikatora Nabywcy na wysyłanej do KSeF fakturze. Od wersji 2026.0 dla każdego rodzaju transakcji której dotyczy faktura wysyłane są one zależnie od zawartości kontrolek Prefiks NIP i NIP na karcie kontrahenta, według zasad przedstawionych w poniższej tabeli:

Prefiks NIP	Kraj w adresie	Rodzaj wysyłanego do KSeF identyfikatora
Pusty	PL	NIP
	Inny niż PL	NrID
PL	PL	NIP
	Inny niż PL
Inny niż PL (kraj UE)	PL	KodUE NrVatUE
	Inny niż PL

Dotychczasowy atrybut KSEF_Nabywca_NrID nie jest już obsługiwany.

Identyczne zmiany dotyczą zasad wysyłania danych identyfikacyjnych Podmiotu2K dla korekty danych.

Obsługa roli Faktor Podmiotu 3 w oparciu o płatnika na wysyłanym dokumencie

Dotychczas jeśli na fakturze określony był Płatnik inny niż Kontrahent główny a dokładniej, jeśli jako adres płatnika użyty został adres inny niż adres kontrahenta głównego, wówczas dane adresowe płatnika wysyłane były do KSeF jako Podmiot3 z rolą 6 (dokonujący płatności). Od wersji 2026.0 na podstawie płatnika obsługiwane są dwie role:

Uwaga

Ww. parametr Faktor służy wyłącznie do ułatwienia w zakresie wysyłania do KseF faktur ze wskazaniem Podmiotu3=Faktora i nie niesie za sobą żadnych innych elementów funkcjonalnych z zakresu faktoringu.

Zmiany w zakresie wysyłki identyfikatora wewnętrznego Podmiotu3

Dotychczas identyfikator wewnętrzny KSeF dla Podmiotów3 był przez Użytkowników zapisywany w atrybucie o nazwie KSeF_Podmiot3_IdWew przypisywanym czy to do adresu kontrahenta czy to do karty osoby u kontrahenta. W wersji 2026.0 udostępnione zostały stosowne kontrolki na formularzach poniższych obiektów i odtąd to w nich należy te identyfikatory umieszczać:

Podczas konwersji bazy ww. atrybuty zostały przeniesione do nowych kontrolek/nowych pól w bazie. Podczas wysyłki faktur do KSeF ww. atrybuty nie są już obsługiwane, dane pobierane są bezpośrednio z nowych kontrolek/nowych pól w bazie danych.

Podmiot upoważniony – obsługa przy wysyłce

W wersji 2026.0 obsłużono wysyłanie informacji o Podmiocie Upoważnionym oraz roli jaką pełni on w kontekście wysyłanego dokumentu. Aby System wysłał do KSeF taki podmiot należy do wysyłanego dokument przypisać:

Obsługa wysyłki adresów korespondencyjnych Podmiotów faktury KSeF

Obsłużona została wysyłka adresów korespondencyjnych poszczególnych podmiotów faktury KSeF:

Obsługa pola Nr Klienta dla Podmiotu2 i Podmiotu3

Na formatce karty kontrahenta i adresu kontrahenta udostępniona została stosowna kontrolka, w której Użytkownik może podać numer nadany danemu Klientowi. Numer ten wysyłany jest w polu NrKlienta faktury KSeF w sekcjach j.n.

Parametryzacja wysyłania danych kontaktowych Podmiotu2 i Podmiotów3

Od kliku wersji Systemu wysyłanie danych kontaktowych Sprzedawcy takich jak adres E-mail oraz numer telefonu jest sparametryzowane. W wersji 2026.0 obsłużono identyczną parametryzację w zakresie wysyłania danych kontaktowych pozostałych podmiotów występujących w fakturze KSeF: Nabywcy (Podmiot 2), Podmiotu3 oraz Podmiotu upoważnionego. Wysyłanie adresu E-mail oraz numeru telefonu Podmiotu2 zależne jest od ustawienia parametru Podczas eksportu wysyłaj/Dane kontaktowe/Nabywcy, natomiast wysyłanie adresu E-mail oraz numeru telefonu Podmiotu3 i Podmiotu Upoważnionego zależne jest od ustawienia parametru Podczas eksportu wysyłaj/Dane kontaktowe/Podmiotów trzecich.

Zmiany w zakresie wysyłki rachunków bankowych

Rachunki bankowe Faktora – rozwój funkcjonalności

W wersji 2025.1.5 Systemu obsłużone zostało wysyłanie w fakturze ustrukturyzowanej informacji o rachunkach bankowych faktora na podstawie stosownie zdefiniowanych atrybutów. W wersji 2026.0 funkcjonalność ta została rozbudowana. Na formatkę rejestru bankowego został dodany parametr Faktoring, pozwalający na określenie czy rachunek bankowy związany z tym rejestrem jest rachunkiem firmowym Użytkownika Systemu, czy też rachunkiem Faktora. Jeśli parametr ten zostanie włączony i rejestr ten zostanie użyty na wysyłanym dokumencie, wówczas dane dotyczące tego rachunku bankowe wysyłane są w sekcji Rachunek Bankowy Faktora. Jeśli parametr pozostanie wyłączony, wówczas dane dotyczące tego rachunku bankowe wysyłane są w sekcji Rachunek Bankowy.

Uwaga

Zarówno ww. parametr Faktoring jak i opisany w dalszej części dokumentu typ rachunku własnego banku służą wyłącznie do ułatwienia w zakresie wysyłania do KseF rachunków bankowych faktora/informacji o typie rachunku własnego czy też rachunku faktora i nie niosą za sobą żadnych innych elementów funkcjonalnych z zakresu faktoringu.

Wysyłka informacji o typie rachunku bankowego

W słowniku kategorii dodano nową kategorię: Typ rachunku własnego banku. Słownik ten służy do przypisywania stosownego typu rachunku na formatce rejestru bankowego. Wskazany na Rejestrze Typ rachunku jest wysyłany do KSeF w polu RachunekWlasnyBanku dla danego rachunku bankowego wysyłanego w fakturze ustrukturyzowanej.

Pole obsłużone zostało zarówno dla rachunków firmowych (wysyłanych w sekcji Rachunek Bankowy) jak i dla rachunków faktora (wysyłanych w sekcji Rachunek Bankowy Faktora).

Podczas kreacji i konwersji bazy do ww. słownika dodane zostały wartości przewidziane w schemacie KSeF e-faktury dla pola Typ rachunku własnego banku.

Zmiany w zakresie wysyłania numeru rachunku bankowego

Rachunek bankowy/rachunki bankowe czy to własne, czy to rachunki faktora wysyłane są zależnie od stosownej opcji w Konfiguracji na podstawie rejestru przypisanego w nagłówku dokumentu lub na poszczególnych płatnościach dokumentu. Zasada ta została w wersji 2026.0 utrzymana, zmianie uległy natomiast zasady wysyłania numeru takiego rachunku tj. pola NrRB faktury ustrukturyzowanej, wg poniższych zasad:

Zmiany w zakresie wysyłania informacji o płatnościach

Pomijanie płatności nie podlegających rozliczeniu przy wysyłce dokumentu do KSeF

Od wersji 2026.0 informacje płatnościach wysłanego dokumentu oraz płatnościach powiązanego z nim dokumentu kaucji WKA/WKK które zostały oznaczone parametrem Nie rozliczaj nie są wysyłane do KSeF. Dotyczy to poniższych danych:

Użytkownicy mogą wykorzystać możliwość oznaczania płatności ww. parametrem dla tych przypadków, gdy w wysyłanym dokumencie wykazują dodatkowe obciążenia czy też odliczenia rejestrowane za pomocą atrybutów KSEF_Obciazenia_Kwota, KSEF_Obciazenia_Powod oraz KSEF_ Odliczenia _Kwota i KSEF_ Odliczenia_Powod. Tak definiowane doliczenie/odliczenie nie są w żaden sposób uwzględniane w znaczniku zapłaty/w kwotach do zapłaty wysyłanego do KSeF dokumentu. Aby temu zaradzić proponujemy dokonanie na płatności dokumentu stosownej modyfikacji tj. w przypadku dodatkowego doliczenia: powiększenie płatności o dodatkowe doliczenie a na płatności różnicowej zaznaczenie parametru Nie rozliczaj.

Przyklad

Wartość brutto faktury to 1230,00, kwota dodatkowego doliczenia to 10,00. Użytkownik zmienia wartość płatności faktury na 1240,00 i na powstałej w wyniku tej modyfikacji płatności różnicowej typu zobowiązanie w wysokości 10,00 ustawia parametr Nie rozliczaj. Dzięki temu podczas wysyłki faktury do KseF dodatkowa opłata zostanie uwzględniona w kwocie do zapłaty.

Poprawa czytelności informacji o kwocie do zapłaty

W związku z tym, że częstą praktyką Użytkowników Systemu jest zawieranie w nazwach form płatności umownego terminu płatności, rozumianego jako ilość dni na zapłatę np. Przelew 14, Przelew 21 itp. dotychczasowa zasada prezentowania opisu dla kwot do zapłaty poprzez połączenie takiej nazwy formy płatności z kwotą do zapłaty powodowała że opis ten stawał się nieczytelny. Aby temu zaradzić wprowadzone zostały poniższe zasady tworzenia takiego opisu:

Dodatkowo obsłużone zostały separatory dla ww. kwot co poprawia czytelność przy dużej wartości kwoty do zapłaty.

Przyklad

Przykład 1: Na płatności faktury użyto formy płatności z przypisaną nazwą KSeF-ową: przelew

Przykład 2: Na płatności faktury użyto formy płatności o nazwie “Przelew 7”, nie przypisano dla niej formy KseF-owej

Zmiany w zakresie wysyłania sekcji Termin płatności

Od wersji 2026.0 jeśli na płatnościach wysyłanego do KSeF dokumentu czy też płatnościach towarzyszącego mu dokumentu kaucji WKA/WKK użyto tego samego terminu płatności, wówczas taki termin wysyłany jest w pliku e-faktury tylko raz. Dotychczasowe wielokrotne wysyłanie tego samego terminu było nadmiarowe.

Dodatkowy Opis – obsługa atrybutów wielowartościowych

W wersji 2024.0 Systemu wprowadzono funkcjonalność wysyłania informacji w sekcji Dodatkowy Opis w oparciu o te atrybuty przypisane czy to do nagłówka dokumentu, czy to do poszczególnych elementów faktury, które zostały oznaczone parametrem KSeF. W wersji 2026.0 funkcjonalność ta została wzbogacona o obsługę atrybutów wielowartościowych.

Zmiany w zakresie wysyłania informacji o umowie związanej z fakturą

W zakresie wysyłania informacji o umowie, z jaką związany jest wysyłany do KSeF dokument zostały dokonane poniższe zmiany:

Uwaga

W przypadku rejestrowania numerów umów za pomocą atrybutu wielowartościowego jako data każdej z nich wysyłana jest ta sama data (z atrybutu KSEF_DataUmowy).

Obsługa pola Warunki dostawy

Podczas wysyłki faktur do KSeF obsłużone zostało pole Warunki dostawy. W polu tym wysyłana jest wartość złożona z symbolu i miejsce Incoterms przypisanych na formatce wysyłanego dokumentu.

Zmiany w zakresie wysyłki korekt

Korekta danych wielu Nabywców i obsługa pola IDNabywcy

System Comarch ERP XL nie posiada funkcjonalności rejestrowania faktury dla wielu nabywców. Aby wesprzeć Użytkowników w tym zakresie w wersji 2025.1.5 wprowadzona została funkcjonalność pozwalająca na wysyłanie do KSeF takich faktur, oparta na poniższych założeniach rejestrowania dokumentu głównego, podlegającego wysyłce do KSeF i dokumentów pomocniczych z włączoną opcją KSeF/Poza Systemem:

W wersji 2026.0 Systemu obsłużona została korekta danych dla faktury zarejestrowanej w ww. trybie faktury dla wielu Nabywców. Aby zarejestrować i wysłać do KSeF taką korektę należy kierować się podobną logiką rejestrowania i wiązania korekt, zachowując poniższe zasady:

Wskazówka

Jeśli ww. fakturami cząstkowymi są faktury A-vista wówczas należy zarejestrować do nich zwykłą korektę z poprawnymi danymi kontrahenta. W przypadku, gdy korygowana (A)FS zawiera elementy, wówczas na (A)FSK należy je usunąć, jeśli korygowana (A)FS nie zawierała elementów a jedynie tabelę VAT, wówczas aby zapisać taką zerową korektę (A)FSK należy dodać na niej dwa techniczne rekordy VAT o przeciwnej wartości różnicując jest np. opisem.

Przy zachowaniu ww. zasady podczas wysyłki korekty danych faktury głównej wysyłane są poniższe dane:

Korekta faktury zaliczkowej – wysyłanie danych dotyczących zamówienia

W wersji 2026.0 obsłużone zostało wysyłanie dla korekt faktur zaliczkowych KSL/KEL informacji o elementach zamówienia, z którym związana jest korygowana faktura zaliczkowa.

Korekta zbiorcza obejmująca wszystkie dostawy – wysyłka dokumentu bez elementów

W myśl art. 106j ust. 3 Ustawy w przypadku gdy podatnik udziela opustu lub obniżki ceny może wystawić fakturę korygującą dotyczącą dostaw towarów lub świadczenia usług na rzecz jednego odbiorcy w danym okresie, która:

Zgodnie w powyższym, jeśli korekta dotyczy wszystkich dostaw towarów i usług podatnik wysyłając ją do KSeF może nie wysyłać żadnych danych w części FaWiersz. Elastyczność ta ma duże znaczenie zwłaszcza w przypadku dużych korekt, które ze względu na ograniczenia po stronie KSeF mogą być odrzucane, a Użytkownicy zmuszani są do dzielenia okresu rabatowego na kilka mniejszych.

Aby umożliwić Użytkownikom wysyłkę korekt zbiorczych bez elementów na formatkę korekt zbiorczych dodany został parametr Rabat dotyczy wszystkich dostawa. Jeśli Użytkownik go włączy, wówczas przy wysyłce takiej korekty (Z)FSK, (Z)FKE do KSeF sekcja FaWiersz nie jest wysyłana.

Ww. parametr dostępny jest również na formatce (Z)FZK, ale pełni wówczas wyłącznie informacyjną rolę.

Uwaga

System nie kontroluje tego czy faktycznie na danej korekcie zbiorczej udzielono rabatu dla wszystkich transakcji z danym kontrahentem w danym okresie, odpowiedzialność w tym zakresie leży po stronie Użytkownika.

Obsługa typu skutku korekty podczas wysyłki do KSeF

Na formatkach korekt udostępniono nową kontrolkę w której Użytkownik może wskazać typ skutku korekty, oparty na nowym słowniku kategorii.

Wskazana w ww. kontrolce korekty sprzedaży wartość jest wysyłane w polu TypKorekty faktury ustrukturyzowanej. Podczas kreacji i konwersji bazy do ww. słownika dodane zostały wartości przewidziane w schemacie KSeF e-faktury.

Zmiany w zakresie wysyłki elementów faktury/elementów zamówienia

Obsługa daty dostawy dla poszczególnych elementów faktury typu spinacz

W fakturze ustrukturyzowanej KSeF informację o dacie dostawy można przesłać w części nagłówkowej faktury (w polu P_6) wówczas, gdy jest ona znana, jest inna niż data wystawienia i jest wspólna dla wszystkich elementów faktury. Zamiast konkretnej daty można przesłać okres dostawy (pola P_6_Od i P_6_Do). Jeśli data dostawy jest różna dla poszczególnych elementów faktury, wówczas nie wysyła się ww. pól, wysyła się natomiast daty dostawy dla kolejnych powtórzeń sekcji FaWiersz (w polach P_6A).

Dotychczas w Systemie Comarch ERP XL pola P_6A wysyłane były wyłącznie na podstawie atrybutu KSEF_P_6A przypisanego do elementu faktury (a w przypadku (S)FS, (S)FSE, RA do elementu WZ/WZE/PA w nim spiętego).

W wersji 2026.0 obsłużona została opcjonalna wysyłka ww. pola również dla spinaczy nagłówkowych i spinaczy elementów na podstawie daty sprzedaży WZ/WZE/PA do którego dany element należy. W przypadku spinaczy elementów, które w jednym elemencie mogą wskazywać na wiele różnych WZ/WZE System ustala tą datę na podstawie daty sprzedaży WZ/WZE 1-go subelementu.

Wysyłka P_6A w ww. okolicznościach dokonywana jest o ile spełnione są oba poniższe warunki:

Ww. daty nie są wysyłane wówczas, jeśli Użytkownik za pomocą stosownych atrybutów jawnie wskaże, że ostateczna data dostawy nie jest jeszcze znana i nie należy jej wysyłać (tj. jeśli zdefiniuje atrybut KSEF_DataDostawy z wartością <Nieokreślona>) lub poda okres od-do dostawy (tj. zdefiniuje atrybuty KSEF_P_6_Od i KSEF_P_6_Do).

Parametryzacja wysyłania kodu towaru w polu Indeks, IndeksZ

Sparametryzowane zostało zachowanie Systemu w zakresie obsługi pola Indeks (pole wysyłane dla kolejnych powtórzeń elementów faktur sprzedaży i ich korekt) oraz IndekZ (pole wysyłane dla kolejnych powtórzeń elementów zamówienia podczas wysyłki faktur zaliczkowych i ich korekt).

W Konfiguracji systemu została dodana kontrolka, w której Użytkownik może zdecydować o tym, czy System ma wypełniać pole Indeks/IndeksZ podczas wysyłki dokumentów do KSeF, a jeżeli tak to w oparciu o jakie dane towaru. W menu kontrolki udostępnione zostały wartości j.n.

Przez ww. kod u kontrahenta rozumiany jest kod przypisany na formatce Odbiorcy danego towaru, przy czym jeśli w Konfiguracji systemu wskazano opcję Podczas eksportu wysyłaj/Ilość/cenę dla jednostki: pomocniczej, wówczas wysyłany jest kod u Odbiorcy dla danego towaru i jednostki zgodnej z użytą na elemencie, a jeżeli takowy nie został zdefiniowany wówczas kod u Odbiorcy dla danego towaru bez przypisanej jednostki. Jeżeli w Konfiguracji wskazano opcję Podczas eksportu wysyłaj/Ilość/cenę dla jednostki: podstawowej, wówczas wysyłany jest kod u Odbiorcy dla danego towaru i bez przypisanej jednostki.

Podczas wysyłki dokumentów (A)FS/(A)FSK nie zawierających elementów a jedynie tabelę VAT obowiązuje zasada, zgodnie z którą jeśli w ww. kontrolce wskazana zostanie wartość Kod systemowy, wówczas w polu Indeks wysyłana jest fraza Koszt, w przypadku, gdy w ww. kontrolce ustawiona zostanie wartość Kod u kontrahenta lub kontrolka pozostanie pusta pole Indeks nie jest wysyłane.

Zmiany w zakresie wysyłki pola GTIN, GTINZ

Od wersji 2026.0 identyfikacja GTIN towaru dokonywana jest wyłącznie w zakresie kodów EAN-8 i EAN-13. Pozostałe rodzaje kodów jako nie należące do rodziny kodów GTIN są pomijane. Ww. zmiany dotyczą pola GTIN wysyłanego dla elementów faktur sprzedaży i ich korekt oraz pola GTINZ elementów zamówienia wysyłanych dla faktur zaliczkowych i ich korekt.

Obsługa pola PKWiU i PKWiUZ

Obsłużona została wysyłka kodów PKWiU z kart towarowych podczas wysyłki dokumentów do KSeF. Obsługa dotyczy pola PKWiU wysyłanego dla elementów faktur sprzedaży i ich korekt oraz pola PKWiUZ elementów zamówienia wysyłanych dla faktur zaliczkowych i ich korekt.

Obsługa pola GTU i GTUZ

Obsłużona została wysyłka kodów GTU z kart towarowych podczas wysyłki dokumentów do KSeF. Obsługa dotyczy pola GTU wysyłanego dla elementów faktur sprzedaży i ich korekt oraz pola GTUZ elementów zamówienia wysyłanych dla faktur zaliczkowych i ich korekt.

Obsługa pola KwotaAkcyzy i KwotaAkcyzyZ

Ww. pola zostały obsłużone w oparciu o atrybut o nazwie KSEF_KwotaAkcyzy:

Udostępnienie pola P_11Vat w procedurze

W Systemie Comarch ERP XL obowiązuje metoda liczenia podatku VAT od sumy wartości elementów w danej stawce. System nie obsługuje metody ustalania wielkości podatku VAT jako sumy VAT-u z poszczególnych elementów. Co za tym idzie w standardzie Systemu pole P_11Vat faktury ustrukturyzowanej (kwota podatku VAT dla elementu faktury) nie jest obsługiwane. Aby jednak umożliwić służbom informatycznym Klienta samodzielną obsługę tego pola zostało ono udostępnione w stosownej procedurze.

Sterowanie czasem wykonywania operacji wysyłki faktury do KSeF w dedykowanym pliku

W przypadku rejestrowania przez Użytkownika bardzo dużych dokumentów i późniejszej próbie ich wysłania do KSeF może się zdarzać, że czas wykonania procedury KSeF_Dane3 przekroczy założony dla tej operacji czas 60 sekund. W takim przypadku przy wysyłce takiego dokumentu występuje błąd o treści Query timeout expired.

Funkcje i procedury biorące udział w wysyłce do KSeF zostały stosownie zoptymalizowane, nadal może się jednak zdarzyć że w określonych przypadkach konkretnego Użytkownika ww. czas 60 sekund nadal będzie niewystarczający. Aby temu zaradzić udostępniono plik config w folderze KSeF (KSeF/Comarch.XL.KSeF.dll.config), w którym Użytkownik może samodzielnie zmienić ww. domyślny limit 60 sekund na odpowiednio wyższy. Plik należy wyedytować i zapisać przed uruchomieniem modułu Comarch ERP XL. Nowa wartość jest zapamiętana na cały czas działania procesu, każda kolejna zmiana wymaga restartu modułu.

Dla większości Klientów 60 sekund to wystarczający czas. Sugerujemy zmianę dopiero po przeprowadzeniu testu na bazie danych (wywołanie procedury KSeF_Dane3) lub faktycznym niepowodzeniu wysyłki czy też sprawdzenia poprawności dokumenty wg schematu KSeF.

Zmiany w zakresie wartości na liście faktur zaimportowanych z KSeF

Ustalanie wartości netto i kwoty podatku VAT podczas importu faktur bez tabeli VAT

Obsłużone zostało samodzielne ustalanie przez System Comarch ERP XL wartości netto oraz kwoty VAT tych importowanych z KSeF dokumentów, dla których Dostawca nie przekazał wielkości netto/VAT na poziomie podsumowania faktury (brak/puste pola od P_13_1 do P_13_11) ale wyłącznie na poziomie elementów (kolejnych powtórzeń sekcji FaWiersz) faktury. Dla takich dokumentów API KSeF nie zwraca wartości netto i kwoty VAT, w konsekwencji czego na fakturze zaimportowanej z KSeF do Systemu Comarch ERP XL były one dotąd zerowe. Aby temu zaradzić System samodzielnie ustala i zapisuje wartość netto i kwotę VAT faktury KSeF w oparciu o elementy faktury. Taki mechanizm uruchamiany jest o ile zachodzą oba poniższe warunki:

Poprawa prezentacji wartości brutto dokumentu

Dotychczasowa metoda prezentowania wartość brutto faktury KSeF jako sumy kolumn: Netto i VAT zawodzi w przypadku dokumentów w walucie obcej. Aby temu zaradzić od wersji 2026.0 w tabeli KSeFDokumenty dla importowanych faktur oprócz wartości netto (w walucie dokumentu) i kwoty podatku VAT (w PLN) zapisywana jest również wartość brutto (w walucie dokumentu) i to ona prezentowana jest na liście faktur KSeF i formatce faktury KSeF w kolumnie/kontrolce: Wartość brutto.

Uwaga

Dla dokumentów zaimportowanych z KSeF niższą wersją Systemu podczas konwersji do 2026.0 wartość brutto ustalana jest wyłącznie dla dokumentów w walucie PLN, dla faktur w walucie obecej poozstaje ona na poziomie 0,00. Dla dokumentów importowanych z KSeF wersją 2026.0 wartość brutto ustalana jest już dla wszystkich dokumentów, bez względu na ich walutę.

Zmiany w zakresie generowania dokumentów na podstawie faktury KSeF

Zmiana zasad ustalania wartości/ceny elementów na dokumencie generowanym na podstawie faktury KSeF

Zmiany w zakresie ww. funkcji dotyczą poniższych przypadków:

Zmiany w ww. zakresie dotyczą generowania dokumentów: FZ, (A)FZ z elementami oraz (s)FZ.

Dokumenty rejestrowane metodę od netto

Dla ww. dokumentów obowiązują przedstawione w poniższej tabeli zasady ustalania cen i wartości na generowanym elemencie zależnie od rodzaju danych przesyłanych w pliku e-faktury.

	Dane w pliku e-faktury				Dane na generowanym elemencie
Lp	Czy dla danego FAWiersz przesłane pole				Cena początkowa	Cena końcowa	Wartość końcowa
	Cena początkowa netto	Cena początkowa brutto	Wartość netto	Wartość brutto
	P_9A	P_9B	P_11	P_11A
1	Tak	Tak	Tak	Tak	P_9A	Wyliczana wtórnie	P_11
2	Tak	Tak	Tak	Nie	P_9A	Wyliczana wtórnie	P_11
3	Tak	Tak	Nie	Tak	P_9A	[P_9A - P_10]	Wyliczana wtórnie
4	Tak	Tak	Nie	Nie	P_9A	[P_9A - P_10]	Wyliczana wtórnie
5	Tak	Nie	Tak	Tak	P_9A	Wyliczana wtórnie	P_11
6	Tak	Nie	Tak	Nie	P_9A	Wyliczana wtórnie	P_11
7	Tak	Nie	Nie	Tak	P_9A	[P_9A - P_10]	Wyliczana wtórnie
8	Tak	Nie	Nie	Nie	P_9A	[P_9A - P_10]	Wyliczana wtórnie
9	Nie	Tak	Tak	Tak	Wyliczana wtórnie	Wyliczana wtórnie	P_11
10	Nie	Tak	Tak	Nie	Wyliczana wtórnie	Wyliczana wtórnie	P_11
11	Nie	Tak	Nie	Tak	Wyliczana wtórnie	Wyliczana wtórnie	Unettowione P_11A
12	Nie	Tak	Nie	Nie	Wyliczana wtórnie	Unettowione [P_9B-P_10]	Wyliczana wtórnie
13	Nie	Nie	Tak	Tak	Wyliczana wtórnie	Wyliczana wtórnie	P_11
14	Nie	Nie	Tak	Nie	Wyliczana wtórnie	Wyliczana wtórnie	P_11
15	Nie	Nie	Nie	Tak	Wyliczana wtórnie	Wyliczana wtórnie	Unettowione P_11A
16	Nie	Nie	Nie	Nie	Wyliczana wtórnie	Wyliczana wtórnie	Wyliczana wtórnie

Dokumenty rejestrowane metodę od brutto

Dla ww. dokumentów obowiązują przedstawione w poniższej tabeli zasady ustalania cen i wartości na generowanym elemencie zależnie od rodzaju danych przesyłanych w pliku e-faktury.

	Dane w pliku e-faktury				Dane na generowanym elemencie
Lp	Czy dla danego FAWiersz przesłane pole				Cena początkowa	Cena końcowa	Wartość końcowa
	Cena początkowa netto	Cena początkowa brutto	Wartość netto	Wartość brutto
	P_9A	P_9B	P_11	P_11A
1	Tak	Tak	Tak	Tak	P_9B	Wyliczana wtórnie	P_11A
2	Tak	Tak	Tak	Nie	P_9B	[P_9B-P_10]	Wyliczana wtórnie
3	Tak	Tak	Nie	Tak	P_9B	Wyliczana wtórnie	P_11A
4	Tak	Tak	Nie	Nie	P_9B	[P_9B-P_10]	Wyliczana wtórnie
5	Tak	Nie	Tak	Tak	Wyliczana wtórnie	Wyliczana wtórnie	P_11A
6	Tak	Nie	Tak	Nie	Wyliczana wtórnie	Wyliczana wtórnie	Ubruttowiona P_11
7	Tak	Nie	Nie	Tak	Wyliczana wtórnie	Wyliczana wtórnie	P_11A
8	Tak	Nie	Nie	Nie	Wyliczana wtórnie	Ubruttowiona [P_9A-P_10]	Wyliczana wtórnie
9	Nie	Tak	Tak	Tak	P_9B	Wyliczana wtórnie	P_11A
10	Nie	Tak	Tak	Nie	P_9B	[P_9B-P_10]	Wyliczana wtórnie
11	Nie	Tak	Nie	Tak	P_9B	Wyliczana wtórnie	P_11A
12	Nie	Tak	Nie	Nie	P_9B	[P_9B-P_10]	Wyliczana wtórnie
13	Nie	Nie	Tak	Tak	Wyliczana wtórnie	Wyliczana wtórnie	P_11A
14	Nie	Nie	Tak	Nie	Wyliczana wtórnie	Wyliczana wtórnie	Ubruttowiona P_11
15	Nie	Nie	Nie	Tak	Wyliczana wtórnie	Wyliczana wtórnie	P_11A
16	Nie	Nie	Nie	Nie	Wyliczana wtórnie	Wyliczana wtórnie	Wyliczana wtórnie

Generowanie (A)FZ/(A)FZK bez elementów na podstawie faktury KSeF nieposiadającej tabeli VAT

Dotychczas tabelka VAT dokumentu (A)FZ/(A)FZK bez elementów tworzona była na podstawie wartości netto i kwot VAT podsumowania dokumentu KSeF przesłanych w polach od P_13_1 do P_13_11.

Ww. obsługa faktur A-vista została zachowana, natomiast oprócz niej obsłużone zostały te przypadki, w których Dostawca nie przesyła tabeli VAT faktury (nie przesyła pól P_13_1 – P_13_11) a jedynie wartości i kwoty VAT dla poszczególnych elementów faktury w kolejnych powtórzeniach sekcji FaWiersz. W takich przypadkach na potrzeby ustalenia rekordów tabeli VAT System samodzielnie ustala stawkę VAT, podstawę VAT (wartość netto lub brutto dla danej stawki zależnie od kierunku Vat na dokumencie) oraz kwotę VAT na podstawie wartości/kwot VAT elementów faktury. Taki mechanizm uruchamiany jest dla faktur spełniających oba poniższe warunki:

Generowanie (A)FZ dla specyficznych rodzajów transakcji

Funkcjonalność generowania dokumentów (A)FZ/(A)FZK bez elementów oraz dokumentów FZL/KZL na podstawie faktur KSeF wzbogacona została o stosowną interpretację specyficznych rodzajów transakcji j.n.:

Generowanie elementów FZ/(A)FZ dla których nie podano ilości

Obsłużono generowanie elementów FZ/(A)FZ na podstawie tych powtórzeń FaWiersz faktury KSeF, dla których w pliku nie przesłano ilości. Dla takich przypadków na generowanym elemencie ustalana jest ilość 1x jednostki miary przesłana w pliku e-faktury, a jeśli jednostka miary również nie została przesłana, wówczas ustalana jest ilość 1x jednostka podstawowa towaru.

Generowanie elementów FZ/(A)FZ dla których nie podano stawki VAT

Stawka VAT elementu faktury FZ/(A)FZ generowanej na podstawie faktury KSeF ustalana jest na podstawie pola P_12 pliku e-faktury. W związku z tym, że zdarzają się faktury, zwłaszcza dotyczące specyficznych typów transakcji, w których Sprzedawca nie przesyła stawki VAT elementu zmieniona została obsługa takich przypadków: dla tych powtórzeń sekcji FaWiersz dla których nie przesłano wartości pola P_12 System sprawdza tabelę VAT e-faktury i to na jej podstawie ustala stawkę VAT elementu. Zasady identyfikacji stawki, w tym kolejność tej identyfikacji przedstawia poniższa tabela:

Ustalanie stawki VAT na elemencie FZ/(A)FZ gdy nie została przesłana w polu P_12
Kolejność	Sprawdzane pola (wartość > 0)	Stawka VAT ustalana na elemencie FZ/(A)FZ
1	P_13_8 P_13_9 P_13_10 P_13_11	np
2	P_13_7	zw
3	P_13_6_1 P_13_6_2 P_16_6_3	0%
4	P_13_1	23%
5	P_13_2	8%
6	P_13_3	5%
7	P_13_4	4%

Generowanie elementów A-vista dla których nie podano jednostki miary

Obsłużono generowanie elementów faktury (A)FZ na podstawie tych powtórzeń FaWiersz faktury KSeF, dla których w pliku nie przesłano jednostki miary. Dla takich przypadków na generowanym elemencie ustalana jest jednostki miary przypisana na karcie towaru A-vista.

Dla zwykłych kartotek towarowych ww. zasada obowiązuje już od kilku wersji Systemu.

Kopiowanie numeru zamówienia na generowaną (A)FZ

Obsłużone zostało przenoszenie informacji o zamówieniu przekazanym w polu NrZamowienia faktury ustrukturyzowanej KSeF na generowaną na jej podstawie:

Uwaga

W żadnym z ww. przypadków generowana faktura nie realizuje żadnego zarejestrowanego w Systemie zamówienia ZZ. W celu realizacji ZZ Użytkownik powinien generować fakturę handlową FZ ze wskazaniem zamówienia zidentyfikowanego w Systemie. Jeśli taka identyfikacja się nie uda, wówczas po wygenerowaniu FZ należy dokonać operacji jej spięcia z samodzielnie odszukanym przez Użytkownika zamówieniem zakupu ZZ.

Generowanie oddzielnych dokumentów WKA i PKA dla kaucji obsługiwanych w systemie kaucyjnym DRS

Wprowadzono modyfikację umożliwiającą automatyczne rozdzielenie opakowań kaucyjnych na dwa odrębne dokumenty: jeden dla dotychczasowych kaucji oraz drugi dla kaucji objętych nowym systemem kaucyjnym.

Konfiguracja systemu

W celu automatycznego rozdzielania kaucji przez system, wymagane jest włączenie odpowiedniego parametru na definicjach dokumentów handlowych. Na definicji dokumentów FS, PA, FZ, WZ, PZ, FSE, WZE, MMW dodano parametr Oddzielne dokumenty kaucji dla systemu kaucyjnego.

Zaznaczenie parametru spowoduje generowanie odrębnych dokumentów kaucyjnych w sytuacji gdy na dokumencie handlowym znajdą się pozycje towarowe powiązane ze schematami zawierającymi stare i nowe kaucje.

Uwaga

Aby system prawidłowo identyfikował nowe kaucje, towary podlegające pod nowy system kaucyjny muszą posiadać odpowiednio skonfigurowany rodzaj kaucji na kartotece kaucyjnej na zakładce [Jednostki, kody,VAT/Opakowanie].

Generowanie odrębnych dokumentów kaucyjnych WKA i PKA podczas wystawiania dokumentów handlowych

Rozdzielanie dokumentów kaucji

Podczas wystawiania dokumentu handlowego i dodawania na niego towarów objętych nowym systemem kaucyjnym, zostanie automatycznie wygenerowany odrębny dokument WKA (lub PKA). Jeżeli na tym samym dokumencie handlowym znajdą się również tradycyjne opakowania, utworzony zostanie drugi, standardowy dokument WKA/PKA.

Generowanie odrębnych dokumentów kaucyjnych dotyczy następujących scenariuszy:

Wygenerowane dokumenty kaucyjne dla kaucji w systemie DRS charakteryzują się odmiennym działaniem w stosunku do standardowych dokumentów kaucyjnych.

Obowiązkowe naliczanie płatności

Na dokumentach WKA/PKA dotyczących nowych kaucji parametr Płatności jest automatycznie zaznaczony. W przeciwieństwie do standardowych kaucji (gdzie płatność wynika z definicji dokumentu i ustawień kontrahenta), dla nowych opakowań zawsze zostanie wygenerowana odpowiednia płatność (należność lub zobowiązanie).

Generowanie pozycji w relacji jeden do jednego (brak grupowania pozycji kaucji)

Na nowych dokumentach kaucyjnych pozycje nie podlegają grupowaniu. Elementy generowane są w relacji jeden do jednego. Oznacza to, że dla każdej pozycji towarowej na dokumencie handlowym zostanie wygenerowana odpowiadająca jej, odrębna pozycja na dokumencie WKA/PKA, posiadająca bezpośrednie powiązanie do pozycji dokumentu handlowego.

Zmiany funkcjonalne w synchronizacji z Comarch EDI (ECOD) związane z KSeF

W związku z możliwością przesyłania faktur do Krajowego Systemu e-Faktur [KSeF] za pośrednictwem Comarch EDI wprowadzono kolejne zmiany pozwalające na dostosowanie wysyłki faktur do wymogów KSeF. Równocześnie zachowano dotychczasowy sposób przesyłania dokumentów za pomocą platformy EDI.

To czy faktura zostanie przesłana w dotychczasowej strukturze czy w strukturze dostosowanej do KSeF zależy od ustawienia na zakładce [KSeF] eksportowanej faktury:

Wskazówka

Dokumenty przeznaczone do wysyłki do KSeF (ustawienie poza systemem) powinny być importowane na odpowiedniej relacji w Comarch EDI, która umożliwia wysyłke faktur do KSeF.

Poniżej przedstawiono działanie systemu w sytuacji, gdy na fakturze zaznaczono parametry Wyślij do KSeF i Poza systemem, co oznacza, że eksport do KSeF będzie realizowany za pośrednictwem Comarch EDI.

Wysyłka danych zamówienia do EDI/KSeF

Zasady wysyłki numeru i daty zamówienia:

Pomijanie kwot podatku w pozycjach faktury

Dla faktur wysyłanych do KSeF wprowadzono następujące ograniczenia w wysyłanych danych:

Obsługa korekt danych w KSeF

Faktura korygująca dane (często nazywana korektą formalną) jest wystawiana przez sprzedawcę w sytuacjach, gdy na dokumencie pierwotnym pojawiły się błędy, które nie wpływają na dane finansowe (kwoty netto, VAT, brutto), ale dotyczą istotnych informacji nagłówkowych. Na korektach danych nie ma obowiązku prezentowania pozycji.

Wprowadzono następujące zmiany w strukturze przesyłanego pliku:

Obsługa odbiorcy (Podmiotu 3) z identyfikatorem wewnętrznym KSeF

System umożliwia prawidłowe przekazywanie danych odbiorcy (Podmiotu 3 / Rola 2), który posiada nadany indywidualny identyfikator wewnętrzny KSeF (składający się z numeru NIP oraz 5-cyfrowego numeru, np. 5493442032-578053).

Zasady działania:

Ograniczenie nadmiarowych sekcji podmiotów w strukturze EDI/KSeF

W celu optymalizacji i uproszczenia struktury faktur przekazywanych za pośrednictwem EDI do KSeF, system automatycznie pomija następujące sekcje:

Inne zmiany

Typ dokumentu generowanego na podstawie KSeF na karcie kontrahenta i wzorcu kontrahenta

Na karcie kontrahenta i wzorca kontrahenta w sekcji KSeF/Zakup dodana została kontrolka Kwalifikacja, w której Użytkownik może wskazać jedną z wartości: Dokument handlowy lub Dokument VAT. Wskazanie jednego z tych typów dokumentów oznacza, że na podstawie faktur importowanych z KSeF pochodzących od tego Dostawcy Użytkownik rejestruje zawsze dokumenty handlowe lub dokumenty kosztowe (dokumenty VAT). Pozostawienie tej kontrolki pustej oznacza, że takiego przypisanie nie można jednoznacznie dokonać, ponieważ od takiego kontrahenta firma otrzymuje zarówno faktury handlowe jak i kosztowe.

Ww. kontrolka pełni na razie wyłącznie funkcję informacyjną, w jednej z kolejnych wersji Systemu będzie wykorzystywana podczas operacji Ustal kwalifikację dokonywaną seryjnie przez System dla dokumentów zaimportowanych z KSeF.

Księgowość

Nowe pole JPK_KSeF na dokumentach handlowych ujmowanych w pliku JPK_V7

Nowe pole JPK_KSeF udostępniono na dokumentach ujmowanych w plikach JPK_V7, zarówno po stronie sprzedaży, jak i zakupu. Zastępuje ono atrybut JPK_KSeF, który był udostępniany w HF5 do wersji 2025.1.5.

Wartości pola są powiązane z oznaczeniami KSeF OFF, BFK oraz DI, którymi oznacza się dokumenty nieposiadające numeru KSeF.

Ustawienie wartości AUTO (wartość domyślna) powoduje, że dokument, który nie ma przypisanego numeru KSeF, zostanie w pliku JPK_V7 oznaczony za pomocą algorytmu zaszytego w systemie.

Z uwagi na możliwość wystąpienia specyficznych przypadków, Użytkownik ma możliwość wskazania konkretnej wartości, która będzie traktowana przez system jako priorytetowa (będzie miała pierwszeństwo). Standardowo system w pierwszej kolejności sprawdza czy dokument ma przypisany numer KSeF – jeśli tak, prezentuje go w pliku JPK_V7.

W przeciwnym razie weryfikuje wartość pola JPK_V7. Jeżeli napotka w tym polu wartość inną niż AUTO, pobiera do pliku JPK_V7 wartość bezpośrednio z dokumentu.

Kopiowanie danych KSeF z dokumentów źródłowych na dokumenty ZD’FS, ZD’FZ (Ulga na złe długi)

W wersji Comarch ERP XL 2026.0 wprowadzono pełną automatyzację przenoszenia parametrów związanych z Krajowym Systemem e-Faktur (KSeF) na dokumenty generowane z tytułu ulgi na złe długi (ZD) oraz ich korekty. Zmiana ta obejmuje zarówno procesy po stronie sprzedażowej, jak i zakupowej.

Strona sprzedażowa

Proces automatycznego przepływu danych KSeF po stronie sprzedaży realizowany jest w ścieżce:

Faktura Sprzedaży (FS) / Korekta -> Dokument ZD’FS -> Korekta dokumentu ZD (ZD’FSK)

Podczas generowania dokumentów ZD’FS/ZD’FZ system automatycznie uzupełni pola takie jak m.in. Numer identyfikujący w KSeF, Status KSeF oraz daty powiązane z procesem walidacji, bazując bezpośrednio na rekordzie dokumentu bazowego. Przy wykonywaniu korekt (ZD’FSK/ZD’FZK) po stronie użytkownika nie są wymagane żadne dodatkowe akcje – mechanizm dziedziczenia działa w tle.

Strona zakupowa

Proces automatycznego przepływu danych KSeF po stronie zakupowej realizowany jest w ścieżce:

Faktura Zakupu (FZ) / Korekta -> Dokument ZD’FZ -> Korekta dokumentu ZD (ZD’FZK).

Podstawa prawna

Źródło: Broszura informacyjna dotycząca struktury JPK_VAT z deklaracją [JPK_V7M(3), JPK_V7K(3) – rozdział “Przykłady”, przykłady nr 9 i 10. Link do broszury: https://www.podatki.gov.pl/media/wgbkrejs/broszura-jpk_vat-z-deklaracj%C4%85-od-1-lutego-2026-r.pdf].

Poniżej zamieszczono zrzut ekranu z broszury, prezentujący treść wspomnianych przykładów

Nowe typy dat powstania obowiązku podatkowego

W wersji Comarch ERP XL 2026.0 wprowadzono nowe typy dat powstania obowiązku podatkowego dla dokumentów, które podlegają wysyłce do Krajowego Systemu E-Faktur (KSeF) i są ujmowane w plikach JPK_V7. Nowe opcje są ściśle powiązane z datami wysłania dokumentów do KSeF oraz ich przyjęcia przez system. Obecnie są one obsługiwane wyłącznie z poziomu dokumentów i nie są dostępne dla kategorii Moment powstania obowiązku podatkowego.

W zależności od typu dokumentu udostępniono następujące parametry:

Zasada działania i automatyzacja pól

1. Brak przetworzenia w KSeF – jeżeli na dokumencie zostanie wybrany jeden z nowych typów dat powstania obowiązku podatkowego, ale dokument nie został jeszcze wysłany do KSeF lub przez niego przyjęty, odpowiednie pole daty pozostanie puste. Skutkuje to jednoczesnym wyczyszczeniem miesiąca i roku ujęcia w deklaracji VAT-7.

2. Aktualizacja danych po przetworzeniu – po poprawnym wysłaniu faktury do KSeF lub jej odebraniu z systemu, właściwa data zostanie uzupełniona na dokumencie. Warunkiem koniecznym do zaktualizowania tej informacji jest ponowne wejście w edycję dokumentu i jego zapisanie. Nastąpi także aktualizacja miesiąca i roku ujęcia na deklaracji VAT-7

Zmiany w logice księgowania różnic kursowych (RK)

W wersji Comarch ERP XL 2026.0 wprowadzono nową logikę księgowania różnic kursowych (RK). Zmiana ta ma na celu wyeliminowanie dotychczasowych ograniczeń związanych z księgowaniem RK na dwa odrębne konta rozrachunkowe. Nowe rozwiązanie niweluje trudności pojawiające się przy rozrachowywaniu dekretów przeciwstawnych do dekretów domykających różnicę kursową, a także dekretów dodatkowych, generowanych za pomocą schematów księgowych.

Dotychczas wszystkie dekrety powiązane z dokumentem RK, niezależnie od typu konta, miały przypisany parametr “Kwota tylko w walucie systemowej” (w bazie danych: tabela CDN.Dekrety, wartość DT_TrybKwotySys = 3).

W nowej wersji logika ta została uzależniona od charakteru dekretu oraz typu użytego konta księgowego.

Dla księgowych pracujących z dokumentami walutowymi oznacza to następujące zasady:

Dekrety bezpośrednio domykające rozrachunek (różnice kursowe)

Dla tego typu dekretów system zachowuje dotychczasową zasadę. Zapis zawsze powstaje z zaznaczonym parametrem “Kwota tylko w walucie systemowej”. Reguła ta dotyczy dekretów rejestrowanych na wszystkich kontach walutowych (związanych i niezwiązanych) oraz kontach wielowalutowych.

Dekrety na kontach przeciwstawnych oraz dodatkowych (niedomykające bezpośrednio RK)

Zasadnicza zmiana dotyczy dekretów, które nie są bezpośrednim domknięciem różnicy kursowej (np. powstających z pozycji schematu księgowego „Konto Plus/Minus”). System traktuje je teraz jak standardowe zapisy księgowe, a ich zachowanie zależy od rodzaju konta:

Wpływ na codzienną pracę

Parametr “Kwota tylko w walucie systemowej”

Niniejszy rozdział nie opisuje zmian w systemie, lecz wyjaśnia rolę parametru “Kwota tylko w walucie systemowej”, która przez wielu użytkowników bywa nieprawidłowo interpretowana. Często jest on traktowany jako „zwykły wpis w złotówkach, który ignoruje walutę obcą”. W rzeczywistości, w architekturze systemu jest to mechanizm służący wyłącznie do korekty wartości istniejącego salda walutowego. Zrozumienie tego niuansu jest kluczowe dla poprawnego prowadzenia ksiąg rachunkowych.

Jak działa parametr „Kwota tylko w walucie systemowej”?

Parametr ten służy do wprowadzania zapisów aktualizujących wycenę na kontach prowadzonych w walutach obcych.

Jego zaznaczenie nie oznacza, że system „pomija” walutę transakcji (np. EUR). Wskazana w polu obok waluta jest tutaj kluczowa, ponieważ wprowadzana kwota w walucie systemowej (PLN) ma za zadanie wycenić właśnie tę konkretną walutę obcą, bez zmiany jej fizycznego salda na koncie.

Mechanizm działania w systemie

Kiedy należy używać tego parametru?

Z tego rozwiązania korzystamy w sytuacjach, gdy zachodzi konieczność zmiany wartości konta w walucie ewidencji (PLN), ale nie nastąpił żaden rzeczywisty przepływ środków w walucie obcej. Najczęstsze scenariusze to:

Wskazówka

Wpisując kwotę przy zaznaczonym parametrze, użytkownik nie księguje „niezależnych złotówek” na koncie walutowym. Przekazuje natomiast systemowi instrukcję: „Dla waluty widocznej w polu obok (np. EUR), zmień jej wartość w PLN o wpisaną kwotę, ale nie zmieniaj samego salda w EUR”.

Przyklad

Jeżeli dotychczasowe saldo wynosiło 1000 EUR (o równowartości 4000 PLN), to po wprowadzeniu takiego zapisu na kwotę 123 PLN saldo walutowe pozostanie bez zmian (1000 EUR), natomiast jego wycena w walucie systemowej wzrośnie do 4123 PLN.

Nowy komunikat informacyjny (tooltip) dla parametru „Kwota tylko w walucie systemowej”

W celu wyeliminowania wątpliwości interpretacyjnych oraz zapobiegania pomyłkom księgowym, wprowadziliśmy nową podpowiedź systemową na formatce zapisu księgowego. Zmiana dotyczy zakładki [Waluty] i widoku dodawania/edycji dekretu.

Nowy komunikat ma za zadanie przypomnieć operatorowi o rzeczywistym, wycenowym charakterze tej operacji w kontekście kont walutowych.

Po zaznaczeniu parametru Kwota tylko w walucie systemowej i najechaniu kursorem na pole wprowadzania kwoty, system automatycznie wyświetli dymek podpowiedzi (tooltip) o następującej treści:

“Wpisana kwota w PLN nie jest niezależnym księgowaniem w złotówkach. Zapis ten jest ściśle powiązany z walutą obcą wybraną obok i służy wyłącznie do zaktualizowania jej wyceny.”

Korzyści dla użytkownika:

W jaki sposób wprowadzić zapis tylko w PLN dla „starych” typów kont walutowych, który nie stanowi wyceny?

W przypadku pracy na tzw. „starych” typach kont walutowych (gdzie ewidencja walutowa prowadzona jest w oparciu o dwa konta, w tym konto pozabilansowe, walutowe), może pojawić się konieczność dodania zapisu wyłącznie w walucie systemowej (PLN). Jeżeli zapis taki ma być całkowicie niezależny od waluty obcej i w przeciwieństwie do standardowych mechanizmów wyceny, nie ma korygować wartości salda walutowego poprawna ścieżka rejestracji powinna wyglądać następująco:

1. Otwieramy formularz dodawania lub edycji zapisu księgowego (dekretu)
2. Przechodzimy na zakładkę [Waluty]
3. W polu przeznaczonym na wskazanie konta pozabilansowego (walutowego) nie wybieramy z listy żadnego konta.

Pozostawienie pustego pola z kontem pozabilansowym jest sygnałem dla systemu, że dana kwota nie ma powiązania z żadną walutą obcą. Dzięki temu mechanizm wyceny zostaje pominięty, a system traktuje tę operację jako zwykły, „czysty” zapis w PLN, który nie wpłynie w żaden sposób na ewidencję walutową.

Zmiany w imporcie Bilansu Otwarcia

Stan do wersji Comarch ERP XL 2025.0 włącznie

W wersji 2025.0 oraz w wersjach starszych, podczas przenoszenia Bilansu Zamknięcia (BZ) na Bilans Otwarcia (BO), nie funkcjonowały mechanizmy powiązań między pozycjami BO na kontach złotówkowych a odpowiadającymi im pozycjami na walutowych kontach pozabilansowych. W efekcie tego braku pozycje dla bilansu otwarcia były tworzone rozdzielnie – generowano je osobno dla wartości w PLN oraz osobno dla walut obcych.

Nowa funkcjonalność od wersji Comarch ERP XL 2025.1

Począwszy od wersji 2025.1 wprowadzono mechanizm automatycznego wiązania tych pozycji. Należy jednak pamiętać o pewnych ograniczeniach wynikających ze struktury danych historycznych.

Obsługa powiązań w relacji jeden do jednego (1:1)

W przypadku powiązania konta złotówkowego (np. konta należącego do zespołu „2”) z pozabilansowym kontem walutowym (np. z zespołu „9”) w relacji 1:1, system przyjmuje założenie, że kwota w złotówkach w 100% wycenia kwotę zaewidencjonowaną w walucie obcej.

Przykład działania: Konto 203 (PLN) jest powiązane z kontem 903 (EUR) w prostej relacji 1:1.

Stary mechanizm (wersja 2025.0): Przeniesienie BZ na BO skutkowało powstaniem dwóch niezależnych od siebie pozycji – na koncie 203 generowano kwotę 4000 PLN, a na koncie 903 kwotę 1000 EUR.

Nowy mechanizm (wersja 2025.1): Jeżeli BO zostanie przeniesiony nową wersją systemu, w miejsce dwóch oddzielnych pozycji powstanie 1 zintegrowana pozycja. System prawidłowo zaimportuje 1000 EUR oraz 4000 PLN, a następnie na podstawie tych dwóch kwot automatycznie wyliczy kurs.

Uwaga

Jeżeli na koncie 203, oprócz zapisów w PLN ściśle powiązanych z walutą obcą (np. EUR), rejestrowano również historycznie zapisy z użyciem „zerowego” kursu (wyłącznie w złotówkach), wartości te zostaną również ujęte przez system w całkowitej wycenie waluty obcej podczas procesu przenoszenia bilansu.

Analiza przypadku

Prześledźmy zachowanie systemu na przykładzie konta rozrachunkowego 203-K1, które jest ściśle powiązane z walutowym kontem pozabilansowym 903-K1. Zobaczmy, co się stanie, gdy na takim koncie wymieszamy zapisy walutowe z zapisami wyłącznie złotówkowymi.

Załóżmy, że na koncie 203-K1 zarejestrowano standardowe zapisy powiązane z walutowym kontem 903-K1, ale dodano do nich jeden, niepowiązany zapis wyłącznie w PLN na kwotę 4 600,00 PLN.

W rezultacie obroty po stronie bilansowej oraz pozabilansowej układają się następująco:

Łatwo zauważyć, że różnica po stronie Dt (między kontem bilansowym a pozabilansowym) wynosi równe 4 600,00 PLN. Wynika ona bezpośrednio z tego jednego, „czysto złotówkowego” zapisu, który nie miał swojego odpowiednika w walucie obcej.

Stan na koniec roku i problem w Bilansie Otwarcia

Z powyższych obrotów wynikają następujące salda końcowe:

Problem ujawnia się na przełomie roku, podczas przenoszenia Bilansu Zamknięcia (BZ) na Bilans Otwarcia (BO). System, widząc te wartości, przypisze całe saldo złotówkowe do pozostałego salda walutowego.

W efekcie na nowym dokumencie BOA, kwota 250,00 EUR zostanie błędnie wyceniona na aż 5 600,00 PLN, zamiast na poprawne 4 000,00 PLN.

Rekomendacja

Biorąc pod uwagę ryzyko zniekształcenia wyceny na przełomie roku, zdecydowanie odradzamy księgowanie operacji wyłącznie w złotówkach (PLN) na tradycyjnych kontach walutowych, które wymagają stosowania kont pozabilansowych.

Jeżeli specyfika Twojej firmy wymaga rejestrowania na jednym koncie rozrachunkowym zarówno transakcji walutowych, jak i czysto złotówkowych, najbezpieczniejszym i w pełni zautomatyzowanym rozwiązaniem jest przejście na nowy typ konta wielowalutowego. Eliminuje ono całkowicie problem niespójności sald i gwarantuje poprawne wyliczenie Bilansu Otwarcia.

Ograniczenia dla relacji jeden do wielu (1:n)

Nowy mechanizm integracji nie ma zastosowania dla Bilansów Otwarcia generowanych na podstawie BZ z wersji starszych niż 2025.1, w przypadku kont powiązanych w relacji jeden do wielu (1:n).

Przyklad

Wyobraźmy sobie konto bilansowe z zespołu „2”, które powiązane jest z dwoma osobnymi kontami pozabilansowymi z zespołu „9” – jednym prowadzonym w EUR i drugim prowadzonym w USD.

Skutek: W systemie brakuje precyzyjnych informacji pozwalających na jednoznaczne określenie, w jakiej konkretnej wartości złotowej (PLN) wyceniana jest dana kwota cząstkowa zewidencjonowana w walucie obcej.

Zmiany w wersji Comarch ERP XL 2026.0 względem wersji 2025.1

W bazie danych, w tabeli CDN.Dekrety, kwoty zapisywane są jednocześnie w walucie transakcji (walucie konta) oraz w walucie systemowej. W przypadku kont złotówkowych powiązanych z walutowymi kontami pozabilansowymi, walutą konta i transakcji jest zawsze PLN. Do tej pory generowane przez system różnice kursowe wpływały wyłącznie na walutę systemową, a nie na walutę transakcji. Z tego powodu podczas przenoszenia BZ na BO, nawet jeśli saldo na koncie wynosiło dokładnie 0,00, system automatycznie generował techniczne zapisy korygujące (in plus oraz in minus), odpowiadające wartości tych różnic kursowych.

Dzięki zmianom wprowadzonym w wersji Comarch ERP XL 2026.0, w przypadku pełnego rozliczenia zapisów na kontach powiązanych, system nie tworzy już korygujących zapisów technicznych z tytułu różnic kursowych (RK in plus oraz RK in minus).

Wyjątek – zachowanie przy relacji jeden do wielu (1:n)

Zapisy techniczne nadal będą powstawać w przypadku powiązań w relacji 1:n. Wynika to ze wspomnianego wcześniej braku szczegółowych powiązań między historycznymi zapisami na koncie złotówkowym a zapisami na poszczególnych kontach walutowych. Sytuacja ta jest bezpośrednim skutkiem zaszłości historycznych powstałych przy migracji ze starszych wersji systemu.

Analiza przypadku dla relacji 1:n w praktyce

Prześledźmy zachowanie systemu, na przykładzie konta 204-K2 powiązanego z dwoma kontami pozabilansowymi: 904EUR-K2 i 904USD-K2.

Stan w BO 2025 (przeniesiony starą wersją):

Zapisy bieżące wprowadzone w 2025 r.:

Przeniesienie BZ 2025 na BO 2026:

System w tym przypadku przeniesie na BO 2026 następujące dane:

Analiza kolejnego przypadku: Zapis bieżący wprowadzony po przeciwnej stronie (Ct)

Przeanalizujmy modyfikację poprzedniego scenariusza. Założenia pozostają podobne z tą różnicą, że nowy zapis bieżący w 2025 roku został wprowadzony po przeciwnej stronie konta (Ma / Ct).

Zdarzenia w roku obrachunkowym 2025:

Przeniesienie BZ 2025 na BO 2026:

Podczas generowania Bilansu Otwarcia system dąży do skonsolidowania pozycji, zachowując zgodność salda i walut. W tym przypadku przeniesie na BO 2026 następujące dane:

Rekomendacja

Aby zapewnić poprawną wycenę sald początkowych na kontach walutowych (np. w EUR i USD), zalecamy jednorazową, ręczną korektę dokumentu Bilansu Otwarcia (BOA/BOAK). Uporządkowanie tych danych na tym etapie zagwarantuje bezproblemowe i w pełni zautomatyzowane przenoszenie bilansów na kolejne lata obrotowe w przyszłości.

Dla przypomnienia, w naszym wcześniejszym przykładzie: saldo 1000 EUR odpowiada wartości 4000 PLN, natomiast 1000 USD to 3900 PLN.

Poniżej instrukcja, jak krok po kroku poprawnie skorygować walutowy Bilans Otwarcia:

Krok 1. Cofnięcie dokumentu do bufora

Otwieramy zatwierdzony dokument Bilansu Otwarcia. W sekcji Status zaznaczamy opcję Bufor i zapisujemy zmiany (ikona dyskietki). Następnie ponownie otwieramy ten sam dokument do edycji, aby móc nanieść odpowiednie kwoty.

Krok 2. Edycja pozycji Bilansu Otwarcia

Przechodzimy na zakładkę [Pozycje]. Odszukujemy na liście i otwieramy do edycji (dwukrotnym kliknięciem lub ikoną lupy) tę pozycję, która wymaga korekty wyceny.

W omawianym przykładzie będzie to zapis dotyczący salda na koncie rozrachunkowym 204-K2 oraz powiązane z nim zapisy na walutowych kontach pozabilansowych.

Krok. 3 Korekta subpozycji

Na formularzu szczegółów wybranej pozycji BO (np. dla konta 204-K2) znajdziemy rozbicie na subpozycje.

Należy je zmodyfikować według poniższego schematu:

Krok 4. Weryfikacja salda końcowego (Per saldo)

W efekcie wprowadzonych zmian, zamiast trzech niespójnych rozbić, pozostaną tylko dwie prawidłowe pozycje. Będą one stanowić czystą wycenę waluty obcej w walucie systemowej.

Upewniamy się, że po usunięciu i modyfikacji subpozycji, całkowita wartość w kolumnie Per saldo dla modyfikowanego konta pozostała dokładnie taka sama jak przed korektą.

Uwaga

Z uwagi na wspomniany brak powiązań dla kont w relacji jeden do wielu (1:n), zablokowano możliwość konwersji starych typów kont walutowych na konta wielowalutowe. Funkcja ta została pozostawiona wyłącznie dla kont powiązanych w relacji 1:1. 

Wpływ na Zestawienie Obrotów i Sald (ZOIS)

Podsumowując, z uwagi na zaszłości historyczne i brak wyceny kwot w walucie obcej walutą systemową (przy relacji 1:n), nowa filozofia systemu skutkuje powstawaniem zapisów technicznych. Co bardzo ważne: zapisy te nie zaburzają w żaden sposób poprawności sald wykazywanych na Zestawieniu Obrotów i Sald. Wykazywane na nim kwoty bilansu otwarcia na kontach złotówkowych oraz pozabilansowych walutowych pozostają poprawne.

Dostosowanie kanału webservice do ISO 20022

Dostosowanie PKO BP

W związku z przechodzeniem poszczególnych instytucji finansowych na komunikację w standardzie ISO 20022, modyfikacji ulegają dotychczasowe formaty obsługi przelewów zagranicznych oraz SEPA. W wersji Comarch ERP XL 2026.0 zmiany w tym zakresie zostały wprowadzone dla następujących banków :

Zmiany w strukturze adresowej

W ramach tej zmiany wprowadzono nowy sposób przekazywania adresów odbiorców dla przelewów zagranicznych i SEPA: Adres jest automatycznie dzielony na odrębne pola systemowe (np. Kraj, Miasto, Ulica). Aby dane były poprawnie identyfikowane i wysyłane, wymagane jest uzupełnienie szczegółowego adresu na karcie kontrahenta na zakładce [Webservice].

Dodatkowe funkcjonalności w kanale Webservice

Dodatkowy rachunek do opłat

W przypadku realizacji przelewów zagranicznych wprowadzono możliwość wskazania dedykowanego rachunku bankowego, z którego bank pobiera prowizje oraz opłaty za realizację transakcji. Funkcja ta pozwala na odseparowanie kosztów operacyjnych od rachunku obciążanego kwotą główną przelewu.

Funkcjonalność została wdrożona dla banków:

Zmiana daty ujęcia zapisu

W module Administrator w konfiguracji formatu wymiany danych, udostępniono opcję modyfikacji typu daty, według której operacja bankowa jest ujmowana w systemie ERP. Bank w historii operacji przekazuje zróżnicowane parametry czasowe:

Wskazane daty mogą się różnić m.in. w przypadku transakcji realizowanych w dni wolne od pracy lub przy płatnościach kartowych. System Comarch ERP XL domyślnie przyjmuje jedną z tych wartości, jednak użytkownik ma możliwość ręcznej zmiany tego zachowania w konfiguracji.

Funkcjonalność została wdrożona dla banków:

Dodatkowa weryfikacja białej listy

W celu podniesienia poziomu bezpieczeństwa transakcji system umożliwia zlecenie bankowi dodatkowej weryfikacji rachunku odbiorcy w wykazie podatników VAT (Biała Lista).

W module Administrator, w oknie konfiguracji formatu wymiany danych, udostępniono parametr Bank dodatkowo weryfikuje przelewy pow. 15000 zł z białą listą VAT. Po zaznaczeniu tej opcji, podczas generowania przelewów o wysokiej wartości, do banku przesyłany jest również numer NIP kontrahenta w celu przeprowadzenia automatycznej weryfikacji po stronie instytucji finansowej.

Funkcjonalność została wdrożona dla banków:

Kod celu zlecenia

Kod celu zlecenia służy do jednoznacznej klasyfikacji charakteru biznesowego płatności międzynarodowej. Umożliwia to bankom oraz organom regulacyjnym automatyczną kontrolę dewizową, przeciwdziałanie praniu pieniędzy (AML) oraz sprawne procesowanie transakcji bez ryzyka ich zablokowania.

Wskazany kod można definiować bezpośrednio na poziomie paczki przelewów przy użyciu funkcji edit-in-place w kolumnie Kod celu zlecenia. Kolumna ta jest domyślnie ukryta – aby była widoczna, należy dodać ją do widoku za pomocą opcji: Formaty listy/ Ustawienia formatu / Zmień.

Wskazówka

W przypadku konieczności jednoczesnego wskazania głównej kategorii zlecenia oraz szczegółowej podkategorii, obie te wartości należy rozdzielić znakiem ukośnika („/”).

Funkcjonalność została wdrożona dla banków:

Zewnętrzny parser wyciągów bankowych

W systemie Comarch ERP XL wprowadzono zaawansowany mechanizm zewnętrznego parsera plików wyciągów bankowych. Architektura tego rozwiązania opiera się na całkowitym odseparowaniu procesów odczytu oraz interpretacji danych od rdzenia systemu. Dzięki temu użytkownicy mogą elastycznie przetwarzać zarówno specyficzne pliki tekstowe, jak i ustrukturyzowane formaty XML oraz JSON.

Konfiguracja formatu

Podstawowa konfiguracja narzędzia realizowana jest w module Administrator w oknie formatów przelewów (ścieżka dostępu: Lista firm / Formaty przelewów), gdzie należy dodać nowy format i wskazać opcję Własny parser pliku wyciągu bankowego.

Definiowanie parametrów uruchomieniowych

W oknie edycji formatu użytkownik definiuje kluczowe parametry techniczne:

Dodatkowo system umożliwia aktywację parametru przekazującego identyfikator rejestru bankowego do programu zewnętrznego. Pozwala to na automatyczne różnicowanie logiki przetwarzania operacji w zależności od kontekstu źródłowego konta bankowego.

Wskazówka

Szczegółowe instrukcje dotyczące parametryzacji, przykłady kodu źródłowego oraz opisy logiki mapowania zostały zamieszczone w dedykowanym biuletynie technicznym. Wraz z dokumentacją udostępniono również agenta generatywnej AI, który wspiera i znacząco skraca czas przygotowania własnych skryptów parsujących.

Inne zmiany

Nowe okno weryfikacji kontrahenta w VAT

Podczas weryfikacji kontrahenta na Białej Liście Ministerstwa Finansów z uwzględnieniem daty historycznej, system pobiera bieżący status podatnika VAT oraz zestaw danych umożliwiających jego weryfikację wsteczną.

W celu precyzyjnego wskazania, że dane pochodzą bezpośrednio z bazy Ministerstwa Finansów, wprowadzono następujące zmiany w systemie Comarch ERP XL:

Rebranding Santander na Erste

W związku z zakończeniem procesu przejęcia Santander Bank Polska S.A. przez Erste Group oraz oficjalnym rebrandingiem instytucji, w systemie Comarch ERP XL wprowadzono następujące zmiany:

Uwaga

Wprowadzone modyfikacje systemowe są w pełni automatyczne i nie wymagają żadnych działań ze strony Użytkownika.

Aktualizacja wysokości stóp procentowych dla odsetek

W konfiguracji, na zakładce [Odsetki] zaktualizowano wysokość stóp procentowych dla odsetek za opóźnienie w transakcjach handlowych, które od 1 lipca 2026 r. wynoszą 13,75%.

Wspólne

Obsługa nowego sposobu licencjonowania w systemie Comarch ERP XL – model subskrypcyjny

W wersji 2026.0 systemu Comarch ERP XL wdrożono obsługę nowego, subskrypcyjnego modelu licencjonowania. System nie pozwala na łączenie modelu dotychczasowego (on-prem) oraz subskrypcyjnego w jednej instalacji. Szczegóły dotyczące pakietów subskrypcyjnych opisane są w cennikach Comarch ERP XL w subskrypcji, które znajdują się m.in. na Indywidualnych Stronach dla Klientów.

Pakiety modułów subskrypcyjnych i zasady dostępu

W ramach nowego modelu wprowadzono nowe moduły stanowiskowe (w wariantach Basic oraz Pro):

Reguły łączenia modułów Basic i Pro

W jednej instalacji powinno być co najmniej tyle modułów Basic co modułów Pro tej samej kategorii (np. 6 Sprzedaż Pro, to 6 lub więcej Sprzedaż Basic). Z perspektywy pojedynczego operatora możliwe jest jednak posiadanie wyłącznie pakietu Pro (pakiet Pro nie zawiera pakietu Basic).

Mapowanie modułów (migracja modułów)

W związku z dodaniem nowych licencji do modelu subskrypcyjnego, zostały zmapowane niżej wymienione dotychczasowe moduły na nowe. Szczególnej modyfikacji uległ obszar Sprzedaży i Zamówień, w którym wprowadzono wyraźny podział na procesy sprzedażowe i zakupowe. Szczegóły podziału (jakie dokumenty w których modułach opisane są w dokumencie „Zasady korzystania z modułów Comarch ERP XL w modelu subskrypcyjnym”, który znajduje się m.in. na Indywidualnych stronach dla Klientów.

Dotychczasowe moduły		Nowe moduły subskrypcyjne
Produkcja Kompletacja	->	Produkcja Basic
Konfigurator produktu Kontrola jakości	->	Produkcja Pro
Księgowość E- sprawozdania	->	Finanse Basic
Umowy Środki trwałe	->	Finanse Pro
Sprzedaż, Zamówienia (tylko procesy sprzedażowe)	->	Sprzedaż Basic
ECOD / EDI (odbiorcy) Lojalność Drukarki fiskalne	->	Sprzedaż Pro
Sprzedaż, Zamówienia (tylko procesy zakupowe)	->	Zakupy Basic
Import ECOD / EDI (dostawcy)	->	Zakupy Pro
Brak		Odczyt

Moduły nieposiadające specyficznego mapowania (np. Administracja, Serwis, CRM) przenoszone są w relacji 1:1.

Kreator instalacji

Na etapie autoryzacji oprogramowania rozszerzono formularz akceptacji o Regulamin subskrypcji. Zmodyfikowano treści informacyjne oraz etykiety wyboru, aby odnosiły się równolegle do „Warunków korzystania i gwarancji” (model on-prem) oraz „Regulaminu subskrypcji” (model subskrypcyjny).

Zmiany w interfejsie użytkownika: Karta operatora, Wzorzec operatora, Edycja seryjna operatorów

Na karcie oraz wzorcu operatora, zakładkach [Parametry/Uprawnienia] zaimplementowano mechanizm warunkowego wyświetlania list dostępowych do modułów, zależny od typu użytkownika:

Automatyzacja uprawnień: przy pierwszym uruchomieniu po zmianie modelu na subskrypcyjny, system automatycznie zaznacza odpowiednie moduły subskrypcyjne na podstawie historycznych uprawnień (zgodnie z zasadą mapowania).

Weryfikacja licencji i komunikaty systemowe

System weryfikuje odpowiednie uprawnienia podczas wywoływania każdej procedury. Zmodyfikowano okna ostrzeżeń o braku licencji (zakładka [Zaawansowane]):

Dedykowany moduł „Odczyt”

Wprowadzono nowy moduł subskrypcyjny, którego celem jest udostępnienie w trybie wyłącznie informacyjnym:

[sPrint] Możliwość wyboru formatu wydruku (zwykły wydruk, Excel, Word)

Dla wydruków Comarch Sprint w menu rozwijanym przycisku „Drukuj” zaimplementowano nową sekcję o nazwie „Eksport do pliku na dysk”. Sekcja ta została umieszczona w dolnej części menu rozwijanego, bezpośrednio pod pozycją „Inna drukarka”:

Rozwinięcie wskazanej sekcji udostępnia okno wyboru formatu docelowego:

Wybór określonego formatu skutkuje automatycznym wywołaniem systemowego okna dialogowego „ Zapisywanie jako”.

Nazwa pliku docelowego jest podpowiadana w sposób automatyczny (zgodnie z nazwą wybranego wydruku) wraz z przypisaniem właściwego rozszerzenia pliku.

Po poprawnym zakończeniu operacji zapisu system wyświetla komunikat autoryzacyjny: „Czy otworzyć wyeksportowany plik?”. Pozwala to na natychmiastowe uruchomienie pliku w zewnętrznym arkuszu kalkulacyjnym lub edytorze tekstu w celu weryfikacji danych:

Współpraca z Comarch Mobile Sprzedaż

Zarządzanie parametrem „Wysyłaj do KSeF” z poziomu Comarch Mobile

Od teraz użytkownicy mają pełną kontrolę nad parametrem decydującym o wysyłce dokumentów do KSeF bezpośrednio z poziomu aplikacji Comarch Mobile, zarówno dla nowych, jak i obecnych kontrahentów.

Wystawianie e-Faktur w trybie awaryjnym (Offline KSeF)

Aby zapewnić ciągłość sprzedaży wprowadzono mechanizm obsługi e-Faktur w trybie awaryjnym. Funkcjonalność ta pozwala na bezproblemowe wystawianie dokumentów w systemie Comarch Mobile Sprzedaż w przypadku awarii po stronie Ministerstwa Finansów (KSeF) lub chwilowego braku połączenia z Internetem.

Tryb awaryjny w systemie Comarch Mobile Sprzedaż

Gdy system napotka problemy z komunikacją z KSeF, faktura VAT jest rejestrowana w specjalnym trybie offline. W ramach tego procesu system Mobile Sprzedaż automatycznie:

Synchronizacja dokumentów wystawianych podczas awarii

1. Przekazanie informacji o konieczności wysyłki faktury do KSeF z poziomu aplikacji ERP XL: Dokument trafia do systemu XL z zaznaczonym parametrem Wyślij do KSeF. Oznacza to, że po ustąpieniu awarii, to z poziomu Comarch ERP XL należy dostarczyć dokument do KSeF.
2. Oznaczenie trybu Offline: Informacja o tym, że faktura powstała w czasie awarii, jest przekazywana do systemu XL i odpowiednio ewidencjonowana na dokumencie. Dzięki temu zachowana jest pełna spójność informacji o statusie dokumentu pomiędzy systemami.
3. Przekazywanie załączników (plików XML): Faktura przygotowana w Comarch Mobile w trybie offline jest przesyłana do systemu XL wraz z wygenerowanym plikiem XML faktury ustrukturyzowanej w formie załącznika. Dzięki temu plik źródłowy dokumentu jest od razu zarchiwizowany i dostępny również z poziomu systemu ERP. Podczas wysyłki faktury do KSeF z poziomu XLa system pobiera plik wygenerowany w aplikacji mobilnej i przekazuje bezpośrednio do portalu KSeF.

Kontrola i rozliczanie limitu licencji KSeF

Wprowadzono zautomatyzowane mechanizmy weryfikacji oraz rozliczania (tzw. „spalania”) licencji Comarch KSeF na styku aplikacji Mobile Sprzedaż i Comarch ERP XL.

Weryfikacja licencji w Comarch Mobile Sprzedaż

Aplikacja Mobile Sprzedaż sprawdza podczas wysyłania faktur do KSeF czy firma posiada aktywną licencję KSeF i dostępny limit w pakiecie.

Zmniejszanie pakietu licencji (spalanie pakietu)

Kluczowym momentem zliczania zużytego limitu jest synchronizacja dokumentów z Mobile Sprzedaż do systemu ERP XL. System analizuje każdy dokument i podejmuje decyzję według jasnych reguł:

Współpraca z Comarch e-Sklep

Obsługa promocji limitowanych

W poprzednich wersjach Comarch ERP XL, w ramach rozwoju modułu rabatowego wprowadzono dodatkową parametryzację dla promocji zwykłych limitowanych. Umożliwia ona zdefiniowanie indywidualnego limitu ilościowego dla poszczególnych kontrahentów w obrębie limitu ogólnego (dla dokumentów rozchodowych). Aktualnie funkcjonalność ta została zintegrowana Comarch e-Sklep.

Synchronizacja i przesyłanie danych.

Współpraca systemu ERP z platformą Comarch e-Sklep w zakresie nowych limitów obejmuje:

Kontrola limitów podczas składania zamówień w Comarch e-Sklep

Kontrola limitów odbywa się automatycznie w e-Sklepie na etapie wystawiania zamówień przez klientów. Algorytm weryfikacji przebiega następująco:

Naliczenie promocji: Promocja zostaje naliczona na zamówieniu w e-Sklepie tylko w przypadku, gdy oba limity (kontrahenta oraz ogólny) posiadają wolne pule.

Aktualizacja limitów w czasie rzeczywistym: pomiędzy kolejnymi procesami synchronizacji z systemem ERP, platforma samodzielnie koryguje poziom wykorzystania limitów na podstawie zamówień realizowanych bezpośrednio w e-Sklepie.

Uwaga

W Konfiguracji systemu Comarch ERP XL należy zaznaczyć parametr Rejestruj strukturę udzielonego rabatu w lokalizacji: System / Konfiguracja / Sprzedaż / Rabaty i promocje. Bez włączenia tej opcji prawidłowa kontrola limitów w Comarch e-Sklep nie będzie możliwa.

Współpraca z Comarch POS

Obsługa dokumentów kaucyjnych WKA i PKA wystawianych niezależnie od faktur i paragonów

Umożliwiono wystawianie w Comarch POS dokumentów WKA oraz PKA niepowiązanych z dokumentem handlowym. Dokumenty te służą do rejestrowania ruchów opakowaniami w obrębie sklepu (wydawanie i przyjmowanie samych opakowań kaucjonowanych).

Obsługa zwrotów opakowań

W szczególności dokumenty PKA mogą być wykorzystywane do przyjmowania zwrotów opakowań od klientów sklepu. Dla dokumentów tych naliczana jest płatność gotówkowa w celu zwrotu środków klientowi za przyjęte opakowania kaucjonowane. Dodatkowo możliwy jest wydruk potwierdzenia zwrotu kaucji na urządzeniu fiskalnym w formie dokumentu niefiskalnego.

Do dokumentów WKA i PKA możliwe jest również wystawianie korekt WKK i PKK.

Konfiguracja

W kreatorze oddziału Comarch POS dodano w Kroku 1. możliwość zaznaczenia opcji PKA – wydanie kaucji, dzięki czemu w systemie POS możliwe będzie generowanie tych dokumentów.

Użytkownicy, którzy pracują już w systemie Comarch POS i będą chcieli prowadzić przyjęcia zwrotów towarów kaucjonowanych za pomocą PKA muszą zaznaczyć opcję Wystawianie i edycja na definicji dokumentu PKA – Przyjęcie towarów kaucjonowanych w centrum powiązanym z oddziałem Comarch POS. Opcja ta dostępna jest w module Administrator.

Uwaga

Do obsługi ręcznych dokumentów PKA i WKA konieczne jest zaznaczenie parametru Obsługa systemu kaucyjnego na oknie konfiguracji oddziału Comarch POS.

Wydruki

Dla dokumentów WKA, PKA, WKK i WKA przygotowano standardowe wydruki, które zostały podpięte pod stanowiska POS. Wydruki domyślne mają zaznaczoną opcję Wysyłaj do POS oraz ilość kopii 1.

Uprawnienia

Obsłużono synchronizację uprawnień operatorów do dokumentów kaucyjnych na podstawie zakazów definiowanych na wzorcu operatora. Aby zablokować operatorowi możliwości, należy dodać zakazy dla operacji: Dodawanie, Kasowanie, Zmiana, Podgląd dla poszczególnych dokumentów PKA, WKA, PKK, WKK.

Przesyłanie dokumentów pomiędzy stanowiskami – wyszukiwanie globalne

W sytuacji, gdy klient zgłasza korektę lub potrzebę weryfikacji dokumentu kaucyjnego wystawionego na innym stanowisku możliwe jest pobranie dokumentu WKA czy PKA i jego skorygowanie bądź wydrukowanie.

Obsługa braków (automatyczne dokumenty PW podczas importu dokumentów do XLa)

Dla dokumentów WKA oraz PKK obsłużono generowanie PW w sytuacji gdy na magazynie nie będzie wystarczającej ilości pozycji kaucyjnych. Działanie to jest zależne od parametru ustawianego na oddziale Comarch POS – Generuj PW na brakujące towary.

Wydruki potwierdzenia sprzedaży

W systemie dodano obsługę nowych wydruków dla faktur przesyłanych do systemu KSeF. Do drzewa wydruków na stanowisku POS dodano następujące domyślne wydruki:

Wydruki domyślne mają zaznaczoną opcję Wysyłaj do POS oraz ilość kopii 1.

Obsługa w Comarch POS

Wydruki Potwierdzenie transakcji sprzedaży oraz Potwierdzenie transakcji sprzedaży – korekta to mechanizm zabezpieczający (tzw. tryb offline/awaryjny KSeF). Są one drukowane dla klienta na stanowisku kasowym w sytuacji, gdy natychmiastowa wysyłka faktury lub korekty do KSeF kończy się niepowodzeniem lub nie jest w danej chwili możliwa.

Obsługa kaucji we współpracy z Comarch webPOS

W ramach synchronizacji z systemem Comarch webPOS obsłużono przesyłanie kaucji, definicji schematów kaucji oraz wystawianie dokumentów WKA powiązanych z paragonem.

Zasady działania analogiczne jak podczas współpracy z Comarch POS.

Nowości w ramach obsługi dokumentów KSeF

Wydruki potwierdzenia sprzedaży

W systemie dodano obsługę nowych wydruków dla faktur przesyłanych do systemu KSeF. Do drzewa wydruków na stanowisku POS dodano następujące domyślne wydruki:

Wydruki domyślne mają zaznaczoną opcję Wysyłaj do POS oraz ilość kopii 1.

Obsługa w Comarch POS

Wydruki Potwierdzenie transakcji sprzedaży oraz Potwierdzenie transakcji sprzedaży – korekta to mechanizm zabezpieczający (tzw. tryb offline/awaryjny KSeF). Są one drukowane dla klienta na stanowisku kasowym w sytuacji, gdy natychmiastowa wysyłka faktury lub korekty do KSeF kończy się niepowodzeniem lub nie jest w danej chwili możliwa.

Przekazywanie linku weryfikacyjnego KSeF dla faktur wystawionych w Comarch POS

Link weryfikacyjny wygenerowany po stronie Comarch POS obsługiwany jest w następujących sytuacjach:

Obsługa odbiorcy (Podmiotu 3) z identyfikatorem wewnętrznym KSeF

System umożliwia obsługę danych odbiorcy (Podmiotu 3 / Rola 2), który posiada nadany indywidualny identyfikator wewnętrzny KSeF (składający się z numeru NIP oraz 5-cyfrowego numeru, np. 5493442032-578053).

Przesyłanie pola Identyfikatora wewnętrznego zapisanego na adresie kontrahenta: Identyfikator wewnętrzny KSeF jest wysyłany i zapisywany na adresach kontrahentów w Comarch POS. Nie jest jednak widoczny na interfejsie POS.

Przesyłanie parametru konfiguracyjnego dotyczącego przesyłania danych odbiorcy do KSeF: Poniższe ustawienia przekazywane są do Comarch POS i w oparciu o wybrane parametry oraz zapisany identyfikator wewnętrzny KSeF, ustalane są dane odbiorcy na fakturach KSeF.

Aktualizacja ustawienia parametru kontrahenta Wysyłaj dokumenty do do KSeF

Obsłużono aktualizację parametru Wysyłaj dokumenty do do KSeF po zmianie ustawienia na karcie kontrahenta w POS.

Parametr na oknie Klasy atrybutu, czy dany atrybut ma trafiać do bazy Comarch POS

Na oknie Klasy atrybutu dodano parametr do zaznaczenia [v] POS, określający czy dany atrybut ma trafiać do bazy sklepu Comarch POS. W systemie Comarch ERP XL możliwe jest wprowadzanie różnorodnych atrybutów, ale nie wszystkie powinny pojawiać się w sklepach POS, dlatego dodano możliwość decydowania o tym na poziomie klasy atrybutu.

Aktualnie ustawienie parametru nie jest respektowane podczas wysyłki atrybutów do POS, aby możliwe było odpowiednie skonfigurowanie atrybutów. Zmiany w synchronizacji atrybutów pojawią się w kolejnej wersji Comarch ERP XL.

Licencjonowanie KSeF (klucz)

Uwaga

W przypadku współpracy z Comarch POS nie należy korzystać z połączenia szyfrowanego po http. Po włączeniu parametru jak niżej nie będzie możliwe wysyłanie faktur do KSeF z poziomu Comarch POS.

Rabaty i promocje na formę i termin płatności

W współpracy z Comarch POS obsłużono promocje i rabaty definiowane na określoną formę i termin płatności. Przypisanie formy płatności do promocji może dotyczyć zarówno zwykłych rabatów jak i promocji pakietowych.

Wybór formy płatności na definicji promocji i rabatów

Formę płatności, dla której będzie obowiązywał rabat ustala się na zakładce [Formy płatności] na oknie promocji. Dla promocji wysyłanych do POS należy przypisać tylko te formy, które przesyłane są do danego sklepu POS.

Ustalenie ilości dni (termin maksymalny)

Dla każdej formy płatności można ustalić dodatkowo ustalić maksymalny termin, dla którego będzie obowiązywała promocja. Ustalenie wartości 0 lub zaznaczenie opcji Bez ograniczeń pozwoli na stosowanie promocji bez względu na ustalony termin płatności.

Uwaga

W ramach integracji z Comarch POS przesyłany jest wyłącznie typ determinantu oparty na liczbie dni. Obsługa terminów określonych konkretną datą nie jest obsługiwana.

Nowe parametry w konfiguracji oddziału POS

W związku z obsługą promocji na formę i termin płatności, w systemie Comarch ERP XL wprowadzone zostały dwa nowe parametry. Ustawienia te dostępne są podczas kreacji oddziału Comarch POS oraz na zakładce [Parametry] oddziału Comarch POS.

Pełni funkcję zabezpieczającą. Jeśli rabat został naliczony na podstawie zadeklarowanej na dokumencie formy płatności (np. przelew), a w oknie finalizacji zapłaty kasjer wybierze inną (np. gotówkę), system zablokuje błąd i wyświetli ostrzeżenie o niespełnieniu warunków promocji. Chroni to przed udzieleniem nienależnej zniżki.

Odblokowuje widoczność tych pól bezpośrednio na głównym ekranie wystawiania dokumentu. Dzięki temu kasjer może ustawić warunki płatności z góry (np. na prośbę klienta), co pozwala systemowi POS na natychmiastowe naliczenie i pokazanie rabatu już w trakcie kompletowania koszyka, przed przejściem do zapłaty.

Działanie promocji na stanowisku sprzedaży w Comarch POS