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

Integración de Boolfy Agents con facturas, órdenes de compra y recepciones de mercadería (3WM)

Detallamos los principales puntos a tener en cuenta para la integración de Boolfy Agents con un ERP para la imputación de facturas de compra asociadas a órdenes de compra y recepciones

Integración Boolfy Agents con el ERP de un tercero

Este flujo corresponde a un esquema 3WM: Three Way Match, donde se valida la consistencia entre:

  1. La factura del proveedor.

  2. La orden de compra.

  3. La recepción de mercadería, remito, parte de entrada o conformidad de servicio.


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 y recepciones de mercadería o servicios.


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, remitos, partes de entrada de mercadería, recepciones y/o conformidades de servicio.

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.

En un flujo 3WM, Boolfy debe poder comparar la información de la factura contra la orden de compra y contra las cantidades efectivamente recibidas o conformadas. Esto permite validar precios, cantidades, impuestos, proveedor, moneda, imputaciones contables y cantidades pendientes de facturar.

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, remitos, partes de entrada, recepciones y líneas asociadas.

  3. Boolfy consulta el ERP para validar la información contra proveedores, órdenes de compra, líneas de orden de compra, recepciones, remitos, partes de entrada, impuestos, dimensiones y cuentas contables.

  4. Boolfy realiza la validación 3WM:

    • Valida que la factura corresponda al proveedor de la orden de compra.

    • Valida que los precios facturados coincidan con los precios de la orden de compra, considerando tolerancias si aplican.

    • Valida que las cantidades facturadas no excedan las cantidades ordenadas.

    • Valida que las cantidades facturadas no excedan las cantidades recibidas o conformadas.

    • Valida que las líneas de factura puedan asociarse a líneas de orden de compra y recepciones correspondientes.

    • Valida impuestos, percepciones, moneda, dimensiones e imputaciones contables.

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

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

  7. En caso de diferencias, Boolfy podrá informar el motivo del rechazo, dejar el documento pendiente de revisión o permitir su reproceso según las reglas acordadas.


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.

  • Asociación entre líneas de factura y recepciones, remitos, partes de entrada o conformidades de servicio.

  • Cantidad facturada por línea.

  • Precio unitario facturado por línea.

  • Cantidad recibida o conformada por línea.

  • Cantidad pendiente de facturar, si aplica.

  • 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.

  • Diferencias detectadas, si el ERP realiza validaciones adicionales.

  • 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.

  • Código interno de proveedor.

  • Estado de la orden de compra.

  • Periodo / fecha.

  • Sociedad / legal entity / business unit.

  • Moneda.

Información esperada como respuesta:

  • Cabecera de la orden de compra.

  • Proveedor asociado.

  • Estado de la orden.

  • Moneda.

  • Condición de pago.

  • Líneas de la orden de compra.

  • Código de artículo, servicio o concepto.

  • Descripción de cada línea.

  • Cantidad ordenada.

  • Cantidad recibida.

  • Cantidad facturada.

  • Cantidad pendiente de recibir.

  • Cantidad pendiente de facturar.

  • Importe unitario.

  • Importe total de la línea.

  • Importe pendiente.

  • Unidad de medida.

  • Impuestos asociados.

  • Dimensiones financieras.

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

  • Recepciones, remitos, partes de entrada o conformidades vinculadas.

  • Tolerancias permitidas por precio, cantidad o importe, si aplican.

  • Indicador de si la línea requiere recepción obligatoria antes de facturar.

Objetivo:

Permitir que Boolfy pueda validar que la factura se corresponda con una orden de compra válida y que los precios, cantidades, importes e imputaciones sean consistentes con lo registrado en el ERP.


3.3 API de consulta de recepciones, remitos, partes de entrada o conformidades de servicio

Se requiere una API para consultar las recepciones de mercadería, remitos, partes de entrada, goods receipts, service entry sheets o conformidades de servicio registradas en el ERP.

