Skocz do zawartości
Forum użytkowników

Radosław Kostrzewa

Partner
  • Ilość treści

    66
  • Rejestracja

  • Ostatnio

Reputacja

2 Neutral

Ostatnio na profilu byli

535 wyświetleń profilu
  1. Korekta. W Ustawie T2 zapisano, ze przychody zwolnienia ze składek nie stanowią przychodu w rozumieniu również podatników CIT.
  2. Jest to uzależnione od tego, czy podmiot jest płatnikiem podatku dochodowego od osób fizycznych, czy prawnych. W przypadku osób prawnych umorzenie stanowi przychód podatkowy, w przypadku fizycznych - przychód nie stanowi przychodu podatkowego. Co do zasad księgowania, księguje Pani w odpowiednią analitykę (podatkową lub niepodatkową) w pozostałych przychodach operacyjnych. Jeśli bardziej szczegółowo - to z tyt. odpisów zobowiązań - zobowiązania publicznoprawne. Mając do tego wyszczególnioną analitykę można od strony księgowej mieć kontrolę nad wartością pomocy publicznej, z której się skorzystało - co może być pomocne w przyszłości w przypadku konieczności raportowania tego. Jeśli chodzi o moment księgowania - ponieważ ZUS nie wydaje w tych przypadkach decyzji, a jedynie informuje o umorzeniu, bezpiecznie jest przyjąć moment zapadalności terminu płatności za dane składki. Oczywiście, jest to moja własna interpretacja, proszę ją zweryfikować we własnym zakresie.
  3. Jak wspomniałem poprzednio wg mnie to obowiązek. Nie jestem prawnikiem, ale podejrzewam, że znajdą się i prawnicy którzy będą widzieli szansę udowodnienia tego, że nie ma obowiązku przekazania przez BR zapisów klientowi w JPK_KR, jak i Ci, którzy będą w stanie do udowadniać. Proszę pamiętać, że JPK_KR jest nowym tworem, ale odnosi się on też do dokumentacji księgowej, tylko w usystematyzowany sposób elektroniczny. Podejrzewam, że w dowodzie prawników, którzy by bronili stanowiska klienta jest to, że jeżeli kodeks cywilny dopuszcza dokumenty w wersji elektronicznej, to klient ma prawo otrzymać swoje dane również w takiej postaci. Także dalej pozostaję przy stanowisku, że baza danych jest własnością biura, ale wszelkie raporty, deklaracje, zestawienia (zarówno elektroniczne jak i papierowe) są własnością klienta. I o ile JPK_KR generowany jest na życzenie organów skarbowych, o tyle klient też może się zwrócić do BR z pismem informującym, że na wskutek prowadzonych czynności sprawdzających został poproszony o dostarczenie plików JPK_KR za okresy... Nie wnikając na rzeczywistość - czy odmówi wtedy po takim piśmie Pani wydania tych plików?
  4. Wg mnie ma Pani obowiązek, jeśli klient o to prosi. Klient jest dalej zobligowany móc dostarczyć na żądanie kontrolne zapisy JPK_KR organom podatkowym. Jeśli ich nie uzyska od Pani, nie będzie mógł się z tego obowiązku wywiązać. Co do zapisów, pytanie nie jest głupie. Owszem, zapisy mogą być jak najbardziej wynikiem autorskiego ułożenia procesów księgowych, ale musi je Pani udostępnić. To trochę tak, jakby zrobić schody z salony na antresole. Mogą być proste, kręcone. Szare, kolorowe. Ostatecznie wejście po nich prowadzi do tego samego celu. Trudno (choć kto wie, jak w USA) zastrzec innym zrobienia takich samych schodów, tylko dlatego, że nasze przyozdobiliśmy w jakieś wzorki...
  5. Dyskusja zawsze może być akademicka, tylko nie wiem po co. Proszę wskazać przepis prawny, który obliguje biuro rachunkowe do wydania klientowi bazy, jeśli nie zostało to zapisane w umowie dwustronnej. Po prostu takiego przepisu prawa nie ma i tutaj na ten moment dyskusja akademicka się kończy. Ale proszę szukać... Są określone w przepisach, co należy wydać klientowi w przypadku, kiedy zmienia się osobę/program do prowadzenia ksiąg rachunkowych. Do tego oczywiście należy też zaliczyć wersje elektroniczne wytworzonych dokumentów. Zatem mamy tutaj mowę o wystąpieniu o pliki np. JPK_KR, KPK_VAT, pliki e-sprawozdań, oraz wymagane wydruki (obrotówka, etc). To nie muszą być nawet wersje XLS... http://www.kancelaria-accountant.pl/Aktualnosci/W-jakiej-formie-biuro-rachunkowe-powinno-przekazac-ksiegi Zatem, jeśli to wszystko co jest wynikiem pracy odtwórczej na bazie jest przekazane z zachowaniem opisanych wymogów, nie podlega ochronie praw autorskich. Ale też - co ciekawe - sama baza, która może być już efektem autorskiego podejścia do implementacji pewnych procesów księgowych - już tak. My osobiście stworzyliśmy np. dla klientów bazę wzorcową dla Rewizora GT, która zawiera wiele rozwiązań, a do tego jest dokumentacja, która tłumaczy, dlaczego w takim programie jak Rewizor GT procesy zostały zorganizowane i jaki efekt dzięki temu uzyskujemy. I kolejna istotna rzecz. Proszę pamiętać, że wraz z bazą InsERT przechowywana jest licencja programu. Jeśli doszliśmy do porozumienia, że chcemy mu przekazać bazę, klient najpierw powinien się wyposażyć w odpowiednią licencję, a biuro rachunkowe za pośrednictwem partnera lub w bezpośrednim kontakcie z InsERT powinno przekazać bazę do wgrania licencji klienta.
  6. @Tomasz Dusza Mamy bardzo dużo rozwiązań, ale dodajemy je do sklepu... powoli Podpięte. https://3rp.com.pl/sklep/marki/insert/gt/wydruk-potwierdzenie-salda-aib-po-angielsku-gt-navireo/
  7. Pani Moniko, tak jak @Daniel Kozłowski napisał, Rachmistrz nie obsługuje rozrachunków. Wprowadzenie dokumentu zakupowego w księdze Rachmistrza nie tworzy z takich zapisów rozrachunków. Kompensata, która jest w Subiekcie, dotyczy modelu rozrachunkowego. W takim przypadku należałoby wprowadzać zakupu jako FZ w Subiekcie - wtedy miałaby Pani do nich rozrachunki i mogła kompensować, a w oparciu o schematy importu tworzyć do FZ wpisy w księdze i ewidencji VAT.
  8. Nie jestem księgowym, nie będę dyskutował, opisałem swoje doświadczenia jak pracują inne księgowe według których "nie musi". Nie podchodziłbym co do zasady, że tutaj coś musi i nie musi. Podejrzewam, że jeśli w polityce rachunkowości opiszemy, że nie wykazujemy w zapisach księgowych podatku należnego i naliczonego w jednym momencie, to może by to przeszło. Osobiście jednak na to bym się nie zdecydował, z uwagi na: Art. 24 UoR, pkt. 1: Księgi rachunkowe powinny być prowadzone rzetelnie, bezbłędnie, sprawdzalnie i bieżąco. pkt. 2. Księgi rachunkowe uznaje się za rzetelne, jeżeli dokonane w nich zapisy odzwierciedlają stan rzeczywisty. oraz Art. 22 UoR pkt. 1: Dowody księgowe powinny być rzetelne, to jest zgodne z rzeczywistym przebiegiem operacji gospodarczej, którą dokumentują, kompletne, zawierające co najmniej dane określone w art. 21 elementy dowodu księgowego, oraz wolne od błędów rachunkowych. Niedopuszczalne jest dokonywanie w dowodach księgowych wymazywania i przeróbek. Ostatecznym efektem takie podejścia do księgowań rozliczeń VAT jest zgodność obrotów na kontach VAT z rzeczywistymi ujęciami tych kwot w ewidencji.
  9. Jeśli uzna Pan, że systemowe zestawienia InsERT to za mało, może Pan wtedy skorzystać z naszego zestawienia: https://3rp.com.pl/sklep/marki/3rp-com-pl/zestawienie-sql-dekretow-i-pozycji-ich-zapisow-z-eksportem-do-xls/ Dostępne kolumny w pozycjach: 1. Rok obrotowy: rok obrotowy dla dekretu 2. Rejestr: symbol rejestru księgowego 3. Dekret nr: Nr dekretu w rejestrze 4. Nr w dzienniku: nr księgowy nadawany dla zaksięgowanych dekretów w dzienniku księgowań 5. Nr dok: numer zadekretowanego dokumentu 6. Rodzaj dowodu: opis rodzaju dowodu księgowego 7. Opis dekretu: opis dekretu 8. Kategoria dekretu: kategoria dokumentu 9. Nr dokumentu źródłowego: w przypadku pracy na jednej bazie z modułem handlowym – nr (systemowy) dokumentu obrotwego w systemie 10. Data dokumentu źródłowego: w przypadku pracy na jednej bazie z modułem handlowym – data dokumentu obrotwego w systemie 11. Status: status księgowy dekretu (niezaksięgowany/zaksięgowany) 12. Data dekretacji: data bilansowa ujęcia zapisów księgowych w dekrecie 13. Data dokumentu: data dokumentu księgowanego w dekrecie 14. Data operacji: data wykonania zapisu dekretu 15. Lp: Kolejny numer pozycji zapisu księgowego w dekrecie 16. Nr konta: nr konta w zapisie pozycji dekretu 17. Nazwa konta: nazwa konta księgowego w zapisie pozycji dekretu 18. WN PLN: zapis kwoty po stronie Winien w wartości PLN 19. MA PLN: zapis kwoty po stronie Ma w wartości PLN 20. WN wal.: zapis kwoty po stronie Winien w walucie 21. Ma wal.: zapis kwoty po stronie Ma w walucie 22. Waluta: waluta na pozycji zapisu dekretu 23. Kurs: zastosowany kurs waluty na pozycji dekretu 24. Data kursu: wskazana data kursu na pozycji dekretu 25. Nr dok. obrot.: w przypadku pracy na jednej bazie z modułem handlowym – nr (oryginalny) dokumentu oborotwego w systemie 26. Opis pozycji: opis pozycji zapisu dekretu 27. Kategoria pozycji: (tylko w Navireo) użyta kategoria na pozycji zapisu dekretu Dostępne opcje filtrowania: 1. Wybór roku obrotowego 2. Wskaznaia rejestru księgowego: multiwybór 3. Status dekretu: multiwybór (niezaksięgowany | zaksięgowany) 4. Numer dekretu: pole do wskazaniakonkretnego nr dekretu 5. Data dekretacji: filtr zakresu dat z gotowymi wartościami 6. Opis dekretu: pole tekstowe do wyszukania dekretów po jego opisie 7. Nr dokumentu: pole tekstowe do wyszukania dekretów po numerze księgowanego dokumentu 8. Rodzaj dowodu: multiwybór: rodzaje dowodów księgowych 9. Kategoria dekretu: multiwybór – kategoria użyta na dekrecie 10. Dokument źródłowy nr: pole tekstowe do wyszukiwania dekretów po nr systemowym dokumentu źródłowego modułu handlowego przy pracy na jednej bazie 11. Data wystawienia dokumentu źródłowego: pole zakresu do wyszukiwania dekretów po dacie wystawienia dokumentu źródłowego modułu handlowego przy pracy na jednej bazie 12. Nr konta: pole tekstowe do zawężenia raportu do zapisów na wskazanym koncie 13. Nazwa konta: pole tekstowe do zawężenia raportu do zapisów na kontach o określonej nazwie 14. Nr dokumentu obrotowego: pole tekstowe do wyszukiwania dekretów po nr oryginalnym dokumentu źródłowego modułu handlowego przy pracy na jednej bazie 15. Opis pozycji: pole tekstowe do wyszukiwania zapisów pozycji dekretu wg ich opisów 16. Kategoria pozycji: (tylko Navireo) multiwybór do wyselekcjonowania zapisów pozycji dekretów z wybraną/nymi kategorią/riami. 17. Typ konta: multifiltr na typy kont księgowych (bilansowe, bilansowo-wynikowe, wynikowe, pozabilansowe).
  10. Nie mamy tej drukarki, żebyśmy mogli przetestować - ale jeśli ma Pani aktywny abonament - proszę spróbować skonfigurować drukarkę przez SUZ-a, zamiast bezpośrednio w Kasiarzu - i zweryfikować.
  11. Zapewniam Panią, że InsERT nie dyskryminuje użytkowników linii GT. Linia GT ma swoje ograniczenia związane z zaprojektowaną strukturą, która pamięta początek lat 2000. Często zmiany - które w linii nexo są szybkie do wprowadzenia, w GT wymagają karkołomnych rozwiązań. Modelowym przykładem, który wpływa na znaczną część funkcjonalności, są rozrachunki, których w Rachmistrzu GT nie ma. Owszem, w innych liniach GT są, ale to, że jest to jedna baza, to nie znaczy, że da się to szybko w GT zaimplementować, ponieważ cała struktura danych została przygotowana do wiązania rozrachunków ale w Rewizorze GT... Przykładów można by mnożyć. Doskonałym przykładem, że InsERT nie dyskryminuje użytkowników GT są bardzo korzystne ceny licencji migracyjnych. Również raz na jakiś czas zdarzają się jeszcze lepsze oferty (np. za 25% ceny).
  12. Trochę obejściem może być zastosowanie modułu Rozliczeń, który de facto miał służyć modelowi rozliczeń metody kasowej. Nie testowałem całości scenariusza, na pewno robiąc wpisy schematem do ewidencji VAT ze spłat w module Rozliczeń, należałoby uwzględnić poprawienie opisów w ewidencji VAT zakupu. Należy pamiętać, że jeśli mamy tutaj ustalone raty z dostawcą, to należałoby od przeksięgować jeden rozrachunek na kwoty cząstkowe, tworząc odpowiednią ilość rozrachunków z określonym czasem spłat, przypisując właściwie kwoty netto i vat oraz zaznaczając w rozrachunkach 'metoda kasowa'.
  13. Czy na tym komputerze ma Pani jakieś inne oprogramowanie wykorzystujące mechanizm wydruków Crystal Report? Jaki jest system operacyjny? Z jakimi wydarzeniami zbiegł się problem z wydrukami (a może baza była przeniesiona na poziomie samego SQL-a a nie podpięta przez program serwisowy)? Czy jednak pracowała Pani do tej pory i to nagle przestało działać? Jeśli tak, to proszę w okolicach tej daty sprawdzić, czy w windowsie doszły jakieś windows uptade i czy jakieś inne oprogramowanie było wtedy instalowane?
  14. Wtrącając się do dyskusji, należy pamiętać, że oprogramowanie pudełkowe (nie tylko InsERT-u) w klasycznej komunikacji klient-serwer sql (gdzie jeszcze sporo funkcjonalności opiera się na procedurach bazodanowych) będzie miało swoje ograniczenia wydajnościowo w korelacji do zasobów sprzętowych i kosztów związanych z bieżącymi konserwacjami takich baz. Sytuacja zaczyna się już trochę zmieniać w przypadku oprogramowania dla firm będących obiektowymi rozwiązaniami (baza służy tylko do zapisu i odczytu danych). Jednak przypadek nexo nie będzie tutaj dobrą kalką, gdyż sama pewna funkcjonalność w programie, skrojona pod pewnie 'uniwersum' użytkowe, też może powodować problemy na końcówkach przy dużej liczbie obiektów. Dopiero faktycznie rozwiązania klasy ERP mają takie mechanizmy jak np. serwery aplikacji (odpowiadające za komunikację klient-serwer a nie klient-baza), realizujące zapisy do bazy hurtowo (a nie per pozycja, wielokrotnie 'mielenie' insertów i update'ów nawet z kontekstu jednego dokumentu), gdzie utrzymanie dużych baz jest po prostu wygodniejsze. W przypadku InsERT bez problemu jednak utrzymujemy bazy i po ponad 100 GB. Bardziej jest zasadnicze, jakie tabele mają wpływ na wielkość bazy.
  15. Tak. Koszt około 300 PLN netto. Do weryfikacji po ustaleniu szczegółów.
×