Zapewne większość z Was generuje pliki JPK MAG z ruchami magazynowymi z SAP. Nasz podział organizacyjny jest prosty - jedna spółka, jeden NIP, jedna jednostka gospodarcza - i w modułach logistycznych podział dalszy struktury organizacyjnej - Zakład A, Zakład B. Oba zakłady oddalone o kilkadziesiąt km od siebie w Polsce. Oba zakłady mają w SAP założone po jednym magazynie, każdy magazyn podzielony na dalsze jednostki - obszar magazynu, typ, czy automatyczny czy paletowy itd. Jeśli chodzi o SAP to oba magazyny są zdecentralizowane w SAP, ale oczywiście mamy tez składy w obu zakładach nie sterowanych magazynem zewnętrznym - np. do wysyłek między zakładami czy kontrola jakości.
No i w takiej sytuacji generujemy dwa pliki JPK MAG ze wszystkimi ruchami magazynowymi - przyjęcia, wydania, przesunięcia itd. W pliku XML są dane podmiotu - w obu plikach takie same dane organizacyjne jak NIP Adres itd, natomiast w tagu "Magazyn" umieszczamy po prostu opis typu "A" i "B".
Problem i pytanie pojawia się taki, że mamy trochę artykułów trzymanych fizycznie w zakładzie "A", natomiast w SAP ruch magazynowy jest na przyjęciu w zakładzie "B". Jest to decyzja typowo biznesowa - mała część całości po prostu na bieżąco jest podejmowana taka decyzja - zależnie od potrzeb - dostępne miejsce magazynowe, albo na przykład zamawia jeden zakład ale dostawa jest fizycznie do drugiego bo tam np. jest rampa do przyjęcia. Więc jest mała rozbieżność jeśli chodzi o fizyczne umiejscowienie materiałów w Zakładzie/Magazynie A i B.
Pod kątem prawnym sprawa pewnie nie jest jednoznaczna, skoro w ustawie o JPK nie ma nawet definicji JPK i jest bardzo dużo niewiadomych.
Pytanie jest takie, czy my teraz mamy zmienić nasze procedury biznesowe i wprowadzić zakaz fizycznego przyjmowania czegokolwiek jeśli w SAP przyjęcie jest na drugi zakład? Naprawdę pod kątem JPK musimy teraz przeksięgowywać wszystkie materiały fizycznie znajdujące się w jednym zakładzie na drugi, tylko dlatego że JPK tego wymaga?
Moim zdaniem to mocna nadinterpretacja i US potrzebuje JPK MAG, aby sprawdzić czy my np. sprzedając towar do klientów mamy na to "kwity" w postaci ruchów wydania z magazynu (w obrębie jednostki gospodarczej), czyli że nie sprzedajemy np. lewego paliwa czy takie historie, albo że jak mamy faktury zakupowe to w naszych zakładach są odpowiednie ruchy magazynowe na przyjęciu. Z ceną, opisem materiału itd.
Dzięki za opinie, jak to u Was jest?
pozdrawiam
JPK MAG - podział na magazyny
-
- Posty: 8355
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: JPK MAG - podział na magazyny
Moim zdaniem sytuację z przyjęciami do zakładów należałoby uporządkować i to wcale nie ze względu na JPK, tylko na jakość zarządzania zapasami.
Jeśli przyjmujesz coś do zakładu A to przecież wcześniej to przyjęcie zostało zaplanowane np. w formie zamówienia zaopatrzeniowego. Zostało zaplanowane nie dlatego, że taka była "decyzja biznesowa", tylko dlatego że w zakładzie A są zapotrzebowania, które to przyjęcie ma obsłużyć. Kiedy przyjęcie zaplanowane do zakładu A przyjmiesz fizycznie w zakładzie B, to systemowo niby wszystko się zgadza, ale faktycznie z zakładzie A zacznie brakować zapasu do obsługi zapotrzebowań, a w zakładzie B tego zapasu będzie zbyt dużo. Musisz zatem w jakiś sposób (najpewniej w Excelu) tymi zapasami zarządzać, nie widzisz ich poprawnie w SAP.
Uważam, że w SAP ERP należy odzwierciedlać rzeczywistość - jeśli faktycznie przyjęcie zostało zrobione do zakładu B to tak ta operacja powinna zostać zaksięgowana w systemie.
Naturalnie jeszcze lepiej byłoby trzymać się planu - skoro zaplanowaliśmy przyjęcie do zakładu A to przyjmujmy do tego zakładu.
Jeśli uporządkujesz rejestrowanie przyjęć to uzyskać w SAP ERP rzetelną informację o zapasach, a temat JPK MAG się rozwiąże niejako przy okazji.
Jeśli przyjmujesz coś do zakładu A to przecież wcześniej to przyjęcie zostało zaplanowane np. w formie zamówienia zaopatrzeniowego. Zostało zaplanowane nie dlatego, że taka była "decyzja biznesowa", tylko dlatego że w zakładzie A są zapotrzebowania, które to przyjęcie ma obsłużyć. Kiedy przyjęcie zaplanowane do zakładu A przyjmiesz fizycznie w zakładzie B, to systemowo niby wszystko się zgadza, ale faktycznie z zakładzie A zacznie brakować zapasu do obsługi zapotrzebowań, a w zakładzie B tego zapasu będzie zbyt dużo. Musisz zatem w jakiś sposób (najpewniej w Excelu) tymi zapasami zarządzać, nie widzisz ich poprawnie w SAP.
Uważam, że w SAP ERP należy odzwierciedlać rzeczywistość - jeśli faktycznie przyjęcie zostało zrobione do zakładu B to tak ta operacja powinna zostać zaksięgowana w systemie.
Naturalnie jeszcze lepiej byłoby trzymać się planu - skoro zaplanowaliśmy przyjęcie do zakładu A to przyjmujmy do tego zakładu.
Jeśli uporządkujesz rejestrowanie przyjęć to uzyskać w SAP ERP rzetelną informację o zapasach, a temat JPK MAG się rozwiąże niejako przy okazji.
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: JPK MAG - podział na magazyny
Pełna zgoda ale rzeczywistość nie zawsze może być idealna. Chociażby argument że stany magazynowe muszą być dostępne, a planowanie zapotrzebowań pod zlecenia produkcyjne ma w pierwszej kolejności pobierać z lokalnego zakładu a gdyby zechcieć zrobić idealną sytuację to trzeba by robić zamówienia międzyzakładowe a to wszystko trwa.
Reasumując - wszędzie są argumenty typu "powinno być", "idealnie by było", itp., natomiast w prawie (ustawa o JPK, ustawa o rachunkowości) nic na ten temat konkretnie nie mówi?
Reasumując - wszędzie są argumenty typu "powinno być", "idealnie by było", itp., natomiast w prawie (ustawa o JPK, ustawa o rachunkowości) nic na ten temat konkretnie nie mówi?
-
- Posty: 8355
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: JPK MAG - podział na magazyny
Nie jestem prawnikiem, więc wszystkie dalsze uwagi proszę traktuj luźno.
Moim zdaniem prawo jest z rozmysłem pisane tak, aby nic nie było jasne i konkretne. Inaczej prawnicy nie byliby potrzebni i nie mieli z czego żyć. Dlatego najpewniej ani w ustawie o JPK, ani w ustawie o rachunkowości nie znajdziesz konkretnego zapisu odnoszącego się do Twojej sytuacji. Natomiast sądzę, że z ustawy o rachunkowości da się wywieźć obowiązek rzetelnego rejestrowania zdarzeń gospodarczych. W Twoim przypadku ta rzetelność jest dyskusyjna - masz zapas w jednym zakładzie (jednostce organizacyjnej) a rejestrujesz jego przyjęcie w innym zakładzie. Naturalnie stwierdzenie czy Twoja praktyka rejestrowania przyjęć jest rzetelna czy nie, okaże się na rozprawie i zdecyduje lepiej opłacony prawnik.
Moim zdaniem prawo jest z rozmysłem pisane tak, aby nic nie było jasne i konkretne. Inaczej prawnicy nie byliby potrzebni i nie mieli z czego żyć. Dlatego najpewniej ani w ustawie o JPK, ani w ustawie o rachunkowości nie znajdziesz konkretnego zapisu odnoszącego się do Twojej sytuacji. Natomiast sądzę, że z ustawy o rachunkowości da się wywieźć obowiązek rzetelnego rejestrowania zdarzeń gospodarczych. W Twoim przypadku ta rzetelność jest dyskusyjna - masz zapas w jednym zakładzie (jednostce organizacyjnej) a rejestrujesz jego przyjęcie w innym zakładzie. Naturalnie stwierdzenie czy Twoja praktyka rejestrowania przyjęć jest rzetelna czy nie, okaże się na rozprawie i zdecyduje lepiej opłacony prawnik.
-
- Posty: 8355
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: JPK MAG - podział na magazyny
Przyznam, że nie trafia do mnie ten argument. Przecież nawet jeśli systemowo stany są dostępne to faktycznie dostępne nie są, bo są innym zakładzie oddalonym o kilkadziesiąt km. Ten zapas trzeba przetransportować jeśli jest potrzebny do produkcji w zakładzie, w którym systemowo zostało zarejestrowane przyjęcie. SAP ERP ma pomagać w zarządzaniu firmą, m.in. w planowaniu dostaw i przesunięć międzyzakładowych. Dobrze wdrożony SAP tak działa - dokumenty są generowane automatycznie, można je przetwarzać masowo. Jeśli wprowadzanie dokumentów np. przesunięć międzyzakładowych ma być sztuką dla sztuki to faktycznie nie ma sensu tego robić. Z drugiej strony, ile trwa wprowadzenie w MIGO przeksięgowania między zakładami?wojtas7 pisze: ↑czw cze 06, 2019 1:05 pm Pełna zgoda ale rzeczywistość nie zawsze może być idealna. Chociażby argument że stany magazynowe muszą być dostępne, a planowanie zapotrzebowań pod zlecenia produkcyjne ma w pierwszej kolejności pobierać z lokalnego zakładu a gdyby zechcieć zrobić idealną sytuację to trzeba by robić zamówienia międzyzakładowe a to wszystko trwa.
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: JPK MAG - podział na magazyny
Żeby przesunąć między zakładami artykuły jest potrzebny cały szereg operacji, to nie jest odpalenie MIGO i wypełnienie pięciu pól. W obu zakładach jest zdecentralizowany system magazynowy (różnych producentów), oba pracują z jednym ERPem. Trzeba księgować zamówienie, do zamówienia programem zetowym skanować opakowania, który robi dostawę wychodzącą na specjalny skład, następnie trzeba zbudować transport w SAP TM, mamy do tego aplikacje skanerowe RFUI na ERP do budowy palet, wszystko działa na handling unitach - nie jest to trywialne. A transport fizycznie materiałów między zakładami to jest kilka godzin czasu i po problemie. Także to nie jest tak że system SAP został źle wdrożony, po prostu korporacja nie przewidziała tego typu sytuacji/procesu (w pozostałych XXX krajach nie mają takich potrzeb - ten sam ERP), że konfiguracja dyspozycji materiałów jest tak wprost powiedziana że jest jeden skład dostępny do produkcji/na sprzedaż. Pewnie w tą stronę by trzeba system analizować - dyspozycja skąd mają być brane artykuły do zapotrzebowań produkcyjnych.
-
- Posty: 406
- Rejestracja: pn kwie 13, 2015 10:17 pm
- Lokalizacja: Poznań
- Has thanked: 35 times
- Been thanked: 229 times
Re: JPK MAG - podział na magazyny
podstawowe zasady jakimi się kierowałem przy pracach nad JPK_MAG dla dużej organizacji z kilkoma magazynami, licznymi zakładami, masowymi procesami intercompany:
1) pozycje raportowane w pliku JPK muszą być zgodne ilościowo i wartościowo w 100% z odpowiednimi dokumentami źródłowymi z ERP.
Uzasadnienie: audytorzy np. przy inwenturach rocznych często proszą wyrywkowo o pokazanie w systemie lub wersji papierowej odpowiednich dokumentów źródłowych (np. dok. PZ) lub chcą zobaczyć z systemu listę ostatnich X ruchów dotyczących przykładowo dok.PZ / WZ. Jeśli to się rozjedzie, trzeba się będzie tłumaczyć Zakładam, że m.in. podobny mechanizm może być zastosowany przy weryfikacji JPM_MAG.
2) w przypadku wątpliwości, czy dana operacja ma być wykazana w pliku JPK, stwierdziliśmy że lepiej zaraportować za dużo niż za mało.
Takie wątpliwości mieliśmy przykładowo w stosunku do operacji związanymi z zapasami specjalnymi podwykonawcy, konsygnacji dostawcy, konsygnacji klienta.
3) ostatnie to nie zasada a spostrzeżenie - najtrudniej zaraportować w odpowiedniej sekcji (PZ, WZ, RW, MM) w JPK niestandardowe procesy / dziwne rozwiązania biznesowe dalekie od tzw. Best Practice
PS. nie pytam jak robicie inwenturę, skoro zapas na magazynie nie jest zgodny z tym co jest w systemie
1) pozycje raportowane w pliku JPK muszą być zgodne ilościowo i wartościowo w 100% z odpowiednimi dokumentami źródłowymi z ERP.
Uzasadnienie: audytorzy np. przy inwenturach rocznych często proszą wyrywkowo o pokazanie w systemie lub wersji papierowej odpowiednich dokumentów źródłowych (np. dok. PZ) lub chcą zobaczyć z systemu listę ostatnich X ruchów dotyczących przykładowo dok.PZ / WZ. Jeśli to się rozjedzie, trzeba się będzie tłumaczyć Zakładam, że m.in. podobny mechanizm może być zastosowany przy weryfikacji JPM_MAG.
2) w przypadku wątpliwości, czy dana operacja ma być wykazana w pliku JPK, stwierdziliśmy że lepiej zaraportować za dużo niż za mało.
Takie wątpliwości mieliśmy przykładowo w stosunku do operacji związanymi z zapasami specjalnymi podwykonawcy, konsygnacji dostawcy, konsygnacji klienta.
3) ostatnie to nie zasada a spostrzeżenie - najtrudniej zaraportować w odpowiedniej sekcji (PZ, WZ, RW, MM) w JPK niestandardowe procesy / dziwne rozwiązania biznesowe dalekie od tzw. Best Practice
PS. nie pytam jak robicie inwenturę, skoro zapas na magazynie nie jest zgodny z tym co jest w systemie