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

A Epicor afirma: “All Kinetic services, including business objects, processes, reports, BAQs, and Epicor Functions, are accessible through REST endpoints.” (Todos os serviços do Kinetic, incluindo objetos de negócio, processos, relatórios, BAQs e Epicor Functions, estão acessíveis através de endpoints REST.) Uma integração para programação da produção assenta em quatro tecnologias Epicor:

1. Kinetic REST API v2 (OData v4). Os objetos de negócio são expostos como serviços com o nome Erp.BO.<Name>Svc. O caminho habitual é /api/v2/odata/{Company}/Erp.BO.{Svc}/{EntitySet}. A REST v1 continua a existir, mas é uma versão legada, pelo que deve desenvolver a integração com a v2. Confirme os conjuntos de entidades e os métodos disponíveis na sua versão na REST Help, em /api/help/v2/.
2. Business Activity Queries (BAQ) via REST. Cada BAQ é exposta em /api/v2/odata/{Company}/BaqSvc/{BAQ}/Data. Esta é a via prática para extrair dados de planeamento que cruzam JobHead, JobOper, JobMtl, PartWhse e PORel numa única chamada (exemplo da comunidade).
3. Epicor Functions (EFx). Funções executadas no servidor, que podem ser chamadas em /api/v2/efx/{Company}/{Library}/{Function}. A Epicor afirma que estas “can be triggered from multiple entry points, including BPMs, REST services, schedules, and application events.” (podem ser acionadas a partir de vários pontos de entrada, incluindo BPMs, serviços REST, agendamentos e eventos da aplicação).
4. Diretivas BPM. As Method Directives e Data Directives são acionadas quando uma ordem de fabrico ou operação é alterada e podem chamar uma função que envia dados para o exterior.

No caso dos ficheiros, o DMT trata das importações e as exportações BAQ tratam da extração de dados. A Epicor também disponibiliza o Epicor Automation Studio, que descreve como “a low-code app for integration-led automations” (uma aplicação de baixo código para automatizações baseadas em integrações). Evite o acesso direto à base de dados: REST, BAQs e funções funcionam da mesma forma em instalações locais e no Kinetic Cloud.

A Epicor não documenta nenhuma API genérica de webhooks de saída, pelo que as alterações no Kinetic chegam ao SkyPlanner de uma de duas formas:

• Por eventos. Uma BPM Data Directive sobre JobHead ou JobOper chama uma Epicor Function, que envia a ordem de fabrico alterada para a REST API do SkyPlanner.
• Consultas periódicas. Uma BAQ filtrada pela data de alteração é executada de poucos em poucos minutos ou de hora a hora. Esta opção é mais simples de manter e de recuperar em caso de falha.

No sentido inverso, o SkyPlanner envia alterações de estado e da programação através dos seus webhooks. O seu middleware ou um endpoint EFx recebe-as e grava-as no Kinetic.

1. Carga inicial dos dados mestre. Leia os artigos, grupos de recursos, recursos, capacidades, calendários e colaboradores. Crie os centros de trabalho do SkyPlanner a partir dos recursos do Kinetic e os grupos de centros de trabalho a partir dos grupos de recursos. Nas leituras de grande volume, use $top e $skip para paginar os resultados ou extraia os dados em bloco através de uma BAQ.

2. Sincronização de ordens. Envie as ordens de fabrico lançadas e firmes, com as respetivas operações e materiais. Obtenha a árvore da ordem com GetDatasetForTree ou uma BAQ, em vez de ler entidade a entidade. Mantenha no Kinetic as ordens de fabrico do MRP que ainda não são firmes, até serem firmadas. Juntamente com a leitura das existências, sincronize as entregas em aberto das encomendas de compra e as respetivas datas previstas. O SkyPlanner considera o material encomendado disponível na data de entrega e atualiza as existências quando a encomenda de compra é marcada como Delivered. Assim, a programação tem em conta tanto as existências como as compras a receber.

3. Gravação da programação no Kinetic. O webhook do SkyPlanner envia o início, o fim e o centro de trabalho planeados para cada operação para um endpoint EFx (/api/v2/efx/{Company}/{Library}/{Function}). A função grava os dados através do motor de programação do Kinetic, o mesmo objeto de negócio utilizado pela programação de Job Entry e pelos quadros de programação (exemplo da comunidade):

1. ScheduleEngine.GetNewParamsForJob cria o conjunto de dados do motor de programação para a ordem de fabrico.
2. A função define o número da ordem de fabrico, as sequências de montagem e de operação e a data e hora de início planeadas. Em seguida, chama ScheduleEngine.MoveJobItem.
3. Quando o SkyPlanner atribui a operação a outro recurso do grupo, ScheduleEngine.ChangeResource transfere-a para esse recurso. Por si só, MoveJobItem mantém o recurso predefinido do grupo.
4. A função ativa o bloqueio da programação da ordem de fabrico (JobHead.SchedLocked, a opção Lock em Job Entry), para que Global Scheduling mantenha as datas do SkyPlanner.

