Functional Documentation

General Introduction

Today, companies that sell online generally have needs imposed by the nature of the channel in which they are operating, needs that also involve issues arising from aspects like internationalization, language, business model, including a network of franchises or physical stores, logistics operations, passing on taxes, accounting needs in invoicing, legal matters and so on. Not to mention the operations involved in handling and promoting the products they sell, graphics, content, usability, feedback, and web positioning, means of payment and more.

To meet the needs involved in running an online sales business effectively and efficiently, providing maximum flexibility in all features and dealing with all these issues, a logical structure has been designed, with a number of entities that cover all these requirements.

The principal entity symbolizing the business is the Commerce. A Commerce is related to a series of top-level entities that serve to define and scale the different aspects the Commerce needs to include.

The following diagram shows these top-level entities:

Each of these entities can in turn be related to a second or third-level entity. These relations are also established in the different modules or functions included in the system, for example:

Multi-Channel System


Multi-Invoicing Company and Multi-Currency Accounting


OMS and Multi-Shipment System


Content and Catalog

The Commerce must have at least:

  • One language (if it has more than one, the Commerce is considered multi-lingual)

  • One currency (if it has more than one, it is considered multi-currency)

  • One country in which to sell

  • One domain (if it has more than one, it is considered multi-domain)

  • One channel (if it has more than one, it is considered multi-channel)

  • One invoicing company (if it has more than one, it is considered multi-invoicing) with the corresponding taxes defined

  • One warehouse

  • One logistic center

  • One system of payment

  • One carrier

  • Optionally, it can have a physical location

For a Commerce to be functional, it must also have at least one user (a super-administrator) and at least one product (content) on sale.

Let us look in a little more detail at some of these entities and some mechanisms provided by the system, and how they help to resolve the issues mentioned at the beginning of this document.

Languages

In general, a Commerce can be multi-lingual. This means that the same content can be viewed in different languages (there are different browsing languages). One language from the list must be selected as the default, and this will be the one used by the system to return content if no change of language is specified. The number of languages available will depend on the type of Commerce and how it is configured.

For the Commerce to be effectively multi-lingual, text for the content must be entered in each of the languages linked. Each content element must have a version for each language. The system provides content bulk entry tools to make this simple and convenient. However, the most usual way is to do it from the BackOffice, where each content element has its section, in which all its features can be edited, including those related to the language.

Currencies

In general, a Commerce can be multi-currency. The Commerce has a set of active currencies which are, a priori, the currencies in which prices are displayed (also referred to as "browsing currencies"). One of these currencies must be chosen as the main one. Only prices in the main currency must be entered; for other currencies it is optional.

The possibility exists of specifying the product prices in the Commerce's different browsing currencies (system of pricing by currency). However, if any product is only priced in the main currency and a user is browsing in another currency, the system will make the currency conversion and display the price in the browsing currency. The advantage of specifying prices in other currencies is that a specific price can be set that will not fluctuate according to the exchange rate.

The Commerce can invoice in any of the accounting currencies or, more specifically, in any of the currencies linked to its invoicing companies. As it has browsing currencies and accounting currencies, an order can be placed in one currency and invoiced in a different one. A Commerce can therefore also have multi-currency accounting.

Countries

A Commerce can define a set of countries, i.e. its sales areas, where it can operate. When a business opens its doors to other countries it is possible that, while it can sell its products throughout the world, the invoicing company must always be in its country of origin. The list it establishes will determine which countries it can sell to. If a user is in a country outside the sales areas, the Commerce can set how the system is to respond: by blocking them and telling them they are outside the sales areas or by letting them shop but blocking the shipping country.

The Commerce can also have branches or franchises in these countries, so it may need invoicing companies for each country, with different taxes and legal texts for each country, and possibly to replicate the warehouse and logistics structure for each country. This model of Commerce needs to have a version for each region or country in which it is based. In this case, if a user is in a country outside the sales areas, as well as the behaviors described above, they must be redirected to the version of the Commerce appropriate to their country. For example, if the Commerce has one version for Europe and another for the Americas and an American user enters the European version, the system must redirect them to the American version, and likewise a European user entering the American version must be redirected to the European version.

The user country also serves as input data to apply filters, both for viewing content and for prices. Therefore, a particular country might, through these filters, show more or less content and different product prices. Also, browsing languages can be redefined by country, so that a specific country is used to change the default language and shorten the list of browsing languages. For example, the Commerce might have 5 browsing languages but only need 3 of them for a particular country; also, the default language to be used for this country can be changed.

