W dniu 2017-07-13 o 14:08, papuga pisze:
> On Thu, 13 Jul 2017 11:48:18 +0200
> Kviat wrote:
>>
>> W SubiekcieGT bez problemu wygenerujesz korektę do dokumentu
>> historycznego, nieistniejącego w bazie.
>
> Tak się jeszcze podpytam (trochę retorycznie, lecz nie jestem
> księgowym).

Słowo wyjaśnienia.
Bardzo proszę, żebyś to co piszę nie brał zbyt dosłownie. To jest grupa
dyskusyjna.

Co do subiekta, to nie była jakaś sugestia, tylko wskazanie, że są takie
programy, porównywalne cenowo które to potrafią.
Inny przykład:
https://dok.enova365.pl/Topic/6494
"Korekta faktur archiwalnych"

Ja też mogę się mylić i to co piszę, to nie są jakieś wytyczne, tylko
moje osobiste stanowisko w tej kwestii.
Spotkałem się oczywiście ze stanowiskiem, że odkąd w jpk_vat są dane
kontrahentów, to po korekcie nabywcy należy wysłać korektę jpk_vat
(wbrew informacjom, które można znaleźć na stronach MF i pozostałych,
które już tu były cytowane).
Ja nie jestem jakimś fanatycznym przeciwnikiem tego, uważam, że wysłanie
takiej korekty na pewno nie zaszkodzi, ale moim zdaniem nie jest
konieczne (mogę się mylić!).

To co skłoniło mnie do tej dyskusji (i tylko to :)), to sposoby jakie tu
były proponowane na "wyprostowanie" błędnych danych nabywcy (anulowanie,
korekty do zera...). A to, czy wyślesz skorygowany jpk_vat czy nie, to
rzecz wtórna.

Twój program po prostu uniemożliwia wygenerowanie dokumentu
korygującego, który mógłbyś (program mógłby) uwzględnić do korekty
jpk_vat (niezależnie od tego, czy chciałbyś/trzeba czy nie taką korektę
wysłać).
Gorzej, nawet nie masz możliwości wystawienia takiej korekty, która
byłaby uwzględniona w jpk_fa (jeżeli faktycznie nie trzeba wysyłać
korekty jpk_vat). I to jest sedno problemu.

W Twoim przypadku ponowne wygenerowanie pliku jpk_vat z poziomu programu
wiązałoby się z koniecznością ręcznej (edycja faktury) zmiany na
fakturze w bazie danych. (Nie uwierzyłem, dopóki nie zobaczyłem tego na
własne oczy po ściągnięciu demo...) A tego nie wolno robić, bo błędna
faktura została wprowadzona do obrotu i miałbyś niezgodność.

Żeby naprostować dane nabywcy zgodnie z przepisami pozostaje Ci
wystawienie korekty faktury "ręcznie" czy tam w jakimś exelu (a
księgowość sobie już poradzi z naprostowaniem rozrachunków, przecież PK
na podstawie tej korekty to nie problem).
Ja bym tak zrobił żeby jak najszybciej mieć _przede_wszystkim_ porządek
w papierach i żeby to było zgodne z przepisami.

Co do plików jpk,
http://www.comarch.pl/erp/zmiany-prawa/jednolity-pli
k-kontrolny/jpk-pytania-i-odpowiedzi/
"43. Czy w przypadku fakturowania z kilku różnych systemów pomocniczych
oprócz fakturowania z głównego systemu księgowego - należy wysłać kilka
plików JPK ze sprzedażą?

Tak. Zgodnie ze stanowiskiem MF, można będzie przygotować osobny plik
dla każdej struktury z powodu ekstraktowania danych z różnych systemów.
Dodatkowo możliwe będzie przedstawienie JPK w formie kilku plików dla
każdej ze struktur."

Czyli w momencie wystawienia "ręcznie" (np. w exelu) korekty,
potraktowałbym wystawianie takich korekt jako "fakturowanie z systemu
pomocniczego" i utworzyłbym osobny plik jpk jako dla osobnej struktury
dokumentów.
W Twoim przypadku miałbyś w tym pliku tylko tę korektę i pozbywasz się
konieczności "grzebania" w jpk wygenerowanych z Twojego programu głównego.

