In­teg­ral Vis­ion's Arch

We recently published an alternative to Drupal Commerce, the Drupal Arch Project.

In the past ten years, I have been working on many webshop projects. One of my first Drupal projects was a webstore of a wine seller from Nyíregyháza. Then when I started working on ShopRenter in Debrecen, suddenly I got insights about how a typical Hungarian merchant thinks about e-commerce. Later I had worked on one Magento project before I joined Integral Vision. The first time we talked with PP and Kulcsi I asked them if there was a way not to work on e-commerce for a while.

Back then I had this impression that the rapid changes of the Hungarian law and TAX regulations, combined with marketing strategies and pricing policies we have to face, produce a pile of problems which - for me - is impossible to solve with the available open-source solutions.

I have two examples to illustrate the complexity of these problems.

Price handling: I want to import my products from an Excel sheet, where I will define only the gross purchase price (the one I have actually paid). The system should calculate different net selling prices for my three customer groups. Those groups should see different discount values, too. If the calculated price is not looking good (i.e. 97.56 HUF) I should be able to edit this price via the administrative UI. After a successful checkout the order should appear in my ERP and the accounting system should show the actual listing and selling price and the applied discounts as well. All of the prices should be visible for net and gross calculations. In case TAX regulations change, we should be able to change the tax rate from the UI without editing all of the products. Also I would like to sell goods outside of the EU using the actual Euro or USD rates.

Stock: The company has multiple sites of operation with different storage. I have products which are available in one of them, and products which are available in both. One of my storages accepts orders from private customers, the other accepts from wholesale partners, and there are other storages which accept every order. The customers of the website are not supposed to access the information about the stocks in the different storages, they should only see the sum of stock values available in storages they have access to. It would be great if we were able to define different priorities of storages for different customer groups.

For a while my colleagues shared my concerns about these projects, but after some time we had to admit, I had to admit that as a team we can gain a lot if we cope with a project like this.

Of course our first choice was the Commerce module with its million small connected projects, which is a de-facto tool for e-commerce for the Drupal ecosystem. But most of the projects came to the point of their life cycle where the contributed modules started working in a certain way, and it took us days to investigate the unexpected behaviour reported by the merchant or a customer.

After Drupal 8 arrived we experienced a long period of time when there was no stable release of Commerce. But we signed for two big projects, where the catalogue and the checkout process were very important. So we started to work parallelly, and tried to simplify the whole problem. We defined the products as nodes, the prices and the stock were synchronised from an ERP, we chose a session-based solution for cart handling, and the checkout process was a huge Drupal form which after successful submission wrote the whole order back into the ERP API.

We shipped both projects, they do the job, but we felt that this is not a good solution.

When we got the Stageshop project, I decided to move all the basic features from the previous two projects to a standalone module for internal use.

At the beginning of the development my goal was to make the list of the core features as short as possible, but it should contain a basic solution for every problem we had to face before.

My idea was that we will be able to define multiple prices, multiple stocks, product variations and be able to build a fully customized checkout form. Next I’ll show you how these goals got realised.

One product, multiple prices

To solve the problem of multiple prices, we had to think about how a merchant defines a price. Most of them handle both net and gross prices, they think about currency, and we need to define multiple VAT categories as well. We came to the conclusion that if we want to be able to handle all of these, we have to store each piece of information with price values. Eventually we created the Price type entity which bundles most of these settings. When we combine price types with the Drupal access management system we are suddenly able to manage different prices for different customer groups. We also defined the additional date limitation fields, so that merchants can schedule discounts with seconds granularity. The previously mentioned VAT rate change can be handled by changing the rate at the Price type. After this update the system calculates the net price from the gross with the new VAT rate, and vica versa.

Stocks

The possibility of handling multiple storages could be useful for larger commercial firms. The company that requires this feature usually already uses a kind of ERP system by which they manage and follow the changes of their stocks. Customers’ access to different storages is also resolved with Drupal’s access management.

Product groups, product variations

When we discuss this feature, the most frequently used example is a T-shirt store. A T-shirt has three properties: color of the fabric, size and the design printed on it. We want to list our products grouped by design only, but customers are able to choose between available colors and sizes. We use the Product group phenomenon to solve this. A Product group has a lead or parent product, which is the representative of this group. When a customer is browsing a product page which is part of a group, we display a UI element with which customers are able to navigate between the group elements.

Project-specific checkout

According to our experience with existing e-commerce solutions, this is the part of the projects where it is especially true: the moment we have to deviate from the shipped functionality problems arise. Just as we need some complex calculation of shipping price or we must handle defined connections between shipping address and courier partners of the merchants, the complexity of the development rises dramatically.

From the merchants' point of view, to use different courier companies for different shipping countries is a totally understandable requirement, and the same goes for refusing Cash on Delivery payment methods for a certain group of products, or if the total is above or under a certain price limit.

Considering all this we chose a way of development where we open the opportunities for developers to build a totally customized checkout process which is suitable for their project.

However, although the project contains a basic one-page checkout solution we decided not to solve this problem. Developers can define a custom CheckoutType plugin and a custom CheckoutForm according to project requirements.

But why do you call it Arch?

The name is a pun. When we give a name to a module for internal usage usually we prefix the name with tag IV. When I first wrote down the Hungarian name “IV bolt” (IV store, IV shop) I realized if I change the order of the words and write it together I get the word “boltív” which is “arch” in English.

So, why this long article about this project? After some discussion we decided to share our solutions with the community, which we already provided a lot. To give back at least a part of it. So a few days ago we published the project Arch on Drupal.org. This is also a call for action: If you have any feedback, advice, idea, or miss some features, or would like to write some tests, we welcome any help.