Problemas

Toda ingesta deja una entrega en Configuración › Conexiones › Ver entregas de su conexión. Ahí está el resultado por ticket y el motivo de cada rechazo. Esta página sirve para leerlos y saber qué hacer.

Estados de una entrega

Estado	Qué significa
Recibida	El ZIP llegó y espera su turno.
Procesando	Se están importando los tickets. La tabla se actualiza sola.
Importada	Todos los tickets entraron (en una central o un bot: todos los llamados del día se crearon o actualizaron).
Importada con rechazos	Algunos tickets entraron y otros se rechazaron. Cada rechazo tiene su motivo.
Rechazada	No entró ninguno. En la carga masiva suele ser un problema del inventario: la entrega entera se descarta.
Falló	La corrida se cortó por un error. En una central o un bot, el motivo típico es que el proveedor no respondió o la conexión no tiene credenciales.

Cada fila muestra Fecha, Id de la entrega (con la marca (API) si se subió por la API o (noche) si la corrió la ingesta nocturna), Formato (JSON, CSV, WebFlow o Inceptia), Estado, Tickets, Creados y Rechazados. Debajo, un desplegable «N errores» lista cada ticket rechazado con su motivo. Se guardan hasta 500 motivos por entrega; los conteos son siempre exactos.

Motivos de rechazo de un ticket

El texto que vas a ver, y qué hacer:

Motivo	Qué revisar
<mail> no es un usuario activo del workspace que pueda ser evaluado	El asignado no existe en Configuración › Usuarios, está Inactivo o su rol no permite evaluarlo. Dalo de alta con rol Reviewee o Evaluador y reviewee y volvé a mandar el ticket.
asignado no elegible: «Nombre» no es un usuario evaluable y activo del workspace	Lo mismo, en una central o un bot: el operador (o el bot) se busca por nombre. Creá el usuario con ese nombre exacto y usá Reintentar.
sin asignado: el llamado no trae operador	La central no registró quién atendió. Ese llamado no se puede asignar.
falta el asignado (assignee_source_user_id en el ticket o en defaults del manifest)	Agregá el asignado al ticket o un defaults.assignee_source_user_id al manifiesto.
el asignado <id> no está en users	Todo usuario referenciado tiene que estar en la lista users del ticket.
el asignado <id> tiene rol <rol>: tiene que ser agent o admin	Cambiá el role del asignado en users.
el asignado <id> no tiene mail	El asignado necesita email para cruzarlo con el usuario del workspace.
falta el archivo <ruta>	El ticket referencia un archivo que no vino.
<ruta>: el archivo está vacío
<ruta>: pesa N bytes y la referencia dice M	Recalculá bytes sobre el archivo final.
<ruta>: el SHA-256 no coincide	Recalculá el resumen; si es un JSON, no lo reformatees después.
<ruta>: el contenido no es <tipo>	El archivo no es del tipo declarado en content_type.
<campo>: <detalle>	El JSON no cumple el contrato: un campo desconocido, una fecha sin zona, updated_at anterior a created_at, tags repetidos. Se listan hasta cinco errores por ticket. Ver Formato del ticket.
el ticket dice source_ticket_id X y el manifest Y	El id del JSON y el del manifiesto no coinciden.
<ruta>: la referencia no coincide con el manifest	bytes, sha256 o content_type difieren entre el ticket y el manifiesto.

En el formato CSV, además: faltan columnas obligatorias: …, el audio <nombre> no está en el ZIP, tipo de audio no admitido: <nombre> y direccion inválida: <valor> (entrante o saliente).

Motivos que rechazan la entrega entera

Aparecen como un único error sin id de ticket:

• el ZIP no tiene manifest.json ni tickets.csv, o el archivo no es un ZIP válido.
• manifest.json: … (el manifiesto no cumple el contrato) o manifest.json supera 10 MiB.
• faltan archivos listados en el manifest: … o archivos que no están en el manifest: ….
• <ruta>: el tamaño no coincide con el manifest o <ruta>: el SHA-256 no coincide con el manifest.
• el manifest dice delivery_id X y la entrega Y (escribiste otro Id de la entrega al subir).
• la entrega descomprimida supera … MB: dividila en varias.
• tickets.csv no se puede leer (…), tickets.csv no tiene filas o tickets.csv supera las 10.000 filas por entrega.

Al subir también podés recibir, antes de que la entrega exista: «el archivo no es un ZIP», «la entrega supera … MB: dividila en varias» y «ya hay una entrega con el id X: usá uno nuevo».

Reintentar

Las entregas de WebFlow e Inceptia (una por día) tienen el botón Reintentar. Vuelve a correr ese día contra el proveedor: lo que ya existía se actualiza, y lo que se había rechazado entra si ahora tiene usuario. Es el camino después de dar de alta a un operador que faltaba. No aparece mientras la entrega está Recibida o Procesando.

La carga masiva no se reintenta: subí otra entrega con un id nuevo y sólo con los tickets corregidos.

Cuando una entrega de la central o del bot termina con rechazos, los Admin del workspace reciben un aviso en la campana con el enlace a la conexión.

Repetidos

• API y carga masiva sólo crean. Un source_ticket_id ya importado por esa conexión no se toca: la API responde 409 (aunque el asignado ya no sea elegible) y la carga masiva lo cuenta en la columna Ya importados, sin marcarlo como error: una entrega con todos sus tickets ya importados termina Importada. Mandar un ticket dos veces nunca lo modifica ni lo duplica.
• La central y el bot actualizan. Correr dos veces el mismo día (la ingesta nocturna y un Reintentar) completa lo que faltaba en los tickets existentes: el audio que no se pudo bajar, la tipificación registrada. Tampoco se duplican.