Direct answer: Accepting a customer portal (orders, shipping, reconciliation, documents) is not a check for "can the customer log in and see an order." It should verify the account and permission model, multi-tenant data isolation, order-status definitions, shipping and receipt timestamps, electronic reconciliation confirmation and evidence, document/drawing versions and withdrawal, ERP/CRM integration and failure handling, logs and classified protection, and personal-information notice. Otherwise customer A may see customer B's prices, or a reconciliation statement shows "confirmed" with no way to prove who confirmed which version.
This guide is for sales, customer service, finance, IT, legal, quality, and website/system vendors at manufacturers in Changzhou and nearby industrial areas. It explains how to build and accept a customer portal's order, shipping, reconciliation, and document modules. Information is current to 2026-11-01. It is a review of public rules and project practice, not legal, cybersecurity classified-protection assessment, or audit advice; specific portal functions, electronic-signature effect, protection level, and data processing depend on the contract, company policy, and regulator requirements.
A portal is not "moving ERP screens onto the website"; it shows each customer the right data, by permission, tenant, and version. Order status, shipping time, and reconciliation amounts need a single definition and source. An electronic reconciliation "confirm" must prove who confirmed, when, which version, and that the content was not altered.
How does the customer portal relate to dealer, download-center, and after-sales pages?
The dealer page handles channel authorisation and lead ownership, the download center handles public documents, the after-sales page handles repairs and spares, and the customer portal handles signed customers' orders, shipping, reconciliation, and controlled documents. They may share an account system, but data boundaries differ: public pages must not show customer-specific prices, and the portal cannot replace contracts or invoices.
Manufacturers usually start a portal because "customers keep calling to ask where the goods are." Then order status, shipping records, statements, invoices, COAs, drawings, and tickets all get added. The more features, the more important it is to define who sees what, where data comes from, and what a confirmation means. Otherwise the portal becomes a second Excel, only harder to maintain.
| Entry | Audience | What they see | Cannot replace |
|---|---|---|---|
| Dealer page | Channel and end customers | Territory, lookup, application | Orders and statements |
| Download center | Public visitors | Brochures, certificates, public docs | Controlled drawings and customer files |
| After-sales page | Existing customers | Repairs, spares, service policy | Orders and financial data |
| Customer portal | Signed customers and staff | Orders, shipping, statements, docs, tickets | Contracts, invoices, legal confirmation |
This split is editorial; account, data, and confirmation requirements are governed by the sources below.
How should portal scope and priorities be set?
Start with high-frequency, low-risk features that already have data: order status, shipping and logistics, statements and invoice downloads, COA/quality documents. Then add features needing approval or involving prices and drawings: customer-specific pricing, drawing release, online confirmation, tickets. For each, state the data source, update frequency, visible roles, and failure fallback.
The biggest portal risk is trying to do everything: orders, inventory, pricing, drawings, reconciliation, tickets, and complaints in one launch, with every module half-finished. A steadier path is to rank by the three questions customers ask most: where are the goods, what is this month's statement, and where is my inspection report. Get those three right, then expand.
| Feature | Data source | Visible roles | Priority |
|---|---|---|---|
| Order status | ERP order/work order | Customer procurement | High |
| Shipping/logistics | WMS/forwarder/courier | Procurement, logistics | High |
| Statements/invoices | Finance system | Finance, procurement | High |
| COA/quality docs | QMS/document system | Quality, procurement | High |
| Customer pricing | Pricing system | Authorised procurement | Medium |
| Drawings/technical data | PLM/document system | Technical (after NDA) | Medium |
| Online confirmation | Portal + evidence | Authorised signatory | Medium |
| Tickets/complaints | CRM/ticketing | Quality, service | Medium |
These features and priorities are editorial; the scope follows customer needs, system status, and the contract.
How should the account and permission model be accepted?
Design "company master account + sub-accounts + roles": the customer administrator manages sub-accounts, roles split by procurement/finance/quality/logistics, least privilege; enable multi-factor authentication, abnormal-login alerts, immediate disable on departure or role change, and periodic access reviews. Staff need separate back-office roles, not shared customer accounts.
The most common portal problem is "one account per customer, shared by the whole company," or sales giving a customer administrator rights to save effort. A departed employee can still log in, finance can see technical drawings, and company A can see company B's orders. Permission design is not a technical detail; it is the data boundary.
| Element | Requirement | Evidence | Common gap |
|---|---|---|---|
| Account hierarchy | Master + sub-accounts; master manages people | Account table | One shared account |
| Roles | Procurement/finance/quality/logistics/technical | Role matrix | Everyone is admin |
| Least privilege | Hidden by default, granted on need | Permission config | All-open default |
| MFA | SMS/OTP/QR; step-up for sensitive actions | Login logs | Password only |
| Lifecycle | Onboard, adjust on transfer, disable on exit | Change records | Ex-employees can log in |
| Access review | Quarterly/semi-annual review | Review records | Never reviewed |
| Staff accounts | Back-office roles isolated | Back-office config | Sales uses customer account |
This model is editorial; operation permissions and security measures for personal information are in Article 51 of the Personal Information Protection Law.
How should multi-tenant isolation be accepted?
Give each customer a tenant ID and filter every query by tenant; file downloads use short-lived signed URLs, not guessable paths; exports, search, reports, caches, and notifications must not cross tenants; internal cross-tenant access needs separate authorisation and logs. Test with two accounts trying to access each other's orders, invoices, drawings, and tickets.
Cross-tenant leakage is the worst portal incident: customer A opens an order and sees company B's prices and lead times, or search results show another company's invoice number. Technically it often comes from hiding data only in the front end while the API still queries by ID. Acceptance must test APIs and authorisation, not just screens.
| Surface | Requirement | Test | Common gap |
|---|---|---|---|
| Queries | Every API filters by tenant | Authorisation test | Front-end hiding only |
| File download | Short-lived signed URL, permission check | URL tampering | Guessable paths |
| Search/reports | Results isolated by tenant | Cross search | Data bleed |
| Export | Approval + watermark + log | Export records | Free export |
| Notifications | Only to the right contacts | Email/SMS test | Wrong recipients |
| Cache | Tenant-scoped keys, correct invalidation | Switch accounts | Cache bleed |
Isolation requirements are editorial; implementation follows system architecture and security testing.
How should order, shipping, and reconciliation data be defined?
Define each status: confirmed, scheduled, in production, ready to ship, partially shipped, shipped, delivered, invoiced, reconciled, paid; state timestamp sources (ERP/WMS/forwarder), time zone, partial shipments, and change orders. Statements must reconcile with invoices, orders, and shipping records, and every difference needs a reason and owner.
"Where are the goods" looks simple but spans orders, scheduling, shipping, logistics, and receipt. If the portal shows ERP's "shipped" as "delivered," the customer may schedule payment on receipt; if a partial shipment shows as a full shipment, reconciliation will not match. Status definitions and sources are the foundation of portal credibility.
| Object | What to define | Source | Common gap |
|---|---|---|---|
| Order status | Meaning of each status, transition rules | ERP | Inconsistent names |
| Timestamps | Order/confirm/ship/deliver times | System logs | Manual entry |
| Time zone | Unified or labelled | System config | Mixed domestic/overseas |
| Partial shipment | Batch quantity, remaining | WMS | Shown as fully shipped |
| Change orders | Quantity/lead-time history | Order system | Old value overwritten |
| Reconciliation | Period, amount, tax, differences | Finance | Does not match invoice |
| Payments | Receipt date, currency, allocation | Finance | Receivable only |
These definitions are editorial; specific fields and sources follow the ERP/WMS/finance systems and company policy.
How should electronic reconciliation and online confirmation be accepted?
A statement needs a unique number, version, period, amount and tax, and difference notes; online confirmation should record the confirmer, time, IP/device, version, and file hash. Where a reliable electronic signature is used, it should meet the conditions of exclusivity, control, and detectability of changes. Whether a simple "click to confirm" suffices depends on the contract and the evidence chain.
Article 13 of the Electronic Signature Law provides that an electronic signature is reliable if the signature creation data is exclusive to the signatory when used, is controlled only by the signatory at signing, any change to the signature is detectable, and any change to the content and form of the data message is detectable. Article 14 gives reliable electronic signatures the same legal effect as a handwritten signature or seal. Article 469 of the Civil Code also treats data messages that can tangibly represent the content and be retrieved at any time as written form.
| Element | Requirement | Evidence | Common gap |
|---|---|---|---|
| Statement version | Number, period, version, amount, tax | PDF/record | Old version overwritten |
| Confirmer | Name, company, role, authority | Account + authorisation | Shared account |
| Time/device | Timestamp, IP, device | Logs | No record |
| Integrity | File hash, tamper evidence | Evidence store | Editable later |
| Reliable e-signature | Exclusive, controlled, change-detectable | Signature report | Click treated as signature |
| Differences | Reason, owner, deadline | Difference note | Handled verbally |
Signature conditions are in Articles 13 and 14 of the Electronic Signature Law; written form for data messages is in Article 469 of the Civil Code; effect depends on the contract and evidence chain.
How should document and drawing release and withdrawal be accepted?
Controlled documents need a version, effective date, scope, watermark, and download log; drawings/technical data are released by project after NDA, with withdrawal and expiry support; customers see only their relevant version, and old versions are explicitly void. Withdrawal must reach the right people and retain who downloaded which version when.
Portal documents are not a cloud drive. COAs, FAI reports, drawings, and work instructions all have versions and scopes; sending the wrong version is worse than sending nothing. Acceptance should test whether old versions remain downloadable, whether links fail after withdrawal, whether downloads carry a customer watermark, and whether logs trace to a person.
| Item | Requirement | Evidence | Common gap |
|---|---|---|---|
| Version | Number, effective date, scope | Metadata | Filename as version |
| Authorisation | By customer/project/role | Permission record | Visible to all |
| Watermark | Customer/account/time | PDF sample | No watermark |
| Download log | Who, when, which version | Logs | No record |
| Withdrawal | Link invalid, notice sent | Withdrawal record | Old link still works |
| Expiry | Auto-expire after validity | System status | Permanent access |
Document-control requirements are editorial; specific versions, authorisation, and withdrawal follow the document-control procedure and contract.
How should integration, logs, and security be accepted?
Define frequency, retry, idempotency, and reconciliation-difference handling for ERP/WMS/finance sync; logs should cover login, queries, downloads, exports, confirmations, and back-office actions, retained at least six months under classified-protection requirements; implement data classification, backup, encryption, vulnerability remediation, and incident drills, and minimise and disclose personal information.
The Cybersecurity Law was amended in 2025 and took effect on 2026-01-01; the classified-protection system is now Article 23: network operators must establish rules, designate a security lead, take preventive measures, monitor and record network status with relevant logs retained at least six months, and classify, back up, and encrypt data. Note the article number: from 2026 the amended text applies, and the old Article 21 is now a publicity-education provision—do not cite the old number. Article 51 of the Personal Information Protection Law also requires internal rules, classification, encryption/de-identification, reasonable operation permissions, training, and contingency plans.
| Item | Requirement | Evidence | Common gap |
|---|---|---|---|
| Sync | Frequency, retry, idempotency | Sync logs | Manual patching |
| Differences | List, owner, deadline | Difference record | No fallback |
| Logs | Login/query/download/export/confirm | Log platform | Login only |
| Retention | Relevant network logs ≥ 6 months | Retention policy | Overwritten in 7 days |
| Classified protection | Filing/assessment per system level | Filing/report | Not classified |
| Backup/encryption | Classification, backup, transport encryption | Policy/config | Plaintext transport |
| Personal data | Notice, minimisation, permissions | Privacy policy | Over-collection |
Classified protection and log retention are in Article 23 of the Cybersecurity Law (2025 amendment, effective 2026-01-01); personal-information measures are in Article 51 of the Personal Information Protection Law.
Access review can be estimated: 200 accounts × 2 minutes ≈ 6.7 hours per review, or about 27 hours a year if quarterly. This is an illustrative assumption to show workload, not a quotation; actual account counts and review depth depend on the company.
How should portal pages and back-office modules be designed and linked?
Customer-side modules should include login and MFA, order list/detail, shipping and logistics, statements and invoices, COA/documents, tickets, and account management; back-office modules should include customers/tenants, roles and permissions, document release/withdrawal, reconciliation confirmations, logs, and export approval. Link to after-sales, download center, privacy policy, and contact page, and state "portal data follows ERP/finance."
A portal should not expose every back-office table to customers. Organise the customer side around "what I need to do now": check an order, see shipping, reconcile, download a report, raise a ticket; organise the back office around "who can change what": accounts, permissions, documents, logs. Both need failure fallbacks: when sync fails, show "subject to customer service confirmation" instead of a blank or a wrong number.
| Module | What to build/write | Evidence | Common gap |
|---|---|---|---|
| Login | MFA, abnormal alerts, recovery | Login logs | Password only |
| Orders | Status, changes, partial shipment | ERP sync | Vague status |
| Shipping | Tracking, receipt, exceptions | WMS/forwarder | Only "shipped" |
| Reconciliation | Version, differences, confirmation, evidence | Records | Click = confirmed |
| Documents | Version, watermark, withdrawal, logs | Document system | Cloud-drive style |
| Tickets | Intake, progress, closure | Ticketing | No status |
| Accounts | Master manages subs, disable on exit | Account records | Support manages |
| Back office | Permissions, release, logs, export approval | Config | No audit |
These modules are editorial; specific features, data, and permissions follow the company systems and customer contract.
Go-live acceptance checklist
Ten checks: accounts and permissions, tenant isolation, order-status definitions, shipping and receipt, reconciliation confirmation and evidence, document versions and withdrawal, integration and fallback, logs and classified protection, personal-information notice, and links/mobile. Each needs an owner, evidence, and review date.
Sales, customer service, finance, IT, legal, quality, and the system vendor can share this list. The pass condition is not "the customer can log in"; it is that each customer sees only their data, status and amounts reconcile, confirmations are traceable, documents are version-controlled, logs are retained, and failures have a fallback.
| Check | Pass condition | Evidence | If it fails |
|---|---|---|---|
| Accounts/permissions | Master/sub accounts, roles, MFA, disable on exit | Account/permission table | Add model |
| Tenant isolation | Authorisation tests cannot see others' data | Test report | Fix APIs |
| Order definitions | Statuses, timestamps, partial shipments | Status table | Add definitions |
| Shipping/receipt | Tracking, receipt, exception handling | Logistics records | Add data |
| Reconciliation | Version, confirmer, time, hash/evidence | Records | Add evidence |
| Documents | Version, authorisation, watermark, withdrawal | Document logs | Add controls |
| Integration | Sync, retry, idempotency, difference handling | Sync logs | Add fallback |
| Logs/protection | Key-action logs ≥ 6 months; filing/assessment | Logs/filing | Add retention |
| Personal data | Notice, minimisation, permissions | Privacy policy | Add notice |
| Links/mobile | After-sales/download/privacy/contact reachable; usable at 390px | Page test | Fix links |
This checklist is editorial; specific functions, security, classified protection, and personal-information requirements follow the contract, company policy, and regulator requirements.
Who should read this, who should not, and what decisions does it support?
It suits manufacturers in Changzhou and nearby areas with high order volumes, frequent shipping and reconciliation questions, COA/drawing release needs, or after-sales tickets. It does not suit companies with only occasional orders, customers who prefer WeChat, or teams without ERP/finance data foundations that want to build a portal directly.
Read it if you are in sales, customer service, finance, IT, legal, quality, or a system/website vendor; you are building a customer portal, order lookup, reconciliation, document release, or after-sales tickets; or you need to decide which features first, how accounts are split, how data is isolated, how confirmations are evidenced, and how long logs are kept. Skip it if your ERP data is inaccurate but you want the portal to "beautify" it; you treat the portal as a substitute for contracts, invoices, or legal confirmation; or you want one page to replace classified-protection assessment, e-signature, or legal advice. It supports self-review of accounts and permissions, tenant isolation, order definitions, reconciliation evidence, document control, integration fallback, logs, and personal-information notice.
Lingyi Information is a website development and enterprise AI project provider, not a classified-protection assessment body, electronic authentication service, or law firm. This article is not a substitute for legal, cybersecurity classified-protection, e-signature, or audit advice. Changzhou projects are delivered remotely or on site as confirmed per project; Lingyi is one candidate, does not claim a local office or team, and does not promise assessment results, launch dates, or inquiries.
FAQ
Should we build the customer portal ourselves?
Depends on order volume and existing systems. With few orders and simple needs, start with a light portal for order status, shipping, and statement downloads, or use the ERP's customer portal module; with high volume, drawing release, and multi-role permissions, consider custom development. The key is data definitions and permissions, not the build method.
Can customers share one account?
Not advisable. A shared account cannot trace who viewed or confirmed what, and cannot be disabled individually after someone leaves. At minimum use a company master account plus sub-accounts with role-based permissions; where sharing is unavoidable, limit visible data and keep operation logs.
Does clicking "confirm" on an electronic statement have legal effect?
Depends on the contract and evidence chain. A reliable electronic signature has the same effect as a handwritten signature or seal under Articles 13 and 14 of the Electronic Signature Law; an ordinary click may also constitute an expression of intent, but you must be able to prove the confirmer, time, version, and content integrity. Record account, time, IP, and file hash, and use reliable e-signature or platform evidence for important reconciliations.
How long should portal logs be kept?
Article 23 of the Cybersecurity Law (2025 amendment, effective 2026-01-01) requires relevant network logs to be retained at least six months as prescribed; companies may keep longer based on system level, contract, and policy. Login logs alone are not enough—queries, downloads, exports, confirmations, and back-office actions must also be logged.
What if the portal's shipping status differs from what customer service says?
Define a single source and status definition; the portal shows the source system's value and does not edit manually. When sync fails, show "subject to customer service confirmation" and record the exception instead of a blank or stale value. Reconciliation differences need a difference note and an owner.
Can drawings be downloaded directly from the portal?
Yes, with customer/project authorisation, release after NDA, customer watermark, download logs, withdrawal, and expiry. The public download center should hold only brochures, certificates, and public documents—not customer drawings or proprietary technical data.
One-sentence takeaway
A Changzhou manufacturer's customer portal is not about "logging in to see orders"; it is about accounts and permissions, tenant isolation, order definitions, shipping and receipt, reconciliation evidence, document versions, integration fallback, logs, and personal-information notice being verifiable—so each customer sees only their data, amounts reconcile, and confirmations are traceable.
Method and limitations
This is a review of public rules and project practice, not a compliance certification or legal opinion on any company, portal, system, reconciliation, e-signature, or classified protection. No undisclosed customer accounts, orders, statements, or drawings were used. Feature priorities, permission models, status definitions, isolation tests, and the acceptance checklist are editorial suggestions; the access-review example (200 accounts × 2 minutes ≈ 6.7 hours per review) is an illustrative calculation, not a quotation or commitment. Actual portal functions, permissions, e-signature effect, protection level, log retention, and personal-information processing depend on the law, contract, company policy, and regulator requirements.
Sources and scope
Information is current to 2026-11-01. The following are public official/primary pages; their scope, version, and wording control.
- Electronic Signature Law of the PRC (2019 amendment): National People's Congress. Article 13 (reliable signature conditions), Article 14 (equal effect), Article 15 (custody and loss notice).
- Civil Code of the PRC, contract book: Supreme People's Court. Article 469 (data messages as written form).
- Cybersecurity Law of the PRC (2025 amendment, effective 2026-01-01): Cyberspace Administration of China. Article 23 (classified protection, logs at least six months, classification/backup/encryption).
- Personal Information Protection Law of the PRC: Cyberspace Administration of China. Article 17 (notice), Article 51 (security measures and operation permissions).