KSeF w enova365. Aspekty techniczne, licencje i bezpieczeństwo w systemach ERP

KSeF w enova365

KSeF w enova365. Aspekty techniczne, licencje i bezpieczeństwo w systemach ERP

Witamy w trzecim, finałowym artykule z cyklu o Krajowym Systemie e-Faktur! Po omówieniu wysyłania dokumentów i pobierania faktur, dziś skupiamy się na aspektach technicznych wdrożenia KSeF. To artykuł dla osób odpowiedzialnych za konfigurację systemu, administratorów IT oraz kierowników projektów wdrożeniowych.

Po raz ostatni w tym cyklu rozmawiamy z Karolem Kostrzewskim, Kierownikiem ds. Handlu w COM@COM, który przeprowadzi nas przez techniczne zawiłości autoryzacji, tokenów, środowisk testowych i kwestii bezpieczeństwa.

Spis treści

Licencje i wymagania systemowe

Paulina Kubiak: Karol, zacznijmy od podstaw. Jakie licencje w enova365 są potrzebne, żeby korzystać z KSeF?

Karol Kostrzewski: To bardzo praktyczne pytanie. enova365 pozwala na korzystanie z KSeF na licencjach: Faktury, Handel, Księga i KPiR. Co ważne, obsługa KSeF jest dostępna w ramach standardowych aktualizacji programu, bez dodatkowych opłat za sam moduł KSeF.

PK: Ale zakres funkcjonalności zależy od posiadanej licencji?

KK: Dokładnie. Zakres współpracy enova365 z KSeF jest adekwatny do tego, co zawiera licencja. Oznacza to, że gdy mamy na przykład tylko wykupioną licencję Księga i nie mamy modułu faktur zakupu/sprzedaży (Handel, Faktury), wówczas mamy dostęp tylko do funkcji pobierania faktur z KSeF, ale nie możemy wystawiać faktur sprzedaży w KSeF.

Jeśli posiadamy pełny moduł Handel, mamy dostęp do wszystkich funkcjonalności – wysyłania faktur sprzedaży, pobierania faktur zakupu, automatycznych relacji z dokumentami magazynowymi, obsługi zaliczek i korekt.

PK: A co z dodatkowymi modułami, takimi jak Workflow?

KK: Workflow nie jest wymagany do podstawowej obsługi KSeF. Można wysyłać i pobierać faktury bez tego modułu. Jednak Workflow znacznie usprawnia procesy, szczególnie w przypadku faktur zakupu.

Minimalne wymagania licencyjne do obsługi procesu standardowego KSeF z Workflow to moduł Handel w wersji srebrnej, moduł DMS w wersji platynowej oraz jednorazowy zakup Konfiguratora Workflow i DMS. W przypadku chęci wykorzystania własnego podprocesu bądź zmodyfikowania już istniejącego potrzebna jest licencja na moduł Workflow w wersji platynowej.

Natomiast proces zbiorczej wysyłki do KSeF, dostępny od wersji 2512.0.0, nie wymaga posiadania licencji Workflow.

PK: Czy każdy użytkownik systemu powinien posiadać podpis elektroniczny?

KK: Nie, nie ma takiej potrzeby. Komunikacja z KSeF odbywa się za pomocą tokenów autoryzacyjnych, które powiązane są z odpowiednimi uprawnieniami. To token umożliwia wykonywanie operacji zgodnych z nadanymi uprawnieniami, a nie podpis elektroniczny poszczególnych użytkowników.

Token autoryzacyjny – podstawy

PK: Skoro tokeny są tak ważne, wyjaśnij proszę dokładnie, czym one są?

KK: Token to unikalny ciąg znaków używany do uwierzytelniania podczas pobierania i wysyłki faktur. Jest to dodatkowa metoda autoryzacji stosowana pomiędzy systemem ERP a platformą KSeF.

Inaczej mówiąc, to identyfikator wygenerowany w systemie KSeF przez podmiot uwierzytelniony, zawierający podzbiór uprawnień tego podmiotu. Stosowany jest do uwierzytelniania się uprawnionych osób poprzez systemy ERP przez udostępnione API w systemie KSeF.

PK: Jak przebiega proces generowania tokenu?

KK: Token można wygenerować na dwa sposoby. Pierwszy to generowanie bezpośrednio na platformie KSeF przez aplikację podatnika. Logujemy się na platformę KSeF, przechodzimy do zakładki „Tokeny/Generuj token”, wpisujemy nazwę tokenu (minimum 5 znaków) i wybieramy uprawnienia – do wysyłki faktur, do pobierania faktur lub obie opcje.

