Pular para o conteúdo principal

Receita: resolver uma ocorrência do início ao fim

Objetivo

Registrar uma ocorrência (manutenção corretiva), aplicar a ação corretiva e fechar com aprovação — o ciclo completo.

Esta receita é escrita como passos encadeáveis. Uma IA ou integração pode segui-la na ordem. Use a versão v3 (a mais evoluída para ocorrências).

Os exemplos -d '{...}' abaixo são bash/POSIX. No PowerShell, use o padrão de arquivo — ver Primeiros passos → PowerShell.

Pré-requisitos​

  • Token JWT válido (ver Autenticação).
  • empresaId do contexto. Os demais IDs (site, área, equipamento, tipo) são descobertos nos passos.
  • Base URL produção: https://lighthousev2.lkp.app.br · sandbox: https://lighthouse.lkp.dev.br.

Passo 1 — Carregar a configuração da empresa​

Antes de criar, descubra o que a empresa exige (campos obrigatórios, se usa típicas, etc.):

curl "https://lighthousev2.lkp.app.br/v3/ocorrencias/config/123" \
  -H "Authorization: Bearer SEU_TOKEN"

(123 = empresaId). A resposta indica regras de preenchimento e se ocorrências típicas são obrigatórias.

Passo 2 — (Opcional) Listar ocorrências típicas​

Se a empresa usa típicas, obtenha o anomaliaTipicaId válido:

curl "https://lighthousev2.lkp.app.br/v3/ocorrencias/tipicas/123" \
  -H "Authorization: Bearer SEU_TOKEN"

Passo 3 — Criar a ocorrência​

POST /v3/ocorrencias com o SaveOcorrenciaCommand. Campos obrigatórios: empresaId, siteId, plataforma.

curl -X POST "https://lighthousev2.lkp.app.br/v3/ocorrencias" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "empresaId": 123,
    "siteId": 456,
    "plataforma": 6,
    "tipoAnomalia": 1,
    "descricao": "Vazamento no sistema hidráulico do 3º andar",
    "dataRegistro": "2026-06-29T10:00:00",
    "anomaliaTipicaId": 10,
    "areaId": 789,
    "prioridadeAnomaliaId": 2
  }'

A resposta retorna o anomaliaId (string) da ocorrência criada — guarde-o para os próximos passos.

Passo 4 — Registrar a ação corretiva​

Com o anomaliaId, crie a correção (POST /v3/correcoes). Campos obrigatórios: anomaliaId, inicio, plataforma. Consulte os tipos disponíveis antes — o header EmpresaId é necessário (sem ele, [] silencioso):

curl "https://lighthousev2.lkp.app.br/v3/correcoes/tipos" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "EmpresaId: 123"

Use o campo codigo da resposta (não tipoAcaoCorretivaEmpresa) como tipoCorrecaoId — ver Glossário → tipoCorrecaoId para a distinção entre os dois IDs.

curl -X POST "https://lighthousev2.lkp.app.br/v3/correcoes" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "anomaliaId": "ANOMALIA_ID_DO_PASSO_3",
    "inicio": "2026-06-29T10:30:00",
    "plataforma": 6,
    "termino": "2026-06-29T12:00:00",
    "tipoCorrecaoId": 1,
    "descricao": "Substituição do conector hidráulico danificado",
    "observacao": "Peça substituída com estoque local"
  }'

Campos opcionais adicionais: emitentes, executores, fotos, materiais, epis, custo, temAssinatura.

Registrar a correção não soluciona a ocorrência por si só — se a empresa tem aprovação habilitada, ela fica em Analisada (aguardando aprovação) até o Passo 5. Ver Fluxo de ocorrências → Máquina de estados.

Passo 5 — Aprovar / fechar a ocorrência​

PUT /v3/ocorrencias/aprovacao com o AprovarOcorrenciaCommand. Os campos anomaliaId, statusAprovacaoId e temAssinatura são obrigatórios em qualquer chamada, mas não bastam para aprovar — ver Glossário → statusAprovacaoId (tabela corrigida em 05/07/2026: 2 é Aprovado, não 1).

Ao enviar statusAprovacaoId=2, a API também exige statusAvaliacaoId (ver Glossário → statusAvaliacaoId), usuarioAssinaturaId e a assinatura (temAssinatura: true + assinaturaPath) — validação condicional; sem eles, a resposta traz um erro estruturado no campo data.

curl -X PUT "https://lighthousev2.lkp.app.br/v3/ocorrencias/aprovacao" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "anomaliaId": "ANOMALIA_ID_DO_PASSO_3",
    "statusAprovacaoId": 2,
    "statusAvaliacaoId": 1,
    "temAssinatura": true,
    "assinaturaPath": "CAMINHO_DA_ASSINATURA",
    "usuarioAssinaturaId": 59064,
    "descricaoAprovacao": "Reparo verificado e aprovado"
  }'

Resumo do fluxo​

config → (típicas) → POST ocorrência → POST correção → PUT aprovação

Dicas para IA / integração​

  • Consulte o Glossário de IDs e enums para os valores válidos de tipoAnomalia, prioridadeAnomaliaId, anomaliaTipicaId, tipoCorrecaoId, statusAprovacaoId e plataforma.
  • statusAprovacaoId e tipoAnomalia são códigos de negócio — consulte os endpoints de referência (/tiposocorrencias, /correcoes/tipos, /prioridadesocorrencias) para os valores válidos.
  • O anomaliaId criado no Passo 3 é a chave que costura todos os passos seguintes.
  • plataforma é obrigatório em SaveOcorrenciaCommand e SaveCorrecaoCommand — use 6 (API) para integrações server-side.
  • Para apenas registrar (sem fechar), pare no Passo 3.
  • Endpoints de escrita afetam dados reais — teste no ambiente Sandbox.