I jak najszybciej zmieniłbym oprogramowanie. Bo co z tego, że wyrzeźbisz
korekty jpk ręcznie, jak i tak to się będzie ciągnęło w systemie, a
sytuacja może się powtórzyć.

Ale to ja bym tak zrobił. Dla mnie to by było tańsze. Po prostu.
Bo taka rada może być g... warta dla kogoś, kto ma kilkanaście faktur
miesięcznie i ręczna zabawa z plikami jpk to 5 minut roboty, a taka
zabawa zdarza mu się raz na kilka lat.

> Wystawiając sposobem: do nieistniejącego dokumentu, za pomocą "zwykłej"
> korekty wartościowej (na 0.00zł).
> To księgując automatem powinienem po prostu przy tym dokumencie nie
> zgodzić się na zaksięgowanie do rej.vat?

Po pierwsze o szczegóły techniczne Subiekta powinieneś raczej pytać
producenta, albo na ich forum.

Po drugie, księgowanie kojarzy mi się bardziej z dekretacją dokumentu w
księgach rachunkowych, niż ewidencjonowaniem dokumentu w jakimś
rejestrze. Ale rozumiem co masz na myśli.

> (bo jpk_vat idzie z rejestrów vat - czyli nie ma problemu jakiegoś
> dodania zapisu do pliku)
> Jak wystawiam zwyczajnie korektę wartościową ,bardzo wydumany
> przypadek ale bywają ciężkie przypadki, dajmy zmieniam klientowi rabat
> (bo ma pretensje że za mały dostał) i cenę i wraz wychodzi wartość
> korekty 0.00zł

Czyli dajesz mu większy rabat i równocześnie podnosisz cenę?
Dobre ;)

> To powinno się taką korektę wartościową na 0.00zł rejestrować w rej. vat
> sprzedaży czy zignorować/pominąć bo nie wpływa na wysokość VAT? (czyli
> też nie wykazywać w jpk_vat z wartością 0.00)

jpk_vat należy wysyłać również wtedy, gdy deklaracja VAT jest zerowa.
Czyli zakładając hipotetycznie, że w danym miesiącu masz same takie
korekty zerowe, to i deklaracja wyjdzie zerowa.
Wnioskuję z tego, że takie korekty "zerowe" powinny być ujęte.
_Moim zdaniem_ :)
To forum dyskusyjne, a nie poradnia ;)

> Pytam o to nie do końca hipotetycznie. Wystaw (w dgcs) FV, potem do niej
> korektę niczego nie zmieniając (po prostu od razu zatwierdź).
>
> Program automatycznie doda dokumenty (vat) do rejestrów vat (od
> razu je przypisuje), nie mam wpływu na to czy faktura,korekta vat
> wejdzie do rejestru czy nie.

Jaki jest sens wystawania korekty, która nic nie zmienia?
Może autorzy programu nie przewidzieli tego, że użytkownik wpadnie na
taki dziwny pomysł? :)


>> A że przy okazji, ze względu na brak takiej funkcjonalności, nie da
>> się obejść problemu z korektą nabywcy...
>> ... to pozostaje aktualne stwierdzenie, że US ma to gdzieś, że się
>> nie da :)
>>
>> Ja bym naciskał na producenta programu żeby jasno się zadeklarował
>> czy zamierza coś takiego w programie uwzględnić i kiedy...
>> i przeliczył ile warte jest kopanie się z koniem.
>> Czy koszty pracy pracowników, spędzających ileś tam dni na szukanie
>> rozwiązań i rozwiązywanie takich banalnych problemów, przypadkiem nie
>> przekraczają kosztu zmiany i wdrożenia innego oprogramowania...
>
> Tak, będę naciskał, wysłałem przez 8 miesięcy ze 150 mejli
> "sugestii". :)

Szacun... po 10 emailu zmieniłbym program. Chyba nie mam takiej
cierpliwości jak Ty...

Pozdrawiam
Piotr