Po wygenerowaniu otrzymujemy ciąg znaków, który kopiujemy i wprowadzamy do konfiguracji enova365. Bardzo ważne: po zamknięciu okna z tokenem nie ma możliwości ponownego jego wyświetlenia, więc musimy go skopiować od razu.

PK: Wspomniałeś o drugim sposobie?

KK: Tak, od odpowiedniej wersji enova365 możliwe jest generowanie tokenu bezpośrednio z poziomu systemu, ale tylko dla środowiska testowego. Tworzymy nowy token w konfiguracji KSeF, wybieramy wersję API 2.0, wpisujemy nazwę tokenu i klikamy „Generuj nowy token”. Po chwili token się wygeneruje, następnie trzeba go uwierzytelnić i sprawdzić status uwierzytelnienia.

PK: Czy trzeba generować osobne tokeny dla różnych operacji?

KK: To zależy od potrzeb organizacji. Można utworzyć jeden token z pełnymi uprawnieniami do wysyłki i pobierania, ale z punktu widzenia bezpieczeństwa często lepszym rozwiązaniem jest utworzenie oddzielnych tokenów dla sprzedaży i zakupu. To jedno z zagadnień, które ustalamy na etapie analizy wdrożeniowej z Klientem.

Dodatkowo, każdy token może mieć przypisane konkretne role lub operatorów w enova365, co pozwala na precyzyjne zarządzanie uprawnieniami.

Token vs podpis elektroniczny – kluczowe różnice

PK: Wiele osób pyta o różnicę między tokenem a podpisem elektronicznym. Czy możesz to wyjaśnić?

KK: To kluczowe rozróżnienie. Podpis elektroniczny kwalifikowany ma taką samą moc prawną jak podpis własnoręczny. Jest poświadczony certyfikatem kwalifikowanym, który umożliwia weryfikację osoby będącej jego właścicielem.

Takim podpisem może posługiwać się tylko jego właściciel, a przy jego składaniu najczęściej konieczne jest wprowadzenie hasła lub PIN-u będącego dodatkowym zabezpieczeniem. W przypadku, gdy podpis ma postać fizyczną – na przykład karty – konieczne jest wprowadzenie jej do czytnika podłączonego do komputera. Podpis kwalifikowany należy zakupić u certyfikowanego dostawcy.

PK: A token?

KK: Token autoryzacyjny wygenerowany w KSeF jest unikalnym identyfikatorem, ale nie umożliwia identyfikacji konkretnej osoby i nie ma mocy prawnej jak podpis elektroniczny. Token KSeF generowany jest za pośrednictwem platformy KSeF i jest powiązany z konkretnym podmiotem – firmą – oraz posiada odpowiednie uprawnienia, na przykład do wysyłki czy dostępu do faktur.

Token przeznaczony jest głównie do komunikacji pomiędzy systemami informatycznymi a platformą KSeF. Uwierzytelnienie za pomocą tokenu odbywa się najczęściej bez udziału operatora – brak PIN-u czy hasła – co pozwala na automatyzację procesów takich jak wysyłka czy pobieranie faktur z KSeF.

PK: Czyli główna różnica to automatyzacja?

KK: Tak, to jest kluczowa różnica z perspektywy operacyjnej. Podpis elektroniczny wymaga aktywnego udziału osoby przy każdym użyciu – wprowadzenia PIN-u, włożenia karty do czytnika. Token działa automatycznie w tle, co umożliwia na przykład nocne wysyłanie faktur przez harmonogram zadań bez obecności pracownika.

Oczywiście token zapewnia bezpieczeństwo danych, pod warunkiem nieprzekazywania go osobom niepowołanym. To jest absolutnie krytyczne – token to klucz do wystawiania i odbierania faktur w imieniu firmy.

Proces autoryzacji w KSeF

PK: Jak dokładnie przebiega proces autoryzacji podatnika w KSeF przez enova365?

KK: Autoryzacja odbywa się przy użyciu tokena autoryzacyjnego lub certyfikatu. W podstawowym scenariuszu, po wprowadzeniu tokenu do konfiguracji enova365, system używa go automatycznie przy każdej komunikacji z KSeF.

PK: Wspomniałeś o certyfikatach. Kiedy są one wykorzystywane?

KK: Certyfikaty pełnią dwie role w integracji z KSeF. Mogą zastąpić token przy identyfikacji wysyłki faktur w trybie online. Certyfikat może też służyć do wysyłki faktur w trybie offline.

