Leitfaden zur MRPeasy-Schnittstelle für die Feinplanung mit SkyPlanner APS

MRPeasy ist ein einheitliches Cloud-Produkt ohne On-Premises-Versionen. Daher nutzen alle Kunden dieselbe API. Es gibt zwei Versionen:

1. REST API v1 (OpenAPI 1.0, Server https://api.mrpeasy.com/rest/v1) ist die API für den produktiven Einsatz. Sie umfasst /items, /boms, /routings, /manufacturing-orders, /work-centers, /work-center-types, /customer-orders, /purchase-orders, /stock/inventory, /lots, /units sowie Produktionsberichte wie /report/production/operations.
2. REST API v2 (OpenAPI 2.0.0, Server https://api.mrpeasy.com/rest/v2) befindet sich in einer frühen Entwicklungsphase. Sie ergänzt /workstation-groups mit work_hours und holidays, /workstations mit productivity und idle, /inventory, /stock-movement sowie PATCH. Fertigungsaufträge werden weiterhin über v1 abgewickelt.

Achten Sie auf die unterschiedlichen Bezeichnungen. Eine Workstation group in der MRPeasy-Oberfläche entspricht in v1 work-center-types (type_id). Eine Workstation entspricht work-centers (center_id). Die Arbeitsgänge eines Arbeitsplans verweisen über type_id auf eine Gruppe, nicht auf eine Maschine.

Die API ist für zahlende Konten im MRPeasy-Tarif Unlimited enthalten. MRPeasy weist außerdem darauf hin: „Our Support Department cannot help you using the API.“ (Unser Support kann Sie bei der Nutzung der API nicht unterstützen.) Deshalb braucht die Schnittstelle einen klaren Verantwortlichen: SkyPlanner, Ihren MRPeasy-Berater oder Ihren Entwickler. Genau diese Aufgabe übernimmt das SkyPlanner-Team beim Onboarding.

Auf der Preisseite von MRPeasy steht „API, webhooks (for paid accounts)“ (API, Webhooks für zahlende Konten). Die Spezifikationen von v1 und v2 dokumentieren jedoch keine Webhook-Ereignisse für Fertigungsaufträge. Die Schnittstelle fragt MRPeasy daher inkrementell ab:

• Fertigungsaufträge, gefiltert nach den Status Not scheduled (15), Scheduled (20), In progress (30) und Paused (35).
• Bestellungen und Lagerbestände in festgelegten Intervallen oder vor jedem Planungslauf.
• Stammdaten bei Änderungen oder jede Nacht.

Sequenzielles, gefiltertes Polling bleibt deutlich unter dem Limit von 100 Anfragen pro 10 Sekunden. In der Gegenrichtung übertragen die eigenen Webhooks von SkyPlanner Planänderungen, sobald sie auftreten. Das Zurückschreiben erfolgt somit ereignisgesteuert.

1. Stammdaten erstmals importieren. Lesen Sie Artikel, Einheiten, Stücklisten und Arbeitspläne aus v1 ein, Arbeitsstationsgruppen und Arbeitsstationen aus v1 oder v2. Übernehmen Sie Kalender aus v2 /workstation-groups (work_hours, holidays) oder legen Sie Schichten direkt in SkyPlanner fest. Ordnen Sie jede Gruppe vom Typ Active processing einer Arbeitsstationsgruppe in SkyPlanner zu und nehmen Sie die zugehörigen Arbeitsstationen als Mitglieder auf.

2. Aufträge synchronisieren. Lesen Sie offene Fertigungsaufträge samt Arbeitsgängen sowie offene Bestellungen und Lagerbestände ein. SkyPlanner betrachtet bestelltes Material zum Liefertermin der Bestellung als verfügbar und aktualisiert den Lagerbestand, sobald die Bestellung als Delivered markiert wird. Bei jeder Neuplanung werden sowohl Lagerbestände als auch erwartete Lieferungen aus Bestellungen geprüft.

3. Planung zurückschreiben. PUT /manufacturing-orders/{id} unterstützt code, quantity, due_date und assigned_id sowie benutzerdefinierte Felder in der Form custom_<id>. Sofern vereinbart, schreibt SkyPlanner das geplante Ende in due_date. Geplanter Start, geplantes Ende und Fortschritt werden in benutzerdefinierte Felder in MRPeasy geschrieben. Vertrieb und Einkauf sehen dann in MRPeasy die tatsächliche Planung. Die detaillierte Reihenfolge der Arbeitsgänge und die Arbeitsstationszuordnung je Arbeitsgang werden in SkyPlanner geführt. SkyPlanner dient damit als Leitstand für die Fertigung.

4. Außerhalb von MRPeasy erstellte Aufträge. Falls Aufträge über die API erstellt werden, akzeptiert POST /manufacturing-orders die Parameter no_scheduling und no_bookings. Nutzen Sie diese, damit MRPeasy keine Arbeitsstationen belegt, die bereits von SkyPlanner eingeplant werden.

5. Rückmeldungen aus der Fertigung. Bediener erfassen ihre Arbeit mit SkyPlanner Mobile Confirmations, Production Timer oder Quick Log Mode. Die Zeitbuchungen halten die Planung aktuell. Entscheiden Sie sich für einen Rückmeldekanal. Wenn Sie für dieselben Arbeitsgänge parallel den Internet-kiosk von MRPeasy und SkyPlanner nutzen, entstehen zwei unterschiedliche Datenstände.

6. Datenhoheit und Konfliktregeln. Halten Sie diese vor dem Go-live schriftlich fest:

Engineer-to-Order-Ablauf. In einem umgesetzten MRPeasy-Projekt wird jedes Kundenprojekt als Hauptprodukt mit einem bis drei Halbfertigprodukten abgebildet. Jedes davon hat in MRPeasy eine eigene Stückliste und einen eigenen Arbeitsplan. Der Fertigungsauftrag ist in beiden Systemen vorhanden. Verwenden Sie für jeden Auftrag eine beständige, systemübergreifende Kennung, damit bei Aktualisierungen niemals Duplikate entstehen.

• Zeitfelder heißen je nach Schnittstelle anders. Die Felder Setup time, Cycle time und Capacity in der Benutzeroberfläche entsprechen fixed_time, variable_time und variable_quantity in der API. Ein Capacity-Wert über 1 steht für Chargenverarbeitung, etwa in einem Ofen. Bilden Sie dies als Chargenarbeitsgang ab, nicht als längere Zykluszeit.
• Gruppen für passive Bearbeitung. Trocknungs- und Kühlgruppen laufen 24/7 ohne Kapazitätsgrenzen. Bilden Sie sie als Wartezeiten ab, nicht als Arbeitsstationen mit begrenzter Kapazität.
• In v1 fehlen Kalender. work-centers liefert nur center_id, type_id, code und title. Nutzen Sie v2 oder pflegen Sie die Schichten in SkyPlanner.
• Stillstandszeiten. Workstation idle time enthält Wartungs- und Ausfallzeiten. Synchronisieren Sie diese Daten, sonst plant SkyPlanner Arbeit auf einer Maschine ein, die stillsteht.
• Arbeitspläne verweisen auf Gruppen. MRPeasy wählt die Maschine mit der besten Verfügbarkeit. In SkyPlanner stehen die Arbeitsstationen der Gruppe als tatsächliche Alternativen zur Verfügung, zwischen denen die Planungsengine wählt.