Multi-Invoicing Company and Multi-Currency Accounting

Overview

The invoicing company is a physical entity located in a particular place that is able to issue invoices, and which will be shown as the issuer of the invoice for an order.

An invoicing company has these possibilities and information:

The tax details of the company itself, which will appear as the issuer details on its invoices.
The associated currencies in which it can invoice. Only those currencies that have been activated in the Commerce can be linked to it.
The associated area of influence or set of geographical areas where it can issue invoices. Locations outside of these areas cannot receive sales or invoices from the company in question.
Taxes may be applied to the document of sale and invoice depending on the country where it is located.

Configuration

A Commerce must have at least one active invoicing company, which must be associated with at least one active channel. As channels can have more than one company, a priority must be established to decide the order the system will follow to link an invoicing company to a shopping process (the system will always follow the order from the lowest to the highest value specified in the Priority property). Thus, among all the companies compatible with a channel, the system will assign the company set as the first one (for example, with priority 1).

The invoicing company can have an area of influence, i.e. the set of geographical areas where the invoicing company operates. Note that, if the area of the invoicing company is not compatible with that of the channel, the invoicing company is invalidated within the channel. Therefore, the invoicing companies valid for a channel must have areas of influence in common or that are included within those of the channel. Moreover, the relationship between channel and invoicing company sets restrictions by zone that will further limit the allowed areas of influence.

Example: You have a channel CH1 which operates in China, with invoicing companies IC1 and IC2 whose area of influence is also China. If a user's address is in Beijing or Hong Kong, the system will say that invoicing must be from IC1 (supposing that IC1 has a higher priority than IC2) in both cases. If you restrict the relationship between CH1 and IC1 to the Hong Kong area only, users in Hong Kong must be invoiced from IC1, while users in Beijing must be invoiced from IC2.

Legal Texts

The invoicing company has the tax details that will be linked to the invoice. As the selection of the company will depend on the channel and the location, each company can have its own tax details. This allows for multiple fiscal entities and targeting to one or another depending on the channel.

Each invoicing company has the legal texts the Commerce needs to be able to inform users of the particulars of the shopping process and data protection. These particulars may be related to the tax data or to features of the business. It is therefore necessary for each company to have its own legal texts. If these texts are common to all the companies, you can simply copy them to each of the companies.

Documents

The Commerce may issue different types of document during and after the shopping process. These documents originate at an invoicing company and, like the legal texts, each invoicing company may need to have its own numbering template for the different documents it issues. So, one company might have an invoicing series with a certain prefix and suffix, while another might have a numbering with a different prefix and suffix. This allows their invoices to be distinguished, and streamlines accounting and management. You can create templates for the following documents:

Order
Delivery note
Invoice
Return request
Return
Corrective invoice

Taxes

When taxes are defined for the Commerce, it must be established which country they affect, so that each country will apply the taxes associated with it. As the element that handles taxation is the invoicing company, taxes in the country associated with this company will be the ones to apply to sales made for the said company. The rates of each of the taxes must be linked afterwards, to the products, so that the system knows which to apply in the shopping process.

Example: Invoicing company IC1 has France as its area of influence. A TVA tax is linked to IC1 and it applies this at its standard rate, 20% of the price of a product. Another invoicing company, IC2, has Germany as its area of influence and has the MWSt tax linked to it at its standard rate, 19% of the price of a product. A particular product P1 has two tax rates linked to it: 20% (for TVA) and 19% (for MWSt). IC1 is associated with sales channel CH1, whose area of influence is France, and IC2 is associated with sales channel CH2 with Germany as its area of influence. If a user in France wants to buy P1, CH1 will be assigned to their shopping process, and therefore it will be linked to IC1. The TVA tax will be applied to their purchase, as this is the tax linked to IC1 and, as a result, 20% will be applied to P1. If a user in Germany wants to buy P1, CH2 will be assigned to their shopping process, and therefore it will be linked to IC2; therefore, the MWSt tax will be applied, as this is the one linked to IC2. As a result, 19% is applied to P1.

The tax rates the invoicing company can apply are not only value added tax at a standard rate; it can also apply others, calculated in different ways, such as equivalence surcharges.

Accounting Currencies

