Guide till integration med Monitor ERP för produktionsplanering med SkyPlanner APS

Det dokumenterade integrationsgränssnittet i Monitor G5 är Monitor ERP API v1. Det är en hybrid av CQRS och REST med JSON över HTTPS. (Monitor ERP API)

• Queries läser data med GET. De stöder parametrar av OData-typ: $filter, $select, $expand, $orderby, $top och $skip.
• Commands skriver data med POST, till exempel Manufacturing/ManufacturingOrderOperations/Update.
• Batch kör flera kommandon i en enda transaktion via POST /api/v1/Batch. Antingen genomförs allt eller inget. Lägg till /Simulate eller /Validate för att testa en batch och sedan återställa den. Det är det säkra sättet att skriva en hel plan. (Batch)

Bas-URL:en är https://{host}:8001/{languageCode}/{companyNumber}/api/v1/. Företagsnumret består av databasnumret och företagets id, till exempel 004.1.

Om licenser skriver Monitor: ”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.” (Alla kunder får kostnadsfritt läsa och hämta information via API:et. För att använda kommandon och skriva data till ERP-systemet krävs däremot köp av Monitor ERP API.) Ta med skrivlicensen i projektet från dag ett. (api.monitor.se)

API-referensen för Monitor ERP dokumenterar inga webhooks eller händelseprenumerationer. Ändringar fångas upp genom pollning:

• Common/EntityChangeLogs (från 2.33) returnerar ChangeType (Update, Create, Delete), EntityTypeId, EntityId och ModifiedTimestamp. Polla med några minuters mellanrum och hämta bara de poster som har ändrats. (EntityChangeLog)
• Filtrera frågor om tillverkningsorder till öppna order och använd $top och $skip för sidindelning.

SkyPlanner skickar webhooks när status eller planen ändras, så återföringen är händelsestyrd.

1. Första inläsning av grunddata. Läs in produktionsgrupper, operationsrader, alternativa operationsrader, materialrader, artiklar och scheman. Mappa varje produktionsgrupp till en produktionsgrupp i SkyPlanner med omsorg. En produktionsgrupp av typen Pool blir en gruppering av produktionsgrupper. De ingående produktionsgrupperna blir de resurser som planeringsmotorn väljer mellan.

2. Ordersynkronisering. Läs in öppna tillverkningsorder med noder, operationer och material, samt lagersaldon och öppna inköpsorder. SkyPlanner räknar beställt material som tillgängligt på inköpsorderns leveransdatum och uppdaterar lagersaldot när inköpsordern markeras som Delivered. Efter den första inläsningen styr Common/EntityChangeLogs vilka ändringar som hämtas.

3. Återföring av planen. För varje operation som planeringsmotorn har lagt in eller flyttat skickar SkyPlanner ManufacturingOrderOperations/Update med PlannedStartDate och PlannedFinishDate. Om motorn har flyttat en operation till en annan maskin i en pool körs SetWorkCenter först. Kommandona för en order samlas i en Batch, så att Monitor godkänner antingen alla eller inga av dem. Kör batchen via /Validate under testningen.

I Monitor-versioner före 24.5 går det inte att skriva planerade datum via Update. Använd i stället ManufacturingOrders/ReplanOperation (från 2.40) med StartDate och FinishDate, och ställ in RestrictToOrderBounds enligt era regler.

4. Återrapportering från produktionen. Använd en enda rapporteringskanal:

• Monitor förblir rapporteringskanal. Operatörerna rapporterar i Recording terminal eller via maskinintegration som i dag. SkyPlanner läser ManufacturingOrderOperationReportings för att följa utfallet och planerar om.
• SkyPlanner blir rapporteringskanal. Operatörerna registrerar arbetet med Mobile Confirmations eller Production Timer, och SkyPlanner skickar ReportManufacturingOrderOperation till Monitor.

Rapportering från båda systemen leder till dubbelregistrering av tid och antal.

5. Dataägarskap och konfliktregler. Dokumentera dem före driftstart:

Den främsta orsaken till konflikter är att planerare fortsätter att ändra i prioriteringsplanen. Rescheduling according to New finish och förflyttning av rader i Priority planning skriver över de datum som SkyPlanner har skrivit. När SkyPlanner styr operationsföljden används Priority planning enbart som vy. Med Autopilot planerar SkyPlanner om automatiskt när produktionen förändras.

• Tillgänglighetsfaktor. Monitor räknar om bruttokapacitet till nettokapacitet med tillgänglighetsfaktorn, som är 80 % som standard för en ny produktionsgrupp. Tillämpa den en gång, antingen som effektivitet i SkyPlanner eller som kortare skift, aldrig båda.
• Tidsnoggrannhet. För produktionsgrupper som använder Day planning anges kapaciteten som grundtid per dag, utan skifttider. Mappa de faktiska skiften från produktionsschemana till SkyPlanner så att jobben planeras inom arbetstiden.
• Kötid och överlappning. Operationsrader innehåller kötid och överlappning i %. Bestäm under kartläggningen hur dessa ska mappas till SkyPlanner, annars förändras ledtiderna efter driftsättningen.
• Pooler. Produktionsgrupper i pooler planeras i Pool planning, inte i Priority planning. Läs in de ingående produktionsgrupperna, inte bara poolraden.
• Versionskrav. Planerade datum via Update kräver 24.5. Kapacitetsfälten för produktionsgrupper i API:et kräver 24.3, och OIDC kräver 25.8. Kontrollera versionsbygget före kartläggningen.
• Nätverk och certifikat. En lokalt installerad Monitor tillhandahåller API:et på port 8001 med ett självsignerat certifikat. SkyPlanner körs i molnet, så planera för en brandväggsregel eller en reläserver och ange uttryckligen att certifikatet är betrott.
• Licenser. Varje tredjepartsapplikation som skriver data behöver egna användare med API-licens. En API-användare med enbart läsbehörighet ingår i varje system.