Distributor Ordering System Migration: Price Lists, Accounts and Open Orders

A distributor ordering system migration usually starts with three sets of records: price lists maintained in spreadsheets, distributor profiles held by sales or finance, and orders still moving through approval, payment, allocation or shipment. For international brands managing a China distributor network, these records connect commercial policy to local fulfilment and financial systems. Loading them in the wrong sequence can expose the wrong prices, reprice an existing order or send already-shipped goods to the warehouse again.

The objective is continuity: the same distributor, pricing agreement and open order must remain identifiable, explainable and actionable after cutover. Moving every historical record into the new platform is a separate decision, driven by retrieval and audit needs.

Cutover boundaries come before import templates

Before deciding which spreadsheet columns to upload, define the data snapshot, the cutoff for orders in the old channel and the time the new channel opens. The snapshot establishes the reference data extracted for migration. After the order cutoff, the old entry point should stop accepting new valid orders. After launch, distributors place new orders through the replacement platform. These events can share a date or occur separately, but the cutover plan must specify who may change which records after each event.

Assign system responsibilities at the same time. The PEKON B2B Ordering Platform can support distributor profiles, eligible products, prices and promotions, order approval and ordering progress. The authoritative records for products, customers, inventory, shipments and financial results may remain in ERP, warehouse management or other systems, depending on the brand’s architecture.

Each open order needs one designated system for subsequent processing. Keeping two editable copies and expecting them to remain aligned creates unnecessary risk. The other system should provide read-only access or receive agreed status updates. Completed orders may remain archived; active distributors, current or forthcoming price lists and unfinished transactions need operational continuity.

Convert spreadsheet price lists into executable rules

A commercial team may keep one spreadsheet per region, a separate column for key accounts, or an amended copy of last month’s list. Staff can interpret the context; software needs explicit product identifiers, customer eligibility, effective dates and precedence for every price.

Keep temporary quotations and one-off approved prices distinct from recurring price lists. A policy negotiated for one transaction may belong in that order’s price snapshot rather than the new platform’s general pricing rules. Model promotions, rebates, free goods and quantity discounts separately from the base price, then define whether they can be combined.

A particular risk is repricing old orders at launch. Suppose a distributor pays CNY 90 per unit in September and the price falls to CNY 86 on October 1. An order submitted on September 28 with a confirmed CNY 90 price must retain it even if shipment remains incomplete. The new price applies only to eligible new orders. A deliberate price change requires the brand’s approval process; migration itself must not overwrite the confirmed transaction.

Distributor records establish identity and access

A distributor profile determines who can sign in, which products they can see, which prices apply, where deliveries go and which actions require approval. It is more than a company-name and phone-number list. Reliable identity mapping must precede pricing and open-order migration.

Retain a stable distributor code and map it to the ERP customer code. Manage the legal name, China Unified Social Credit Code where applicable, invoicing details, settlement entity, region, tier, contract status, delivery addresses and contacts as separate attributes. One legal entity may have several delivery locations and ordering users. It should not become several duplicate distributors simply to support multiple logins. A phone number that has been used for different companies is also unsuitable as the sole distributor identifier.

Classify profiles before activation. Active trading distributors enter the new system with confirmed accounts. Temporarily inactive distributors with open transactions may retain the permissions needed to complete those transactions without being allowed to place new orders. Long-inactive profiles with no unfinished business can remain in historical lookup or archives. Resolve former employees, expired contracts, invalid addresses and duplicate customers before opening access.

Link each login to both the distributor entity and its actual user. Do not copy legacy passwords into the new platform. Use the invitation, identity-verification or first-login reset process agreed for the project. Remove shared, departed-user and obsolete accounts as appropriate, and distinguish the distributor’s contract status from each user account’s active or inactive status.

Account balances also need their underlying states. Credit should distinguish approved, committed and available amounts. Prepayments should distinguish available, frozen and processing amounts. Rebates should retain the brand’s categories, such as pending confirmation, available, used and expired. Use one agreed snapshot time and reconcile each category with finance or ERP before loading it.

Identify the ledger owner for each account and how subsequent reservations, releases, deductions and adjustments reach the ordering system. Import only the agreed data scope, retaining source references and adjustment history rather than treating one opening balance as a complete audit trail.

Hand over open orders by business status

A draft has not created the same commitment as a paid order. A partially shipped order already links to fulfilment documents in ERP and WMS. Importing every unfinished row as “pending” discards approvals, payments and shipment facts that have already occurred.

For a paid order, migrate evidence of payment and the external transaction references, not a new payment instruction. Retain merchant order references, payment request references and channel transaction IDs for online payments; remittance-allocation evidence for bank transfers; and ledger entries for prepayment deductions. If the new platform cannot refund through the original payment channel, complete the refund in that channel or the finance system and write the final result back to the order.

Each migrated order should retain its legacy order number, distributor code, ERP document reference, original submission time, price version, total value, amount paid, ordered quantity, shipped quantity, cancelled quantity, returned quantity and remaining work. Where the old system lacks stable order numbers, create a migration business reference and retain the source identifiers needed to trace it back.

Once the new platform owns an order, the old platform should stop changing its business status. Orders deliberately left in the old system require a documented scope and lookup arrangement so that customer service does not chase payment, change quantities or close the same order in both places.

A partially shipped order crossing the launch date

Distributor D001 has order O20260928 for 100 units at CNY 90 each. It is fully paid. ERP has shipped 60 units, leaving 40 awaiting replenishment. On October 1, the replacement price list reduces the product price to CNY 86.

