Import JPK_V7(3) uzupełnia brakujące oznaczenia KSeF, rodzaj dowodu z pliku w księgach oraz seria poprawek eksportu i importu danych
Import JPK_V7(3) z innego programu bez weryfikacji sam uzupełnia brakujące oznaczenia wymagane przez schemat (BFK, DI) na podstawie rodzaju dowodu, więc scalony plik przechodzi walidację; jedynego oznaczenia, którego nie da się odtworzyć (OFF), program nie zgaduje, tylko o nim przypomina. Wczytywanie JPK_V7 wprost do ksiąg przenosi rodzaj dowodu z pliku, dzięki czemu raporty kasowe i dokumenty wewnętrzne nie trafiają już do ksiąg jako faktury (dotyczy też importu z plików XML Comarch Optima). Okno księgowania e-faktur rozpoznaje zaksięgowane dokumenty niezależnie od ich typu, co chroni przed dwukrotnym zaksięgowaniem faktury offline. Do tego gruntowny przegląd wymiany danych między bazami (pliki .tmdb): kompletność eksportu, podmioty z faktur KSeF, scalanie kontrahentów po NIP, pozycje faktur przy imporcie płatności, zachowanie logo firmy i czytelne podsumowanie importu. W kanale testowym (Beta): osobny portal akceptacji dla każdej bazy danych wraz z poprawkami.
Opublikowano
Porcja zmian wokół wymiany danych z innymi programami — import JPK_V7
uzupełnia oznaczenia wymagane przez nowy schemat i przenosi rodzaj dowodu do
ksiąg — oraz gruntowny przegląd eksportu i importu danych między bazami
(pliki .tmdb). Zmiany dostępne są po aktualizacji do najnowszej wersji programu
(instalator: pobieranie programów).
Uwaga: dwie ostatnie zmiany dotyczą portalu akceptacji e-faktur, który jest na razie dostępny wyłącznie w kanale testowym (Beta) — oznaczono je dopiskiem „wersja testowa Beta". Pozostałe zmiany działają w wersji standardowej.
Import JPK_V7(3) bez weryfikacji — brakujące oznaczenia KSeF uzupełniane automatycznie
Schemat JPK_V7(3) wymaga, żeby każda pozycja ewidencji miała dokładnie jedno z oznaczeń: numer KSeF, OFF, BFK albo DI. Pliki z innych programów księgowych często tych oznaczeń nie zawierają — taki plik po scaleniu nie przechodził walidacji i nie dało się go wysłać.
Teraz przy imporcie z opcją Importuj bez weryfikacji program sam uzupełnia brakujące oznaczenia, dobierając je na podstawie rodzaju dowodu zapisanego w pliku:
- raporty z kas fiskalnych (RO) i dokumenty wewnętrzne (WEW) dostają DI — dowód inny niż faktura,
- faktury do paragonów (FP), faktury z metodą kasową (MK), faktury VAT RR i pozostałe pozycje dostają BFK — faktura wystawiona poza KSeF,
- pozycje, których z natury nie dokumentuje faktura — spis z natury, zwrot ulgi na zakup kas rejestrujących, podatek od niezwróconej kaucji, korekty podatku naliczonego z art. 90a–91 — dostają DI także wtedy, gdy plik nie podaje rodzaju dowodu.
Po imporcie program pokazuje podsumowanie: ile pozycji uzupełniono i jakim oznaczeniem. Jednego oznaczenia nie da się odtworzyć z pliku — OFF (faktura wystawiona w trybie offline). Jeżeli takie faktury są w ewidencji, trzeba je poprawić ręcznie, o czym komunikat wprost przypomina.
Import JPK_V7 do ksiąg — rodzaj dowodu przenoszony z pliku
Przy wczytywaniu pliku JPK_V7 z innego programu bezpośrednio do ksiąg każdy dokument dostawał dotąd typ „Faktura VAT" — niezależnie od tego, co faktycznie było w pliku. Skutek ujawniał się później: raport z kasy albo dokument wewnętrzny wracał do wygenerowanego JPK z oznaczeniem BFK, czyli z deklaracją, że istnieje faktura, której nie ma.
Teraz rodzaj dowodu jest odczytywany z pliku: pozycje oznaczone RO lub WEW trafiają do ksiąg jako Inny dokument VAT, a dokumenty z numerem KSeF — jako faktury. Ta sama zasada obowiązuje w imporcie z plików XML Comarch Optima. Dzięki temu wczytanie ewidencji i ponowne wygenerowanie z niej pliku JPK daje spójny wynik.
Okno księgowania e-faktur — pewniejsze rozpoznawanie już zaksięgowanych
Okno księgowania e-faktur oznacza każdą pobraną fakturę stanem („Nowa", „Zaksięgowane"), sprawdzając, czy w księgach istnieje już dokument z tym samym numerem KSeF. Dotąd za zaksięgowane uznawało jednak tylko dokumenty o typie Faktura VAT. Dokument zaksięgowany z faktury otrzymanej w trybie offline dostaje typ „Faktura offline" — i taki dokument nie był rozpoznawany: jego e-faktura wciąż pokazywała się jako „Nowa", co groziło zaksięgowaniem drugi raz. To samo dotyczyło dokumentów, w których księgowa ręcznie zmieniła typ na „Inny dokument VAT". Teraz zaksięgowany dokument jest rozpoznawany niezależnie od ustawionego typu.
Eksport i import danych między bazami (pliki .tmdb) — seria poprawek
Wymiana faktur, płatności, kontrahentów i produktów między bazami programu przeszła gruntowny przegląd. Poprawki:
- Kompletność eksportu. Przy eksporcie większej partii faktur — zwłaszcza zawierającej korekty, faktury zaliczkowe lub duplikaty — część pozycji mogła nie trafić do pliku przez błąd wewnętrznego mechanizmu pomijania powtórzeń. Usunięte; do pliku trafia zawsze komplet.
- Podmioty z faktur KSeF. Dodatkowe podmioty na fakturze — wystawca, drugi nabywca, faktor, podmiot pierwotny, jednostki samorządu, członkowie grupy VAT — są teraz poprawnie przenoszone między bazami. Wcześniej ich powiązania po imporcie wskazywały na przypadkowe rekordy.
- Kontrahenci dopasowywani po NIP. Jeżeli kontrahent z pliku istnieje już w bazie docelowej (np. został tam wcześniej wpisany ręcznie), import scala go z istniejącym rekordem zamiast zakładać duplikat. Kontrahenci bez NIP oraz przypadki dwóch podmiotów o tym samym NIP są obsługiwane bezpiecznie.
- Import płatności przenosi faktury w komplecie. Faktury towarzyszące importowanym płatnościom wczytywały się bez pozycji — powstawał sam nagłówek. Teraz wchodzą w całości, razem z pozycjami; dotyczy to również starych plików eksportu, bo dane zawsze w nich były, tylko import po nie nie sięgał.
- Logo firmy bezpieczne. Import faktur lub płatności kasował logo firmy, których akurat nie było w importowanym pliku. Już nie kasuje.
- Czytelny wynik importu. Pojedynczy rekord odrzucony przez bazę nie przerywa już importu ani nie psuje kolejnych rekordów, a na końcu program pokazuje podsumowanie z liczbą pominiętych pozycji i przyczynami — zamiast kończyć się po cichu z niekompletnymi danymi.
- Odporność na uszkodzone odwołania. Faktura odwołująca się do rekordu usuniętego w bazie źródłowej traciła przy imporcie nabywcę, odbiorcę i płatnika. Teraz pomijane jest tylko brakujące odwołanie, reszta powiązań wczytuje się poprawnie.
Osobny portal akceptacji dla każdej bazy (wersja testowa Beta)
Biuro prowadzące kilka baz danych może teraz uruchomić osobny portal akceptacji dla każdej z nich. Dotąd portal był jeden i obsługiwał bazę akurat otwartą w programie — po przełączeniu się na inną bazę i ponownej instalacji zaczynał po cichu obsługiwać innych klientów.
Nowe okno „Portale akceptacji dla wielu baz danych" (wstążka Konfiguracja → Usługi) pokazuje listę baz i pozwala każdej przypisać własny adres, pod którym klienci otwierają portal, oraz własną skrzynkę pocztową do wysyłki zaproszeń i przypomnień. Ustawienia jednej bazy nie mają wpływu na pozostałe.
Przy zakładaniu nie trzeba wszystkiego wpisywać ręcznie — przyciski „Kopiuj z bieżącego połączenia TM" i „Kopiuj SMTP z konfiguracji programu" przenoszą dane jednym kliknięciem. Kolumny „Stan" i „Czego brakuje" mówią, czy portal danej bazy działa i czego jeszcze wymaga, a zaznaczone pozycje uruchamia się, zatrzymuje i instaluje razem — jednym poleceniem zamiast osobno dla każdej bazy.
Poprawki w portalu akceptacji (wersja testowa Beta)
- Klienci dostają linki pod właściwy adres. Adres portalu podany przy instalacji potrafił różnić się od tego, którego program używał w mailach — klient dostawał link prowadzący pod stary adres, choć konfiguracja wyglądała na poprawną. Teraz jest uzgadniany przy instalacji, a przycisk „Porównaj z ustawieniami w bazie…" pokazuje ewentualną rozbieżność.
- Sprawdzenie konfiguracji niczego nie wysyła. Kontrola ustawień wykonywana po instalacji potrafiła przy okazji rozesłać klientom zaległe powiadomienia i oznaczyć je jako wysłane. Teraz wyłącznie sprawdza.
- Poprawione również: zatrzymywanie i odinstalowywanie portalu oraz zapamiętywanie hasła do bazy przy ponownej instalacji.