# Guía de desarrollo

API (v1.0.1)

## Introducción

Boolfy Agents comparte su API pública para clientes, la cual permite integrarse fácilmente con plataformas de terceros mediante la carga de documentos y su posterior devolución de los datos estructurados e imágenes obtenidas a partir de su procesamiento. La documentación de la API es la misma para todos los países.

{% hint style="info" %}
**Solicita una demo:** Para solicitar una demo o saber más acerca de nosotros escribinos en nuestro [formulario de contacto](https://boolfy.com/es/#contact).
{% endhint %}

## Acerca de Boolfy Agents

Boolfy Agents es una plataforma que integra en una misma solución procesos en lenguaje natural, inteligencia artificial y automatización de flujos de trabajo. Conectamos el negocio de tu empresa a nuestros agentes y flujos de trabajo de forma transparente, segura y ciento por ciento adaptable a las necesidades del negocio. 

Somos la solución para procesar grandes cantidades de documentos 7x24x365 de forma automática y eficiente, logrando resultados desde el primer día.


# Descripción general de las APIs

Todas las API están disponibles a través de endpoint REST y aceptan JSON como el tipo de contenido para las solicitudes y las respuestas correspondientes.

## Autenticación

Boolfy utiliza claves API para autenticar las solicitudes. Puedes ver y administrar tus claves desde API Keys en el administrador de Boolfy.

Tus claves API conllevan muchos privilegios, así que asegúrate de mantenerlas seguras. No compartas tus claves API secretas en áreas de acceso público, como GitHub, código del lado del cliente, etc.

Todas las solicitudes de API deben realizarse a través de HTTPS. Las llamadas realizadas a través de HTTP simple fallarán. Las solicitudes de API sin autenticación también fallarán.

Aquí hay un ejemplo de una invocación genérica de cURL, con la carga contenida en `payload.json`:

```
curl "https://agents.boolfy.com/api/documents/$method" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

## Boolfy Bearer Key <a href="#h3-5" id="h3-5"></a>

La autenticación Bearer de Boolfy utiliza una cadena que es el resultado de la siguiente concatenación:

```
Boolfy_Bearer_Key = Enterprise Id + "_" + Key + "_" + Private Key
//Por ej: 2_25874125_454gdf-rge24ger-erg5er4-rs2s2
```

## Api Keys <a href="#h3-5" id="h3-5"></a>

Dentro de Boolfy Document Assistant podrás crear o te proporcionaran las credenciales de acceso de la Api Key.&#x20;

<figure><img src="https://143018119-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkM1sjIIYYl6C0d7jcyPF%2Fuploads%2Fhwxd3Ab5JyOys8w26NGP%2FAPI.png?alt=media&amp;token=a710f112-5e1b-4da0-bfc9-b796b979902e" alt=""><figcaption><p>Datos de la Api Key</p></figcaption></figure>

A continuación detallamos los principales datos de la Api key

<table><thead><tr><th width="201">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Enterprise</td><td>Especifica la empresa a la cual pertenece el Api Key</td></tr><tr><td>Name</td><td>Especifica el nombre de la Api Key. Este nombre lo podrás utilizar en WorkFlows.</td></tr><tr><td>Key</td><td>Especifica la clave pública de acceso</td></tr><tr><td>Private Key</td><td>Especifica la clave privada de acceso</td></tr></tbody></table>

## Solicitudes <a href="#h3-5" id="h3-5"></a>

Cualquier solicitud debe tener su tipo de contenido establecido en `application/json` y el payload debe enviarse en el cuerpo de la solicitud.

La estructura genérica para el endpoint de API es: `https://agents.boolfy.com/api/<api>/<method>`

Por ejemplo, el endpoint para subir documentos es: `https://agents.boolfy.com/api/documents/upload`

## APIs disponibles <a href="#h3-5" id="h3-5"></a>

Echa un vistazo a las API disponibles actualmente:

<table><thead><tr><th width="532">API</th><th>Path</th></tr></thead><tbody><tr><td><a href="/documents"><strong>Documents</strong></a> Permite gestionar documentos</td><td>documents</td></tr><tr><td><a href="/suppliers"><strong>Suppliers</strong></a> Permite obtener los datos de los proveedores</td><td>suppliers</td></tr><tr><td><a href="/tables"><strong>Tables</strong></a> Permite obtener los datos de conexto que existen en la plataforma.</td><td>tables</td></tr></tbody></table>

## Respuestas <a href="#h3-5" id="h3-5"></a>

Las respuestas, cuando están presentes, se envían en formato JSON (tipo de contenido `application/json`).

El formato de respuesta general de todas las APIs es el siguiente:

```json
{
    "code": 200,
    "msg": "mensaje variable"
    "response": "contenido variable"
}
```

## Códigos de respuesta

A continuación detallamos los códigos de respuesta posibles para cada solicutd.

<table><thead><tr><th width="152" data-type="number">Code</th><th width="229">Nombre</th><th>Significado</th></tr></thead><tbody><tr><td>200</td><td>Ok</td><td>Operación realizada exitosamente</td></tr><tr><td>400</td><td>Bad request</td><td>Solicitud con formato incorrecto</td></tr><tr><td>402</td><td>Authentication failed</td><td>ApiKey inválida o no provista</td></tr><tr><td>403</td><td>Method not found</td><td>El método no existe o no es válido</td></tr><tr><td>404</td><td>Not found</td><td>El registro solicitado no existe</td></tr><tr><td>500</td><td>Internal server error</td><td>Error del servidor durante el procesamiento</td></tr></tbody></table>

## Estados de revisión

Los documentos, entre otros, pueden tener los siguientes estados.

<table><thead><tr><th width="168">Valor</th><th>Descripción</th></tr></thead><tbody><tr><td>Draft</td><td>Borrador. Es el estado inicial del documento</td></tr><tr><td>Revised</td><td>Revisado. Opcional. Representa que se ha realizado la revisión del documento</td></tr><tr><td>Rejected</td><td>Rechazado. Opcional. Representa que se ha rechazado el documento</td></tr><tr><td>Approved</td><td>Aprobado. Opcional. Representa que se ha aprobado el documento</td></tr></tbody></table>

## Estados del proceso

El procesamiento del documento puede tener los siguientes estados.

<table><thead><tr><th width="170">Valor</th><th>Descripción</th></tr></thead><tbody><tr><td>Joined</td><td>Ingresado. Es el estado inicial del documento cuando ingresa Boolfy.</td></tr><tr><td>Processing</td><td>Procesando. Es cuando se esta analizando y procesando el documento.</td></tr><tr><td>Excluded</td><td>Excluido. Se establece cuando existen errores de formato en el documento.</td></tr><tr><td>Finished</td><td>Finalizado. Se establece cuando se termina de procesar el documento.</td></tr><tr><td>Sended</td><td><p>Enviado. Se establece en forma automática cuando se invoca al método <a href="/documents/getinfo">GetInfo </a>o <a href="/documents/list">List</a> y  el documento se encuentra entre estos registros. También se establece de forma automática cuando se realiza una descarga desde la plataforma en formato: JSON, CSV o XML y cuando se realiza una descarga por aplicación. Una vez establecido el documento en Sended, no puede cambiarse.</p><p><strong>Nota:</strong> La asignación automática del estado Sended facilita el método de sincronización con terceros. Idealmente se puede consumir el método <a href="/documents/list">List</a> sin filtro por estado, para obtener los documentos que faltan sincronizar.</p></td></tr></tbody></table>

## [Boolfy connect](#boolfy-connect)

Esquema de integraciones con terceros auto-gestionada.

## Postman collection

Te dejamos un [postman collection](https://boolfy.com/BoolfyAgents.postman_collection.json) con todos los métodos de la API para que puedas realizar tus pruebas.


# Documents

Esta API permite subir documentos, asignar asistentes de procesamiento y obtener los datos generados a partir de su procesamiento.

## Visión general

La carga programatica de documentos es probablemente la razón principal por la que está aquí. A estas alturas ya debería tener una Api Key registrada y saber cómo realizar solicitudes autenticadas. Veamos cómo subir un documento.

## Flujo normal del documento

El flujo tipico de un documento es:

1. Se sube el documento asignando el agente de IA que lo procesará
2. Se procesa el documento y queda en estado Draft
   * Si existe un flujo de trabajo configurado, se puede ejecutar un llamado al [Callback ](/documents/callback)especificado en los pasos del Flujo de trabajo para su posterior consulta.
3. A partir de una interacción prestablecida, el documento pasa a estado Approved

## Métodos de Documents API

A continuación, detallamos los métodos de la API Documents

<table><thead><tr><th width="253">Método</th><th>Descripción</th></tr></thead><tbody><tr><td><a href="/documents/upload">Upload</a></td><td>Se utiliza para subir documentos</td></tr><tr><td><a href="/documents/callback">Callback</a></td><td>Se utiliza para notificar a aplicaciones de terceros</td></tr><tr><td><a href="/documents/getinfo">GetInfo</a></td><td>Se utiliza para obtener los datos estructurados de los documentos</td></tr><tr><td><a href="/documents/setinfo">SetInfo</a></td><td>Se utiliza como callback cuando el tercero termina de procesar el documento</td></tr><tr><td><a href="/documents/setagent">SetAgent</a></td><td>Se utiliza para modificar el Agente que procesa el documento</td></tr><tr><td><a href="/documents/list">List</a></td><td>Se utiliza para obtener el listado de documentos procesados</td></tr><tr><td><a href="/documents/getimage">GetImage</a></td><td>Se utiliza para obtener las imagenes de los documentos</td></tr><tr><td><a href="/documents/runrules">RunRules</a></td><td>Se utiliza para ejecutar todas las reglas de un documento en particular</td></tr><tr><td><a href="/documents/deeplink">Deeplink</a></td><td>Especifica la URL para la validación visual de datos</td></tr></tbody></table>


# Upload

Método utilizado para subir un documento

Para subir un documento podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/documents/upload" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "agent": "Facturas",
    "document": "yJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1...",
    "externalcode": "123456",
    "filename": "0001-00003456.pdf",
    "bag": "{\"user\":\"user@enterprise.com\",\"pass\":\"MD5 password\",...}",
    "cluster":[
        {
        "agent": "Recibo", 
        "document": "yJndgdenen...", 
        "filename":"photo.jpeg"
        }
    ]
}
```

Detallamos en forma completa los campos de la solicitud:

<table><thead><tr><th width="191">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Agent</td><td>Especifica el nombre del agente IA que se utilizará para procesar el documento</td></tr><tr><td>Document</td><td>Especifica en Base64 el Stream del documento. Los formatos de archivo aceptados son: PDF, PNG, JPEG y JPG</td></tr><tr><td>ExternalCode</td><td>Opcional. Especifica el identificador del documento en tu plataforma</td></tr><tr><td>Filename</td><td>Opcional. Especifica el nombre del documento. Si no se proporciona, se asume .pdf</td></tr><tr><td>Bag</td><td>Opcional. Permite enviar un JSON especifico para ser utilizado durante el proceso del documento. Ver <a href="/documents/setinfo#bag">Bag</a>.</td></tr><tr><td>Cluster</td><td>Opcional. Esta opción se debe habilitar desde el Agente principal. Permite adjuntar otros documentos al documento principal. La definición de campos es la misma que la principal.</td></tr><tr><td>Context</td><td>Opcional. Establece datos de contexto para el procesamiento de documentos. <strong>En este método se priorizan datos leidos</strong>. Por ej, si envias el valor Total de un documento y el mismo se obtiene del documento, prevalecerá el del  documento. Ver <a href="/documents/setinfo#context">Context</a>.</td></tr></tbody></table>

#### Ejemplo de campo Bag

Detallamos un ejemplo del campo Bag aplicado al envio de los datos extraidos a un tercero:

```json
{
    "user": "user@enterprise.com",
    "pass": "MD5 password",
    "idEmpresa": "Enterprise identifier",
    "endPoint": "End point to call"
}
```

### Respuesta

La respuesta exitosa para la operación de carga de documentos es:

```json
{
    "code": 200,
    "msg": "Document uploaded",
    "response": "{\"Identifier\":\"5a37b2ab-551b-4380-aa88-b808e3352d66\"}"
}
```

La respuesta exitosa cuando se envia con Cluster es:

```json
{
    "code": 200,
    "msg": "Document uploaded",
    "response": "{\"Identifier\":\"5a37b2ab-551b-4380-aa88-b808e3352d66\",
    \"Cluster\":[{\"Identifier\":\"54d542ab-451c-1855-t452-bse4rfse22211\"}]}"
}
```

Detallamos el contenido del campo Response:

<table><thead><tr><th width="194">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Identifier</td><td>Especifica el identificador único dentro de Boolfy para el documento</td></tr></tbody></table>


# Callback

Este llamado se puede ejecutar a partir de la configuración dentro de un Flujo de trabajo.

El llamado que recibirá tu plataforma se detalla en la siguiente solicitud:

```
curl "https://api.enterprise-erp.com/?pk=eD1JdnY9-Zbq...&Identifier=5a37b2..." \ 
    -H "Content-Type: application/json"
```

El parámetro **pk** es a modo de ejemplo del llamado. El dato que envia Boolfy Agents siempre es **Identifier**.

En esta solicitud debes obtener el parametro **Identifier** para poder llamar posteriormente al método [GetInfo](/documents/getinfo).


# GetInfo

Método utilizado para obtener los datos de un documento

Para consultar los datos de un documento podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/documents/getinfo" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "identifier": "5a37b2ab-551b-4380-aa88-b808e3352d66"
}
```

Detallamos en forma completa los campos de la solicitud:

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Identifier</td><td>Especifica el identificador único de Boolfy para el documento. Este dato se proporciono en <a href="/documents/upload">Upload </a>y en <a href="/documents/callback">Callback</a>.</td></tr><tr><td>SetState</td><td>Opcional. Especifica si debe registrarse el <a href="/descripcion-general-de-las-apis#estados-del-proceso">Estado del proceso</a> como Sended en el Documento. Valor por defecto: True.</td></tr></tbody></table>

Ejemplo de archivo `payload.json` con SetState:

```json
{
    "identifier": "5a37b2ab-551b-4380-aa88-b808e3352d66",
    "setState": false
}
```

### Respuesta

La respuesta exitosa para la consulta de datos del documentos es:

```json
{
    "code": 200,
    "msg": null,
    "response": "[{\"Identifier\":\"5a37b2ab...",\"Pages\":2,\"Filename\":\"...}]"
}
```

{% hint style="info" %}
[Descarga de la respuesta de ejemplo para Facturas AR](https://boolfy.com/assets/samples/FacturaAR.json)
{% endhint %}

Detallamos el contenido del campo Response:

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Identifier</td><td>Especifica el identificador único de Boolfy para el documento</td></tr><tr><td>State</td><td>Especifica el estado del documento. Ver <a href="/descripcion-general-de-las-apis#estados-de-revision">Estados de revisión</a></td></tr><tr><td>Process</td><td>Especifica el estado del proceso. Ver <a href="/descripcion-general-de-las-apis#estados-del-documento">Estados del proceso</a></td></tr><tr><td>Filename</td><td>Especifica el nombre del documento, si este fue proporcionado</td></tr><tr><td>Number</td><td>Especifica el número asignado al documento, por el numerador de documentos.</td></tr><tr><td>Pages</td><td>Especifica la cantidad de paginas del documento</td></tr><tr><td>ExternalCode</td><td>Especifica el identificador en tu plataforma del documento</td></tr><tr><td>UploadDate</td><td>Especifica la fecha de carga del documento en Boolfy Agents. Formato de respuesta: yyyy/mm/dd hh:mm:ss</td></tr><tr><td>Images</td><td>Listado de Image de cada pagina del documento. Ver <a href="#image">Image</a></td></tr><tr><td>Rules</td><td>Listado de reglas aplicadas al documento. Ver <a href="#rule">Rule</a></td></tr><tr><td>Traces</td><td>Listado de cambios de estado del documento. Ver <a href="#trace">Trace</a>.</td></tr><tr><td>Deeplink</td><td>URL, sin autenticación, a pagina de validación visual de datos. Ver <a href="/documents/deeplink">Deeplink</a>.</td></tr><tr><td><em>{Campos}</em></td><td>Campos y valores del Agente vinculado al documento</td></tr></tbody></table>

### Image

Detallamos el contenido del campo Image:

<table><thead><tr><th width="222">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Image</td><td>Especifica el identificador de la imagen. Este valor se utiliza en el método <a href="/documents/getimage">GetImage</a></td></tr><tr><td>Page</td><td>Especifica el número de pagina que representa la imagen</td></tr></tbody></table>

### Rule

Detallamos el contenido de cada Rule:

<table><thead><tr><th width="222">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Rule</td><td>Especifica el identificador único de la regla. Este valor no se modifica y se puede tomar como identificador único de la misma</td></tr><tr><td>Name</td><td>Especifica el nombre de la regla</td></tr><tr><td>Leyend</td><td>En caso de fallar la regla, en este campo se especifica información adicional</td></tr><tr><td>Pass</td><td>Especifica si la regla se cumple. Valore posibles: true, false.</td></tr></tbody></table>

### Trace

Detallamos el contenido de cada Rule:

<table><thead><tr><th width="222">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>User</td><td>Especifica el usuario que realizó la acción.</td></tr><tr><td>InDate</td><td>Especifica la fecha y hora de la acción en formato: yyyy/MM/dd HH:mm:ss.</td></tr><tr><td>State</td><td>Especifica el estado en el que quedó el documento cuando se realizó la acción. Ver <a href="/descripcion-general-de-las-apis#estados-de-revision">Estados de revisión</a>.</td></tr><tr><td>Comment</td><td>Especifica el comentario ingresado por el usuario.</td></tr><tr><td>Details</td><td>Opcional. En caso de integraciones, muestra el mensaje de terceros.</td></tr></tbody></table>


# SetInfo

Método utilizado para informar sobre la actualización de un documento en particular

Para informar de la actualización de un documento podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/documents/setinfo" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "identifier": "5a37b2ab-551b-4380-aa88-b808e3352d66",
    "externalcode": "tyujt4f4s5f454w",
    "bag": "{\"property1\":\"value1\",\"property2\":12345.67}",
    "context": "{\"property1\":\"value1\",\"property2\":12345.67}"
}
```

Detallamos en forma completa los campos de la solicitud:

Se debe especificar Identifier o ExternalCode para identificar univocamente al documento sobre el que se quiere realizar la operación.

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Identifier</td><td>Opcional. Especifica el identificador único de Boolfy para el documento. Este dato se proporciono en <a href="/documents/upload">Upload </a>y en <a href="/documents/callback">Callback</a>.</td></tr><tr><td>ExternalCode</td><td>Opcional. Especifica el identificador del documento en tu plataforma</td></tr><tr><td>Bag</td><td>Opcional. Especifica los datos a ser enviados al Application registrado para el Agente. Ver <a href="#bag">Bag</a>.</td></tr><tr><td>Context</td><td>Opcional. Especifica los datos que se quieren modificar en el documento. Ver <a href="#context">Context</a>.</td></tr></tbody></table>

### Bag

Los datos especificados en Bag se transmiten a la Application registrada para el Agente. Quedando en responsabilidad de la Application aplicar los cambios y/o flujos de trabajo necesarios.

### Context

Boolfy Agent toma la responsabilidad de aplicar los cambios en el documento especificado y deja trazabilidad de los mismos en el documento. Aquí pueden enviarse valores para campos que son leidos y/o no leidos desde los documentos.&#x20;

Este JSON puede ser similar al obtenido en GetInfo, por ej:&#x20;

```json
//Simple
{"centro_costo":"ADM", "descuento": 12345.67}

//Complejo
{"cuenta_contable":"ADM", "items": [{"centro_costo": "ADM"}]}
```

### Respuesta

La respuesta exitosa para la consulta es:

```json
{
    "code": 200,
    "msg": null,
    "response": ""
}
```


# SetAgent

Método utilizado para cambiar el Agente de lectura de un documento en particular

Para informar de la actualización de un documento podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/documents/setinfo" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "identifier": "5a37b2ab-551b-4380-aa88-b808e3352d66",
    "agent": "Facturas AR"
}
```

Detallamos en forma completa los campos de la solicitud:

Se debe especificar Identifier o ExternalCode para identificar univocamente al documento sobre el que se quiere realizar la operación.

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Identifier</td><td>Especifica el identificador único de Boolfy para el documento. Este dato se proporciono en <a href="/documents/upload">Upload </a>y en <a href="/documents/callback">Callback</a>.</td></tr><tr><td>Agent</td><td>Especifica el nombre del Agente que quieres establecer al documento. Este cambio puede realizarse una unica vez por documento.</td></tr></tbody></table>

### Respuesta

La respuesta exitosa para la consulta es:

```json
{
    "code": 200,
    "msg": "Agent changed",
    "response": ""
}
```


# List

Método utilizado para obtener un listado de documentos

Para consultar el listado de documentos podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/documents/list" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "Agent": "Facturas",
    "FromDate": "2024/01/01",
    "ToDate": "2024/01/31",
    "State": "Finished",
    "DocumentState": "Approved",
    "FileFormat": "JSON"
}
```

Detallamos en forma completa los campos de la solicitud:

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Agent</td><td>Obligatorio. Especifica el nombre del agente IA de Boolfy para el documento. </td></tr><tr><td>FromDate</td><td>Obligatorio. Especifica la fecha desde del listado en formato: yyyy\mm\dd.</td></tr><tr><td>ToDate</td><td>Obligatorio. Especifica la fecha hasta del listado en formato: yyyy\mm\dd.</td></tr><tr><td>State</td><td>Opcional. Es el estado del <a href="/descripcion-general-de-las-apis#estados-del-proceso">Proceso del documento</a>. Si no se especifica se asume Finished. Para consultar documentos enviados, especificar Sended. </td></tr><tr><td>DocumentState</td><td>Opcional. Es el <a href="/descripcion-general-de-las-apis#estados-de-revision">Estado de revisión</a>. Si no se especifica, este dato no filtra los documentos a obtener.</td></tr><tr><td>FileFormat</td><td>Opcional. Es el formato del campo response en la respuesta. Sus valores posibles son: JSON, CSV o XML. Si no se especifica, se asume: JSON.</td></tr><tr><td>Source</td><td>Opcional. Especifica como fue cargado el documento. Los valores posibles se detallan en <a href="#codigos-de-origen">Códigos de origen</a>.</td></tr></tbody></table>

### Respuesta

La respuesta exitosa para la consulta es:

```json
{
    "code": 200,
    "msg": null,
    "response": "[{\"Identifier\":\"5a37b2ab...",\"Pages\":2,\"Filename\":\"...},{...}]"
}
```

El campo Response es un listado de documentos. Los campos de este listado pueden consultarse en el método [GetInfo](/documents/getinfo#respuesta).

## Códigos de origen

A continuación detallamos los códigos de origen para los documentos.

<table><thead><tr><th width="152">Code</th><th width="599.4000244140625">Nombre</th></tr></thead><tbody><tr><td>Manual</td><td>Cuando un usuario sube de forma manual el documento</td></tr><tr><td>API</td><td>Cuando se recibe por API</td></tr><tr><td>Email</td><td>Cuando se descarga automáticamente desde una dirección de email</td></tr><tr><td>FTP</td><td>Cuando se descarga automáticamente desde un acceso FTP</td></tr><tr><td>Portal</td><td>Cuando se sube desde el Portal de proveedores</td></tr><tr><td>Drive</td><td>Cuando se descarga automáticamente desde Google o Microsoft Drive</td></tr></tbody></table>


# GetImage

Método utilizado para obtener las imágenes de los documentos

Para obtener la imagen de un documento podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/documents/getinfo" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "image": "7598e70c-7557-1235-b3c9-51dc8cfe9729"
}
```

