For the complete documentation index, see llms.txt. This page is also available as Markdown.

Integración de Boolfy Agents con facturas y órdenes de compra (2WM)

Detallamos los principales puntos a tener en cuenta para la interación de Boolfy Agents con un ERP para la imputación de Facturas de compra con Órdenes de compra sin stock (2WM: Two way match).

Integración Boolfy Agents con el ERP de un tercero

Objetivo del documento: Definir el alcance técnico y funcional para integrar Boolfy Agents con el ERP de un tercero, con foco en la lectura automática de comprobantes de compra asociados a órdenes de compra.


1. Contexto general

Boolfy Agents permite leer, interpretar y estructurar información de comprobantes de compra, incluyendo facturas que hacen referencia a órdenes de compra. El objetivo de la integración es automatizar el ingreso de estos comprobantes al ERP, reduciendo la carga manual y permitiendo validar la información contra los datos maestros y transaccionales del ERP.

Para avanzar con la integración, se requiere que el equipo responsable del ERP disponibilice APIs o mecanismos equivalentes de consulta e ingreso de información.


2. Flujo esperado de integración

El flujo funcional propuesto es el siguiente:

  1. Boolfy Agents recibe y procesa comprobantes de compra. Estos pueden llegar por email, api y/o ser cargados manualmente.

  2. El sistema identifica datos relevantes del comprobante, tales como proveedor, CUIT / identificación fiscal, número de factura, fechas, importes, impuestos, percepciones, moneda, orden de compra y líneas asociadas.

  3. Boolfy consulta el ERP para validar la información contra órdenes de compra, proveedores, impuestos, dimensiones y cuentas contables.

  4. Una vez validada la información, Boolfy envía la factura estructurada al ERP para su ingreso.

  5. El ERP devuelve el resultado del proceso, incluyendo identificadores internos, estado de creación, errores de validación o mensajes de negocio.


3. APIs requeridas

3.1 API de ingreso de facturas de compra

Se requiere una API que permita registrar facturas de proveedores en el ERP.

Información esperada a enviar:

  • Datos de cabecera de la factura.

  • Proveedor.

  • Número de comprobante.

  • Tipo de comprobante.

  • Fecha de emisión.

  • Fecha contable.

  • Fecha de vencimiento, si aplica.

  • Moneda.

  • Importes netos, impuestos, percepciones, descuentos y total.

  • Orden de compra asociada.

  • Líneas de factura.

  • Asociación entre líneas de factura y líneas de orden de compra.

  • Impuestos y códigos fiscales aplicables.

  • Dimensiones financieras, centros de costo o cuentas contables, si corresponden.

  • Adjuntos del comprobante, si el proceso lo requiere.

  • Identificador externo o clave de idempotencia para evitar ingresos duplicados.

Respuesta esperada:

  • Identificador interno de la factura creada.

  • Estado del proceso.

  • Mensajes de validación.

  • Errores funcionales o técnicos, si existieran.

  • Referencia para consultar posteriormente el estado del documento.


3.2 API de consulta de órdenes de compra

Se requiere una API para consultar órdenes de compra existentes en el ERP.

Criterios posibles de búsqueda:

  • Número de orden de compra.

  • CUIT / identificación fiscal del proveedor.

  • Estado de la orden de compra.

  • Periodo / Fecha.

Información esperada como respuesta:

  • Cabecera de la orden de compra.

  • Proveedor asociado.

  • Estado de la orden.

  • Moneda.

  • Condición de pago.

  • Importe unitario.

  • Importe pendiente.

  • Impuestos asociados.

  • Dimensiones financieras.

  • Centro de costo, cuenta contable o imputación asociada.

  • Recepciones vinculadas, si corresponde.


3.3 API de consulta de proveedores

Se requiere una API para consultar y validar proveedores registrados en el ERP.

Criterios posibles de búsqueda:

  • CUIT / identificación fiscal.

Información esperada como respuesta:

  • Código interno de proveedor.

  • Razón social.

  • Estado del proveedor.


3.4 API de consulta de impuestos, percepciones y datos de localización

Se requiere una API o mecanismo de consulta para validar impuestos, percepciones y reglas fiscales aplicables.