Country configurations, together with the possibility of linking a domain to a country (as described below) generate different scenarios for organization and sales, so solutions are available for a large number of Commerce models.

Domain

In general, a Commerce can be multi-domain. This means that its website (the collection of content offered by the Commerce) can have different versions, identified by the different domains.

A domain can be linked to a language in both directions, so that either of these two features determines the other: the domain determines a language and vice versa, the language determines a domain. This means that if a language is linked to a domain, browsing in this language will be in this domain, and if this domain is entered into a browser, the Commerce will display the content in the language associated with it. A Commerce can therefore be multi-domain and use this feature to implement strategies to boost its positioning in search engines (SEO strategies).

A domain can be linked to a country. This means that when this domain is used the content filters and features specific to this country like, for example, languages are applied automatically. This allows the scope of the Commerce to be set to a specific geographical area instead of being global. When content and price filters are applied, the country versions of the Commerce can show more or less content and change product prices.

Also, the fact that domains can be linked to countries (one domain per country) makes the Commerce multi-domain. This can serve to implement SEO strategies from a more regional standpoint but also, together with the other features linked to a country, means this domain can be seen as a different version of the Commerce to the global one. This version may need to sell only to a subset of the countries that make up the Commerce's sales areas. Therefore, when configuring a country this list can be redefined to leave only the country or countries where this version of the Commerce can sell.

Channel

A sales channel is what serves to define a line of business, taking "line of business" to mean each of the segments into which turnover is to be separated. The multi-channel system is the mechanism for classifying the shopping processes generated in a Commerce through the different channels it has in place. For the mechanism to be effective, all sales made must be assigned to a channel. Each channel symbolizes a line of business, which will be defined by the configuration of the channel. The channel is not something that can be selected, but one channel or another is activated by the features of the user browsing the store, according to the way each of them is configured.

Channels are assigned automatically according to specific criteria, such as the device type (mobiles, computers, etc.), the domain, the country, or the user group. Different channels can use a single criterion with different values or else use a set of these. The system analyses and assigns the channel with the criteria and values matching those set automatically by the user when they access the Commerce presentation layer.

The Commerce must have at least one active channel defined. Channels are related to the following entities:

  • Warehouses

  • Physical sites

  • Invoicing companies

In the channel an area of influence can be defined, i.e. a set of geographical areas where it works. These entities (warehouses, physical locations and invoicing companies) can also have their own area of influence, so if this area of influence is incompatible with that of the channel, the entity in question will be disqualified from operating in this channel.

Channels must have at least one warehouse associated with them, which means that only the supported warehouses of the channel assigned can supply stock for orders placed through this channel. Channels can also have physical locations, and only those of the channel assigned will be enabled in the shopping process as pick-up and return points or sites that can be found on a map. Channels must have at least one invoicing company, which means only the companies compatible with the channel assigned will be enabled in the shopping process.

Warehouses are grouped in logistic centers and these are what determine where shipments are sent from and therefore shipping costs. This is why the channel is to a great extent what decides the source because it is what determines the warehouse for the logistic center. Likewise, the channel is what determines which company is to invoice the sale. As the invoicing company determines the accounting currency, the channel could be said to decide the accounting currency. The channel is therefore the key to the whole shopping process.

Invoicing Companies

The invoicing company is a physical entity located in a particular place that is able to issue invoices, and 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.

A Commerce must have at least one active invoicing company, which must be associated with at least one active channel; however, it can create as many as necessary, leading to a multi-invoicing company Commerce.

The invoicing company has the tax details that will be linked to the invoice. As 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 segmenting to one or another depending on the channel.

As the invoicing company is the entity that handles taxation, it is where taxes —with their respective tax rates— are incurred and must be applied by the system when a particular invoicing company is assigned to a shopping process. Each company is free to apply taxes at the applicable rates. The rates of each of the taxes then must be linked to the products, so that the system knows which to apply in the shopping process.

The invoicing company must be associated with at least one accounting currency, which is the one it will use to issue invoices, and this may not be the main one. If a company has more than one accounting currency (multi-currency accounting), 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 accounting currency of the company with the highest priority.

Warehouse

