Guia de integração do MRPeasy para programação da produção com SkyPlanner APS

O MRPeasy é um único produto na nuvem, sem versões para instalação local, pelo que todos os clientes utilizam a mesma API. Existem duas versões:

1. A REST API v1 (OpenAPI 1.0, servidor https://api.mrpeasy.com/rest/v1) é a API em produção. Abrange /items, /boms, /routings, /manufacturing-orders, /work-centers, /work-center-types, /customer-orders, /purchase-orders, /stock/inventory, /lots, /units e relatórios de produção, como /report/production/operations.
2. A REST API v2 (OpenAPI 2.0.0, servidor https://api.mrpeasy.com/rest/v2) encontra-se numa fase inicial de desenvolvimento. Acrescenta /workstation-groups com work_hours e holidays, /workstations com productivity e idle, /inventory, /stock-movement e PATCH. As ordens de fabrico continuam na v1.

Tenha atenção às designações. Na interface do MRPeasy, um Workstation group corresponde a work-center-types na v1 (type_id). Um Workstation corresponde a work-centers (center_id). As operações da gama operatória referenciam um grupo através de type_id, e não uma máquina.

A API está incluída no plano Unlimited do MRPeasy, para contas pagas. O MRPeasy também declara: “Our Support Department cannot help you using the API.” (O nosso departamento de apoio não pode ajudar na utilização da API.) Por isso, a integração precisa de um responsável: o SkyPlanner, o seu consultor de MRPeasy ou o seu programador. É precisamente esse trabalho que a equipa do SkyPlanner assume durante a implementação inicial.

A página de preços do MRPeasy indica “API, webhooks (for paid accounts)” (API e webhooks para contas pagas), mas as especificações da v1 e da v2 não documentam eventos de webhook para ordens de fabrico. Por isso, a integração consulta o MRPeasy de forma incremental:

• Ordens de fabrico filtradas pelos estados Not scheduled (15), Scheduled (20), In progress (30) e Paused (35).
• Encomendas de compra e existências a intervalos definidos ou antes de cada execução da programação.
• Dados mestre quando há alterações ou todas as noites.

A consulta sequencial com filtros fica bastante abaixo do limite de 100 pedidos por 10 segundos. No sentido inverso, os próprios webhooks do SkyPlanner enviam as alterações à programação assim que ocorrem, pelo que a escrita de retorno é desencadeada por eventos.

1. Carga inicial dos dados mestre. Obtenha artigos, unidades, BOMs e gamas operatórias da v1, e grupos de centros de trabalho e centros de trabalho da v1 ou da v2. Obtenha os calendários de /workstation-groups na v2 (work_hours, holidays) ou defina os turnos diretamente no SkyPlanner. Associe cada grupo Active processing a um grupo de centros de trabalho do SkyPlanner, incluindo os respetivos centros de trabalho como membros.

2. Sincronização de ordens. Leia as ordens de fabrico em aberto com as respetivas operações, bem como as encomendas de compra em aberto e as existências. O SkyPlanner considera o material encomendado disponível na data de entrega da encomenda de compra e atualiza as existências quando esta é marcada como Delivered. A cada reprogramação, são verificadas tanto as existências como as compras a receber.

3. Escrita da programação no MRPeasy. PUT /manufacturing-orders/{id} suporta code, quantity, due_date e assigned_id, bem como campos personalizados no formato custom_<id>. O SkyPlanner grava o fim planeado em due_date quando tal é acordado. Grava também o início planeado, o fim planeado e o progresso nos campos personalizados do MRPeasy. Assim, as equipas de vendas e compras veem a programação real no MRPeasy. A sequência detalhada das operações e o centro de trabalho atribuído a cada operação ficam no SkyPlanner, cuja vista orienta a execução do trabalho no chão de fábrica.

4. Ordens criadas fora do MRPeasy. Se forem criadas ordens através da API, POST /manufacturing-orders aceita no_scheduling e no_bookings. Utilize-os para que o MRPeasy não reserve centros de trabalho cuja programação já é gerida pelo SkyPlanner.

5. Confirmações no chão de fábrica. Os operadores registam o trabalho com SkyPlanner Mobile Confirmations, Production Timer ou Quick Log Mode, e os registos de tempo mantêm a programação atualizada. Escolha um único canal de registo. Utilizar o Internet-kiosk do MRPeasy e o SkyPlanner em paralelo para as mesmas operações cria dois registos distintos da mesma realidade.

6. Responsabilidades e regras de conflito. Documente-as antes da entrada em produção:

Fluxo de engenharia por encomenda. Num projeto MRPeasy já entregue, cada projeto de cliente dá origem a um produto principal e a um a três produtos semiacabados. Cada um tem a sua própria BOM e gama operatória no MRPeasy, e a ordem de fabrico existe nos dois sistemas. Mantenha um identificador comum e estável em cada ordem para que as atualizações nunca criem duplicados.

• Os campos de tempo variam consoante a interface. Os campos Setup time, Cycle time e Capacity da interface correspondem a fixed_time, variable_time e variable_quantity na API. Uma capacidade superior a 1 significa processamento por lote, como num forno. Faça o mapeamento como uma tarefa por lote, não como um ciclo mais longo.
• Grupos de processamento passivo. Os grupos de secagem e arrefecimento funcionam 24/7, sem limites de capacidade. Mapeie-os como tempos de espera, não como centros de trabalho com capacidade limitada.
• A v1 não inclui calendários. work-centers devolve apenas center_id, type_id, code e title. Use a v2 ou mantenha os turnos no SkyPlanner.
• Tempo de inatividade. O tempo de inatividade dos centros de trabalho inclui os períodos de manutenção e paragem. Sincronize-o; caso contrário, o SkyPlanner planeia trabalho para uma máquina parada.
• As gamas operatórias referenciam grupos. O MRPeasy seleciona a máquina com maior disponibilidade. No SkyPlanner, os centros de trabalho do grupo tornam-se alternativas reais entre as quais o motor escolhe.