Detallamos en forma completa los campos de la solicitud:

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Image</td><td>Especifica el Identificador único de Boolfy para la imagen. Este dato se proporciono en <a href="/documents/getinfo">GetInfo</a>.</td></tr></tbody></table>

### Respuesta

La respuesta exitosa para la consulta es:

```json
{
    "code": 200,
    "msg": null,
    "response": "BASE64 STRING"
}
```

El contenido del campo Response es la imagen en formato BASE64. Todas las imágenes son optimizadas en tamaño y calidad. El formato de estas es Webp.


# RunRules

Método utilizado para ejecutar todas las reglas de un documento en particular

Para ejecutar nuevamente todas las reglas de un documento particular podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/documents/runrules" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "identifier": "5a37b2ab-551b-4380-aa88-b808e3352d66"
}
```

Detallamos en forma completa los campos de la solicitud:

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Identifier</td><td>Especifica el identificador único de Boolfy para el documento. Este dato se proporciono en <a href="/documents/upload">Upload </a>y en <a href="/documents/callback">Callback</a>.</td></tr></tbody></table>

### Respuesta

La respuesta exitosa de la ejecución de reglas es:

```json
{
    "code": 200,
    "msg": null,
    "response": "The rules were executed correctly"
}
```

El contenido del campo Response simplemente notifica la ejecución exitosa del método.


# Deeplink

Es una URL que apunta a un único documento y permite la validación visual de datos sin necesidad del ingreso de credenciales de acceso.

El deeplink permite la integración de Boolfy Agents tanto en ambientes WinForm como en WebApps de manera directa, segura y transparente para el usuario final.

A continuación, detallamos como se visualiza un Deeplink embebido en una pagina de un tercero.

<figure><img src="https://143018119-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkM1sjIIYYl6C0d7jcyPF%2Fuploads%2Fih0qdbhuhcoxaY29Su6A%2FDeeplink.png?alt=media&amp;token=bbe1a795-38d8-4d72-86dc-97c62970bc49" alt=""><figcaption></figcaption></figure>

Para integrar el deeplink existen dos esquemas diferentes.&#x20;

### WinForm

En aplicaciones WinForm se puede abrir una instancia de navegador con la URL del deeplink.

### WebApp

En aplicaciones Web puedes crear un IFRAME con la URL del deeplink.&#x20;

{% hint style="info" %}
Recuerda contactar con el equipo de integraciones de Boolfy para que habilitemos a tu dominio a embeber nuestros Deeplinks.
{% endhint %}

```html

