Guide til Fulcrum-integration til produktionsplanlægning med SkyPlanner APS

Fulcrum er ét cloudprodukt med multi-tenant-arkitektur, så alle kunder bruger samme API. Udviklerportalen beskriver det som et offentligt API til “REST API calls directly into your Fulcrum site.” (REST API-kald direkte til jeres Fulcrum-miljø).

• Specifikation. OpenAPI “Fulcrum PublicAPI” v1 kan hentes på https://api.fulcrumpro.com/swagger/v1/swagger.json. Fulcrum foreslår at generere en typet klient ud fra den. Siden History viser alle ændringer med dato.
• Værter. https://api.fulcrumpro.com bruges til standardmiljøer. ITAR-miljøer bruger api.fulcrumpro.us, og ITAR-tokens får en 401 på .com-værten.
• Kaldstruktur. Lister hentes med POST .../list med et filter i forespørgslens body, sideinddeling via Skip og Take samt Sort.Field / Sort.Dir. Mange objekter understøtter PUT, og opgaver understøtter også JSON Patch.

En integration til produktionsplanlægning bruger disse endpoints:

Fulcrums egen integrationsside beskriver arbejdet ligefremt: “Every system is a little bit different and requires some configuration.” (Alle systemer er lidt forskellige og kræver en vis konfiguration). Det er netop den konfiguration, SkyPlanner-teamet står for under opstarten.

Fulcrum understøtter webhooks, som konfigureres af en administrator. Siden september 2026 sættes webhooks med fejl på pause og testes igen dagligt i stedet for at blive forsøgt igen i det uendelige. API History nævner hændelser som PurchaseOrderUpdated og ItemUpdated.

Integrationen læser data fra Fulcrum sådan:

• Åbne opgaver hentes med få minutters mellemrum, filtreret på scheduled og inProgress med hasIncompleteOperations: true. Det er det filter, Fulcrum selv angiver for at få samme resultat som på planlægningssiden.
• Indkøbsordrer og lagerbeholdning hentes før hver planlægningskørsel eller ved en PurchaseOrderUpdated-webhook, hvis den er konfigureret.
• Varer, ruter, udstyr og skift hentes ved ændringer eller hver nat.

I den modsatte retning sender SkyPlanners egne webhooks ændringer i planen, så snart de sker. Tilbageskrivningen er derfor hændelsesstyret.

1. Første indlæsning af stamdata. Hent varer, materialer, ruter, arbejdscentre og udstyr, derefter afdelingernes skiftehold og nedetider. Hvert arbejdscenter i Fulcrum bliver til en gruppe af arbejdsstationer i SkyPlanner med det tilhørende udstyr som medlemmer. Det udstyr, der er valgt for hver operation i ruten, bliver til operationens tilladte arbejdsstationer. Udstyr med Unlimited Capacity, f.eks. ovne og malerkabiner, bliver til batchopgaver.

2. Ordresynkronisering. Læs åbne opgaver med tilhørende varer, der skal produceres, og operationer samt åbne indkøbsordrer og lagerbeholdning. SkyPlanner regner bestilt materiale som tilgængeligt på indkøbsordrens leveringsdato og opdaterer lageret, når indkøbsordren markeres som Delivered. Ved hver omplanlægning kontrolleres lagerbeholdningen og de indgående indkøb.

3. Tilbageskrivning af planen. Fulcrum beregner selv scheduledStartUtc, scheduledEndUtc og scheduledEquipmentId og returnerer dem som skrivebeskyttede felter. Ved opdatering af en operation accepteres customFields. SkyPlanner skriver planlagt start, planlagt afslutning og arbejdsstation til brugerdefinerede felter på hver opgaveoperation og den planlagte afslutning til et brugerdefineret felt på opgaven. Salg og indkøb kan se SkyPlanners datoer på opgaven i Fulcrum.

4. Tilbagemeldinger fra produktionsgulvet. Operatørerne registrerer arbejde i SkyPlanner med Mobile Confirmations, Production Timer eller Quick Log Mode. SkyPlanner sender tiden til Fulcrum via /api/job-tracking-timers/start og /stop eller som en afsluttet tidsblok via /api/timers. Antal sendes via add-quantity-completed, og det endelige antal inklusive kassation sendes via complete. Omkostningsberegningen for opgaver i Fulcrum holdes løbende ajour.

5. Regler for dataansvar og konflikter. Fulcrums planlægningsfunktion “dictates the order of operations in Job Tracking.” (bestemmer rækkefølgen af operationer i Job Tracking). Vælg derfor én kanal til fordeling af arbejdet pr. operation: SkyPlanners operatørkø eller Fulcrum Job Tracking. Skriv reglerne ned før idriftsættelsen:

• Bemandingen afspejles i antallet pr. skiftehold. Fulcrums Max Equipment pr. skiftehold “is usually determined by how many people you have working in a certain area at that time.” (bestemmes normalt af, hvor mange personer der arbejder i et bestemt område på det tidspunkt). Navngivne operatører og deres skiftehold opsættes i SkyPlanner. Navnene hentes fra brugerne i /api/users.
• Arbejdet planlægges på udstyr. Arbejdscentre i Fulcrum er grupper af udstyr, der kan bruges i stedet for hinanden. Sørg for, at det valgte udstyr på ruten er korrekt, da det danner de alternativer, planlægningsmotoren vælger mellem.
• Produktionsordrer samler opgaver. En produktionsordre samler operationer fra flere opgaver, for eksempel i et skærelayout. Når tidsregistreringen startes på en grupperet operation, startes produktionsordrens tidsregistrering i stedet, og den dækker alle opgaveoperationer i gruppen.
• Grænser for tidsregistrering. Efterregistrerede tidsblokke via /api/timers “may not be in the future, older than 30 days, or longer than 7 days.” (må ikke ligge i fremtiden eller overskride de angivne grænser for alder og varighed). Overfør tiden, efterhånden som operatørerne registrerer den.
• Tidsformaterne er forskellige. Skiftehold bruger lokale HHmm-værdier, driftsstop og planlagte datoer er i UTC, og estimater for operationer angives i sekunder.
• Opdatering af udstyr erstatter hele posten. En PUT-anmodning for udstyr rydder alle felter, der ikke er med i anmodningen. SkyPlanner læser udstyrsdata og skriver aldrig til dem.
• ITAR-miljøer. Brug .us-værten og et ITAR-token.