Przewodnik po integracji Monitor ERP ze SkyPlanner APS na potrzeby harmonogramowania produkcji

Udokumentowanym interfejsem integracyjnym Monitor G5 jest Monitor ERP API v1. Łączy on CQRS i REST, przesyłając dane JSON przez HTTPS. (Monitor ERP API)

• Zapytania odczytują dane metodą GET. Obsługują opcje w stylu OData: $filter, $select, $expand, $orderby, $top i $skip.
• Komendy zapisują dane metodą POST, na przykład Manufacturing/ManufacturingOrderOperations/Update.
• Batch wykonuje kilka komend w jednej transakcji na zasadzie „wszystko albo nic” przez POST /api/v1/Batch. Dodaj /Simulate lub /Validate, aby przetestować pakiet komend i wycofać zmiany. To bezpieczny sposób zapisu całego harmonogramu. (Batch)

Bazowy adres URL to https://{host}:8001/{languageCode}/{companyNumber}/api/v1/. Numer firmy łączy numer bazy danych i identyfikator firmy, na przykład 004.1.

W kwestii licencji Monitor podaje: „It is free to query and extract information from the API for all our customers. However, in order to use commands and write data to the ERP system, you need to purchase Monitor ERP API.” (Wszyscy nasi klienci mogą bezpłatnie wysyłać zapytania i pobierać informacje z API. Aby jednak korzystać z komend i zapisywać dane w systemie ERP, trzeba kupić Monitor ERP API.) Uwzględnij licencję na zapis danych w projekcie od samego początku. (api.monitor.se)

Dokumentacja Monitor ERP API nie opisuje webhooków ani subskrypcji zdarzeń. Zmiany są wykrywane przez cykliczne odpytywanie:

• Common/EntityChangeLogs (od wersji 2.33) zwraca ChangeType (Update, Create, Delete), EntityTypeId, EntityId i ModifiedTimestamp. Odpytuj ten endpoint co kilka minut i pobieraj tylko zmienione rekordy. (EntityChangeLog)
• Ogranicz zapytania o zlecenia produkcyjne do otwartych zleceń i stosuj stronicowanie za pomocą $top i $skip.

SkyPlanner wysyła webhooki przy zmianie stanu lub harmonogramu, więc zapis zwrotny jest sterowany zdarzeniami.

1. Początkowy import danych podstawowych. Odczytaj gniazda produkcyjne, wiersze operacji, wiersze operacji alternatywnych, wiersze materiałowe, pozycje kartoteki i harmonogramy. Starannie przyporządkuj każde gniazdo produkcyjne do stanowiska roboczego w SkyPlanner. Gniazdo typu Pool staje się grupą stanowisk roboczych, a należące do niego gniazda — stanowiskami roboczymi, spośród których wybiera silnik.

2. Synchronizacja zleceń. Odczytaj otwarte zlecenia produkcyjne wraz z ich węzłami, operacjami i materiałami, a także stany magazynowe i otwarte zamówienia zakupu. SkyPlanner traktuje zamówiony materiał jako dostępny w terminie dostawy z zamówienia zakupu i aktualizuje stan magazynowy, gdy zamówienie otrzyma status Delivered. Po pierwszym imporcie aktualizacje przyrostowe opierają się na Common/EntityChangeLogs.

3. Zapis zwrotny harmonogramu. Dla każdej operacji, którą silnik umieścił w harmonogramie lub przesunął, SkyPlanner wysyła ManufacturingOrderOperations/Update z PlannedStartDate i PlannedFinishDate. Jeśli silnik przeniósł operację na inną maszynę w puli, najpierw wykonywane jest SetWorkCenter. Komendy dla jednego zlecenia trafiają do jednego Batch, dzięki czemu Monitor przyjmuje wszystkie albo żadnej. Podczas testów uruchamiaj pakiet komend przez /Validate.

W wersjach Monitor wcześniejszych niż 24.5 nie można zapisywać planowanych dat przez Update. Zamiast tego użyj ManufacturingOrders/ReplanOperation (od wersji 2.40) z StartDate i FinishDate, a RestrictToOrderBounds ustaw zgodnie ze swoimi regułami.

4. Potwierdzenia z hali produkcyjnej. Korzystaj z jednego kanału raportowania:

• Monitor pozostaje kanałem raportowania. Operatorzy raportują w Recording terminal lub przez integrację z maszynami, tak jak dotychczas. SkyPlanner odczytuje ManufacturingOrderOperationReportings jako dane o postępie prac i ponownie układa harmonogram.
• SkyPlanner staje się kanałem raportowania. Operatorzy rejestrują pracę za pomocą Mobile Confirmations lub Production Timer, a SkyPlanner wysyła ReportManufacturingOrderOperation do Monitor.

Raportowanie z obu systemów powoduje podwójne naliczanie czasu i ilości.

5. Odpowiedzialność za dane i reguły rozstrzygania konfliktów. Spisz je przed uruchomieniem produkcyjnym:

Głównym źródłem konfliktów jest dalsze wprowadzanie przez planistów zmian w planie priorytetów. Rescheduling according to New finish i przeciąganie wierszy w Priority planning nadpisują terminy zapisane przez SkyPlanner. Gdy za kolejność odpowiada SkyPlanner, Priority planning służy już tylko do podglądu. Dzięki Autopilot SkyPlanner automatycznie aktualizuje harmonogram, gdy w produkcji zachodzą zmiany.

• Współczynnik dostępności. Monitor przelicza zdolność produkcyjną brutto na netto za pomocą współczynnika dostępności. Dla nowego gniazda produkcyjnego wynosi on domyślnie 80 %. Uwzględnij go tylko raz: jako wydajność w SkyPlanner albo jako krótsze zmiany robocze, nigdy na oba sposoby jednocześnie.
• Dokładność czasu. Gniazda produkcyjne korzystające z Day planning mają zdolność produkcyjną określoną jako podstawowy czas dzienny, bez godzin zmian roboczych. Odwzoruj rzeczywiste zmiany w SkyPlanner na podstawie harmonogramów produkcji, aby zadania były planowane w godzinach pracy.
• Czas oczekiwania i nakładanie się operacji. Wiersze operacji zawierają czas oczekiwania i stopień nakładania się operacji w %. Podczas określania zakresu ustal, jak odwzorować każdy z tych parametrów w SkyPlanner. W przeciwnym razie po uruchomieniu zmienią się czasy realizacji.
• Pule. Gniazda produkcyjne należące do puli są planowane w Pool planning, a nie w Priority planning. Odczytuj gniazda wchodzące w skład puli, nie tylko jej wiersz.
• Wymagania dotyczące wersji. Zapis planowanych terminów przez Update wymaga wersji 24.5. Pola zdolności produkcyjnej gniazd w API wymagają wersji 24.3, a OIDC — 25.8. Sprawdź kompilację przed określeniem zakresu.
• Sieć i certyfikat. Monitor zainstalowany lokalnie udostępnia API na porcie 8001 z certyfikatem z podpisem własnym. SkyPlanner działa w chmurze, dlatego zaplanuj regułę zapory lub serwer pośredniczący i jawnie oznacz certyfikat jako zaufany.
• Licencje. Każda aplikacja zewnętrzna zapisująca dane potrzebuje własnych użytkowników z licencją API. Każdy system jest dostarczany z jednym użytkownikiem API z dostępem tylko do odczytu.