Criterios posibles de búsqueda:

  • Número de orden de compra.

  • Número de remito.

  • Número de recepción.

  • Número de parte de entrada de mercadería.

  • Número de conformidad de servicio.

  • CUIT / identificación fiscal del proveedor.

  • Código interno de proveedor.

  • Fecha de recepción.

  • Estado de la recepción.

  • Sociedad / legal entity / business unit.

  • Código de artículo, servicio o concepto.

Información esperada como respuesta:

  • Identificador interno de la recepción, remito, parte de entrada o conformidad.

  • Número externo del remito o comprobante de entrega, si existe.

  • Número interno del ERP.

  • Orden de compra asociada.

  • Proveedor asociado.

  • Fecha de recepción.

  • Estado de la recepción.

  • Líneas recibidas o conformadas.

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

  • Código de artículo, servicio o concepto.

  • Descripción.

  • Unidad de medida.

  • Cantidad recibida o conformada.

  • Cantidad ya facturada.

  • Cantidad pendiente de facturar.

  • Cantidad rechazada, devuelta o anulada, si aplica.

  • Precio de referencia de la orden de compra.

  • Moneda.

  • Almacén, depósito o ubicación, si aplica.

  • Usuario o área que realizó la recepción, si aplica.

  • Documentos adjuntos o referencias asociadas, si aplica.

Objetivo:

Permitir que Boolfy pueda validar que las cantidades facturadas por el proveedor no excedan las cantidades efectivamente recibidas o conformadas en el ERP.


3.4 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.

  • Código interno de proveedor.

  • Razón social.

  • Sociedad / legal entity / business unit.

Información esperada como respuesta:

  • Código interno de proveedor.

  • Razón social.

  • CUIT / identificación fiscal.

  • Estado del proveedor.

  • Sociedad o entidades legales habilitadas.

  • Condición fiscal.

  • Moneda habitual, si aplica.

  • Condición de pago.

  • Indicador de bloqueo de pago o bloqueo de carga, si aplica.

Objetivo:

Validar que el proveedor identificado en la factura exista en el ERP, esté activo y coincida con el proveedor asociado a la orden de compra y a las recepciones correspondientes.


3.5 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.

  • Reglas de aplicación por sociedad, proveedor, provincia o tipo de comprobante.

  • Mapeos entre conceptos fiscales del comprobante y códigos internos del 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.6 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.

  • Relación entre recepción, almacén, centro de costo y cuenta contable, si aplica.

Objetivo:

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


3.7 API de consulta de tolerancias y reglas de matching

Se recomienda contar con una API, catálogo o documentación funcional que permita conocer las reglas aplicables al proceso 3WM.

Información requerida:

  • Tolerancia por diferencia de precio.

  • Tolerancia por diferencia de cantidad.

  • Tolerancia por diferencia de importe total.

  • Tolerancia por moneda o tipo de cambio.

  • Reglas por proveedor.

  • Reglas por sociedad.

  • Reglas por tipo de artículo o servicio.

  • Reglas por categoría de compra.

  • Reglas para facturación parcial.

  • Reglas para sobrefacturación.

  • Reglas para diferencias entre factura, orden de compra y recepción.

  • Reglas de aprobación manual cuando existan diferencias.

Objetivo:

Permitir que Boolfy pueda aplicar validaciones consistentes con las reglas de negocio del ERP antes de intentar registrar la factura.


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 para adjuntar remitos, partes de entrada o documentación adicional, si aplica.

  • Mecanismo de trazabilidad entre Boolfy y el ERP.

  • Campo o identificador externo para evitar duplicidad de facturas.

  • Campo o identificador externo para relacionar factura, orden de compra y recepción.

  • Criterios para reprocesar documentos con error.

  • Criterios para registrar facturas con diferencias dentro de tolerancia.

  • Criterios para rechazar o dejar pendiente facturas con diferencias fuera de tolerancia.

  • Mecanismo para consultar el estado posterior de una factura enviada al ERP.

  • Mecanismo de auditoría para conocer qué validaciones fueron aplicadas.


