De documento a dato
en tu programa.
Al instante.

No. El sistema no trabaja con plantillas por proveedor: interpreta el documento entendiendo qué es cada campo, aunque el diseño cambie. Esa es la diferencia práctica con el OCR clásico, que exigía declarar en qué coordenada de la hoja estaba el número de factura y dejaba de funcionar el día que el proveedor cambiaba el logo o movía una tabla. No hay una configuración inicial por cada emisor ni una lista de formatos admitidos que haya que ir ampliando. Lo que sí se hace en la puesta en marcha es afinar con documentos reales vuestros (vuestros proveedores, vuestros partes) en lugar de con ejemplos genéricos.

Sí: los partes rellenados a mano se leen y se convierten en datos, no en una foto guardada. De un parte manuscrito se extraen el equipo o el cliente, la descripción del trabajo, el operario, la fecha, las horas y los materiales, y entran en el sistema como campos consultables. La calidad depende de lo legible que sea la letra y de que la foto esté enfocada y completa, igual que le pasaría a una persona; lo que no hace falta es que el parte tenga un formato especial ni casillas preimpresas. Es lo que permite digitalizar sin pedirle al operario que cambie su forma de trabajar.

Facturas de proveedor, partes de trabajo, albaranes, packing lists y partes de mantenimiento; en papel, en PDF o en foto hecha con el móvil. De cada tipo se extraen los campos que tienen sentido: de una factura, el NIF, el número, la fecha, la base, el IVA y las líneas; de un albarán, los artículos, las cantidades recibidas y el cruce con el pedido; de un parte, las horas y los materiales. Cada circuito está explicado en contabilizar facturas automáticamente, digitalización de albaranes y OCR de partes de trabajo. Si vuestro documento no está en esa lista, la pregunta no es si se puede leer, sino a qué campos hay que llevarlo.

Se integra: el OCR no es un programa aparte al que haya que entrar, es la puerta de entrada de los datos al que ya usáis. Con los programas que tienen API el dato entra directo; con los que no, por intercambio de ficheros en el formato que admitan. Lo que se decide en la puesta en marcha no es qué programa usar, sino qué campos van a qué sitio y qué pasa cuando algo no cuadra (una factura duplicada, un albarán sin pedido), porque de eso depende que nadie tenga que revisarlo todo a mano después. El detalle de cada conexión está en integraciones.

En servidores propios de Vertebra, en España y dentro de la Unión Europea. Los documentos no se suben a una plataforma de terceros ni pasan por un servicio de OCR público: entran en vuestro sistema y ahí se quedan, y los ve quien vosotros autoricéis, con los permisos que se definen en la puesta en marcha. La otra mitad de la pregunta es la que de verdad importa cuando los documentos son de terceros (las facturas de los clientes de una asesoría, por ejemplo) y tiene una respuesta corta: no. Vuestros documentos no se usan para entrenar ningún modelo. Se procesan para extraer los datos y nada más; no alimentan un sistema que luego rinda mejor con otro cliente. El plazo de conservación no lo fijamos nosotros por defecto: se acuerda con vosotros en el contrato de encargo de tratamiento, que es donde toca fijarlo.

Sí, pero solo con los tipos de documento ya desarrollados: facturas de proveedor, albaranes, partes de trabajo y partes de mantenimiento se prueban con documentos reales vuestros y sin coste. Si vuestro documento es de un tipo que no se ha hecho todavía, eso no entra en la prueba: es un desarrollo aparte que se presupuesta, porque hay que definir qué campos se extraen y a dónde van. La prueba se hace sobre vuestros documentos en una demo, no registrándose en una web. Herramientas gratuitas que leen una factura suelta y devuelven el texto existen; lo que no hacen es llevar el dato a tu programa, cuadrarlo con un pedido ni avisar de un duplicado.