Monitor ERP integration: guide til produktionsplanlægning med SkyPlanner APS

Den dokumenterede integrationsgrænseflade i Monitor G5 er Monitor ERP API v1. Den kombinerer CQRS og REST med JSON over HTTPS. (Monitor ERP API)

• Queries læser data med GET. De understøtter parametre i OData-stil: $filter, $select, $expand, $orderby, $top og $skip.
• Commands skriver data med POST, for eksempel Manufacturing/ManufacturingOrderOperations/Update.
• Batch udfører flere kommandoer i én samlet transaktion via POST /api/v1/Batch: enten gennemføres alle kommandoer eller ingen. Tilføj /Simulate eller /Validate for at teste en batch og rulle den tilbage. Det er den sikre måde at skrive en hel plan på. (Batch)

Basis-URL’en er https://{host}:8001/{languageCode}/{companyNumber}/api/v1/. Virksomhedsnummeret kombinerer databasenummer og virksomheds-id, for eksempel 004.1.

Om licenser siger 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.” (Alle kunder kan gratis forespørge på og hente oplysninger fra API’et. For at bruge kommandoer og skrive data til ERP-systemet skal man dog købe Monitor ERP API.) Indregn licensen til skriveadgang i projektet fra dag ét. (api.monitor.se)

Referencen til Monitor ERP API dokumenterer ingen webhooks eller hændelsesabonnementer. Ændringer hentes via polling:

• Common/EntityChangeLogs (fra 2.33) returnerer ChangeType (Update, Create, Delete), EntityTypeId, EntityId og ModifiedTimestamp. Forespørg med få minutters mellemrum, og hent kun de ændrede poster. (EntityChangeLog)
• Filtrer forespørgsler efter produktionsordrer, så de kun omfatter åbne ordrer, og brug $top og $skip til sideinddeling.

SkyPlanner sender webhooks, når tilstanden eller planen ændres, så tilbageskrivningen er hændelsesstyret.

1. Første indlæsning af stamdata. Læs arbejdscentre, operationsrækker, alternative operationsrækker, materialerækker, varer og arbejdstidsplaner. Tag bevidst stilling til, hvordan hvert arbejdscenter mappes til en arbejdsstation i SkyPlanner. Et arbejdscenter af typen Pool bliver til en arbejdsstationsgruppe, og de tilknyttede arbejdscentre bliver til de arbejdsstationer, som planlægningsmotoren vælger imellem.

2. Ordresynkronisering. Læs åbne produktionsordrer med deres noder, operationer og materialer samt lagerbeholdning og åbne indkøbsordrer. SkyPlanner regner bestilte materialer som tilgængelige på indkøbsordrens leveringsdato og opdaterer lagerbeholdningen, når indkøbsordren markeres som Delivered. Efter første indlæsning bruges Common/EntityChangeLogs til at hente ændringerne.

3. Tilbageskrivning af planen. For hver operation, som planlægningsmotoren har placeret eller flyttet, sender SkyPlanner ManufacturingOrderOperations/Update med PlannedStartDate og PlannedFinishDate. Når motoren har flyttet en operation til en anden maskine i en pulje, sendes SetWorkCenter først. Kommandoerne for én ordre samles i én Batch, så Monitor enten accepterer dem alle eller ingen. Kør batchen via /Validate under testen.

I Monitor-versioner før 24.5 kan de planlagte datoer ikke skrives via Update. Brug i stedet ManufacturingOrders/ReplanOperation (fra 2.40) med StartDate og FinishDate, og indstil RestrictToOrderBounds efter jeres regler.

4. Tilbagemeldinger fra produktionen. Brug kun én kanal til indrapportering:

• Monitor forbliver kanalen. Operatørerne indrapporterer via Recording terminal eller maskinintegration som i dag. SkyPlanner læser ManufacturingOrderOperationReportings for at følge fremdriften og omplanlægger.
• SkyPlanner bliver kanalen. Operatørerne registrerer arbejdet med Mobile Confirmations eller Production Timer, og SkyPlanner sender ReportManufacturingOrderOperation til Monitor.

Indrapportering fra begge systemer giver dobbeltregistrering af tid og mængder.

5. Dataejerskab og konfliktregler. Skriv dem ned før idriftsættelsen:

Konflikter opstår især, når planlæggere fortsætter med at ændre i prioritetsplanen. Omplanlægning efter New finish og flytning af rækker i Priority planning overskriver de datoer, SkyPlanner har skrevet. Når SkyPlanner styrer rækkefølgen, bruges Priority planning kun som visning. Med Autopilot omplanlægger SkyPlanner automatisk, når produktionen ændrer sig.

• Tilgængelighedsfaktor. Monitor omregner bruttokapacitet til nettokapacitet med tilgængelighedsfaktoren, som er 80 % som standard på et nyt arbejdscenter. Anvend den kun én gang: enten som effektivitet i SkyPlanner eller som kortere skift, aldrig begge dele.
• Tidspræcision. Arbejdscentre med Day planning angiver kapacitet som grundtid pr. dag uden skifttider. Overfør de faktiske skift fra produktionskalenderne til SkyPlanner, så opgaverne placeres inden for arbejdstiden.
• Køtid og overlap. Operationsrækker indeholder køtid og overlap i %. Fastlæg under afklaringen, hvordan hver af dem overføres til SkyPlanner. Ellers ændrer gennemløbstiderne sig efter idriftsættelsen.
• Puljer. Arbejdscentre i puljer planlægges i Pool planning, ikke i Priority planning. Læs de arbejdscentre, der indgår i puljen, ikke kun selve puljerækken.
• Versionskrav. Planlagte datoer via Update kræver 24.5. API-felter for arbejdscentrets kapacitet kræver 24.3, og OIDC kræver 25.8. Kontrollér buildnummeret før afklaringen.
• Netværk og certifikat. Ved lokal installation stiller Monitor API’et til rådighed på port 8001 med et selvsigneret certifikat. SkyPlanner kører i skyen, så planlæg en firewallregel eller en relay-løsning, og angiv udtrykkeligt certifikatet som betroet.
• Licenser. Hver tredjepartsapplikation, der skriver data, skal have sine egne brugere med API-licens. Hvert system leveres med én API-bruger, der kun har læseadgang.