Información requerida:

  • Códigos de IVA.

  • Códigos de percepciones.

  • Códigos de retenciones, si aplica.

  • Provincias y/o Jurisdicciones.

  • Códigos de impuestos utilizados por el ERP.

Objetivo:

Permitir que Boolfy pueda mapear correctamente los impuestos y percepciones identificados en los comprobantes contra los códigos válidos del ERP.


3.5 API de consulta de dimensiones, cuentas contables y centros de costos

Se requiere una API para consultar y validar estructuras contables y dimensiones financieras utilizadas en el ERP.

Información requerida:

  • Sociedades / legal entities / business units.

  • Plan de cuentas.

  • Cuentas contables habilitadas.

  • Centros de costo.

  • Dimensiones financieras.

  • Unidades de negocio.

  • Departamentos.

  • Proyectos, si aplica.

  • Combinaciones válidas de dimensiones.

  • Reglas de imputación contable.

  • Relación entre orden de compra, cuenta contable y dimensiones.

Objetivo:

Validar que la información enviada por Boolfy sea consistente con la estructura contable definida en el ERP.


4. Aspectos técnicos a definir

Durante la reunión se deberán relevar los siguientes puntos técnicos:

  • Tipo de autenticación requerido.

  • Ambientes disponibles: desarrollo, testing / UAT y producción.

  • Documentación técnica de las APIs.

  • Formato de intercambio: JSON, XML u otro.

  • Mecanismo de autorización por sociedad o entidad legal.

  • Paginación y filtros disponibles en APIs de consulta.

  • Límites de uso, rate limits o restricciones de volumen.

  • Manejo de errores técnicos y errores de negocio.

  • Tiempos esperados de respuesta.

  • Mecanismo para adjuntar el PDF o imagen del comprobante.

  • Mecanismo de trazabilidad entre Boolfy y el ERP.

  • Campo o identificador externo para evitar duplicidad de facturas.

  • Criterios para reprocesar documentos con error.


5. Validaciones funcionales esperadas

Se propone validar los siguientes escenarios:

  • Factura con orden de compra válida.

  • Factura con proveedor válido pero sin orden de compra.

  • Factura con orden de compra inexistente.

  • Factura con diferencias de importe respecto de la orden de compra.

  • Factura con diferencias de cantidad respecto de la orden de compra.

  • Factura con impuestos o percepciones no mapeadas.

  • Factura con proveedor no encontrado.

  • Factura duplicada.

  • Factura con múltiples líneas de orden de compra.

  • Factura con múltiples impuestos o percepciones.

  • Factura con dimensiones financieras obligatorias.

  • Factura rechazada por validaciones del ERP.


6. Información requerida al equipo del ERP

Para avanzar con el análisis técnico, se solicita al equipo del ERP compartir:

  1. Documentación de APIs disponibles para ingreso de facturas de proveedor.

  2. Documentación de APIs para consulta de órdenes de compra.

  3. Documentación de APIs para consulta de proveedores.

  4. Documentación de APIs o catálogos para impuestos, percepciones y localizaciones.

  5. Documentación de APIs o catálogos para dimensiones financieras, cuentas contables y centros de costo.

  6. Ejemplos de requests y responses.

  7. Credenciales o mecanismo de acceso al ambiente de testing.

  8. Reglas funcionales para el ingreso de facturas con orden de compra.

  9. Criterios de validación obligatorios antes de registrar una factura.

  10. Contacto técnico responsable de la integración.


7. Próximos pasos propuestos

  1. El equipo del ERP compartirá la documentación técnica disponible.

  2. Boolfy analizará los endpoints y definirá el mapeo inicial de datos.

  3. Se acordará un set de casos de prueba representativos.

  4. Se habilitará un ambiente de testing con credenciales de integración.

  5. Boolfy realizará pruebas de consulta de proveedores, órdenes de compra, impuestos y dimensiones.

  6. Se probará el ingreso de facturas de compra en el ERP.

  7. Se revisarán errores, validaciones y ajustes necesarios.

  8. Se definirá el flujo definitivo para puesta en producción.


Última actualización