<iframe src="Deeplink Url" style="height:700px;width:1500px;"></iframe>

```

En los entornos WebApp te puedes suscribir a la mensajeria de Boolfy Agents para recibir notificaciones de las acciones del usuario. Estas pueden ser:

* **Update**: El usuario actualizó el documento. En este caso recomendamos volver a ejecutar el método [GetInfo](/documents/getinfo) para obtener las actualizaciones.
* **Cancel**: El usuario hizo click en el botón de cancelar.
* **404**: El link no es válido.

Para recibir estas notificaciones, simplemente debes suscribirte a la mensajería que emite Boolfy Agents. Aquí tienes un código de ejemplo para la suscripción.

```javascript
window.addEventListener("message", (event) => {
	if (event.data != null && event.data.type != null) {
		if (event.data.type == "boolfy:navigate") {
			if (event.data.action == "updated") {
				//El usuario actualizó el documento
			} else if (event.data.action == "cancel") {
				//El usuario canceló la acción;
			} else if (event.data.action == "404") {
				//Deeplink no válido;
			}
		} else if (event.data.type == "boolfy:rule_not_pass") {
			if (event.data.action == QAId) {
				//Los QAId dependen de cada modelo
			}
		}
	}
});

```

Así mismo, implementamos un mecanismo que permite ejecutar todas las reglas sin necesidad de intervención humana:

```javascript
IFRAME.contentWindow.postMessage({ 
                                    type: "boolfy:rules", 
                                    action: "refresh" 
                                 }, 
                                 "enterprise.com");
