NEGOCIO
GLOBAL

Cubra todas sus necesidades para gestionar un NEGOCIO GLOBAL en BUSINESS CENTRAL.
En este artículo explicamos qué debería exigir, cómo evitar las personalizaciones y qué APPS utilizar.

Cuando gestionamos varias empresas con Business Central, surgen algunas necesidades adicionales. Suele deberse a que tenemos empresas en varios países, pero también puede tratarse simplemente de varias empresas en el mismo país.

Las empresas suelen tener distintos roles en la cadena de suministro, por ejemplo, empresas de logística, empresas de producción y empresas de ventas, con una serie de procesos entre ellas.

Intercompañía

Tenemos una empresa de ventas que recibe pedidos de venta porque recibe pedidos de los clientes finales. La empresa de ventas envía previsiones a la central, que planifica la necesidad de producto y recurre al almacén o a la empresa de logística para entregar, o a una empresa de logística externa, y en algunos pedidos la empresa de logística puede entregar directamente al cliente final.

La central también compra mercancías a la empresa de producción, que utiliza varios proveedores externos, fabrica los artículos y los entrega en un contenedor a la empresa de logística o almacén.

Es solo un ejemplo. Sea cual sea la estructura de nuestra empresa, debemos poder gestionarla en Business Central, y los procesos deben estar respaldados para que no tengamos que gestionar manualmente todos los datos y la contabilidad.

De forma estándar, Business Central gestiona bien las transacciones intercompañía, especialmente con la versión de octubre de 2023, pero enseguida necesitamos más estructura y automatización para poder registrar automáticamente en varias empresas a la vez.

Cuando la empresa de ventas crea un pedido de compra, debe crearse automáticamente un pedido de venta en la empresa que va a entregar, y así sucesivamente a lo largo de la estructura de empresas. También queremos poder ver los niveles de existencias en otras empresas, de modo que, ya al tomar el pedido del cliente, podamos ver si el artículo está en stock en otra empresa.

También necesitamos gestionar los precios entre empresas. Además, supone un reto si tenemos tipos de cambio distintos en diferentes empresas.

Necesitamos utilizar la misma fuente para los precios y los tipos de cambio, de modo que las eliminaciones sean más sencillas y obtengamos los mismos valores en los mismos artículos en las cuentas de consolidación.

Gestión global de datos maestros

La gestión de datos maestros es un tema importante en una corporación con muchas empresas (entidades jurídicas). Debemos contar con una estructura global para los datos maestros y poder sincronizarlos entre empresas, y debemos incluir los datos maestros en los documentos utilizados en los pedidos de venta, de compra y de transferencia entre todas las empresas. Profundizamos en los datos maestros en un capítulo aparte.

Quizá tengamos cinco empresas distintas que, en la práctica, tendrán los mismos clientes, artículos, datos maestros, etc. Cuando creamos un nuevo artículo en la sede central, queremos que se replique en las demás empresas para no tener que crearlo varias veces ni mantenerlo en varias empresas. Necesitamos datos maestros organizados en una jerarquía de maestro y suscriptores.

Contenedores

Los contenedores son un tema importante si enviamos mercancías a larga distancia, tanto si enviamos como si recibimos mercancías en contenedores.

Como compradores, puede que tengamos un contenedor en el proveedor que vamos llenando poco a poco con pedidos de compra y, cuando está suficientemente lleno, lo enviamos hacia nosotros. Entonces nos gustaría gestionar conjuntamente todos los pedidos de compra del contenedor. Si el contenedor se retrasa 4 días por el camino, querríamos actualizar todas las líneas de compra de una vez y detectar los conflictos que esto genera.

De la misma manera, si somos el vendedor, somos nosotros quienes enviamos el contenedor y queremos planificar su capacidad lo mejor posible antes de despacharlo.

Surtidos

A menudo hay diferencias en cuanto a qué mercancías y variantes se pueden comprar y vender en las distintas empresas.

En la empresa de almacén tenemos 8 colores de un artículo, y una empresa de ventas debe comprar los 8, mientras que otra solo puede comprar 2 de los colores porque solo comercializa esos 2.

En la tienda online también deben aparecer los 8 colores para los clientes del primer país, pero solo 2 para los clientes del segundo país. Y la central ha decidido que uno de los colores debe descatalogarse, por lo que solo deben reponerse 7 de los colores al proveedor.

La estructura internacional debe poder gestionar todo eso en Business Central.

Embalajes y etiquetas

Cuando ofrecemos mercancías a muchos países, los embalajes y las etiquetas suponen un reto especial. Una etiqueta de ingredientes puede contener 3 idiomas: inglés, español y portugués, y esto determina en qué países se puede vender el producto.

