ERP-Integrated Distribution Management System for ADF Foods
Distributors ordered by phone. Sales teams tracked revenue in spreadsheets. We built a role-based DMS on top of ADF Foods' ERP, without replacing the system underneath.
ADF Foods
4
3
~10 weeks
ADF Foods had a working ERP, but it was built for internal operations, not distributor self-service or management visibility. Orders still came through calls and emails, while sales teams relied on spreadsheets for revenue, order history, and distributor performance.
SoluteLabs built a distribution management system on top of the existing ERP, giving distributors a self-service ordering portal and managers live, role-scoped dashboards without replacing the ERP underneath.
The data already existed within the ERP. The challenge was providing the right users with timely access to act on it.
Area
Before
After
Order placement
Phone calls and emails to a sales rep, manual ERP entry, no distributor-side record
Self-service portal: browse, select, submit. Every order is timestamped and auditable.
Fulfilment visibility
No status tracking for distributors after placing an order
Real-time status: submitted, confirmed, in-transit, delivered — visible in the portal.
Revenue reporting
Manual spreadsheets, assembled infrequently, prone to version drift
Live dashboards scoped by role — sales heads, country managers, and admins each see their view.
Performance tracking
Country managers waited for weekly reports to spot underperforming distributors
Live drill-downs — underperforming distributors surfaced without waiting for a report cycle.
Distributor onboarding
Manual coordination, no structured access provisioning
Structured admin flow: details, region mapping, account activation, Kinde Auth provisioning.
ERP integration
Orders entered manually by sales reps after receiving calls or emails
Orders pushed directly from the DMS into the ERP on submission, status pulled back automatically.
Services Delivered
Across this project, we delivered:
Discovery:
Understanding the Distribution Workflow Before Designing the DMS
Before writing a line of code, we mapped how orders moved across distributors, sales teams, country managers, admins, and the existing ERP.
The ERP was the source of truth, so the new system had to sit on top of it, not replace it.
What we learned:
Distributors needed a self-service ordering layer. They had no portal to browse products, place orders, or track fulfillment. Every order still depended on phone calls or emails.
Sales heads needed live regional visibility. They needed to track orders, revenue, distributor performance, and product demand without waiting for manually prepared reports.
Country managers needed a wider performance view. They needed one dashboard to compare distributors, monitor targets, and spot underperforming regions.
Admins needed operational control. They needed to manage distributor onboarding, user accounts, region mapping, and permissions without engineering support.
The ERP had to remain the system of record. Orders needed to flow into the ERP, while fulfillment status and reporting data came back into the DMS for users to act on.
Two decisions shaped the entire architecture.
Role-based access from day one
The same platform had to serve four fundamentally different user types. A distributor sees only their own orders. A country manager sees the full network under their geography. Building this cleanly upfront meant that changes to role permissions were considered configuration changes rather than architectural changes.
Integrate with the ERP, not replace it
The ERP already owned order processing. The DMS would own the user experience and the analytics layer on top. Keeping the integration surface narrow — push orders in, pull status updates out — reduced risk and made the system easier to maintain.
Three modules. One platform. Every stakeholder served.
The DMS was structured around three core modules, each addressing a distinct gap in the existing workflow.
Distributor Onboarding & User Management
Admin panel for onboarding distributors and creating sales head and country manager accounts
Role-scoped permissions — distributor sees only their own orders; country manager sees their full geography
Structured onboarding: distributor details, region and category mapping, account activation
Credential provisioning via Kinde Auth — distributors receive access without manual handoff
Every stakeholder type was served from one platform without any user seeing data outside their scope.
Order Placement & Tracking
Distributor portal: browse product catalogue, select quantities, submit orders
Orders flow directly into the ERP for processing on submission
Real-time fulfilment status surfaced back to the distributor: submitted, confirmed, in-transit, delivered
Timestamped, auditable order history for every distributor — for the first time
Admin and sales head dashboards with filters by distributor, date range, product category, and status
A workflow that previously required a phone call or email became fully self-service. Every order now has a verifiable paper trail.
Sales Analytics Dashboard
Role-scoped dashboards for sales heads, country managers, and admins
Revenue by distributor, order volume over time, performance against targets
Live data — dashboards update as orders flow through the system
Country manager analyzes data to spot underperforming distributors without waiting for a weekly report
Full-network view for admins
The manual spreadsheet process was replaced entirely. Country managers now see underperforming distributors in real time instead of waiting for a weekly report.
What Changed Along the Way
Analytics grew beyond the admin view
Initial scope covered a basic revenue view for admins. Early demos surfaced deeper needs from sales heads and country managers: target-vs-actual tracking, distributor drill-downs, and time-series trends. The analytics layer expanded without changing the core platform architecture.
Role scoping became more granular
The first design assumed fewer permission models. Client feedback showed that sales heads and country managers needed distinct dashboard views and access rules. Because role-based access was built early, the change stayed configurable instead of becoming a rewrite.
ERP integration stayed intentionally narrow
We scoped for deeper bidirectional sync, but the final path was simpler: push orders into the ERP and pull fulfilment status back. Keeping the integration surface small reduced risk and made the system easier to maintain.
How the platform was built to run reliably.
Concern
How it's handled
Authentication
Kinde — OAuth 2.0, role claims map directly to DMS permission model. No passwords stored in the application layer.
File Storage
Google Cloud Storage with signed URLs for time-limited access to distributor-uploaded files
Infrastructure
Google Kubernetes Engine — horizontal scaling, rolling deployments, staging/production environment isolation.
Observability
Cloud Monitoring and Cloud Logging for full visibility. All API errors logged centrally with request context.
Secrets
Secret Manager for all credentials and environment configuration. No secrets in source code or environment files.
Container images
Artifact Registry across environments.
Failure handling
Invalid role access returns 403 with no information leakage. ERP integration failures surface as order submission errors with retry guidance.
What the platform changed in practice.
Distributors are onboarding now, with early feedback already pointing to self-service order placement as a major improvement over the previous phone-and-email workflow. The platform is live in production and operational.
Sales heads and country managers now have a single, role-scoped view of network performance, replacing the manual spreadsheet process entirely. Admins have end-to-end control over the platform without requiring engineering involvement for routine operations.
The ERP remains the system of record. The DMS is the interface layer that makes it accessible to the people who depend on it.
Tech Stack
Team & Timeline
2 Developers
1 QA Engineer
1 Product Manager
~10 Weeks
A lean four-person team with a clear scope.
The PM owned stakeholder alignment and requirement clarification.
Developers owned architecture, backend, and frontend.
QA owned test coverage and regression cycles.
Ten weeks from kickoff to a production-ready platform covering onboarding, order management, ERP integration, analytics, and role-based access across four user types.