```


# Suppliers

Esta API permite obtener los datos de los proveedores que existen en la plataforma.

## Visión general

La automatización de alta de proveedores es probablemente la razón principal por la que está aquí. A estas alturas ya debería tener una Api Key registrada y saber cómo realizar solicitudes autenticadas. Veamos cómo subir un documento.

## Flujo normal del proveedor

El flujo tipico del alta de un proveedor es:

1. Se sube el documento asignando al agente de IA que lo procesará y este agente tiene preconfigurado obtener los datos del proveedor
2. Se identifica un TaxCode de proveedor y se procede a obtener sus datos de un tercero dependiendo del país en el que estas procesando
3. A partir de una interacción prestablecida, se crea el proveedor y quedan sus datos listos para ser consultados

## Métodos de Documents API

A continuación, detallamos los métodos de la API Suppliers

<table><thead><tr><th width="253">Método</th><th>Descripción</th></tr></thead><tbody><tr><td><a href="/suppliers/get">Get</a></td><td>Se utiliza para obtener los datos estructurados de los proveedores</td></tr></tbody></table>


# Get

Método utilizado para obtener los datos de un proveedor

Para consultar los datos de un proveedor podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/suppliers/get" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "TaxCode": "30123456780"
}
```

Detallamos en forma completa los campos de la solicitud:

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>TaxCode</td><td>Especifica el identificador fiscal del proveedor en el país que estas trabajando. Algunos de estos pueden ser: CUIT, CUIL, RFC y/o CNPJ entre otros.</td></tr></tbody></table>

