Retail & Modern Trade Distributor Management System for Malaysian Business

Each retail chain has its own EDI message format or B2B portal export. The integration layer takes in chain POs, normalises them to the platform's order schema, and pushes them into the order queue. Line-level fields, chain SKU codes, and pack sizes get mapped against the active listing. New chains and format changes are configured in the admin portal without code deployment.

Every chain has its active SKU list with PO codes, chain barcodes, listing start and end dates, and pack-size mapping. KAMs manage listing additions and delistings from the admin portal. Orders validate against the live listing at the line level. Out-of-listing items trigger a hold so they never ship by accident. Range compliance reports show which listed SKUs are still active on shelf versus on the listing master.

Trade discount trees are configurable per chain and format: off-invoice for upfront discount, on-invoice for value or volume slabs, and post-invoice claim for accrual that gets reconciled at JBP. Multiple discount layers can stack with the rule order set per chain. The system shows landed net price at the order line so KAMs and finance both see what the chain actually pays.

Trade investment expenses including listing fees, slotting fees, and category support contributions are logged against the chain ledger with the underlying agreement. Each entry carries the scheme reference, the validity period, and the chain SKUs in scope. Finance sees the running trade investment by chain. KAMs use the running tally during JBP discussions on incremental investment versus expected lift.

When stock is tight, allocation policies decide which chain PO gets fulfilled first. The system supports priority by chain, by margin contribution, by penalty risk for delay, or by SLA. Allocations are reservation-based so two POs cannot double-allocate the same stock. Operations see a live view of committed stock per chain and can release reservations if a chain PO is cancelled.

DC returns (rejection at the chain's distribution centre during inbound check) flow through a separate workflow from store-level returns (damaged on arrival or near-expiry pulled by the chain). Each has its own reason codes, chain-specific credit-note formats, and approval routing. The original PO and dispatch documents stay linked so finance can reconcile the credit note back to the original invoice with full audit trail.

Hypermarket and supermarket chains often work on 60 to 90-day payment terms while convenience stores and wholesale clubs operate on shorter cycles. Credit terms are set per chain in the agreement master and applied automatically. Ageing dashboards highlight chains approaching the limit. Automated reminders go out before due dates. JBP-time exception reports show which chains have drifted from agreed payment behaviour.

Yes. REST APIs support bidirectional sync with SAP, Oracle, Microsoft Dynamics, Tally, and existing distributor systems. EDI message types and chain-specific B2B portal feeds are supported through the integration layer. Sales orders, invoices, dispatch notes, GRN, returns, and payment records flow between the DMS, the ERP, and each chain's system without manual rekeying.

KAMs see chain-wise order book, listing performance, range compliance, scheme ROI, and JBP-relevant metrics. Retail ops sees dispatch on time, DC return rate, claim ageing, and exception trends. Finance sees credit ageing per chain, trade investment running total, and reconciliation between dispatches and chain remittance. Drill-downs go from country to chain to store to SKU to PO line.

Onboarding a new chain involves capturing the listing master, the trade discount tree, the credit terms, the EDI or B2B format, the preferred DC mapping, and the return workflow. The configuration runs in the admin portal without code changes. A standard chain onboarding typically takes a few business days. Integration with a chain that uses non-standard EDI formats adds a short development sprint for the format mapping.