Tenemos el mismo artículo en stock con otras combinaciones de idiomas, por ejemplo, inglés, italiano y griego. Puede que tengamos 1000 unidades del artículo en stock y podamos entregar las 1000 a países de habla inglesa, pero solo podamos entregar 80 a Italia porque las otras 920 no tienen italiano en la etiqueta de ingredientes.

Las numerosas variantes de embalajes y etiquetas suponen un reto adicional en Business Central.

Informes y seguimiento

Los informes tienen que ver con la inteligencia empresarial (Business Intelligence). En un entorno global, nos gustaría poder elaborar informes de toda la estructura de la empresa. ¿Qué vendemos en qué partes del mundo? ¿Cuáles son nuestros plazos de entrega?

Si Business Intelligence muestra que el plazo de entrega de un artículo es en realidad de 3 meses, pero los datos maestros del artículo en el ERP indican 2 meses, deberíamos corregir los datos maestros para no prometer a los clientes algo que no podemos cumplir.

Consolidación

La consolidación financiera es otro tema que a menudo se gestiona con una herramienta de informes.

Nos gustaría poder analizar las unidades de la estructura de la empresa de forma comparable. No tiene sentido tener que mapear los datos desde cero cada vez para obtener cifras comparables. Debemos poder gestionar la estructura de forma centralizada para todo el grupo.

Normalmente elaboramos una cuenta de grupo, en la que consolidamos todos los datos de las empresas subyacentes y eliminamos la transacción. A menos que todas las empresas utilicen Business Central, es inteligente llevar a cabo la consolidación con una solución de Business Intelligence, pero esto requiere que tengamos planes de cuentas y códigos de dimensión armonizados en todas las empresas.

Si nuestra empresa opera a nivel internacional, o si tenemos muchas empresas en nuestro sistema ERP que deben integrarse, la «intercompañía» es un tema importante.

En una empresa de ventas creamos un pedido de venta para un cliente; cuando lo liberamos, debe crearse un pedido de compra para comprar el artículo a otra empresa del grupo, y debe crearse (automáticamente) un pedido de venta en la empresa de producción o de inventario de nuestro grupo.

Ahora tenemos tres documentos de pedido vinculados entre sí en dos empresas, y debemos poder gestionarlos conjuntamente y modificarlos como uno solo.

Gestión de cambios

La gestión de los cambios es la parte difícil. En la empresa de producción debemos poder modificar cantidades o precios, y que el cambio se propague tanto al pedido de compra como al pedido de venta de la empresa de ventas.

Debemos poder hacer un cambio en cualquiera de los tres registros, y el cambio debe reflejarse en los demás. De nada sirve que nuestra solución sea demasiado rígida para dar soporte al mundo en el que vivimos.

Hay varios ámbitos en los que necesitamos flexibilidad en el día a día.

Un único pedido de venta

Nuestra empresa de ventas necesita poder crear un pedido de venta con líneas de varias empresas, por ejemplo, dos artículos de la propia empresa de ventas local, cuatro artículos de la empresa de inventario de Alemania y tres artículos que debe producir la empresa de Polonia.

Envío directo

Debemos poder indicar si se trata de un envío directo, es decir, si todas las empresas deben enviar los artículos directamente al cliente final, o si las empresas de Alemania y Polonia deben enviar los artículos a nuestra empresa de ventas local, que después los enviará al cliente.

De hecho, este es uno de los aspectos más difíciles de las transacciones intercompañía. Si las empresas de Alemania y Polonia envían directamente al cliente, deben poder adjuntar un albarán o una factura impresos con la lógica de la empresa de ventas local original, que es, al fin y al cabo, con la que ha tratado el cliente. Esto se complica cuando intervienen distintas empresas y entidades contables.

Cuando la empresa local vende a un cliente local con precios y descuentos locales, los documentos deben poder salir de la impresora en Alemania y Polonia.

Seguimiento de artículos

También queremos poder hacer el seguimiento de los artículos entre empresas.

Cuando el operario de almacén en Alemania prepara artículos con números de serie, debe escanear el número de serie, y este debe fluir hasta nuestra empresa de ventas local para que podamos ver localmente qué números de serie se han preparado para el pedido.

Configuración

Con la configuración de artículos, los datos deben fluir en sentido contrario. Registramos las especificaciones del artículo configurado, y quizá el hecho de que haya que imprimir el logotipo de una empresa en la tapa, en el pedido de venta local. Estos detalles deben fluir entonces a la empresa de producción de Polonia, que fabricará los artículos e imprimirá el logotipo en la tapa.