After migration, the new platform should still show 100 ordered, 60 shipped and 40 outstanding, at CNY 90 each. The original CNY 9,000 total remains unchanged. Replenishment proceeds for the remaining 40 units against the original order and ERP references. Eligible orders created after the new list takes effect use CNY 86. A distributor-tier upgrade during cutover must not retrospectively change this order’s price or approval result.

Reconcile four areas: the order total against the amount paid; shipped quantities against ERP and WMS; outstanding quantities against ordered, shipped and cancelled quantities, with returns checked separately; and the next outbound ERP message. Whether a return restores outstanding demand depends on the brand’s policy. The new system must send only the agreed remaining business or status query, not reissue the entire original order as a new sale.

A dependency-based distributor ordering system migration

Prepare product and organizational codes first, then establish distributor identities. Once products and distributors are mapped, validate price-list applicability. Only then can open orders be attached to reliable customer, product and commercial records.

1. Define scope and ownership. List records to migrate, finish in the old system, expose as read-only or archive, with an accountable business owner for each.
2. Build mappings. Document product and unit conversions, distributor and address mappings, price-list versions, order-status translations and external references.
3. Run a sample migration. Include regions and distributor tiers, multiple addresses, special prices, unpaid and paid orders, and partial shipments.
4. Rehearse at representative scale. Follow the planned extraction, cleaning, import, integration and reconciliation sequence. Record timing, failed rows and correction versions.
5. Freeze the old channel and transfer changes. Extract the final increment after the agreed cutoff and account for every order created between snapshots.
6. Apply launch and recovery criteria. Unexplained material differences in distributor identity, effective prices, open-order values or remaining quantities should block opening the new channel. If widespread pricing errors, duplicates or integration failures appear after launch, stop accepting new orders, preserve submitted business and follow the agreed repair, incremental transfer or rollback plan. Do not reopen both channels for concurrent ordering.
7. Open access after acceptance. Sales, finance, supply chain and representative distributors validate the results before the service opens to the full network.

Retain source files, mapping versions, import logs and discrepancy reports for each run. Repeating the same batch must recognize existing distributor codes, price-list versions and business order references. It must not create duplicate customers, overlay conflicting prices or generate new copies of orders.

Migration evidence should include a data dictionary, mapping tables, import logs and business test scripts. These deliverables make supplier capability assessable and allow another team member to understand and repeat the transfer.

Validate totals, individual records and real operations

A report saying “100,000 rows imported” confirms execution, not business readiness. A distributor must be able to log in, see the right products and prices, and continue an existing order from its real status. Finance and supply-chain teams must be able to explain discrepancies.

• Reconcile total, active, inactive and exception distributor counts to the approved scope.
• Trace every effective price list to its distributors, products, validity period and version, and sample the calculated results.
• Reconcile open-order counts, values and quantities by status. Assign a reason, owner and resolution date to each discrepancy.
• Confirm that partial shipments process only the balance, paid orders do not collect payment again, and original and external references remain searchable.
• Repeat imports and simulate interface interruptions or individual-row failures. Successful records must not duplicate; failed records must be correctable and rerunnable.
• Make the ownership boundary between legacy and new orders clear to customer service, finance and the warehouse.

Use the brand’s own data during acceptance. Have two distributor tiers order the same SKU and check the price list, unit and effective period. Open one paid-but-unshipped order and one partially shipped order, checking original prices, payment references and outstanding quantities. Finally, rerun the batch and confirm that no second set of distributors, price lists or orders appears.

The PEKON B2B Ordering Platform covers distributor ordering, price lists and promotions, approvals, account operations and reconciliation, with interface scope for products, customers, inventory, orders, shipments, returns and price lists. Data cleaning, master-data ownership, surrounding-system changes and open-order handover require project-specific confirmation. Classify each requirement as standard functionality, configuration, integration, custom development or unsupported.

Migration is accepted when distributors can order under the right identity and commercial terms, open transactions can continue without losing their history, and the brand can reconcile source files, imported records and downstream documents.

FAQ

Does every historical order need to move into the new system?

No. Completed orders can be migrated in detail, retained as summaries or archived in the legacy system according to retrieval and audit requirements. Orders with remaining approvals, payments, allocation, shipments, returns or refunds need the most attention. Historical records must remain retrievable by their original references.

Can price lists be imported against customer names alone?

Stable distributor codes are safer because names may be abbreviated, duplicated or changed. Include product codes, ordering units, tax treatment, effective dates and rule priority, and resolve overlapping prices before import.

Should unpaid orders stay in the old system?

Either approach can work if only one processing route remains active. A transferred order needs its original reference, payable amount, price snapshot and payment-request relationships, with duplicate payment capability disabled in the old channel. An order left for completion in the old system must not be recreated as a new unpaid order.

How should credit and rebate balances be transferred?

Identify the ledger owner and use a common snapshot time. Separate approved, committed and available credit; available, frozen and processing prepayments; and the applicable pending, available, used and expired rebate states. Sales and finance should approve the results with source references, adjustment records and effective times.

What proves that open-order migration has passed acceptance?

Compare order counts by status and reconcile each order’s total, amount paid, ordered, shipped and outstanding quantities. Then complete realistic follow-on actions such as approval, matching a receipt, shipping the balance, cancellation or return. Matching totals without continued fulfilment, or workable screens without traceable original transactions, is insufficient.

A practical migration acceptance checklist

Organize the project’s checklist into distributor profiles, price lists, open orders, account balances, cutover and recovery, and acceptance sign-off. Record snapshot times, differences, responsible owners and retest results. This gives sales, finance, supply chain, IT and the supplier a shared written basis for opening distributor access.

Brands replacing spreadsheet ordering or a legacy portal can begin with their current price list, distributor file and three to five representative open-order states. These samples provide a concrete basis for agreeing migration scope and on-site validation with PEKON.