Why one back office keeps multi-end data from forking

Split entries by role so they are usable. Split the back-office database by role and you schedule reconciliation meetings. Status a customer sees in a mini program must equal the ticket the employee just submitted or self-serve is fake. See Why customers need a self-serve status page. Store redemption must deduct the same stock. See After the store app shares HQ stock and membership. Ship quantities suppliers return must land on the same PO. See Why suppliers cannot live on emailed spreadsheets.

“Build separately and connect later” rarely connects

Later you face different keys, different item codes, different definitions of “done.” API specs can phase. Master data must be owned in phase one: who decides SKU, customer, store, supplier. Cost looks like extra ends. The expensive part is two ledgers. How to estimate cycle. See What APP, mini program and H5 cost, and how long they take.

H5, mini program and native can coexist. Logic cannot exist twice

Campaign H5, member mini program, field APP—normal. Three order APIs each computing their own stock—not normal. How to pick the main entry. See Mini program or APP as the main entry.

Master data needs an owner in phase one

Who can create SKUs, customer numbers, store codes—write it into permissions. Mobile only consumes those codes. Do not invent a second “front-end item name” in the mini program. Reports come only from the back office. Ban a store manager’s private “convenient” sheet as truth. Once management tolerates the fork, pretty APIs still get overwritten by a spreadsheet at month end.

APIs can phase. You cannot have two state machines

Phase one can be employee report-only and customer lookup-only. “Done” on report and “done” on lookup cannot mean different things. Field names, enums and void rules live in one spec both ends obey. If an old POS must stay for a while, lock one-way sync: store writes HQ; the two must not overwrite each other. Reconciliation day follows HQ.

Identity, price changes and stock locks must apply on every end at once

Employees use a company account, customers a phone number, suppliers an invite code, stores a store ID—four identities map to one permission model. Item-code changes need an effective date so the mini program is not still selling a voided SKU. A back-office price change must hit every entry. Do not change Web and forget the mini program. Stock locks must be visible on every end so a store can sell while the customer side still shows in stock. The same user’s tasks across ends must dedupe so both sides do not process once. Voided tickets disappear on every entry at once—not only on the desktop back office.

DaXi Technology delivers multiple ends on one back office. Management stays on the Web. To connect an existing mini program to the business system, go to the mobile service page and say how many account sets run in parallel now.