Sincronización y modo offline

APP y POS conservan sus pendientes en el almacenamiento local de cada aplicación. Cuando hay conexión y una sesión autorizada, el cliente envía operaciones a SIVA BACK. No se requiere que ambos proyectos compartan el mismo modelo local.

Envoltorio de una operación

Cada elemento enviado incluye:

• organizationId, applicationId y deviceId para delimitar el ámbito.
• operationId único para identificar el reintento.
• collection, recordId y schemaVersion para identificar el registro y la forma de su carga.
• expectedRevision para detectar escrituras basadas en una versión antigua.
• action (upsert o delete) y payload JSON cuando corresponda.

La identidad del actor se deriva de la sesión, no de un campo confiado al cliente. La ruta acepta lotes de hasta 50 operaciones. El backend guarda de manera atómica el registro, la decisión idempotente y la entrada del feed de cambios.

Repetir el mismo operationId con el mismo contenido devuelve la decisión guardada. Reutilizarlo con contenido distinto produce un conflicto. La lectura incremental usa un cursor firmado y ligado a la organización, aplicación, dispositivo y ubicación de almacenamiento.

Colecciones de los clientes

Aplicación	Colección actual	Significado
SIVA APP	draft.catalog-item	Borrador flexible de artículo de catálogo; no es todavía el catálogo canónico de producción.
SIVA POS	demo.sale-intent	Intención de venta de demostración; no es una venta aceptada, un pago ni un cierre.

Las colecciones y las cargas son específicas de cada aplicación. BACK valida la envoltura y el ámbito, pero no interpreta la semántica comercial de esos documentos.

Estados y conflictos

• accepted confirma que el registro flexible se almacenó en BACK; no confirma una operación comercial.
• conflict indica que debe consultarse el estado remoto y resolverse en el cliente antes de enviar una nueva revisión.
• Un error de red o 503 se puede reintentar conservando el mismo operationId.
• Un cursor rechazado por cambio de ubicación debe descartarse y la lectura debe reiniciarse desde el cursor inicial.

Las escrituras offline se quedan en la cola local hasta que el backend confirme el resultado. Para sincronizar se necesita conectividad, una sesión vigente, membresía activa y un dispositivo autorizado.