Krzysztof Lipczyk

Bardzo jasno widać, że cena jednostkowa podmiotu dla abonamentu NEXO jest tańsza niż GT. Z branży wiem, że sporo osób wybierała produkty Insert z uwagi na sposób licencjonowania, co było atutem firmy - czy tak będzie teraz? Zobaczymy. Zmiana licencjonowania nie została klarownie przedstawiona klientom poza regularnymi zachętami do zakupów promocyjnych NEXO oraz informacji o zakończeniu sprzedazy licencji open. Wzrost kosztów rozumiem, natomiast zmiana zasad licencjonowania bardzo mnie rozczarowała i trudno stwierdzić, że ma jakikolwiek związek. Dla porównania abonament na zestaw Gt w 2022 (RachmistrzGt + RewizorGt + GratyfikantGt + BiuroGt) wynosił 1616 zł netto + VAT w przedłużeniu przed upływem terminu. Dzisiaj, rok później, taki sam zestaw dla obsługiwanych podmiotów wynosi 4372 zł netto + VAT również w przedłużeniu przed upływem terminu. Wychodzi, że podwyżka w moim przypadku wynosi 270,50% 🤡

Dalej Z-3 generuje nieporawną strukturę. Wersja 1.75 miała mieć aktualny wzór, zgodny z PUE ale chyba nie zadziałało

W module deklaracji ZUS przy generowaniu Z-17 program wpisuje w tabelę nieaktualne stawki podatkowe. Uzupełnia podatek liczony jako 18% dochodu, zamiast 12%. np. dla drugiego wiersza: 1471,86 x 0,18 = 264,93 zł (wartość niepoprawna) 1471,86 x 0,12 = 176,62 zł (wartość poprawna)

Ten parser rozpoznaje płatności podzielone. Czy jest idealnie? Tego nie wiem, ale zapewnia taką funkcjonalność że znaczna większość użytkowników będzie zadowolona. Można pooznaczać operacje, poprawnie przypisać itd. Ostatecznie stworzyć wyciąg bankowy i zaksięgować lub dekretować każdą operację bankową z osobna - co kto lubi Co do opłat to bywa różnie - jedni widzę płacą 50 zł, a inni nic nie płaca.

Gratyfikant Gt nie uzupełnia numeru REGON, który jest wymagany i w sumie Z-3 notorycznie nie akceptowane przez PUE ZUS. Mnie przez ostatnie lata udało się wysłać tylko jeden raz Z-3 i to właśnie po uzupełnieniu numeru REGON. Ostatnio taki komunikat przy imporcie się pojawia:

Parser PKO BP poprawnie wczytuje pliki MT940 z mBanku. Pliki kodowane są w UTF-8.

Warto byłoby informację o takiej zmianie umieścić bo obecne rozwiązanie wygląda bardziej jak błąd oprogramowania niż celowe działanie, a to mimo wszystko mała ale bardzo istotna zmiana.

Dzień dobry, GratyfikantGT dokonuje niepoprawnie potrącenia komorniczego dla umowy o pracę z minimalnym wynagrodzeniem. Część osób z listy płac ma naliczone potrącenie bez uznania ochrony wynagrodzenia ze względu na stawkę minimalną. Jest to o tyle ciekawe, że te osoby w poprzednich miesiącach nie miały dokonanego potrącenia. Pracownik ma skonfigurowaną umowę o pracę na 1/2 etatu z wynagrodzeniem 1400 zł brutto. Przy liście płac generowany jest składnik pensji zasadniczej i nic poza tym. Także, do potrącenia nie powinno dochodzić. Tymczasem, program niestety dokonuje potrącenia wbrew przepisom. Dla przykładu we wcześniejszej wypłacie takie zjawisko nie miało miejsca:

U mnie od dawna nie udało się poprawnie wysłać żadnego zaimportowanego Z-3, uprzednio wyeksportowanego z GratyfikantaGT. Za każdym razem mam poprawny import, poprawną autoweryfikację i przy próbie podpisania z wysłaniem dokument wraca do ponownej autoryzacji - czyli nie jest wysłany. Korzystam zwykle z bieżących wersji oprogramowania (aktualizuję kiedy można) - obecnie 1.67 SP1 HF1 (1.6711.11.5140). Nie ukrywam, że ta funkcja jest bardzo przydatna, ze względu na niekomfortowe uzupełnianie formularzy dostępnych w PUE. Po imporcie: Przy wysyłce: i tak jest od wielu miesięcy...

Niestety ta funkcja dalej nie współgra z PUE ZUS - w zasadzie każdy eksport kończy się poprawnym importem, poprawną weryfikacją przez platforme PUE, a przy wysyłce zwraca komunikat jak z pierwszego posta tematu - "Dokument "Zaświadczenia ZUS Z-3" nie został wysłany. Wystąpił błąd podczas wykonywania usługi biznesowej wysyłki dokumentu"

