Files

82 lines
3.7 KiB
Markdown

# Product
<!-- impeccable:product-schema 1 -->
## Platform
Web application with one role-aware sign-in entry and two independent portals.
## Users And Portals
- **Group administrator portal**: manages companies, company users, system
settings, reminders, all bank flows, reconciliation exceptions, and every
company-to-company position.
- **Company cashier portal**: is bound to exactly one company and can upload,
review, query, and export only that company's bank flows and exceptions.
The portals have different navigation, homepages, priorities, and URLs. They
must not be implemented as one dashboard with hidden controls.
## Product Purpose
Centralize group bank statements, prevent local-file data loss, identify
internal transfers, and calculate traceable company-to-company positions with
software-led reconciliation and human exception review.
## Core Accounting Model
- One or two bank-side observations may represent one canonical transfer.
- Same-company transfers between bank accounts affect account cash history but
never affect intercompany positions.
- Intercompany positions are presented as debit and credit totals, then by
counterparty and subject: `应收`, `应付`, `其他应收`, `其他应付`.
- Bank evidence can determine amount, direction, date, parties, and matching
state. Statutory subject classification uses deterministic rules plus
audited exception confirmation; it is never silently guessed.
## Calculation Window
- The group administrator owns one global calculation start date, opening
balances, and the monthly closing day.
- Imported rows before the start date remain preserved but are excluded from
calculations.
- If the earliest accepted statement begins after the start date, both portals
show a coverage gap.
- A cashier may attest that no transactions occurred during a gap. The
attestation requires a reason and creates an immutable audit record.
- Without an opening balance, the result is labelled `期间净变动`, not
`期末余额`.
## Capabilities And Constraints
- Companies, users, accounts, aliases, effective dates, and opening balances
are dynamic master data and are never hard-coded as product configuration.
- Bank templates are identified from header signatures rather than fixed row
or column positions.
- Imported files and rows remain immutable; corrections use audited mappings,
reversals, or adjustments.
- Cashiers may submit manual records for personal transit flows or facts that
are not represented by a bank row. Manual records remain separate from bank
evidence and affect positions only after administrator approval.
- Cashiers submit bank-account registrations. An account becomes active master
data only after administrator review; pending accounts cannot identify
ownership, accept statement uploads, or affect coverage calculations.
- Personal transit-account flows require a known mapping or manual association.
- External messaging is future scope; the current product provides in-product
automatic reminders and administrator-triggered manual reminders.
## Evidence On Hand
The `流水模板` directory contains statement samples from CITIC Bank,
Agricultural Bank of China, ICBC, China Construction Bank, Henan Rural
Commercial Bank, and Bank of Zhengzhou. The set includes both `.xls` and
`.xlsx`, variable header positions, and different debit/credit conventions.
## Product Principles
- Automate deterministic facts and route uncertainty to a small exception queue.
- Never count two bank observations as two economic transfers.
- Always show the effective calculation window and unresolved coverage gaps.
- Keep cashier work centered on upload, validation, and exception handling.
- Make every position traceable from company total to original bank evidence.