A warehouse is an entity that contains a stock of products. This entity can be physical (with an actual address on the map) or virtual. It can contain stock for the whole inventory of products in the Commerce or only some of them. A Commerce can have as many warehouses as it needs, either because it has these actual physical locations from which stock is dispatched and needs to show this in the Commerce or because its logistics require virtual warehouses (even if it does not have them physically).

Warehouses are where goods are received and dispatched, and where inventory management takes place. Where it exists, this management is essential to the smooth functioning of the Commerce because it is what decides whether the goods can be purchased, in what quantities, whether they are in reserve and the possible delivery date.

Logistic Centers

A logistic center is a group of warehouses with a common source or, to put it another way, a group of warehouses which, for logistical reasons, you want located at the same physical address. This address is what determines the source of shipments, i.e. the place where the carrier has to go to collect the goods in the order and deliver them to the buyer.

One of the factors that influences the price of shipment is the distance the carrier has to travel and as the logistic center defines the starting point, to a great extent it is the entity that will determine the price.

An area of influence is defined for logistic centers. This is the set of geographical areas to which the logistic center can deliver shipments. This area of influence is important because it determines which places (user addresses) goods can be delivered to. If an order has a delivery address outside the area defined for the logistic center, it cannot be sent because the destination is incompatible with the area the logistic center can serve.

Payment System

Payment systems are the set of means by which payment can be made for an order. There are two types: online payment gateways (with a connection) and offline payments (no connection).

The online payment gateway is a service provided by some banks and companies to handle the sending and receipt of payments via Internet. The advantage of these methods is that the Commerce gets an almost immediate response from the gateway informing it whether the transaction has been accepted or refused. If it is accepted, this tells the Commerce the order has been paid for; if it is refused, this means the gateway supplier has found a problem that stops it from approving the transaction and it is rejected.

These online payment gateways are implemented by means of a plugin to allow communication between the payment management service and the system. This way, the customer can use the most popular services to effect payment, including an online POS terminal, PayPal, Adyen, Alipay or SeQura.

Orders with offline payment methods are those where payment need not be handled by Internet and where payment is made afterwards, for example by cash on delivery or by bank transfer. These systems need to be managed by the administrator to know whether the order has been paid for or not and therefore do not require any plugin.

Physical Locations

It is very normal for the businesses behind Commerces to also have a network of physical stores, franchises, branches, or authorized points of sale. These sites often play an important part in the online channel, primarily as points for picking up and returning products bought in the Commerce. In some cases, the Commerce merely wishes to show that it also has a physical presence.

A physical location is an entity that represents an actual place. It can also be a point that can be found on the map, for which the relevant coordinates are required. The map can show the network of physical stores, pick-up or return points, or be used for any other purpose required by the Commerce.

The physical locations configured as pick-up points allow deliveries at pick-up points to be generated; these are deliveries where the order is not shipped to the user's home, but they have to go to the pick-up point to collect it. The system can automatically calculate pick-up points within a radius of distance configured for each pick-up point, and show the closest ones to the user's address. Likewise, the physical locations configured as return points allow the user to return their purchases (or part of them) simply by going to the closest location to their address (which may be the place where they picked up the purchase, if the location serves as a pick-up point and a return point at the same time).

Carriers and Shipping Management

Carriers are the entities in the Commerce that represent those in charge of delivering shipments, i.e. those who take orders to user's homes. Shipping management is essential in any Commerce, but it is generally out of its hands, delegated to dedicated companies. It is therefore important to clearly define the interaction with the carrier and keep close control over this area of the Commerce. The shipping management system takes care of all this.

Good control calls for maximum flexibility. This means a Commerce can have as many carriers as it needs. Each carrier must have its associated shipping types defined, and for each shipping type there must be a specified delivery area or areas. Finally, ranges must be established by order weight or value to determine the price to be charged for shipping each order. All this assures a good delivery service with maximum control over costs and shipping or delivery areas.

Moreover, interaction with the carrier can be automated using carrier integration plugins. With these plugins, requests for pick-up of packages can be made entirely automatically and shipment status tracked. These carrier shipment statuses pass to the system's own statuses, so that when a carrier reports that the shipment is, "in transit", for example, the system changes it to the complementary status configured in the Commerce, e.g. "sent". Carrier integration relieves the Commerce manager of the task of moving shipments and orders through the planned logistics cycle, as this is all left in the carrier's hands.

Multi-Shipment System

While shipments are not part of the core definition of the Commerce, they play an important role because they add flexibility to the order delivery process, a process that is often highly critical because it is where the most interactions are generated between users and the Commerce, and where the latter can make or break its reputation.

