/v1/buyer/work_order/: creación de órdenes de trabajo, consulta, acciones de estado del lado del comprador, el hilo de notas, las etiquetas y los tipos de problema.
Todos los ejemplos asumen estas variables de shell:
El objeto orden de trabajo
Una orden de trabajo devuelta por la API lleva, entre otros campos:Crear una orden de trabajo
POST /v1/buyer/work_order/work_orders requiere más que los campos obvios. A diferencia de la mayoría de endpoints del comprador, buyerFacilityId, buyerCompanyId y createdBy deben suministrarse en el cuerpo; no se derivan de tu clave de API en este endpoint. Usa GET /v1/buyer/me para consultar tus ids de empresa e instalación una vez y cachéalos.
Campos requeridos: title, locationId, problemTypeId, buyerFacilityId, buyerCompanyId y createdBy (el correo del contacto que crea).
- Estado inicial. Si se omite
status, el estado inicial se calcula a partir de la configuración de tu empresa. Las solicitudes de servicio típicamente empiezan enPendingApproval; las órdenes de trabajo por defecto enUnassigned. Si pasas unstatus, aún se resuelve contra la configuración de la empresa, así que el estado efectivo puede diferir del que enviaste. - Despachar al crear. Pasar
supplierFacilityIdasigna el proveedor de inmediato. UnsupplierFacilityId,assetIdoproblemTypeIddesconocido se rechaza con400. - Subactivos.
subAssetIdses un arreglo opcional de ids de subactivos que se adjuntan junto alassetIdprincipal. Los subactivos son activos creados con unparentId; ver Activos. - Flag de aprobación. El campo es
needApproval, noneedsApproval. El objeto de respuesta usaneedsApproval; la solicitud de creación no. - Enlace a recorrido.
walkThroughIdysiteSurveyTaskTitleIddeben suministrarse juntos o no suministrarse. Ver Recorridos de encuesta de sitio. - Upserts. Pasar un
idactualiza esa orden de trabajo existente en lugar de crear una nueva.
Listar, filtrar y contar
offset, limit (por defecto 10, máx. 25), sort_by y order. Cualquier otro parámetro de consulta se trata como un filtro de campo; separa un valor por coma para coincidir con cualquiera de varios (status=Unassigned,PendingApproval). Los filtros siempre se combinan con el alcance por inquilino derivado de tu clave, así que solo verás las órdenes de trabajo de tu empresa.
El listado y el conteo resuelven qué órdenes de trabajo coinciden en el índice de búsqueda de OpenWrench y luego cargan los registros completos desde la base de datos. Eso cambia algunos comportamientos:
- Búsqueda de texto completo.
search=coincide con palabras (con coincidencia por prefijo y por raíz) en el título, la descripción, el nombre de la ubicación, las notas, las notas de check-in y check-out de las llamadas de servicio, y el nombre del tipo de problema. También coincide con números de referencia como el número de orden de trabajo, el número de PO y el número de serie del activo. Pon el valor entre comillas (search="walk-in cooler") para exigir la frase exacta. - Los filtros de activo incluyen los subactivos.
assetId=yassetIds=coinciden con órdenes de trabajo cuyo activo principal o cualquiera de sus subactivos es el id dado. - Ordenamiento.
sort_byadmitecreatedAt,locationName,woPriority(por el tiempo de resolución esperado de la prioridad) ylastServiceCallServiceScheduledAt. Cualquier otro valor, o la ausencia desort_by, ordena porcreatedAtdescendente. - Los filtros no indexados se ignoran.
updatedAtStartDate,updatedAtEndDate,buyerFacilityIdywalkthroughIdno están en el índice de búsqueda y ya no estrechan los resultados. Filtra en su lugar por ventanas destatusChangedAtu otras columnas indexadas. - Frescura. Las actualizaciones del índice de búsqueda y de la réplica van un momento por detrás de las escrituras, así que una orden de trabajo creada hace milisegundos puede estar brevemente ausente de los resultados de listado y de los conteos.
- Profundidad de paginación.
offset + limitno puede exceder la ventana de resultados de búsqueda de 10.000. Estrecha el filtro en lugar de paginar tan profundo.
GET /v1/buyer/work_order/work_orders/{id}.
Reasignar un proveedor
PATCH /v1/buyer/work_order/work_orders/{id} es deliberadamente estrecho: solo supplierFacilityId y supplierPrimaryContactEmail se leen del cuerpo. Cualquier otro campo que envíes se ignora silenciosamente en lugar de rechazarse.
supplierPrimaryContactEmailsolo aplica como parte de una reasignación. Enviarlo sin un cambio de instalación de proveedor hace que todo el patch sea un no-op: nada se persiste y se devuelve la orden de trabajo actual.- Un id inexistente y una denegación de permiso devuelven la misma respuesta
400unauthorized, así que no uses este endpoint para sondear si una orden de trabajo existe.
Acciones de estado del comprador
Cuatro endpoints dedicados mueven una orden de trabajo por las partes del ciclo de vida que son propiedad del comprador. Cada uno toma el mismo cuerpo: elid de la orden de trabajo y una note opcional que se añade al hilo junto con el cambio de estado.
Bloqueo de cancelación mientras un técnico tiene check-in activo
Las empresas pueden optar por un bloqueo de cancelación que mantiene abiertas las órdenes de trabajo mientras un técnico está en sitio. Con el bloqueo habilitado, OpenWrench rechaza cualquier cancelación con409 Conflict si un técnico tiene un check-in activo en cualquiera de las llamadas de servicio de la orden de trabajo. Esto cubre las visitas de la propia orden de trabajo y las visitas de sus órdenes de trabajo subcontratadas. OpenWrench bloquea de la misma forma la cancelación de un subcontrato cuyo estado se propaga a la orden de trabajo raíz, y no confirma nada en ninguna de las dos órdenes.
El bloqueo se configura por empresa compradora con dos ajustes:
El mensaje de error
409 identifica al técnico con check-in por su correo cuando la visita lo registró:
409, espera a que el técnico haga check-out (o a que el check-in caduque) y reintenta, o pide al proveedor que termine la visita primero. El bloqueo forma parte de la configuración de órdenes de trabajo de tu empresa compradora en OpenWrench.
El modelo de estados
Valores destatus que verás y que establecerás a través de la API:
Las transiciones propiedad del proveedor llegan a través de la integración del propio proveedor o de las apps de OpenWrench; tu lado las observa mediante webhooks o por sondeo (
statusChangedAt, statusChanges) y actúa sobre las que son propiedad del comprador.
Notas
Las órdenes de trabajo llevan un hilo de notas comprador-proveedor compartido. Añade conPATCH /v1/buyer/work_order/work_orders/append_notes. El cuerpo es { "id": <woId>, "note": { ... } } donde la nota necesita text y noteAddedBy. El servidor sobrescribe noteAddedAt con su propio reloj, y el correo del autor se añade a la lista de suscriptores del comprador de la orden de trabajo para que reciba notificaciones posteriores.
taggedUsers junto a note: una lista de correos electrónicos de contactos a los que @mencionar. OpenWrench incorpora cada correo en note.elements como un elemento user, la misma forma que las apps escriben para una @mención, así que no necesitas construir la estructura elements tú mismo. Los contactos etiquetados se añaden a la lista de suscriptores de la orden de trabajo si aún no están suscritos.
taggedUsers:
- Los correos se recortan y se pasan a minúsculas antes de compararse. Una nota puede mencionar como máximo a 25 usuarios.
- Los correos duplicados en la lista, y los usuarios ya etiquetados en
note.elements, se omiten en lugar de mencionarse dos veces. - Una entrada que no sea un correo electrónico válido, o una lista de más de 25 correos, se rechaza con un
400de tipoinvalidInputDataException. No se persiste nada. - Una lista vacía se ignora. Enviar
taggedUserssin un objetonotese rechaza con400.
PATCH /v1/buyer/work_order/work_orders/append_notes/bulk. Úsalo cuando tengas un lote de fotos que publicar (el conjunto de antes/después de un técnico, por ejemplo): los suscriptores reciben una única notificación agrupada en lugar de una notificación por foto. El cuerpo es { "id": <woId>, "notes": [ ... ] } con de 1 a 25 notas, y cada nota debe llevar una URL en photo y ningún otro contenido: text debe estar vacío y video, audio, otherFile y elements deben estar ausentes. Repetir la misma URL de foto dentro de una solicitud se rechaza con 400. El servidor marca cada nota del lote con el mismo noteAddedAt y conserva el orden en que las enviaste.
GET /v1/buyer/work_order/work_order_notes/{woId}. Esto devuelve solo el hilo raíz comprador-proveedor (los hilos de contratista e internos son separados), y la lectura marca las notas como leídas para tu contacto. Una lectura denegada devuelve una lista vacía en lugar de un error.
Etiquetas
Las etiquetas son marcadores ligeros que tu equipo define en la app de OpenWrench (un nombre más un color opcional). A través de la API puedes leer el catálogo y reemplazar las etiquetas aplicadas a una orden de trabajo. La creación y edición de las etiquetas en sí permanece en la app. Explora el catálogo conGET /v1/buyer/work_order/work_order_labels, u obtén una con GET /v1/buyer/work_order/work_order_labels/{id}. El listado está limitado a las etiquetas de tu empresa y paginado a 10 por página por defecto. Acepta filtros search y label sobre el texto de la etiqueta. Pasa no_pagination=true para traer el catálogo completo en una sola llamada (el ordenamiento sigue aplicando).
PUT /v1/buyer/work_order/work_orders/{woId}/labels. El cuerpo es { "ids": [...] } y es un reemplazo completo: las etiquetas no listadas se eliminan, y un array vacío las borra todas. La respuesta lista los mapeos de etiquetas ahora activos en la orden de trabajo.
- Un
idsausente o que no sea un array, o un id que no sea un número entero, se rechaza con400. - Cada id debe ser una etiqueta viva de tu propio catálogo. Los ids desconocidos o de otro inquilino responden
400con los ids problemáticos listados. - La escritura requiere permiso de escritura de órdenes de trabajo. Un id de orden de trabajo desconocido, eliminado o ajeno responde el mismo
400que una escritura denegada, no un404.
Tipos de problema
GET /v1/buyer/work_order/problem_types lista los tipos de problema configurados para tu empresa. Cachea esto: necesitas un problemTypeId válido para cada orden de trabajo que crees, y el endpoint jerarquizado de proveedores también toma uno.
Juntándolo todo
Una integración de despacho típica:- Cachea
me, tipos de problema y ubicaciones al arrancar. - Crea la orden de trabajo con
supplierFacilityIdestablecido (o créala sin asignar, luego jerarquiza proveedores y hazPATCHde la asignación). - Sigue el progreso del proveedor mediante webhooks (
workorder.status_update), obteniendo cada orden de trabajo por id cuando llegue un evento. ManténGET /work_orders?statusChangedAt=...como una pasada de conciliación poco frecuente, no como la señal principal. - Cuando el proveedor alcance
WaitingForReview, verifica el trabajo (ver Llamadas de servicio para la evidencia de la visita) y publicawork_reviewed_and_completed, owork_unsatisfactorycon una nota. - Concilia el lado monetario mediante Cotizaciones y propuestas y Facturas.