JPK_KR_PD to nowa struktura obejmująca dane z ksiąg rachunkowych w zakresie podatku dochodowego (JPK CIT). Program potrafi wygenerować plik technicznie, ale wymaga poprawności danych źródłowych.

Wartość „BRAK” pojawia się w pliku XML wtedy, gdy opisy poszczególnych pozycji zapisów księgowych nie zostały uzupełnione w systemie Comarch ERP Optima.

Nie. Mechanizm został zaprojektowany tak, aby uzupełniać wyłącznie puste pola i całkowicie chronić opisy, które zostały już wcześniej wprowadzone przez użytkownika.

W pierwszej kolejności system może wykorzystać opis kategorii z nagłówka zapisu, a w razie jego braku – sięgnąć po numer dokumentu źródłowego.

Usprawnienie nie zastępuje oceny merytorycznej księgowego, lecz pomaga w szybki sposób usunąć powtarzalny problem techniczno-organizacyjny w postaci pustych opisów pozycji.

Obowiązek dotyczy podatników CIT – w pierwszej kolejności największych podmiotów o przychodach powyżej 50 mln euro oraz podatkowych grup kapitałowych, a kolejno następnych grup.

Tak, rozwiązanie doskonale sprawdza się w biurach rachunkowych obsługujących wiele spółek, gdzie ręczna weryfikacja tysięcy dekretów zajmowałaby zbyt dużo czasu.

Warto sprawdzić wersję programu, znaczniki kont (m.in. S_12_1, S_12_2), dane dodatkowe dokumentów oraz wygenerować testowy plik JPK_KR_PD w celu wykrycia ewentualnych braków.

Wystarczy skontaktować się z nami przez formularz. Sprawdzimy zakres danych w Twojej bazie Optimy i pokażemy, jak działa nasze usprawnienie.

Tak, usprawnienie instalowane jest na poziomie Comarch ERP Optima, a nie pojedynczej bazy. Oznacza to, że działa na wszystkich bazach podpiętych pod daną instalację programu.

Tak, jako osobne rozszerzenie usługi możemy pomóc dostosować lub utworzyć schematy księgowe tak, aby opisy pozycji powstawały automatycznie podczas bieżącego księgowania. To uzupełnienie podstawowego wdrożenia, wyceniane indywidualnie.

Opisane rozwiązanie jest przygotowane dla Comarch ERP XL. Inne środowiska wymagają osobnej analizy.

Klasy atrybutów zamieniane na atrybuty, grupy towarowe jako rodziny Family oraz produkty wraz z ilościami i cenami.

Mapowanie odbywa się na podstawie nazwy atrybutu, dzięki czemu nie trzeba wiązać pól ręcznie.

To rodzina produktów w Akeneo. Powstaje na podstawie grup towarowych z Comarch ERP XL.

Parametry uzupełnione w Akeneo oraz zdjęcia produktów. Dokładny zakres pól ustalamy przy wdrożeniu.

Tak. Dane o ilościach i cenach są przekazywane razem z produktami do katalogu PIM.

Tak. Aktualizacja przebiega cyklicznie, w powtarzalnej kolejności kroków, bez ręcznego uruchamiania.

Zakres i kierunki wymiany ustala się podczas wdrożenia; dokumentacja nie przesądza o niezależnym włączaniu obu kierunków.

Dokumentacja nie wskazuje jednego źródła prawdy. Podział odpowiedzialności między ERP XL i Akeneo ustala się na etapie analizy.

Tak. Synchronizator rozwijamy pod potrzeby klienta, dodając kolejne obszary danych po analizie.

Dostęp do środowiska Comarch ERP XL, dostęp do instancji Akeneo PIM oraz ustalone mapowanie danych.

Od zakresu pól, kierunków wymiany, obsługi zdjęć i liczby testów. Wycenę przygotowujemy po analizie procesu.

Tak. Import dostępności od dostawców i silnik przesunięć MM oraz zamówień ZD mogą zostać uruchomione niezależnie.

Po kodzie EAN. Dopasowanie odbywa się między pozycją w pliku CSV a kartą towaru w Comarch ERP Optima.

W atrybutach towaru Dostepnosc oraz StatusH. Nazwy atrybutów potwierdzamy na etapie konfiguracji.

Atrybuty dostępności są usuwane, aby w systemie nie pozostała nieaktualna informacja.

Progi są zapisane w atrybutach i ustawiane osobno dla każdego magazynu.

Najpierw sprawdzany jest magazyn centralny i tworzone przesunięcie MM. Dopiero brakująca część trafia do zamówienia u dostawcy.

Oznacza towar, dla którego przesunięcie MM ma zostać pominięte. Zapotrzebowanie idzie wtedy bezpośrednio do zamówienia u dostawcy.

Nie. Ilość jest ograniczana do dostępności zgłoszonej przez dostawcę.

Przed utworzeniem dokumentu sprawdzane są istniejące zamówienia ZD dla danego towaru.

Dla każdego magazynu tworzony jest osobny plik zawierający kod towaru oraz ilość.

Cyklicznie, według harmonogramu ustalonego przy wdrożeniu i dopasowanego do rytmu zamówień.

Tak. Zakres reguł i obsługiwanych plików rozwijamy zgodnie z potrzebami klienta, po analizie procesu.

Tak. Komunikacja z Comarch ERP Optima odbywa się przez ELTE-S Web API Optima.

Tak. Kanały wskazujemy w konfiguracji jako listę ChannelId rozdzieloną przecinkami.

Przez REST API TradeByte, na dedykowanym użytkowniku TB.ONE przeznaczonym wyłącznie do komunikacji API.

Program pobiera pełny plik XML z zamówieniami, a następnie przetwarza pojedyncze zamówienia po ich identyfikatorach.

Tak. Dostępne są dwa warianty: numeracja własna z dedykowaną serią dokumentów oraz numeracja pobierana z plików platformy.

W wariancie z numeracją własną powstaje faktura PDF wysyłana na FTP. W wariancie z numeracją platformy PDF nie jest generowany.

Dokumenty sprzedaży są importowane na podstawie plików Excel, wpisów kanałów i wskazanej ścieżki, z danymi podatkowymi właściwymi dla rynku.

Tak, dla wariantu GALAXUS z numeracją własną. Dokument jest generowany z przygotowanego szablonu i przekazywany na serwer FTP.

Różnicowo, po kodzie EAN i w skonfigurowanym interwale. Wysyłane są tylko pozycje, których dostępność się zmieniła.

Standardem jest aplikacja konsolowa. Wersja z interfejsem okienkowym jest rozszerzeniem wycenianym dodatkowo.

Tak. Zakres można rozszerzać o kolejne funkcje udostępniane przez REST API TradeByte, po analizie technicznej.

Od liczby kanałów, wariantów numeracji, obsługi PDF i FTP oraz zakresu testów. Wycenę przygotowujemy po analizie procesu.