Anveo EDI Connect / Config / Mappings / Modelowanie Mapowanie Przepływy pracy
Jest to tłumaczenie automatyczne. Pierwotne stanowisko jest dostępne w angielski.

Modelowanie Mapowanie Przepływy pracy

W Anveo EDI Connect do modelowania procesu EDI używa się zazwyczaj wielu mapowań. Poniżej przyjrzymy się bardzo prostym przykładom i kolejnym, bardziej złożonym. Moduł jest bardzo elastyczny i można mapować proces tak, jak chcesz, ale poniższe przykłady są naszym zalecanym sposobem modelowania procesu.

Zanim przejdziemy do zbyt wielu szczegółów, wyjaśnijmy kilka pojęć. Mapowanie w Anveo EDI Connect może zostać wykonane. Następnie pojawia się koncepcja transakcji z bazą danych. Mówiąc prościej, transakcja z bazą danych gromadzi wszystkie zmiany w bazie danych podczas transakcji. Po zakończeniu transakcji dane mogą być przechowywane na stałe, co nazywane jest zobowiązaniem bazy danych. Albo zmiany mogą być zresetowane, to znaczy wszystkie zmiany dokonane podczas transakcji są cofnięte i nie są zapisywane. Każde wykonanie mapowania odbywa się w osobnej transakcji w bazie danych. Jeśli podczas wykonywania mapowania wystąpi błąd, transakcja zostanie wycofana. W przeciwnym razie transakcja zostanie zawarta. (To jest prawdziwe dla większości mappingów. W Anveo EDI Connect dostępne są trigery tabelaryczne, które mogą uruchamiać dowolny kod. Jeśli kod ten zawiera polecenie COMMIT, moduł nie może wycofać zmian. Może to prowadzić do niepożądanych zachowań).

Przychodzące zlecenie sprzedaży XML

W tym przykładzie używamy trzech mapowań, aby zaimportować plik XML. To jest zalecane minimum. W pierwszym kroku zmapujemy zewnętrzną strukturę danych do tabel buforowych. Chodzi o to, aby importować dane, nawet jeśli nie wszystkie dane mogą być przetwarzane. Umożliwi to użytkownikowi końcowemu skorygowanie błędów w transakcji EDI, bez wiedzy na temat zewnętrznego formatu danych. Oczywiście jest to możliwe tylko wtedy, gdy występują błędy danych, a nie wtedy, gdy nie można przetworzyć struktury plików.

Następnym krokiem jest sprawdzenie danych. Tutaj można dodać dowolne logiczne sprawdzenia danych biznesowych. Zalecamy zrobić to w oddzielnym kroku przed przetwarzaniem, aby zebrać wiele komunikatów o błędach i dać użytkownikowi końcowemu kompletny protokół błędu. Jeśli potrzebujesz wyszukać dane z tabeli systemowej i chcesz je zachować, zrobimy to w czwartym kroku pomiędzy mapowaniem zewnętrznym i sprawdzającym.

Ostatnim krokiem jest stworzenie dokumentu Microsoft Dynamics NAV 2017. Robimy to w oddzielnym kroku, aby zamki na stołach systemowych były możliwie jak najkrótsze.

Faktura wychodząca EDIFACT

W dokumentach wychodzących, zazwyczaj są pewne wartości, które nie są bezpośrednio przechowywane w tabeli źródeł Microsoft Dynamics NAV 2017. Aby dać użytkownikowi końcowemu możliwość zobaczenia tych danych i uproszczenia mapowania w zewnętrznym formacie danych, zalecamy najpierw zapisać dane do tabeli bufora. W tym kroku można wyszukać wartości i wykonać obliczenia.

Mapowanie eksportu tylko pobiera zbuforowane dane i zapisuje je w docelowym formacie.

Proces EDI z potwierdzeniem

Proces ten nie musi być liniowy. Jeśli potrzebujesz wysłać potwierdzenia lub chcesz pogrupować dane, zawsze możesz wywołać wiele mapowań z jednego mapowania. Można również wykorzystać warunki i warunkowe rozgałęzienia, aby wykonać różne mapowania na podstawie danych.

Jak skonfigurować przepływ pracy

Do szczegółów przejdziemy później. Jeśli chcesz skakać do przodu, używamy dwóch technik, aby uporządkować przepływ pracy związany z mapowaniem. Transakcje biznesowe i post-processing.

Powiadomienie o plikach cookie WordPress od Real Cookie Banner