Wprowadzenie certyfikatu w enova365 odbywa się poprzez zakładkę „Autoryzacje” w koncie KSeF. Wybieramy wersję API 2.0, rodzaj „Certyfikat” i dodajemy certyfikat KSeF.

PK: Jakie dane trzeba uzupełnić?

KK: Musimy podać numer certyfikatu, wybrać przeznaczenie – „Uwierzytelnienie w systemie KSeF” dla trybu online lub „Podpis linku do weryfikacji wystawcy” dla trybu offline. Następnie dodajemy plik certyfikatu z rozszerzeniem .crt, plik klucza z rozszerzeniem .key oraz hasło wygenerowane przy tworzeniu certyfikatu na platformie KSeF.

Po zatwierdzeniu, jeśli certyfikat jest do trybu online, klikamy „Rozpocznij uwierzytelnianie” oraz „Sprawdź status uwierzytelnienia”. Na koniec ustawiamy uprawnienia ról i operatorów do danego certyfikatu.

PK: Jaka jest różnica między tokenem a certyfikatem?

KK: Certyfikaty i tokeny służą do uwierzytelnienia podczas wysyłki i pobierania faktur. Certyfikaty są niezbędne do trybu offline, gdzie podpisują faktury lokalnie. Tokeny są ważne tylko do końca 2026 roku. Od 01.01.2027 jedynymi autoryzacjami będą certyfikaty. Certyfikat jest ważny na 2 lata. Z punktu widzenia bezpieczeństwa, oba wymagają odpowiedniej ochrony – certyfikat wraz z hasłem i plikiem klucza to równie wrażliwe dane jak token.

Środowiska KSeF – testowe, przedprodukcyjne, produkcyjne

PK: Czy KSeF daje możliwość testowania przed wejściem na środowisko produkcyjne?

KK: Tak, i to jest bardzo ważny element bezpiecznego wdrożenia. W systemie KSeF są dostępne trzy środowiska: testowe, przedprodukcyjne i produkcyjne.

PK: Czym się różnią?

KK: Środowisko testowe służy wyłącznie do testów i nie ma żadnych ograniczeń. Wprowadzając dowolny NIP, bez konieczności autoryzacji, możemy poznawać system, testować wysyłkę, sprawdzać struktury XML. To idealne miejsce dla programistów i integratorów.

Środowisko przedprodukcyjne, czasami nazywane środowiskiem demo lub sandbox, również służy do testów, ale należy się do niego zalogować przy pomocy faktycznych danych firmowych i odpowiedniego sposobu autoryzacji. Tutaj możemy przetestować pełny proces z prawdziwymi danymi firmy, ale w bezpiecznym środowisku, gdzie faktury nie mają mocy prawnej.

Środowisko produkcyjne to już oficjalny system KSeF, do którego trafiają faktyczne dokumenty o pełnej mocy prawnej.

PK: Jak przebiega proces testowania w COM@COM?

KK: Zgodnie z naszą metodyką wdrożenia, po spotkaniu analitycznym najpierw konfigurujemy środowisko przedprodukcyjne (sandbox). Dodajemy konto KSeF sandbox, konfigurujemy bazę testową według ustaleń z analizy, przeprowadzamy szkolenie użytkowników i testy wysyłki oraz odbioru dokumentów.

Dopiero po pomyślnych testach przechodzimy do konfiguracji środowiska produkcyjnego – dodajemy produkcyjne konto KSeF i przenosimy konfigurację na bazę produkcyjną. To minimalizuje ryzyko błędów na środowisku rzeczywistym.

Zarządzanie uprawnieniami i rolami

PK: Wspominałeś o przypisywaniu uprawnień do tokenów i certyfikatów. Jak to działa w praktyce?

KK: W enova365 każda autoryzacja ma możliwość określenia, które role lub którzy operatorzy mają do niego dostęp. Wchodząc do autoryzacji poprzez „Otwórz”, ustawiamy te uprawnienia.

PK: Po co to rozdzielanie?

KK: To kwestia bezpieczeństwa i organizacji pracy. Możemy na przykład stworzyć token do pobierania faktur i przypisać go tylko do działu księgowości, a token do wysyłki faktur sprzedaży przypisać do działu handlowego. Każdy zespół ma dostęp tylko do tego, czego potrzebuje.