Przepisy wymagają ujawnienia w plikach JPK nabywców - każdy musi mieć swój wpis w ewidencji VAT a aktualne zmiany nie upraszczają tego, a wręcz przeciwnie zmuszą do wpisania wszystkiego. Zatem scalenie odbiorcy w jednego kontrahenta odpada. Pozyskiwane dane ze źródła nie tworzą rozróżnienia na klienta detalicznego i niedetalicznego, więc to też odpada. Zostaje tylko kontrahent jednorazowy, ale z tego co się orientuje to on też uzyskuje wpis w tabeli kh__Kontrahent, jak wszyscy, tylko ma specyficzny symbol w kolumnie kh_symbol z wartością "********************" - czy takie rozwiązanie przyspieszy procesy importu czy nie tego nie wiem, jeśli ktoś z was wie to proszę o podpowiedź. Czy takie rozwiązanie spowoduje, że zapytanie SQL, o którym mowa w tym poście, nie będzie uruchamiane? Zmiany procesów u klienta można by ustawić tak, żeby selektywnie importować rodzaje transakcji - właśnie z podziałem na detal i firmy, jednak obecne zmiany VAT po części utopiły ten temat. Fiskalizacja transakcji znacznie ułatwiłaby sprawę, ale niestety to rozwiązanie zostało odrzucone.

Tak, zdaję sobie sprawę z takiego rozwiązania, ale ze smutkiem na chwilę obecną nie mam takiej możliwości. Taka zmiana rodziłaby konieczność dostosowania pewnych procesów u klienta. Męczę temat od 2 lat Czyli wygląda na to, że taką bazę kontrahentów można oczyścić - to też jest ciekawe rozwiązanie warte uwagi. Proszę:

W bazie znajduje się ok. 800 tys. kontrahentów, 99% niepotrzebnych gdyż mają powiazania tylko z rejestrem VAT i kontem bez rozrachunków. Byłaby to bardzo fajna opcja, gdyby InsertGt nie umieszczał automatycznie kontrahentów jeśli nie tworzy się dla nich rozrachunków. Kiedyś testowo usunąłem wszystkich kontrahentów żeby sprawdzić czy import dokona dekretów i wpisów w ewidencji VAT bez zakładania kartotek dla nich, ale nie - nawet z usuniętymi kontrahentami dodaje ich na podstawie zapisów z nagłówków dokumentów. Najchętniej usunąłbym wszystkich kontrahentów, którzy nie mają przypisanych kont analitycznych - ich jedyne powiązanie jest z wpisem w rejestrze VAT, ale przyznam szczerze, że nie wiem czy to nie naruszyłoby integralności danych. Co do planów wykonania, to SSMS sugerował założenie 2 indeksów dla kolumn. Poprawiło to szybkość wykonywania zapytania o jakieś ~500ms.

Niestety praca na wspólnej bazie danych odpada. Klient pracuje na WAPRO i jedyna opcja to niestety konwersja plików eksportowych do EPP. Pliki zawierają bardzo dużą ilość pozycji (dziesiątki tysięcy miesięcznie). Praca na wspólnym środowisku i bazie byłaby spełnieniem marzeń bo wiadomo ma to więcej korzyści niż import z EPP. Dobrze się, składa bo lada dzień ten staroć zostanie zastąpiony trochę młodszą maszynką i chętnie podzielę się rezultatami. Następcą jest i7-6700, 16GB RAM, M.2 SSD, Win10Pro z opcją rozszerzenia pamięci RAM do 32GB ale najpierw muszę zobaczyć czy w przypadku SQL Express ma to jakikolwiek sens. Baza po 2 latach ma ok. 4 GB, także jeszcze jest limit.

Czy ma ktoś pomysł na optymalizację związaną z zapytaniem SQL, które jest wykonywane podczas importu z pliku EDI w fazie importowania kontrahentów. Uruchomione na RewizorGT (1.64 HF2 (1.6402.2.4882). Plik EDI zawiera zwykle po 5-15 tys. kontrahentów i podobną ilość dokumentów handlowych. Zapytanie (w miejscu numer_nip jest oczywiście konkretny NIP): SELECT TOP 1 kh_Id, adr_Id, adrh_Id FROM kh__Kontrahent AS a INNER JOIN adr__Ewid AS b ON a.kh_Id=b.adr_IdObiektu INNER JOIN adr_Historia AS c ON b.adr_Id=c.adrh_IdAdresu WHERE adr_TypAdresu=1 AND REPLACE(REPLACE(adr_NIP,'-','' ),' ','')='numer_nip' ORDER BY adrh_Id DESC SQL Profiler zwraca informację, że czas przetwarzania takiego zapytania wynosi od 11 do 13 sekund. Czy ma ktoś pomysł jak to przyspieszyć? Zapytanie wykonywane jest na SQL Express 14.0.20.27 na dość starym sprzęcie (Q8200 @2.33Ghz, 8GB RAM, SSD, Win10Pro), ale to nie jest raczej powód. Gdy tylko z tego zapytania usuniemy fragment AND REPLACE(REPLACE(adr_NIP,'-','' ),' ','')='numer_nip' i zastąpimy to adr_NIP='numer_nip' to zapytanie wykonywane jest błyskawicznie. Wygląda to tak, że funkcja REPLACE mieli kolumnę z numerami NIP. Ma ktoś jakiś pomysł na to?