The Commerce has a set of active currencies which are, a priori, the display currencies for prices (also referred to as "browsing currencies"). One of these currencies must be chosen as the main one. It is only mandatory to enter prices for the main currency; for other currencies it is optional (see Pricing System).

The invoicing company must be associated with at least one accounting currency, which is the one it will use to issue invoices, and may be different from the main one. It is only possible to link to browsing currencies, i.e. those the Commerce has enabled. Therefore, a user can have main currency X, display currency Y and accounting currency Z assigned to them. The channel enables the company (see Multi-Channel System) and the company enables the currencies; thus, the channel is the entity that determines accounting currencies. This is important because, depending on which channel was assigned to a particular shopping process, the system can invoice in one currency or another.

If a company has more than one accounting currency, the system will invoice in the browsing currency, if this is available. For example, if the company can invoice in euros and dollars, and a user is browsing in dollars, the system can invoice in the latter currency because it is enabled as an accounting currency. For accounting currencies a priority must be established to decide the order the system will follow to link the currency. If the user is browsing in a currency that is not available at the company as an accounting currency, the system will invoice in the company’s accounting currency having the highest priority.

If the invoicing company has several accounting currencies defined and the user's browsing currency matches one of them, the system will always invoice in the browsing currency, regardless of the priority level assigned to the currencies.

Example: If the company's accounting currencies are euros, dollars and yen in that order, and the user is browsing in yen, the system will invoice in yen even though it is the lowest priority. Prioritization of accounting currencies is only applied when the browsing currency is not defined as an accounting currency.

If the invoice is issued in the accounting currency, the shopping cart will also be calculated in this currency. However, depending on whether the browsing currency is the same as the accounting one, and if the browsing currency has its own price, the prices calculated in the cart may be different.

Example: Imagine that a Commerce has two invoicing companies, with Europe and China as their respective areas of influence. The company in Europe has the euro linked to it as the accounting currency, while that in China is linked to the renminbi. The Commerce 's main market is Europe, so its main currency is the euro. The Commerce needs sales in Europe to be invoiced in euros and sales in China in renminbi. The euro and the renminbi are two of the Commerce 's currencies, but it has another 3 browsing currencies: the dollar, the yen and the pound. The price of products in the Commerce is shown in the main currency (this is mandatory), but also in renminbi and dollars.

The system handles this configuration in the following way:

The system always returns the price in the selected browsing currency:
- If the browsing currency is the main one, it will return prices in euros (the main currency).
- If the browsing currency is renminbi or dollars, the system will return the amount in either of these currencies instead of doing so in the main currency.
- If the browsing currency is yen or pounds, as the prices are not shown in these currencies, the system will take the price in the main currency (euros) and convert it to the navigation currency in question to show the price in the latter currency (the system updates the currency exchange rates every day).
If a shopping process is linked to the European sales channel:
- The European sales channel is linked to the invoicing company for Europe and the currency for invoicing (determined by the company) is the euro.
- While prices are shown in any of the browsing currencies, the shopping process takes the euro (its accounting currency) as its currency for prices and calculating them. The following can happen:
  - If the browsing currency is the euro, no additional calculations are needed, but the value in euros is taken directly. The cart, the order document and the subsequent invoice document will be in euros.
  - If the browsing currency is the dollar, the system takes price values in dollars directly (the prices are also shown in dollars) to show them in the cart. Invoicing must be in euros and the internal calculations in the cart must be carried out in euros. As the prices are shown directly in dollars, the system turns the prices from dollars into euros. This is done like this because it is possible that the prices in dollars, as they are direct, are not an exact conversion from dollars to euros. For example, if the price in euros is €10 and the Commerce manager decides that the price in dollars is $10, if a user buys in dollars, as the invoice has to be in euros, the system cannot take the value in euros (€10) directly and use it because the manager has indicated explicitly that the price of the product in dollars is $10. Therefore, the system has to transform the $10 into euros to perform the internal calculations in the cart. As the calculation will depend on the exchange rate at the time, values in euros can vary. To record the value used at any time, the system saves one version of the cart in the browsing currency, another in the accounting currency and the exchange rate it used.
    The end result is that the user will see the basket and their respective order document in dollars (the browsing currency). When the invoice is generated it will be displayed in euros (the accounting currency) and the user will see that the product costs not €10, but the result of converting $10 to euros.
  - If the browsing currency is renminbi, the same will happen as with dollars because this currency also has the prices set directly. Note that the renminbi is the accounting currency at the China company, but not in the Europe one, so invoicing will be in euros and the renminbi will be converted to euros.
  - If the browsing currency is the pound or the yen, the system will do the same as for the dollar, but as these currencies do not have the prices set directly, it will convert from euros to pounds or yen for the prices in the cart and the order document. The end result will be that the user will see the cart and their respective order document in the browsing currency (pounds or yen) after conversion. The invoice will be generated in euros and the user will see that the product costs €10.
