Skocz do zawartości

Jan Reczek

Partner
  • Liczba zawartości

    1 369
  • Rejestracja

  • Ostatnia wizyta

Posty dodane przez Jan Reczek

  1. Dołączę się do wątku.

    Skąd mogła się pojawić inna kwota w polu "Koszt rzeczywisty" niż "Koszt ewidencyjny" - Są trzy faktury zakupu na towar, ceny zakupu na nich 20szt. 22,5 potem 10szt. po 21,50 i ostatnia faktura 10szt. po 21,5. Nie jest to komplet, nie był żadnych korekt.

    Na fakturze sprzedaży oczywiście na czerwono po pisaniu netto 30zł.

    Co wpływa jeszcze na wyliczenie "Kosztu rzeczywistego"

    image.png.ee64cfcd2fd8e1aa17768db9d35fa4d9.png

  2. Dokleję się do tematu.
    Mam zgłoszenie od klienta:
    "
    Gratyfikant GT  błędnie przenosi przychód z umowy zlecenie osoby do 26 lat do deklaracji PIT-11 .
    Inna kwota przychodu  jest na karcie wynagrodzeń za rok 2022, inną przenosi do wygenerowanego PIT-11  za 2022 dla tej osoby.
    Jakoś dziwnie zaokrągla do pełnych złotych niezgodnie z zasadami matematycznymi, ale w ogóle powinno przenosić przychód taki jaki był
    faktycznie, a nie zaokrąglony."

  3. Tak. Proszę Pana wiem, że można, ale przy obecnie zmieniających się przepisach nie zawsze jest czas i chęć płacenia za to przez klienta.
    Można było od wielu lat i jakoś Opteam się wycofał jak i wielu innych.

    Abstrahując od faktu, że część biur rachunkowych ma to gdzieś bo skoro w JPK nie jest wymagany adres to uważają, że oni też nie muszą mieć u siebie w zapisach.

    Ale są biura, które nie mają pod ręką jednoznacznego paragrafu, na którym mogli by się oprzeć, aby nie mieć zarzutu o nierzetelne prowadzenie ksiąg.

  4. Biura rachunkowe nagminnie wykorzystywały JPK_VAT do importów sprzedaży do ewidencji.

    Po to te dane.

    Klienci przyzwyczaili się do importów z systemów sprzedaży z innych firm za pomocą JPK.

    Teraz muszą wejść w każdy zapis aby zaktualizować dane o dane adresowe.
    Gorzej w przypadku indywidualnych klientów na FS detalicznych.

    Nawet tak zaawansowany program jak Nexo ze swoim JPK wewnętrznym nie zawiera tych danych.

     

    Konwerterów do EDI już nikt nie poprawia bo po co, jak więc importować duże ilości faktur z systemów zewnętrznych.

    Macie swoje rozwiązania?

     

     

  5. Panie Danielu nawet mi nie przyszło to na myśl bo aktualizacja do 1.65 szła poprawnie.

    Przed próbą aktualizacji robiłem sprawdzanie bazy, ale dopiero po aktualizacji do 1.65 i sprawdzeniu bazy było 3 błędy w spójności bazy. Po naprawie wykonało skrypt 1.6502_1.6600.enc i poszło dalej.

     

  6. Przyklejam się do tematu.

    U klienta baza ok 2GB wysypuje się aktualizacja z wersji 1.6409 do najnowszej.

    Zatrzymuje się na aktualizacji do wersji 1.65 więc do takiej zrobiona była aktualizacja, ale z tej wersji też nie zastartuje.

    Czyżby opłata cukrowa powodowała takie problemy?

    Macie jakąś witaminkę na to? (próbowałem różne wersje aktualizacji 1.66, 1.67, z ftp ze strony) i dalej nic

    SQL 2017 express i 2019 express

     

    Cytat

     

    Zastosowano do podmiotu skrypt: C:\Program Files (x86)\InsERT\InsERT GT\Skrypty\skrypt1.6502_1.6600.enc
    Nie powiodło się wykonanie polecenia:

    update tw__Towar set tw_OplCukrowaKofeinaKwota = 0.1
    update plb_UmowaCP_Parametry_Zestaw set upz_Umowa_Zgloszenie_ZUS_RUD = 1 where upz_Umowa_Rodzaj = 1 and upz_Id not in (3)
    update jpk_Wersja set jpkw_WaznaDo = '20201231' where jpkw_Typ=7 and jpkw_NrWersji=1;

    Błąd 0x80040E14: Internal Query Processor Error: The query processor encountered an unexpected error during execution (HRESULT = 0x80040e19).
    Aktualizacja podmiotu nie powiodła się: 0x80040e14: Internal Query Processor Error: The query processor encountered an unexpected error during execution (HRESULT = 0x80040e19).
    Przywrócenie podmiotu powiodło się.

     

     

×
×
  • Dodaj nową pozycję...