5. Validaciones funcionales esperadas

Se propone validar los siguientes escenarios:

  • Factura con orden de compra válida y recepción suficiente.

  • Factura con orden de compra válida pero sin recepción registrada.

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

  • Factura con orden de compra inexistente.

  • Factura con remito o parte de entrada inexistente.

  • Factura con recepción registrada para otro proveedor.

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

  • Factura con diferencias de precio unitario respecto de la orden de compra.

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

  • Factura con cantidad facturada superior a la cantidad recibida.

  • Factura con cantidad facturada superior a la cantidad pendiente de facturar.

  • Factura con recepción parcial.

  • Factura con múltiples recepciones asociadas a una misma orden de compra.

  • Factura con múltiples órdenes de compra.

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

  • Factura con líneas que no pueden asociarse automáticamente a la orden de compra.

  • Factura con diferencias de unidad de medida.

  • Factura con impuestos o percepciones no mapeadas.

  • Factura con proveedor no encontrado.

  • Factura duplicada.

  • Factura con múltiples impuestos o percepciones.

  • Factura con dimensiones financieras obligatorias.

  • Factura rechazada por validaciones del ERP.

  • Factura dentro de tolerancia permitida.

  • Factura fuera de tolerancia permitida.

  • Nota de crédito asociada a factura, orden de compra o recepción previa.

  • Recepción anulada, revertida o devuelta.

  • Orden de compra cerrada, bloqueada o sin saldo pendiente.


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 recepciones, remitos, partes de entrada, goods receipts o conformidades de servicio.

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

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

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

  7. Documentación funcional de reglas de 3WM.

  8. Reglas de tolerancia por precio, cantidad e importe.

  9. Ejemplos de requests y responses.

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

  11. Reglas funcionales para el ingreso de facturas con orden de compra y recepción.

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

  13. Criterios para facturación parcial.

  14. Criterios para diferencias entre factura, orden de compra y recepción.

  15. Criterios para registrar, rechazar o dejar pendiente una factura con diferencias.

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

  17. Contacto funcional responsable del proceso de compras, recepción y cuentas a pagar.


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á el criterio funcional de matching 3WM.

  4. Se relevarán las reglas de tolerancia aplicables.

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

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

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

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

  9. Se validarán casos de facturación parcial, múltiples recepciones y diferencias de precio o cantidad.

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

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

  12. Se documentará el circuito operativo para documentos rechazados, pendientes o reprocesados.


8. Consideraciones adicionales para 3WM

Para asegurar una integración robusta, se recomienda definir de forma explícita los siguientes criterios:

  • Qué documento será considerado como recepción válida: remito, parte de entrada de mercadería, goods receipt, conformidad de servicio u otro.

  • Si la factura puede ingresarse antes de la recepción o si la recepción es obligatoria.

  • Cómo se manejarán recepciones parciales.

  • Cómo se manejarán facturas parciales.

  • Cómo se manejarán múltiples remitos para una misma factura.

  • Cómo se manejarán múltiples facturas para una misma orden de compra.

  • Cómo se manejarán diferencias de unidad de medida entre orden de compra, recepción y factura.

  • Cómo se manejarán diferencias de precio dentro y fuera de tolerancia.

  • Cómo se manejarán diferencias de cantidad dentro y fuera de tolerancia.

  • Cómo se manejarán devoluciones, anulaciones o reversas de recepción.

  • Cómo se manejarán líneas de servicios sin stock físico.

  • Cómo se manejarán cargos adicionales, fletes, bonificaciones, descuentos u otros conceptos no presentes en la orden de compra.

  • Qué información debe quedar auditada para justificar la validación realizada por Boolfy.

Última actualización