El pago que llega al banco es el importe de la venta menos una serie de factores que la plataforma de mercado ha determinado, y SAP Business One necesita esos tres factores en lugar de simplemente la cantidad recibida.
Un marketplace no te paga lo que el cliente pagó. Cobra su comisión, sus gastos de gestión y otros cargos aplicables, y envía la diferencia, por lo que el dinero que llega al banco no coincide con ningún pedido en el sistema. La solución habitual es una hoja de cálculo a fin de mes donde alguien calcula retrospectivamente desde el pago hasta las ventas que cubre y registra la diferencia como un único cargo denominado comisiones. La conexión de ChannelEngine con SAP Business One permite que la venta, la comisión y el beneficio neto lleguen como tres hechos separados, de modo que el libro mayor refleje lo que realmente sucedió, en lugar del remanente.

Las comisiones y los gastos de gestión llegan a SAP Business One como importes independientes, en lugar de como una diferencia que alguien registra a final de mes y denomina "tarifas", por decirlo de alguna manera.
El pago se suma a las órdenes que cubre a medida que llega, por lo que nadie tiene que hacer cálculos retrospectivos, desde una línea bancaria hasta una semana de operaciones en el mercado, utilizando una calculadora y una hoja de cálculo.
Dado que lo que cobra cada canal es independiente de lo que vende, la pregunta de en qué mercado realmente vale la pena operar tiene una respuesta en los registros contables, en lugar de una opinión.
El reembolso llega a SAP Business One contra la venta que revierte, en lugar de como una deducción dentro del siguiente pago, que es donde las devoluciones generalmente desaparecen de la vista de todos.
Cuando ChannelEngine informa de un pago, Alumio contabiliza las ventas, la comisión y el importe neto por separado en SAP Business One, de modo que la línea bancaria y el libro mayor coinciden sin que nadie tenga que reconstruir los cálculos posteriormente.
Cuando llega un pedido de Marketplace sin un cliente reconocido por SAP Business One, Alumio lo resuelve según la regla que usted haya configurado, en lugar de crear una para cada comprador, de modo que el libro mayor no se llene con nombres que nadie ve dos veces.
Cuando se deduce una devolución de un pago, esta llega a la venta que revierte en lugar de reducir el total discretamente, por lo que el margen de ese pedido refleja el hecho de que la mercancía volvió al almacén.
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.
Las devoluciones en el mercado se gestionan mediante un servicio que el canal te obliga a usar, y ninguno de estos sistemas las registra. Una devolución que fue clasificada y revendida es diferente a una que fue cancelada, y el margen del canal es incorrecto hasta que esa distinción se refleja en el libro mayor. Alumio mantiene esa conexión junto con esta, por lo que la información es completa, no solo parcial.
Sí, y conviene tratar los pedidos y los pagos como entradas independientes en lugar de una sola. Un pedido se registra cuando se realiza y el dinero llega días o semanas después, por lo que forzarlos a un solo paso implica que el libro mayor se queda esperando. Alumio registra cada uno en su propio ciclo, y lo que se puede crear es lo que SAP Business One expone para ello.
No. La configuración indica qué cargo del marketplace se asigna a qué cuenta y a qué cliente se registra un pedido del canal. Estas son decisiones que el equipo de finanzas toma una sola vez y que puede consultar posteriormente. Si un canal informa un cargo en un formato que no se encuentra en el libro mayor, el Transformador de Código lo resuelve en ese mismo paso.
Dondequiera que decida el departamento de finanzas, que es precisamente la razón de separarlos. Un pago que llega como una sola cifra solo aporta un número al libro mayor, sin ninguna explicación, y la comisión por una venta es un costo de venta, no un descuento sobre el precio. Registrar la venta bruta y el cargo por separado permite que el margen, el tratamiento del IVA y la comparación de canales funcionen sin que nadie tenga que analizar previamente una línea bancaria.
El único caso que provoca un retraso a fin de mes es un pago que no coincide con ninguna orden, ya que el dinero es real pero no se identifican las ventas que lo respaldan. Alumio indica qué transacciones no se pudieron realizar y con qué, por lo que la búsqueda se centra en un solo pago en lugar de una semana de operaciones. Cada transferencia se monitoriza en tiempo real y se registra con su contenido; en caso de rechazo, se generan alertas con el motivo; se realizan reintentos donde esté configurado, y no se pierde información de forma silenciosa.
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.