«¿Podéis automatizar las facturas de proveedores?» Decid que sí.
Es la petición que os llega todos los meses, y a la que hasta ahora era difícil decir que sí. DocFlow lee y valida las facturas de proveedores de vuestros clientes y las entrega por la puerta que el ERP expone: vuestro endpoint con firma, un script SQL para la tabla de importación, o el archivo que su proceso ya consulta. El cliente sigue siendo vuestro.
Por qué ahora podéis decir que sí
Instalasteis el ERP y el cliente sigue pidiéndoos lo que el ERP no resuelve. Tres razones para decir que no, y qué cambia en cada una.
Sin escribir en la base de datos
Entregamos por la puerta que el ERP expone: vuestro endpoint, un script SQL para la tabla de importación, o un fichero. Numerar, calcular y asentar sigue siendo cosa del ERP.
Ver cómo encajaCon el alcance escrito en una página
Cinco preguntas al cliente antes de aceptar, la petición exacta mostrada antes de que haya código, y una clave de pruebas el mismo día.
Ver las cinco preguntasLo que no cuadra no entra
NIF con dígito de control, suma de líneas contra el total, duplicados, el QR de la factura. Lo que falla se detiene para revisión en vez de entrar mal.
Ver las garantíasCómo trabajamos con socios
Cuatro cosas que no cambian, sea cual sea el ERP.
- El cliente es vuestro. Quien habla con él, quien escribe la rutina y quien cobra la implantación sois vosotros. Nosotros nos quedamos con la lectura, las reglas y el soporte técnico a la integración.
- Los flujos se configuran con nosotros. Decidnos qué campos queréis, dónde y con qué reglas. Las peticiones de cambio se aplican normalmente el mismo día. No es autoservicio, y es a propósito.
- Se empieza en un entorno de pruebas. Clave propia y un buzón de correo dedicado, el mismo día. El contrato es el mismo que el de producción; al pasar, cambian las URL y la clave.
- Se paga por documento. Implantación a medida del proceso y después por documento procesado, sin licencias por usuario. Los tramos están en la página de precios.
La parte técnica
Lo que necesita saber quien va a conectar el sistema del cliente, por orden. Los ejemplos de petición y respuesta se abren al hacer clic.
Cómo encaja
Entramos antes del ERP y entregamos por la puerta que él expone, en vez de escribir en la base de datos por debajo. Un INSERT directo se salta la numeración, el stock, la contabilidad y los impuestos, y es la primera objeción que cualquier consultor plantea.
Enviáis
Un POST con el fichero, desde vuestra aplicación o desde el proceso que ya ejecutáis. PDF o imagen, hasta 25 MB. Si el usuario final prefiere reenviar un correo, hay un buzón dedicado que hace el mismo camino.
Leemos y comprobamos
Cabecera y líneas. Después las reglas: el NIF pasa el dígito de control, la suma de las líneas cuadra con el total, el duplicado se detecta. Lo que no cuadra se detiene para revisión humana en vez de entrar mal.
Entregamos
En vuestro endpoint, firmado. Y en paralelo donde haga falta: hoja de cálculo, archivo en SharePoint, script SQL. No hay que elegir uno solo.
Del botón al número
El caso de quien ya tiene aplicación propia: el usuario pulsa un botón que ya tenéis, y el documento aparece en el sistema del cliente con número asignado. No hay pantalla nuestra por medio.
Ver la petición y la respuesta
1. El botón envía
POST /ingest/<INBOX_ID>
{ "data": { "document_id": "a3f1…", "status": "queued",
"tracking_url": "https://app.docflow.pt/documents/a3f1…",
"routing": { "flow_id": "…", "strategy": "default_flow" } },
"error": null }2. Y pregunta cómo fue
GET /ingest/<INBOX_ID>/documents/a3f1…
{ "data": { "status": "delivered",
"client_metadata": { "encomenda": "ENC-2026-8842" },
"deliveries": [
{ "name": "Pedido API para o PHC", "status": "delivered",
"document_ref": "FT 2026/1187",
"document_url": "https://erp.cliente.pt/documentos/1187" } ] },
"error": null }El document_ref y el document_url son lo que devolvió vuestro sistema al recibir el documento. Vuelven aquí para que el botón pueda mostrar el número con el que quedó, en vez de solo «enviado». Aceptamos las claves más comunes (id, numero, obrano, stamp), en la raíz de la respuesta o dentro de data.
Si preferís no preguntar, llamamos a una dirección vuestra en cada cambio de estado, también cuando el documento se detiene para revisión. Se activa en vuestra conexión de envío, de nuestro lado y el mismo día: los avisos van a la misma dirección que recibe los documentos, o a otra que nos indiquéis, con la misma firma.
Estados del documento: received, extracting, extracted, pending_approval, approved, delivering, delivered. Y además failed, rejected y needs_routing. El final feliz es delivered con todas las entregas entregadas.
Ver la referencia ir y volver
Este es el detalle que separa una integración de un depósito de ficheros. En el envío mandáis lo que os identifica el proceso:
curl -X POST "https://api.docflow.pt/ingest/<INBOX_ID>" \
-H "Authorization: Bearer dfl_live_…" \
-H "Idempotency-Key: $(uuidgen)" \
-F "file=@fatura.pdf;type=application/pdf" \
-F 'metadata={"encomenda":"ENC-2026-8842","operador":"amaral"}'Ese campo queda accesible en el mapeo del destino como _meta.encomenda, y sale en lo que entregamos:
{ "adoc": "FT 2026/1187", "ncont": "501234567",
"etotaldeb": 475.89, "encomenda": "ENC-2026-8842" }Y vuelve en la consulta de estado, tal cual, para que no tengáis que mantener una tabla de correspondencia de vuestro lado. No hay lista de nombres reconocidos: _meta. seguido de la clave que enviéis.
Sin esto, la factura llega a vuestro sistema sin vínculo con el proceso que la originó, y alguien tiene que casarla a mano al otro lado. Que es exactamente el trabajo que esto existe para quitar.
Garantías
Lo que la integración cumple, con los números escritos.
No duplica en los reintentos
Una cabecera de idempotencia vuestra por envío. Repetir la petición devuelve la respuesta original en vez de crear un documento nuevo. Como segunda línea, el mismo fichero enviado dos veces se detiene para revisión.
Vuestro proceso pregunta si ya está
Un GET devuelve el estado y cada entrega. Pidiendo el payload, devuelve también los datos mapeados que fueron a cada destino. Nadie necesita abrir una pantalla para saber el resultado.
O no pregunta, y os avisamos
Como alternativa a la consulta, llamamos a un endpoint vuestro en cada cambio de estado, con firma HMAC-SHA256 y reintentos automáticos.
La entrega va firmada
La petición lleva el identificador del documento y el de la entrega, para que dedupliquéis de vuestro lado, y firma opcional para que verifiquéis que viene de nosotros.
Los errores dicen de quién es la culpa
Todas las respuestas traen el mismo envoltorio, incluidas las de error, con código propio. Si recibís HTML en su lugar, vino de la capa de red delante de la API y no de nosotros.
Los límites están escritos
60 peticiones por minuto y 1000 al día en el envío; 240 y 20.000 en la consulta, contados aparte. El 429 trae el tiempo de espera y la ventana.
Las cinco preguntas al cliente
Se hacen antes de aceptar, y deciden si el proyecto es de dos semanas o de dos meses. Valen para cualquier herramienta.
- ¿El ERP expone un servicio web de entrada de documentos, o cuál es el camino soportado? Nunca la tabla final.
- ¿Qué campos son obligatorios para que el asiento pase, y cuáles no vienen en el papel?
- ¿Hay tabla de correspondencia entre las referencias del proveedor y las del cliente?
- ¿Dónde vive el documento digitalizado?
- ¿Quién revisa lo dudoso, y en cuánto tiempo?
Con las cinco respondidas, el resto es cosa nuestra: el mapeo, las reglas, el entorno de pruebas. El artículo con las preguntas completas (en portugués).
Preguntas de quien integra
¿En qué ERP entra esto?
En cualquiera: el conector se hace a medida del ERP del cliente, con vosotros. La entrega es una petición HTTP a vuestro endpoint, un script SQL, o un fichero, y cuando el ERP tiene una API propia escribimos y mantenemos la conexión con esa API. Por eso esta página habla de endpoint y no de una lista de ERP: quien conoce el sistema del cliente sois vosotros, y nosotros entregamos en el formato que acepta.
¿Qué se puede mapear sin escribir código?
Cualquier campo del documento a cualquier nombre que vuestro sistema espere, consulta a las tablas de referencia del cliente (artículos, proveedores, cuentas) con recuperación de erratas confirmada por un segundo campo, y numeración de las líneas siguiendo la convención del ERP. Cálculos y condiciones, no: esos quedan de vuestro lado o del nuestro, en la configuración.
¿Podemos probar el encaje antes de que haya endpoint?
Sí, y es el camino que recomendamos. Hay un destino que construye la petición y la muestra sin enviarla, y otro que genera el script SQL. Se ve el cuerpo exacto que saldría, con los campos ya mapeados, antes de que exista código de vuestro lado.
¿Qué es lo que no hacemos?
- No es autoservicio La clave la emitimos nosotros y se entrega una vez. No hay un portal donde la gestionéis, ni donde creéis entornos por vuestra cuenta.
-
Hay una guía de integración, entregada con la clave. Es
multipart/form-dataa la entrada y JSON a la salida, así que cualquier lenguaje llega con lo que ya tiene. - Vuestra cuenta es operativa Los documentos de vuestra organización, aprobación y reprocesado, recuentos y tiempos, y la vista de los flujos configurados.
La próxima vez que un cliente lo pida, decid que sí.
Decidnos qué sistema habéis instalado. Una conversación de veinte minutos basta para saber si encaja, y salís de ella con un entorno de pruebas y una clave.
Hablemos