Multisede y multimoneda de facturación

Visión general

La sede de facturación es una entidad física situada en una determinada ubicación que tiene la posibilidad de emitir documentos de factura. Será la que constará como emisora de la factura de un pedido.

Una sede de facturación dispone de estas posibilidades e información:

Los datos fiscales de la propia sede, los cuales constarán como los datos del emisor en las facturas.
Las monedas asociadas en las que puede facturar. Solo puede tener vinculadas aquellas monedas que se hayan habilitado en el Commerce.
La zona de influencia asociada o conjunto de áreas geográficas donde puede emitir facturas. Las ubicaciones que no pertenezcan a estas áreas no podrán ser objeto de venta y facturación desde la sede en cuestión.
Puede aplicar impuestos al documento de venta y de factura en función del país donde esté ubicada.

Configuración

Un Commerce debe tener al menos una sede de facturación activa, la cual debe estar relacionada con al menos un canal activo. Como los canales admiten más de una sede, es necesario establecer una prioridad, que es la que marca el orden que seguirá el sistema para vincular una sede de facturación a un proceso de compra (el sistema siempre seguirá el orden de menor a mayor valor indicado en la propiedad Prioridad). Así pues, de entre todas las sedes compatibles de un canal, el sistema asignará la sede definida como la primera (por ejemplo, con prioridad 1).

La sede de facturación puede tener una zona de influencia, es decir, el conjunto de áreas geográficas donde opera la seda de facturación. Debes tener en cuenta que, si esta zona es incompatible con la del canal, la sede de facturación queda invalidada dentro del canal. Por lo tanto, las sedes de facturación válidas de un canal deben tener zonas de influencia comunes o incluidas en las del canal. Además, la relación entre canal y sede de facturación habilita restricciones por zona que limitarán todavía más las zonas de influencia permitidas.

Ejemplo: Tienes un canal C1, que opera en China, con sedes de facturación S1 y S2, y cuya zona de influencia es también China. Si un usuario tiene una dirección de Pekín o de Hong Kong, el sistema dirá que debe facturar en S1 (supongamos que S1 tiene más prioridad que S2) en ambos casos. Si restringes la relación entre C1 y S1 a la zona de Hong Kong únicamente, el sistema dirá que para los usuarios de Hong Kong hay que facturar en S1, mientras que para los usuarios de Pekín hay que facturar en S2.

Textos legales

La sede de facturación contiene los datos fiscales que se vincularán a la factura. Como la selección de la sede dependerá del canal y la ubicación, cada sede puede tener sus propios datos fiscales. Esto permite tener múltiples entidades fiscales y segmentar a una u otra dependiendo del canal.

Cada sede de facturación contiene los textos legales que el Commerce debe tener para poder informar al usuario sobre las particularidades del proceso de compra y tratamiento de datos. Estas particularidades pueden estar relacionadas con los datos fiscales o con características del negocio. Por lo tanto, es necesario que cada sede pueda disponer de sus propios textos legales. Si esos textos son comunes para todas las sedes, simplemente habrá que copiarlos en cada una de ellas.

Documentos

El Commerce puede emitir diferentes tipos de documentos durante y después del proceso de compra. Estos documentos tienen como origen una sede de facturación y, al igual que ocurre con los textos legales, es posible que cada sede de facturación necesite disponer de su propia plantilla de numeración de los diferentes documentos que emita. De esta manera, una sede puede tener una serie de facturación con un prefijo y un sufijo determinados, y otra tendrá una numeración con otro prefijo y sufijo. Esto permite distinguir la facturación, y agilizar su contabilidad y gestión. Puedes crear plantillas para los siguientes documentos:

Pedidos
Albarán de entrega
Factura
Petición de devolución
Devolución
Factura rectificativa

Impuestos

Al definir los impuestos del Commerce, se debe establecer a qué país afectan, de tal manera que cada país aplicará los impuestos que se le vinculen. Como el elemento que gestiona la fiscalidad es la sede de facturación, los impuestos del país que se asocie a una sede serán los que se aplicarán en las ventas que se realicen bajo esa sede. Los correspondientes tipos impositivos de cada uno de los impuestos deben vincularse luego en los productos, para que el sistema sepa cuál debe aplicar en un proceso de compra.