W enova365 mamy też dedykowaną listę Handel/KSeF/Autoryzacje, która prezentuje tokeny dostępne dla danego operatora. Każdy widzi tylko te tokeny, do których ma uprawnienia. Dostępne są tutaj również czynności „Rozpocznij uwierzytelnianie” i „Sprawdź status uwierzytelniania”.

PK: Czy można ograniczyć uprawnienia jeszcze bardziej szczegółowo?

KK: Tak, w konfiguracji możemy określić, czy autoryzacja służy tylko do pobierania, tylko do wysyłania, czy do obu operacji. Dodatkowo, poprzez system ról w enova365, możemy kontrolować dostęp do list, czynności, możliwość zatwierdzania dokumentów itd. To bardzo elastyczny system uprawnień.

Biura rachunkowe i uprawnienia instytucjonalne

PK: Szczególnie istotne pytanie dla biur rachunkowych: czy firma może nadać uprawnienia instytucjonalne innemu podmiotowi, żeby ten podmiot mógł zarządzać fakturami w KSeF?

KK: Tak, jest taka możliwość i jest to typowy scenariusz dla biur rachunkowych. Posiadając autoryzacje wygenerowane przez klientów, biuro może pobierać i wysyłać faktury do KSeF bez konieczności wpisywania dodatkowych poświadczeń przy każdej operacji.

PK: Jak to wygląda technicznie?

KK: Klient generuje autoryzacje w swoim koncie KSeF z odpowiednimi uprawnieniami – najczęściej do pobierania faktur zakupu. Następnie przekazuje te autoryzacje biuru rachunkowemu w bezpieczny sposób. Biuro wprowadza je do swojej instalacji enova365, przypisuje go do konkretnego klienta (czyli do konkretnej bazy danych lub firmy w systemie).

Od tego momentu system automatycznie korzysta z odpowiedniej autoryzacji podczas pobierania faktur dla danego klienta. Nie ma potrzeby logowania się na konto klienta, używania jego certyfikatów czy haseł. Wszystko działa automatycznie.

PK: A co z bezpieczeństwem tych tokenów?

KK: To kluczowa kwestia. Autoryzacje muszą być traktowane jak hasła dostępu do systemu bankowego. Powinny być przechowywane w bezpieczny sposób, przesyłane szyfrowanymi kanałami i dostępne tylko dla uprawnionych osób.

W praktyce zalecamy, żeby klient przekazywał token biuru drogą szyfrowaną – na przykład przez bezpieczny portal klienta, zaszyfrowany email czy bezpośrednie wprowadzenie podczas spotkania. Nigdy nie powinno się przesyłać autoryzacji zwykłym, nieszyfrowanym emailem.

Bezpieczeństwo tokenów i certyfikatów

PK: Skoro już o bezpieczeństwie mowa – jakie są najlepsze praktyki w zarządzaniu tokenami i certyfikatami?

KK: Zacznę od fundamentalnej zasady: certyfikaty i tokeny dają możliwość wystawiania i odbierania faktur w imieniu firmy, dlatego muszą być traktowane z najwyższą ostrożnością. To jest jak klucz do konta bankowego – jeśli ktoś nieuprawiony będzie miał dostęp, może działać w Twoim imieniu.

PK: Jakie konkretne zasady powinny obowiązywać?

KK: Po pierwsze, ograniczona lista osób z dostępem. Tylko wybrane, zaufane osoby powinny mieć dostęp do tokenów i certyfikatów. W enova365 realizujemy to przez system uprawnień – przypisujemy autoryzacje tylko do konkretnych ról i operatorów.

Po drugie, bezpieczne przechowywanie. Tokeny nie powinny być zapisywane w nieszyfrowanych plikach na dysku, przesyłane zwykłym emailem czy umieszczane w ogólnodostępnych dokumentach.

Po trzecie, regularna weryfikacja. Należy okresowo sprawdzać, kto ma dostęp do autoryzacji, czy wszystkie aktywne są nadal potrzebne, czy nie należy któregoś dezaktywować.

PK: Co z hasłami do certyfikatów?

KK: Hasła do certyfikatów powinny być silne i unikalne. Przy generowaniu certyfikatu na platformie KSeF system wymaga wprowadzenia hasła. To hasło należy dobrze zapisać, ponieważ po wygenerowaniu certyfikatu nie ma możliwości podejrzenia czy zmiany hasła.

W praktyce zalecamy używanie menedżerów haseł do bezpiecznego przechowywania tych danych, szczególnie w organizacjach, gdzie wiele osób może potrzebować dostępu.

PK: Co w przypadku podejrzenia wycieku autoryzacji?

