Podręcznik: Konwerter Comarch e-Faktura

Spis treści

Wprowadzenie

Informacje ogólne

Konwerter Comarch e-Faktura to narzędzie do wysyłania faktur elektronicznych za pośrednictwem standardowych formatów wymiany danych. Obecnie obsługiwane są następujące formaty e-faktur:

  • Formaty ZUGFeRD Niemieckiego Forum Elektronicznego Fakturowania (FeRD) (więcej informacji na temat formatu można znaleźć się na stronie ferd-net.de)
    • ZUGFeRD 1.0
    • ZUGFeRD 2.1 (Factur-x / EN16931)
  • Formaty FatturaPA dla e-fakturowania we Włoszech (więcej informacji na temat formatów można znaleźć na stronie https://www.fatturapa.gov.it/it/index.html)
    • FatturaPA 1.2
    • FatturaPA 1.3
  • Formaty faktur
    • XRechnung 1.2.2 (Standard)
    • XRechnung 2.0.0 (Standard)
    • Kolejne wersje faktury XRerchnung zgodnie z sekcją Okres ważności na stronie https://xeinkauf.de/xrechnung/ (dostępność w Comarch e-Faktura można znaleźć w informacjach o wersji)
  • Format KSeF FA(2) dla e-faktury w Polsce (więcej informacji można znaleźć na stronie https://www.gov.pl/web/kas/krajowy-system-e-faktur.) KSeF wymaga również odpowiedniej wersji dodatku CEE Comarch ERP Enterprise dla Polski (sem.ext.app.Erp4pl) (szczegóły można znaleźć w informacji o wersji).
  • Inne formaty e-faktur dla faktur zakupu znajdują się w sekcji Obsługa dodatkowych formatów dla faktur zakupu.

Wymiana e-faktur w formacie ZUGFeRD odbywa się za pośrednictwem dokumentów w formacie PDF/A-3, tj. za pośrednictwem dokumentu PDF/A reprezentującego fakturę (tj. obraz faktury) oraz osadzonego pliku XML z powiązanymi danymi faktury zgodnie ze znormalizowanym modelem danych ZUGFeRD.

Comarch e-Faktura działa w połączeniu z konwerterem Comarch e-Faktura (wcześniej nazywanym narzędziem centralnym) i dodatkiem Comarch ERP Enterprise e-Faktura, do którego można uzyskać dostęp za pośrednictwem Comarch ERP Enterprise. Interfejs Comarch e-Faktura służy do wysyłania faktur sprzedaży i przetwarzania faktur zakupu. Pliki XML ZUGFeRD i dokumenty PDF/A-3 są tworzone i wysyłane jako e-faktury za pośrednictwem konwertera Comarch e-Faktura. Elektroniczne faktury zakupu są określane ze zdefiniowanych kont e-mail i udostępniane w interfejsie do dalszego przetwarzania w Comarch ERP Enterprise.

W przypadku innych formatów tworzony jest tylko plik XML z danymi e-faktury. Oprócz wysłania e-mailem, plik e-faktury może być również przesłany do katalogu Windows w celu dalszego przetwarzania w innych systemach.

Niniejszy artykuł opisuje wykorzystanie i funkcje konwertera Comarch e-Faktura w połączeniu z Comarch ERP Enterprise.

Informacje na temat obsługi Comarch e-Faktury w Comarch ERP Enterprise znajdują się w artykułach pomocy Comarch ERP Enterprise.

Dalsze dokumenty zostały zawarte w podfolderze Documents w katalogu instalacyjnym (więcej informacji można znaleźć w rozdziale Instalacja obiektów). W szczególności jest to pomoc w postaci dokumentów quick_guides lub quick_guide dla nowych wersji formatów, np. z instrukcjami dotyczącymi wprowadzenia nowego formatu e-faktury. Informacje na temat interpretacji komunikatów o błędach można znaleźć w rozdziale Wyjaśnienie komunikatu o błędzie podczas walidacji XRechnung i ZUGFERD 2.1.

Wyjaśnienia dotyczące formularzy e-Faktury

W odniesieniu do obsługiwanych formatów e-faktur należy zwrócić uwagę na następujące kwestie:

  • ZUGFeRD 2.1 to hybrydowy format faktur elektronicznych spełniający wymagania europejskiej normy EN 16931-11 (identyczny pod względem treści i struktury z francuskim formatem hybrydowym Factur-X w wersji 1.0.05).
  • XRechnung (wersje 1.2.2, 2.0.0 i kolejne) jest kompatybilny z ZUGFeRD 2.1, tj. identyczny pod względem treści i struktury. Istnieją jednak dodatkowebowiązkowe szczegóły, takie jak identyfikator routingu lub dane kontaktowe. Więcej informacji na ten temat można znaleźć w rozdziale Cechy szczególne XRechnung.
  • FatturaPA 1.2 i FatturaPA 1.3 są identyczne pod względem struktury, choć zmianie uległy prawidłowe wartości dla niektórych atrybutów. Obecnie należy korzystać z FatturaPA 1.3, ponieważ jest on obowiązkowy od 1 stycznia 2021 r., a nowe funkcje FatturaPA są obsługiwane tylko w tym formacie.
  • FA(2) jest czystym formatem danych. W przypadku faktur KSeF istnieje również połączenie z Krajowym Systemem e-Faktur, do którego e-faktury są przesyłane i z którego pobierany jest numer dokumentu KSeF oraz Urzędowe Poświadczenie Odbioru (UPO). Numer dokumentu KSeF i odpowiedni status e-faktury są przenoszone do Comarch ERP Enterprise.
Uwaga
Podstawowe procesy mają również zastosowanie do XRechnung, FatturaPA i KSeF, nawet jeśli są one opisane w tym artykule w połączeniu z ZUGFeRD. To samo dotyczy informacji na temat tworzenia treści XML faktury. Wyjaśnienia dotyczące ZUGFeRD i ZUGFeRD 2.1 mają również zastosowanie do XRechnung, ponieważ oba są na normie EN 16931. Różnice między formatami są wyraźnie wskazane.

Struktura narzędzia Konwerter Comarch e-Faktura

Konwerter Comarch e-Faktura składa się z kilku komponentów:

  • Serwer e-faktury:
    • Kokpit sterowania e-fakturą
    • Utrzymanie serwera e-faktury
    • Utrzymanie list kodów
    • Utrzymanie konwersji wartości
    • Wdrażanie aktualizacji
  • Updater eInvoice
  • Serwer rozliczeniowy (nie jest częścią instalacji, ale oddzielnym serwerem w Comarch)

Serwer e-faktur (zwany w skrócie serwerem) określa e-faktury udostępniane w interfejsie w regularnych odstępach czasu dla faktur sprzedaży. Te e-faktury są przetwarzane (konwertowane), a następnie wysyłane. Równocześnie konta e-mail, które mają odbierać e-faktury, są skanowane w poszukiwaniu nowych wiadomości zawierających e-faktury. Dla każdego z tych kont e-mail wszystkie wiadomości są przetwarzane lub przenoszone do odpowiedniego folderu skrzynki odbiorczej, w zależności od tego, czy wiadomość e-mail zawiera fakturę jako załącznik. W przypadku faktur zakupu dane z XML do e-faktury i PDF w ZUGFeRD są przenoszone do interfejsu.

Serwer jest zwykle uruchamiany jako usługa.

Kokpit sterujący może być używany do wykonywania wszystkich funkcji utrzymania, monitorowania interfejsu i aktualizacji konwertera Comarch e-Faktura poprzez aktualizacje oprogramowania.

Korzystanie z Comarch e-Faktura jest rozliczane na podstawie transakcji. W tym celu licznik przetworzonej e-faktury jest zwiększany za pośrednictwem serwera rozliczeniowego za pomocą usługi sieciowej przed wysłaniem wiadomości e-mail z e-fakturą lub przed przesłaniem e-faktury do interfejsu (skrzynka odbiorcza).

Faktury sprzedaży, które są nieprawidłowe, tj. nie mogły zostać poprawnie utworzone, oraz faktury zakupu, które nie zostały przesłane do interfejsu, ponieważ są nieprawidłowe, nie są obsługiwane lub zostały przesłane przed aktywowaniem e-fakturowania, nie są rozliczane.

Kokpit sterujący

Najważniejszym elementem konwertera Comarch e-Faktura jest serwer. To właśnie za pośrednictwem kokpitu sterującego dokonuje się wszystkich niezbędnych ustawień i definicji.

Ze względu na fundamentalne znaczenie tych ustawień, opis działania aplikacji rozpoczynany jest od opisu kokpitu sterowania. Informacje na temat uruchamiania i konfiguracji serwera znajdują się w rozdziale Zapewnienie dostępności serwerów.

Uwaga
Przed użyciem kokpitu sterującego należy w pełni zainstalować konwerter Comarch e-Faktura. Szczegółowe instrukcje znajdują się w rozdziale Instalacja, a w szczególności w podrozdziale Instalacja obiektów.

Aby uruchomić kokpit sterowania, należy uruchomić plik cockpit_start.bat.

Przegląd interfejsu i statusu serwera

Najczęściej wykorzystywaną funkcją kokpitu sterującego jest monitorowanie serwera i interfejsu. Funkcja ta jest dostępna wyłącznie wtedy, gdy serwer jest uruchomiony.

Status serwera można sprawdzić w polu statusu znajdującym się poniżej adresu serwera.

Na zakładkach Faktury sprzedaży i Faktury zakupu można przeglądać statusy powiązanego przetwarzania oraz zawartość interfejsu wraz ze statusami przetwarzania faktur elektronicznych (e-faktur).

Wybranie przycisku [Odśwież] aktualizuje dane widoczne w interfejsie. Pola wyboru umożliwiają zawężenie zakresu danych. Pola wyszukiwania tekstowego obsługują wyszukiwanie ogólne (dodawany jest automatycznie znak *). Wiele warunków wyszukiwania jest łączonych za pomocą logiki AND.

Dla wyświetlanych w tabeli e-faktur można użyć funkcji podglądu ekranu, aby otworzyć powiązane dokumenty, jeśli takie istnieją. W przypadku problemów z otwieraniem dokumentów, należy zapoznać się z informacjami w rozdziale Otwieranie pliku przez pop-up w kokpicie sterującym kończy się niepowodzeniem.

Przyciski [Wstrzymaj przetwarzanie] i [Start], znajdujące się po prawej stronie przycisku [Odśwież], umożliwiają wstrzymanie lub uruchomienie procesu wejściowego lub wyjściowego, w zależności od jego bieżącego statusu.

Status danego przetwarzania wejściowego/wyjściowego wyświetlany jest pod tabelą z danymi interfejsu. Gdy przetwarzanie jest aktywne, prezentowana jest lista aktywnych zadań w chwili ostatniego odświeżenia. Zatrzymanie przetwarzania oznacza, że nie będą już przetwarzane nowe e-faktury. Aktualnie aktywne zadania nie zostaną przerwane — zakończą się standardowo.

Na zakładce System KSeF można sprawdzić status i czas ostatniego wykonania akcji przez odpowiednie przetwarzanie. Odnosi się do wysyłania i odbierania potwierdzeń faktur oraz pobierania faktur zakupu z podłączonego systemu KSeF.

Zakładka Komunikaty zawiera listę najnowszych komunikatów z serwera. Wszystkie komunikaty można znaleźć w pliku dziennika serwera.

Utrzymanie danych sterujących Konwertera Comarch e-Faktura

Działanie aplikacji sterowane jest za pomocą różnych ustawień. Zachowanie serwera regulowane jest przez ustawienia serwera, opisane w rozdziale Ustawienia serwera.

Dodatkowe definicje są wymagane w celu prawidłowego przetwarzania zawartości e-faktur. Aby określone specyfikacje pochodzące z systemu Comarch ERP Enterprise mogły być interpretowane jako prawidłowe wartości w standardzie ZUGFeRD, muszą zostać zastosowane odpowiednie konwersje wartości.

Przykład
Standard ZUGFeRD oczekuje wartości C62 jako oznaczenia jednostki miary Sztuka. Tego rodzaju transformacje są obsługiwane poprzez: konwersje wartości do list kodów specyficznych dla formatu (więcej informacji na ten temat można znaleźć w rozdziale Listy kodów), oraz specjalne konwersje wartości dla Comarch ERP Enterprise (więcej informacji na ten temat można znaleźć w rozdziale Specjalne konwersje).

Odpowiednie programy, służące do zarządzania tymi definicjami, można uruchomić poprzez kokpit sterujący z poziomu menu na zakładce Dodatki.

Transfer danych definicji dla nowych formatów (jednorazowo!)

Każdy format e-faktury, a także każda wersja danego formatu, posiada własne definicje dotyczące konwersji wartości. Aby uniknąć konieczności ponownego ręcznego wprowadzania wszystkich definicji, w menu pod przyciskiem [Dodatki] dostępna jest akcja [Transfer danych definicji dla nowych formatów (jednorazowo!)]. Umożliwia ona skopiowanie już zdefiniowanych danych z istniejącego formatu do odpowiadającego mu nowego formatu lub nowej wersji tego formatu.

Uwaga
Przeniesienie danych definicyjnych do nowego formatu może zostać wykonane wyłącznie jeden raz.

Po wykonaniu przeniesienia, dane w nowym formacie muszą zostać zweryfikowane, a w razie potrzeby również dostosowane i uzupełnione. Dodatkowe informacje dotyczące wprowadzania nowych formatów znajdują się w rozdziale Ogólne.

Zatrzymywanie serwera

Aby możliwe było przeprowadzenie aktualizacji, serwer musi zostać uprzednio zatrzymany. W tym celu w menu pod przyciskiem [Serwer] dostępna jest akcja [Zamknij serwer e-faktury]. Funkcja ta zatrzymuje serwer w sposób kontrolowany. Podobnie jak w przypadku zatrzymywania przetwarzania, serwer nie jest wyłączany natychmiastowo. Najpierw zatrzymywane jest uruchamianie nowych procesów przetwarzania e-faktur, a trwające przetwarzanie jest doprowadzane do końca.

Dopiero gdy wszystkie aktywne zadania zostaną zakończone, serwer zostaje wyłączony.

Aktualizacja

Gdy dostępna jest nowa wersja konwertera Comarch e-Faktura, administratorzy wskazani w ustawieniach otrzymują odpowiednie powiadomienie. Aktualizacja nie odbywa się automatycznie — musi zostać przeprowadzona ręcznie, za pomocą akcji [Aktualizacja e-Faktury (kompletna)], dostępnej w menu pod przyciskiem [Aktualizacje].

Przed wykonaniem aktualizacji ponownie przeprowadzana jest kontrola wersji, dlatego funkcja ta może być również wykorzystana do sprawdzenia dostępności nowych wersji.

Automatyczne aktualizacje nie są możliwe, ponieważ serwer musi być wcześniej wyłączony. Ponadto, konieczne może być posiadanie odpowiednio aktualnej wersji dodatku e-Faktury systemu Comarch ERP Enterprise oraz interfejsu e-faktury.

Proces aktualizacji działa w języku ustawionym jako domyślny dla systemu operacyjnego.

Rozliczenia

Przycisk [Przerwij] na pasku menu umożliwia sprawdzenie statusu rozliczeń.

Aby przetwarzanie e-faktur mogło przebiegać w pełni poprawnie, wymagane jest dostępne połączenie z serwerem rozliczeniowym. Jeżeli serwer rozliczeniowy jest niedostępny, aplikacja umieszcza go w tymczasowym stanie oczekiwania.

Co około 30 minut przeprowadzana jest automatyczna kontrola dostępności serwera rozliczeniowego. Jeśli sprawdzenie zakończy się powodzeniem, przetwarzanie e-faktur jest wznawiane.

Akcja [Sprawdzanie serwera rozliczeniowego], dostępna pod przyciskiem [Przerwij], umożliwia sprawdzenie, czy serwer rozliczeniowy jest dostępny. Kontrola obejmuje: fizyczną dostępność serwera (np. czy nie jest blokowany przez zaporę sieciową), poprawność definicji ustawień licencyjnych (więcej informacji na ten temat można znaleźć w rozdziale Licencja) oraz poprawność konfiguracji użytkownika i hasła dla połączenia z serwerem rozliczeniowym (więcej informacji można znaleźć w rozdziale Komunikacja).

Identyfikacja użytkownika w serwerze rozliczeniowym odbywa się na podstawie ustawień licencyjnych i danych logowania. Funkcja ta jest szczególnie przydatna po instalacji konwertera Comarch e-Faktura oraz po pomyślnej parametryzacji ustawień serwera, gdy nie są jeszcze dostępne żadne e-faktury do przetworzenia.

Akcja [Bieżący stan rozliczenia], dostępna pod przyciskiem [Przerwij], pozwala na wyświetlenie aktualnego statusu rozliczeń, tj. liczbę przetwarzanych obecnie e-faktur.

Utrzymanie danych kokpitu sterującego

Sam kokpit sterujący posiada własne dane sterujące. Powiązany program do zarządzania tymi ustawieniami uruchamiany jest w kokpicie sterującym poprzez akcję [Ustawienia kokpitu], znajdującą się pod przyciskiem [Kokpit].

Ustawienia serwera

Funkcjonalność serwera oraz jego połączenie z interfejsem e-faktury, serwerem pocztowym i kontami e-mail dla faktur zakupu jest utrzymywana za pomocą ustawień. Wywołanie odbywa się z poziomu kokpitu sterującego poprzez menu główne, przycisk [Dodatki], a następnie na tematycznie podzielonych zakładkach.

Działanie poszczególnych ustawień opisane jest w kolejnych rozdziałach.

Jeśli poprawna wartość została oznaczona jako domyślna, oznacza to, że będzie ona używana przez serwer w przypadku, gdy nie zostanie określona żadna inna wartość w ustawieniach.

Deklaracje true/false są zazwyczaj zarządzane przez pola wyboru, gdzie zaznaczone pole oznacza wartość true.

Uwaga
Po dokonaniu zmian w ustawieniach należy zatrzymać i ponownie uruchomić serwer aplikacji konwertera Comarch e-Faktura, aby zmiany mogły wejść w życie.

Jeżeli wszystkie pola nie zostały poprawnie uzupełnione, podczas zapisu za pomocą przycisku [OK] mogą pojawić się komunikaty o błędach. W takim przypadku należy zapisać wprowadzone ustawienia za pomocą przycisku [Zapisz bez sprawdzania].

Zakładka Elementy podstawowe

Zakładka Elementy podstawowe zawiera następujące dane:

  • Używana aplikacja Comarch — konwerter Comarch e-Faktura wykorzystuje połączenia z interfejsem e-Faktury Comarch ERP Enterprise i uwzględnia specjalne metody przetwarzania dla tego systemu
  • System testowy — wartość false wskazuje na wykorzystywanie konwertera w systemie rzeczywistym. Faktura zakupu ze wskaźnikiem testowym true nie zostanie przetworzona, jedynie przeniesiona do folderu testowego konta e-mail. Wartość true wskazuje, że wszystkie faktury zakupu są akceptowane niezależnie od wskaźnika testowego. Wraz z tym ustawieniem zaleca się ustawienie dla faktur sprzedaży wartości true w polu trybu testowego.
  • Język dla serwera — język, w którym działa serwer. Jest to język, w którym wyświetlane są komunikaty w kokpicie oraz wysyłane komunikaty o błędach i wiadomości e-mail. Jeśli nie określono języka, wykorzystywany jest język zgodny z ustawieniami systemowymi, tj. zgodnie z formatem regionalnym.

Zakładka Ustawienia domyślne

Uwaga
Wartości na zakładce Ustawienia domyślne, znajdujące się powyżej przycisku [Ustaw domyślne dla pustych pól], są również używane dla formatu XRechnung i muszą być ustawione podczas korzystania z XRechnung.
  • Format daty — wartości dat w interfejsie muszą mieć następujący format, jeśli nie przypisano innego formatu do wartości daty w interfejsie:
    • 102 — YYYYMMDD (domyślna wartość)
    • 610 — YYYYMM
    • 616 — YYYYWW
  • Format identyfikatora partnera — format globalnego identyfikatora partnera w systemie ERP. Zazwyczaj jest to Globalny Numer Lokalizacyjny (GLN, wcześniej ILN), który w liście kodów ma wartość 0088 (domyślnie). Dodatkowe wartości można znaleźć w listach kodów pod oznaczeniem listy kodów GLOBAL_ID_FMT  (więcej informacji można znaleźć w rozdziale Listy kodów).
  • Format identyfikatora artykułu — format globalnego identyfikatora artykułu w systemie ERP. Zazwyczaj jest to Globalny Numer Jednostki Handlowej (GTIN), który w liście kodów ma wartość 0160 (domyślnie). Dodatkowe wartości można znaleźć w listach kodów (więcej informacji można znaleźć w rozdziale Listy kodów) pod oznaczeniem listy kodów GLOBAL_ID_FMT.
  • Rodzaj dokumentu ZUGFeRD — wartości 84 i 389 są udostępnione zgodnie ze standardem ZUGFeRD, ale nie są obsługiwane przez system Comarch ERP Enterprise.
    • 380 — faktura handlowa (wartość domyślna)
    • 84 — załadowana wartość
    • 389 — faktura wystawiona samodzielnie
  • Format docelowy znacznika czasu z faktury zakupu — wartość domyślna dla konwersji informacji o znaczniku czasu dla faktur zakupu
  • Zawsze używaj ZUGFeRD 2.1 Factur-X zamiast ZUGFeRD 1.0 — wszystkie faktury sprzedaży ze specyfikacją formatu ZUGFeRD 1.0 będą tworzone jako e-faktury w formacie ZUGFeRD 2.1 zgodnie z ustawieniami dla nowego formatu. Aktywacja tego parametru ma taki sam skutek, jak ręczna zmiana wszystkich specyfikacji ZUGFeRD 1.0 (w systemie Comarch ERP Enterprise określane po prostu jako ZUGFERD) na ZUGFeRD 2.1 w widoku klienta. W związku z tym należy odpowiednio dostosować szablony dokumentów lub filtry eksportu.

Ustawienia domyślne FatturaPA:

  • Minimalna kwota Bollo — ustalana jest suma pozycji faktury ze stawką podatku 0%. Jeśli bezwzględna kwota sumy przekracza kwotę Bollo w tym przypadku kwota opłaty skarbowej jest umieszczana na fakturze FatturaPA.
  • Kwota płatności Bollo — kwota znaczka skarbowego
  • Zawsze należy wykorzystywać FatturaPA 1.3 zamiast FatturaPA 1.2. — wszystkie faktury sprzedaży ze specyfikacją formatu FatturaPA 1.2 zostaną utworzone jako e-faktura w formacie FatturaPA 1.3 zgodnie z ustawieniami nowego formatu. Dostosowanie szablonów dokumentów lub filtrów eksportu nie jest konieczne.

Ustawienia domyślne XRechnung:

  • Domyślne ustawienia dla pustych pól — wartości domyślne w polach w sekcji Ustawienia domyślne ZUGFeRD muszą być również ustawione dla XRechnung
  • Wersja formatu dla XRechnung — w Comarch ERP Enterprise jako format faktury wybrano wartość XRECHNUNG. Ważna wersja dla tego formatu jest zdefiniowana w tym polu.

Zakładka Interfejs

Specyfikacje interfejsu definiują dostęp i połączenie z interfejsem e-faktury. Umożliwiają one zdefiniowanie szczegółów połączenia konwertera z systemem Comarch ERP Enterprise.

  • System CEE — adres serwera aplikacji Comarch ERP Enterprise musi być określony bez początkowego prefiksu https i bez końcowego /. Można użyć oddzielnych serwerów aplikacji, określając port. Przykładowo, kundendv.kunde.de lub kundendv.kunde.de:7777.
  • Baza danych — wykorzystywana baza danych, przykładowo KUNDENDV02
  • Firma główna — identyfikator klienta, tzn. katalog główny wszystkich organizacji, np. organizacja główna 00000
  • Certyfikat JKS — ścieżka do certyfikatu JKS. Więcej informacji na ten temat można znaleźć w rozdziale Tworzenie certyfikatu JKS.
  • Hasło JKS — hasło do certyfikatu JKS
  • Katalog faktur zakupu (kstore) — główny katalog interfejsu w kstore, w którym umieszczane są załączniki i pliki interfejsu do faktur zakupu. Nawet jeśli nie procesuje faktur zakupu, należy określić istniejący folder kstore w tym miejscu, ponieważ połączenie z kstore jest sprawdzane za pomocą tej specyfikacji. Przykładowo Documents/eInvoices/Incoming. Wraz ze wskazanym systemem Comarch ERP Enterprise oraz bazą danych, informacje zapisywane są pod adresem https://kundendv.kunde.de:7777/kstore/KUNDENDV02/eInvoices/Incoming.
Uwaga
Ponieważ dla oryginalnych plików faktur zakupu tworzony jest link do dokumentów faktur zakupu, utworzonych na ich podstawie w Comarch ERP Enterprise, katalog ten musi znajdować się pod folderami Database/Documents.

Zakładka Komunikacja

Konwerter Comarch e-Faktura wymaga połączenia z dwoma serwerami Comarch, tj. serwerem rozliczeniowym dla przetwarzanych e-faktur oraz serwerem aktualizacji oprogramowania.

Ważne jest, aby dostęp do tych serwerów był możliwy, tj. nie był blokowany przez zapory sieciowe lub inne mechanizmy. Opis wymagań systemowych można znaleźć w rozdziale Wymagania systemowe.

Dostęp do serwera rozliczeniowego odbywa się za pośrednictwem połączenia HTTPS, które jest dodatkowo zabezpieczone logowaniem przy użyciu użytkownika i hasła. Użytkownik i odpowiednie hasło zostaną dostarczone wraz z licencją. Więcej informacji na ten temat można znaleźć w rozdziale Licencja.

Jeśli używane są serwery proxy, parametr Używaj serwera proxy musi zostać zaznaczony. Tylko wtedy odpowiedni przycisk ustawień serwera proxy jest aktywny i można dokonywać wpisów.

Parametr Czas oczekiwania w sekundach jest brany pod uwagę zarówno z aktywowanym, jak i dezaktywowanym parametrem Używaj serwera proxy.

Formaty

Dodatkowe dane można dodać do obsługiwanych formatów e-faktur, wybierając format a następnie przycisk [Edytuj], aby rozpocząć edycję. Po wprowadzeniu zmian należy wybrać przycisk [Ustaw dane dla wybranego formatu], aby tymczasowo zastosować informacje dla formatu na liście. Dane zostaną jednak ostatecznie zastosowane dopiero po zapisaniu ustawień poprzez wybranie przycisku [OK].

Uwaga
To samo dotyczy nowych formatów po aktualizacji wersji. Nie są one tworzone na stałe, dopóki ustawienia nie zostaną później otwarte i zapisane przyciskiem [OK].

Szczegóły wybranego formatu:

  • Nie używaj do faktur sprzedaży — jeśli parametr nie zostanie aktywowany, format e-faktury jest obsługiwany dla faktur sprzedaży. Jeśli parametr jest aktywny, format e-faktury jest wyłączony dla faktur sprzedaży. Ta specyfikacja nie ma wpływu na odpowiadający jej wybór w widoku Klient dla partnera Comarch ERP Enterprise.
  • Nie używaj do faktur zakupu — jeśli parametr nie jest aktywowany, format e-faktury jest obsługiwany dla faktur zakupu. Jeśli parametr jest aktywny, format e-faktury jest wyłączony dla faktur zakupu.
  • Rodzaj pliku(ów) wyjściowego(ych) — ta specyfikacja ustawia domyślny typ pliku e-faktury, który ma być tworzony dla faktur należności. U partnera Comarch ERP Enterprise, dla klientów można zdefiniować wartości odbiegające od domyślnych. Dopuszczalne są następujące wartości:
    • PDF z osadzonymi danymi faktury (dla ZUGFeRD: PDF/A-3)
    • Dane faktury
    • Plik XML
  • Rodzaj przetworzenia końcowego — ta specyfikacja ustawia domyślny typ końcowego wyniku utworzonego pliku e-faktury. Aby można było wybrać wartość, musi ona być włączona przez inne właściwości formatu lub być zasadniczo możliwa (FatturaPA nie obsługuje e-maila, ponieważ transmisja musi odbywać się przez SDI). U partnera Comarch ERP Enterprise, dla klientów można zdefiniować wartości odbiegające od domyślnych, w takim przypadku wybrany typ musi być aktywowany. Dopuszczalne są następujące wartości:
    • Mail
    • Zapis w katalogu Windows
    • Brak maila, brak zapisu w katalogu Windows (plik e-faktury znajduje się tylko w folderze kstore zgodnie z interfejsem / szablonem dokumentu)

Sekcja Przesyłanie wiadomości e-mail:

  • Przesyłanie poczty z fakturą dozwolone — aktywowanie parametru zezwala na wysyłkę mailową. Aby ustawienie było skuteczne, wartość Mail musi być dozwolona w ramach rodzaju przetwarzania końcowego.
  • Nazwa pliku dla utworzonej faktury — nazwę pliku e-faktury można określić w następujący sposób:
    • Domyślnie, tzn. bez specyfikacji, einvoice jest dodawane do nazwy pliku obrazu faktury przed rozszerzeniem .pdf. Zalecane jest to w przypadku korzystania z Comarch ERP Enterprise.
    • Wartość uzupełniająca, tzn. nazwa pliku obrazu faktury jest rozszerzana o wartość uzupełniającą przed rozszerzeniem .pdf
    • W DSS należy określić stałą nazwę pliku dla e-faktury, tzn. dla pliku PDF/A-3 utworzonego z pliku PDF i XML ZUGFeRD (np. eInvoice.pdf)
    • W przypadku formatu FatturaPA nazwa pliku jest ustawiana automatycznie przez system Comarch ERP Enterprise

Sekcja Przechowywanie w katalogu Windows:

  • Kopiowanie e-faktury do folderu docelowego dozwolone — aktywowanie parametru umożliwia zapis utworzonych e-faktur do folderu Windows. Aby specyfikacja działała, opcja Zapis w katalogu Windows musi być dostępna w rodzaju przetwarzania końcowego.
  • Folder docelowy kopii e-faktury — folder, do którego zostanie zapisany utworzony plik e-faktury lub w którym zostanie utworzony podfolder z utworzonym plikiem e-faktury
  • Podfolder docelowy według rodzaju — ponieważ e-faktury generowane na podstawie faktur zakupu są przetwarzane w konwerterze Comarch e-Faktura w taki sam sposób jak faktura sprzedaży, stworzono możliwość podziału tych faktur na różne foldery plików Windows poniżej folderu docelowego dla kopii. W tym miejscu można podać dwa foldery, oddzielone przecinkami. Najpierw podaje się folder dla faktur sprzedaży, a następnie folder dla e-faktur wygenerowanych dla faktur zakupu. Przykłady: out,in_gen lub in_gen lub out lub out,. Jeśli nie podano żadnej specyfikacji, jak w trzech ostatnich przykładach, żaden folder nie jest wstawiany.

Sekcja Dodatkowa wysyłka faktury PDF pocztą elektroniczną:

  • Wysyłanie PDF faktury CEE — aktywacja parametru oznacza, że po pomyślnym utworzeniu e-faktury, plik PDF faktury Comarch ERP Enterprise jest dodatkowo wysyłany mailem. Opcja ta jest obecnie aktywna tylko dla formatu FatturaPA. W przypadku FatturaPA, specyfikacja tematu maila jest uzupełniana o specyfikację.

Sekcja Tworzenie plików PDF do formatów:

Informacje zawarte w tej sekcji nie są istotne dla Comarch ERP Enterprise, ponieważ plik PDF z fakturą jest przygotowywany w systemie Comarch ERP Enterprise i przekazywany do konwertera Comarch e-Faktura.

Sekcja Specyficzne (zależne od formatu) funkcje:

  • Drukuj noty kredytowe z dodatnią kwotą faktury — dzięki aktywacji tego parametru, korekty faktur sprzedaży są konwertowane na dodatnią kwotę końcową. Parametr może być wykorzystywany tylko dla formatu FatturaPA.
  • Sortowanie danych dokumentu — dzięki aktywacji tego parametru, w szczegółach dokumentów faktur sprzedaży FatturaPA (np. dla zamówienia zakupu, listów przewozowych) są one sortowane zgodnie z wyborem lub pozostawiane w kolejności, w jakiej są przekazywane z Comarch ERP Enterprise

Sekcja Sterowanie wydaniem dokumentu e-faktury:

  • Inny folder docelowy — jeśli w tym miejscu wskazano folder kstore lub folder obszaru roboczego Comarch ERP Enterprise, utworzone pliki e-faktur zostaną umieszczone w podanym tutaj folderze docelowym. Ten folder musi już istnieć. Folder ten może być uzupełniony o dalsze foldery, jeśli dla Uwzględnij foldery nadrzędne podano liczbę większą niż zero. Więcej szczegółów można znaleźć w rozdziale Procedura dla niestandardowego folderu docelowego. Bez tej specyfikacji utworzona e-faktura zostanie umieszczona w tym samym folderze, co plik z neutralnym XML, tak jak to miało miejsce wcześniej.
  • Uwzględnij foldery nadrzędne (liczba) — liczba większa od zera określa maksymalną liczbę folderów, które zostaną dołączone ze ścieżki pliku neutralnego XML (od końca wstecz) do folderu docelowego dla danej faktury. Więcej informacji można znaleźć w rozdziale Procedura dla niestandardowego folderu docelowego.
  • Nie zmieniaj nazwy pliku dla utworzonej faktury — nazwa pliku dla utworzonej faktury jest tworzona na podstawie nazwy pliku PDF faktury Comarch ERP Enterprise lub neutralnego XML poprzez dodanie wartości uzupełniającej z pola Nazwa pliku dla utworzonej faktury (specyfikacja wartości lub wartość domyślna). Bez innego folderu docelowego jest to konieczne, aby uniknąć używania tych samych nazw w folderze. Jeśli folder docelowy jest inny, dodawanie nazwy nie jest już wymagane i można je tym samym dezaktywować.
  • Nie twórz wizualizacji — w tym miejscu można zdefiniować, czy ma zostać wygenerowana wizualizacja dla utworzonej e-faktury
  • Nie wysyłaj faktur zerowych — faktury zerowe to faktury, których kwota całkowita wynosi 0,00 (tzn. gdy <grossAmount> w neutralnym XML ma tę wartość) Dzięki tej opcji zapobiega się wysyłaniu tych e-faktur mailem oraz zapisywaniu/tworzeniu kopii e-faktury w katalogu Windows (zgodnie z polem Folder docelowy dla kopii e-faktury). W takim przypadku nie jest również wysyłany PDF faktury Comarch ERP Enterprise.
  • Usuwanie plików źródłowych po utworzeniu — ten parametr kontroluje, czy po pomyślnym utworzeniu e-faktury, neutralny XML i PDF faktury Comarch ERP Enterprise zostaną usunięte. Jeśli aktywowano ten parametr, pomyślnie utworzone e-faktury nie są już widoczne w kokpicie sterującym. W Comarch ERP Enterprise są jednak nadal widoczne.

Sekcja Definicje konwersji:

  • Definicja dla list kodów — zawiera nazwę pliku z wymaganymi listami kodów dla formatu. Plik o tej nazwie musi znajdować się w folderze instalacyjnym.
  • Definicja dla konkretnej konwersji — zawiera nazwę pliku ze specjalnymi konwersjami dla formatu. Plik o tej nazwie musi znajdować się w folderze instalacyjnym.
  • Usuń niedozwolone znaki — parametr określa, czy nieprawidłowe znaki, takie jak podziały wierszy lub znaki specjalne, mają zostać usunięte z utworzonego pliku XML e-faktury przed jego walidacją. Dopuszczalne wartości to:
    • Nie usuwaj
    • Zgodnie z definicjami czyszczenia znaków (ZBD)
    • Wszystkie nieprawidłowe podziały wierszy/tabulatory zgodnie z definicją XSD (XSD)
    • Zgodnie z obiema procedurami (ZBD i XSD)

ZBD dotyczy tylko niektórych elementów w XML e-faktury, podczas gdy XSD dotyczy całego XML. Jeśli używane są obie metody, najpierw wykonywane jest ZBD. Jest to wymagane tylko dla formatu FatturaPA i istnieją już domyślne ustawienia dla ZBD w FatturaPA 1.2.

Uwaga
Procedura XSD nie tylko czyści znaki, które nie są dozwolone, ale może nawet dodawać dodatkowe informacje do XML e-faktury. Dzieje się tak np. w przypadku XRechnung i dlatego nie wolno jej używać z tym formatem. Zasadniczo, procedura powinna być używana tylko dla FatturaPA i najlepiej tylko z ZBD.

Zakładka Serwer pocztowy

Określony serwer pocztowy z zdefiniowanym kontem jest używany do wysyłania powiadomień do administratorów. Jeśli w sekcji Faktury sprzedaży nie zdefiniowano własnego konta (więcej informacji można znaleźć w rozdziale Faktury sprzedaży), serwer pocztowy/konto pocztowe zdefiniowane tutaj będzie również używane do wysyłania faktur sprzedaży.

Obsługiwane są tylko konta SMTP, dlatego jako protokół pocztowy należy wprowadzić wartość smtp lub, jeśli komunikacja jest szyfrowana, smtps. Szyfrowane transfery za pomocą STARTTLS mogą być również używane jako tryb transferu.

Oprócz szczegółów konta, podaje się tutaj, czy komunikacja z serwerem pocztowym jest odnotowywana w plikach logowania. Więcej informacji na ten temat można znaleźć w rozdziale Logowanie komunikacji z serwerem pocztowym.

Dla powiadomień do administratorów, należy podać adres nadawcy i jeden lub więcej adresów odbiorców (oddzielonych średnikami). Każde powiadomienie do administratorów zaczyna się od podanego w temacie tekstu.

Zakładka Faktury sprzedaży

Możliwe jest zdefiniowanie oddzielnego serwera pocztowego z własnym kontem dla faktur sprzedaży. Jeśli specyfikacja hosta pozostaje pusta, faktury sprzedaży będą wysyłane z ustawieniami zgodnie ze specyfikacjami serwera pocztowego.

Jeśli w danych interfejsu dla faktury sprzedaży nie ma własnego nadawcy, faktury sprzedaży są wysyłane ze specyfikacją z pola Domyślny adres jako dostawca.

Inne opcje konfiguracji:

  • Tryb testowy — brak aktywacji parametru powoduje, że faktury sprzedaży są wysyłane jako rzeczywiste faktury. Jeśli parametr jest aktywowany, faktura sprzedaży zawsze będzie tworzona jako faktura testowa. Gdy faktura sprzedaży jest tworzona jako faktura testowa, w XML ZUGFeRD 1.0 ustawiany jest wskaźnik testowy, a na pierwszej stronie obrazu faktury dodawany jest czerwony, ukośny tekst TEST CASE.
  • Faktura sprzedaży dezaktywowana — aktywowanie parametru jest równoznaczne z dezaktywowaniem faktury sprzedaży
  • Opóźnienie startu (w ms) — gdy usługa e-faktury zostanie ponownie uruchomiona, przetwarzanie faktur sprzedaży jest aktywowane dopiero po upływie tego czasu (w milisekundach). Daje to możliwość zatrzymania przetwarzania za pośrednictwem kokpitu sterującego po uruchomieniu serwera, zanim zostaną przetworzone pierwsze dane z interfejsu.
  • Czas oczekiwania między cyklami przetwarzania (w ms) — gdy wszystkie udostępnione faktury sprzedaży w interfejsie zostaną przetworzone, przetwarzanie zostaje zatrzymane. Po upływie określonego czasu, wszystkie nowo dodane udostępnione faktury sprzedaży zostaną przetworzone. Zapobiega to niepotrzebnemu stałemu obciążeniu komputera/systemu. Zalecane wartości minimalne (60000 -> 1 minuta lub 1200000 -> 20 minut).
  • Maksymalna liczba dla równoległego przetwarzania — reguluje jednoczesne przetwarzanie faktur sprzedaży. Wartość domyślna jest równoznaczna z przetwarzaniem szeregowym, natomiast wartość x>1 nie powinna być zbyt duża, w zależności od wydajności i pamięci RAM komputera.
  • Adresy e-mail dla powiadomień — adresy e-mail do odbiorców, którzy zostaną powiadomieni w przypadku problemów z fakturą sprzedaży (oddzielone średnikiem). W przeciwieństwie do analogicznej specyfikacji pod serwerem pocztowym, tutaj należy podać adresy pracowników zajmujących się fakturami sprzedaży. Jeśli nie mają być wysyłane maile, należy podać specjalną wartość *noMail.
  • Adres domyślny jako nadawca — nadawca dla faktur sprzedaży, jeśli w interfejsie nie ma specyfikacji na ten temat. Konto pocztowe ustawione dla faktur sprzedaży musi pozwalać na wysyłanie maili na te adresy dla wszystkich szczegółów, podanych za pośrednictwem tego adresu lub adresu nadawcy z interfejsu. Jeśli to nie jest zagwarantowane, tzn. jeśli konto pocztowe nie pozwala na różnych nadawców, należy aktywować parametr Zawsze używaj domyślnego adresu nadawcy.
  • Zawsze używaj domyślnego adresu nadawcy — jeśli parametr jest aktywny, adres e-mail z pola Adres domyślny jako nadawca jest zawsze wykorzystywany jako nadawca wiadomości
  • Zażądaj potwierdzenia odbioru — parametr ustawia właściwość żądania potwierdzenia odbioru/przesłania dla maili, które wysyłają fakturę sprzedaży. To, czy odpowiedź zostanie odesłana, zależy od odbiorcy lub ustawień jego serwera pocztowego. Innym warunkiem jest, aby własny serwer pocztowy obsługiwał DSN (Delivery status notifications).
  • Zażądaj potwierdzenia odczytu — parametr ustawia właściwość potwierdzenia przeczytania dla maili, w ramach których wysyłane są faktury sprzedaży. To, czy odpowiedź zostanie odesłana, zależy od odbiorcy lub ustawień jego serwera pocztowego.
  • Folder roboczy dla faktur sprzedaży — jest to folder roboczy do przechowywania faktur sprzedaży utworzonych plików XML, w przypadku gdy ich walidacja się nie powiedzie
  • Katalog wyjściowy dla komunikatów błędów — domyślny folder dla komunikatów o błędach

Ponadto, możliwe jest utworzenie konta pocztowego dla faktur sprzedaży, za pośrednictwem którego mają być wysyłane zrealizowane e-faktury. Jeśli podano hosta, to konto będzie używane. Jeśli konto pocztowe nie jest skonfigurowane w taki sposób, aby zezwalało na wysyłanie maili przez różnych nadawców za pośrednictwem tego konta, musi zostać podany Adres domyślny jako nadawca, a parametr Zawsze używaj domyślnego adresu nadawcy musi być aktywowany.

Jeśli nie zdefiniowano oddzielnego konta pocztowego dla faktur sprzedaży, używane będzie konto pocztowe z ustawień serwera pocztowego.

Zakładka Faktury zakupu

Dla faktur zakupu obsługiwanych jest wiele kont e-mail, które odbierają faktury zakupu. Te konta e-mail są definiowane na zakładce Faktury zakupu.

  • Faktura zakupu dezaktywowana — jeśli parametr jest aktywowany, przetwarzanie faktur zakupu nie jest możliwe
  • Opóźnienie startu (w ms) — gdy usługa e-faktury zostanie ponownie uruchomiona, przetwarzanie faktur zakupu zostanie aktywowane dopiero po upływie tego czasu. Daje to możliwość zatrzymania przetwarzania za pośrednictwem kokpitu sterującego po uruchomieniu serwera, zanim zostaną przetworzone pierwsze dane z interfejsu.
  • Czas oczekiwania między cyklami przetwarzania (w ms) — gdy wszystkie maile z folderów skrzynki odbiorczej zostaną przetworzone na kontach e-mail skrzynki odbiorczej, przetwarzanie wstrzymuje pracę. Po upływie określonego czasu (w milisekundach) rozpoczyna się ponowne przetwarzanie maili w folderach skrzynki odbiorczej. Zapobiega to niepotrzebnemu stałemu obciążeniu komputera/systemu.
  • Maksymalna liczba dla równoległego przetwarzania kont e-mail — ustawienie kontroluje jednoczesne przetwarzanie kont mailowych. Wartość domyślna oznacza przetwarzanie szeregowe. Wartości x>1 nie powinny być zbyt duże, w zależności od wydajności komputera. W ramach odpowiedniego konta e-mail przetwarzanie może być ponownie zrównoleglone.
  • Maksymalna liczba dla równoległego przetwarzania katalogów — ustawienie kontroluje jednoczesne przetwarzanie katalogów. Wartość domyślna oznacza przetwarzanie szeregowe. Wartości x>1 nie powinny być zbyt duże, w zależności od wydajności komputera. W ramach odpowiedniej definicji katalogu przetwarzanie może być ponownie zrównoleglone.
  • Przypisywanie organizacji do numerów GLN — przypisanie odpowiedzialnej organizacji w interfejsie na podstawie GLN odbiorcy. (Używany jest termin GLN, ponieważ jest to najczęstszy zakres numerów dla identyfikatorów partnerów). Przypisania są określane jako pary ze znakami -> oddzielonymi przecinkami w formie numer GLN -> Organizacja.
Przykład
1922209920000->90200,1922209920444->90100,1922209920022->90300

Faktury zakupu dla kupującego z GLN 1922209920000 są przypisywane do organizacji 90200 i tam przetwarzane w Comarch ERP Enterprise.

Podejmowana jest próba najpierw określenia GLN odbiorcy faktury, a jeśli ten nie jest dostępny, używany jest GLN kupującego. Jednocześnie podejmowana jest próba znalezienia odbiorcy faktury lub kupującego przez wyszukiwanie partnera. Jeśli przypisanie przez GLN/wyszukiwanie partnera nie jest możliwe, przypisanie odbywa się przez konto e-mail faktury zakupu. Więcej informacji można znaleźć w rozdziale Konta pocztowe faktur dostawcy.

  • Nie dołączaj dodatkowych załączników do interfejsu — aktywacja parametru uniemożliwia przetwarzanie dodatkowych załączników. Do interfejsu przekazywana jest wyłącznie e-faktura. Brak aktywacji parametru umożliwia przeniesienie wszystkich załączników do interfejsu. Ten parametr należy aktywować, ponieważ Comarch ERP Enterprise obecnie nie obsługuje przenoszenia dodatkowych załączników.
  • Zezwalaj na potwierdzenie odbioru do odczytu — parametr umożliwia automatyczne wysyłanie maili do nadawcy e-faktury, jeśli nadawca zażądał takiego potwierdzenia. Automatyczne potwierdzenie odczytu ma miejsce tylko dla maili, które zostały przeniesione do interfejsu. Dla pozostałych maili nie ma potwierdzenia odczytu, ponieważ muszą być sprawdzane ręcznie. Jako specyfikacja hosta/portu/protokołu pocztowego dla maila z potwierdzeniem odczytu używana jest specyfikacja z zakładki Serwer pocztowy. Jako nadawca używany jest użytkownik/hasło zgodnie z kontem odbiorczym.
  • Folder roboczy dla faktur zakupu — folder roboczy do tymczasowego przechowywania załączników e-maila w podfolderach. Folder roboczy jest czyszczony, gdy serwer e-faktur jest uruchamiany. Folder potrzebny jest jedynie w systemie Comarch ERP Enterprise, ponieważ w DSS załączniki są umieszczane bezpośrednio w SQX00.
  • Katalog wyjściowy dla komunikatów o błędach — katalog, w którym umieszczane są pliki z komunikatami o błędach przetwarzania faktur zakupu

Zakładka Konta pocztowe faktury zakupu

Konwerter Comarch e-Faktura obsługuje przetwarzanie elektronicznych faktur zakupu z wielu kont e-mail. Umożliwia to używanie oddzielnych kont przychodzących dla różnych organizacji. Konta skrzynki odbiorczej muszą obsługiwać protokół IMAP. Dlatego jako Protokół maila należy wpisać imap lub imaps, jeśli komunikacja jest szyfrowana.

Zdefiniowane konta przychodzące są wyświetlane na liście. Po kliknięciu na konto w dolnej części ekranu pokazują się szczegółowe informacje dotyczące konta. Aby zmienić dane konta, należy wybrać żądane konto na liście i uaktywnić pola do wprowadzania danych za pomocą przycisku [Edytuj]. Po dokonaniu zmian, należy wybrać przycisk [Ustaw dane dla wybranego konta e-mail], aby tymczasowo zastosować informacje dla konta na liście. Dane zostaną ostatecznie zastosowane dopiero po zapisaniu ustawień za pomocą przycisku [OK]. W ten sam sposób usunięte lub nowo utworzone konta zostaną zapisane na stałe tylko wtedy, gdy zmiany zostaną zapisane przyciskiem [OK].

Oprócz podstawowych informacji dostępu do konta e-mail, należy również zdefiniować następujące dane:

  • Nie używaj konta pocztowego — jeśli parametr jest aktywny, wskazane konto mailowe nie jest wykorzystywane przez konwerter
  • Rejestrowanie komunikacji z serwerem poczty e-mail — oprócz danych szczegółowych na temat konta, podawane jest tutaj, czy komunikacja z serwerem pocztowym jest rejestrowana w plikach logowania. Więcej informacji na ten temat można znaleźć w rozdziale Logowanie komunikacji z serwerem pocztowym.
  • Katalog wejściowy e-faktur — folder konta e-mail, który jest przeszukiwany pod kątem maili zawierających e-faktury. Zazwyczaj jest to folder Inbox. (INBOX = wartość specjalna dla poczty przychodzącej). Można jednak używać innych folderów lub podfolderów.
Przykład
Jeśli użytkownik chce wykorzystywać podfolder in, musi podać w tym miejscu wartość eingangsrechnung.in. Inaczej INBOX.eRG byłby podfolderem eRG w Inboxie.
  • Przetworzone e-faktury — w tym folderze umieszczane są e-faktury, które zostały poprawnie przeniesione do interfejsu
  • Błędne e-faktury  w tym folderze umieszczane są e-faktury, które formalnie zawierają e-fakturę, przykładowo plik PDF/A-3 z osadzonym plikiem ZUGFeRD-invoice.xml, ale które nie mogą być przeniesione do interfejsu
  • Wiadomości bez załączonej e-faktury — w tym folderze umieszczane są maile, które formalnie nie zawierają e-faktury
  • E-faktury z oznaczeniami testowymi — w tym folderze umieszczane są maile zawierające e-faktury, które oznaczone są wskaźnikiem testowym. E-faktura nie jest w tym przypadku przenoszona do interfejsu. Folder wykorzystywany jest wyłącznie dla rzeczywistych systemów. W przypadku systemów testowych, wszystkie faktury przenoszone są do interfejsu.
  • Liczba zadań dla przetwarzania równoległego — maksymalna liczba wiadomości mailowych, które mają być przetwarzane równolegle. Wartość x>1 powinna być współmierna do wydajności i pamięci RAM komputera.
  • Organizacja/firma powiązana z kontem e-mail — organizacja, do której przypisane jest konto e-mail. Jeśli nie można przypisać organizacji za pomocą numeru GLN/wyszukiwania partnera dla różniącego się odbiorcy faktury lub kupującego, organizacja podana tutaj jest przypisywana do e-faktury w interfejsie. Więcej informacji można znaleźć w rozdziale Faktury zakupu.
  • Adres(y) e-mail, na które można przesyłać informacje o błędach — adresy mailowe pracowników, którzy mają być powiadamiani o błędnych fakturach zakupu. Adresy należy rozdzielić średnikiem. We wszystkich przypadkach nadawca jest taki sam jak w przypadku informacji do administratorów. Jeśli nie podano adresu, komunikat o błędzie zostanie wysłany na adresy e-mail administratorów. Jeśli nie ma być wysyłany żaden mail o błędzie, należy wprowadzić wartość *noMail.

Zakładka Katalogi faktury zakupu

Oprócz e-faktur z kont e-mail, można również przetwarzać e-faktury z katalogów Windows. Konwerter Comarch e-Faktura obsługuje przetwarzanie e-faktur zakupu z wielu katalogów. Umożliwia to używanie oddzielnych kont przychodzących dla różnych organizacji.

Zdefiniowane definicje katalogów są wyświetlane na liście. Kliknięcie na definicję katalogu wyświetla szczegóły w dolnej części okna. Aby zmienić dane definicji katalogu, należy wybrać żądaną definicję katalogu na liście i aktywować pola do wprowadzania danych za pomocą przycisku [Edytuj]. Po dokonaniu zmian, należy wybrać przycisk [Ustaw dane dla wybranej definicji katalogu], aby tymczasowo zastosować dane dla katalogu na liście. Dane zostaną jednak ostatecznie zastosowane dopiero po zapisaniu ustawień za pomocą przycisku [OK]. W ten sam sposób usunięte lub nowo utworzone definicje katalogów zostaną zapisane na stałe tylko wtedy, gdy zmiany zostaną zapisane przyciskiem [OK].

Definicja katalogu zawiera następujące informacje:

  • Definicje katalogów — unikalna nazwa definicji katalogu
  • Nie używaj definicji katalogów — aktywowanie parametru uniemożliwia wykorzystywanie definicji katalogu przez konwerter
  • Katalog wejściowy e-faktur — katalog, który zawiera pliki związane z e-fakturami. Obsługiwane są ścieżki UNC. E-faktury mogą być pojedynczymi plikami w folderze lub mogą być rozmieszczone w podfolderach. Należy pamiętać, że w każdym podfolderze przetwarzany jest tylko jeden plik e-faktury.
  • Przetworzone e-faktury — w tym folderze będą umieszczane e-faktury (lub podfoldery z e-fakturą), które zostały poprawnie przeniesione do interfejsu
  • Błędne e-faktury — do tego folderu przenoszone są e-faktury, które formalnie zawierają e-fakturę, przykładowo plik PDF/A-3 z osadzonym plikiem ZUGFeRD-invoice.xml, ale które nie mogą być przeniesione do interfejsu
  • Pliki bez e-faktur/wspierany format — ten folder służy do przenoszenia e-faktur, które formalnie nie zawierają e-faktury lub jeśli format e-faktury nie jest obsługiwany, tzn. nie jest aktywowany
  • E-faktury z oznaczeniami testowymi — do tego folderu przenoszone są e-faktury ze wskaźnikiem testowym. E-faktura również nie jest przenoszona do interfejsu. Ten folder jest używany tylko dla rzeczywistych systemów. W przypadku systemów testowych, wszystkie e-faktury są przenoszone do interfejsu.
  • Przenieś do podfolderu ze znacznikiem czasu — jeśli parametr nie jest aktywowany, przeniesiony plik otrzymuje znacznik czasu podczas przenoszenia. Jeśli parametr jest aktywny, przenoszenie do powyższych folderów docelowych odbywa się zawsze do podfolderu, który ma nazwę pliku lub katalogu, uzupełnioną o aktualny znacznik czasu. Jeśli plik lub katalog już istnieje w folderze docelowym, jest przenoszony z wartością true.
  • Liczba zadań dla przetwarzania równoległego — maksymalna liczba e-faktur z tej definicji katalogu, które mają być przetwarzane równolegle (wartość domyślna to 1). Wartość x>1 powinna być współmierna do wydajności i pamięci RAM komputera.
  • Organizacja/firma powiązana z definicją katalogu — organizacja powiązana z definicją katalogu. Jeśli nie można przypisać organizacji za pomocą numeru GLN/wyszukiwania partnera dla różniącego się odbiorcy faktury lub kupującego, organizacja podana w tym miejscu jest przypisywana do e-faktury w interfejsie. Więcej informacji można znaleźć w rozdziale Faktury zakupu.
  • Adres(y) e-mail, na które można przesyłać informacje o błędach — adresy mailowe pracowników, którzy mają być powiadamiani o błędnych fakturach zakupu. Adresy należy rozdzielić średnikiem. We wszystkich przypadkach nadawca jest taki sam jak w przypadku informacji do administratorów. Jeśli nie podano adresu, komunikat o błędzie zostanie wysłany na adresy e-mail administratorów. Jeśli nie ma być wysyłany żaden mail o błędzie, należy wprowadzić wartość *noMail.

Zakładka Kokpit sterujący

Serwer dodatkowo pełni funkcję serwera danych dla kokpitu sterującego. Pozwala to na używanie kokpitu sterującego jako satelity na innych komputerach do monitorowania interfejsu (inne funkcje są wyłączone). Do tego celu istnieją specjalne ustawienia.

  • Port serwera danych — pod tym portem serwer e-faktur udostępnia dane do kokpitu sterującego. Ten sam port musi być podany w ustawieniach dla kokpitu sterującego. Domyślna wartość to 8080.
  • Maksymalna liczba przechowywanych wiadomości — maksymalna liczba komunikatów, które mogą być przechowywane na serwerze i wyświetlane na zakładce Komunikaty w kokpicie sterującym.

Zakładka Logowanie

To, czy i w jakim stopniu odbywa się logowanie aktywności serwera e-faktur, jest ustawiane za pomocą pliku sterującego. Dla e-faktury, jest to domyślnie log4j2.xml w folderze instalacyjnym. Specyfikacja ./log4j2.xml ma takie samo znaczenie, jak brak specyfikacji. Alternatywnie, można podać ścieżkę względną lub bezwzględną do innego pliku sterującego log4j2.

Zakładka Licencja

Dla konwertera Comarch e-Faktura wymagana jest licencja. Szczegóły licencji należy wprowadzić lub zaimportować na tej zakładce.

Za pomocą przycisku [Szczegóły dotyczące tworzenia licencji] można podać informacje do wydania licencji. Licencję użytkownik otrzymuje w formie pliku licxml. Dane licencyjne importuje się za pomocą funkcji Import pliku licencyjnego na zakładce Dodatki kokpitu sterującego. Następnie należy wypełnić następujące informacje:

  • Adres MAC — w tym polu należy wprowadzić adres MAC dla wydanej licencji
  • Identyfikator klienta — w tym polu należy wprowadzić ID klienta, który jest dostarczany razem z licencją
Uwaga
W tym polu nie należy wprowadzać numeru klienta tylko ID klienta.
  • Klucz licencyjny — klucz licencyjny dla wydanej licencji, który musi być wprowadzony w całości. Najlepiej jest go skopiować i wkleić.
Uwaga
Komunikat o błędzie Invalid license key może wynikać z obecności spacji na początku/końcu klucza. Należy je usunąć. Możliwe jest również, że informacje o adresie MAC lub ID klienta są nieprawidłowe.
  • IP lokalnego komputera — w tym polu należy wprowadzić IP komputera
  • Adres IP serwera proxy (jeśli jest dostępny) — w tym polu należy wprowadzić IP serwera proxy do serwera rozliczeniowego Comarch e-faktura

Zakładka System KSeF

Informacje o systemie KSeF pozwalają ustalić, czy nawiązać połączenie ze środowiskiem testowym, czy produkcyjnym. Połączenia z systemem KSeF wymagają odpowiednich czasów oczekiwania między cyklami przetwarzania. Ponieważ liczba identycznych dostępów w ramach określonej jednostki czasu jest ograniczona, przekroczenie tego limitu spowodowałoby wstrzymanie połączenia. Dlatego zaleca się, aby nie schodzić poniżej sugerowanych wartości.

  • Typ systemu KSeF – w tym polu można określić, z którym środowiskiem Krajowego Systemu e-Faktur połączony jest konwerter. Aktualne adresy stron internetowych dla środowisk udostępnione są na stronie https://www.gov.pl/web/kas/api-krajowego-system-e-faktur.
  • Rodzaj certyfikacji – w tym polu można określić rodzaj uwierzytelniania w systemie KSeF
  • Wersja interfejsu – w tym polu można określić wersję API, wykorzystywaną do połączenia z systemem KSeF

Sekcja Worker dla faktury wychodzącej – przesyłanie

  • Prześlij aktywowaną fakturę wychodzącą – za pomocą parametru możliwe jest aktywowanie lub dezaktywowanie przesyłania faktur sprzedaży do systemu KSeF
  • Zakończenie sesji KSeF po maksimum – w ramach jednej sesji, tzn. połączenia z systemem KSeF, możliwe jest przesłanie kilku e-faktur. Dopiero po zakończeniu sesji możliwe jest sprawdzenie statusu Urzędowego Poświadczenia Odbioru (UPO) dla tych faktur. Pole umożliwia zdefiniowanie warunków, po spełnieniu których sesja KSeF zostanie zamknięta. Dostępne są następujące opcje:
    • Liczba faktur wychodzących – maksymalna ilość faktur sprzedaży, które mogą zostać przekazane do systemu KSeF w ramach jednej sesji
    • minuty – maksymalny czas trwania sesji KSeF definiowany w minutach
  • Opóźnienie startu (w ms) – w tym polu można określić, jaki będzie czas opóźnienia otwarcia sesji KSeF. Opóźnienie definiowane jest w milisekundach.
  • Czas oczekiwania między cyklami przetwarzania (w ms) – w tym polu można określić czas oczekiwania pomiędzy poszczególnymi cyklami przetwarzania. Czas oczekiwania definiowany jest w milisekundach. Rekomendowana wartość to 5000.
  • Tryb zapytania o faktury – parametr pozwala na zdefiniowanie sposobu określania statusu faktury. Dostępne są następujące opcje:
    • Za fakturę – status określany jest przy każdorazowym przekazaniu faktury
    • Dla wszystkich faktur sesji – status określany jest po przesłaniu wszystkich faktur w ramach danej sesji KSeF
  • Liczba zapytań o status na fakturę – w tym polu można wprowadzić liczbę prób zapytania o status faktury. Ze względu na to, że nie można oczekiwać natychmiastowej odpowiedzi, należy zezwolić na kilka prób.
  • Czas oczekiwania na żądanie statusu (w ms) – czas oczekiwania między zapytaniami o status faktury. Czas definiowany jest w milisekundach.

Sekcja Worker dla faktury wychodzącej – zapytanie o status (UPO)

  • Aktywowano zapytanie o status faktury wychodzącej (UPO) – parametr pozwala na aktywowanie lub dezaktywowanie zapytania o status e-faktury w systemie KSeF. Zapytania te określają Urzędowe Poświadczenia Odbioru, które mogą zawierać potwierdzenia dla jednej, jak i kilku e-faktur.
  • Opóźnienie startu (w ms) – w tym polu można określić, jaki będzie czas opóźnienia zapytania o status faktury sprzedaży. Opóźnienie definiowane jest w milisekundach.
  • Czas oczekiwania między cyklami przetwarzania (w ms) – w tym polu można określić czas oczekiwania pomiędzy poszczególnymi cyklami przetwarzania zapytań. Czas oczekiwania definiowany jest w milisekundach. Rekomendowana wartość to 20000.
  • Folder do składania UPO – w tym polu można wskazać domyślny folder w kstore wykorzystywanej bazy danych, w którym umieszczane będą Urzędowe Poświadczenia Odbioru. Ścieżka folderu musi zaczynać się od Documents. Wpis {org} jest zastępowany numerem partnera Comarch ERP Enterprise według użytkownika, przykładowo: Documents/_eRechnung/UPOs/{org}

Sekcja Worker dla faktur przychodzących

  • Faktura przychodząca aktywowana – za pomocą parametru możliwe jest aktywowanie lub dezaktywowanie przesyłania faktur zakupu z systemu KSeF
  • Opóźnienie startu (w ms) – w tym polu można określić, jaki będzie czas opóźnienia startu przesyłania faktur zakupu. Opóźnienie definiowane jest w milisekundach.
  • Czas oczekiwania między cyklami przetwarzania (w ms) – w tym polu można określić czas oczekiwania pomiędzy poszczególnymi cyklami przetwarzania. Czas oczekiwania definiowany jest w milisekundach. Rekomendowana wartość to 121000.

Zakładka Użytkownicy KSeF

Użytkownicy rejestrowani są w systemie KSeF za pomocą numeru NIP. Dostęp do środowiska produkcyjnego KSeF można uzyskać poprzez https://ksef.mf.gov.pl/web/ lub https://ksef.mf.gov.pl/web/login. Do środowiska testowego można uwierzytelnić się za pomocą https://ksef-test.mf.gov.pl/web/ lub https://ksef-test.mf.gov.pl/web/login. W razie konieczności należy przypisać tokeny z uprawnieniami.

W zależności od sposobu uwierzytelniania, do logowania wykorzystywane są tokeny lub certyfikaty.

  • CEE Partner – pole zawiera identyfikatory partnerów, którzy mogą wysyłać i odbierać e-faktury. Przyciski [Edytuj], [Wyświetlacz], [Nowość] i [Usuń], znajdujące się po prawej stronie pola, umożliwiają wprowadzanie w nim zmian.

Sekcja Szczegóły połączenia KSeF dla wybranych partnerów CEE:

  • CEE Partner – pole zawiera identyfikator partnera wyświetlanego wpisu
  • Numer identyfikacji podatkowej (NIP) – pole zawiera numer identyfikacji podatkowej partnera
Uwaga
Aby transfer faktur pomiędzy konwerterem Comarch e-Faktura a Krajowym Systemem e-Faktur przebiegał pomyślnie, numer NIP Partnera musi zostać zarejestrowany w systemie KSeF.
  • Token połączenia – pole zawiera token, wykorzystywany do rejestracji partnera w systemie KSeF
  • Certyfikat – pole zawiera ścieżkę, w której znajduje się certyfikat
  • Hasło do certyfikatu – pole zawiera hasło wykorzystywanego certyfikatu
  • Określanie faktur przychodzących – jeśli ten parametr jest aktywny, a na zakładce System KSeF aktywowano i zdefiniowano Ustawienia dla faktur zakupu, e-faktury zakupu pobierane są z systemu KSeF dla organizacji o wskazanym numerze identyfikacji podatkowej
  • Definicja faktury przychodzącej w katalogu – lokalizacja, w której umieszczane są pliki e-faktur pobranych z systemu KSeF. W tym miejscu należy wskazać definicję katalogu dla faktur zakupu, zdefiniowaną wcześniej na zakładce Katalogi faktury zakupu w oknie dialogowym Ustawienia serwera.

Weryfikacja ustawień

Kokpit migracji sprawdza jedynie, czy dokonano obowiązkowych wpisów i czy są one formalnie poprawne. To czy, na przykład, loginy dla serwerów e-mail, usług sieciowych i kont e-mail są poprawne, ujawnia się dopiero podczas kontroli, gdy serwer konwertera Comarch e-Faktura zostanie uruchomiony.

Te kontrole – bez uruchamiania serwera konwertera Comarch e-Faktura – symuluje się za pomocą pliku wsadowego:

service_check_configuration.bat

W tym celu należy wykonać ten plik w oknie DOS po przejściu do folderu instalacyjnego. Wynik kontroli jest zapisywany w pliku …\Installation Folder\logs\configCheck.txt. Przy ponownym wykonaniu ten plik jest zastępowany, dlatego nie powinien być otwierany za pomocą aplikacji, która blokuje plik, lecz np. za pomocą Notepad++. Jeśli plik nie zostanie utworzony lub nie zostanie zastąpiony (należy zwrócić uwagę na datę modyfikacji pliku lub najpierw go usunąć), należy zapoznać się z informacjami znajdującymi się w rozdziale Uruchomienie usługi ZT lub kontrola konfiguracji usługi ZT kończy się niepowodzeniem.

Procedura dla folderu docelowego, który jest inny niż standardowy

Za pomocą pola Inny folder docelowy, znajdującego się w sekcji Sterowanie wydaniem dokumentu e-faktury można zdefiniować alternatywne procedury dla zapisu i przetwarzania pomyślnie utworzonych e-faktur. Poniżej zostanie wyjaśniony efekt dwóch z tych ustawień:

W specyfikacjach formatu można podać folder kstore lub folder obszaru roboczego jako wartość w polu Inny folder docelowy. Obszar roboczy również znajduje się w kstore, ale jest niezależny od bazy danych. Przykładowo, możliwe są następujące zapisy:

  • kstore://database/documents/_eInvoice/OutgoingInvoice
  • kstore://workspace/_eInvoice/OutgoingInvoice/ZF21/100-RE3830
  • Documents/_eInvoice/Outgoing invoice

Jeśli specyfikacja niestandardowego folderu docelowego zaczyna się od kstore, specyfikacja folderu jest przejmowana bez zmian. W przeciwnym razie, na początku automatycznie dodawane jest kstore://database/ z bazą danych, wskazaną na zakładce Interfejs. Zatem pierwszy i trzeci przykład odnoszą się do tego samego folderu. Jeśli adresowane są obszary robocze, jak w drugim przykładzie, muszą one zawsze zaczynać się od kstore://.

Uwaga
Obszary robocze są niezależne od bazy danych. Zatem, jeśli tworzona jest kopia instalacji konwertera Comarch e-Faktura, należy użyć innego obszaru roboczego. W przeciwnym razie istnieje ryzyko mieszania danych z systemów produkcyjnego i testowego.

Ponieważ w Comarch ERP Enterprise struktura dla zapisu e-faktur jest tworzona za pomocą zmiennych zastępczych, takich jak {number}, {date}, itd., sensowne jest uwzględnienie tej struktury w niestandardowym folderze docelowym.

Zachowanie struktury można zarządzać poprzez ustawienie wartości większej od zera w polu Uwzględnij foldery nadrzędne (liczba) w sekcji Sterowanie wydaniem dokumentu e-faktury, która definiuje maksymalną liczbę folderów, które zostaną dodane ze ścieżki pliku neutralnego XML (od końca wstecz) do folderu docelowego dla danej faktury. Brakujące foldery dodawane do ścieżki są fizycznie tworzone automatycznie.

Przykład
Zlecenie z neutralnym XML: kstore://APP620DV03/Documents/_eRechnung/2022_10/Org_222

Inny folder docelowy: kstore://workspace/customer_invoices 

Jeśli liczba folderów nadrzędnych = 0, folder docelowy to kstore://workspace/customer_invoices,

czyli bez zmian, a jeśli liczba folderów nadrzędnych = 1, folder docelowy to kstore://workspace/customer_invoices/Org_222,

a jeśli liczba folderów nadrzędnych = 2, folder docelowy to kstore://workspace/customer_invoices/2022_10/Org_222.

Ustawienia kokpitu sterującego

Utrzymanie tych ustawień dla kokpitu sterującego jest analogiczne do ustawień dla serwera. Zostały one opisane w rozdziale Ustawienia serwera.

Uwaga
Aby zmienione dane weszły w życie, kokpit sterujący musi zostać zamknięty i ponownie uruchomiony po ich zapisaniu.

Ustawienia połączenia z serwerem e-faktur

Kokpit sterujący otrzymuje dane wymagane do wyświetlania zawartości interfejsu i jego statusu za pośrednictwem serwera konwertera Comarch e-Faktura. Należy pamiętać, że konwerter musi być uruchomiony.

  • Język dla kokpitu — język dla graficznego interfejsu użytkownika kokpitu. Jeśli nie podano języka, obowiązuje język zgodnie z ustawieniami systemowymi, tzn. zgodnie z formatem regionalnym.
Uwaga
Wyświetlane nagłówki kolumn dla list kodów lub specjalnych konwersji są nadal w języku niemieckim, ponieważ tak jest to zdefiniowane.
  • Adres: port serwera — adres komputera, na którym działa serwer konwertera Comarch e-Faktura oraz port ustawiony dla serwera w polu Port serwera danych w ustawieniach kokpitu sterującego. Specyfikacja ma postać Address:Port.
Przykład

  • http://localhost:8080 (gdy kokpit jest wywoływany na komputerze z serwerem konwertera Comarch e-Faktura)
  • http://111.222.333.444:8080
  • http://kunden.server.com:8080

  • Okres aktualizacji (w ms) — przedział czasu, po którym zawartość na zakładce Komunikaty jest aktualizowana

Logowanie

Logowanie przebiega analogicznie do rozdziału Logowanie.

Wyszukiwanie

W połączeniu z dodatkiem dla e-faktur, opartym na wersji Comarch ERP Enterprise 6.2 lub wyższej, wyszukiwanie faktur sprzedaży można dodatkowo ograniczyć do daty od/do i liczby wyników. To ustawienie nie dotyczy faktur zakupu, ponieważ data przyjęcia jest uwzględniona w numerze faktury. Na tej zakładce ustawiane są wartości domyślne dla tych opcji wyszukiwania. Ponieważ ta wersja aplikacji Comarch ERP Enterprise dla e-faktur nie jest jeszcze dostępna, w polu Wersja systemu CEE należy ustawić wartość 5.4 i wyższe, aby pola wyboru nie były wyświetlane.

  • Wersja systemu CEE — wersja powiązanego systemu Comarch ERP Enterprise
  • Sortowanie domyślne — domyślny rodzaj sortowania e-faktur podczas wyszukiwania
  • Okresy wyszukiwania (w dniach) — wartość dla okresu wyszukiwania mieści się w przedziale od 0 do 100. Wartość równa 0 oznacza brak wstępnie zdefiniowanej daty, tzn. wyszukiwanie nie posiada ograniczeń. Wartość większa od 0 przyjmuje bieżącą datę jako wartość Data do oraz bieżącą datę pomniejszoną o okres wyszukiwania jako wartość Data od.
  • Maksymalna liczba wyników — liczba rekordów danych, które są określane w systemie Comarch ERP Enterprise. W tym polu należy wprowadzić liczbę od 1 do 9999, w przeciwnym razie domyślnie używana jest wartość 999.
  • Ustawienia krajowe — pole ustawia format daty podczas wyszukiwania w zależności od ustawienia kraju. To ustawienie jest niezależne od ustawień w polu Język dla kokpitu.

Konwersja danych

Listy kodów

Dla określonych specyfikacji, w formacie ZUGFeRD definiowane są listy z prawidłowymi wartościami, tzw. listy kodów. Ważnym przykładem są oznaczenia dla jednostek miary. Zamiast szt., ZUGFeRD oczekuje specyfikacji C62 dla sztuki. Dzięki tym listom kodów osiąga się unikalność, która jest konieczna do wymiany faktur z wieloma różnymi partnerami. Te konwersje wartości z wartości list kodów na wartości, które wykorzystywane są w systemie Comarch ERP Enterprise (i odwrotnie), należy wskazać samodzielnie lub sprawdzić, czy konwersje są już wstępnie zdefiniowane. Specyfikacje zgodne z kodowaniem jednostek zdefiniowanym w Comarch ERP Enterprise są brane pod uwagę priorytetowo.

Aplikacja konwersji

Utrzymanie konwersji wartości odbywa się w aplikacji Listy kodów Comarch e-Faktura. Tę aplikację wywołuje się za pomocą funkcji Utrzymanie listy kodów pod przyciskiem [Dodatki] kokpitu sterującego dla różnych formatów e-faktur. Plik definicji dla konwersji jest stały w ustawieniach formatu e-faktur i podany tam plik musi znajdować się w folderze instalacyjnym, np. eRg_CodeListen_Definitions.xml.

Plik z definicjami list kodów można otworzyć za pomocą menu Plik i funkcji Otwórz. Przy uruchamianiu aplikacji Listy kodów Comarch e-Faktura automatycznie otwiera się plik należący do formatu, jeśli taki istnieje.

Pola powyżej tabeli z wartościami list kodów są specyfikacjami wyboru i pomagają w wyszukiwaniu konkretnych rekordów. Wartość mapowania wartości z Comarch ERP Enterprise jest przypisywana do wartości z listy kodów poprzez uaktywnienie kolumny Wartość mapowania do edycji, dwukrotnie klikając lub klikając raz, a następnie naciskając [F2]. Uaktywnienie edycji działa tylko dla list kodów, które są przeznaczone do specyfikacji utrzymania. Aby następnie zapisać dane, nie można jednocześnie edytować wartości, tzn. trzeba opuścić pole.

Listy kodów, które nie podlegają utrzymaniu, nie są używane, albo mają specyficzną konwersję nie potrzebują konwersji, ponieważ Comarch ERP Enterprise używa tych wartości w tym samym znaczeniu.

Atrybuty listy kodów są określone przez plik eRg_Codelisten_Usage.xml, tzn. są nadpisywane, jeśli plik ten znajduje się w katalogu instalacyjnym. Jeśli eRg_Codelisten_Usage.xml zawiera również wartości domyślne dla niektórych wartości, są one przejmowane, jeśli dla powiązanej wartości listy kodów nie ma jeszcze żadnej specyfikacji. Tego pliku należy używać podczas pierwszej instalacji jako pomocy lub podczas aktualizacji, jeśli jest to podane w przyszłych informacjach o wersji. W szczególności atrybuty list kodów nie mogą być zmieniane, ponieważ mają wpływ na działanie programu.

Wspierane listy kodów

Listy kodów z prawidłowymi wartościami są częścią instalacji. Pliki list kodów są również rozróżniane według formatów e-faktur. Ich nazwy plików można znaleźć na zakładce Formaty w ustawieniach. Pliki te muszą znajdować się w katalogu instalacyjnym, np. eRg_Codelisten_Definitions.xml. W przeciwnym razie, odpowiednie szablony można znaleźć w folderze DefaultSpecifications w katalogu instalacyjnym.

Należy utrzymywać następujące listy kodów w pliku listy kodów:

  • PAYMENT_TYPE — sposoby płatności
  • UNIT — jednostki miary

Te listy kodów są ograniczone od samego początku, gdy otwarty zostanie plik definicji listy kodów. Należy utrzymywać tylko te listy kodów. W zależności od formatu e-faktury, mogą istnieć inne listy kodów, ale nie trzeba ich utrzymywać.

Podczas podawania wartości mapowania, jeśli są dostępne, należy podać kod jednostki dla jednostki Comarch ERP Enterprise. Zapewnia to niezależną od języka konwersję z kodów ZUGFeRD UNIT i na nie. To, które kodowanie jednostek obowiązuje, jest zapisane w systemie Comarch ERP Enterprise w funkcji Wymiana danych w aplikacji Konfiguracja. Jeśli jednostka nie zawiera żadnej specyfikacji w kodowaniu jednostek, sama jednostka jest używana do konwersji.

Inne listy kodów, np. TAX_CATEGORY, mogą zostać uaktywnione przez zmianę wyboru opcji utrzymania i ewentualnie zastosowania z profilu ZUGFeRD.

Kompletne listy kodów

Listy kodów zawarte w definicji dostawy powinny być kompletne, z wyjątkiem jednostek miary na liście kodów UNIT. Ponieważ istnieje duża liczba możliwych wpisów na liście kodów UNIT, dostawa została ograniczona do najczęstszych. Jeśli użytkownik potrzebuje dodatkowych kodów UNIT, można je wprowadzić za pomocą przycisku [Dodatki] i funkcji Nowa wartość listy kodów. Więcej informacji na ten temat można znaleźć w rozdziale UNECE – Jednostki miary i opakowania.

Standaryzowane listy kodów

Wartości, które można używać na listach kodów lub w specjalnych konwersjach, są pobierane ze standaryzowanych specyfikacji. Te wartości domyślne są przechowywane w podfolderze Dokumente\Info_Codeliste_UNIT w plikach:

  • ZUGFeRD_1p0_c1p0_Codelists.xlsx (dla ZUGFeRD 1.0)
  • EN16931 code lists values used from 2020-06-30.xlsx (dla ZUGFeRD 2.1 i XRechnung)

Wartości te są również częściowo już obecne w utrzymaniu list kodów i mogą być wartościami docelowymi w specjalnej konwersji, np. jako kategoria kontrolna.

UNECE – Jednostki miary i opakowania
FatturaPA

Ten rozdział nie dotyczy formatu FatturaPA, ponieważ nie ma tam przepisów dotyczących kodów jednostek miary.

ZUGFeRD 1.0

Jednostki opakowaniowe nie są jednostkami miary i są zdefiniowane w UNECE Recommendation No. 21. Aktualnie możliwe kody dla jednostek miary i jednostek opakowaniowych są wymienione w folderze instalacyjnym w podfolderze Dokumente\Info_Codeliste_UNIT w plikach rec20_Rev12e_2016.xls i rec21_Rev9e_2012.xls.

ZUGFeRD 2.1 i XRechnung

Procedura jest analogiczna do opisanej w ZUGFeRD 1.0. Odpowiednie kody można znaleźć w pliku EN16931 code lists values used from 2020-06-30.xlsx, który umieszczony jest w podfolderze Dokumente\Info_Codeliste_UNIT.

KSeF

Ten rozdział nie dotyczy KSeF, ponieważ nie ma tam przepisów dotyczących kodów dla jednostek miary.

Specjalne konwersje

Oprócz list kodów istnieją specjalne konwersje dla Comarch ERP Enterprise. Nowa wartość jest określana przez kombinację innych wartości.

Aplikacja konwersji wartości

Do definiowania tych konwersji wartości istnieje oddzielna aplikacja, która jest wywoływana za pomocą funkcji Utrzymanie konkretnych konwersji, dostępnej pod przyciskiem [Dodatki] w menu kokpitu sterującego dla różnych formatów e-faktur. Plik definicji dla specjalnych konwersji jest stały w ustawieniach formatu e-faktur i podany tam plik musi znajdować się w folderze instalacyjnym, np. eRg_Conversion_CEE.xml.

Aby utrzymywać dane, można wyświetlać różne konwersje za pomocą pola wyboru Konwersja. Kolumny wyświetlają najpierw wartości dla kombinacji (wartości kluczy), a następnie kolumnę dla wartości docelowej (etykieta kolumny kończy się na (target value)). Poprzez dwukrotne kliknięcie można ją zmienić. Okna na wierszu należy natomiast użyć, aby utworzyć nowe wpisy lub usunąć aktualnie wybrany wpis. Należy pamiętać, że aby zapisać dane, nie można jednocześnie edytować wartości.

Wspierane konwersje wartości

Poniżej opisano specjalne konwersje dla Comarch ERP Enterprise, które są dostarczane i utrzymywane przez użytkownika.

Ogólne konwersje wartości

Następujące konwersje są niezależne od formatu e-faktury (nawet jeśli muszą być utrzymywane oddzielnie dla każdego formatu):

  • Dane bankowe organizacji — ponieważ faktura nie zawiera danych bankowych z modułu księgowości, w przypadku sposobu płatności Przelew bankowy (=MP05 w FatturaPA) dane bankowe są określane na podstawie tej tabeli. Dla każdej organizacji można utworzyć kilka kont bankowych. Dwukrotne kliknięcie na komórkę w kolumnie Konto preferowane pozwala wskazać za pomocą true, że to konto ma być używane dla organizacji.
  • Wielokrotne przypisanie do jednej jednostki — na liście kodów UNIT możliwe są tylko przypisania jednostek miary w relacji 1:1. Często klienci mają inne lub bardziej szczegółowe jednostki, niż są one przewidziane w ich systemie Comarch ERP Enterprise. Ta konwersja pozwala na przypisanie różnych przychodzących jednostek miary do tej samej jednostki Comarch ERP Enterprise, albo ogólnie, albo tylko w odniesieniu do określonego partnera.
ZUGFeRD and XRechnung
  • Kategoria podatku dla faktury sprzedaży — na podstawie kombinacji kodu kraju, typu podatku VAT, klucza VAT Comarch ERP Enterprise oraz stawki podatku, definiowana jest kategoria podatku ZUGFeRD. Jako kategoria podatku prawidłowe są tylko wartości z listy kodów TAX_CATEGORY, a jako kod kraju tylko wartości z listy kodów COUNTRY. Pochodzenie kodu kraju jest zdefiniowane w eRg_Conversion.xml. Domyślnie kod kraju jest określany na podstawie adresu sprzedawcy. Dla kodów podatkowych dotyczących pozycji ze zwolnieniem z podatku od sprzedaży lub sprzedaży niepodlegającej opodatkowaniu, należy również podać powód zwolnienia z podatku, zgodnie z przepisami prawnymi.
Uwaga
Dla stawek podatku należy pominąć zera na końcu miejsc dziesiętnych. Tzn. zamiast 19.50 wprowadzić 19.5, a zamiast 7.00 wprowadzić 7. Wartość 19 pozostaje niezmienna.
Wskazówka
Ponieważ powód zwolnienia z podatku nie może być jeszcze określony na podstawie aplikacji, informacja ta musi być ustawiona powyżej tego wskazania.
  • Klucz podatku naliczonego CEE dla faktury zakupu — klucz podatku naliczonego Comarch ERP Enterprise ustawiany jest na podstawie kombinacji kodu kraju, typu podatku VAT, kategorii podatku ZUGFeRD, procentowej stawki podatku oraz powodu zwolnienia z podatku. Jako kategoria podatku prawidłowe są tylko wartości z listy kodów TAX_CATEGORY, a jako kod kraju tylko wartości z listy kodów COUNTRY. Pochodzenie kodu kraju jest zdefiniowane w eRg_Conversion.xml. Domyślnie kod kraju jest określany na podstawie adresu kupującego. Przy określaniu klucza podatku naliczonego uwzględniany jest powód zwolnienia z podatku, ignorując różnice w wielkości liter. Jeśli nie ma dopasowania, wyszukiwanie jest powtarzane z pustą wartością dla powodu zwolnienia z podatku. Dlatego sensowne jest również wprowadzanie definicji z pustą wartością dla powodu zwolnienia z podatku dla kategorii podatkowych dotyczących zwolnienia z podatku od sprzedaży lub sprzedaży niepodlegającej opodatkowaniu. Dla konwersji narzutów/rabatów oraz kosztów transportu i opakowania na poziomie nagłówka, dla pewnych kombinacji wymagane są powiązane pozycje rozliczeniowe. Należy je wtedy wprowadzić w odpowiednich kolumnach. Opisy pozycji rozliczeniowej można dodać w kolumnach dla oznaczenia.
Uwaga
Dla stawek podatku należy pominąć zera na końcu miejsc dziesiętnych. Tzn. zamiast 19.50 wprowadzić 19.5, a zamiast 7.00 wprowadzić 7. Wartość 19 pozostaje niezmienna.
  • Rodzaj faktury zakupu — do określenia rodzaju faktury zakupu nie są obecnie przewidziane żadne specyfikacje ani listy kodów w formacie ZUGFeRD. Dlatego to przypisanie jest używane do próby ustawienia rodzaju faktury zakupu na podstawie specyfikacji typu dokumentu faktury. Na podstawie kombinacji organizacji, która będzie odbiorcą faktury oraz rodzaju dokumentu definiowany jest rodzaj faktury zakupu. W ZUGFeRD 1.0 typ dokumentu to wartość znaleziona w XML faktury pod HeaderExchangedDocument/Name (typ dokumentu). W ZUGFeRD 2.1 i XRechnung ta specyfikacja nie jest już dozwolona, więc wartość dla typu dokumentu składa się z typu faktury (pod HeaderExchangedDocument/TypeCode w XML, wartość to zazwyczaj 380) i, w zależności od znaku kwoty całkowitej faktury, _POSITIVE_AMOUNT lub _NEGATIVE_AMOUNT, więc, przykładowo, ma wartość 380_POSITIVE_AMOUNT.
  • Definicje czyszczenia znaków — pole zostało szczegółowo opisane w rozdziale FatturaPA, ponieważ dotyczy przede wszystkim tego formatu e-faktury
  • Kontakt z dostawcą/dane kontaktowe odpowiedzialnego pracownika — XRechnung wymaga następujących informacji: numer partnera odpowiedzialnego pracownika, zgodny z zamówieniem sprzedaży, należy wprowadzić w polu Pracownik CEE. Dane dla Numeru telefonu i E-mail są również obowiązkowe. Jeśli w polu Nazwa nie wprowadzono żadnej nazwy, używana jest nazwa przeniesiona z Comarch ERP Enterprise. Jeśli wprowadzono, to ta nazwa zostanie wpisana w XML XRechnung. Ta konwersja jest również używana do podania ogólnego adresu e-mail dla sprzedawcy. Jest on dodawany do numeru partnera organizacji. Ten adres e-mail jest następnie używany preferencyjnie dla danych sprzedawcy. Jeśli nie ma dostępnych informacji, używany jest adres e-mail nadawcy z interfejsu zgodnie z szablonem dokumentu.
FatturaPA
  • Klucz kontrolny dla Natura — na podstawie kombinacji stawki podatku i klucza VAT Comarch ERP Enterprise, ustawiany jest kod FatturaPA dla powodu zwolnienia z podatku Natura. Dla podatków ze stawką 0%, podawana jest odpowiednia wartość Natura N1-N7. Klucze VAT dla stawek powyżej 0% również są oczekiwane, w takim przypadku specyfikacja Natura pozostaje pusta.
Uwaga
Dla stawek podatku należy pominąć zera na końcu miejsc dziesiętnych, tzn. zamiast 19.50 wpisuje się 19.5, a zamiast 7.00 – 7. Wartość 19 pozostaje 19.
Wskazówka
Ponieważ powód zwolnienia z podatku nie może być jeszcze określony w aplikacji, informację tę należy ustawić w polu powyżej tego wskazania. Specyfikacja Natura może być również poprzedzona prefiksem BOLLO_. Więcej informacji na ten temat można znaleźć w rozdziale Ignorowanie pozycji Natura przy obliczaniu minimalnej kwoty Bollo.

Jako dodatkową wartość, w kolumnie Esigibilita można ustawić termin płatności inny niż domyślna wartość I. Dla podatków z wartościami S lub D, w Comarch ERP Enterprise wymagane są oddzielne klucze kontrolne.

Uwaga
Faktury ze stawkami podatku, które zawierają pozycje z tymi samymi stawkami procentowymi, ale z różnymi wartościami esigibilitas (np. bez esigibilita, tzn. z wartością domyślną I oraz z esigibilita=S) nie powinny być umieszczane na jednej fakturze. Ponadto, w celu generowania e-faktur FatturaPA 1.3 dla faktur zakupu Comarch ERP Enterprise od zagranicznych dostawców, należy podać odpowiednie informacje dla użytych tam kluczy podatku naliczonego.
  • Klucz podatku naliczonego FatturaPA — dla faktur zakupu, na podstawie kombinacji stawki podatku i Natury, przypisywany jest odpowiedni klucz podatku naliczonego zgodnie z Comarch ERP Enterprise. Dla każdego klucza podatku naliczonego można podać pseudoartykuł zakupu. Pozycja zostanie zaimportowana pod tym pseudoartykułem w połączeniu z opisem pozycji (Descrizione). Każdy klucz podatku naliczonego powinien używać własnego (unikalnego) pseudoartykułu. Ponieważ w FatturaPA kody pozycji nie są obowiązkowe, należy używać tego rodzaju importu. Więcej informacji na ten temat można znaleźć w rozdziale Zastosowanie pseudoartykułu.
  • Rodzaj faktury zakupu — rodzaj faktury zakupu jest określany na podstawie kombinacji organizacji, która otrzyma fakturę oraz rodzaju dokumentu (TipoDocumento)
  • Definicje czyszczenia znaków — FatturaPA ma bardziej rygorystyczne specyfikacje dotyczące dozwolonych znaków i podziałów wierszy. Funkcja ta może być używana do specyficznego usuwania niedozwolonych znaków. Jest ona aktywowana w ustawieniach dla odpowiedniego formatu do usuwania nieprawidłowych znaków. Więcej informacji na ten temat można znaleźć w rozdziale Formaty. Nową definicję można dowolnie nazwać. Specyfikacja w polu XPath expression musi być prawidłową specyfikacją XPath, która wybiera elementy z wartościami obecnymi w FatturaPA-XML. Tzn. //Indirizzo znajduje wszystkie szczegóły ulic w FatturaPA XML. Jako definicja dozwolonych znaków, dopuszczalne są następujące wartości:
    • Normalized
    • Latin
    • LatinNormalized
    • LatinSuppl
    • LatinSupplNormalized

Część Normalized, zawarta w nazwie oznacza, że w szczególności podziały wierszy i tabulatory są usuwane. Latin oznacza, że dozwolone są tylko znaki ASCII (Unicode #x0000-#x007F), a LatinSuppl dodatkowo dopuszcza górny zakres ISO 8859-1 (Unicode #x0000-#x00FF). Wartości true, false, 1, 0 i brak specyfikacji są prawidłowe dla specyfikacji Zastąp spacją. Jeśli wartość wynosi true lub 1, podział wiersza lub nieprawidłowy znak (lub bezpośrednio następujące po sobie) jest zastępowany spacją. Z zawartości elementów znalezionych zgodnie ze specyfikacją XPath, znaki lub podziały są usuwane lub zastępowane spacją, jeśli nie są zawarte w powiązanej definicji dozwolonych znaków.

  • Kontrola rodzaju faktury sprzedaży — dla rodzaju faktury sprzedaży Comarch ERP Enterprise typ faktury (TipoDocumento) jest określany jako wartość docelowa. Nie wolno podawać TD01 lub TD04, ponieważ wartości te zostaną zignorowane. Przykładowo, dla TD02 (faktura zaliczkowa), muszą istnieć oddzielne typy faktur (i rodzaje zamówień sprzedaży, jeśli mają zastosowanie) i nie powinno być faktur korygujących.
Uwaga
Znak całkowitej kwoty faktury/faktury korygującej Comarch ERP Enterprise jest używany do określenia, czy dla faktury FatturaPA ma być wybrany TD01 (faktura) czy TD04 (faktura korygująca).

Ta tabela jest również używana do mapowania typów faktur zakupu, gdy e-faktury są generowane z faktur zakupu Comarch ERP Enterprise. Dla takich zagranicznych faktur zakupu zawsze musi istnieć specyfikacja konwersji w FatturaPA 1.3, ponieważ potrzebne są typy dokumentów TD17 – TD19. Za istnienie takich definicji odpowiedzialny jest użytkownik.

Aby odróżnić typy faktur zakupu od typów faktur sprzedaży, typy faktur zakupu muszą być poprzedzone prefiksem IN_.

Przykład
Wartość IN_200 musi być wprowadzona jako typ faktury zakupu, jeśli użytkownik chce przypisać inny typ dokumentu do typu faktury zakupu 200. Natomiast wartość 22 dotyczy tylko typów faktur sprzedaży Comarch ERP Enterprise.
  • Numer identyfikacji routingu odbiorcy faktury zakupu (CodiceDestinario) — w organizacjach zakupu Comarch ERP Enterprise, w których e-faktury są tworzone na podstawie zagranicznych faktur zakupu należy wprowadzić ich numer identyfikacji routingu (CodiceDestinario). Są to więc państwa własne CodiceDestinario.
  • Zamiar rozliczenia podatku (dichiarazioni d’intento) — do każdej pozycji faktury z kluczem podatkowym 0% ze wskazaniem Natura N3.5 (lub BOLLO_N3.5) musi być przypisany zamiar podatkowy. Odpowiednie informacje muszą być zdefiniowane dla tych kluczy podatkowych. Ta konwersja definiuje numer protokołu z kolejnym numerem wraz z datą odbioru przez urząd skarbowy do klienta, kluczem kontrolnym i na określony okres. Na klucz składa się kombinacja Klient, Klucz kontrolny i Data do. Należy upewnić się, że specyfikacja Data do nie powoduje nakładania się okresów. Numer protokołu deklaracji dichiarazioni d’intento wydanej przez urząd skarbowy ma 17 cyfr. Oddzielona myślnikiem lub ukośnikiem następuje 6-cyfrowa liczba kolejnościowa, która musi być wprowadzona w całości przy wskazaniu kolejnego numeru protokołu. Należy pamiętać, że wszystkie wartości dat muszą mieć wartość w formacie ISO YYYY-MM-DD.
Uwaga
Jeśli dla klienta dostępne są różne deklaracje na ten sam okres, należy użyć dla nich różnych kluczy kontrolnych.
Wskazówka
Nowsze formaty nie zawierają żadnych danych przykładowych, ponieważ dane można przejąć z istniejących formatów za pomocą przeniesienia danych definicji. Tylko dla ZUGFeRD 1.0 i FatturaPA dane przykładowe są nadal dostępne w dostawie w danych specyficznych, których można użyć jako szablonów, jeśli zdefiniowane są dane.
KSeF
  • Alokacja KSeF na podatki — kombinacja kraju dla klucza podatkowego, klucza VAT, wprowadzonego w Comarch ERP Enterprise, rodzaju podatku, procentowej stawki podatku oraz waluty faktury określają rozłożenie kwot netto i kwot podatku na odpowiednie elementy KSeF za pomocą prawidłowej specyfikacji KSeF w polu Nazwa elementu dla wartości. Używane są także przykładowo, P_13_1, P_14_1 i, w razie potrzeby, P_14_1W. Prawidłowy wpis KSeF może być również dokonany w polu Stawka podatku, jeśli jest to wymagane (np. zw, oo, np). Prawidłowe informacje można pobrać z opisu KSeF lub z podpowiedzi dla nagłówka kolumny.
  • Rodzaj faktury zakupu — dla każdej organizacji Comarch ERP Enterprise i każdego typu faktury KSeF (VAT, ZAL, ROZ, KOR, ZAL-KOR, ROZ-KOR) można określić, który typ faktury zakupu Comarch ERP Enterprise ma być ustawiony jako domyślny
  • Kod podatku wyjściowego — na tej zakładce ustawiane są wartości domyślne dla kluczy podatkowych Comarch ERP Enterprise. Dla wartości z P_13_1, P_14_1, itp. w formacie KSeF, odpowiednie informacje o typie podatku i stawce podatku są już dostępne.
  • Dane rejestru handlowego — dane rejestru handlowego można wprowadzić dla każdej organizacji. Wartości te są następnie dodawane do KSeF jako dane typu Stopka. Nie jest to wpis obowiązkowy.

Rabaty i opłaty za usługi jako pozycja faktury

Uwaga
Ten rozdział nie dotyczy FatturaPA, ponieważ nie ma tam takich nagłówków.

W Comarch ERP Enterprise narzuty/rabaty oraz koszty transportu i opakowania są wykazywane na fakturach jako pozycje. W przypadku faktur zakupu, koszty te lub rabaty mogą być wykazywane na poziomie nagłówka. Aby można było przetwarzać te dane przez Comarch ERP Enterprise, dane te są przenoszone jako pozycja faktury ze zdefiniowanymi pozycjami rozliczeniowymi podczas transferu do Comarch ERP Enterprise. Pozycje rozliczeniowe, które mają być do tego użyte, należy zdefiniować w utrzymaniu specjalnych konwersji dla kluczy podatku naliczonego dla odpowiedniej kategorii podatkowej/stawki podatkowej. Więcej informacji na ten temat można znaleźć w rozdziale Utrzymanie konwersji wartości.

Zapewnienie dostępności serwerów

Po zainstalowaniu serwera i powiązanej usługi zgodnie z rozdziałem Instalacja, należy upewnić się, że serwer działa lub jest zatrzymany podczas tworzenia kopii zapasowych. Najprostszym sposobem jest kontrolowanie usługi za pomocą właściwości Typ uruchamiania lub uruchamianie i zatrzymywanie usług w aplikacji Windows.

Należy zauważyć, że po zakończeniu działania powiązanego serwera aplikacyjnego, serwer e-faktur również zostanie automatycznie zakończony. Serwer będzie działał tylko wtedy, gdy powiązany serwer aplikacyjny jest aktywny. Istnieją również inne błędy, w wyniku których serwer e-faktur może się samoczynnie zakończyć. We wszystkich przypadkach administratorzy (zgodnie z informacjami zawartymi w rozdziale Serwer pocztowy) zostaną powiadomieni o sytuacji mailowo, jeśli jest to możliwe, tzn. jeśli serwer pocztowy jest dostępny.

W takich przypadkach usługę uruchamia się ręcznie lub za pomocą polecenia:

net start „Comarch_eInvoice_Service”

Serwer / usługa jest zatrzymywana albo za pomocą kokpitu sterującego, ręcznie za pośrednictwem aplikacji Windows Usługi, albo za pomocą polecenia:

net stop „Comarch_eInvoice_Service”

Używając kombinacji poleceń net do zatrzymywania/uruchamiania, można zrestartować serwer po nocnych kopiach zapasowych lub ustawić okna czasowe, w których e-faktury są przetwarzane.

Ustawienia CEE dla formatów ZUGFeRD

ZUGFeRD rozróżnia formaty Basic, Comfort i Extended. Comarch dostarcza dane dla formatu Comfort. W ZUGFeRD 2.1 i w XRechnung format Comfort odpowiada formatowi EN 16931.

Jednak dla formatu Comfort, teksty nagłówka i pozycji muszą posiadać przypisany kod tematyczny, w zależności od treści. Kwalifikuje to tekst zgodnie z typem treści:

Kod Oznaczenie Zastosowanie w ZUGFeRD Przykład
(puste) Informacje ogólne, dowolne teksty Żaden kod tematyczny nie jest używany dla wszystkich tekstów, nawet w profilach Comfort i Extended.
  • Zgodnie z rozmową z panią Kowalską
  • Mamy urlop firmowy do 05.01.
REG Informacje regulacyjne Szczegóły dotyczące firmy świadczącej usługi (podać dyrektora zarządzającego, numer w rejestrze handlowym itp.) ZUGFeRD KG Siedziba Stuttgart Sąd rejonowy – Sąd rejestrowy – Stuttgart HRA 1234
AAK Informacje dotyczące warunków cenowych Szczegóły dotyczące obniżek opłat Obowiązują umowy o rabatach i bonusach.
AAJ Dodatkowe warunki do zakupu Informacje o zastrzeżeniu własności Towar pozostaje naszą własnością aż do pełnej zapłaty
PMT Informacje o płatności Powiadomienie o cesji wierzytelności Ustaliliśmy cesję z firmą XYZ. Proszę opłacić nasze faktury firmie XYZ z następującymi danymi bankowymi…
Uwaga
Dalsze szczegóły można znaleźć w dokumencie ZUGFeRD_1p0_c1p0_Codelisten.xlsx, znajdującym się w folderze instalacyjnym w podfolderze Dokumente\Info_Codeliste_UNIT. W szczególności, znajdzie się tam również tabela dla tekstów pozycji. Należy również zwrócić uwagę na arkusze Free texts (header) i Free texts (line item).

Jeśli w fakturach są umieszczane teksty nagłówka lub pozycji, które otrzymują takie informacje, należy klasyfikować ich teksty za pomocą kodów tematycznych. Jest to ważne, ponieważ w przeciwnym razie e-faktura nie będzie zgodna z formatem ZUGFeRD Comfort.

W tym celu należy wprowadzić takie teksty w Comarch ERP Enterprise jako stałą tekstową w formacie HTML i nadać im atrybut data-cei-texttype, który zawiera typ tekstu (kod) jako wartość.

Przykład

Przykładowy element tekstowy <html><p data-cei-texttype=”AAK”>Obowiązują umowy rabatowe</p><html>

Jeśli na wydruku faktury PDF znajdują się warunki płatności, użytkownik powinien przynajmniej odwołać się do nich za pomocą ogólnego tekstu w zamówieniu sprzedaży, przykładowo, Obowiązują umowy rabatowe.

Uwaga
W ZUGFeRD 2.1 i XRechnung kody tematyczne nie mogą być już podawane na poziomach pozycji. Z tego powodu nie jest konieczna zmiana swoich stałych tekstowych Comarch ERP Enterprise. Konwerter Comarch e-Faktura automatycznie usuwa niedozwolone kody tematyczne dla tych formatów.

Wymagania systemowe

System operacyjny i Java

Oprogramowanie działa pod systemem Windows i Java Runtime (1.8 lub Java 17 LTS, inne wersje nie są obsługiwane).

Obsługiwane systemy operacyjne:

  • Windows 2008
  • Windows 7
  • Windows 2008 R2
  • Windows 8
  • Windows 2012
  • Windows 10
  • Windows 2016
  • Windows 2019
  • Windows 11

Konta e-mail

Obsługiwane są tylko konta e-mail z protokołami SMTP (do wysyłania faktur sprzedaży i wewnętrznych powiadomień) i IMAP (do faktur zakupu) lub ich zabezpieczone warianty SMTPS i IMAPS.

Czyste konta serwera Microsoft Exchange nie są obsługiwane. Jednak serwer Microsoft Exchange obsługuje IMAP i SMTP.

Dla poczty wychodzącej konto e-mail musi zezwalać na różnych nadawców. Więcej informacji na ten temat można znaleźć w rozdziale Faktury sprzedaży.

Przeglądarka PDF

Aby wyświetlać e-faktury ZUGFeRD za pośrednictwem kokpitu sterującego, musi być zainstalowana przeglądarka PDF (i ustawiona jako domyślny program w Eksploratorze plików Windows za pomocą przycisku [Otwórz za pomocą]). Więcej informacji można znaleźć w rozdziale Otwieranie pliku przez pop-up w kokpicie sterującym kończy się niepowodzeniem.

Uprawnienia

Użytkownik, z poziomu którego uruchamiany jest serwer e-faktur, musi mieć uprawnienia do katalogu instalacyjnego i katalogu roboczego dla faktur zakupu.

Musi być również dozwolone połączenie z Internetem, a także pobieranie i rozpakowywanie plików *.zip.

Oprócz dostępu do serwera rozliczeniowego pod adresem https://einvoice-accounting.comarch.com musi być również dozwolony dostęp do serwera aktualizacji, tzn. do plików pod adresem https://econnect.comarch.de/comarch_einvoice/ (preferowane) lub http://econnect.comarch.de/comarch_einvoice / (Port 80).

Jest to jedyny sposób na aktualizację konwertera Comarch e-Faktura.

Aby wykonać aktualizację, wywołujący użytkownik musi mieć uprawnienia do odczytu, zapisu i usuwania wszystkich plików i katalogów w całym katalogu instalacyjnym i pod nim.

Licencja

Do uruchomienia serwera potrzebna jest ważna licencja. Klucz licencyjny jest ważny tylko dla komputera lub serwera terminali, na którym działa usługa e-fakturowania.

Do wydania licencji wymagane są następujące informacje:

  • Dane klienta
  • Dane systemu, dla którego wymagana jest licencja
  • Informacje wyświetlone za pomocą przycisku [Szczegóły dotyczące tworzenia licencji]. Dane należy skopiować za pomocą przycisku [Kopiuj tekst].
  • Adres IP serwera proxy, jeśli jest on wykorzystywany do połączenia z serwerem rozliczeniowym
  • Dla adresów IP należy upewnić się, że nie jest wysyłany adres IP sieci wewnętrznej, lecz adres IP, który jest przekazywany na zewnątrz. W tym celu należy przejść na stronę http://request.urih.com/ na komputerze, na którym jest zainstalowany konwerter Comarch e-Faktura. Zewnętrzny adres można znaleźć pod tekstem What is your IP? Whois?. Zewnętrzny adres należy wprowadzić na końcu okna dialogowego Szczegóły dotyczące tworzenia licencji.

Licencja musi być zażądana mailem z właśnie wspomnianymi informacjami. Aby otrzymać licencje należy zawnioskować o nią poprzez system zgłoszeniowy.

Serwer rozliczeniowy

Tryb rozliczeniowy

Rozliczanie przetworzonych e-faktur odbywa się na podstawie transakcji. Przed wysłaniem e-faktury lub przyjęciem e-faktury do interfejsu, usługa sieciowa na serwerze rozliczeniowym na koncie użytkownika zwiększa o jeden liczbę przetworzonych e-faktur. Jeśli dostęp do usługi sieciowej nie jest możliwy lub nie zwraca pozytywnej odpowiedzi, przetwarzanie jest przerywane. Jeśli usługa sieciowa jest ponownie dostępna, dana e-faktura jest ponownie przetwarzana. Za pomocą kokpitu sterującego, używając funkcji Sprawdź serwer rozliczeniowy w menu Serwer, można przetestować, czy dostęp do serwera rozliczeniowego działa i czy użytkownik jest zarejestrowany oraz aktywowany zgodnie ze szczegółami licencji. E-faktury ze wskaźnikiem testowym nie są rozliczane, tzn. jeśli wskaźnik testowy = true (więcej informacji można znaleźć w rozdziale Faktury sprzedaży). Ustawienie System testowy nie jest brane pod uwagę, tzn. e-faktury zakupu bez wskaźnika testowego są również rozliczane w systemach testowych.

Wymagane wywołanie serwera rozliczeniowego zawiera następujące dane:

  • Adres MAC i identyfikator klienta ze szczegółów licencji
  • Numer faktury
  • Data faktury
  • Wskaźnik faktury sprzedaży/zakupu i wskaźnik testowy
  • Wersja konwertera Comarch e-Faktura
  • Wersja Javy, pod którą działa serwer
  • Wersja interfejsu
  • Format e-faktury

Niedostępność serwera rozliczeniowego

Każdego dnia między 0:00 a 1:00 serwer rozliczeniowy jest niedostępny. Jeśli w tym czasie nastąpi dostęp do serwera rozliczeniowego, wystąpi błąd rozliczeniowy. Proces dla faktury sprzedaży lub zakupu jest następnie powtarzany po 30 minutach. W praktyce użytkownik nie powinien więc zauważyć tego przekroczenia czasu. Jednak nie zaleca się przetwarzania faktur w tym przedziale czasowym.

Instalacja

Wymagania wstępne

  • Serwer pocztowy (SMTP) oraz specjalne konta e-mail dla faktur zakupu z protokołem IMAP muszą być dostępne.
Wskazówka
Zaleca się posiadanie oddzielnego adresu e-mail dla faktur zakupu, ponieważ firmowy adres e-mail prawdopodobnie nie jest odpowiedni do ich odbierania. Jeszcze lepszym rozwiązaniem jest udostępnienie oddzielnego adresu e-mail dla faktur zakupu dla każdej organizacji.
  • W przypadku używania potwierdzeń odczytu dla faktur zakupu, muszą one być przetwarzane przez ten sam serwer pocztowy, co powiadomienia dla administratorów.
  • Należy upewnić się, że wymagania systemowe są spełnione.
  • Zmienna środowiskowa JAVA_HOME musi być ustawiona dla wersji Java wymaganej zgodnie z wymaganiami systemowymi.

Obiekty dostawy

Dostawa dla konwertera Comarch e-Faktura składa się z pliku Comarch e-Invoice.zip.

Plik ten zawiera programy, szablony plików sterujących, niniejszy podręcznik i wszystkie inne wymagane obiekty.

Instalacja obiektów

Aby zainstalować obiekty należy:

  1. Rozpakować cały plik Comarch e-Invoice.zip do katalogu na komputerze/serwerze, który jest nazywany katalogiem instalacyjnym.
  2. Podczas początkowej instalacji, następujące pliki muszą zostać umieszczone w katalogu instalacyjnym, a ich nazwy są zgodne z ich przeznaczeniem w tym katalogu. W tym celu należy skopiować odpowiednie pliki z podfolderu DefaultSpecifications.

Odbywa się to poprzez wywołanie pliku wsadowego Copy_CEE_DefaultSpecifiactions_To_InstallFolder.bat. To wywołanie kopiuje następujące pliki do katalogu instalacyjnego i, w razie potrzeby, zmienia ich nazwy:

  • Plik cmag-einvoice-service-app.properties [kodowanie: UTF-8] dla ustawień serwera aplikacji.
  • Plik cmag-einvoice-cockpit-app.properties [kodowanie: UTF-8] dla ustawień kokpitu sterującego.
  • Pliki listy kodów eRg_CodeListen_Definitions.xml [kodowanie: UTF-8 bez BOM] i eRg_Codelisten_Usage.xml [kodowanie: UTF-8 bez BOM].
  • Plik ze specjalnymi konwersjami eRg_Conversion.xml (zmieniony z eRg_Conversion_CEE.xml) [kodowanie: UTF-8 bez BOM].
  • Pliki wsadowe: service.bat, service_start.bat, cockpit_start.bat, set_java_home.bat i service_check_configuration.bat [kodowanie: ANSI].
  • Program prunsrv.exe (jeśli używana jest 64-bitowa wersja Javy, należy skopiować plik prunsrv_amd64.exe i zmienić jego nazwę na prunsrv.exe). Starsze wersje są nadal zawarte w dostawie i mają dodany numer wersji.
  • Kontrola logowania log4j2.xml [kodowanie: UTF-8 bez BOM].
Uwaga
Kodowanie tych plików tekstowych nie może być zmieniane.

Ustawienie wersji Javy do wykonania

W pliku set_java_home.bat można ustawić wersję Javy dla wykonania kokpitów sterujących i serwera.

Przykład
set e-invoice_JAVAPATH=C:\comarch\Java\jdk-17.0.1.12-hotspot

Jest to szczególnie efektywne podczas instalowania usługi dla serwera aplikacji konwertera Comarch e-Faktura. Jeśli usługa ma działać pod inną wersją Javy, należy odinstalować usługę, ustawić nową wersję Javy, a następnie zainstalować usługę ponownie. Więcej informacji można znaleźć w rozdziale Instalacja usługi.

Jeśli wersja Javy nie zostanie określona w pliku set_java_home.bat, podczas instalacji usługi używane są specyfikacje ze zmiennych środowiskowych JAVA_HOME (lub alternatywnie JRE_HOME). W takim przypadku również konieczne jest ponowne zainstalowanie usługi w przypadku zmian. Kokpit (cockpit_start.bat) oraz bezpośrednie uruchomienie usługi będą wtedy używać aktualnie ustawionej wersji Javy.

Za pomocą parametru service installJvmAuto jako pierwszego przy instalacji usługi, np. service installJvmAuto lub service installJvmAuto REAL, można zainstalować usługę w taki sposób, aby wersja Javy była określana automatycznie na podstawie ustawień systemowych. Eliminuje to potrzebę ponownej instalacji przy zmianie wersji Javy.

W tym przypadku wersja Javy jest określana zgodnie z następującą kolejnością wyszukiwania:

  1. Obecna biblioteka Java runtime, zdefiniowana w rejestrze
  2. Obecna JRE, zdefiniowana w rejestrze
  3. Jawnie skonfigurowana JavaHome dla usługi
  4. Obecna JDK, zdefiniowana w rejestrze

(por. np. https://commons.apache.org/proper/commons-daemon/procrun.html)

Wersję Javy używaną aktualnie z parametrem installJvmAuto można znaleźć w pliku logowania einvoice-service.log.

Definiowanie ustawień dla konwertera Comarch e-Faktura

Wszystkie niezbędne specyfikacje do wysyłania i przetwarzania e-faktur są wprowadzane w ustawieniach serwera. Szczegółowy opis można znaleźć w rozdziałach Ustawienia serwera oraz Kokpit sterujący. Wcześniej należy utworzyć lub wyeksportować certyfikat JKS dla użytkownika Comarch ERP Enterprise e-faktury, aby uzyskać dostęp do interfejsu. Po wprowadzeniu ustawień można sprawdzić ich poprawność za pomocą odpowiednich testów, opisanych w rozdziale Testowanie ustawień.

Skrócona instrukcja uruchamiania:

  1. Należy uruchomić kokpit sterujący za pomocą pliku cockpit_start.bat.
  2. Należy otworzyć ustawienia dla serwera za pomocą menu Dodatki -> Ustawienia serwera.
  3. Przejść na zakładkę Licencja, a następnie określić wymagane dane techniczne za pomocą przycisku [Szczegóły dotyczące tworzenia licencji]. Skompilować pozostałe dane i zażądać licencji z adresu referencyjnego zgodnie z opisem w rozdziale Licencja.

Ustawienia należy skonfigurować zgodnie z rozdziałami Ustawienia serwera oraz Kokpit sterujący. Jeśli użytkownik nie posiada jeszcze loginu (użytkownika/hasła) dla serwera rozliczeniowego, należy wprowadzić wartość dummy.

Użytkownik dla konwertera Comarch e-Faktura

Konwerter Comarch e-Faktura komunikuje się z Comarch ERP Enterprise za pomocą usług sieciowych. Wymagany jest do tego użytkownik e-faktury. Dla tego użytkownika musi być również utworzony przypisany partner. Użytkownik e-faktury musi mieć wystarczające uprawnienia, tzn. musi być przypisany do grupy użytkowników Administratorzy. Dodatkowo, dla użytkownika musi być dozwolony dostęp SOAP (Panel System -> Typ System -> Zakładka Przyporządkowania użytkownika).

Tworzenie certyfikatu JKS

Certyfikat JKS tworzy się w aplikacji Panel System pod typem Użytkownik. W tym celu należy utworzyć Certyfikat użytkownika X.509.

Podczas tworzenia certyfikatu JKS, należy wybrać wartość Plik JKS w polu Format. W polu Elementy nazwy domeny nie powinna zostać wprowadzona żadna wartość. W polu Nazwa wspólna zaleca się dodanie -JKS do nazwy użytkownika.

Dane certyfikatu przykładowego użytkownika konwertera Comarch e-Faktura

Testowanie ustawień

Weryfikacja poprawności danych została opisana w rozdziałach System KSeF, Uruchomienie usługi ZT lub kontrola konfiguracji usługi ZT kończy się niepowodzeniem.

Utrzymanie list kodów i specjalnych konwersji

Utrzymanie tych definicji opisane zostało w rozdziałach Konwersja danych i Instalacja obiektów.

Tworzenie definicji filtrów w Comarch ERP Enterprise

Do tworzenia danych XML w interfejsie do konwertera Comarch e-Faktura wymagane są następujące definicje filtrów:

  • CUSTOMER_EINVOICE*
  • SUPPLIER_EINVOICE*

(* to stała uzupełniająca dla formatów, * jest puste dla ZUGFeRD 1.0)

Podfolder CEE_Filterdefinitions zawiera niezbędne pliki do importu tych definicji filtrów. Należy skopiować niezbędne pliki transformacji:

  • CustomerInvoice*.xsl
  • SupplierInvoice*.xsl

do Knowledge Store, do katalogu kstore://Database/eInvoice odpowiedniej bazy danych. Następnie w pliku einvoiceFilter*.xml (gdzie * jest stałą uzupełniającą) należy zastąpić trzy częściowe ścieżki URI kstore://CEEDATABASE/eRechnung/ folderem docelowym plików transformacji.

Następnie za pomocą aplikacji Import danych w Comarch ERP Enterprise należy zaimportować dla obiektu biznesowego com.cisag.sys.tools.bi.obj.FilterDefinition (filtr FILTERDEFINITION) dostosowany plik einvoiceFilter.xml (z opcjami Czytelne bez GUID, jeden język i w znormalizowanym formacie czasu).

Alternatywnie, można samodzielnie zdefiniować filtry eksportu, korzystając z listy atrybutów wymaganych w filtrach eksportu. Filtry należy tworzyć w jednym języku, w znormalizowanym formacie czasu i dostarczyć z odpowiednim plikiem transformacji. Listę atrybutów można znaleźć w podfolderze Documents w pliku FilterAttributes_to_eInvoice_formats.pdf.

Nawet podczas importowania filtrów należy sprawdzić wymagane atrybuty, ponieważ, przykładowo, brakuje atrybutów dla poleceń zapłaty dotyczących szczegółów, takich jak mandaty.

Uwaga
Dla XRechnung 2.0.0 i kolejnych wersji używa się tych samych filtrów/plików transformacji co dla XRechnung 1.2.2. Zasadniczo, można ich również użyć dla ZUGFeRD 2.1.
Uwaga
W przypadku wersji Comarch ERP Enterprise 6.1 i wyższych, należy używać odpowiednich wersji transformacji CEE61 oraz atrybutów taxinfo z innego węzła (szczegóły w liście atrybutów).

Ustawienia w Comarch ERP Enterprise

W Comarch ERP Enterprise należy tworzyć odpowiednie moduły tekstowe dla tekstów, które wymagają kwalifikacji w ZUGFeRD (więcej informacji na ten temat można znaleźć w rozdziale Ustawienia CEE dla formatów ZUGFERD). W razie potrzeby należy również tworzyć neutralne językowo kodowania jednostek.

Aby format faktury ZUGFeRD był dostępny do wyboru dla Comarch e-faktura w Comarch ERP Enterprise u partnera, serwer konwertera Comarch e-Faktura musi zostać pomyślnie uruchomiony przynajmniej raz, ponieważ ustawia tę wartość jednorazowo przy starcie.

Uwaga
Jeśli w ustawieniach zostanie zmieniony system Comarch ERP Enterprise lub baza danych, może się zdarzyć, że ten lub ewentualne przyszłe formaty faktur nie będą jeszcze dostępne na tym środowisku. W takim przypadku właściwości einvoice.format w pliku UpdateAction.properties muszą zostać usunięte lub ustawione na false. Po następnym uruchomieniu serwera konwertera Comarch e-Faktura formaty zostaną wprowadzone do bazy danych Comarch ERP Enterprise.

Uruchamianie serwera konwertera Comarch e-Faktura

W oknie DOS, z ustawioną ścieżką do katalogu instalacyjnego, serwer konwertera Comarch e-Faktura jest uruchamiany za pomocą polecenia service_start.bat. Sposób uruchamiania serwera konwertera Comarch e-Faktura za pomocą usługi został opisany w rozdziale Instalacja usługi.

Instalacja usługi

Do instalacji potrzebne są pliki service.bat i prunsrv.exe. W tym celu należy skopiować te pliki do katalogu instalacyjnego z podfolderu DefaultSpecifications. Instalacja usługi dla serwera konwertera Comarch e-Faktura odbywa się za pomocą okna DOS. W tym celu należy przejść do katalogu instalacyjnego i wywołać polecenie service install.

Powoduje to skonfigurowanie usługi pod nazwą Comarch eRechnung Service i technicznie pod nazwą usługi Comarch_eRechnung_Service.

Nazwę usługi można modyfikować, podając sufiks nazwy jako dodatkowy parametr service install REAL definiujący usługę Comarch_eRechnung_Service_ECHT.

Usługę odinstalowuje się, uruchamiając to samo polecenie ze słowem remove zamiast install.

Jeśli usługa ma być konfigurowana lub usuwana przez innego użytkownika (np. z uprawnieniami administratora), do polecenia na końcu można dodać specyfikację /user xxx, przykładowo:

service install ECHT /user patternadmin
service install ECHT /user domain\patternadmin

Wszystkie dalsze ustawienia należy wprowadzać za pośrednictwem aplikacji Windows Panel sterowania -> Administracja. W szczególności należy sprawdzić/ustawić, pod jakim użytkownikiem lub kontem działa usługa.

Sposób kontrolowania wersji Javy, pod którą usługa jest wykonywana, opisano w rozdziale Ustawienie wersji Java do wykonania. Uruchamianie usługi ma sens tylko wtedy, gdy wszystkie ustawienia są poprawne. W przeciwnym razie usługa lub serwer zakończy działanie z błędami. Aby sprawdzić funkcjonalność serwera, można go również uruchomić za pomocą pliku service_start.bat w oknie DOS z katalogu instalacyjnego.

Uruchomiona usługa działa w menedżerze zadań pod procesami o nazwie prunsrv.

Jeśli użytkownik chce aktywować kilka usług dla serwerów konwertera Comarch e-Faktura na jednym komputerze w tym samym czasie, musi ustawić różne porty dla zdalnego dostępu Javy (jmxremote). Osiąga się to poprzez ustawienie portu w oknie DOS przed wykonaniem polecenia service install za pomocą zmiennej środowiskowej EINVOICE_JMXPORT, przykładowo używając set „EINVOICE_JMXPORT=7777” (bez spacji przed i po znaku =). Bez tej specyfikacji wartość domyślna wynosi 7901.

Logowanie

Poziom logowania

Poziom szczegółowości logowania jest ustawiany w pliku log4j2.xml w atrybucie level w elementach <Logger>. Po fazie wprowadzającej, poziom można zresetować do wartości INFO, np. <Logger name=”com.comarch.einvoice” level=” INFO ” />. Ten poziom automatycznie uwzględnia w logowaniu wszystkie ostrzeżenia i błędy.

Logowanie komunikacji z serwerem pocztowym

Logowanie komunikacji z serwerem pocztowym (opisane również w rozdziale Serwer pocztowy) odbywa się w pliku o nazwie service-name-stdout. Date.log, np. comarch_billing_service-stdout.2016-05-11.log. Jeśli w pliku log4j2.xml domyślnej dostawy włączone zostaną zakomentowane elementy z MailRollingFileApp, logowanie komunikacji z serwerem pocztowym będzie odbywało się zamiast tego w plikach einvoice-service-mail-communication*.

Logowanie dla KSeF

Zapytania do systemu KSeF są logowane w podfolderze KSeF\Protocols.

Plik InvoiceUploadSessions.txt w podfolderze KSeF\Work zawiera tymczasowe informacje o sesjach, w których e-faktury są przesyłane do systemu KSeF. W idealnej sytuacji podfolder jest pusty.

Plik KsefWorkProcessingData.xml w folderze Work również zawiera dane do przetwarzania w systemie KSeF. W szczególności są to informacje o ostatnio pobranej fakturze zakupu dla każdej organizacji.

Informacje w pliku KsefWorkProcessingData.xml nie mogą być usuwane, ponieważ są używane jako czas początkowy, od którego wyszukiwane są nowe faktury zakupu.

Jeśli, przykładowo wpis <maxInvoiceSentTime> jest pusty lub go brakuje, jako czas jest używana godzina 4:00 rano bieżącego dnia.

Instalacja kokpitu sterującego jako satelity

Istnieje możliwość zainstalowania kokpitu sterującego jako satelity, tzn. na innym komputerze.

W tym celu należy skopiować podfolder Comarch_eInvoice_Satellite_Installationfolder do katalogu instalacyjnego, wywołując plik wsadowy Create_Installationfolder_For_Satellite.bat.

Następnie należy skopiować/przenieść ten folder na komputer, np. lokalny PC, na którym ma zostać uruchomiony kokpit satelitarny dla konwertera Comarch e-Faktura.

Tylko część obiektów jest zintegrowana w tym podfolderze, analogicznie do informacji zawartych w rozdziale Instalacja obiektów. Nie są potrzebne następujące pliki:

  • Plik cmag-einvoice-service-app.properties
  • Plik cmag-invoice-service.jar
  • Plik listy kodów eRg_CodeListen_Definitions.xml
  • Plik ze specjalnymi konwersjami eRg_Conversion.xml
  • Pliki wsadowe service.bat, service_start.bat i service_check_configuration.bat
  • Program prunsrv.exe

Plik cmag-einvoice-service.jar w żadnym wypadku nie może być dołączony. Zapobiega to przypadkowej zmianie ustawień na niewłaściwym komputerze. Ustawienia są zawsze utrzymywane lokalnie i muszą być utrzymywane na komputerze (w katalogu instalacyjnym), na którym konwerter Comarch e-Faktura działa jako serwer.

W takim przypadku adresem serwera nie jest http://localhost:8080 lecz adresem i portem serwera, na którym zainstalowany jest konwerter Comarch e-Faktura, przykładowo http://eRechnungsserver4ZT.com:8080. Więcej informacji można znaleźć w rozdziale Kokpit sterujący.

Obecnie nie ma automatycznego aktualizatora dla kokpitów satelitarnych.

Wskazówki

Po pauzie lub kontrolowanym zakończeniu pracy serwera zadania pozostają aktywne

Jeśli zadania pozostają aktywne zbyt długo podczas tych działań, należy spróbować znaleźć w plikach logowania, których e-faktur lub e-maili dotyczy problem w przypadku faktur zakupu i jaka jest przyczyna, dla której zadania nie mogą zostać zakończone. Następnie pozostaje tylko twarde zakończenie pracy serwera, tzn. zakończenie procesu o nazwie prunsrv.exe dla użytkownika, pod którym działa usługa. Faktura sprzedaży będzie miała status Udostępniona. W takim przypadku faktura sprzedaży zostanie ponownie przetworzona po ponownym uruchomieniu. W przypadku faktury zakupu nie powinno być jeszcze wpisu w interfejsie. Jeśli dany e-mail został już przeniesiony z folderu skrzynki odbiorczej, należy go przenieść z powrotem do folderu skrzynki odbiorczej.

Uruchomienie usługi ZT lub kontrola konfiguracji usługi ZT kończy się niepowodzeniem

Zazwyczaj, gdy wywoływany jest plik service_check_configuration.bat, wynik kontroli jest zapisywany w pliku …\folder instalacyjny\logs\configCheck.txt (więcej informacji można znaleźć w rozdziale System KSeF). Jeśli ten plik wyjściowy nie został utworzony, błąd należy ustalić na podstawie logu. Znany problem polega na tym, że port serwera danych jest już używany gdzie indziej lub ZT jest już uruchomiony. W takim przypadku log zawiera wiersze:

java.net.BindException: Address already in use: bind
java.lang.IllegalStateException: Tomcat connector in failed state

Wtedy należy zakończyć działanie aplikacji, która używa portu, lub zdefiniować inny port (tzn. odpowiednio dostosować Adres: port serwera we właściwościach kokpitu).

Zmiana wartości na listach kodów

Jeśli wartości są zmieniane lub wprowadzane na listach kodów (więcej informacji na ten temat można znaleźć w rozdziale Listy kodów), nie jest konieczne ponowne uruchamianie serwera konwertera Comarch e-Faktura. Trzeba tylko ponownie udostępnić daną fakturę sprzedaży do przetworzenia w swojej aplikacji lub, w przypadku faktur zakupu, przenieść dany e-mail z folderu z nieprawidłowymi mailami z powrotem do folderu przychodzącego dla e-faktury.

Otwieranie pliku przez pop-up w kokpicie sterującym kończy się niepowodzeniem

Jeśli pojawi się błąd w formie Failed to open file …. Error message. A device connected to the system does not work, oznacza to, że rozszerzenie pliku nie jest powiązane z żadną aplikacją. W takim przypadku, przykładowo, należy kliknąć prawym przyciskiem myszy na plik PDF w Eksploratorze plików Windows, wybrać [Otwórz za pomocą], a następnie wybrać domyślny program. Następnie, wybierając program, tzn. odpowiedni plik .exe, określa się, że pliki z wybranym typem pliku będą zawsze otwierane za pomocą wskazanego tutaj programu.

Uruchamianie usługi kończy się niepowodzeniem

Uruchamianie usługi kończy się błędem The service Comarch e-invoice Service xxx on computer xy could not be started. Error 216:0xd8 i jedna z poniższych informacji znajduje się w Podglądzie zdarzeń w sekcji Dzienniki systemu Windows / System:

  • Usługa Comarch eInvoice Service TEST została zakończona z następującym błędem specyficznym dla usługi: Nieprawidłowa funkcja.
  • Wersja Comarch e-invoice Service T8888 jest niezgodna z wersją używanego systemu Windows. Należy otworzyć informacje o systemie komputera, aby sprawdzić, czy wymagana jest wersja programu x86 (32-bitowa) czy x64 (64-bitowa), a następnie skontaktować się z wydawcą oprogramowania.

Powodem tego może być użycie nieprawidłowej wersji pliku prunsrv.exe. Dlatego prunsrv.exe powinien zostać zastąpiony inną wersją tego pliku z podfolderu DefaultSpecifications. Wersje te muszą następnie zostać przemianowane na prunsrv.exe.

Zastosowanie pseudoartykułów

Jeśli dla numerów pozycji używane są pseudoartykuły, opis pozycji z pozycji faktury jest łączony z pseudoartykułem. Istnieją dwie możliwości:

  • Jeśli pseudoartykuł jest prawidłowy, tzn. istnieje w systemie Comarch ERP Enterprise jako pozycja zakupu, nie można już zmienić pseudoartykułu w wierszu pozycji.
  • Jeśli pseudoartykuł jest nieprawidłowy, zaimportowana e-faktura musi zostać przejęta za pomocą aplikacji korygującej we wpisie protokołu wymiany danych. W tym przypadku należy wprowadzić odpowiednią pozycję zakupu.

Nowości w związku z Comarch ERP Enterprise w wersji 6.2:

  • Pseudoartykuł może być podany, ale nie jest to wymagane. Pseudoartykuły są w takiej sytuacji wprowadzane jako domyślne dla pozycji.
  • Jeśli użytkownik nie chce wykorzystywać pseudoartykułów w fakturze zakupu, zaleca się nie podawanie pseudoartykułów.

Wyjaśnienie komunikatu o błędzie podczas walidacji XRechnung i ZUGFERD 2.1

W komunikatach o błędach z kontroli poprawności dla nowych formatów ZUGFERD 2.1 lub XRechnung, występują instrukcje w nawiasach okrągłych lub kwadratowych, które zaczynają się od BT (Business Term) lub BG (Business Group) i są uzupełnione myślnikiem i numerem. Są to odniesienia, do których brakujących lub nieprawidłowych danych w fakturze odnosi się komunikat. Informacja BR (Business Rule) odnosi się do powiązanych reguł biznesowych.

Wyjaśnienia dla tych specyfikacji BT, BG i BR w języku niemieckim są zawarte w specyfikacji XRechnung (i mają zastosowanie również do ZUGFERD 2.1). Wersja XRechnung 2.3.1 z datą 03.02.2022 r. jest możliwa do pobrania pod adresem https://xeinkauf.de/app/uploads/2023/02/231-XRechnung-2023-02-03.pdf.

Dla przyszłych wersji informacje na temat XRechnung można uzyskać ze strony pobierania biura koordynacji standardów IT, dostępnej pod adresem https://xeinkauf.de/xrechnung/#kontext.

Cechy szczególne/ograniczenia

Inny odbiorca płatności

Inny odbiorca płatności jest używany przy określaniu dostawcy (partnera lub GLN) dla interfejsu, ale nie jest uwzględniany w danych faktury do jej przetwarzania, ponieważ Comarch ERP Enterprise nie obsługuje innego odbiorcy płatności.

Typy dokumentów ZUGFeRD

Obciążenia wartościowe i faktury wystawiane przez samego siebie (więcej informacji na ten temat można znaleźć w rozdziale Ustawienia domyślne) nie są obsługiwane. Jeśli takie typy faktur są możliwe w Comarch ERP Enterprise, nie wolno ich wysyłać jako e-faktura ZUGFeRD.

Specjalna logika Fattura PA

Znaczek skarbowy Dati Bollo

Znaczek skarbowy jest wstawiany do dokumentu faktury FatturaPA przez konwerter Comarch e-Faktura, gdy zostanie przekroczona minimalna kwota zgodna z rozdziałem Ustawienia domyślne. Jeśli siedziba klienta nie znajduje się we Włoszech, znaczek skarbowy nie zostanie wstawiony.

Kody projektu CodiceCUP i CodiceCIG

Dla faktur do administracji publicznej, kody projektu CUP i CIG mogą być wprowadzane jako tekst nagłówka w fakturze (tzn. w zamówieniu sprzedaży). Teksty nagłówka muszą zaczynać się od CIG= lub CUP= i zawierać powiązany kod. Teksty te są przenoszone tylko wtedy, gdy podany jest zewnętrzny numer dokumentu.

Kody projektu Causale

Dla zwolnień podatkowych w FatturaPA istnieją wskazania … Lettera di …. Za pomocą kodu projektu CAUSALE powiązany tekst może być wprowadzony jako tekst nagłówka w fakturze (tzn. w zamówieniu sprzedaży). Tekst musi zaczynać się od CAUSALE= i zawierać informację Causale (maks. 200 znaków). Obsługiwany jest tylko jeden tekst causale, inne zostaną zignorowane.

Uwaga
Podatkowe deklaracje zamiaru muszą być teraz podawane na poziomie pozycji. Dlatego ta funkcja nie powinna być już używana, nawet jeśli nie jest wyłączona.

Wskazanie deklaracji zwolnienia z podatku odbywa się tylko za pomocą pozycji faktury, którym przypisano wskazanie Natura N3.5. Dalsze informacje na ten temat można znaleźć w ramach specyficznej implementacji Deklaracja podatkowa zamiaru (dichiarazioni d’intento). Więcej informacji można znaleźć w rozdziale FatturaPA.

Kody pocztowe/region dla klientów spoza Włoch

Jeśli siedziba klienta nie znajduje się we Włoszech, jego kod pocztowy jest uzupełniany wiodącymi zerami do 5 znaków lub, jeśli to konieczne, obcinany z prawej strony. Jeśli po usunięciu spacji i myślników kod pocztowy zawiera znaki inne niż cyfry, kod pocztowy jest ustawiany na 00000, w przeciwnym razie walidacja zakończyłaby się niepowodzeniem.

Jeśli region nie składa się z dwóch wielkich liter, informacja ta jest pomijana.

CodiceFiscale klienta

Jeśli informacja o lokalnym numerze podatkowym klienta w jego widoku księgowym nie zawiera żadnych danych, używana jest informacja z pola supplementaryTaxIdentificationNumber.

Zasadniczo, tylko włoscy klienci mają CodiceFiscale. Wszyscy klienci spoza Włoch mają numer VAT i nie powinni mieć CodiceFiscale. Z tego powodu w konwerterze Comarch e-Faktura wprowadzono następujące dostosowanie:

  • Jeśli siedziba klienta nie znajduje się we Włoszech, ale klient nie ma numeru VAT, a numer podatkowy dla <CodiceFiscale> nie ma cyfry w pierwszych dwóch znakach, numer podatkowy zostanie przeniesiony do numeru VAT <IdFiscaleIVA>.
  • Jeśli siedziba klienta nie znajduje się we Włoszech, a klient ma numer VAT, wskazanie <CodiceFiscale> zostanie usunięte.
Ustawianie komponentów pozycji

Komponenty pozycji zestawu otrzymują taki sam numer pozycji jak odpowiednia pozycja zestawu. Ponadto, dane podatkowe powiązanej pozycji zestawu są przejmowane w komponentach pozycji zestawu dla celów podatkowych (brakuje tego w systemie Comarch ERP Enterprise).

Cena jednostkowa

Ceny jednostkowe są używane w Comarch ERP Enterprise z większą dokładnością, a następnie w fakturze są drukowane po zaokrągleniu. Prowadzi to do sytuacji, w której wzór:

Ilość * Cena jednostkowa = Cena pozycji

ma zbyt duże odchylenie od tolerancji 0,01 euro. W takich przypadkach cena jednostkowa jest przeliczana i akceptowana, jeśli zmiana mieści się w określonej różnicy zaokrąglenia, a wzór jest poprawny w ramach tolerancji. Zwłaszcza w przypadku pozycji z wymiarami cenowymi, cena jednostkowa jest w razie potrzeby obliczana na podstawie jednostki.

Dodatkowe wysyłanie faktury PDF pocztą elektroniczną

Dzięki funkcji Dodatkowe wysyłanie faktury PDF pocztą elektroniczną plik PDF faktury, który został utworzony w Comarch ERP Enterprise, może być dodatkowo wysłany mailem. Mail jest wysyłany do adresata zgodnie z szablonem dokumentu. W ten sposób można przesłać klientowi dodatkowe informacje dotyczące faktury. Fakt, że jest to tylko dodatkowa informacja, powinien być określony w specyfikacjach dla tematu i tekstu w szablonie dokumentu. Temat jest uzupełniany o nazwę pliku transferowego SDI.

Dodatkowa wysyłka zostanie zrealizowana tylko wtedy, gdy spełnione są następujące warunki:

  • ta opcja jest włączona,
  • e-faktura została pomyślnie utworzona,
  • u partnera będącego klientem w typie końcowego przetwarzania jest ustawiona wartość zgodnie z ustawieniem w narzędziu do konwersji e-faktur.

Jeśli użytkownik nie chce wysyłać do klienta dodatkowej przesyłki, a opcja Konwertuj do Comarch e-faktury jest włączona, dla partnera należy ustawić Wyjście do katalogu Windows jako typ końcowego przetwarzania.

Ignorowanie pozycji Natura przy obliczaniu minimalnej kwoty Bollo

Pozycje ze stawką podatku 0 są używane do określenia Minimalnej kwoty Bollo. Aby w przypadku wyjątków, takich jak dalsze obliczanie znaczka skarbowego (MARCA DA BOLLO), pozycje te nie były uwzględniane w sumie do obliczania minimalnej kwoty, do specyfikacji Natura należy dodać prefiks BOLLO_. W tym celu konieczne są własne, powiązane klucze kontrolne Comarch ERP Enterprise.

Przykład
BOLLO_N1 lub BOLLO_N2.1.

W pliku FatturaPA XML prefiks BOLLO_ jest następnie ponownie usuwany ze specyfikacji Natura i staje się, przykładowo, ponownie N1 lub N2.1.

Przygotowanie informacji na temat CodiceFiscale i kodu pocztowego

Informacje dotyczące numeru podatkowego i kodu pocztowego muszą być zgodne z wymaganiami dla Włoch i często nie spełniają tych wymagań w przypadku partnerów zagranicznych. W ten sposób jest uzupełniane przez dodanie liter X, aż wartość osiągnie 11 znaków, jeśli kraj tych partnerów jest inny niż Włochy. Dla kodów pocztowych poniżej tych partnerów dodawane są wiodące zera lub wartość jest ustawiana na 00000, jeśli dostosowanie nie jest możliwe.

Szczególne cechy formatu ZUGFeRD 2.1

Różni odbiorcy faktury

W formacie ZUGFeRD 2.1 nie są już obsługiwani różni odbiorcy faktury, ponieważ nie są oni już uwzględniani w standardzie EN 16931/Factur-X.

E-faktury z oznaczeniem trybu testowego

Wskaźnik trybu testowego w plikach XML e-faktury nie jest już obsługiwany.

Szczególne cechy formatu XRechnung

Cechy szczególne analogiczne do ZUGFeRD 2.1

Obowiązują te same cechy szczególne, co dla formatu ZUGFeRD 2.1. Więcej informacji na ten temat można znaleźć w rozdziale Cechy szczególne ZUGFERD 2.1.

Dodatkowe informacje obowiązkowe

Konwerter Comarch e-Faktura obsługuje formaty standardu XRechnung (nazywanego również XRechnung).
Formaty XRechnung (1.2.2, 2.0.0 i kolejne wersje) są pod względem treści i struktury identyczne ze standardem ZUGFeRD 2.1.

Jednak XRechnung wymaga obowiązkowych informacji, w szczególności:

  • numeru identyfikacyjnego routingu,
  • danych kontaktowych sprzedawcy — więcej informacji można znaleźć w rozdziale ZUGFERD i XRechnung – Kontakt ze sprzedawcą,
  • adresu e-mail organizacji sprzedażowej — od wersji XRechnung 3.0.1 może być określony poprzez dane kontaktowe sprzedawcy – więcej informacji można znaleźć w rozdziale ZUGFERD i XRechnung.

Wszystkie pozostałe obowiązkowe dane są zazwyczaj zapewniane lub weryfikowane w ramach audytów.

Numer routingu wprowadza się w systemie Comarch ERP Enterprise w aplikacji Partnerzy dla widoku Klient w polu o tej samej nazwie. Ponieważ to pole w Comarch ERP Enterprise jest ograniczone do 30 znaków, a identyfikatory routingu mogą być dłuższe, pozostała część numeru musi zostać wpisana w polu Numer rejestracji w sekcji Iscrizione REA. Obie części są następnie łączone po usunięciu spacji (na początku i końcu).

Format wyjściowy

Konwerter Comarch e-Faktura umożliwia utworzenie faktury XRechnung jako dokumentu hybrydowego, czyli jako faktury w formacie PDF z osadzonym plikiem XML XRechnung.

Uwaga
Należy jednak pamiętać, że taki dokument nie jest prawidłowym formatem XRechnung.
Prawidłowa faktura XRechnung składa się wyłącznie z danych w formacie XML.
Szczegóły dotyczące rabatów

Format XRechnung umożliwia zapisanie informacji o rabacie gotówkowym w postaci formuły w opisie warunków płatności. W specyfikacji ZUGFeRD ta szczególna cecha formatu XRechnung została opisana następująco:

Informacje dotyczące przyznania rabatu lub naliczania odsetek za zwłokę muszą być przekazywane w elemencie Warunki płatności (BT-20), każda na osobnej linii, w następujący sposób:
w pierwszym segmencie należy wskazać ‘SKONTO’ lub ‘VERZUG’, w drugim ‘TAGE=n’, w trzecim ‘PROZENT=n’, przy czym każdy segment musi być ujęty w znaki ‘#’. Procenty muszą być zapisane z użyciem kropki i dwóch miejsc po przecinku.
Jeśli kwota, od której dokonywane są obliczenia, nie opiera się na BT-115, czyli kwocie należnej, lecz tylko na części tej kwoty, to wartość bazową do obliczeń rabatu lub odsetek za zwłokę należy podać jako czwarty segment ‘BASISBETRAG=n’ z typem danych Kwota.

Ograniczenie: Instrukcja formatu, np.:

#SKONTO#TAGE=14#PROZENT=2.25# 
#SKONTO#TAGE=14#PROZENT=2.25#BASISBETRAG=357.93#

Dalsze opisy można znaleźć na stronie https://xeinkauf.de/xrechnung/. Opisy aktualnych wersji XRechnung są dostępne w sekcji Wersje i pakiety.

Jeśli użytkownik chce przekazać informacje o rabacie gotówkowym w tej formie, musi użyć warunków płatności zawierających wyłącznie taki formatowy opis. Tekst nie jest przetwarzany, tzn. nie można stosować zmiennych kwot podstawowych.

Szczególne cechy faktur KSeF

Po pomyślnym utworzeniu pliku faktury w formacie XML dla KSeF, musi on zostać przesłany do systemu KSeF. Należy również pobrać potwierdzenie odbioru faktury (UPO). Te dodatkowe zadania są realizowane przez odpowiednie procesy (więcej informacji można znaleźć w rozdziale Użytkownicy KSeF) oraz z wykorzystaniem danych połączeniowych do systemu KSeF (więcej informacji można znaleźć w rozdziale Użytkownicy KSeF).

Szczególne cechy dla faktur zakupu

Uwaga
Ergonomiczne przetwarzanie faktur zakupu jest możliwe wyłącznie w połączeniu z dodatkiem Comarch e-Faktura od wersji CEE 6.2.
Kontrola uprawnień przez rodzaj faktury zakupu (od wersji 6.2)

Za pomocą odpowiedniej konwersji można zdefiniować rodzaj faktury zakupu. Jeżeli określona w ten sposób wartość odpowiada rodzajowi faktury zakupu obowiązującemu w systemie Comarch, zostaje ona wprowadzona do interfejsu i może być wykorzystywana do kontroli uprawnień.

Uwaga
W systemie Comarch ERP Enterprise ten rodzaj faktury zakupu może zostać jeszcze zmodyfikowany podczas importu faktury zakupu.
Obsługa dodatkowych formatów dla e-Faktur zakupu

Oprócz formatów wymienionych w rozdziale Ogólne, obsługiwane są również inne formaty dla e-faktur zakupu, które są do nich podobne.

Dane zawarte w tych formatach, które są wykorzystywane przez konwerter Comarch e-Faktura muszą znajdować się w tych samych miejscach, co w przypisanym do nich podobnym formacie e-faktury. Dotyczy to na przykład rozszerzonych formatów ZUGFeRD przypisanych do odpowiednich formatów EN16931. To samo dotyczy formatu ZUGFeRD 2.0.1, który jest podobny do ZUGFeRD 2.1.

Po wykryciu tych dodatkowych formatów i pomyślnej walidacji, są one przetwarzane jako e-faktury w przypisanym podobnym formacie (wymienionym w rozdziale Ogólne).

Takie formaty można zidentyfikować w systemie Comarch ERP Enterprise na podstawie informacji w polu Informacja dodatkowa dot. formatu w aplikacji e-Faktury zakupu.

Funkcjonalność KSeF dla faktur zakupu

Plik KsefWorkProcessingData.xml zawiera m.in. dane dotyczące odbioru faktur zakupu. Podczas wyszukiwania faktur zakupu w systemie KSeF konieczne jest określenie przedziału czasowego. Jako czas początkowy wykorzystywana jest wartość podana w znaczniku <maxInvoiceSentTime>. Jeśli ten wpis jest nieobecny lub pusty, jako domyślny czas przyjmowana jest godzina 4:00 rano bieżącego dnia.

Uwaga
Modyfikacja wartości w pliku KsefWorkProcessingData.xml powinna być wykonywana wyłącznie przez specjalistę i tylko w wyjątkowych przypadkach.

Funkcje opcjonalne

Preferowana skrytka pocztowa zamiast ulicy w adresie nabywcy (domyślnie wyłączone)

W transformacjach dla ZUGFeRD i XRechnung istnieje możliwość wyświetlenia w adresie nabywcy skrytki pocztowej (z tekstem P.O. Box przed numerem) zamiast ulicy, jeśli skrytka pocztowa jest dostępna.

Można aktywować tę opcję, zastępując poBox_inactive wartością poBox w odpowiednim pliku XSL, najlepiej w jego kopii. Zakłada się, że jeśli podano skrytkę pocztową, to partnerowi przypisano również odpowiedni kod pocztowy dla skrytki.

Jeśli użytkownik chce zastosować to rozwiązanie tylko dla wybranych klientów, należy dla nich utworzyć osobne szablony dokumentów dla drukarki z własną definicją filtra i transformacją.

Uwagi dotyczące ustawień w Comarch ERP Enterprise

Format faktury z kontrolą zatwierdzania

W ustawieniach aplikacji Konfiguracja dla Comarch e-faktura znajduje się pole o nazwie Format faktur z weryfikacją przed udostępnieniem. Dla formatów faktur określonych w tym polu (oddzielonych przecinkami), faktury, które mają być utworzone jako e-faktury, otrzymują status W opracowaniu. Takie faktury muszą następnie zostać zatwierdzone do przetwarzania poprzez odpowiednią akcję na fakturze sprzedaży lub w aplikacji typu lista dla faktur sprzedaży.

Tworzenie faktur sprzedaży KSeF

Faktury, dla których mają zostać utworzone faktury sprzedaży KSeF, należy wystawiać z użyciem dodatku Comarch ERP Enterprise dla Polski w zamówieniu sprzedaży. Umożliwia to dalsze przetwarzanie faktur korygujących.

Czy ten artykuł był pomocny?