Chapter 1. Turning Scattered Sales into Structured Records
Brill received orders through Shopee, Tokopedia, and direct purchases, but the operational record was still maintained manually outside the main database. The process depended on free-form input, making customer, vehicle, product, and purchase information vulnerable to typing differences and inconsistent formats. It also meant that a completed sale could not reliably become structured input for inventory control or later customer follow-up.
I developed Stock Management as a centralized internal workflow for recording those sales in one consistent structure. The module does not claim to import marketplace orders automatically; administrators still record the sale, while the application validates and connects the information to the correct product, vehicle, and stock data.
Chapter 2. Researching the Operational Data
The work began in May 2026 with research into the existing spreadsheet and database records, followed by preparation of the master data needed by the new workflow. Vehicle brands, models, production years, filter types, product variants, and existing pricing relationships had to be reviewed before sales records could reference them consistently.
This phase also exposed an important modeling requirement: a vehicle is not the stock item itself. Each supported vehicle and filter type must resolve to one active product variant and SKU. Separating vehicle compatibility from product inventory created a clearer foundation for both stock calculation and future modules.
Chapter 3. Standardizing Multi-Channel Sales Entry
The recording flow standardizes the information needed from every sales channel: customer details, phone number, vehicle, filter or headrest variant, quantity, purchase date, payment status, payment method, and additional operational notes. Shopee, Tokopedia, transfer, free-sample, and manual transactions can therefore enter the same internal record structure without pretending that the marketplaces are directly integrated.
Separate Filter AC and Headrest views keep product-specific inputs understandable. Search, purchase-month filtering, editable records, and consistent form controls give the owner one place to review what was sold and the operational context attached to each sale.
Chapter 4. Reshaping the Product and Vehicle Model
The database was reorganized around products, product variants, per-SKU stock, vehicle-to-filter mappings, product records, and stock transaction logs. Existing vehicle and filter-detail data was migrated into this structure, duplicate and legacy relationships were reviewed, and the older detail model was retired after the replacement mappings were prepared.
For Filter AC records, the selected vehicle and filter type must resolve to exactly one active SKU. Missing mappings are rejected, while ambiguous mappings are surfaced for review instead of silently selecting a product. Headrest records use their own active color variants. These boundaries reduce guesswork at the point where a sale becomes an inventory transaction.
Chapter 5. Keeping Stock Changes Transactional and Auditable
Creating a product record and reducing its SKU stock happen inside one database transaction. The current stock row is locked before calculation, insufficient stock prevents the operation, and a successful sale stores both the quantity before and after the change. Each movement is written to a stock transaction log with its reference, channel context, customer and vehicle context, timestamp, and responsible user.
Editing an existing sale also reconciles inventory. Quantity changes adjust the difference, while changing the selected SKU returns stock to the previous variant before reducing the replacement variant. Changes that affect stock require an adjustment reason. A separate per-SKU view supports controlled manual correction while preserving the before-and-after audit trail.
Chapter 6. Preparing Each Sale for Follow-Up
A Filter AC sale with a usable phone number does more than reduce inventory. The same transaction creates a linked refill reminder using the customer, vehicle, filter type, quantity, purchase date, source channel, and a default nine-month replacement interval. The reminder keeps a reference to the originating product record so the handoff remains traceable.
This connection was deliberately kept at the boundary of Stock Management. The stock module is responsible for producing reliable purchase data and a reminder candidate; scheduling, WhatsApp delivery, acknowledgment, retry, and manual recovery belong to the separate Brill Auto Reminder workflow.
Chapter 7. Application Flow and Operational Result
The completed flow starts when an administrator records a sale from Shopee, Tokopedia, or a direct channel. The application validates the required fields, resolves the vehicle and product selection to an active SKU, locks and updates stock, writes the product and stock audit records, and creates a linked refill reminder when the sale is eligible.
The result is a standardized source of operational data in place of disconnected manual notes. Stock quantities, sales context, and subsequent corrections can be reviewed from the same system, while downstream automation receives structured records instead of having to reinterpret spreadsheets or free-form entries.