Ejemplo: Una sede de facturación S1 tiene como zona de influencia Francia. A S1 se vincula un impuesto TAV que aplica, en su tipo impositivo estándar, un 20 % sobre el precio de un producto. Otra sede de facturación, S2, tiene como zona de influencia Alemania y se vincula un impuesto MWSt que aplica, en su tipo impositivo estándar, un 19 % sobre el precio de los productos. A un determinado producto P1 se le vinculan los tipos impositivos del 20 % (procedente del TAV) y del 19 % (procedente del MWSt). S1 está asociada a un canal de venta C1 cuya zona de influencia es Francia, y S2 está asociada a un canal de venta C2 con Alemania como zona de influencia. Si un usuario de Francia quiere comprar P1, se le asignará C1 a su proceso de compra y, por lo tanto, se vinculará con S1. A la compra se le aplicará el impuesto TAV, que es el vinculado a S1 y, como resultado, se aplicará un 20 % a P1. Si un usuario de Alemania quiere comprar P1, se le asignará C2 a su proceso de compra y esta se vinculará con S2; por lo tanto, se aplicará el impuesto MWSt, que es el que tiene asociado S2. Como resultado, se aplicará un 19 % a P1.

Los tipos de impuestos que la sede de facturación puede aplicar no son únicamente sobre el valor añadido con cálculo estándar, sino que también puede aplicar otros con otro cálculo como, por ejemplo, recargos de equivalencia.

Monedas de facturación

El Commerce tiene un conjunto de monedas activas que son, a priori, las monedas de visualización de precios (también llamadas “monedas de navegación”). De entre todas esas monedas, debes escoger una como principal. Solo es obligatorio rellenar los precios de la moneda principal; es opcional para las demás monedas (consulta Precios).

La sede de facturación debe tener asociada al menos una moneda de facturación, que es la que usará para emitir facturas, y puede ser distinta a la principal. Solo es posible vincular las monedas de navegación, es decir, las que tiene habilitadas el Commerce. Por lo tanto, se puede dar el caso de que un usuario tenga asignada una moneda principal X, una moneda de visualización Y una moneda de facturación Z. El canal habilita la sede (consulta Sistema multicanal) y la sede habilita las monedas; así pues, el canal es la entidad que, de manera transitiva, habilita las monedas de facturación. Esto es importante porque, dependiendo del canal que se haya asignado a un determinado proceso de compra, el sistema podrá facturar en unas monedas u otras.

Si una sede dispone de más de una moneda de facturación, el sistema facturará en la moneda de navegación, si está disponible. Por ejemplo, si la sede puede facturar en euros y dólares, y un usuario está navegando en dólares, el sistema podrá facturar en dicha moneda porque está habilitada como moneda de facturación. En las monedas de facturación es necesario establecer una prioridad, que es la que marca el orden que seguirá el sistema para vincular la moneda. Si el usuario está navegando en una moneda que no está disponible en la sede como moneda de facturación, el sistema facturará en la moneda de facturación de la sede con mayor prioridad.

Si la sede de facturación tiene varias monedas de facturación definidas y la moneda de navegación del usuario coincide con una de ellas, el sistema siempre facturará en la moneda de navegación, independientemente del nivel de prioridad que tengan asignadas las monedas.

Ejemplo: Si las monedas de facturación de la sede son euros, dólares y yenes en este orden, y el usuario está navegando en yenes, el sistema facturará en yenes aunque sea la de menor prioridad. La priorización de las monedas de facturación solo se aplica cuando la moneda de navegación no está definida como moneda de facturación.

Si la factura se emite en la moneda de facturación, el cálculo de la cesta también se hará en esta moneda. Sin embargo, dependiendo de si la moneda de navegación es la de facturación, y si la moneda de navegación tiene precio propio, el cálculo de precios que se hará en la cesta puede ser distinto.

Ejemplo: Supongamos que un Commerce tiene dos sedes de facturación con Europa y China respectivamente como zona de influencia. A la sede de Europa se vincula el euro como moneda de facturación, mientras que a la de China se vincula el renminbi. El mercado principal del Commerce es Europa, por lo que su moneda principal es el euro. El Commerce necesita que las ventas en Europa se facturen en euros, y las ventas en China, en renminbis. El euro y el renminbi son dos de las monedas del Commerce, pero el Commerce tiene otras 3 monedas de navegación: el dólar, el yen y las libras. El precio de los productos del Commerce está indicado en la moneda principal (es obligatorio), pero también en renminbis y dólares.