### Respuesta

La respuesta exitosa para la consulta de datos del documentos es:

```json
{
    "code": 200,
    "msg": null,
    "response": "[{\"Name\":\"Empresa SRL",\"TaxCode\":\"30123456780\"...}]"
}
```

Detallamos el contenido del campo Response:

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Name</td><td>Especifica el nombre o razon social del proveedor</td></tr><tr><td>Brand</td><td>Especifica el nombre de fantasía o marca comercial del proveedor</td></tr><tr><td>Country</td><td>Especifica el país de origen del proveedor</td></tr><tr><td>TaxType</td><td>Especifica el tipo de inscripción del proveedor</td></tr><tr><td>TaxCode</td><td>Especifica el identificador fiscal del país de origen del proveedor</td></tr><tr><td>VatType</td><td>Especifica el tipo de inscripción frente a impuestos del proveedor.</td></tr><tr><td>ExternalCode</td><td>Especifica el identificador en tu plataforma del proveedor</td></tr><tr><td>Email</td><td>Especifica el email del proveedor</td></tr><tr><td>Phone</td><td>Especifica el teléfono del proveedor</td></tr><tr><td>Notes</td><td>Especifica las notas que tiene adheridas el proveedor</td></tr><tr><td>State</td><td>Especifica el estado del proveedor. Ver <a href="/descripcion-general-de-las-apis#estados-de-revision">Estados de revisión</a></td></tr><tr><td>Addresses</td><td>Especifica el listado de direcciones del proveedor. Ver <a href="#address">Address</a></td></tr></tbody></table>

### Address

Detallamos el contenido de las direcciones:

<table><thead><tr><th width="222">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Name</td><td>Es el nombre del domicilio</td></tr><tr><td>Country</td><td>Especifica el país del domicilio</td></tr><tr><td>State</td><td>Especifica el estado o provincia del domicilio</td></tr><tr><td>City</td><td>Especifica la ciudad del domicilio</td></tr><tr><td>Street</td><td>Especifica el nombre de la calle o avenida del domicilio</td></tr><tr><td>Number</td><td>Especifica la altura o número de puerta del domicilio</td></tr><tr><td>Floor</td><td>En caso de existir, especifica el piso del domicilio</td></tr><tr><td>Department</td><td>En caso de existir, especifica el departamento del domicilio</td></tr><tr><td>Tower</td><td>En caso de existir, especifica la torre del domicilio</td></tr><tr><td>ZipCode</td><td>Especifica el código postal del domicilio</td></tr></tbody></table>


# Tables

Esta API permite obtener los datos de las tablas satelites que existen en la plataforma.

## Visión general

Estas tablas pueden ser el resultado de la sincronización de datos con sistemas externos, como ser ERPs, CRMs o PMSs y/o el resultado de importaciones masivas que realizan los usuarios dentro de la plataforma. A estas alturas ya debería tener una Api Key registrada y saber cómo realizar solicitudes autenticadas. Veamos cómo subir un documento.

## Métodos de Documents API

A continuación, detallamos los métodos de la API Tables

<table><thead><tr><th width="253">Método</th><th>Descripción</th></tr></thead><tbody><tr><td><a href="/tables/list">List</a></td><td>Se utiliza para obtener los datos estructurados de una tabla en particular.</td></tr></tbody></table>


# List

Método utilizado para obtener los registros de una tabla particular

Para consultar los registros de una tabla en particular podemos generar la siguiente solicitud con el archivo `payload.json`:

```
curl "https://agents.boolfy.com/api/tables/list" \ 
    -H "Authorization: Bearer BOOLFY_BEARER_KEY" \
    -H "Content-Type: application/json" \
    -d @payload.json
```

El archivo `payload.json` debe tener el siguiente formato:

```json
{
    "Name": "Cost center"
}
```

Detallamos en forma completa los campos de la solicitud:

<table><thead><tr><th width="221">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Name</td><td>Obligatorio. Especifica el <a href="#nombres-de-tablas">nombre de la tabla</a> a consultar. </td></tr></tbody></table>

### Respuesta

La respuesta exitosa para la consulta es:

```json
{
    "code": 200,
    "msg": null,
    "response": "[{\"Code\":\"1",\"Name\":\"Library\",\"ExternalCode\":\"...},{...}]"
}
```

El campo Response es una lista con todos los registros **activos** de la tabla.&#x20;

## Nombres de tablas

A continuación, detallamos los nombres de las tablas que se pueden consultar.

| Parámetro Name          | Descripción                   |
| ----------------------- | ----------------------------- |
| Business unit           | Unidad de negocio             |
| Cost center             | Centro de costo               |
| Accounting account      | Cuenta contable               |
| Heading                 | Rubro                         |
| Customer                | Cliente                       |
| Seller                  | Vendedor                      |
| Accounting concept      | Concepto contable             |
| Internal perceptions    | Percepciones internas         |
| Internal taxs           | Impuestos internos            |
| Internal other taxs     | Otros impuestos internos      |
| Earnings                | Ganancias                     |
| Internal jurisditions   | Jurisdicciones internas       |
| Internal withholdings   | Retenciones internas          |
| Articles                | Artículos                     |
| Categories              | Categorías                    |
| Services                | Servicios                     |
| Auxiliar taxes          | Impuestos auxiliares          |
| Tax regime              | Régimen impositivo            |
| VAT Purchases           | IVA compras                   |
| Bank account type       | Tipo de cuenta bancaria       |
| Recurrence              | Recurrencia                   |
| Clasification           | Clasificación                 |
| Employee                | Empleado                      |
| Internal conditions sal | Condiciones internas de venta |
| Imputation              | Imputación                    |
| Expenses                | Gastos                        |
| Reason                  | Motivo                        |
| Unit of measurement     | Unidad de medida              |
| Branches                | Sucursales                    |
| Contract                | Contrato                      |
| Department              | Departamento                  |
| Method of payment       | Método de pago                |


# Boolfy connect

En esta sección se detalla el estándar de conectividad que se implementa en Boolfy Agents para las integraciones con sistemas de terceros.

## Visión general

A partir de la necesidad de contar con un esquema homogeneo y automatizado de integraciones, surge la propuesta de unificar todas las integraciones en este conector. La visión principal es la implementación de un micro-servicio y/o lambda function que permita a un tercero disponer de una API que se encargue de realizar el envío de datos a la plataforma del tercero (ERP, CRM, etc.).

## Habilitar Boolfy connect

Para habilitar esta conectividad con un tercero se deben realizar los siguientes pasos dentro de Boolfy Agents.

### Creación de credenciales

Ir a Credenciales y generar las credenciales que utilizará Boolfy connect para autenticarse en el End-Point. Es importante destacar que debe seleccionarse el método: Bearer token.

<figure><img src="https://143018119-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkM1sjIIYYl6C0d7jcyPF%2Fuploads%2FuiAxAI41Lj3JQem3dM0g%2FCredencial.png?alt=media&amp;token=263ad712-44b3-4848-83bd-91ae86dfd146" alt="" width="563"><figcaption></figcaption></figure>

### Creación de aplicación

La aplicación se puede crear para cada Agent y principalmente debe tener los siguientes datos.

<figure><img src="https://143018119-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkM1sjIIYYl6C0d7jcyPF%2Fuploads%2Fg29AcAtyYVNvwnJ5q8VZ%2FApplication.png?alt=media&amp;token=f592e800-58d3-48ab-a1ed-13bc28a8b878" alt="" width="563"><figcaption></figcaption></figure>

Por último, debes crear el flujo de trabajo con el evento activador del mismo y como acción llamar a la aplicación que acabas de crear.

## Métodos a implementar

A continuación, detallamos los métodos que se utilizan Boolfy connect.

<table><thead><tr><th width="253">Método</th><th>Descripción</th></tr></thead><tbody><tr><td>Documents</td><td>Se utiliza para informar a un tercero de un nuevo documento que ha sido enviado a partir de un flujo de trabajo</td></tr><tr><td>GetAll</td><td>Se utiliza para sincronizar tablas de conexto de un tercero con Boolfy Agents.</td></tr></tbody></table>