Encapsular estas chamadas numa única Epicor Function garante uma gravação atómica por ordem de fabrico e permite acrescentar validações próprias. Se a unidade fabril preferir não usar uma função personalizada, a mesma sequência pode ser executada através de chamadas REST diretas a Erp.BO.ScheduleEngineSvc. Nunca grave diretamente em ResourceTimeUsed nem nos campos de data de JobOper: isso contorna o motor e deixa as afetações nos quadros de programação dessincronizadas.

4. Confirmações na fábrica. Os operadores registam o trabalho no SkyPlanner com Mobile Confirmations, Production Timer ou Quick Log Mode. Cada registo de tempo encerrado dá origem a um registo de mão de obra no Kinetic através de Erp.BO.LaborSvc: StartActivity e EndActivityByEmp para atividade em tempo real, ou Labors com Update para registos posteriores à execução. Se a unidade fabril exigir aprovação, inclua submitForApproval no fluxo e no âmbito das permissões.

5. Responsabilidade pelos dados e regras de conflito. Documente-as antes da entrada em produção:

As ordens de fabrico programadas pelo SkyPlanner têm a programação bloqueada, pelo que o Global Scheduling não altera as suas datas. Mantenha a programação do Kinetic para os recursos que o SkyPlanner não planeia.

A implementação fica normalmente concluída em poucas semanas após o início do processo de integração. Um projeto com o Kinetic abrange:

1. Um teste de 30 dias com exportações de ordens de fabrico, operações e recursos em CSV ou Excel, antes de qualquer desenvolvimento.
2. Chave de API, âmbito de acesso, conta de utilizador dedicada à integração e BAQs que a integração consulta.
3. Mapeamento dos dados mestre: correspondência entre capacidades, grupos de recursos, recursos, calendários e colaboradores do Kinetic e os postos de trabalho, grupos, turnos e pessoal do SkyPlanner.
4. Carregamento inicial de artigos, métodos de fabrico (BOM e operações) e recursos.
5. Sincronização de ordens de fabrico e encomendas de compra (datas previstas de PORel), bem como das existências de PartWhse.
6. Gravação das datas planeadas das operações no Kinetic através de ScheduleEngineSvc (MoveJobItem, ChangeResource) numa Epicor Function, com o bloqueio da ordem de fabrico ativado.
7. Confirmações da fábrica lançadas como registos de mão de obra através de LaborSvc.
8. Testes em paralelo com a programação atual do Kinetic, seguidos da entrada em produção.

Não há duas fábricas que utilizem o Kinetic da mesma forma. As gamas operatórias baseadas em capacidades, os calendários dos grupos de recursos, a estrutura das BAQs, as diretivas BPM e os métodos específicos de cada versão para gravar dados de volta no Kinetic variam de instalação para instalação. Configurá-los corretamente faz a diferença entre uma programação em que os planeadores confiam e outra que têm de refazer.

1. A equipa SkyPlanner configura a integração durante a implementação e presta suporte após a entrada em produção. A equipa mapeia os seus recursos, ordens de fabrico e entregas previstas de encomendas de compra, e configura as leituras de BAQs, os acionadores BPM e a função que grava os dados de volta no Kinetic. Liga a API REST e os webhooks do SkyPlanner ao Kinetic REST v2. O suporte mantém-se quando as suas BAQs, BPMs ou a versão do Kinetic mudam.
2. O seu parceiro Epicor. Os parceiros que já desenvolvem BAQs, BPMs e Epicor Functions podem trabalhar com a mesma API REST documentada do SkyPlanner, que permite ler e gravar ordens, produtos, materiais, etapas de processo e registos de tempos.
3. Os seus próprios programadores. As equipas internas com experiência em Kinetic REST podem desenvolver diretamente ou através do Automation Studio, se o utilizarem. Basta uma chave de API do SkyPlanner para começar (tutorial de integração), e a equipa SkyPlanner ajuda sempre que necessário. A documentação do produto está disponível publicamente na documentação do SkyPlanner.

O mesmo modelo de API e webhooks já funciona em produção com outros ERPs, por exemplo na UTU. Na Laboratory & Allied, a equipa interna de TI desenvolveu a integração com o SAP Business One em grande parte pelos seus próprios meios, com o apoio do SkyPlanner.

Todas as opções começam da mesma forma: faça primeiro o teste gratuito de 30 dias com importações CSV, valide a programação e só depois desenvolva a integração. O preço começa nos 199 € por mês com 5 postos de trabalho, faturação mensal e cancelamento a qualquer momento. A integração é orçamentada antecipadamente, em função do seu processo e das suas necessidades, juntamente com o seu plano, para que conheça o custo total antes de começar.