# 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.