If a shopping process is linked to the Chinese sales channel:
- The Chinese sales channel is linked to the invoicing company for China and the currency for invoicing (determined by the company) is the renminbi.
- While prices are shown in any of the browsing currencies, the shopping process takes the renminbi (its accounting currency) for prices and calculating them. This is what can happen:
  - If the browsing currency is the renminbi, no additional calculations are necessary, but the value in renminbi is taken directly. The cart, the order document and the subsequent invoice document will be in renminbi.
  - If the browsing currency is the dollar, the same happens as in the case of Europe, except the system converts to renminbi instead of euros. The end result is that the user will see the cart and their respective order document in dollars and, when the invoice is generated, the prices will be shown in renminbi.
  - If the browsing currency is the euro, the same will happen as in the previous case because it is a currency with the prices set directly. As in the case of Europe: the euro is the accounting currency at the European company, but not in the Chinese one, so the invoice will be generated in renminbi and the euros will be converted to renminbi. As in the case of dollars, the price of the products in renminbi is not used in the invoice. For example, if the product is worth ¥100, but in euros it is worth €10, the invoice takes not ¥100 but the result of converting €10 into renminbi, which will not be exactly ¥100.
  - If the browsing currency is the pound or the yen, the system will do the same as for the dollar, but as these currencies do not have the prices set directly, it will convert from renminbi to pounds or yen for the prices in the cart and the order document.
    Important note: The conversion is always from the main currency, so even if invoicing is in renminbi and not euros, the starting value for the conversion to renminbi is the euro (main currency).
    
    Example: If the browsing currency is the pound, the price of a product (€10) will be converted into pounds. Imagine that the exchange rate on the day is as follows: £1 = €1.20 and ¥1 = €0.12. The price of the product will be £8.33 (€10) in the cart and the order document, and ¥83.33 (also €10) in the invoice.

Exceptions to Accounting Currencies

As mentioned above, there is a relationship between channel and invoicing company. This link allows for exception set up in accounting currencies (see Multi-Channel System):

In the relationship between a channel and an invoicing company (with linked currencies), exceptions to some of these currencies can be set. This allows you to restrict accounting currencies in the event that a channel and an invoicing company operate together.

Example: You have a channel CH1 which is linked to invoicing company IC1. IC1 invoices in renminbi, Hong Kong dollars and Taiwanese dollars. In the relationship between CH1 and IC1 you define exceptions for the Hong Kong dollar and the Taiwanese dollar. This means that when IC1 works with any other channel, it can invoice in renminbi, Hong Kong dollars and Taiwanese dollars, but when IC1 works with CH1 it can only invoice in renminbi (because Hong Kong dollars and Taiwanese dollars are excluded).
In a zone restriction between a channel and an invoicing company (with linked currencies), exceptions to some of these currencies can be set. This restricts the currencies of invoicing companies by geographical location.

Example: You have a channel CH1 with invoicing companies IC1 and IC2 which operate in China and invoice in renminbi, Hong Kong dollars and Taiwanese dollars. If you restrict the relationship between CH1 and IC1 to the Hong Kong area only, Hong Kong users must be invoiced from IC1; and they can also be invoiced in renminbi, Hong Kong dollars and Taiwanese dollars. If in the restriction between CH1 and IC1 you define currency exceptions for renminbi and Taiwanese dollars, users in Hong Kong must be invoiced from IC1, but only in Hong Kong dollars.

As the relationships with the channel can invalidate accounting currencies, in the event that a company has multiple accounting currencies it is important to define an order of priority so that the system can always find an accounting currency. If there were only one preferential currency as the accounting currency and the channel defined an exception for this currency, the system would not know which currency to use. It is also important to configure exceptions carefully to avoid invoicing in an unexpected currency.