- Specjalizujemy się w naprawach laptopów, z jakimi nie poradziły sobie inne serwisy
- Naprawa laptopów po zalaniu
- Naprawa laptopów po upadku
- Specjalistyczne naprawy płyt głównych
JPK, czyli Jednolity Plik Kontrolny, to ustandaryzowany plik danych księgowych przekazywany administracji skarbowej albo udostępniany na żądanie. W programach InsERT GT przygotowanie takiego pliku opiera się na danych zapisanych w bazie firmy, dlatego poprawność dokumentów sprzedaży, zakupów, kontrahentów i stawek VAT ma bezpośredni wpływ na wynik eksportu.
W praktyce najczęściej występują dwa różne zadania. JPK_V7 zawiera ewidencję VAT oraz część deklaracyjną, natomiast JPK_FA obejmuje dane faktur i jest przygotowywany na potrzeby kontroli lub konkretnego żądania. Nie są to zamienne pliki. Inne są także ich zastosowanie, zakres danych i sposób przekazania do biura rachunkowego lub urzędu.
JPK_V7 jest plikiem okresowym związanym z rozliczeniem podatku od towarów i usług. Zawiera między innymi informacje o sprzedaży, zakupach, podstawach opodatkowania, stawkach VAT i kwotach podatku. W zależności od sytuacji rozliczeniowej może dotyczyć okresu miesięcznego albo być częścią rozliczenia kwartalnego. Właściwy wariant powinien wynikać z ustaleń z biurem rachunkowym.
JPK_FA to struktura przeznaczona do przekazania danych faktur. Nie zastępuje JPK_V7 i nie służy do bieżącego rozliczenia VAT. Zwykle przygotowuje się go w określonym zakresie, na przykład dla wskazanego okresu albo rodzaju dokumentów. Przed eksportem trzeba ustalić, jakie faktury mają zostać ujęte i jakie wymagania zawiera wezwanie.
W Subiekcie GT można również pracować z innymi programami rodziny InsERT GT, takimi jak Rewizor GT, Rachmistrz GT, Gratyfikant GT i Gestor GT. Integracje ze sklepem internetowym dotyczą wyłącznie Subiekta GT, ponieważ jest on systemem sprzedażowo-magazynowym. Pozostałe wymienione programy mogą być obsługiwane i wdrażane bez integracji ze sklepem.
Najczęstszy objaw to komunikat pojawiający się podczas tworzenia pliku, sprawdzania jego poprawności albo wysyłki. Program może wskazać brak wymaganego pola, nieprawidłowy numer dokumentu, niezgodną stawkę VAT lub błąd danych kontrahenta. Czasem eksport kończy się bez widocznego błędu, ale biuro rachunkowe odrzuca plik podczas importu albo system administracji skarbowej nie przyjmuje dokumentu.
Problem może też wyglądać inaczej. Plik jest tworzony, lecz zawiera zbyt mało dokumentów, nie obejmuje korekt albo pokazuje wartości różniące się od raportu sprzedaży. Innym sygnałem jest rozbieżność między dokumentami w Subiekcie GT a danymi zaimportowanymi do programu księgowego. W takiej sytuacji nie należy od razu ponawiać wysyłki. Najpierw trzeba ustalić, czy błąd dotyczy danych, zakresu eksportu, struktury pliku czy samego procesu przekazania.
Najczęściej przyczyną są niekompletne dane dokumentów. W fakturze może brakować właściwego oznaczenia VAT, rodzaju sprzedaży, informacji wymaganej dla korekty albo danych nabywcy. Problemem bywają również błędne daty: data wystawienia, data sprzedaży i data obowiązku podatkowego mogą mieć różne znaczenie dla ewidencji.
Drugą grupę stanowią ustawienia podatkowe i słowniki. Słownik to lista zdefiniowanych w programie wartości, takich jak stawki VAT, formy płatności, typy dokumentów czy kartoteki kontrahentów. Jeżeli dokument używa starej albo nieprawidłowej pozycji słownika, eksport może nie odpowiadać wymaganej strukturze JPK.
Częstą przyczyną jest także niewłaściwy zakres dat lub rodzaj dokumentów. JPK_FA przygotowany dla całej bazy zamiast dla wskazanego okresu może być niezgodny z zakresem wezwania. W JPK_V7 problem może wynikać z pominięcia korekt, dokumentów wewnętrznych albo zmian wprowadzonych po wcześniejszym eksporcie.
Znaczenie ma również wersja programu i używane definicje struktur. Struktura JPK, czyli opis wymaganych pól, formatów i zależności między danymi, może się zmieniać. Dlatego sam fakt, że wcześniejszy plik został zaakceptowany, nie oznacza, że identyczne ustawienia będą właściwe w innym okresie.
Przed jakąkolwiek ingerencją w bazę danych wykonywana jest jej kopia. Baza danych to uporządkowany zbiór informacji o dokumentach, kartotekach, kontrahentach i konfiguracji programu. Kopia pozwala wrócić do stanu sprzed zmian, jeżeli poprawianie danych wpłynie na dokumenty, raporty albo późniejsze operacje.
Nie powinno się ograniczać do skopiowania pojedynczego pliku bez sprawdzenia, czy obejmuje on całą bazę i czy można go później odtworzyć. W środowisku wielostanowiskowym, czyli takim, w którym z jednej bazy korzysta kilka komputerów, trzeba uwzględnić sposób pracy serwera oraz aktywne połączenia. Kopia powinna zostać opisana datą i zakresem, którego dotyczy.
Po utworzeniu kopii można przejść do analizy dokumentów. Jeżeli problem wymaga zmiany danych zapisanych w bazie, zakres modyfikacji powinien być możliwie wąski. Nie należy masowo zmieniać stawek VAT, typów dokumentów ani kartotek bez ustalenia, jaki skutek będzie miała taka operacja dla wcześniejszych okresów.
Najpierw sprawdzany jest dokładny komunikat, a nie tylko ogólna informacja o niepowodzeniu. Przydatny jest również log, czyli zapis przebiegu operacji zawierający informacje o wykonanych czynnościach i napotkanych problemach. Warto zachować nazwę pliku, zakres dat, rodzaj eksportu oraz moment, w którym pojawił się błąd.
Następnie porównuje się dokumenty źródłowe z raportami programu. Analiza obejmuje między innymi numery faktur, daty, dane kontrahentów, stawki VAT, korekty i oznaczenia wymagane w ewidencji. W przypadku JPK_FA sprawdza się również, czy eksport obejmuje dokładnie te dokumenty, których dotyczy żądanie.
Jeżeli plik jest przekazywany do programu księgowego, trzeba odróżnić błąd Subiekta GT od błędu importu. Import to wczytanie danych do innego programu. Plik może być poprawny formalnie, ale nie pasować do sposobu mapowania danych w programie biura rachunkowego. Mapowanie oznacza przypisanie pól z jednego systemu do odpowiadających im pól w drugim systemie.
Biuro rachunkowe powinno określić, jaki plik jest potrzebny, za jaki okres i w jakim zakresie. Dotyczy to zwłaszcza JPK_FA, ponieważ ten plik może być przygotowywany według konkretnego wezwania. Należy ustalić także, czy biuro oczekuje pliku XML, czy danych przekazanych przez określony mechanizm importu.
XML, czyli tekstowy format zapisu danych za pomocą znaczników, jest standardem stosowanym przy plikach JPK. Nie powinno się ręcznie edytować jego zawartości w zwykłym edytorze tekstu. Nawet niewielka zmiana może spowodować utratę zgodności ze strukturą albo zmianę danych bez kontroli w programie źródłowym.
Ważne jest rozdzielenie odpowiedzialności. Subiekt GT służy do przygotowania danych sprzedażowo-magazynowych i eksportu, natomiast biuro rachunkowe może odpowiadać za sprawdzenie rozliczenia, podpisanie pliku i jego przekazanie. Podpis elektroniczny to mechanizm potwierdzający tożsamość osoby lub podmiotu składającego plik. Sposób podpisu i wysyłki powinien zostać ustalony z biurem.
Walidacja, czyli sprawdzenie pliku według określonych reguł, może zgłosić błąd pola obowiązkowego, niewłaściwego formatu albo niespójności między elementami dokumentu. Jeżeli komunikat wskazuje konkretny numer faktury, analizuje się najpierw ten dokument. Jeżeli dotyczy całej paczki, sprawdza się zakres eksportu, wersję struktury oraz ustawienia programu.
Inny przypadek to poprawna walidacja, ale nieudana wysyłka. Przyczyną może być problem z podpisem, uprawnieniami, środowiskiem używanym do przekazania pliku albo niezgodność pliku z wymaganiami odbiorcy. Nie należy wtedy zmieniać danych faktur, ponieważ błąd może nie dotyczyć zawartości JPK.
Po wysyłce istotne jest UPO, czyli urzędowe poświadczenie odbioru. Samo wygenerowanie pliku lub zapisanie go na dysku nie potwierdza skutecznego przekazania. Dokumenty potwierdzające wysyłkę powinny być przechowywane zgodnie z zasadami przyjętymi przez firmę i biuro rachunkowe.
Bezpieczne czynności obejmują odczyt komunikatu, sprawdzenie zakresu dat, porównanie liczby dokumentów z raportem oraz potwierdzenie, czy eksport dotyczy JPK_V7 czy JPK_FA. Można również sprawdzić, czy wybrano właściwą firmę i właściwy okres rozliczeniowy, zwłaszcza gdy w programie działa więcej niż jedna baza.
Warto sprawdzić, czy dokumenty nie zostały oznaczone jako robocze, anulowane albo zapisane w innym okresie. Należy także porównać dane problematycznej faktury z dokumentem źródłowym, ale bez ręcznego poprawiania pliku XML. Jeżeli biuro rachunkowe przekazało konkretną treść błędu, trzeba zachować ją w całości.
Nie należy samodzielnie usuwać dokumentów, zmieniać numeracji ani przepisywać faktur tylko po to, aby zniknął komunikat. Takie działania mogą naruszyć ciągłość dokumentacji i utrudnić późniejsze ustalenie, co faktycznie wydarzyło się w bazie.
Jednym z ryzyk jest poprawianie danych bez kopii bazy. Drugim — wielokrotne generowanie pliku po kolejnych zmianach bez zapisania informacji o wykonanych czynnościach. W takiej sytuacji trudno określić, która zmiana usunęła problem, a która spowodowała nową rozbieżność.
Nieprawidłowym rozwiązaniem jest także usuwanie dokumentów z okresu objętego JPK tylko dlatego, że zawierają błąd. Faktura może wymagać korekty albo konsultacji księgowej, a nie fizycznego usunięcia. Podobnie nie powinno się ręcznie zmieniać numerów faktur, stawek VAT i dat bez ustalenia skutków podatkowych.
Nie należy również zakładać, że instalacja nowszej wersji programu automatycznie naprawi dane. Aktualizacja może być potrzebna, lecz nie zastępuje analizy dokumentów i kopii bezpieczeństwa. Przed zmianą wersji programu trzeba sprawdzić zgodność z używanymi bazami oraz dodatkami.
Nie każda rozbieżność w rozliczeniu wynika z błędu eksportu. Jeżeli raport sprzedaży w Subiekcie GT nie zgadza się z ewidencją prowadzoną w Rewizorze GT lub Rachmistrzu GT, przyczyną może być sposób przenoszenia danych, filtr dokumentów albo odmienne zasady księgowania. Wtedy trzeba przeanalizować przepływ danych między programami, a nie tylko sam plik JPK.
Jeżeli problem dotyczy drukarki fiskalnej, kasy albo urządzenia podłączonego do komputera, nie jest to automatycznie problem JPK. Obsługa może obejmować sterowniki i konfigurację, natomiast same urządzenia fiskalne nie są naprawiane. Podobnie błąd integracji sklepu internetowego dotyczy wyłącznie Subiekta GT i wymiany danych sprzedażowo-magazynowych, a nie JPK przygotowywanego w Rewizorze, Rachmistrzu, Gratyfikancie lub Gestorze.
Sfera GT to interfejs programistyczny oparty na COM i OLE Automation, czyli mechanizmach pozwalających innym aplikacjom korzystać z funkcji programu. Działa w Subiekcie GT, Gestorze GT, Rewizorze GT i Gratyfikancie GT. Jeżeli pliki są tworzone przez własne rozszerzenie wykorzystujące Sferę GT, źródła błędu trzeba szukać także w kodzie integracji i sposobie zapisu danych.
Czy chodzi o JPK_V7, czy o JPK_FA? Odpowiedź określa zakres danych, okres i sposób przygotowania pliku. Bez tego można poprawiać niewłaściwy eksport.
Czy plik ma zostać wysłany, czy tylko przekazany do biura rachunkowego? Wysyłka wymaga dodatkowej weryfikacji podpisu i potwierdzenia odbioru. Sam eksport może być tylko etapem pracy księgowej.
Czy błąd pojawia się w Subiekcie GT, podczas importu, czy dopiero przy walidacji? Każdy z tych etapów ma inne przyczyny. Dokładne wskazanie miejsca skraca analizę i ogranicza niepotrzebne zmiany.
Czy po ostatnim poprawnym eksporcie zmieniano dokumenty lub konfigurację? Informacja o korektach, aktualizacji programu, zmianie stawek albo integracji pomaga odtworzyć moment powstania problemu.
Standardowa naprawa problemu z konfiguracją lub danymi programu jest z reguły wykonywana do 3 dni. Jeżeli sprawa dotyczy przygotowania pliku, sprawdzenia ustawień i prostych korekt, prace mogą zostać przyspieszone do 24 godzin. Czas zależy od stanu bazy, liczby błędnych dokumentów, dostępności informacji z biura rachunkowego i konieczności odtworzenia problemu.
Wsparcie może odbywać się w modelu dojazdowym. Serwisant dojeżdża i pracuje na miejscu albo kierowca odbiera i zwraca sprzęt w formule door-to-door. Przed zmianami w bazie wykonywana jest kopia, a zakres modyfikacji powinien być opisany. Na wykonane naprawy może obowiązywać gwarancja do 12 miesięcy, wyłącznie w zakresie wykonanej naprawy.
Poprawne przygotowanie JPK_V7 i JPK_FA w Subiekcie GT wymaga rozróżnienia obu struktur, ustalenia zakresu z biurem rachunkowym oraz sprawdzenia danych źródłowych. Najważniejsze jest zachowanie kopii bazy przed zmianami i unikanie ręcznej edycji gotowego pliku XML. Gdy błąd dotyczy wymiany danych, integracji, walidacji albo podpisu, należy najpierw wskazać konkretny etap, na którym powstaje problem. Dopiero wtedy można dobrać właściwą korektę bez naruszania dokumentacji firmy.
Nie wiesz, od czego zacząć? Opisz objaw przez telefon
Zadzwoń, umów wizytę serwisanta — dotrze do Ciebie w ciągu godziny.