Gestión de errores

Por último, ¿cómo gestiona los errores la solución intercompañía? Si algo falla entre empresas (por ejemplo, si el número de artículo no existe en la otra empresa), ¿el pedido pasa a un registro de errores que alguien debe revisar antes de que el pedido pueda continuar?

Recomendamos sin duda que la solución funcione en línea y que los errores se devuelvan al usuario en tiempo real. Esto significa que, si en nuestra empresa de ventas local introducimos un pedido que retirará artículos de las empresas de Alemania y Polonia, veremos cualquier error en pantalla de inmediato mientras escribimos, de modo que no podamos avanzar en el proceso hasta que se haya resuelto el error.

Notamos un claro aumento de la demanda de soluciones intercompañía. Sin duda es cada vez más habitual que las transacciones crucen fronteras y empresas.

Los fundamentos son razonablemente sencillos, pero la flexibilidad ante los retos del día a día es el verdadero sello de una buena solución intercompañía.

Puede que tengamos cinco empresas distintas (entidades jurídicas) que, en la práctica, tendrán los mismos clientes, artículos, datos maestros, etc. Cuando creamos un nuevo artículo en la sede central, queremos que se replique en las demás empresas para no tener que configurarlo varias veces.

También puede que tengamos un sistema ERP distinto en una de las filiales. Necesitamos que los datos maestros se sincronicen en todas las plataformas, tanto en Business Central como en otros sistemas ERP de la corporación. Esto también se aplica a los datos maestros que hemos creado nosotros mismos, es decir, color, talla, material u otros muchos tipos de datos maestros en artículos, clientes y proveedores.

El reto es conseguir que los distintos sistemas ERP, con estructuras de datos diferentes, se comuniquen entre sí. Debemos pensar con detenimiento al desarrollar una estructura de datos para asegurarnos de que las claves coincidan en todas las empresas, en los distintos sistemas ERP.

Estrategias de sincronización de datos

Podemos elegir entre varias estrategias.

Una estrategia centralizada significa que tenemos una empresa principal en la que configuramos todos los datos maestros de forma consolidada, reuniendo todos los deudores, todos los artículos y todo lo demás que queremos que gestione el equipo central. El sistema «empuja» los datos desde la empresa principal hacia las empresas periféricas.

La gestión central tiene ciertas ventajas, pero el inconveniente es que los datos son más difíciles de mantener cuando menos personal tiene acceso.

Quizá un usuario local en Francia nota que un dato concreto de un artículo es incorrecto, pero no llega a corregirse porque comunicarlo a la sede central es un gran esfuerzo. Si corrige sus datos locales, simplemente serán sobrescritos por los datos de la empresa principal cuando se ejecute la siguiente tarea de sincronización.

Por ello nos inclinamos por una estrategia híbrida en la que los datos puedan sincronizarse en ambos sentidos.

Está bien que los datos se recopilen en una empresa principal central, pero consideramos fundamental que los usuarios locales puedan actualizarlos, de modo que el usuario francés pueda actualizar los datos locales del artículo, y la modificación se sincronice de vuelta con la empresa central, y la siguiente tarea de sincronización replique su modificación en todas las empresas.

Naturalmente, debemos controlar los derechos de edición que necesita, es decir, qué campos puede actualizar y cuáles no debe tocar.

También necesita poder introducir datos en francés sin que se sobrescriban otras variantes de idioma.

Además, necesita poder crear un artículo que solo sea relevante en Francia y que no deba difundirse a otras empresas.

Cuanto mayor es la corporación, y cuantos menos artículos tenemos o menos dinámica es nuestra estructura de artículos, más relevante nos parece una estrategia centralizada con una empresa principal.

Esto también se aplica si tenemos controles de calidad estrictos sobre nuestros artículos y nuestro departamento de desarrollo o calidad asegura y depura los datos de forma muy rigurosa. En estos casos tiene sentido prescindir de la actualización y la innovación descentralizadas.

Suscripción a los datos

Debemos poder construir una estructura de datos maestros con un propietario de los datos y suscriptores de los datos. En cada filial elegimos los datos a los que queremos suscribirnos.

Por ejemplo, si hay una filial francesa en un grupo alemán, la filial francesa puede suscribirse a artículos, clientes y otros datos maestros compartidos, pero también puede crear artículos locales que solo sean relevantes en Francia.

Si la filial francesa compra un artículo que solo existe en Francia, no tiene sentido replicar ese número de artículo en otras 20 filiales de todo el mundo.