KK: Jeśli istnieje podejrzenie, że autoryzacja mógła wyciec, należy natychmiast ją zdezaktywować na platformie KSeF i wygenerować nową. To jest kwestia kilku minut, a zabezpiecza przed potencjalnym nadużyciem.

Integracja z JPK_VAT

PK: Ostatnio Klienci często pytają o JPK_VAT. Czy będzie potrzebował numeru KSeF?

KK: Tak, to bardzo aktualna kwestia. W chwili obecnej trwają prace nad rozporządzeniem w sprawie dostosowania JPK do KSeF. Projekt zmian zakłada wprowadzenie do JPK_VAT z deklaracją numeru identyfikującego fakturę w Krajowym Systemie e-Faktur.

PK: Czy enova365 będzie to obsługiwać?

KK: Tak, numer KSeF jest przechowywany w systemie enova365 i będzie automatycznie przekazywany do pliku JPK_VAT zgodnie z nowymi wymogami. System już teraz rejestruje i przechowuje te numery, więc kiedy zmieni się rozporządzenie, będziemy gotowi.

To oznacza, że nie trzeba będzie ręcznie przepisywać numerów KSeF do JPK – system zrobi to automatycznie, co eliminuje ryzyko błędów i znacznie przyspiesza proces raportowania.

PK: A co z fakturami wystawionymi przed wdrożeniem KSeF?

KK: Faktury wystawione przed obowiązkiem KSeF nie będą miały numeru referencyjnego KSeF i będą raportowane w JPK w dotychczasowy sposób. W okresie przejściowym JPK_VAT będzie zawierał mieszankę faktur – niektóre z numerami KSeF, niektóre bez. System enova365 będzie to obsługiwał automatycznie.

Obsługa błędów i wsparcie techniczne

PK: Co zrobić w enova365, kiedy KSeF odrzuci fakturę z powodów technicznych?

KK: Należy zweryfikować powód odrzucenia. W enova365 wszystkie komunikaty błędów są logowane i widoczne w konsoli.

Jeżeli faktura została odrzucona poprzez niezgodność XML ze schemą – na przykład brakujące dane adresowe kontrahenta, nieprawidłowy NIP czy błędne kody GTU – wówczas należy poprawić odpowiednie dane i wysłać do KSeF jeszcze raz.

PK: Jak to technicznie wykonać?

KK: Mając pewność, że wysłana faktura nie została wystawiona w KSeF – bo otrzymaliśmy komunikat błędu – używamy czynności „KSeF/Usuń”. To usuwa wygenerowany plik XML i resetuje status dokumentu. Po użyciu tej czynności można poprawić dane na dokumencie i wysłać go ponownie.

Warto podkreślić, że enova365 ma wbudowany mechanizm „Sprawdź strukturę pliku”, który weryfikuje zgodność ze schemą jeszcze przed wysyłką do KSeF. To znacznie redukuje ryzyko odrzucenia.

PK: A jeśli błąd jest po stronie KSeF – awaria systemu?

KK: W przypadku oficjalnie ogłoszonej awarii KSeF przez Ministerstwo Finansów, wchodzimy w tryb awaryjny. Możemy wystawiać faktury w trybie offline i mamy 7 dni roboczych od ustąpienia awarii na dosłanie dokumentów.

Enova365 obsługuje ten tryb automatycznie – wystarczy zaznaczyć podczas generowania faktury, że wysyłamy ją offline, wybrać odpowiedni certyfikat i system wygeneruje fakturę z kodami QR dla trybu offline.

PK: Jak COM@COM wspiera Klientów przy problemach technicznych?

KK: Mamy dedykowany ServiceDesk COM@COM, gdzie Klienci mogą zgłaszać problemy. Nasz zespół techniczny zna wszystkie niuanse KSeF w enova365 i pomaga rozwiązać zarówno kwestie konfiguracyjne, jak i bieżące problemy operacyjne.

Dodatkowo, podczas wdrożenia przeprowadzamy szkolenia, przygotowujemy dokumentację techniczną i pozostajemy w kontakcie z Klientem także po zakończeniu wdrożenia, aby zapewnić płynne działanie systemu.

Gotowy na bezpieczne wdrożenie KSeF w enova365?

Jeśli chcesz wdrożyć KSeF w sposób uporządkowany, bezpieczny i dopasowany do realnych procesów w firmie, zapraszamy do kontaktu z COM@COM.
Podsumowanie cyklu

PK: Karol, to była ostatnia rozmowa z naszego cyklu o KSeF. Czy mógłbyś podsumować całość?

