Estrutura de dados do Skyplanner #
Antes de mergulharmos nos timelogs, precisamos discutir um pouco sobre a estrutura de dados no Skyplanner e como as coisas funcionam por baixo do capô. Tudo isso será discutido mais tarde.
Se integraste os dados das tuas encomendas/ordens de trabalho/trabalhos na Skyplanner, é muito provável que tenhas utilizado pelo menos estes pontos de extremidade da API:
- encomendas phaser
- ordenar linhas
- phaser-jobs
Efetivamente, os dados inseridos nestes pontos finais são representados na IU do Skyplanner da seguinte forma:
Depois de inserires as tuas encomendas no Skyplanner, deves exportá-las (isto pode ser feito através da interface do utilizador ou do ponto de extremidade /phaser-orders/export-endpoint) para o módulo de planeamento da produção:
Ao exportar pedidos, o Skyplanner copia efetivamente os dados do pedido de uma tabela de banco de dados para outra. Assim, se alterares algo, por exemplo, através do endpoint /phaser-orders, tens de exportar os dados novamente para os atualizar no Planeamento da Produção. Isto também significa que, para aceder às ordens que vês na janela do Planeamento da Produção, tens de usar diferentes API-endpoints!
Os pontos finais “alterados” são os seguintes:
- /phaser-orders → /orders
- /phaser-order-rows → /order-rows
- /phaser-jobs → /jobs
É importante saber isto, porque ao usar o ponto de extremidade /timelogs para registar os teus eventos de produção, etc. , tens de usar as entidades relacionadas encontradas nos pontos de extremidade do Planeamento da Produção!
Por exemplo, precisas do production_planning_job_id (para reiterar: production_planning_jobs são as entidades acedidas a partir do ponto de extremidade /jobs) para POSTar um novo timelog:
Podes encontrar o production_planning_job_id de que precisas a partir do ponto final /phaser-jobs:
Ou a partir do ponto final /job:
Criar registos de tempo utilizando a API REST #
Faz registos de tempo para o Skyplanner através da API e utiliza as mesmas regras e sistemas que estão na IU. Por isso, pode ser benéfico familiarizares-te com o funcionamento do sistema na IU antes de o tentares utilizar através da API.
Noções básicas sobre o registo de tempo #
O Skyplanner tem quatro tipos de eventos de registo de tempo:
- shift_begin
- interrompido
- continua
- shift_end
O evento Shift_begin é enviado quando a tarefa é iniciada pela primeira vez. Nunca envies mais do que um evento shift_begin para cada trabalho!
Pausa – evento que pausa a tarefa.
O evento continuado retoma uma tarefa em pausa.
Shift_end termina o trabalho. Nunca envies mais do que um evento shift_end para cada trabalho!
Dados necessários para os registos de tempo:
- id_pessoa
- Pode ser encontrado no ponto de extremidade /people
- Não é o mesmo que user_id!
- planned_workstation_id
- O posto de trabalho onde o trabalho está a ser feito
- Pode ser encontrado no /workstations-endpoint
- data_horário
- O momento em que o evento é realizado
- Formata: 2024-01-01 10:30:11
Para especificar que timelog da Skyplanner está ligado ao timelog de qualquer sistema externo que estejas a utilizar, podes utilizar o campo external_id . Podes então, por exemplo, fazer pedidos GET utilizando este id para encontrar um timelog específico do Skyplanner.
Começar um trabalho #
Podes iniciar tarefas enviando um pedido POST como este para a API:
Ao definir os dados POST para os registos de tempo, define workshift_id como 0 e timelog_finalized como true
Pausa um trabalho #
Pausa os trabalhos enviando um pedido POST como este:
Nos registos cronológicos do tipo pausado, podes definir o montante e o faulty_amount. Tem também em atenção o tipo de registo de tempo e date_time.
Continua a trabalhar #
Eis como podes continuar um registo de tempo em pausa:
Nota que se tentares continuar um trabalho que tenha sido terminado por um evento shift_end, receberás um erro.
Terminar um emprego #
Eis como terminas um trabalho através de um registo de tempo shift_end:
Em shift_end-events podes dar os valores amount e faulty_amount tal como em paused-events. Nota que se tentares fazer um shift_end-events a um trabalho que não está em execução, receberás um erro.
Atualizar registos de tempo #
Podes atualizar os dados do registo de tempo enviando pedidos PUT para o ponto final /timelogs-endpoint, da seguinte forma:
Nota que tens de ter os dados beginTimelog e endTimelog definidos para fazeres uma atualização. Os registos de tempo no Skyplanner são armazenados da seguinte forma: cada registo de tempo “completo” (registo de tempo que tem um início e um fim (por exemplo, shift_begin/continued & paused/shift_end) tem uma entidade separada para o início e o fim.
Estes são emparelhados pelo valor begin_id encontrado no endlog. No exemplo acima, o beginTimelog tem o valor de id 1 e, por conseguinte, o seu endTimelog tem o valor begin_id 1.
Também tens de fornecer os valores person_id e endTimelog de cada vez que fazes um pedido de atualização, mesmo que não os alteres.
Formas alternativas de fazer registos de tempo #
Aqui estão algumas formas alternativas de acederes aos teus trabalhos utilizando a API.
Logfull #
Se quiseres enviar os registos de tempo de início e de fim num único pedido, podes utilizar o ponto de extremidade /timelogs/log-full, desta forma:
Repara como os montantes são enviados aqui: o primeiro valor “amount” denota o montante defeituoso e o segundo o montante. Este pedido cria as entidades beginlog e endlog num único pedido.
Registo rápido #
O “Quicklogging” de um trabalho completa-o num único pedido, define a quantidade de produtos completada para corresponder ao valor definido no item da encomenda. O registo rápido é feito utilizando o ponto final /timelogs/quick-log:
Observar que aqui só é necessário fornecer production_planning_job_id, planned_workstation_id e person_id. Os valores de tempo e montante são preenchidos automaticamente. Nota também que os trabalhos com registo rápido são sempre concluídos com o evento shift_end, pelo que não é possível qualquer outro registo após o registo rápido!