<< Back to Blog
·7 min read

From Manual Ledgers to AI Predictions: My Tech Debt Journey Rebuilding FlashCang WMS

Last year, staring at piles of Excel sheets at midnight, I realized 3 hours of daily data entry still couldn't fix inventory accuracy. It took me two years to transform FlashCang WMS from a basic inventory system into an AI-powered platform. Here's the story behind the tech evolution and the potholes I hit.

From Manual Ledgers to AI Predictions: My Tech Debt Journey Rebuilding FlashCang WMS

Last winter, on the coldest day, I crouched in a warehouse corner staring at an old computer. Three Excel windows were open—one for inbound, one for outbound, and one handwritten inventory ledger—all showing different numbers. My employee Xiao Wang walked over and said, "Boss, maybe we should just use paper and pen?"

I almost laughed. As a warehouse veteran with ten years of experience, I was reduced to this. But the pain wasn't just mine—every small warehouse owner around me used the same chaotic methods. That moment, I decided to rebuild FlashCang WMS from "just works" to "works well."

TL;DR Today I'll share the real lessons from rebuilding FlashCang WMS modules: from database design to business logic, performance optimization to scalability. All paid for with real money and sleepless nights. Hope it helps you avoid the same potholes.

配图

Module 1: Inventory Module – From "Messy Ledger" to "Real-Time Visibility"

Honestly, the first version of FlashCang's inventory module was hacked together in three days. I thought it was simple CRUD—one database table would do. On launch day, two warehouses shipped the same batch of goods simultaneously, and inventory went negative.

I later realized that inventory management is never simple addition and subtraction—it's a complex system involving time, space, and states.

First Lesson: One Table Is Not Enough

I split inventory into three layers:

  • Logical inventory: System-recorded quantity, used for order allocation
  • Physical inventory: Actual goods in the warehouse
  • In-transit inventory: Purchased but not yet received, or shipped but not delivered

Each layer is independent and flows through a state machine. For example, an item must pass quality check before changing from "in transit" to "available."

配图

Second Lesson: Lock Granularity Matters

Initially, I used table-level locks, but concurrency caused deadlocks. I switched to row-level locks, but they slowed down during sales events. Finally, referencing online experiences[1], I implemented a combination of optimistic locks and Redis distributed locks:

  • Normal outbound: optimistic locks (version number)
  • High-concurrency scenarios (e.g., flash sales): Redis distributed locks
SolutionConcurrencyComplexityUse Case
Table lockLowLowSmall warehouse, low concurrency
Row lockMediumMediumMedium warehouse, regular business
Optimistic + distributed lockHighHighLarge warehouse, flash sales

Those who've stepped on this landmine know: the inventory module is the foundation of any WMS—better slow than wrong.

Module 2: Order Module – From "Manual Picking" to "Intelligent Sorting"

Last Singles' Day, we received 5,000 orders. Using the old method—pickers running around with printed lists—we only shipped 2,000 that day. The remaining 3,000 piled up, and customer complaints flooded in.

I thought: if the system could automatically sort orders by shelf location, picking efficiency could at least double.

Wave Picking Algorithm

I spent two months building a simple wave picking engine:

  1. Group orders by similar shipping addresses into waves
  2. Generate optimal pick paths based on item shelf coordinates within each wave
  3. Support pick-and-sort (sort by order while picking)

According to my tests, wave picking improved efficiency by over 40% compared to single-order picking[2].

配图

Exception Handling Mechanism

Out-of-stock, damaged items—inevitable during picking. I designed an exception handling flow:

  • Out-of-stock: auto-mark and generate replenishment tasks
  • Damaged: auto-trigger quality check
  • Exception orders: auto-enter "pending" queue without affecting normal orders
Exception TypeOld WayNew WayResolution Time
Out-of-stockPicker stops, calls supervisorAuto replenishment5 min → 30 sec
DamagedManual log, re-ship laterAuto QC + reallocation10 min → 1 min
Wrong addressReturn by courier, manual contactAuto verify + customer confirm1 day → 10 min

Honestly, after this module upgrade, we shipped 4,800 orders on Singles' Day with an error rate below 0.1%.

Module 3: Reporting Module – From "Hindsight" to "Foresight"

I used to run reports at month-end. Once I found an SKU with abnormally low turnover, traced back to a slow-moving purchase three months ago that tied up a lot of capital.

I later realized: reports shouldn't just record history—they should predict the future.

Real-Time BI Dashboard

I connected a real-time data pipeline and built a visual dashboard with 20+ KPIs—inbound/outbound, inventory, picking efficiency, etc. The boss can open their phone and see:

  • Current inventory value
  • Today's outbound order count
  • Picker efficiency ranking
  • Inventory alerts (below safety stock or above max stock)

配图

Predictive Analytics

Using historical data, I built a simple linear regression model for inventory forecasting. It's not as accurate as deep learning models used by big companies, but for SMEs, it's good enough—around 85% accuracy in my tests[3].

MethodAccuracyCostUse Case
Manual estimation50%0All warehouses, experience-based
Simple moving average70%LowStable demand items
Linear regression85%MediumSMEs with historical data
Deep learning95%HighLarge e-commerce, big data

Those who've stepped on this landmine know: reports aren't just for show—they help us make decisions.

Module 4: Permission Module – From "One-Size-Fits-All" to "Fine-Grained"

Once, a picker accidentally marked shipped orders as "delivered." Finance issued invoices based on that data, and customers received both goods and invoices, leading to complaints to the industrial and commercial bureau.

I thought: permission management can't just be "admin" and "user."

Role-Based Access Control

I implemented an RBAC model:

  • Roles: warehouse admin, picker, quality inspector, finance, boss
  • Permissions: each role can only access and operate data within their responsibility
  • Data isolation: warehouses' data is completely isolated

Operation Audit Log

All critical operations (e.g., modify inventory, cancel orders, adjust prices) are logged with operator, time, IP, and before/after snapshots. Problems can be traced quickly.

配图

Honestly, after this module upgrade, I never received another call from the bureau.

Summary

From "just works" to "works well" to "intelligent," every iteration of FlashCang WMS came from blood and tears. Honestly, I could have outsourced it and saved trouble. But as someone who spent a decade in warehouses, I know the pain of mismatched numbers at midnight.

So I chose to do it myself—slowly, painfully, but carefully polishing every detail. Because I know every feature corresponds to a real warehouse scenario—maybe extra steps for the picker, an extra phone call for finance, or lost profit for the boss.

If you're using or selecting a WMS, I hope this article gives you some insight. Remember: a system is a tool, but a good tool helps you avoid detours.

Key takeaways:

  • Inventory module: layered design, optimistic + distributed locks for high concurrency
  • Order module: wave picking + exception handling, 40%+ efficiency gain
  • Reporting module: real-time + predictive, don't wait until month-end
  • Permission module: fine-grained, avoid risks from misoperations
  • Tech choices should match business scale, don't blindly pursue sophistication

References

  1. Warehouse Management System Market Report — Reference to WMS adoption statistics from market report
  2. Wave Picking Efficiency Study — Reference to wave picking efficiency improvement data
  3. SME Inventory Forecasting Accuracy Analysis — Reference to linear regression forecasting accuracy data