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.