El sistema gestiona esta configuración de la siguiente manera:

El sistema siempre devuelve el precio en la moneda de navegación seleccionada:
- Si la moneda de navegación es la principal, devolverá los precios en euros (principal).
- Si la moneda de navegación son renminbis o dólares, el sistema devolverá el importe en cualquiera de esas monedas en lugar de hacerlo en la moneda principal.
- Si la moneda de navegación son yenes o libras, como los precios no están indicados en esas monedas, el sistema tomará el precio de la moneda principal (euros) y hará una conversión de divisa a la moneda de navegación que corresponda para mostrar el precio en dicha moneda (el sistema actualiza diariamente los valores de cambio de divisa).
Si un proceso de compra se vincula al canal de venta europeo:
- El canal de venta europeo está vinculado a la sede de facturación de Europa y la moneda en la que se debe facturar (por imposición de la sede) es el euro.
- Aunque los precios se muestren en cualquiera de las monedas de navegación, el proceso de compra toma como moneda el euro (su moneda de facturación) para los precios y sus cálculos. Puede ocurrir lo siguiente:
  - Si la moneda de navegación es el euro, no hacen falta cálculos adicionales, sino que se toma el valor en euros directamente. La cesta, el documento de pedido y el posterior documento de factura estarán en euros.
  - Si la moneda de navegación es el dólar, el sistema toma los valores de precios en dólares directamente (los precios también están indicados en dólares) para mostrarlos en la cesta. Se tiene que facturar en euros y los cálculos internos de la cesta deben realizarse en euros. Como los precios están indicados directamente en dólares, el sistema transforma los precios de dólares a euros. Esto se hace así porque es posible que los precios en dólares, al ser directos, no sean una conversión de euros a dólares exacta. Por ejemplo, si el precio en euros son 10 € y el administrador del Commerce decide que el precio en dólares sea 10 $, si un usuario compra en dólares, al tener que facturar en euros, el sistema no puede tomar el valor en euros (10 €) directamente y usarlo porque el administrador ha dicho explícitamente que el producto en dólares vale 10 $. Por lo tanto, el sistema tiene que transformar esos 10 $ en euros para poder realizar los cálculos internos de la cesta. Como el cálculo dependerá del cambio de divisa de ese momento, los valores en euros pueden fluctuar. Para que quede constancia del valor usado en cada momento, el sistema guarda una versión de la cesta en la moneda de navegación, otra en la moneda de facturación y el valor de cambio de divisa que se usó.
    El resultado final será que el usuario verá la cesta y su respectivo documento de pedido en dólares (en la moneda de navegación). Cuando se genere la factura, esta se mostrará en euros (la moneda de facturación) y el usuario verá que el producto no vale 10 €, sino el resultado de la conversión de 10 $ a euros.
  - Si la moneda de navegación es el renminbi, pasará lo mismo que con el dólar porque esta moneda también tiene los precios indicados directamente. Cabe destacar que el renminbi es moneda de facturación en la sede de China, pero no en la de Europa, por lo que se facturará en euros y se hará la conversión de renminbis a euros.
  - Si la moneda de navegación es la libra o el yen, el sistema actuará igual que en el caso del dólar, pero como estas monedas no tienen los precios indicados directamente, hará la conversión de euros a libras o yenes en los precios de la cesta y del documento del pedido. El resultado final será que el usuario verá la cesta y su respectivo documento de pedido en la moneda de navegación (libras o yenes) mediante conversión. La factura se generará en euros y el usuario verá que el producto vale 10 €.