KK: Z przyjemnością. Udało nam się kompleksowo omówić temat wdrożenia KSeF w enova365:

W pierwszym artykule skupiliśmy się na wysyłaniu dokumentów – wyjaśniliśmy, kiedy faktura jest uznawana za wystawioną, jak działają tryby awaryjne, jak zarządzać korektami i błędami, oraz jak automatyzować wysyłkę.

W drugim artykule przeszliśmy przez pobieranie faktur zakupu – omówiliśmy, kiedy faktura jest odebraną, jak system zabezpiecza przed podwójnym księgowaniem i jak wygląda weryfikacja dokumentów przed zaksięgowaniem.

W tym, trzecim artykule zagłębiliśmy się w aspekty techniczne – tokeny, certyfikaty, autoryzację, środowiska testowe, zarządzanie uprawnieniami, bezpieczeństwo i integrację z JPK_VAT.

PK: Jakie są najważniejsze wnioski dla osób planujących wdrożenie?

KK: Po pierwsze, wdrożenie KSeF wymaga przygotowania, ale przy odpowiedniej metodyce i wsparciu – takiego jak oferuje COM@COM – jest procesem przewidywalnym i bezpiecznym.

Po drugie, automatyzacja to klucz. Harmonogramy zadań, procesy workflow, integracja z dokumentami magazynowymi – wszystko to sprawia, że KSeF zamiast obciążenia staje się usprawnieniem.

Po trzecie, bezpieczeństwo tokenów i certyfikatów to fundament. Trzeba traktować je z najwyższą ostrożnością i wdrożyć odpowiednie procedury.

Po czwarte, testowanie przed produkcją. Wykorzystanie środowiska przedprodukcyjnego eliminuje ryzyko i pozwala przeszkolić pracowników bez stresu.

PK: Jaki jest pierwszy krok dla firmy, która chce rozpocząć wdrożenie?

KK: Warto zacząć od wypełnienia ankiety przedwdrożeniowej, którą udostępniamy na naszej stronie. Następnie należy przejść przez formalne przygotowanie: wygenerować tokeny i certyfikaty na Portalu Podatkowym MF, ustalić procesy i definicje dokumentów, przygotować listę ról i osób obsługujących KSeF.

Kolejny krok to kontakt z COM@COM i umówienie spotkania analitycznego. Podczas tego spotkania omówimy szczegółowo scenariusze wysyłki, pobierania, role, procesy, konfiguracje i wyjątki. Na tej podstawie przygotujemy plan wdrożenia dostosowany do specyfiki firmy.

PK: Jak długo trwa typowe wdrożenie?

KK: Dla pakietu standardowego, obejmującego spotkanie analityczne, konfigurację środowiska testowego, szkolenie, testy i wdrożenie produkcyjne, szacujemy około 8-9 godzin pracy, rozłożonych na kilka etapów. Rzeczywisty czas zależy od złożoności procesów i liczby wyjątków w firmie.

Ważne jest, że nie trzeba wdrażać wszystkiego na raz. Można zacząć od podstawowych scenariuszy – wysyłki standardowych faktur sprzedaży i pobierania faktur zakupu – a później rozbudowywać o bardziej zaawansowane funkcje.

PK: Na koniec – czy wiadomo jest, jakie są plany względem rozwoju funkcjonalności KSeF w enova365?

KK: Producent oprogramowania enova365 – Soneta – nieustannie pracuje nad rozwojem. W najbliższych wersjach planowana jest m.in. obsługa wysyłki do KSeF identyfikatorów lokalizacji jako miejsca dostawy w fakturach sprzedaży oraz konfigurator do wysyłania dodatkowego opisu do KSeF.

Zarówno Soneta, jak i COM@COM, nieustannie śledzi zmiany w przepisach i wymaganiach Ministerstwa Finansów, żeby enova365 zawsze była zgodna z aktualnymi standardami. Nasi Klienci mogą być pewni, że system będzie gotowy na wszystkie zmiany związane z obowiązkowym KSeF.

PK: Karol, bardzo dziękuję za całą serię rozmów. Myślę, że naszym Klientom i Czytelnikom pomoże to w przygotowaniu do KSeF.

KK: Dziękuję za możliwość podzielenia się wiedzą. Zachęcam wszystkich do kontaktu z COM@COM, jeśli mają dodatkowe pytania czy potrzebują wsparcia we wdrożeniu. Jesteśmy tu, żeby pomóc.

O autorach