Siguiendo el ejemplo de la credencial, cada uno de estos métodos se llamaran de la siguiente manera:

```http
https://miempresa.com/api/boolfyconnect/documents
https://miempresa.com/api/boolfyconnect/getall
```

## VS Code en Lambda AWS

Adjuntamos un proyecto en .Net 10 C# listo para subir a Lambda AWS y empezar a trabajar.

[Descargar proyecto](https://boolfy.com/Boolfy-Connect-Sample.zip)


# Documents

Método utilizado para enviar el callback a un End-Point con la notificación del documento que fue enviado por el flujo de trabajo desde Boolfy.

La solicitud que envia Boolfy connect es la siguiente:

```
curl "https://miempresa.com/api/boolfyconnect/documents?Identifier=XXX" \ 
    -H "Authorization: Bearer TOKEN_CREDENTIAL" \
    -H "Content-Type: application/json" \
```

De esta manera se notifica al End-Point del Identifier de Boolfy que fue enviado por el flujo de trabajo. El valor de Identifier es el documentado en [GetInfo](/documents/getinfo). El valor TOKEN\_CREDENTIAL es el generado en [Credenciales](/boolfy-connect#creacion-de-credenciales).

En el método documents se recomienda validar el token de seguridad del header y posteriormente se puede proceder a realizar la llamada a [GetInfo](/documents/getinfo) para obtener los datos del documento.

### Respuesta esperada

La respuesta exitosa para la respuesta es la siguiente:

```json
{
    "code": 200,
    "messge": null,
    "id": "Internal_Id_del_ERP"
}
```

A continuación detallamos cada uno de estos campos:

<table><thead><tr><th width="141.2000732421875">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Code</td><td>Http code. Informa si hubo exíto en el procesamiento del documento. </td></tr><tr><td>Message</td><td>En caso de error, se informa el mismo en este campo. Considerar que este mensaje debe llevar a la acción del usuario.</td></tr><tr><td>Id</td><td>En caso de exíto, es el Id interno del documento en la plataforma del tercero.</td></tr></tbody></table>

Para procesos asincronicos se recomienda responder Code: 200 y luego utilizar el método [SetInfo](/documents/setinfo) asignando el ExternalCode.


# GetAll

Método utilizado para sincronizar las tablas de contexto en la UI de Boolfy Agents.

La solicitud que envia Boolfy connect es la siguiente:

```
curl "https://miempresa.com/api/boolfyconnect/getall?field=XXX" \ 
    -H "Authorization: Bearer TOKEN_CREDENTIAL" \
    -H "Content-Type: application/json" \
```

De esta manera se realiza un GET al End-Point de forma diaria para obtener los datos de las tablas declaradas en Sincronización.

Esté metodo debe devolver un array en json con todos los registros de la tabla.

### Respuesta esperada

La respuesta exitosa para la respuesta es la siguiente:

```json
[
    {"code": "012","name": "Zapatilla","InternalId": "012"},
    {"code": "013","name": "medias","InternalId": "013"},
    ...
]
```

A continuación detallamos cada uno de estos campos:

<table><thead><tr><th width="141.2000732421875">Campo</th><th>Descripción</th></tr></thead><tbody><tr><td>Code</td><td>Es el código que se utilizará dentro de Boolfy Agents.</td></tr><tr><td>Name</td><td>Es el nombre amigable que visualizará el usuario en Boolfy Agents.</td></tr><tr><td>InternalId</td><td>Opcional. Es el código interno con el cual queres que el método <a href="/documents/getinfo">GetInfo</a> te comunique cuando obtengas los datos del documento.</td></tr></tbody></table>


# Creación de proyecto en VS Code

Detallamos el paso a paso para armar un proyecto desde cero con VS Code y Lambda Functions de AWS

### Crear el proyecto .NET

Abri una terminal PowerShell y ejecuta:

```powershell
dotnet new install Amazon.Lambda.Templates
dotnet tool install -g Amazon.Lambda.Tools

dotnet new lambda.EmptyFunction `
  --name MyFunctionLambda `
  --region sa-east-1
```

Ingresá a la carpeta del proyecto:

```powershell
cd MyFunctionLambda\src\MyFunctionLambda 
```

Agregá el paquete para recibir solicitudes HTTP:

```powershell
dotnet add package Amazon.Lambda.APIGatewayEvents
```

AWS Function URL utiliza el mismo formato de evento que API Gateway Payload Format 2.0, por eso se puede usar `APIGatewayHttpApiV2ProxyRequest`

### Desplegar la Lambda

```powershell
dotnet lambda deploy-function MyFunctionLambda `
  --region sa-east-1
```

## VS Code en Lambda AWS

Adjuntamos un proyecto en .Net 10 C# listo para subir a Lambda AWS y empezar a trabajar.

[Descargar proyecto](https://boolfy.com/Boolfy-Connect-Sample.zip)


# Anexos

En esta sección se detallan los anexos complementarios de integración de Boolfy Agents con terceros.


# Integración de Boolfy Agents con facturas de servicios

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 servicios

Este flujo aplica a comprobantes donde la validación principal no se realiza contra una orden de compra ni contra una recepción física, sino contra datos maestros, reglas fiscales, imputaciones contables, dimensiones financieras y, si corresponde, circuitos de aprobación interna.

***

### 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 facturas de servicio sin órdenes de compra ni remitos asociados.

***

### 1. Contexto general

Boolfy Agents permite leer, interpretar y estructurar información de comprobantes de compra, incluyendo facturas de servicios que no tienen una orden de compra asociada.

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, reglas fiscales y estructuras contables definidas en el ERP.

En este tipo de flujo, Boolfy no realiza validación contra órdenes de compra ni contra cantidades recibidas. La validación se centra principalmente en:

* Identificación y validación del proveedor.
* Validación fiscal del comprobante.
* Validación de impuestos, percepciones y retenciones aplicables.
* Determinación de cuentas contables, centros de costo y dimensiones financieras.
* Validación de importes, moneda y fechas.
* Asignación del gasto a una categoría, área, sociedad, proyecto o unidad de negocio.
* Aprobación funcional o contable, si el proceso lo requiere.
* Ingreso de la factura en el ERP con la información estructurada.

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, concepto del servicio, periodo del servicio y datos de imputación si estuvieran presentes.
3. Boolfy consulta el ERP para validar la información contra proveedores, impuestos, percepciones, dimensiones financieras, centros de costo, cuentas contables y reglas de imputación.
4. Boolfy determina o propone la imputación contable correspondiente, de acuerdo con las reglas definidas para el cliente.
5. Si el proceso lo requiere, Boolfy puede dejar la factura pendiente de revisión o aprobación por parte del área usuaria, responsable del gasto, sector contable o circuito definido.
6. Una vez validada la información, Boolfy envía la factura estructurada al ERP para su ingreso.
7. El ERP devuelve el resultado del proceso, incluyendo identificadores internos, estado de creación, errores de validación o mensajes de negocio.
8. En caso de diferencias o datos faltantes, 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 sin necesidad de asociarlas a una orden de compra.

**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.
* Tipo de cambio, si aplica.
* Importes netos, impuestos, percepciones, descuentos y total.
* Concepto o descripción del servicio.
* Periodo del servicio, si aplica.
* Líneas de factura.
* Cuenta contable.
* Centro de costo.
* Dimensiones financieras.
* Unidad de negocio.
* Departamento.
* Proyecto, si aplica.
* Categoría de gasto o tipo de servicio.
* Impuestos y códigos fiscales aplicables.
* Adjuntos del comprobante, si el proceso lo requiere.
* Identificador externo o clave de idempotencia para evitar ingresos duplicados.
* Estado esperado de ingreso: borrador, pendiente de aprobación, contabilizada o equivalente, según permita el ERP.

**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.
* Estado de aprobación o contabilización, si aplica.

***

#### 3.2 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.
* Cuenta bancaria o datos de pago, si el proceso lo requiere.
* Indicador de bloqueo de pago o bloqueo de carga, si aplica.
* Categorías o tipos de gasto habituales asociados al proveedor, si existen.

**Objetivo:**

Validar que el proveedor identificado en la factura exista en el ERP, esté activo y se encuentre habilitado para la sociedad o entidad legal correspondiente.

***

#### 3.3 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.
* Reglas de aplicación por tipo de servicio.
* 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.4 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 proveedor, categoría de gasto, cuenta contable y dimensiones.
* Relación entre usuario solicitante, área, centro de costo y dimensiones.
* Reglas de obligatoriedad de dimensiones.
* Reglas de imputación por tipo de servicio.

**Objetivo:**

Validar que la información enviada por Boolfy sea consistente con la estructura contable definida en el ERP y que la factura pueda registrarse correctamente sin orden de compra asociada.

***

### 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.
* Criterios para registrar facturas como borrador, pendiente de aprobación o contabilizadas.
* Criterios para rechazar facturas con datos incompletos.
* Mecanismo para consultar el estado posterior de una factura enviada al ERP.
* Mecanismo de auditoría para conocer qué validaciones fueron aplicadas.
* Reglas para actualización de datos luego del ingreso inicial.

***

### 5. Validaciones funcionales esperadas

Se propone validar los siguientes escenarios:

* Factura de servicio con proveedor válido.
* Factura de servicio con proveedor no encontrado.
* Factura con datos fiscales correctos.
* Factura con número de comprobante duplicado.
* Factura con moneda extranjera.
* Factura con tipo de cambio requerido.
* Factura con fecha de vencimiento informada.
* Factura con múltiples líneas de servicio.
* Factura con múltiples impuestos o percepciones.
* Factura con conceptos de servicio que deben imputarse a distintas cuentas contables.
* Factura con dimensiones financieras obligatorias.
* Factura con categoría de gasto obligatoria.
* Factura con importe superior al umbral de aprobación.
* Factura aprobada y enviada al ERP.
* Factura rechazada por validaciones del ERP.
* Factura con datos obligatorios ausentes o ilegibles.

***

### 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 proveedores.
3. Documentación de APIs o catálogos para impuestos, percepciones y localizaciones.
4. Documentación de APIs o catálogos para dimensiones financieras, cuentas contables y centros de costo.
5. Documentación de categorías de gasto o tipos de servicio.
6. Documentación de reglas de imputación contable para facturas.
7. Documentación de circuitos de aprobación, si aplica.
8. Ejemplos de requests y responses.
9. Credenciales o mecanismo de acceso al ambiente de testing.
10. Reglas funcionales para el ingreso de facturas de servicio.
11. Criterios de validación obligatorios antes de registrar una factura.
12. Criterios para registrar facturas como borrador, pendiente de aprobación o contabilizadas.
13. Criterios para rechazar o dejar pendiente una factura con datos incompletos.

***

### 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 para el ingreso de facturas de servicio sin orden de compra.
4. Se relevarán las reglas de imputación contable aplicables.
5. Se relevarán las reglas de aprobación aplicables, si existen.
6. Se acordará un set de casos de prueba representativos.
7. Se habilitará un ambiente de testing con credenciales de integración.
8. Boolfy realizará pruebas de consulta de proveedores, impuestos, dimensiones, cuentas contables y centros de costo.
9. Se probará el ingreso de facturas de compra de servicios en el ERP.
10. Se validarán casos de facturas aprobadas, pendientes y rechazadas.
11. Se revisarán errores, validaciones y ajustes necesarios.
12. Se definirá el flujo definitivo para puesta en producción.
13. Se documentará el circuito operativo para documentos rechazados, pendientes o reprocesados.

***

### 8. Consideraciones adicionales para facturas de servicio sin orden de compra

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

* Si la factura puede registrarse directamente o debe quedar pendiente de aprobación.
* Qué áreas o usuarios deben aprobar el gasto.
* Qué campos contables son obligatorios.
* Cómo se determina la cuenta contable.
* Cómo se determina el centro de costo.
* Cómo se determina la unidad de negocio, departamento o proyecto.
* Cómo se clasifican los servicios recurrentes.
* Cómo se manejan facturas de servicios con periodos mensuales, anuales o parcialmente devengados.
* Cómo se manejan gastos que deben distribuirse entre varios centros de costo.
* Cómo se manejan gastos que deben distribuirse entre varias cuentas contables.
* Cómo se manejan cargos adicionales, descuentos, bonificaciones, intereses u otros conceptos.
* Cómo se manejan facturas en moneda extranjera.
* Cómo se manejan comprobantes con datos fiscales incompletos o inconsistentes.
* Qué información debe quedar auditada para justificar la imputación y aprobación realizada.


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

***


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