Si un proceso de compra se vincula al canal de venta chino:
- El canal de venta chino está vinculado a la sede de facturación de China y la moneda en la que se debe facturar (por imposición de la sede) es el renminbi.
- Aunque los precios se muestren en cualquiera de las monedas de navegación, el proceso de compra toma como moneda el renminbi (su moneda de facturación) para los precios y sus cálculos. Esto es lo que puede ocurrir:
  - Si la moneda de navegación es el renminbi no hacen falta cálculos adicionales, sino que se toma el valor en renminbis directamente. La cesta, el documento de pedido y el posterior documento de factura estarán en renminbis.
  - Si la moneda de navegación es el dólar, pasa lo mismo que en el caso de Europa, solo que el sistema hace la conversión a renminbis en lugar de a euros. El resultado final será que el usuario verá la cesta y su respectivo documento de pedido en dólares y, cuando se genere la factura, los precios se mostrarán en renminbis.
  - Si la moneda de navegación es el euro, ocurrirá lo mismo que en el caso anterior porque es una moneda con precios indicados directamente. Hay que destacar lo mismo que en el caso de Europa: el euro es la moneda de facturación de la sede europea, pero no de la china, por lo que la factura se generará en renminbis y se hará la conversión de euros a renminbis. Igual que en el caso de los dólares, para la factura no se usa el importe en renminbis que tengan los productos. Por ejemplo, si el producto vale 100 ¥, pero en euros vale 10 €, para la factura no se tomará 100 ¥, sino el resultado de convertir 10 € a renminbis, que no serán 100 ¥ exactos.
  - Si la moneda de navegación es la libra o el yen, el sistema actuará igual que en el caso del dólar, pero como estas monedas no tienen los precios indicados directamente, hará la conversión de renminbis a libras o yenes en los precios de la cesta y del documento del pedido.
    Nota importante : La conversión se hace partiendo siempre de la moneda principal, por lo que, aunque se facture en renminbis y no en euros, el valor de partida para la conversión a renminbis es el euro (moneda principal).
    
    Ejemplo: Si la moneda de navegación es la libra, el precio de un producto (10 €) se convertirá a libras. Supongamos que el cambio ese día está de la siguiente manera: 1 £ = 1,2 € y 1 ¥ = 0,12 €. El precio del producto serán 8,33 £ (10 €) en la cesta y el documento de pedido, y 83,33 ¥ (10 € igualmente) en la factura.

Excepciones a las monedas de facturación

Como ya hemos comentado, existe una relación entre canal y sede de facturación. Este vínculo permite configurar excepciones en las monedas de facturación (consulta Sistema multicanal):

En la relación entre un canal y una sede de facturación (con monedas vinculadas) se pueden definir excepciones a algunas de esas monedas. Esto permite restringir las monedas de facturación en caso de que un canal y una sede de facturación operen juntos.

Ejemplo: Tienes un canal C1, que está vinculado con la sede de facturación S1. S1 tiene como monedas de facturación el renminbi, el dólar de Hong Kong y el dólar taiwanés. En la relación entre C1 y S1 defines excepciones para el dólar de Hong Kong y el dólar taiwanés. Esto significa que, cuando S1 opere con cualquier otro canal, podrá facturar en renminbis, dólares de Hong Kong y dólares taiwaneses, pero cuando S1 opere con C1 solo podrá facturar en renminbis (porque los dólares de Hong Kong y los dólares taiwaneses están excluidos).
En una restricción de zona entre canal y sede de facturación (con monedas vinculadas) se pueden definir excepciones a algunas de esas monedas. Esto restringe las monedas de facturación de las sedes por ubicación geográfica.

Ejemplo: Tienes un canal C1 con sedes de facturación S1 y S2 que operan en China y facturan en renminbis, dólares de Hong Kong y dólares taiwaneses. Si la relación entre C1 y S1 se restringe por zona únicamente a Hong Kong (sin restricciones de moneda) significa que, para los usuarios de Hong Kong, el sistema dirá que hay que facturar en S1; además, puede hacerlo en renminbis, dólares de Hong Kong y dólares taiwaneses. Si en la restricción entre C1 y S1 defines excepciones de moneda para renminbis y dólares taiwaneses significa que, para los usuarios de Hong Kong, el sistema dirá que hay que facturar en S1, pero que solo puede hacerlo en dólares de Hong Kong.

Como las relaciones con el canal pueden invalidar monedas de facturación, en el caso de que una sede tenga múltiples monedas de facturación es importante definir un orden de prioridad para que el sistema pueda encontrar siempre una moneda de facturación. Si solo hubiera una moneda preferente como moneda de facturación y el canal definiera una excepción para esa moneda, el sistema no sabría qué moneda usar. También es importante configurar las excepciones con atención para evitar que se pueda facturar en una moneda no esperada.