Conciliación
Para garantizar la transparencia y la facilidad de consumo de datos a gran escala, se creó el módulo de conciliación financiera, un conjunto de API cuya finalidad es mostrar los importes que componen la transferencia de un socio. En este artículo, le mostraremos cómo utilizar este módulo de forma eficaz.Con el conjunto de endpoints de la API Financiera, podrá automatizar el proceso de conciliación iFood en su empresa, evitando así errores operativos y garantizando la claridad necesaria en la composición de los asientos financieros que componen la transferencia, generando más valor para su negocio.Conceitos importantes
Venta
Son todos los pedidos que han pasado por la app de iFood, independientemente de la forma de pago utilizada por el consumidor, de si se han pagado o no online y de si el pedido se ha entregado (completado) o no. Cada venta tiene unas características individuales que, junto con los datos del contrato, iFood utiliza para facturar y componer el importe a pagar o a cobrar al socio, estos datos están en la API de Ventas.Ajustes
Los ejemplos incluyen la cancelación de un artículo después de que el pedido haya sido entregado (completado), el cargo de un saldo pendiente, el descuento de pedidos cancelados pagados con VA/VR, las disputas aceptadas por iFood, entre otras opciones. Estos ejemplos se pueden encontrar en las APIs de Ajustes de Ventas, Ocurrencias, Cancelaciones de Cargos y Cancelaciones.Contabilizaciones financieras
Son registros detallados de transacciones/operaciones, vinculadas al socio, que tienen fecha, valor y naturaleza de operación, que impactan directa y/o indirectamente en el cálculo financiero del socio, compuesto por ventas y ajustes, así como las APIs de Cuotas de Mantenimiento e Impuestos a las Ganancias.Contando
iFood completa el cierre financiero de la transferencia del socio semanalmente (de lunes a domingo), todas las entradas realizadas durante este periodo se calculan el lunes siguiente y tras el cálculo, si existe un importe a transferir al socio, se programa el pago según el plan de transferencias contratado, como por ejemplo D30 (30 días), si el saldo es negativo, iFood puede generar un albarán de cobro para el socio o cargar este importe a la siguiente transferencia, recordando que iFood actualmente realiza los pagos los miércoles.Responsabilidad
Identificador de la organización que ha cobrado el pago del consumidor para una transacción concreta, por ejemplo IFOOD o MERCHANT:- Un consumidor que ha pagado un pedido directamente en la app de iFood e iFood ha cobrado este pago para repercutirlo al socio, en este caso el responsable será IFOOD.
- Si el mismo ejemplo anterior se produjera con el método de pago VA o VR, iFood en este caso no recoge el valor del pedido, se envía directamente desde el emisor de la tarjeta al establecimiento asociado, por lo que la responsabilidad es del COMERCIANTE.
- Un consumidor ha pagado fuera de línea, por lo que iFood no recoge el pago del pedido y la responsabilidad es del COMERCIANTE.
Traslado
Para identificar estos importes a cobrar o a pagar a iFood, el campo "periodid" y el filtro deben utilizarse como clave de agrupación, un identificador único que hace referencia al conjunto de asientos que componen la transferencia.Cómo conciliar
La conciliación se basa en un conjunto de recursos:
Actualización diaria de datos
Todas las API, a excepción de la API /payments, se actualizarán diariamente y los datos estarán disponibles a las 18.00 horas.
Period ID e Expected Payment Date
Los periodos (nombre que recibe el conjunto de entradas que componen la transferencia) se cerrarán todos los miércoles, por lo que los campos periodId y expectedPaymentDate sólo estarán disponibles en las API a partir de ese día. Es importante tener en cuenta que la información actualizada el miércoles se referirá a la semana anterior (de lunes a domingo). Mientras no haya periodId, los únicos filtros posibles serán por intervalo de fechas.
Periodo
El endpoint /{merchantId}/period, ,devuelve información sobre los "ids" que tiene el socio en un mes determinado, estos "ids" son los identificadores que agrupan un conjunto de contabilizaciones que conforman la transferencia del socio y que deben ser utilizados en las peticiones de los otros endpoints para entender qué conjunto de datos impactó en una transferencia determinada.
Vale la pena recordar que los períodos pueden tener el estado ABIERTO o CERRADO, cuando tiene el estado ABIERTO, significa que el período aún no se ha calculado, y puede sufrir cambios en la inclusión o eliminación de entradas que repercuten en la transferencia, podemos citar como ejemplo la aceptación de iFood de un desafío que estaba en análisis, sólo después de aprobar el desafío, entrará como una entrada en el período abierto del socio.
Más informaciónVale la pena recordar que los períodos pueden tener el estado ABIERTO o CERRADO, cuando tiene el estado ABIERTO, significa que el período aún no se ha calculado, y puede sufrir cambios en la inclusión o eliminación de entradas que repercuten en la transferencia, podemos citar como ejemplo la aceptación de iFood de un desafío que estaba en análisis, sólo después de aprobar el desafío, entrará como una entrada en el período abierto del socio.
Pagos por tienda
El endpoint /{merchantId}/payments, devuelve información sobre la transferencia del socio realizada por iFood. El valor total será la suma de los valores de todas las API, ya sean a cobrar o a pagar, recordando que podemos tener varias transferencias al socio en el mismo día, dependiendo de varios factores durante la facturación de iFood.
Más informaciónObservación
Si el socio ha realizado un anticipo de crédito con una entidad financiera y ha otorgado como garantía la cartera de créditos de iFood, estos pagos pueden verse afectados por el efecto del contrato (registro de créditos), esta API sólo mostrará el pago residual destinado al socio de iFood si existe, ya que el establecimiento puede comprometer parte o la totalidad de su cartera, el importe comprometido con la entidad financiera debe consultarse en la API recebíveis.
Ventas por tienda
El endpoint /{merchantId}/sales,devuelve información sobre los "ids" que tiene el socio en un mes determinado, estos "ids" son los identificadores que agrupan un conjunto de contabilizaciones que conforman la transferencia del socio y que deben ser utilizados en las peticiones de los otros endpoints para entender qué conjunto de datos impactó en una transferencia determinada.
Vale la pena recordar que los períodos pueden tener el estado ABIERTO o CERRADO, cuando tiene el estado ABIERTO, significa que el período aún no se ha calculado, y puede sufrir cambios en la inclusión o eliminación de entradas que repercuten en la transferencia, podemos citar como ejemplo la aceptación de iFood de un desafío que estaba en análisis, sólo después de aprobar el desafío, entrará como una entrada en el período abierto del socio.
Más informaciónVale la pena recordar que los períodos pueden tener el estado ABIERTO o CERRADO, cuando tiene el estado ABIERTO, significa que el período aún no se ha calculado, y puede sufrir cambios en la inclusión o eliminación de entradas que repercuten en la transferencia, podemos citar como ejemplo la aceptación de iFood de un desafío que estaba en análisis, sólo después de aprobar el desafío, entrará como una entrada en el período abierto del socio.
Observación
El campo de responsabilidad, como se ha comentado anteriormente, es el identificador de quién ha recibido el pago por parte del consumidor, si es COMERCIANTE, iFood no tendrá ningún importe recibido del consumidor para repercutir al asociado, esto quiere decir que el establecimiento ha recibido el importe del pedido directamente del consumidor o del emisor de la tarjeta, por lo que la venta sólo podrá mostrar adeudos a cobrar por hacer posible la operación, como por ejemplo la comisión del pedido.
El valor total de la venta estará representado por el campo GMV, que se encargará de proporcionar el valor de la venta más el valor de la entrega, incluso sin deducir las comisiones cobradas por iFood.
Cabe señalar que un pedido puede sufrir cambios durante su ciclo de vida, siempre y cuando haya sido aceptado por el socio, este punto final mostrará el "final" del pedido, como una foto de cómo estaba en el momento en que se completó o canceló (CONCLUDED/CANCELLED) cualquier y todos los cambios realizados antes o después no se mostrarán en este punto final.
El valor total de la venta estará representado por el campo GMV, que se encargará de proporcionar el valor de la venta más el valor de la entrega, incluso sin deducir las comisiones cobradas por iFood.
Cabe señalar que un pedido puede sufrir cambios durante su ciclo de vida, siempre y cuando haya sido aceptado por el socio, este punto final mostrará el "final" del pedido, como una foto de cómo estaba en el momento en que se completó o canceló (CONCLUDED/CANCELLED) cualquier y todos los cambios realizados antes o después no se mostrarán en este punto final.
Ajuste de vendas
O Endpoint /{merchantId}/salesAdjustments, devuelve información sobre los cambios que afectan al valor de los pedidos una vez finalizados. En estos casos, el pedido completado será refacturado (CONCLUIDO), recordando que podemos tener varias refacturas para un mismo pedido. Como ejemplo, podemos considerar un pedido en el que, una vez finalizado, un artículo de la cesta fue cancelado por el cliente, que se puso en contacto con nosotros e informó de que el producto no había sido enviado. En estos casos, se refacturará el pedido, descontando el artículo anulado, generando así un nuevo importe para repercutir al socio.
Más informaciónObservación
Es necesario destacar que la refacturación del pedido puede ocurrir en un "periodid" diferente al de la venta, esto ocurrirá siempre que la refacturación del pedido ocurra cuando el periodo de la venta ya haya sido cerrado/compensado, de esta forma iFood cargará este valor para el próximo periodo abierto.
Ocurrencias
El Endpoint /{merchantId}/occurrences, devuelve información sobre los asientos realizados por iFood que repercuten en la transferencia del socio. Las incidencias son asientos financieros manuales de abono o adeudo que sirven para diversos fines.
En general, podemos resumirlos en 2 grupos:
Más informaciónEn general, podemos resumirlos en 2 grupos:
- Ocurrencias para correcciones financieras - Cuando es necesario, iFood realiza un ajuste de la transacción financiera que se contabilizó erróneamente, por ejemplo, ajustando una comisión cargada con un importe erróneo, o para realizar un asiento financiero específico.
- Ocurrencias que habilitan nuevas reglas y/o nuevos productos - iFood está en constante evolución, siempre lanzando nuevas funcionalidades para nuestros socios y con el fin de satisfacer estas nuevas mecánicas de negocio, el sistema financiero de iFood tiene esta característica, reduciendo el tiempo de implementación y pudiendo validar con nuestros socios.
Observación
Dado que se trata de una herramienta interna de iFood que ayuda con diversos fines, es imposible predecir qué tipos de incidencias podrían publicarse, por lo que es importante categorizar el campo "motivo" para tener una mejor experiencia de comprensión de los casos publicados.
Entradas IR
El endpoint/{merchantId}/incomeTaxes, devuelve información sobre los reembolsos efectuados por iFood al socio, debidos a operaciones en las que se recaudó el impuesto sobre la renta. Este importe se calcula en cada cierre mensual de iFood y se contabiliza el importe a devolver correspondiente al mes anterior.
Más informaciónCancelaciones de facturación
El endpoint /{merchantId}/chargeCancellations, devuelve información sobre el importe que iFood ha repercutido al socio, cuando la anulación del pedido es responsabilidad de iFood. Por ejemplo, una anulación causada por un problema con el repartidor. Si el socio utiliza la logística de entrega de iFood y durante el trayecto hasta el destinatario se produce un problema y el pedido no llega a su destino, se entiende que el socio ha cumplido con su deber de preparar y enviar el pedido, pero éste no ha sido entregado por causas ajenas a su voluntad. En este caso, iFood realiza un abono al socio, deduciendo los gastos correspondientes.
Más informaciónCancelaciones
El endpoint /{merchantId}/cancellations, devuelve información sobre la cancelación total del pedido. Como ejemplo, podemos tomar un pedido cuyo estado era completado, pero el partner no pudo entregarlo al cliente, por lo que el pedido será cancelado. Cabe destacar que los pedidos cancelados siempre estarán disponibles para su consulta en la api de ventas, ya que en algún momento fue un pedido con estado completado.
Más informaciónObservación
Es necesario destacar que la refacturación del pedido puede ocurrir en un "periodid" diferente al de la venta, esto ocurrirá siempre que la refacturación del pedido ocurra cuando el periodo de la venta ya haya sido cerrado/compensado, de esta forma iFood cargará este valor para el próximo periodo abierto.
Impuestos de mantenimiento
El endpoint /{merchantId}/maintenanceFees,devuelve información sobre la cuota mensual cobrada por iFood al socio, de acuerdo con las normas y condiciones del contrato entre las organizaciones.
Más informaciónPaymentDetails
El Endpoint /{merchantId}/paymentDetails, devuelve información sobre los detalles de la transacción de pago con tarjeta MEAL VOUCHER. Es importante destacar que la api no está vinculada a la api de pagos. Como ejemplo, podríamos tomar un pedido realizado en la aplicación iFood y pagado a través de la aplicación, utilizando una tarjeta VA o VR. En este caso, la API mostrará información sobre la entidad adquirente, la NSU, el estado del pago, etc.
Más informaciónObservación
Presentamos estos datos de la transacción porque iFood no se encarga de recibir el pago y transmitirlo al socio; en estos casos, el propio emisor de la tarjeta envía el importe al establecimiento, sin pasar por iFood..
También detallamos las devoluciones de cargo, en su caso, identificando si el cargo se ha realizado directamente al emisor de la tarjeta, por lo que el establecimiento no tendría importe a percibir, o si el cargo se ha realizado al monedero digital del consumidor, por lo que el establecimiento recibirá el importe del emisor de la tarjeta, pero al haberse anulado parcial o totalmente el pedido, el importe ha sido devuelto al consumidor, por lo que iFood generará un cargo al establecimiento por esta operación..
También detallamos las devoluciones de cargo, en su caso, identificando si el cargo se ha realizado directamente al emisor de la tarjeta, por lo que el establecimiento no tendría importe a percibir, o si el cargo se ha realizado al monedero digital del consumidor, por lo que el establecimiento recibirá el importe del emisor de la tarjeta, pero al haberse anulado parcial o totalmente el pedido, el importe ha sido devuelto al consumidor, por lo que iFood generará un cargo al establecimiento por esta operación..
Registros Recebíveis
El Endpoint /{merchantId}/receivableRecords, devuelve información sobre los registros de cuentas por cobrar, es decir, el importe transferido a una entidad financiera con la que el socio ha suscrito algún tipo de acuerdo de pago por adelantado y que ha concedido el diario iFood como garantía.
Más informaciónObservación
La transferencia en el registro de créditos puede comprometer parcial o totalmente el calendario de créditos del socio con iFood, en función del contrato firmado entre el establecimiento y la entidad financiera.
Para la transferencia que aquí se presenta, se realizan uno o más fraccionamientos del pago original, por acuerdo de pago según lo establecido en la normativa del Banco Central.
Para la transferencia que aquí se presenta, se realizan uno o más fraccionamientos del pago original, por acuerdo de pago según lo establecido en la normativa del Banco Central.
Ifood Beneficios
O Endpoint /{merchantId}/salesBenefits, devuelve información sobre las ventas que fueron pagadas por el consumidor en la app con la tarjeta de beneficios iFood. La api mostrará un apartado con los datos de los pedidos y las comisiones aplicadas por iFood y el importe neto que recibirá el comercio por la operación.
Más informaciónObservación
Los datos sólo se mostrarán en este punto final si el establecimiento recibe la transferencia de iFood independientemente de las tarjetas de crédito y débito.
iFood Ajustes de beneficios
O Endpoint /{merchantId}/adjustmentsBenefits, devuelve información sobre los cambios que afectan al valor de los pedidos después de su finalización y que han sido pagados con iFood Benefits en la app. En estos casos, el pedido finalizado se refacturó (CONCLUIDO), recordando que podemos tener varias refacturas para un mismo pedido. Como ejemplo, podemos considerar un pedido en el que, una vez finalizado, el consumidor canceló un artículo de la cesta y se puso en contacto con nosotros informando de que el producto no había sido enviado. En estos casos, se refacturará el pedido, descontando el artículo anulado, generando así un nuevo importe para repercutir al socio.
Más informaciónObservación
Los datos sólo se mostrarán en este punto final si el establecimiento recibe la transferencia de iFood independientemente de las tarjetas de crédito y débito.