Nico Pujia

Overview¶

Siderplast S.A. is a relatively small local company from Buenos Aires that sells sanitary equipment. They had a legacy internal system made with FoxPro 2 around the year 2000, some monday.com tables, and an online shop disconnected from that.

A close friend of mine, whose father is the owner of this company, told me about the situation, and that is how I got my first deal, where I rebuilt the company's software from scratch using Django.

Screenshots¶

Online shop

Payments via bank transfer, Mercado Pago, or cash

Admin panel

Apps¶

In Django, your site is made up of applications, which are independent sets of features. For Siderplast, there are three apps:

Store¶

This is the main app, which contains the business logic for most operations. Given its broad responsibilites, it is further divided into different modules:

Inventory¶

The inventory module contains the Product and related models needed to work. Some features it had:

• Bulk price adjustments to perform discounts or recharges.
• Up-to-date US dollar-ARS convertion.
• Dynamic discount labels in the shop pages based on applied discounts.
• Automated stock tracking based on orders.

Sales¶

The sales module features order tracking, user messages, shop banners, client budgeting functionalities, and invoice generation. Here's a sample invoice:

People¶

The people module groups all the models related to clients and suppliers, which are shown along Django's User and Group default models. For example, it handles exclusive discounts for certain clients, which are then rendered in the shop only for the specific client.

Shared logic¶

It wouldn't be a single app if these modules didn't share logic. The shared logic includes, and I'll get more technical now, custom ModelAdmin mixins, abstract models, and other kinds of utilities, specially useful for customizing the Django admin site without repeating myself.

For example, instead of writing a display method for every relation field (e.g. ForeignKeyField) to convert them into a link to the related object, I created a mixin that, once applied to the ModelAdmin, it detects all those types of fields and displays them as links. And because there were other types of fields that I wanted to render in a common way (like ImageFields as img tags, TextFields shortened to a maximum of words, etc.), I abstracted away the shared logic of all these mixins into a base mixin, resulting in my ModelAdmins and mixins written in much cleaner way.

Like that, I have more examples of refactors that I had to do in order to maintain the codebase in a state where I can keep adding features, something increasingly important as the project grew in scope.

Wave¶

In the wave app, employees can dynamically create tables with custom columns, replacing their usage of monday.com and therefore eliminating its monthly spend.

Wave, where data flows

Custom column creation

System¶

This one is a secondary app for backups, logs, configuration, and system information.