Descripción general
La remesa ocurre cuando se transfiere dinero de una parte a otra. Un ejemplo podría ser cuando se envía dinero del banco de la integradora de pagos al banco de Google. En el siguiente diagrama, se ilustra cómo ocurre esto.
Cómo funciona el flujo
En el siguiente diagrama, se ilustra un ejemplo de cómo podría funcionar el flujo de remesas.
Integrador de pagos de remesas a Google
A continuación, se muestra una lista de los objetos que se usan en este diagrama:
- Servidor de Google: El servidor de backend de Google que realiza la verificación de autenticación junto con otras tareas de autenticación.
- Integrador de pagos: Es la empresa que ofrece una forma de pago a sus clientes.
- Banco de integración de pagos: Es el banco emisor que el integrador utiliza para las transacciones financieras.
- Banco de Google: Es el banco que Google utiliza en las transacciones.
El flujo de remesas anterior comienza con el servidor de Google.
- En días de T+N, Google envía la notificación del resumen de remesas (
remittanceStatementNotification). - El integrador de pagos notifica al servidor de Google que recibió correctamente la notificación del resumen de remesas.
- Además, el integrador de pagos envía detalles del resumen de remesas (
remittanceStatementDetails). - El servidor de Google responde con la declaración junto con transactionDetails.
- El integrador de pagos concilia los detalles.
- El integrador de pagos envía un mensaje (
acceptRemittanceStatement) al servidor de Google para indicar que se aceptó el estado de cuenta. - El Integrador de pagos también envía un mensaje que indica que el Banco de Integradores de Pagos debe enviar fondos al Banco de Google.
- El banco de Payment Integrator transfiere fondos al Banco de Google.
Prácticas recomendadas y otras consideraciones
Tiempos
Las condiciones de pago se establecen en el contrato y, por lo general, se expresan como V+N. T es la frecuencia con la que se genera un certificado de remesa y la duración del período que cubre cada estado. En el siguiente ejemplo, T es un día de transacción. N es la cantidad de días posteriores al período de transacción en los que llega el resumen de remesas.
Si N se configura como 2 y una transacción se registra en 23:59:59.999 en la zona horaria de facturación el martes, se mostrará en un resumen el jueves.
Sentencias netas negativas o cero
Para los días en los que no haya transacciones dentro del período de facturación, no se enviarán notificaciones del resumen de remesas. Además, si se realizan reembolsos dentro de un período de facturación y generan un importe neto negativo en una factura, tampoco se enviarán los resúmenes de remesa. Sin embargo, estas transacciones se incluirán en la siguiente factura neta positiva, para la cual se enviará la notificación del resumen de remesas. En el caso de que las transacciones sean netos a 0 para un período de facturación en particular, se enviarán notificaciones del resumen de remesas.
Límites
A continuación, se presentan algunos ejemplos con varios límites. Un límite transaccional es el momento en que la transacción se inicia o se confirma. Recuerda que la marca de tiempo contable es el momento en que Google procesó esta transacción. El límite de las declaraciones de remesas comienza a las 00:00:00.000 y finaliza a las 23:59:59.000.
Transacción dentro de límites
| Evento | |
|---|---|
| Capturar | requestHeader.requestId
001 requestHeader.requestTimestamp 01/01/2017 23:26:32.253 responseHeader.responseTimestamp 01/01/2017 23:26:34.248 marca de tiempo de {i>accounting071/40281:0 01:81 |
| RemittanceStatementNotification | requestHeader.requestTimestamp
01/03/2017 03:17:18.132 billingPeriod.startDate 01/01/2017 00:00:00.000 billingPeriod.endDate 01/01/2017 293.59.59 |
Límites de intervalos de transacciones
Una de las capturas que aparecen a continuación tiene todas las marcas de tiempo del día 01/01/2017. Sin embargo, esto no se incluye hasta el 02/01/2017.
| Evento | |
|---|---|
| Capturar | requestHeader.requestId
001 requestHeader.requestTimestamp 01/01/2017 23:26:32.253 responseHeader.responseTimestamp 01/01/2017 23:26:34.248 marca de tiempo de {i>accounting071/40281:0 01:81 |
| Capturar | requestHeader.requestId
002 requestHeader.requestTimestamp 01/01/2017 23:59:58.253 responseHeader.responseTimestamp 01/01/2017 23:59:59.879 marca de tiempo de los datos07 01/01 |
| RemittanceStatementNotification | requestHeader.requestTimestamp
01/03/2017 03:17:18.132 billingPeriod.startDate 01/01/2017 00:00:00.000 billingPeriod.endDate 01/01/2017 captura 293.59.19 |
| RemittanceStatementNotification | requestHeader.requestTimestamp
01/03/2017 00:27:34.321 billingPeriod.startDate 01/02/2017 00:00:00.000 billingPeriod.endDate 01/02/2017 290t.29.2017 capture 293.59. Dado que 002 se registró el 02/01/2017, no el 01/01/2017. |
Conciliación
En algunos casos, es posible que Google envíe una declaración de remesas más tarde de lo esperado. Por ejemplo, si Google encuentra un error que retrasa la notificación del resumen de remesas un día.
Si el método remittanceStatementDetails muestra transacciones que el integrador no tiene dentro del período de facturación, debe notificar a Google de la discrepancia de inmediato. Otra posibilidad sería si hay transacciones que el integrador espera, pero no se muestran. Cuando se resuelva la discrepancia, Google podrá enviarte un nuevo resumen de remesa con un ID nuevo.
Aceptación de la Declaración de Remesa
Se dice que el integrador acepta una declaración una vez que llama al método acceptRemittanceStatement.
Los resúmenes deben pagarse dentro de los términos NET definidos en el contrato después de la aceptación. El integrador y el administrador de cuentas deben abordar las impugnaciones de forma manual.
Pago
Los resúmenes de remesas proporcionan los detalles necesarios del importe que se debe pagar. Cada resumen se debe pagar en su totalidad. Si hay discrepancias, el integrador debe comunicarse con su administrador de cuentas para manejar la disputa. En esos casos, es posible que no pague el importe total del resumen.
Precisión
Cada tarifa se calculará con la precisión definida como la cantidad de unidades menores especificadas en la norma ISO 4217 para esa moneda. Por ejemplo, INR y USD usarán unidades menores de 2 dígitos y JPY usarán unidades menores de 0 dígitos.
Si se necesitan más decimales para representar la tarifa, Google redondeará a la unidad menor más cercana; los empates se redondearán a la unidad menor par más cercana. Por ejemplo, con unidades menores de 2 dígitos de INR:
| Tarifa calculada | Tarifa redondeada |
|---|---|
| 0.013 | 0.01 |
| 0.015 | 0.02 |
| 0.025 | 0.02 |
| -0.013 | -0,01 |
| -0,025 | -0,02 |
Este redondeo se producirá en cada transacción, no de forma agregada en el resumen.