For the workshops of an art academy, aromicon was commissioned to make a customized digitization solution, i.e. an online material library with an ordering function. The use of an open source shop system offered itself as a basis. Numerous adaptations such as a central university login, order releases via local terminals, order quantities, price and inventory management, storage for yard goods, areas, and volumes as well as the consideration of internal payments via budgets had to be considered. Here we show how the implementation was realized with Shopware 6.
Our task
The task was to make the large range of materials and semi-finished products for each workshop, be it the metal workshop, the wood workshop, the digital workshop or others, searchable for the students. The students should thus be able to get an overview of the available materials, their properties and dimensions, safe handling, and the extensive machinery, such as various 3D printers, CNC machines or the laser cutting machine, before visiting the respective workshop.
The university's goal was primarily to improve teaching. A material library should make it easier for students to plan their projects in advance. The workshop staff should be relieved of routine tasks and thus have more time for advising the students.
At the same time, there should be an order and online payment function, thus reducing the administrative effort behind it to a minimum and replacing cash payments.
Concept for an online shop with tailoring for multiple dimensions
It quickly became clear that a customized online shop would be the best basis for solving this requirement. Shopware 6, an open source ecommerce system with extensive functions and a high degree of flexibility, was the obvious choice for the complex requirements of the art academy.
But as we all know, the devil is in the details.
For example, we were not aware that Shopware 6 did not support material orders smaller than "1" by default.
This meant that, for example, a threaded rod could be ordered with a length of 2 meters, but not with a length of 0.5 meters.
Another aspect that had to be taken into account was the possibility to map prices, stock, and quantities for two dimensions, i.e. areas. This is the case, for example, with materials such as MDF boards or Plexiglas. For blocks, such as model building foam, the third dimension, i.e. volumes, then came into play.
Another concern was to use the students' central login data for the computer pools on campus for the workshop shop as well. The focus was on user-friendliness, i.e. students should be able to process their workshop orders seamlessly and conveniently using their existing access data. At the same time, simple authentication had to be guaranteed.
Is there a solution or have the limits of Shopware 6 been reached?
How can we now solve the problem of order quantities smaller than "1" and the warehousing and price calculation for areas and volumes, or have the limits of Shopware already been reached here?
This is how we proceeded:
-
The quick way: Is there already a Shopware plugin?
First, of course, we looked for suitable Shopware 6 Plugins. But at this point without any success. There wasn't even a plugin that could roughly fit and could have been extended. -
Programmer's approach: Change data type in MySQL
The second attempt was the classic approach of a computer scientist, if the variable does not do what it should, its data type is simply adjusted.
Unfortunately, this is not possible due to the type castings and definition to integer. -
With brains: Simply convert the ISO unit of measurement.
We still know how to convert units of measurement from physics lessons. For example, 0.5 meters is also 500 millimeters. And you have an elegant solution. You simply convert everything to the basic units, millimeters, square millimeters, and cubic millimeters as well as seconds. For each product, you can define which sales unit should apply and which is the "base" unit. Thus 0.5 m2 becomes either 5000 cm2 or 500,000 mm2.
Price calculation settings: sales units, units of measure, minimum and maximum panel cut, step size of cut.
The devil in the details – changes to price calculation...
This meant that a valid solution had been found, but at the same time it opened up a need for further customization:
Next, the price calculation and inventory management had to be adapted. If the system is converted to small basic units such as millimeters, price, and stock management in the administration area can easily become a complex calculation task.
For example, MDF boards are delivered with standard dimensions of 125 cm x 83 cm, and the price is given by the supplier in euros/sqm. How much does a board cost or just X x Y millimeters?
When calculating the price, it was also necessary to take into account a variable waste factor, as this can have a considerable influence on the sales price.
Another problem arose. If you no longer put 1 cubic meter in the shopping basket, but now the value of 1,000,000,000 converted into cubic millimeters, you reach the limit of MySQL's INT data type. In this case, the data type of the fields "stock" and "available_stock" could be changed to BIG INT, which was easily done with a migration script. This way the type casts and type declarations were not violated.
Afterwards, only all the places where the stock is displayed and this is converted into the sales unit accordingly had to be adapted and extended by the sales unit. Due to the good extensibility of Shopware 6, this was easy to implement. In the frontend, the display in the category, the product detail page, shopping cart, checkout and display in the order were adapted. The administration area was extended in the product overview, product details, variants and order data.
Product detail page with variants (different panel sizes and thicknesses).
Result: Administration input stock in square meters and frontend order square millimeters
Modified inventory management in the Shopware 6 administration area.
Shopping cart with cutting, project details, and locked checkout (orders can only be placed via terminal PCs), checkout only possible via local terminal PC with student account.
Price maintenance incl. surcharge for off-cutting
And other things: Solve central login, adjust payment method and checkout*
For student login, the Radius server of the university is requested and the accounts are verified. In addition, the workshop team can create guest users in the administration area. Checkout is only possible from certain terminal computers in the workshop and project details must be provided for each order.
If advice is required for certain materials or machines, shopping baskets must be approved by a member of staff before checkout. This is also done via the authentication of the Radius server.
PayPal was used as the payment method and the system was expanded to include another payment method for internal budgets. This method must also be manually released by a staff member in the checkout.
Authentication via the Radius server
A separate plugin was developed for using the university's internal Radius server for logging into the workshop shop. The library by Drew Phillips (https://github.com/dapphp/radius) was used as the Radius client. The server connection could be fully customized via the plugin configuration in the administration area. To avoid a separate login, the default login in the frontend was adapted to also allow usernames instead of emails. All links for registration were removed, as registration via the storefront should not be possible. The class "Shopware\Core\Checkout\Customer\SalesChannel\LoginRoute" was used to adapt the login process, as no suitable events were available.
In the "login" function, it was checked if there was no email in the email field. In this case, the data was checked on the Radius server. If the user was successfully authenticated by the Radius server, the customer was loaded from the shop database based on the user name stored in the customer's CustomFields. If the customer did not already exist in the database, an error was returned that led to a modified registration page in the storefront. For this, the controllers "\Shopware\Storefront\Controller\RegisterController" and "\Shopware\Storefront\Controller\AuthController" were overwritten.
On the registration page, the student only had to complete their name and adjust the email address (by default, the student email address was used). The automatic registration then took place. Once completed, the student could log in either with their student account or normally with their email address.
Current challenges in operation
The shop was very popular from the beginning. Its use helped to minimize the time spent in the workshops during the Corona restrictions and to comply with the rules in place regarding the maximum number of simultaneous users.
It was clear that the shop was a non-profit project. However, PayPal fees present a challenge. In some cases, the fees exceed the value of the order, for example when ordering only two screws. To keep the hurdle for using the shop low, a minimum order value was deliberately waived.
The problem of micropayments arises here as so often, especially since a university is limited in its choice of payment service provider. A solution has yet to be found here for the future.
The project has not only mastered the challenges of the Corona period, but has also digitized the practical knowledge transfer in the workshops. Therefore, the offer will be further expanded and more workshops of the university will be integrated into the shop and equipped with terminal PCs.
Do you want to talk to other Shopware developers?
Join our amazing open source community with over 7,000 developers on Slack!
About the authors:
Alf Jahn is managing director of the digital agency aromicon based in Halle (Saale). Since 2008, aromicon has been developing e-commerce solutions, apps, and AI applications for its customers in the DACH region as a digitalization partner. In addition to the management, Alf is responsible for sales as well as strategic and conceptual consulting for customers.
Stefan Richter is responsible for the conceptual and technical implementation of projects as well as the area of in-house development of future digital products at aromicon.
