Los ingresos, comisiones y devoluciones de Square se contabilizan por ubicación en Microsoft Dynamics 365 Business Central, de modo que el día de cada tienda coincide con el depósito bancario que realmente generó.
Cada ubicación de Square produce un día comercial, una liquidación de tarjeta que llega neta de comisiones, y un depósito que rara vez coincide con ambos. Business Central necesita asientos contabilizables por tienda, y sin conexión alguien introduce los totales desde el panel de Square, contabiliza las comisiones como una suma global, y no puede explicar por qué la tienda tres está descuadrada por unos euros. El comercio multiubicación agrava esto con cada nueva ubicación. Conectar Square y Microsoft Dynamics 365 Business Central mediante Alumio resuelve esto por ubicación: los ingresos se contabilizan por tipo de pago, las comisiones se separan, y las devoluciones se revierten contra la venta.

Los ingresos se contabilizan en Business Central por ubicación de Square, de modo que una discrepancia se rastrea hasta el día de una tienda en lugar de perseguirse en una cifra combinada para toda la red.
Las comisiones de procesamiento se contabilizan en su propia cuenta en lugar de deducirse de los ingresos, lo que mantiene visible en la cuenta de resultados el coste real de aceptar tarjeta por ubicación.
Las liquidaciones se vinculan a las ventas que cubren, de modo que el depósito bancario se ata a los asientos contabilizados sin que nadie reconstruya el vínculo desde dos paneles separados.
Añadir una ubicación de Square es un paso de configuración en lugar de una nueva tarea de captura diaria, de modo que la expansión de la red no aumenta en paralelo la carga de trabajo de finanzas.
Cuando una ubicación de Square cierra su día, Alumio contabiliza los ingresos en Business Central desglosados por tipo de pago y codificados a esa tienda, de modo que las cuentas muestran el comercio de cada ubicación sin que nadie introduzca totales desde un panel.
Una liquidación de Square se vincula a las ventas que cubre con las comisiones contabilizadas por separado, de modo que el depósito concilia exactamente y finanzas puede explicar la diferencia entre ingresos brutos y caja recibida un día dado.
Una devolución procesada en Square crea el asiento de reversión de Business Central contra la venta y ubicación originales, de modo que las cifras de la tienda y la ficha del cliente coinciden sin un asiento manual para cerrar la diferencia después.
Alumio se sitúa entre los canales de venta y los sistemas de cumplimiento como una columna vertebral de integración gobernada. Los pedidos se enrutan, transforman y validan, mientras que las actualizaciones de estado regresan a cada canal.
Autentique sus sistemas utilizando los conectores preconfigurados de Alumio. Elija entre más de 200 paquetes de conectores en el marketplace, además de integraciones personalizadas ilimitadas.
Defina cómo se asignan los campos de datos entre sistemas en una interfaz visual. Ajuste formatos, enriquezca registros y aplique lógica de negocio, sin necesidad de código personalizado.
Configure los flujos para que se ejecuten en tiempo real según eventos, según un horario o ambos. Reduzca la entrada manual de datos y deje que Alumio gestione el movimiento y la transformación entre sistemas.
Una vez que su primera integración esté activa, añadir su ERP, PIM, WMS o CRM se conecta al mismo centro. Los flujos existentes siguen funcionando. Sin necesidad de reconstruir desde cero.
Pueden conectarse más sistemas, y el inventario o un canal de comercio electrónico es el añadido habitual, ya que Square registra la venta mientras el stock de los mismos productos también puede comprometerse online. Alumio los conecta, de modo que una venta en tienda reduce la disponibilidad que la tienda online está dispuesta a ofrecer en lugar de que ambos canales vendan la misma unidad dos veces.
Sí. Alumio lee ingresos, tipos de pago, comisiones, devoluciones y liquidaciones desde Square y los contabiliza en Business Central codificados con la ubicación correspondiente, al cerrar los días o al llegar las liquidaciones. Los tipos de pago permanecen separados a lo largo del flujo, lo que hace que los asientos resultantes sean conciliables con el banco en lugar de solo correctos en total.
El mapeo de ubicaciones, la codificación de cuentas, la contabilización de comisiones y la vinculación de liquidaciones se establecen todas en la interfaz de Alumio, lo que sustituye la captura manual diaria en la que suelen apoyarse los minoristas. Añadir una tienda se convierte en configuración en lugar de una nueva tarea. Si una regla de propina, recargo o multimoneda necesita un tratamiento propio, el Code Transformer la cubre.
Tantas como la empresa opere, siempre que cada una se mapee a algo sobre lo que Business Central pueda informar, lo cual merece diseñarse desde el principio. Las ubicaciones suelen mapearse a dimensiones en lugar de empresas separadas, de modo que una sola empresa puede llevar toda la red mientras informa por ubicación. Alumio aplica esa codificación a medida que se contabilizan los asientos, así que la estructura se sostiene a medida que se añaden ubicaciones.
Ningún ingreso de tienda se contabiliza dos veces, y ninguno se pierde. Alumio registra cada mensaje con su contenido, supervisa ambos vínculos en tiempo real, y notifica de inmediato a finanzas cuando Business Central rechaza un asiento, nombrando la ubicación, la fecha y la causa. Los reintentos sin supervisión resuelven los bloqueos temporales, y un día sin contabilizar permanece en la cola de excepciones en lugar de desaparecer.
Habla con un especialista en integración de Alumio. Diseñaremos la arquitectura adecuada para tus sistemas, a la escala correcta, para que tus operaciones sigan siendo fiables ante cualquier cambio.