"Delivery" is taken to mean the way an order reaches a user who has bought something. There can be home deliveries or deliveries to a pick-up point. Home deliveries involve sending the order to the delivery address the user used when placing the order. The order can be sent in a single shipment or several may be necessary.

The shipment is the entity that represents the transport or movement of the merchandise making up all or part of an order from a point of origin to a destination. The point of origin is the logistic center and the destination is the shipping address specified by the user when they placed their order.

As mentioned above, deliveries can be sent in a single shipment or split into several (multi-shipment). For the system to create multiple shipments, the necessary conditions must exist; the main one of these is that the Commerce has set up the multi-shipment feature. If it is not set up, even if the other conditions are met, the system will not split up the delivery and there will always be a single shipment.

If the Commerce has enabled multi-shipment, delivery can be split according to the following criteria:

  • Delivery date

  • Shipping calculation type

  • Source of the shipment

  • Shipping type

The more criteria apply, the more divisions can happen. However, as the system tries to minimize the number of shipments, at the end of the calculation process it will try to group shipments with the same source and shipping type together wherever possible.

Multi-shipment allows the Commerce to design flexible, robust logistics. If it is combined with carrier integration, management of home deliveries is greatly simplified and involves practically no supervision by the Commerce manager.

IMS

The inventory management system or IMS controls the stock of the products sold by the Commerce. It provides the Commerce manager with mechanisms to report on the quantity of units coming in of each of the products and handle removing them when they are sold, as well as offering different forms of stock control to manage replenishing or reserving stock.

These mechanisms allow different ways of working with orders where, for example, products are temporarily out of stock or waiting to be replenished. With these the Commerce can, in practice, handle orders as pending (backorder) or as advanced sales (preorder). They can also implement a backordering strategy (a way of selling inventory not available to the Commerce) where an out-of-stock product will be available soon, whereby users are encouraged to buy by informing them of this date, or where a product has to be ordered from the supplier or made to order, whereby users are encouraged to buy by stating the waiting time involved.

This system is especially relevant in B2B contexts, where the quantities purchased may be large and the availability of units need to be reported in comprehensive detail; where items are out of stock, the quantities and delivery dates of future incoming stock need to be reported and monitored to avoid selling more units than expected, i.e. to avoid overbooking.

The system also provides the tools to manage reserves automatically. This way, incoming stock for these reserves is allocated automatically and orders can be fulfilled without the action of the Commerce manager.

OMS and Pricing System

The order management system or OMS deals with monitoring and managing the whole purchase process. This process begins in the shopping cart, which is the entity symbolizing an order in progress. The pricing system works together with the OMS to obtain the right prices for the features of the cart. This system provides different ways to report product prices: from a simple manual price to one based on a percentage using a pricing policy, including pricing by quantity or pricing by product family. Moreover, prices can be filtered by user, user group, country, or country area. All this makes the pricing system flexible so that it can adapt to most of the pricing systems used by the main ERPs and most types and contexts of Commerce, such as B2B.

When a product is added to the shopping cart, the OMS checks whether a discount is to be applied, whether the quantity added is correct (control of multiples), whether there is an alert of some kind, e.g. whether there are products in reserve or there is a delay in the delivery date, whether recommended products need displaying in relation to the contents of the cart, etc. It also makes the cart calculations, including the application of discounts and breakdowns of taxes.

The OMS also deals with returning the different means of delivering the order (home delivery or to a pick-up point) and, if home delivery is chosen, asks the multi-shipment system to create the different shipments into which the order is to be split (in the case of multi-shipment). Of course, it also deals with returning payment systems and, once the user has chosen the payment system they want to use, implementing the payment gateway through the service in question.

Once the order has been placed and payment confirmed, the OMS issues the relevant order document and executes the actions configured for it. The OMS also deals with creating the other documents used by the Commerce, such as the delivery notes (for the carrier) or the invoice document. The latter gets the invoice numbering and tax details from the invoicing company to which the order is linked. Furthermore, the invoice will always be issued in one of the currencies authorized by this invoicing company.

Finally, the OMS also deals with return requests and accepting or rejecting these. Return requests are always based on an order, so the system allows it to be returned wholly or in part. Once the return request has been accepted, the OMS creates the return documents, i.e. the return order for merchandise to be returned to the Commerce and the pertinent corrective invoice.