Pular para o conteúdo principal

Passo 1 — Preparar os catálogos

Antes de criar equipamentos e ordens, os catálogos têm de existir. São vários grupos independentes.

Ordem sugerida

Crie primeiro tipos/marcas/modelos de equipamento, depois catálogos e estados da ordem, e por fim tipos/estados de intervenção.

1.1 Tipos, marcas e modelos de equipamento​

Tipo (ex.: "Portátil"):

POST /gateway/equipment-type
Content-Type: application/json
Authorization: Bearer {token}
{
  "keyId": "PORT",
  "description": "Portátil"
}

Marca (ex.: "Lenovo"):

POST /gateway/equipment-brand
Content-Type: application/json
Authorization: Bearer {token}
{
  "keyId": "LEN",
  "description": "Lenovo"
}

Modelo (ex.: "ThinkPad T14"):

POST /gateway/equipment-model
Content-Type: application/json
Authorization: Bearer {token}
{
  "keyId": "T14",
  "description": "ThinkPad T14",
  "brandKeyId": "LEN"
}
Chaves nos paths

Estes três recursos usam {keyId} alfanumérico nos GET/PUT/DELETE (ex.: GET /equipment-brand/LEN), mas o equipamento em si usa {id} numérico (GET /equipment/123). Confirme sempre na referência de cada recurso.

1.2 Catálogos da ordem de serviço​

Endpoint unificado — o {catalogType} escolhe a tabela: 0 = Prioridades, 1 = Tipos de assistência.

Prioridade (catalogType = 0):

POST /gateway/service-order-catalog/0
Content-Type: application/json
Authorization: Bearer {token}
{
  "keyId": "URG",
  "description": "Urgente"
}

Tipo de assistência (catalogType = 1):

POST /gateway/service-order-catalog/1
Content-Type: application/json
Authorization: Bearer {token}
{
  "keyId": "REP",
  "description": "Reparação em oficina"
}

1.3 Estados da ordem de serviço​

Os estados controlam o ciclo de vida da ordem:

POST /gateway/service-order-state
Content-Type: application/json
Authorization: Bearer {token}
{
  "keyId": "RECEB",
  "description": "Recebida",
  "requestReason": false,
  "closeServiceOrder": false,
  "sendSmsToCustomer": false,
  "sendEmailToCustomer": false
}

Campos obrigatórios: keyId (≤10 car.) e description (≤50 car.).

Com requestReason: true, é obrigatório indicar um motivo sempre que a ordem mudar para este estado (o motivo fica no histórico de estados). Este comportamento está em funcionamento.

Automatismos ainda não activos

Os restantes campos (sendSmsToCustomer, sendEmailToCustomer, sendSmstoUser, sendEmailToUser, closeServiceOrder, closePendingQuotes e respectivos textos/layouts) são guardados e devolvidos pela API, mas os automatismos associados (SMS/email e fecho automático) ainda não estão implementados. Configurá-los não produz, para já, qualquer efeito.

O fecho da ordem faz-se explicitamente pelo POST /service-order/{guid}/close — ver Ordem de serviço — Fecho.

1.4 Tipos e estados de intervenção​

Também unificado — {configType}: 0 = Tipos, 1 = Estados.

Tipo de intervenção (configType = 0):

POST /gateway/intervention-config/0
Content-Type: application/json
Authorization: Bearer {token}
{
  "keyId": "DIAG",
  "description": "Diagnóstico"
}

Estado de intervenção (configType = 1):

POST /gateway/intervention-config/1
Content-Type: application/json
Authorization: Bearer {token}
{
  "keyId": "CURSO",
  "description": "Em curso"
}

Seguinte​

Leia a configuração SAT (sat-config) antes de criar ordens. Depois configure (opcionalmente) os contratos de assistência ou avance para o equipamento.