沉淀页面设计规则（page-design-rules-audit）
这个提交包含在：
@@ -160,6 +160,48 @@ change the visual treatment once while preserving component contracts.
|
||||
- Focused Playwright screenshot coverage when changing login, Portal, primary
|
||||
PC list pages or command-bar/table styling.
|
||||
|
||||
## Convention: Page Template Taxonomy
|
||||
|
||||
**What**: hyb-oa frontend pages use six layout templates. New or redesigned
|
||||
pages must pick one primary template before implementation:
|
||||
|
||||
- `工作台总览`: Portal and mobile home. Compact summary, today's actionable
|
||||
items, conditional progress/blocker/reminder sections.
|
||||
- `任务处理列表`: workflow task queues. Pending summary, task list, processed
|
||||
records and advanced filters.
|
||||
- `业务台账列表`: reimbursement, contracts, projects, payments, AP and invoices.
|
||||
Page-header primary action, command bar, list/table body and folded ledger
|
||||
tools.
|
||||
- `主从工作台`: procurement, assets and inventory checks. Left/index list plus
|
||||
right/current-object detail and actions.
|
||||
- `详情工作区`: reimbursement detail, workflow task detail, project detail and
|
||||
future contract detail. Overview, facts/evidence, right-side summary/command
|
||||
panel and history.
|
||||
- `管理配置页`: people, organization, master data, approval rules, workflow
|
||||
definitions, feature flags and audit logs. Grouped settings, searchable
|
||||
tables and confirmed destructive/configuration actions.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- A page has one primary template. Local sections may reuse shared components,
|
||||
but the page must not mix ledger, configuration, detail and dashboard patterns
|
||||
without an explicit Trellis task.
|
||||
- Mobile is the responsive expression of these templates: top status/focus,
|
||||
card list or sectioned detail, bottom primary action. Do not create a PC shell
|
||||
inside mobile routes.
|
||||
- B-class business pages should usually choose `业务台账列表` or `主从工作台`.
|
||||
Use a ledger when records open into details; use master-detail when users
|
||||
select one object and edit/process it in the same workspace.
|
||||
- A-class task pages must not drift into configuration surfaces. C-class
|
||||
configuration pages must not appear as ordinary employee task pages.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright or screenshot checks for changed A-class, mobile or shared
|
||||
template surfaces.
|
||||
|
||||
## Convention: Global Shell And Page Header Baseline
|
||||
|
||||
**What**: PC page redesigns should preserve the shared Wave0-2 shell and
|
||||
@@ -168,8 +210,10 @@ header baseline instead of recreating page-local wrappers:
|
||||
- `AppShellLayout` owns the PC shell background and content offset through
|
||||
`app-shell` and `app-shell-main`.
|
||||
- `Sidebar` and `NavLinks` own role-aware task navigation. The mental model is
|
||||
a short primary task list plus collapsed `更多`; management configuration is
|
||||
represented by one `管理` entry instead of many sidebar rows.
|
||||
a task-first primary list plus collapsed `更多`; enabled OA-owned business
|
||||
ledgers such as contracts, procurement, assets and projects should not be
|
||||
hidden in `更多` by default when the current role has access. Management
|
||||
configuration is represented by one `管理` entry instead of many sidebar rows.
|
||||
- `Topbar` is a compact command surface: page title, group badge, user context,
|
||||
global search and notifications. Do not expand it back into a large hero.
|
||||
- `PageHeader` and `WorkspaceHeader` should use `page-header-shell`,
|
||||
@@ -187,6 +231,10 @@ point and prevents each route from inventing a different title/action layout.
|
||||
- Sidebar entries should be role-aware and task-first for domestic tech startups
|
||||
under 10 people; do not expose all permission-allowed modules as a default
|
||||
module catalog.
|
||||
- Do show enabled, permission-allowed day-to-day business ledgers directly in
|
||||
the primary sidebar, including `合同`, `采购`, `资产` and `项目` when relevant.
|
||||
`更多` is for low-frequency, frozen, staged or occasional entries, not a
|
||||
place to bury common work.
|
||||
- Approvers see `待我处理`; ordinary employees should not see `待办` or
|
||||
`审批待办` in the sidebar by default.
|
||||
- PC leave navigation uses `请假记录` unless the current task explicitly opens OA
|
||||
@@ -196,8 +244,9 @@ point and prevents each route from inventing a different title/action layout.
|
||||
- Finance labels should use work names such as `付款`, `应付账款` and `票据`;
|
||||
internal platform words like `AP 运营`, `ERP 集成` and `功能开关` should be
|
||||
hidden behind management wording or renamed for users.
|
||||
- `更多` is a lightweight collapsed row for low-frequency entries; do not add a
|
||||
sidebar explanation card, subtitle or onboarding copy around it.
|
||||
- `更多` is a lightweight collapsed row for low-frequency, frozen, staged or
|
||||
occasional entries; do not add a sidebar explanation card, subtitle or
|
||||
onboarding copy around it.
|
||||
- Playwright navigation helpers should use exact names or anchored regex for
|
||||
short sidebar labels such as `管理`, otherwise fuzzy role-name matching can
|
||||
click longer labels such as `预算管理`.
|
||||
@@ -220,6 +269,823 @@ point and prevents each route from inventing a different title/action layout.
|
||||
`Topbar`, `NavLinks`, `PageHeader`, `WorkspaceHeader`, login, Portal or other
|
||||
A-class pages.
|
||||
|
||||
## Convention: Action Placement Baseline
|
||||
|
||||
**What**: Page actions, filters, ledger tools and destructive commands use one
|
||||
system-wide coordinate model. New and redesigned pages should not invent
|
||||
page-local action placement.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- PC page primary action lives in the page header action area
|
||||
(`WorkspaceHeader` / `PageHeader` actions). Keep one primary action per page
|
||||
surface and at most two visible secondary actions.
|
||||
- List filters live in the first command bar below the page header. Search,
|
||||
status, scope and other common filters stay on the left; ledger tools such as
|
||||
export, batch, statistics, templates and advanced filters stay on the right or
|
||||
inside `台账工具` / `更多`.
|
||||
- Row-level actions live at the right edge of a table row or at the tail of a
|
||||
card. Prefer `查看详情`, `查看处理` and `继续编辑` over broad verbs that hide the
|
||||
result.
|
||||
- Detail pages keep facts and evidence in the main content. High-risk actions
|
||||
such as approve, reject, return, pay, publish, delete and configuration
|
||||
switching live in the right command panel or a clearly separated
|
||||
`detail-action-stack`, with confirmation that includes the current object
|
||||
summary.
|
||||
- Form save/submit actions live at the form bottom on PC. Long forms may add a
|
||||
right-side summary command panel, but the same action should not be repeated in
|
||||
unrelated header, row and footer locations.
|
||||
- Mobile pages use top status/focus content plus a bottom safe-area action
|
||||
surface for the primary action. Do not copy PC command bars or wide tables
|
||||
into mobile routes.
|
||||
- Batch actions only appear after selection, as a contextual command bar or
|
||||
bottom sticky bar.
|
||||
- Destructive, financial, approval and configuration-changing actions must be
|
||||
visually and structurally separated from normal navigation/edit actions.
|
||||
|
||||
**Why**: hyb-oa targets small teams where one person may switch roles many times
|
||||
per day. Stable action coordinates reduce relearning and help a solo developer
|
||||
avoid page-by-page exceptions.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright or screenshot checks when changing shared page headers,
|
||||
command bars, task lists, detail action panels or mobile bottom actions.
|
||||
|
||||
## Convention: State-Driven Actions
|
||||
|
||||
**What**: Business actions are derived from explicit object state and current
|
||||
actor context. Do not scatter page-local button conditions across route
|
||||
components.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Before redesigning a page with mutable business records, define or reference a
|
||||
state matrix. The matrix must cover object state, actor role, primary action,
|
||||
secondary actions, forbidden actions, reason text, risk level and confirmation
|
||||
requirement.
|
||||
- Common lifecycle states include draft, submitted, in approval, returned or
|
||||
rejected, approved, pending execution or payment, completed or paid,
|
||||
cancelled, abnormal and archived. Use the business module's real names when
|
||||
they differ.
|
||||
- Draft states prioritize edit, submit and delete draft. Do not show approval or
|
||||
payment actions there.
|
||||
- In-approval states prioritize progress, withdraw and supplement-material
|
||||
actions. Approve, reject and return actions belong to the current user's
|
||||
workflow task detail, not broad ledger rows.
|
||||
- Returned or rejected states prioritize correction and resubmission.
|
||||
- Approved-but-not-paid states route payment work to finance or cashier views;
|
||||
ordinary employee views should explain the next step instead of exposing
|
||||
executable payment controls.
|
||||
- Payment actions such as mark paid, register payment, cancel payment, batch
|
||||
payment and execute payment live only in payment, finance-processing,
|
||||
payment-batch detail or an explicitly current finance task panel.
|
||||
Reimbursement, procurement, contract and project ledgers/details show payment
|
||||
status, receipt status, `查看付款`, `补回单` or a payment-record link instead
|
||||
of executable payment controls.
|
||||
- Paid, completed, archived and cancelled states are read-mostly. Print, export,
|
||||
attachment download and history belong in `更多` or audit paths when allowed.
|
||||
- Abnormal states must explain source, impact and next step. A red status label
|
||||
alone is insufficient.
|
||||
- Destructive, financial, approval and configuration-changing actions require
|
||||
confirmation that shows the current object summary and writes audit evidence
|
||||
when the backend supports it.
|
||||
- The frontend may hide disabled actions or show reason text, but the backend
|
||||
remains the source of truth for permission and state validation.
|
||||
- Use destructive lifecycle verbs consistently: `删除` only for drafts,
|
||||
non-effective temporary records or wrong materials that have not entered a
|
||||
business process; `撤回` for initiator withdrawal during allowed workflow
|
||||
states; `取消` when the business will not continue; `作废` when a numbered,
|
||||
signed, paid, published or effective object becomes invalid; `归档` when a
|
||||
completed object is locked for retention. Submitted business records should
|
||||
not be physically deleted from ordinary UI paths.
|
||||
|
||||
**Why**: State-driven actions prevent pages from showing buttons that the user
|
||||
cannot complete and keep reimbursement, procurement, contracts, assets and
|
||||
payments consistent as the system grows.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright coverage for changed state/action behavior, especially
|
||||
draft, rejected/returned, in-approval, approved, paid/completed, cancelled and
|
||||
abnormal states.
|
||||
|
||||
## Convention: Role-Scoped Data Surfaces
|
||||
|
||||
**What**: The backend is the source of truth for permissions and data scope. The
|
||||
frontend shapes the authorized capabilities into the current task role instead
|
||||
of exposing every allowed tool at once.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Ordinary employee views default to `我的`, `与我相关`, `我发起` and
|
||||
`需要我补充`. Do not show company-wide ledgers, batch tools, export, audit,
|
||||
configuration, internal IDs or other people's sensitive attachments by
|
||||
default.
|
||||
- Initiator views emphasize current status, next step, supplement-material
|
||||
needs, approval/payment progress and whether edit or withdraw is allowed.
|
||||
- Approver and processor views emphasize `待我处理` and the current node task.
|
||||
Show approve, reject, return or transfer actions only when the server-backed
|
||||
task assignment says the current user can act.
|
||||
- Approval actions such as approve, reject, return and transfer execute only in
|
||||
`待我处理`, workflow task detail, mobile approval detail or an explicitly
|
||||
current task-processing panel. Business ledger rows and ordinary business
|
||||
details use `查看处理`, `查看进度`, `补材料` or a link into the workflow task;
|
||||
they must not duplicate approval action buttons.
|
||||
- Finance and cashier views may expose authorized reimbursement, payment,
|
||||
invoice, AP, receipt and exception operations. Full-scope, export, batch,
|
||||
delegated creation and statistics tools belong in `台账工具`, `更多` or
|
||||
role-only panels.
|
||||
- Owner and project-lead views emphasize team/project scope, blockers, risks and
|
||||
approvals. They should not drift into system configuration unless the route is
|
||||
a management route.
|
||||
- Admin views live under `管理` and cover people, organization, workflow,
|
||||
feature flags, integrations, audit and troubleshooting. Do not mix these
|
||||
controls into ordinary employee paths.
|
||||
- Read-only or audit views can show authorized evidence but must not show
|
||||
mutable edit, approval, payment, publish or disable actions.
|
||||
- Do not add a global role or identity switcher. Multi-role users do not choose
|
||||
`员工` / `财务` / `管理员` before using the system. Routes infer the most
|
||||
relevant task view by default.
|
||||
- Multi-role users may switch scope inside a specific authorized ledger, but the
|
||||
default scope follows the page purpose: reimbursement starts with mine,
|
||||
workflow tasks start with my tasks, ledgers start with relevant or recent
|
||||
records, management starts with management scope. Use route-local scope
|
||||
controls such as `我相关` / `我负责` / `财务处理` / `全范围`.
|
||||
- Use explicit controls such as `我的 / 团队 / 全范围` only when the server grants
|
||||
those scopes. Hiding controls in the frontend is not a security boundary.
|
||||
- Unauthorized actions should usually be hidden. When explanation is useful,
|
||||
show short natural Chinese reasons such as `当前节点不是你处理`, `已支付单据不可编辑`
|
||||
or `仅财务可导出`.
|
||||
|
||||
**Why**: hyb-oa users often wear several hats. Role-scoped surfaces keep one
|
||||
person's broad authority from turning every page into an admin console.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Role-focused Playwright coverage when changing visibility for employee,
|
||||
approver, finance/owner or admin paths.
|
||||
|
||||
## Convention: User-Facing Identifiers And Copy Semantics
|
||||
|
||||
**What**: Ordinary product surfaces use business identifiers and natural
|
||||
Chinese. Internal identifiers are auxiliary evidence for audit and
|
||||
troubleshooting, not primary user-facing content.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Use business identifiers, names or summaries as primary labels: reimbursement
|
||||
number, purchase request number, contract number, asset number, payment batch
|
||||
number and project name.
|
||||
- Do not show UUID, taskId, entityId, permission code, role code, internal state
|
||||
code, raw payload, full local path, API path, database field name, OCR
|
||||
provider, debug trace, Secret or token on ordinary employee, approver,
|
||||
finance or mobile paths.
|
||||
- Audit logs, admin troubleshooting, integration failure details, printed
|
||||
evidence and export handoff files may show necessary internal IDs when
|
||||
authorized. Place them in low-priority areas such as `技术信息`, `审计信息` or
|
||||
`排障信息`; never use them as the page title, card title, button label or
|
||||
first ordinary list column.
|
||||
- Show one primary identifier for the same object in one surface. Avoid placing
|
||||
business number, UUID, taskId and entityId together unless the route is an
|
||||
audit/troubleshooting route.
|
||||
- Translate technical enum values and platform words into natural Chinese:
|
||||
`PENDING_APPROVAL` becomes `审批中`; `REJECTED` becomes `已驳回` or
|
||||
`被退回待补正`; `AP Operations` becomes `应付账款`; `Feature Flag` becomes
|
||||
management wording.
|
||||
- Time copy should answer the business question. Prefer `已等待多久`, `接收于`,
|
||||
`提交于`, `支付于` and `归档于` over generic `更新时间` when the user needs to
|
||||
decide what to do.
|
||||
- Errors and abnormal states must explain source, impact and next step in
|
||||
natural Chinese. Do not surface only HTTP codes, backend enum names or red
|
||||
badges.
|
||||
- Notifications and mobile cards use the shortest useful business identifier or
|
||||
summary. Do not pack long technical IDs into small surfaces.
|
||||
|
||||
**Why**: Internal implementation language makes the product feel complex and
|
||||
unfamiliar. Business identifiers and natural Chinese keep small-team workflows
|
||||
legible.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- UI tests or screenshot review for changed list/detail/notification/mobile
|
||||
surfaces to confirm internal IDs and technical enum names are not visible.
|
||||
|
||||
## Convention: Ledger List Defaults
|
||||
|
||||
**What**: Business list and ledger pages default to a light, task-oriented list.
|
||||
Advanced ledger capabilities remain available but must not dominate the first
|
||||
screen.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Keep 3 to 5 high-frequency filters visible by default. Prioritize search,
|
||||
status, scope and date/time; add business-specific filters such as project,
|
||||
person or type only when they are genuinely frequent.
|
||||
- The default view must match the route's main job: `我的报销`, `待我处理`,
|
||||
`合同台账`, `资产台账` and similar task nouns. Do not default ordinary users
|
||||
into company-wide management views.
|
||||
- Rows and cards must answer what the object is, current state, why it relates
|
||||
to the current user and the next action.
|
||||
- Place common filters on the left side of the command bar below the page
|
||||
header. Put export, batch, statistics, templates, full-scope, advanced
|
||||
filters, delegated creation and low-frequency module links in `台账工具`,
|
||||
`更多` or role-only panels.
|
||||
- Batch actions appear only after selection, as a contextual command bar or
|
||||
bottom sticky bar. High-risk batch actions such as approve, pay, delete or
|
||||
publish require summary confirmation and result details.
|
||||
- Export is not a primary page action. Explain export scope and sensitive
|
||||
content when relevant; finance, contract, asset and invoice exports must stay
|
||||
permissioned and auditable.
|
||||
- PC ledgers may use pagination, sorting and density controls. Default columns
|
||||
should be decision-supporting fields only; low-frequency fields belong in
|
||||
details, column configuration or advanced filters.
|
||||
- Empty states are status-specific. `没有草稿`, `没有被驳回`, `没有待处理` and
|
||||
`没有异常` should not all share one generic explanatory panel.
|
||||
- Mobile routes do not copy PC ledger tools. Use search, status filtering, card
|
||||
lists and one primary action; leave complex analysis, export and broad-scope
|
||||
management to PC.
|
||||
- Contract, procurement, project and finance ledgers use a list-to-detail
|
||||
boundary. The list is for discovery, filtering, status reading and navigation.
|
||||
High-risk or sensitive actions such as contract download, archive, payment,
|
||||
export, batch processing, void/cancel and sensitive attachment viewing belong
|
||||
in detail workspaces, detail command panels or `台账工具`, with permission,
|
||||
audit and confirmation.
|
||||
- Default ledger scope follows the current task role: ordinary employees see
|
||||
`我发起` / `我相关`, owners and project leads see `我负责` / `项目相关`, finance
|
||||
sees `待复核` / `待付款` / `异常`, and admins may enter or switch to `全范围`.
|
||||
Full scope, export and batch commands stay in `台账工具` or role-only panels,
|
||||
not ordinary first screens.
|
||||
- Contract ledgers in V1 are registration, archive, due/renewal reminder and
|
||||
relation surfaces for project, procurement and payment context. Do not design
|
||||
`/contracts-registry` as e-signature, legal-review, clause-library,
|
||||
version-collaboration or full CLM software. If contract approval is needed,
|
||||
link to the OA approval center or a separate future task instead of adding an
|
||||
approval workspace inside the contract ledger.
|
||||
- Procurement ledgers in V1 are request, approval, attachment, light
|
||||
acceptance/archive and relation surfaces for project, contract and payment/AP
|
||||
context. Do not design `/purchase-requests` as purchase-order lifecycle,
|
||||
inventory, three-way matching, supplier-lifecycle, tendering or ERP software.
|
||||
Approved procurement means the request was approved; it does not imply paid,
|
||||
received into inventory or converted into a fixed asset.
|
||||
- Project pages in V1 are light project ledgers for status, owner/member,
|
||||
milestone/task, risk, delivery-record and related reimbursement, procurement,
|
||||
contract and payment context. Do not design `/projects` as full project
|
||||
management software with Gantt charts, complex dependencies, timesheets,
|
||||
resource scheduling, OKR, portfolio management or large collaboration suites.
|
||||
Project pages summarize and route; source records stay in their business
|
||||
modules.
|
||||
- Finance ledgers in V1 are payment-preparation, payment-batch, receipt-audit,
|
||||
AP-status, invoice/OCR-status and agency-accounting handover summaries. Do
|
||||
not design payment, AP or invoice pages as online banking, bank-statement
|
||||
ingestion, ERP/general-ledger, voucher-generation, auto-reconciliation, tax
|
||||
filing or full accounting software. Real payment stays in offline banking or
|
||||
existing finance/accounting workflows; OA records status, evidence and
|
||||
handover summaries.
|
||||
- Payment actions require the finance/payment context: amount, payee or target
|
||||
object, source records, offline payment explanation, evidence completeness,
|
||||
receipt requirement and correction boundary. Do not place `标记已付款`,
|
||||
`取消付款`, `批量付款` or `执行付款` directly in reimbursement, procurement,
|
||||
contract or project ledgers/details.
|
||||
- Cross-module relation sections are summary-and-route surfaces. Project,
|
||||
procurement, contract, reimbursement, asset and payment pages may show related
|
||||
business number/name, status, amount or quantity, owner, evidence completeness
|
||||
and next-step summary, then link to the owning detail/task/finance page. Do not
|
||||
duplicate the owning module's approval actions, payment actions, invoice/OCR
|
||||
processing, contract-body download, sensitive attachment actions, state machine
|
||||
or batch tools inside another module's relation card.
|
||||
|
||||
**Why**: The product's main complexity complaint is too many visible operations.
|
||||
Light default ledgers keep daily work simple while preserving advanced finance
|
||||
and management workflows.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright or screenshot checks when changing list filters, command
|
||||
bars, `台账工具`, batch selection behavior, empty states or mobile list cards.
|
||||
|
||||
## Convention: Asset Registry Pages
|
||||
|
||||
**What**: Asset pages render `FA` fixed assets as a lightweight responsibility
|
||||
ledger inside the unified asset registry, not as a full accounting fixed-asset
|
||||
subsystem.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- The default `/assets` view answers where the asset is, who uses it, who is
|
||||
responsible for it, what state it is in and whether it needs inventory or
|
||||
handover. Do not lead with depreciation, accounting subjects or ERP sync.
|
||||
- Register physical items that must be returned, transferred, inventoried or
|
||||
protected, such as computers, monitors, disks, equipment and security media.
|
||||
Do not create `FA` cards for ordinary consumables.
|
||||
- Every `FA` card needs an asset number. Physical assets that can carry labels
|
||||
should expose QR-label status for scan, inventory, assignment and return
|
||||
workflows. Assets that cannot be labeled must still expose serial number,
|
||||
custodian and location as the lookup fallback.
|
||||
- Inventory cadence is lightweight: quarterly routine checks by default, event
|
||||
checks for departure, transfer, repair and retirement, and monthly custodian
|
||||
plus location confirmation for high-risk physical assets such as backup disks,
|
||||
security media and critical equipment.
|
||||
- Assignment, return and transfer are daily flow actions that admins may record
|
||||
with audit evidence. Disposal actions such as retirement, loss, sale and gift
|
||||
require owner confirmation, a reason and consequence summary. If compensation,
|
||||
money or responsibility is disputed, the asset UI records pending/confirmed
|
||||
outcomes only and must not complete the dispute in one click.
|
||||
- Keep acquisition source, business number, owner/custodian, location, status,
|
||||
assignment, return, transfer, repair, retirement, inventory result and
|
||||
handover evidence visible in the business flow.
|
||||
- Procurement or reimbursement records may expose an asset-candidate signal, but
|
||||
they must not create an `FA` asset card automatically after approval,
|
||||
submission or payment. The asset registry UI may guide admins from candidates
|
||||
to `新建资产卡片`, but the card is created only after manual verification of
|
||||
delivery, quantity, owner/custodian, consumable status, returns and gifts.
|
||||
- Move depreciation, residual value, accounting subject and monthly
|
||||
depreciation voucher concepts out of the OA primary UI unless a later Trellis
|
||||
task explicitly scopes accounting-ledger work.
|
||||
- Keep classification maintenance, ERP sync, raw metadata and advanced filters
|
||||
behind management, collapsed or advanced surfaces so they do not dominate the
|
||||
asset list/detail first screen.
|
||||
- Mobile asset lookup should prefer QR scan and fall back to asset number or
|
||||
serial number input. Do not require heavy photo inventory unless a later task
|
||||
explicitly scopes it.
|
||||
- Asset list/detail UI may show last inventory, next inventory and overdue
|
||||
hints. Do not turn cadence into a complex scheduling/configuration console in
|
||||
the default asset registry view.
|
||||
- Disposal commands must be visually separated from assignment/return/transfer
|
||||
commands and use confirmation that shows asset number, name, owner, current
|
||||
custodian, location, reason and effect on asset status.
|
||||
- Electronic assets (`EA-DOC`, `EA-SYS`, `EA-REPO`, `EA-BKP`) are metadata and
|
||||
responsibility indexes. Show owner, custodian/admin, permission-recovery
|
||||
requirement, backup or restore-verification date, sensitivity level and
|
||||
archive-location summary. Do not display or store source packages, secrets,
|
||||
tokens, full configs, real full paths or backup contents.
|
||||
- `EA-DOC` list/detail views show document name, type, hash or verification
|
||||
summary, sensitivity level, owner, related project/contract/payment and
|
||||
archive-location summary. Contract text, bank statements, certificate
|
||||
originals, customer materials, sensitive quotes, payroll/social-security data
|
||||
and personal identity materials must not appear as ordinary asset-page
|
||||
content; route business originals through their module attachment permissions
|
||||
or offline controlled archive.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- Asset page screenshots or E2E assertions should verify the first screen is
|
||||
asset-list/detail/task oriented, with classification and integration tooling
|
||||
demoted.
|
||||
- Mobile asset scan tests should cover lookup, summary and one allowed action;
|
||||
mobile must not expose classification maintenance or full metadata editing.
|
||||
Include QR scan or manual asset-number/serial-number fallback when this
|
||||
surface changes.
|
||||
- Electronic asset UI changes should assert that sensitive source/config/backup
|
||||
content and full paths are not visible in ordinary list/detail/mobile views.
|
||||
- `EA-DOC` UI changes should assert that high-sensitive originals are not
|
||||
rendered in ordinary asset list/detail/mobile views.
|
||||
|
||||
## Convention: Forms, Drafts And Validation
|
||||
|
||||
**What**: Long business forms support interruption and recovery. Save draft and
|
||||
submit are distinct actions with different consequences.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Long forms should support drafts by default when the business object requires
|
||||
multiple fields, line items or materials, including reimbursements,
|
||||
procurement, contract drafting, asset intake and payment supplement flows.
|
||||
- `保存草稿` stores progress only. It must not trigger approval, payment,
|
||||
publishing or external synchronization. `提交` enters the business workflow.
|
||||
- Draft save may allow incomplete data, but it must preserve entered fields,
|
||||
line items, attachment references and the recoverable object state.
|
||||
- Before submit, run business validation and show a summary confirmation with
|
||||
the object summary, amount or quantity, important contract/asset/payment
|
||||
facts, attachment or invoice completeness, and next node or consequence.
|
||||
- Material upload is type-first. Let the user choose or enter the material type
|
||||
before upload, then apply type-specific copy, validation, permissions, audit
|
||||
and display placement. Do not use one generic attachment uploader for PDF
|
||||
invoices, ordinary attachments, contract files, payment receipts, acceptance
|
||||
materials, asset materials and electronic-document indexes.
|
||||
- Upload labels must describe the result, such as `上传 PDF 发票`,
|
||||
`补充付款回单`, `上传合同文件`, `补充验收材料` or `登记资产材料`.
|
||||
- Validation errors must point to the field, line item, invoice, attachment,
|
||||
contract material or asset section that needs work. A top-level `提交失败`
|
||||
message alone is insufficient.
|
||||
- Separate blocking errors from warnings. Blocking errors prevent submit;
|
||||
warnings may allow users to confirm and continue when the business rule
|
||||
permits it.
|
||||
- Server-side validation failures must preserve user input and show repair
|
||||
guidance in natural Chinese.
|
||||
- Warn before navigation when the form has unsaved changes, including leaving
|
||||
the route, closing a modal, switching record or returning to the list.
|
||||
- Autosave can be used as an enhancement, but the visible state must still make
|
||||
clear whether the object is draft, submitted or failed to save.
|
||||
- Mobile forms keep only necessary fields, material upload, status explanation
|
||||
and a bottom safe-area primary action. Do not move admin configuration,
|
||||
complex configuration matrices, bulk import or workflow design into mobile
|
||||
forms.
|
||||
- Mobile validation messages should appear near the field or material card, and
|
||||
bottom actions must not cover the final input.
|
||||
|
||||
**Why**: Small-team users often switch tasks mid-form. Drafts and precise
|
||||
validation prevent repeated re-entry and reduce support/debugging cost.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright coverage for draft save, submit validation, unsaved-change
|
||||
protection and server-validation failure paths when changing form behavior.
|
||||
|
||||
## Convention: Detail Evidence Layout
|
||||
|
||||
**What**: Detail pages use one evidence-first structure so users can understand
|
||||
state, facts and consequences before acting.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Use this order for reimbursement, workflow task, procurement, contract, asset,
|
||||
project and payment details: status/next step, business summary, evidence
|
||||
materials, risk or validation signals, approval/processing history, actions.
|
||||
- The top overview shows business number or name, current state, critical amount
|
||||
or object facts, current handler or next node, and a clear return path.
|
||||
- The first content block is `当前状态与下一步`: explain where the object is,
|
||||
who needs to act, what happens next and whether there are blockers or
|
||||
warnings.
|
||||
- The business summary block shows the fields needed before approval or review:
|
||||
requester, amount, project, purchase object, contract counterparty, asset
|
||||
owner, payment batch and similar module facts.
|
||||
- Evidence materials sit in the main content, grouped by business meaning:
|
||||
line items, PDF invoices, attachments, contract files, asset photos/numbers,
|
||||
receipts and acceptance materials.
|
||||
- Risk or validation sections appear only when there is a real signal such as
|
||||
budget issue, duplicate invoice, missing attachment, contract expiry, asset
|
||||
anomaly or payment failure.
|
||||
- Approval and processing history is for traceability. Keep a useful summary
|
||||
visible, but do not let full history crowd out current status and evidence.
|
||||
- PC high-risk actions live in the right command panel or separated action
|
||||
stack. Mobile high-risk actions live in the bottom action surface or a
|
||||
confirmation panel.
|
||||
- Approve, reject, return, pay, publish, delete and void actions must show the
|
||||
object summary and consequence before execution.
|
||||
- When evidence is incomplete, change the primary action to supplement material,
|
||||
view issues or an explained disabled state. Do not leave users guessing from a
|
||||
disabled button alone.
|
||||
- List and ledger rows show only evidence completeness summaries, missing
|
||||
evidence hints and a detail entry. Invoice preview, attachment download,
|
||||
contract file viewing, receipt download, evidence deletion and bulk packaging
|
||||
belong in detail workspaces, detail command panels, `台账工具` or authorized
|
||||
audit paths.
|
||||
- Sensitive evidence such as invoices, contracts, receipts and attachments must
|
||||
be permissioned; download and export belong in `更多` or audit paths when
|
||||
appropriate.
|
||||
- Detail evidence sections group materials by type. Do not mix invoices,
|
||||
ordinary attachments, contract files, receipts, asset materials and
|
||||
electronic-document indexes in one undifferentiated list.
|
||||
- Mobile details use a top focus card, sectioned cards and bottom safe-area
|
||||
actions. Do not copy PC two-column detail or wide tables into mobile.
|
||||
|
||||
**Why**: Detail pages are the place where users decide whether to approve,
|
||||
reject, pay or supplement materials. Consistent evidence order reduces
|
||||
misreads and accidental actions.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright or screenshot checks when changing detail overview,
|
||||
evidence sections, history placement, right command panels or mobile detail
|
||||
bottom actions.
|
||||
|
||||
## Convention: Mobile Lightweight Surfaces
|
||||
|
||||
**What**: Mobile and Enterprise WeChat WebView routes are lightweight action
|
||||
surfaces. They are not compressed PC management consoles.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Mobile may support lightweight submit, supplement-material, status lookup,
|
||||
task handling, scanning, upload and message-deeplink flows.
|
||||
- Keep mobile pages to top status or focus card, card list or sectioned detail,
|
||||
and bottom safe-area primary action.
|
||||
- Mobile home should show compact status and today's actionable items. Do not
|
||||
add a full module directory or dashboard.
|
||||
- Mobile lists use search/status filtering, cards and one primary action. Do not
|
||||
use wide tables, column configuration, complex multi-column filters,
|
||||
full-scope management, admin configuration, batch export, bulk approval or
|
||||
bulk payment.
|
||||
- Mobile details use a focus card, sectioned evidence and bottom actions. Do not
|
||||
copy PC two-column layouts.
|
||||
- Mobile forms keep necessary fields, material upload, field-local validation
|
||||
and a bottom action. Do not put admin configuration, workflow configuration,
|
||||
feature flags, statistics dashboards or bulk import into mobile forms.
|
||||
- Bottom actions must account for safe area and keyboard overlap. Button text
|
||||
must remain readable on narrow screens.
|
||||
- Dangerous mobile actions must open a confirmation panel that shows object
|
||||
summary and consequence.
|
||||
- Ordinary mobile paths must not show internal IDs, permission codes,
|
||||
configuration matrices or audit troubleshooting panels.
|
||||
- Enterprise WeChat remains the primary owner for daily HR/attendance actions
|
||||
such as leave, missed punch, outing, overtime and check-in. OA mobile shows
|
||||
mirror/history/exception/emergency takeover according to the business
|
||||
boundary.
|
||||
|
||||
**Why**: Most mobile use happens from notifications or quick context switches.
|
||||
Reducing mobile scope keeps the phone path fast and prevents PC admin
|
||||
complexity from leaking into WeChat.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Playwright or screenshot coverage for representative narrow viewports when
|
||||
changing mobile home, mobile lists, mobile details, bottom actions, upload
|
||||
surfaces or Enterprise WeChat WebView flows.
|
||||
- If true Enterprise WeChat device validation is unavailable, record it as
|
||||
paused manual validation; do not claim full WebView acceptance.
|
||||
|
||||
## Convention: Notifications Versus Tasks
|
||||
|
||||
**What**: Task queues and notifications have separate jobs. A task queue is for
|
||||
action; a notification center is for event awareness and navigation.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- `待我处理` is an action list. Include only items that require the current user
|
||||
to process, supplement material, review, pay, approve, confirm or resolve an
|
||||
exception.
|
||||
- Task rows must have a clear next step, object summary, business state and
|
||||
processing entry.
|
||||
- Completed items, read-only progress, announcements, successful sync notices
|
||||
and ordinary system messages do not belong in the pending task list.
|
||||
- `通知中心` is an event inbox for status changes, reminders, failures, sync
|
||||
results, workflow transitions, invoice/attachment recognition results and
|
||||
Enterprise WeChat delivery results.
|
||||
- Notifications should support read/unread, view, jump target and failure
|
||||
explanation. Do not rebuild the full workflow task list inside the
|
||||
notification center.
|
||||
- Notification clicks must deep-link to the business detail, workflow task,
|
||||
mobile target page or failure explanation. Do not send users back to a
|
||||
generic notification list as the final destination.
|
||||
- Notification copy should explain what happened, who or what is affected, and
|
||||
the next useful step. Do not expose raw payloads, internal state codes or
|
||||
debug fields.
|
||||
- Workbench `今日待处理` aggregates only actionable items. Ordinary
|
||||
notifications, read-only progress, completed activity and announcements are
|
||||
not counted as pending work.
|
||||
- If a notification represents real work, the backend or aggregation layer
|
||||
should expose it as an explicit task item; the frontend should not infer every
|
||||
notification is a task.
|
||||
- The topbar bell is the notification entry. Do not add notification center as a
|
||||
default sidebar row.
|
||||
- Enterprise WeChat messages are an external delivery channel. Keep message
|
||||
content desensitized and deep-link into the OA business or task detail.
|
||||
|
||||
**Why**: Separating event awareness from action prevents Portal, task queue and
|
||||
notification center from showing the same thing in three different ways.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright coverage when changing task aggregation, notification
|
||||
center rows, topbar bell behavior, notification deep links or workbench
|
||||
`今日待处理` counts.
|
||||
|
||||
## Convention: Sensitive Data And Exports
|
||||
|
||||
**What**: Contracts, finance, invoices, receipts, payments, assets and
|
||||
attachments are sensitive by default. Frontend surfaces show the minimum useful
|
||||
summary unless a permissioned workflow requires more.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Treat contract text and attachments, quotations, acceptance materials,
|
||||
invoices, receipts, payment information, bank accounts, supplier details,
|
||||
asset serial/location/owner data, personnel records, payroll/performance,
|
||||
audit records, original file names and export files as sensitive.
|
||||
- Workbench, notifications, ordinary lists, mobile cards and Enterprise WeChat
|
||||
messages show desensitized summaries only.
|
||||
- Ordinary surfaces must not show full bank/account numbers, full local paths,
|
||||
storage paths, raw payloads, full sensitive attachment names, Secrets, tokens
|
||||
or high-sensitive contract/finance details.
|
||||
- Previewing contract text, invoices, receipts and attachments requires
|
||||
server-side permission checks. Frontend visibility is not a security boundary.
|
||||
- High-sensitive previews should explain context or purpose when useful and
|
||||
record view evidence when the backend supports it.
|
||||
- Download, batch download, export, print, attachment packaging, contract text
|
||||
export and finance ledger export must be controlled by server permissions and
|
||||
data scope.
|
||||
- Export is never the primary first-screen action. Put exports in `台账工具`,
|
||||
`更多` or role-only finance/admin panels.
|
||||
- Before exporting sensitive ledgers, explain scope and sensitive contents.
|
||||
Finance, contract, asset and invoice exports should write audit records.
|
||||
- Export file names use business numbers and dates. Do not concatenate complete
|
||||
personal accounts, complete supplier secrets or internal filesystem paths.
|
||||
- Audit sensitive operations with actor, time, object, action, scope and result
|
||||
where supported.
|
||||
- Permission-denied and failure messages use natural Chinese without leaking
|
||||
full paths, permission codes, raw URLs, payloads, Secrets or tokens.
|
||||
|
||||
**Why**: The product is for small teams, but the data is still financial,
|
||||
contractual and operationally sensitive. Small team convenience must not turn
|
||||
into broad accidental disclosure.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright or screenshot checks when changing attachment preview,
|
||||
contract/invoice/receipt surfaces, export controls, mobile summaries,
|
||||
notification copy or permission-denied states.
|
||||
|
||||
## Convention: Permission Empty And Error States
|
||||
|
||||
**What**: Permission-denied, empty and error states use natural Chinese that
|
||||
explains cause and next step. Ordinary users should not inspect platform
|
||||
internals to understand what happened.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Hide unauthorized actions by default. If a route is opened directly or the
|
||||
user needs context, show a natural Chinese explanation and a real next step
|
||||
such as returning to workbench, viewing related records or contacting an
|
||||
admin.
|
||||
- Empty states are scoped to the current filter, status or section. Explain what
|
||||
is absent and show one useful next step; if there is no real next step, hide
|
||||
the section instead of adding instructional copy.
|
||||
- Error states explain business cause, impact and recovery path such as retry,
|
||||
supplement material, return to list or contact admin.
|
||||
- Ordinary user paths must not show raw `403`, API route names, permission
|
||||
codes, internal state codes, route stacks, full paths, raw payloads or long
|
||||
technical error dumps.
|
||||
- Admin, audit and troubleshooting routes may show the minimum technical
|
||||
details needed to diagnose a problem, but the business reason and next step
|
||||
remain primary.
|
||||
- Mobile and notification targets use shorter copy, but must still include
|
||||
cause and next step.
|
||||
|
||||
**Why**: Small-team users do not have time to decode implementation details.
|
||||
Clear failure states reduce support work and avoid leaking internal platform
|
||||
structure.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright or screenshot checks when changing empty states,
|
||||
permission-denied pages, notification failure targets or shared error
|
||||
components.
|
||||
|
||||
## Convention: Dangerous Action Confirmation
|
||||
|
||||
**What**: Destructive, financial, approval, configuration, batch and external
|
||||
sync actions require meaningful confirmation. A generic `确定吗？` dialog is not
|
||||
enough.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Treat delete, void, revoke, archive, restore, disable, publish, configuration
|
||||
switching, workflow switching and feature-flag changes as dangerous actions.
|
||||
- Treat pay, batch pay, sensitive export, batch download, contract text
|
||||
download and attachment packaging as dangerous or high-sensitive actions.
|
||||
- Treat approve, reject, return, transfer, batch approve and batch reject as
|
||||
approval-risk actions that need context before execution.
|
||||
- Treat external synchronization, retry external write and Enterprise
|
||||
WeChat/OA emergency-takeover switching as integration-risk actions.
|
||||
- Confirmation UI must show object summary: business number, name, requester or
|
||||
counterparty, amount or quantity and current state when relevant.
|
||||
- Confirmation UI must explain consequences: target state, reversibility,
|
||||
notifications, payment/approval/configuration impact and external-system
|
||||
effect.
|
||||
- Confirmation UI must show impact scope for batch, export, configuration and
|
||||
integration actions: selected count, data range, external system, Enterprise
|
||||
WeChat message or audit scope.
|
||||
- Rejection and return require a reason. Payment, publishing, batch and
|
||||
configuration actions may require a confirmation word, explicit checkbox or
|
||||
selected reason when risk is high.
|
||||
- Dangerous actions must be visually separated from normal view, edit, save and
|
||||
submit actions.
|
||||
- Mobile dangerous actions use bottom or full-screen confirmation panels, not
|
||||
instant execution from an easy-to-mistap control.
|
||||
- Confirmation failure must preserve user input and show result details plus the
|
||||
next repair action.
|
||||
- Audited actions should record actor, time, object, action, scope, reason and
|
||||
result where backend support exists.
|
||||
- Delete, withdraw, cancel, void and archive confirmations must use the exact
|
||||
business verb and explain the target state. Do not label cancel, void or
|
||||
archive as `删除`.
|
||||
|
||||
**Why**: These actions can change finance, contracts, workflow, approvals,
|
||||
configuration and external integrations. Users need context before execution,
|
||||
and support needs an audit trail after execution.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright coverage when changing delete, payment, approval,
|
||||
publish/disable, batch, configuration or external-sync confirmations.
|
||||
|
||||
## Convention: Integration Boundary And External Status
|
||||
|
||||
**What**: External-system state is conservative. OA shows facts confirmed by its
|
||||
own backend and explicit external acknowledgements; it does not present a queued
|
||||
request, frontend click or message attempt as final business completion.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- OA owns reimbursement, procurement, contracts, projects, payments, AP,
|
||||
invoices, assets, sensitive attachments, audit and OA workflow handling.
|
||||
- Enterprise WeChat owns daily HR/attendance actions: check-in, leave, missed
|
||||
punch, outing and overtime. OA shows mirror, history, exception, audit and
|
||||
emergency-takeover records for those domains.
|
||||
- ERP, agency accounting, bank, OCR and Enterprise WeChat messages are external
|
||||
capabilities or delivery channels. They do not replace OA server-side
|
||||
permissions or state machines.
|
||||
- Show final labels such as `已同步`, `已发送`, `已付款` and `识别完成` only when the
|
||||
relevant external system has returned a clear success acknowledgement.
|
||||
- Use in-progress labels such as `同步中`, `等待回执`, `银行处理中`, `识别中` and
|
||||
`消息发送中` when the request has started but is not confirmed.
|
||||
- External failures must show source, impact and next step in natural Chinese,
|
||||
such as `银行回执未返回` or `OCR 识别失败，需重新上传 PDF`.
|
||||
- Do not expose raw external error codes, payloads, full URLs, secrets, tokens
|
||||
or debug traces to ordinary users.
|
||||
- External writes, payment execution, ERP sync, Enterprise WeChat resend and OCR
|
||||
retry must be controlled by permissions and state-driven actions.
|
||||
- Retry confirmation should explain which object will be retried, whether it may
|
||||
send duplicate external messages, external-system impact and audit effect.
|
||||
- External sync state should not block unrelated primary flows. If it blocks a
|
||||
flow, show the blocker and manual repair path.
|
||||
- Ordinary routes show summary, failure reason and next step. Admin, finance or
|
||||
troubleshooting routes may show deeper diagnostics when authorized.
|
||||
- HR/attendance routes should default to Enterprise WeChat record, sync mirror
|
||||
or exception handling copy. Do not expose OA daily leave/missed-punch paths
|
||||
unless OA emergency takeover is explicitly enabled.
|
||||
- Enterprise WeChat messages carry desensitized summary and OA deeplink only;
|
||||
they do not carry sensitive attachment text or final payment/approval actions.
|
||||
- If bank, ERP, agency accounting or another integration is not connected or not
|
||||
confirmed, UI copy must not imply the capability already completed.
|
||||
|
||||
**Why**: External integrations are asynchronous and failure-prone. Conservative
|
||||
copy prevents users from trusting a state the system has not actually verified.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- `cd client && npm run typecheck`
|
||||
- `cd client && npm run build`
|
||||
- Focused Playwright coverage when changing Enterprise WeChat boundary copy,
|
||||
OCR status, bank/payment callbacks, ERP/accounting sync status, retry
|
||||
controls, external failure messages or integration diagnostics.
|
||||
|
||||
## Convention: Verification And User-Testable Claims
|
||||
|
||||
**What**: Verification claims must describe the actual validation level. Local
|
||||
checks, screenshots and mock Playwright runs do not mean a user can test the
|
||||
change online.
|
||||
|
||||
**Contracts**:
|
||||
|
||||
- Local build passing means only the local code built successfully.
|
||||
- Playwright passing means the specified automated path passed in the specified
|
||||
environment and data state.
|
||||
- Screenshot review passing means only the captured viewport and state were
|
||||
reviewed.
|
||||
- Deployment passing must identify the deployed environment, version or commit
|
||||
and health check result when available.
|
||||
- Say `可以线上测试` only after deployment, public access check, key-path smoke
|
||||
testing and necessary screenshot evidence are complete.
|
||||
- Before deployment, say `本地验证通过，尚未线上可测`.
|
||||
- After deployment but before public access check, say `已部署，公网检查未完成`.
|
||||
- If real-device or Enterprise WeChat WebView validation is unavailable, record
|
||||
it as paused manual validation. Do not substitute automation for full WebView
|
||||
acceptance.
|
||||
- A-class page changes should keep build, focused Playwright or screenshot
|
||||
evidence according to risk.
|
||||
- Changes touching permissions, state machines, approval, payment, Enterprise
|
||||
WeChat, external systems, sensitive downloads or production configuration
|
||||
need rollback or manual repair notes.
|
||||
- Updating this design/spec documentation does not mean pages were refactored,
|
||||
deployed or accepted for live trial.
|
||||
|
||||
**Why**: This keeps delivery status honest and prevents the user from trying a
|
||||
change that has not actually reached a public environment.
|
||||
|
||||
**Tests Required**:
|
||||
|
||||
- Documentation-only changes: Trellis task validation, governance check and
|
||||
`git diff --check`.
|
||||
- Frontend implementation changes: `cd client && npm run typecheck`,
|
||||
`cd client && npm run build`, plus focused Playwright or screenshots based on
|
||||
affected surface.
|
||||
|
||||
## Convention: A-Class PC Task-First Pages
|
||||
|
||||
**What**: A-class PC pages such as Portal, approvals, reimbursement list and
|
||||
@@ -296,6 +1162,10 @@ a later Trellis task adds an explicit backend eligibility contract.
|
||||
but normal approval remains in Enterprise WeChat.
|
||||
- Reimbursement, procurement, travel, contract and other amount/evidence-heavy
|
||||
OA-owned tasks should route through `查看处理` first.
|
||||
- Business ledgers and ordinary business details must follow the same rule:
|
||||
show the task entry or progress, but do not place `通过`, `驳回`, `退回` or
|
||||
`转审` directly in reimbursement, procurement, contract, project or asset
|
||||
tables/details.
|
||||
- Future list-level quick approval requires the backend to expose an explicit
|
||||
eligibility flag such as `quickApproveEligible=true`, plus task-domain and
|
||||
audit semantics in the current Trellis task. Frontend heuristics based only on
|
||||
@@ -319,10 +1189,15 @@ training or permission-maintenance surfaces:
|
||||
`处理待办`, `提交报销` or `请假`; do not use explanatory entries like
|
||||
`了解流程`, and do not route users to settings or notifications as a
|
||||
substitute for task guidance.
|
||||
- `个人设置` default content is account identity, notification preference and
|
||||
Enterprise WeChat binding. Organization, report line and role summary may be
|
||||
folded under `账号详情`; permission code lists and full employee dossier fields
|
||||
stay out of the default view.
|
||||
- `个人设置` default content is personal profile, password/security,
|
||||
notification preference and Enterprise WeChat binding. Organization, report
|
||||
line and role summary may be folded under `账号详情`; permission code lists
|
||||
and full employee dossier fields stay out of the default view.
|
||||
- Keep account settings separate from admin configuration. `个人设置` may show
|
||||
personal profile, password/security, notification preferences and Enterprise
|
||||
WeChat binding only. Organization maintenance, role assignment, approval
|
||||
rules, feature flags, master data, audit logs, employee maintenance and
|
||||
system configuration belong under `管理`, not the ordinary profile route.
|
||||
|
||||
**Why**: Small teams need fewer default decisions. Persistent onboarding and
|
||||
permission-heavy profile pages make ordinary users inspect system internals
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
{"file": ".trellis/spec/hyb-oa/project-governance.md", "reason": "检查任务合同、计划、审批和治理门禁是否满足项目规则。"}
|
||||
{"file": ".trellis/spec/hyb-oa/frontend-react-vite-design.md", "reason": "检查页面规则是否符合前端任务优先和共享布局约定。"}
|
||||
{"file": ".trellis/spec/hyb-oa/docs-and-evidence.md", "reason": "检查是否误建长期文档、是否符合事实源回写和脱敏规则。"}
|
||||
{"file": ".trellis/spec/hyb-oa/wecom-boundary.md", "reason": "检查 HR/考勤企微主办和 OA 镜像/历史边界是否清楚。"}
|
||||
{"file": ".trellis/spec/hyb-oa/approval-workflow.md", "reason": "检查审批动作、状态和自审边界是否被正确表达。"}
|
||||
{"file": ".trellis/spec/hyb-oa/reimbursement-invoice-ocr.md", "reason": "检查报销、PDF 发票 OCR 和附件规则是否一致。"}
|
||||
文件差异内容过多而无法显示
加载差异
@@ -0,0 +1,6 @@
|
||||
{"file": ".trellis/spec/hyb-oa/project-governance.md", "reason": "Trellis task、审批、提交和单人开发低风险原则。"}
|
||||
{"file": ".trellis/spec/hyb-oa/frontend-react-vite-design.md", "reason": "前端页面设计、任务优先布局、共享组件和验证规则。"}
|
||||
{"file": ".trellis/spec/hyb-oa/docs-and-evidence.md", "reason": "文档治理、事实源回写和证据脱敏规则。"}
|
||||
{"file": ".trellis/spec/hyb-oa/wecom-boundary.md", "reason": "企业微信主办 HR/考勤与 OA 主办业务边界。"}
|
||||
{"file": ".trellis/spec/hyb-oa/approval-workflow.md", "reason": "审批、工作流、自审和状态边界。"}
|
||||
{"file": ".trellis/spec/hyb-oa/reimbursement-invoice-ocr.md", "reason": "报销、PDF 发票 OCR 和附件边界。"}
|
||||
@@ -0,0 +1,114 @@
|
||||
# 全页面设计规则梳理
|
||||
|
||||
## Goal
|
||||
|
||||
梳理 hyb-oa 当前 PC、移动和企业微信入口下所有页面的职责、默认布局、操作层级和后续优化建议，形成一份可用于后续前端开发、改进和重构的页面规则地图。目标不是本轮直接重构页面，而是先把“每类页面应该长什么样、先展示什么、哪些能力应隐藏到高级入口、哪些页面不应该继续做”的判断固定下来，降低单人开发时的返工和误改概率。
|
||||
|
||||
## What I Already Know
|
||||
|
||||
- 产品面向国内、小于 10 人的科技初创公司，用户一人多岗，默认需要低决策成本、少入口、任务优先。
|
||||
- 开发和维护主要由一个人完成，后续页面规则必须减少分叉、减少页面局部特例，优先复用已有共享布局和验证路径。
|
||||
- 前端视觉、布局和交互裁决以 `frontend-design` skill 为准；`docs/产品设计规则.md` 只保留产品体验事实、业务边界和验收边界。
|
||||
- OA 主办报销、采购、费用、合同、项目、付款、AP、票据、资产、审计和高敏附件。
|
||||
- 企业微信主办 HR/考勤日常动作，包括打卡、请假、补卡、外出、加班；OA 只做镜像、历史、审计、异常和应急接管。
|
||||
- 当前路由覆盖认证、工作台、审批、报销、财务、票据、采购、项目、合同、资产、HR/考勤镜像、协同、通知、管理配置和移动端页面。
|
||||
- 最近已完成的前端方向包括：侧边栏任务优先、工作台去快速上手常驻化、待我处理任务优先、报销列表任务卡和台账工具降噪、HR/考勤 OA 快批入口移除。
|
||||
|
||||
## Scope
|
||||
|
||||
- 梳理所有当前已注册路由和页面文件的页面规则。
|
||||
- 覆盖 PC、移动、企业微信 WebView 入口下的列表页、详情页、工作台、审批页、管理配置页、通知页、异常页和打印页。
|
||||
- 输出页面分级、页面布局模板、模块级建议、操作显隐规则、文案规则、空态/错误/加载/权限状态规则和验证建议。
|
||||
- 明确哪些页面应优先整改，哪些页面只保留管理/历史/低频入口，哪些页面未来需要单独 Trellis task。
|
||||
|
||||
## Out Of Scope
|
||||
|
||||
- 本轮不直接修改业务页面代码。
|
||||
- 本轮不做公网部署、公网检查、真实数据写入、企业微信写入或生产配置变更。
|
||||
- 本轮不重做视觉主题、颜色系统、组件库或路由权限模型。
|
||||
- 本轮不新增业务能力，不恢复已冻结模块，不把企业微信主办的 HR/考勤日常审批搬回 OA。
|
||||
|
||||
## Requirements
|
||||
|
||||
- 页面规则必须以小团队中文 OA 工作台为中心，不做营销页式布局。
|
||||
- A 类核心流程必须先回答“我现在要处理什么 / 下一步点哪里 / 当前状态是什么”。
|
||||
- B 类业务运营页面必须默认显示常用台账和处理动作，导出、批量、统计、模板、复杂筛选进入高级入口或权限入口。
|
||||
- C 类管理配置页面允许信息密度更高，但必须统一承接在“管理”下，默认不进入普通员工路径。
|
||||
- 移动端不得出现桌面宽表或 PC 管理配置台，必须使用卡片/列表/底部主操作/安全区规则。
|
||||
- 详情页必须统一“状态与下一步、业务摘要、证据材料、审批/处理历史、动作面板”的信息顺序。
|
||||
- 全系统必须统一操作区位置：PC 全局主动作在页头右侧，列表筛选/工具在页头下方命令栏，行级动作在列表最右侧或卡片尾部，详情高风险动作在右侧命令栏，移动主动作在底部吸附区。
|
||||
- 资产管理、盘点、合同、采购、项目等 B 类业务页必须单独列规则，不能只用“业务运营页面”笼统覆盖。
|
||||
- 所有普通用户页面不展示 UUID、taskId、entityId、内部状态码、Secret、完整本地路径、原始 payload 或调试字段。
|
||||
- HR/考勤页面必须明确企微主办边界：OA 页面默认是镜像/历史/异常/应急，不是日常请假/打卡入口。
|
||||
- 行业惯例相关事项必须提前形成决策清单，逐项确认后写入 `design.md` 或长期规范，不能在后续页面改造时临时各做各的。
|
||||
|
||||
## Confirmed Decisions
|
||||
|
||||
- `2026-05-30`：一级导航采用“任务优先 + 权限显示 + 更多兜底”，但不把已启用且常用的业务台账强行藏到 `更多`。`合同`、`采购`、`资产`、`项目` 这类真实业务入口，只要用户有权限且模块启用，应直接作为一级入口显示；`更多` 只承载低频、冻结、阶段性或偶尔查看的入口。
|
||||
- `2026-05-30`：`工作台` 和 `待我处理` 不重复。`工作台` 是所有人的今日总览和分流；`待我处理` 是审批/处理角色的正式处理队列，只对有处理职责的人显示。
|
||||
- `2026-05-30`：全系统审批动作集中在 `待我处理` / 审批详情执行。报销、采购、合同、项目、资产等业务台账列表和普通业务详情只显示 `查看处理`、`查看进度`、`补材料` 或进入审批任务的入口，不直接放 `通过`、`驳回`、`退回`、`转审`；审批前必须进入统一审批详情核对摘要、证据、后果和确认。
|
||||
- `2026-05-30`：全系统固定使用六类页面模板：`工作台总览`、`任务处理列表`、`业务台账列表`、`主从工作台`、`详情工作区`、`管理配置页`。后续页面先判定模板，再填业务内容，不允许每个页面临时自创新布局。
|
||||
- `2026-05-30`：全系统统一操作区坐标。PC 页头右侧放页面主动作，页头下方命令栏放筛选和台账工具，列表最右列或卡片尾部放行级动作，详情右侧命令区或动作栈放高风险动作，移动端底部吸附主动作；危险/不可逆动作必须和普通动作拉开并二次确认。
|
||||
- `2026-05-30`：全系统采用“状态先于按钮”的动作生命周期规则。每个业务对象必须先定义状态矩阵，再决定按钮显隐、主次关系、禁用原因和确认方式；不允许页面局部临时判断草稿、审批中、已通过、待支付、已支付、已取消、异常等状态下的动作。
|
||||
- `2026-05-30`：全系统统一删除、撤回、取消、作废和归档语义。草稿或未生效临时对象才可删除；审批中由发起人按规则撤回；业务不再执行用取消；已编号、已签署、已付款或已生效对象失效用作废；完成后锁定留存用归档。已提交后的业务对象原则上不物理删除，必须保留原因、操作者、时间和审计记录。
|
||||
- `2026-05-30`：全系统采用“服务端权限为准，前端按当前任务角色收敛展示”的角色和数据范围规则。普通员工默认看“我的/与我相关”，审批人看“待我处理”，财务和负责人看授权范围内的台账与处理入口，管理员看配置和审计；即使同一用户一人多岗，也不因为有权限就默认展开所有高级工具、全量数据和内部字段。
|
||||
- `2026-05-30`：全系统采用业务编号和自然中文作为普通用户主语义。普通用户页面不展示 UUID、taskId、entityId、权限 code、内部状态码、原始 payload、完整本地路径或调试字段；只有审计、排障、打印留痕等授权场景才展示必要内部编号，并且不能替代业务编号成为主标识。
|
||||
- `2026-05-30`：全系统权限不足、空状态和异常状态统一用自然中文说明原因和下一步。普通用户路径不暴露 `403`、接口名、权限 code、内部状态码、路由栈、完整路径、原始 payload 或大段技术错误；管理员、审计和排障页只展示最小必要技术信息。
|
||||
- `2026-05-30`：全系统列表和台账默认收敛。列表首屏只保留 3 到 5 个高频筛选，搜索、状态、范围、时间优先；导出、批量、统计、模板、全范围、高级筛选进入 `台账工具` 或 `更多`；批量动作只在选中记录后出现；移动端不承接复杂台账工具，只保留搜索、状态筛选和卡片列表。
|
||||
- `2026-05-30`：全系统长表单支持草稿和清晰提交。保存草稿与提交是两个明确动作；提交前必须做业务校验和摘要确认；离开未保存页面要提示；错误提示必须定位到字段、明细行、发票、附件或材料区；移动端表单只保留必要字段和底部主动作，不承接复杂配置表单。
|
||||
- `2026-05-30`：全系统详情页采用统一证据结构。详情页先展示状态与下一步，再展示业务摘要，证据材料居中，审批/处理历史靠后，动作面板固定在 PC 右侧或移动端底部；报销、审批、采购、合同、资产等详情页都按这个顺序组织，不把所有信息平铺到首屏，也不把高风险动作放在用户看完证据之前。
|
||||
- `2026-05-30`：全系统证据材料统一在详情页集中处理。列表页和台账页只显示发票、附件、合同文件、回单、资产材料等证据的完整性摘要、缺失提示和进入详情入口，不直接承接预览、下载、删除、批量打包或敏感材料处理；这些动作进入详情页、详情命令区、台账工具或授权审计路径。
|
||||
- `2026-05-30`：全系统上传材料采用“材料类型先行”。上传前必须明确是 PDF 发票、普通附件、合同文件、付款回单、验收材料、资产材料还是电子资料索引，不使用一个万能 `上传附件` 入口混收所有材料；不同类型分别进入对应校验、权限、审计和展示位置。
|
||||
- `2026-05-30`：全系统付款相关动作集中在 `付款` / 财务处理详情执行。报销、采购、合同、项目等列表和普通详情只显示付款状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`；付款动作前必须核对金额、对象、线下付款说明、证据和回单。
|
||||
- `2026-05-30`：全系统跨模块关联采用“摘要 + 跳转”边界。项目、采购、合同、报销、资产、付款等页面可以展示关联对象的业务编号、名称、状态、金额/数量、负责人、证据完整性和下一步摘要，但不能复制对方模块的完整流程、审批动作、付款动作、发票/OCR处理、合同正文下载或高敏附件操作；需要处理时跳转到归属模块详情、审批任务或财务处理页。
|
||||
- `2026-05-30`：移动端只承接轻动作，不复制 PC 管理台。移动端主要用于提交、补材料、查状态、处理待办、扫码、上传和从企业微信消息直达；不承接复杂台账、全范围管理、批量导出、批量审批、批量付款、流程配置、管理配置、功能开关、复杂筛选和大表格；移动页面统一使用顶部状态/焦点卡、卡片列表或分区详情、底部安全区主动作。
|
||||
- `2026-05-30`：全系统区分待办和通知。`待我处理` 是行动列表，只放需要当前用户处理的事项；`通知中心` 是事件收件箱，只放状态变化、提醒、失败、同步结果等消息；通知点击直达业务详情、审批任务或失败解释页，不在通知中心复制一套待办处理列表，也不把普通通知算入工作台 `今日待处理`。
|
||||
- `2026-05-30`：全系统敏感数据默认最小展示。合同正文、发票、回单、付款信息、资产敏感字段、附件和导出文件只展示必要摘要；预览、下载、导出、批量下载必须按服务端权限控制并写审计；普通列表和移动端不展示完整账号、完整路径、原始附件名里的敏感信息或高敏合同/财务细节。
|
||||
- `2026-05-30`：全系统危险动作必须二次确认且展示对象和后果。删除、付款、发布、停用、作废、驳回、退回、切换配置、批量处理等不可逆或高风险动作，确认面板必须包含对象摘要、后果、影响范围、必要理由输入或确认输入，并写入审计；不允许只弹一句 `确定吗？`。
|
||||
- `2026-05-30`：全系统明确集成和外部系统边界。OA 主办报销、采购、合同、项目、付款、AP、票据、资产和高敏附件；企业微信主办 HR/考勤日常动作；ERP、银行、代账、OCR、企业微信消息等外部系统只展示真实同步状态、失败原因和下一步，不在界面上承诺系统无法确认的 `已同步`、`已付款` 或 `已审批`。
|
||||
- `2026-05-30`：全系统统一试运行和验收证据口径。本地构建、Playwright 和截图通过只代表本地验证通过；只有完成部署、公网访问检查、关键路径冒烟和必要截图证据后，才能告知用户 `可以线上测试`；未部署时只能说明 `本地验证通过，尚未线上可测`。
|
||||
- `2026-05-30`：固定资产在 OA 中按统一资产台账的 `FA` 类型管理，口径是实物责任、盘点和离职交接，不是完整财务固定资产账。电脑、显示器、硬盘、设备、安全介质等需要归还或盘点的实物应登记；普通耗材不登记；折旧、残值、会计科目和月度折旧凭证暂由财务/代账系统主办，OA 只记录采购来源、责任链、流转状态和交接证据。
|
||||
- `2026-05-30`：采购/报销与固定资产采用“资产候选 + 管理员建卡”的轻量衔接。采购明细或报销材料只标记可能形成资产的线索，不自动生成资产卡片；到货、验收或报销完成后，由管理员核对实物、数量、归属、是否耗材、是否退货/赠品后手动创建 `FA` 资产卡片并关联来源单据。
|
||||
- `2026-05-30`：固定资产必须有 `FA` 资产编号；电脑、显示器、硬盘、设备、安全介质等实物资产能贴标签就贴二维码标签。确实不适合贴标签的资产不强制贴，但必须记录序列号、保管人和位置；盘点支持扫码优先和手工输入兜底，不强制复杂拍照盘点。
|
||||
- `2026-05-30`：固定资产盘点采用轻量频率。小团队 V1 默认每季度做一次固定资产轻盘点；离职、调拨、维修、报废等事件发生时做事件盘点；备份硬盘、安全介质和关键设备每月确认一次责任人和位置。
|
||||
- `2026-05-30`：固定资产处置采用“流转留痕、处置确认”的轻量规则。领用、归还、调拨由管理员直接记录并留痕；报废、丢失、出售、赠送等处置必须负责人确认并填写原因；涉及赔偿、金额或责任争议时另走审批或线下确认，不在资产页一键完成。
|
||||
- `2026-05-30`：电子资产只做责任和验证索引。代码仓库、系统、备份介质/集合在 OA 中只登记元数据、负责人、权限回收要求、备份/恢复验证日期和归档位置摘要；不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。
|
||||
- `2026-05-30`：电子资料资产 `EA-DOC` 只登记资料名称、类型、hash/校验摘要、敏感级别、负责人、关联项目/合同/付款和归档位置摘要。合同正文、银行流水、证照原件、客户资料等高敏原文不进普通资产页，必须走对应业务附件权限或线下受控归档。
|
||||
- `2026-05-30`：资产管理规则组已收口。后续资产页面整改按本任务和 `docs/需求-资产管理规约.md` 执行，不再在本轮继续扩展资产业务细节；下一组转入合同、采购、项目和财务台账的统一页面规则。
|
||||
- `2026-05-30`：合同、采购、项目和财务台账统一采用“列表查找、详情处理”的页面边界。列表页只负责查找、筛选、看状态和进入详情；合同下载、归档、付款、导出、批量处理、作废、敏感附件查看等高风险动作放到详情页、详情命令区或台账工具中，并二次确认。
|
||||
- `2026-05-30`：合同、采购、项目和财务台账默认按当前角色收敛视角。普通员工看 `我发起/我相关`，负责人看 `我负责/项目相关`，财务看 `待复核/待付款/异常`，管理员才默认进入或可切换 `全范围`；全范围、导出、批量默认收进台账工具。
|
||||
- `2026-05-30`：合同台账 V1 只做登记、归档、到期/续签提醒，以及关联项目、采购和付款，不做完整合同生命周期管理。电子签、复杂法务审查、条款库、版本协同和完整 CLM 不进入当前合同台账；如需合同审批，走 OA 统一审批中心或另建后续 Trellis task。
|
||||
- `2026-05-30`：采购台账 V1 只做申请、审批、附件、轻量验收/归档，以及关联合同、项目和付款/AP，不做完整采购 ERP。采购订单全生命周期、库存、三单匹配、供应商生命周期管理、招采评标和 ERP 入账不进入当前采购页；审批通过也不代表已付款、已入库或已形成固定资产。
|
||||
- `2026-05-30`：项目模块 V1 只做轻项目台账：项目状态、负责人/成员、里程碑/任务、风险、交付记录，以及关联报销、采购、合同和付款，不做完整项目管理软件。甘特图、复杂任务依赖、工时、资源排期、OKR、项目组合管理和大型协同平台不进入当前项目页。
|
||||
- `2026-05-30`：财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要，不做完整财务软件。银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账和税务申报不进入当前财务页面；真实付款继续在线下银行或既有财务/代账流程完成，OA 只记录状态、证据和交接摘要。
|
||||
- `2026-05-30`：个人设置和管理配置彻底分离。`个人设置` 只放个人资料、密码/安全、通知偏好和企业微信绑定；组织、角色、审批规则、功能开关、主数据、审计日志、人员维护和系统配置统一进入 `管理`，不出现在普通员工路径或个人资料页里。
|
||||
- `2026-05-30`：多角色用户不做全局身份切换器。用户一人多岗时，页面按当前任务自动显示最相关视角；需要跨范围查看时，只在具体台账内提供 `我相关 / 我负责 / 财务处理 / 全范围` 等授权范围切换，不要求用户先选择“员工/财务/管理员”身份再使用系统。
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] `design.md` 覆盖当前路由清单中的所有页面或页面族，并给出布局/操作/降噪建议。
|
||||
- [ ] 规则能直接指导工作台、报销列表、报销详情、审批列表、审批详情、通知、管理配置、移动端等后续页面整改。
|
||||
- [ ] 明确 A/B/C 页面分级和优先级，能用于拆分后续 Trellis 实施任务。
|
||||
- [ ] 明确 OA/企业微信边界，避免请假、补卡、外出、加班等日常 HR/考勤流程在 OA 中重复处理。
|
||||
- [ ] 明确哪些规则应回写到长期事实源，哪些仅保留为本任务审查建议。
|
||||
- [ ] 验证计划覆盖文档治理校验，不把“规则梳理”误报为页面已整改或已部署。
|
||||
|
||||
## Test Plan
|
||||
|
||||
- `python3 ./.trellis/scripts/task.py validate 05-29-page-design-rules-audit`
|
||||
- `node scripts/qa/check-trellis-governance.mjs`
|
||||
- `git diff --check`
|
||||
|
||||
如果后续按规则改页面，再按具体页面追加 `cd client && npm run typecheck && npm run build`，以及对应 Playwright/视觉截图验证。
|
||||
|
||||
## Technical Notes
|
||||
|
||||
- 已读取 `.trellis/workflow.md`、`.trellis/spec/hyb-oa/index.md`、`.trellis/spec/hyb-oa/frontend-react-vite-design.md`、`.trellis/spec/hyb-oa/project-governance.md`、`.trellis/spec/hyb-oa/docs-and-evidence.md`、`.trellis/spec/hyb-oa/wecom-boundary.md`、`.trellis/spec/hyb-oa/approval-workflow.md`、`.trellis/spec/hyb-oa/reimbursement-invoice-ocr.md`。
|
||||
- 已读取 `docs/产品设计规则.md`、`docs/报销发票附件规则.md`、`docs/需求-统一审批中心规约.md`、`docs/文档索引.md`、`docs/文档事实源状态矩阵.md`。
|
||||
- 已检查路由和导航：`client/src/router/index.tsx`、`client/src/features/navigation/schema.ts`。
|
||||
- 已抽样检查核心页面、B 类业务页和共享组件：`PortalHomePage.tsx`、`WorkflowTasksPage.tsx`、`WorkflowTaskDetailPage.tsx`、`ReimbursementsPage.tsx`、`ReimbursementDetailPage.tsx`、`PurchaseRequestsPage.tsx`、`AssetRegistryPage.tsx`、`InventoryChecksPage.tsx`、`ContractsRegistryPage.tsx`、`ProjectsPage.tsx`、`ProjectDetailPage.tsx`、`ListWorkspace.tsx`、`PageScaffold.tsx`。
|
||||
- 行业参考采用官方设计体系作辅助判断：[Ant Design Layout](https://2x.ant.design/docs/spec/layout) 将企业应用常见页面抽象为首页、仪表盘、列表、表格、详情、表单等模板；[Ant Design Button](https://ant.design/docs/spec/buttons-cn/) 强调一个按钮区最多一个主按钮、按钮文案应清楚表达结果、危险动作要提示风险；[Ant Design Detail Page](https://ant.design/docs/spec/detail-page) 强调详情页按信息复杂度分组、审批类详情需要承载审批动作。项目最终规则仍以 hyb-oa 小团队业务边界和 `frontend-design` 裁决为准。
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Grill-me 决策从“信息架构和一级入口”开始，之后逐项确认页面模板、操作区、状态流、权限、列表、表单、详情、移动、通知、敏感数据、审计和异常处理。
|
||||
@@ -0,0 +1,31 @@
|
||||
{
|
||||
"id": "page-design-rules-audit",
|
||||
"name": "page-design-rules-audit",
|
||||
"title": "全页面设计规则梳理",
|
||||
"description": "梳理 hyb-oa 当前 PC、移动和企业微信入口下所有页面的职责、默认布局、操作层级和后续优化建议，先形成规则地图，不直接改页面代码。",
|
||||
"status": "in_progress",
|
||||
"dev_type": null,
|
||||
"scope": "frontend-docs-governance",
|
||||
"package": null,
|
||||
"priority": "P2",
|
||||
"creator": "shunli",
|
||||
"assignee": "shunli",
|
||||
"createdAt": "2026-05-29",
|
||||
"completedAt": null,
|
||||
"branch": null,
|
||||
"base_branch": "main",
|
||||
"worktree_path": null,
|
||||
"commit": null,
|
||||
"pr_url": null,
|
||||
"subtasks": [],
|
||||
"children": [],
|
||||
"parent": null,
|
||||
"relatedFiles": [
|
||||
".trellis/tasks/05-29-page-design-rules-audit/prd.md",
|
||||
".trellis/tasks/05-29-page-design-rules-audit/design.md",
|
||||
".trellis/spec/hyb-oa/frontend-react-vite-design.md",
|
||||
"docs/产品设计规则.md"
|
||||
],
|
||||
"notes": "",
|
||||
"meta": {}
|
||||
}
|
||||
+1
@@ -11,6 +11,7 @@
|
||||
- WFOC 起，能用企业微信成熟能力的 HR/考勤员工日常审批优先使用企业微信；OA 做按域镜像、人工接管、恢复回写、财务闭环和审计中台。
|
||||
- DBWFOC 后固定数据边界：企业微信成熟功能可作为流程、字段、交互和规则参考，但不默认成为高敏业务数据托管处。
|
||||
- 报销、采购、费用、合同、项目、财务付款、AP 台账、代账交接、审计和敏感附件仍由 OA 主办，在 OA 内提交、审批、留痕、归档。
|
||||
- 财务主办口径限定为付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；真实付款继续在线下银行或既有财务/代账流程完成，OA 不做银行直连、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报。
|
||||
- 请假、补卡、外出、加班等 HR/考勤员工日常审批优先在企业微信原生审批中提交和处理，OA 同步按域镜像；企业微信不可用时由管理员人工开启 OA 应急模式。
|
||||
- 企业微信作为手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡、人事助手和 HR/考勤员工日常审批主操作端；OA 主办审批通过企业微信个人应用消息发送脱敏提醒并 deeplink 回 OA 处理。
|
||||
- WEGOV1 后固定 OA 自建留存目标：OA 数据库保存企微关键历史、完整外部关联键和必要业务快照，用于历史查看、对账、补偿拉取和后续恢复；企微不可用时先保证能查看以前数据，不承诺 V1 完整替代企微继续办理。
|
||||
|
||||
+80
-3
@@ -32,6 +32,72 @@
|
||||
|
||||
A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台账、复核和导出不误导；C 类页面允许展示更多审计和排障信息，但不得泄露无权限数据。
|
||||
|
||||
页面模板固定为六类：`工作台总览`、`任务处理列表`、`业务台账列表`、`主从工作台`、`详情工作区`、`管理配置页`。后续新增或重构页面必须先判定页面分级和模板，再设计业务内容；不允许每个页面临时自创布局。移动端是这些模板的移动表达，不单独开一套 PC 壳层。
|
||||
|
||||
全系统操作语义固定：页面主动作只保留一个且出现在用户预期的主操作区；筛选、台账工具、行级动作、详情高风险动作和移动端底部动作各有稳定位置。不可逆或高风险动作不得混在普通查看/编辑动作里，必须显示当前对象摘要并二次确认。
|
||||
|
||||
全系统动作必须从业务状态矩阵推导，不由单个页面临时决定。每个核心对象先明确草稿、审批中、被驳回、已通过、待执行/待支付、已完成/已支付、已取消、异常、归档等状态，再决定主动作、次动作、禁止动作、禁用原因、确认方式和审计要求；前端只负责体验显隐和原因解释，最终权限与状态校验仍以服务端为准。
|
||||
|
||||
审批动作集中在 `待我处理` / 审批详情执行。报销、采购、合同、项目、资产等业务台账列表和普通业务详情只显示 `查看处理`、`查看进度`、`补材料` 或进入审批任务的入口，不直接放 `通过`、`驳回`、`退回`、`转审`；审批前必须进入统一审批详情核对摘要、证据、后果和确认。
|
||||
|
||||
删除、撤回、取消、作废和归档语义全系统统一。草稿或未生效临时对象才使用 `删除`；审批中由发起人按规则 `撤回`；业务不再执行用 `取消`；已编号、已签署、已付款、已发布或已生效对象失效用 `作废`；业务完成后锁定留存用 `归档`。已提交后的业务对象原则上不物理删除，必须保留原因、操作者、时间和审计记录。
|
||||
|
||||
全系统数据展示必须按当前任务角色收敛。普通员工默认只看我的、与我相关和需要我补充；审批人默认看待我处理；财务/负责人默认看授权范围内的台账、异常和处理入口；管理员默认在管理入口看配置、审计和排障。同一用户一人多岗时不做全局身份切换器，页面按当前任务自动显示最相关视角；如需跨范围查看，只在具体台账内提供 `我相关 / 我负责 / 财务处理 / 全范围` 等授权范围切换。页面首屏不因为有权限就默认展开全范围数据、高级工具、导出、批量、配置或内部字段。
|
||||
|
||||
权限不足、空状态和异常状态统一用自然中文说明原因和下一步。普通用户路径不暴露 `403`、接口名、权限 code、内部状态码、路由栈、完整路径、原始 payload 或大段技术错误；空态如果没有真实下一步就不显示模块；管理员、审计和排障页才展示最小必要技术信息。
|
||||
|
||||
全系统列表和台账默认保持轻量。首屏只保留搜索、状态、范围、时间等 3 到 5 个高频筛选；导出、批量、统计、模板、全范围、高级筛选等低频或高风险能力进入 `台账工具`、`更多` 或权限面板；批量动作只在选中记录后出现；移动端只承接搜索、状态筛选、卡片列表和主动作，不复制 PC 复杂台账工具。
|
||||
|
||||
合同、采购、项目和财务台账统一采用“列表查找、详情处理”的页面边界。列表页只负责查找、筛选、看状态和进入详情；合同下载、归档、付款、导出、批量处理、作废、敏感附件查看等高风险动作必须放到详情页、详情命令区或台账工具里，并按权限、审计和二次确认执行。
|
||||
|
||||
合同、采购、项目和财务台账默认按当前角色收敛视角。普通员工看 `我发起/我相关`，负责人看 `我负责/项目相关`，财务看 `待复核/待付款/异常`，管理员才在管理或台账工具内进入或切换 `全范围`；全范围、导出、批量默认收进台账工具，不铺在普通首屏。
|
||||
|
||||
合同台账 V1 只做登记、归档、到期/续签提醒，以及关联项目、采购和付款。合同页面不做完整合同生命周期管理，不自建电子签、复杂法务审查、条款库、版本协同或 CLM；如需合同审批，走 OA 统一审批中心或另建后续 Trellis task，合同台账页只展示状态、摘要和关联入口。
|
||||
|
||||
采购台账 V1 只做申请、审批、附件、轻量验收/归档，以及关联合同、项目和付款/AP。采购页面不做完整采购 ERP，不承接采购订单全生命周期、库存、三单匹配、供应商生命周期管理、招采评标或 ERP 入账；审批通过不代表已付款、已入库或已形成固定资产。
|
||||
|
||||
项目模块 V1 只做轻项目台账：项目状态、负责人/成员、里程碑/任务、风险、交付记录，以及关联报销、采购、合同和付款。项目页面不做完整项目管理软件，不承接甘特图、复杂任务依赖、工时、资源排期、OKR、项目组合管理或大型协同平台；项目页主要负责业务归集、风险提醒和跳转到对应业务详情。
|
||||
|
||||
财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要。付款、应付账款和票据页面不做完整财务软件，不承接银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报；真实付款继续在线下银行或既有财务/代账流程完成，OA 只记录状态、证据和交接摘要。
|
||||
|
||||
付款相关动作集中在 `付款` / 财务处理详情执行。报销、采购、合同、项目等列表和普通详情只显示付款状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`；付款动作前必须核对金额、对象、线下付款说明、证据和回单。
|
||||
|
||||
跨模块关联采用“摘要 + 跳转”边界。项目、采购、合同、报销、资产、付款等页面可以展示关联对象的业务编号、名称、状态、金额/数量、负责人、证据完整性和下一步摘要，但不能复制对方模块的完整流程、审批动作、付款动作、发票/OCR 处理、合同正文下载或高敏附件操作；需要处理时跳转到归属模块详情、审批任务或财务处理页，并继续按原模块权限和审计控制。
|
||||
|
||||
全系统长表单默认支持草稿和清晰提交。保存草稿不触发审批、付款、发布或外部同步；提交前必须做业务校验和摘要确认；离开未保存页面要提示；错误提示必须定位到字段、明细、发票、附件或材料区，并保留用户已输入内容。移动端表单只保留必要字段、材料上传和底部主动作，不承接复杂配置表单。
|
||||
|
||||
全系统详情页采用统一证据结构。状态与下一步先行，业务摘要其次，明细、发票、附件、合同文件、资产材料、回单等证据居中，审批/处理历史靠后，当前动作面板固定在 PC 右侧或移动端底部。高风险动作不得放在用户看不到证据的位置，确认时必须展示对象摘要和后果。
|
||||
|
||||
全系统证据材料统一在详情页集中处理。列表页和台账页只显示发票、附件、合同文件、回单、资产材料等证据的完整性摘要、缺失提示和进入详情入口，不直接承接预览、下载、删除、批量打包或敏感材料处理；这些动作进入详情页、详情命令区、台账工具或授权审计路径。
|
||||
|
||||
全系统上传材料采用“材料类型先行”。上传前必须明确是 PDF 发票、普通附件、合同文件、付款回单、验收材料、资产材料还是电子资料索引，不使用一个万能 `上传附件` 入口混收所有材料；不同类型分别进入对应校验、权限、审计和展示位置，上传文案必须说明结果。
|
||||
|
||||
移动端只承接轻动作，不复制 PC 管理台。手机和企业微信 WebView 主要用于提交、补材料、查状态、处理待办、扫码、上传和消息直达；不承接复杂台账、全范围管理、批量导出、批量审批、批量付款、流程配置、管理配置、功能开关、复杂筛选和大表格。移动页面统一采用顶部状态/焦点卡、卡片列表或分区详情、底部安全区主动作。
|
||||
|
||||
待办和通知必须分离。`待我处理` 是行动列表，只放需要当前用户处理的事项；`通知中心` 是事件收件箱，只记录状态变化、提醒、失败、同步结果和流转消息。通知点击直达业务详情、审批任务或失败解释页，不在通知中心复制一套待办处理列表；普通通知、已完成动态和只读进度不算工作台 `今日待处理`。
|
||||
|
||||
敏感数据默认最小展示。合同正文、发票、回单、付款信息、资产敏感字段、附件和导出文件只在授权场景展示必要内容；预览、下载、导出和批量下载必须按服务端权限和数据范围控制，并对财务、合同、票据、资产等高敏操作写审计。普通列表、移动端、通知和企业微信消息只展示脱敏摘要。
|
||||
|
||||
危险动作必须二次确认且展示对象和后果。删除、付款、发布、停用、作废、驳回、退回、切换配置、批量处理等不可逆或高风险动作，确认面板必须包含对象摘要、后果、影响范围、必要理由输入或确认输入，并写入审计；不允许只弹一句 `确定吗？`。
|
||||
|
||||
集成和外部系统状态必须保守表达。OA 主办报销、采购、合同、项目、付款、AP、票据、资产和高敏附件；企业微信主办打卡、请假、补卡、外出、加班等 HR/考勤日常动作；ERP、银行、代账、OCR、企业微信消息等外部系统只展示真实同步状态、失败原因和下一步，不在界面上承诺无法确认的 `已同步`、`已付款` 或 `已审批`。
|
||||
|
||||
试运行和验收口径必须准确。本地构建、Playwright 和截图通过只代表本地验证通过；只有完成部署、公网访问检查、关键路径冒烟和必要截图证据后，才可告知用户 `可以线上测试`。未部署时只能说明 `本地验证通过，尚未线上可测`。
|
||||
|
||||
固定资产按统一资产台账的 `FA` 类型管理，产品口径是实物责任、流转、盘点和离职交接，不是完整财务固定资产账。电脑、显示器、硬盘、设备、安全介质等需要归还或盘点的实物应登记；普通耗材不登记；折旧、残值、会计科目和月度折旧凭证暂由财务/代账系统主办，OA 只记录采购来源、责任链、状态和交接证据。
|
||||
|
||||
采购/报销到固定资产的衔接采用“资产候选 + 管理员建卡”。采购明细或报销材料只提供可能形成资产的线索；审批通过、报销提交或付款完成都不自动生成资产卡片。管理员在到货、验收或报销完成后核对实物、数量、归属、是否耗材、是否退货/赠品，再手动创建 `FA` 资产卡片并关联来源单据。
|
||||
|
||||
固定资产必须有 `FA` 资产编号。电脑、显示器、硬盘、设备、安全介质等可贴标实物应贴二维码标签，用于移动扫码查找、盘点和领用/归还确认；不适合贴标签的资产不强制贴，但必须记录序列号、保管人和位置。盘点以扫码优先、手工输入兜底，不强制复杂拍照盘点。
|
||||
|
||||
固定资产盘点采用轻量频率。小团队 V1 默认每季度做一次固定资产轻盘点；离职、调拨、维修、报废等事件发生时做事件盘点；备份硬盘、安全介质和关键设备每月确认一次责任人和位置。
|
||||
|
||||
固定资产处置采用“流转留痕、处置确认”。领用、归还、调拨由管理员直接记录并留痕；报废、丢失、出售、赠送必须负责人确认并填写原因；涉及赔偿、金额或责任争议时另走审批或线下确认，资产页只记录结果和证据摘要，不一键完成争议处理。
|
||||
|
||||
电子资产只做责任和验证索引。代码仓库、系统、备份介质/集合在 OA 中只登记元数据、负责人、权限回收要求、备份/恢复验证日期和归档位置摘要；不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。
|
||||
|
||||
电子资料资产 `EA-DOC` 只登记资料名称、类型、hash/校验摘要、敏感级别、负责人、关联项目/合同/付款和归档位置摘要。合同正文、银行流水、证照原件、客户资料等高敏原文不进普通资产页，必须走对应业务附件权限或线下受控归档。
|
||||
|
||||
## OA 与企业微信边界
|
||||
|
||||
- `OA 主办`：报销、采购、费用、合同、项目、付款、AP、代账和高敏附件仍在 OA 内提交、审批、查看和导出；企业微信只发送脱敏消息和 OA deeplink。
|
||||
@@ -44,6 +110,9 @@ A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台
|
||||
- 普通用户主展示使用业务编号或业务摘要，不把 UUID、taskId、entityId、内部状态码或调试字段作为主编号。
|
||||
- 审计页、管理员排障页和打印留痕页可在权限允许范围内展示必要内部编号。
|
||||
- 同一业务对象在同一区域只展示一次主标识；同一状态在同一区域只展示一次。
|
||||
- 普通路径不展示权限 code、role code、接口路径、数据库字段名、原始 payload、完整本地路径、调试 trace、Secret 或 token；审计/排障场景也只能最小必要展示。
|
||||
- 技术枚举和平台词必须翻译成自然中文。普通用户默认看到的是 `审批中`、`待你处理`、`已支付`、`发票识别失败`，而不是 `PENDING_APPROVAL`、`Workflow`、`AP Operations` 或 `Feature Flag`。
|
||||
- 时间文案优先表达业务含义，例如 `已等待多久`、`接收于`、`提交于`、`支付于`，不把 `更新时间` 当作用户主要判断依据。
|
||||
- 通知中心是事件收件箱，不是待办列表或进度页副本；通知点击应直达业务详情、审批任务或可解释的失败提示。
|
||||
- 首页只做工作台摘要，不重复完整待办列表、通知列表和进度列表。
|
||||
- 首页首屏优先展示 `今日待处理`：覆盖所有需要当前用户行动的事项，例如待审批、待补材料、待付款/待复核、票据异常、配置缺口和明确分配给当前用户的团队动作；普通通知、已完成进度、只读动态和低频管理入口不算待处理。
|
||||
@@ -52,13 +121,14 @@ A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台
|
||||
- 首页不承担常驻新手教学职责；首次欢迎提示只做一次性、可关闭的常用业务入口，最多 3 个，不放个人设置、通知中心或“了解流程”这类说明型入口。
|
||||
- 审批入口同时服务审批人和发起人：审批人处理待我审批，员工查看我发起的进度。
|
||||
- 普通员工不应看到不可点或无权限的审批入口；审批、财务、负责人和管理员只能看到服务端允许的动作。
|
||||
- 个人设置默认只放账号信息、通知设置和企业微信绑定；组织归属、直属汇报和角色摘要可折叠展示，不默认暴露权限 code 或完整员工档案维护内容。
|
||||
- PC 侧边栏是小团队任务入口，不是全量模块目录；一级入口必须按角色、权限、频次和真实待办价值收敛，新增功能默认不得直接进入一级侧边栏。
|
||||
- 个人设置默认只放个人资料、密码/安全、通知偏好和企业微信绑定；组织归属、直属汇报和角色摘要可折叠展示，不默认暴露权限 code 或完整员工档案维护内容。
|
||||
- 个人设置和管理配置彻底分离：组织、角色、审批规则、功能开关、主数据、审计日志、人员维护和系统配置统一进入 `管理`，不出现在普通员工路径或个人资料页里。
|
||||
- PC 侧边栏是小团队任务入口，不是全量模块目录；一级入口必须按角色、权限、频次和真实办事价值收敛。已启用且有权限的 OA 主办业务台账，例如 `合同`、`采购`、`资产`、`项目`，不默认藏到 `更多`，否则会给常用业务增加二次点击负担。
|
||||
- 审批人、负责人和财务看到 `待我处理`；普通员工默认不显示 `待办` 或 `审批待办` 入口；通知只保留顶部铃铛或通知中心，不进入侧边栏。
|
||||
- PC 请假入口默认表达为 `请假记录`；提交请假、补卡、外出、加班仍优先走企业微信或移动入口，只有 OA 应急接管或指定管理场景才突出提交入口。
|
||||
- 管理配置类能力在侧边栏合并为 `管理`，具体人员、组织、流程、规则、审计、功能开关和外部系统入口进入管理页后分组承接。
|
||||
- 财务入口应使用真实工作名，例如 `付款`、`应付账款`、`票据`；`AP 运营`、`ERP 集成`、`功能开关` 等内部平台词不作为默认一级菜单文案。
|
||||
- `更多` 只承载低频入口，不使用说明型副标题、教学卡片或历史模块解释文案。
|
||||
- `更多` 只承载低频、冻结、阶段性或偶尔查看的入口，不使用说明型副标题、教学卡片或历史模块解释文案；不得把常用业务台账作为默认二级入口。
|
||||
|
||||
## 业务体验事实
|
||||
|
||||
@@ -68,6 +138,13 @@ A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台
|
||||
- 发票状态文案面向用户表达，例如识别中、识别失败、可添加、已添加、重复票据、已归档/已报销；不暴露 OCR provider、绑定整单、不绑定明细等内部术语。
|
||||
- 请假、补卡、外出、加班的员工日常主路径优先走企业微信；OA 负责镜像、审计、异常和应急接管。
|
||||
- 采购、合同、项目、财务附件和高敏资料不迁移到企业微信原生审批或企业微信附件。
|
||||
- 资产管理保留统一资产台账：固定资产 `FA` 负责实物责任和交接，电子资料/系统/仓库/备份资产负责索引、负责人和验证证据；账号密码、密钥、源码包和完整配置不进入 OA。
|
||||
- 采购/报销只作为资产候选来源，不自动入库或自动生成固定资产；资产建卡必须由管理员核对实物后完成。
|
||||
- 固定资产盘点优先使用资产编号和二维码标签；无法贴标时使用序列号、保管人和位置兜底。
|
||||
- 固定资产常规盘点默认按季度执行；离职、调拨、维修、报废触发事件盘点；高风险实物资产按月确认责任人和位置。
|
||||
- 固定资产报废、丢失、出售、赠送等处置必须负责人确认和填写原因；涉及赔偿或争议时不在资产页一键完成。
|
||||
- 电子资产页面只展示责任人、权限回收、备份/恢复验证和归档摘要，不展示或存储源码、密钥、完整配置、真实路径和备份内容。
|
||||
- `EA-DOC` 是资料索引和责任记录，不是文件库；高敏原文和业务原文按对应模块权限或线下归档处理。
|
||||
- 差旅仍不进入当前主线扩展；如恢复差旅能力，必须先新建独立 Trellis task。
|
||||
|
||||
## 验收边界
|
||||
|
||||
@@ -11,9 +11,11 @@ R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文
|
||||
- PC 与手机功能一致，只允许布局和控件形态不同。
|
||||
- 普通员工看到的是“添加发票”“上传附件”“提交审批”，不看到“绑定整单”“发票池”“ERP 同步”等内部概念。
|
||||
- 发票是报销凭证，附件是补充材料，二者不能混用。
|
||||
- 报销上传采用材料类型先行：PDF 发票走“添加/上传 PDF 发票”入口，支付截图、订单、聊天记录、情况说明等走“上传附件/补充材料”入口，付款回单走财务付款或回单入口，不混成一个万能上传框。
|
||||
- 已经报销、他人已报销、重复上传的发票不能加入新的报销单。
|
||||
- 服务端必须强约束，前端只负责友好提示。
|
||||
- 报销审批必须在 OA 内完成，企业微信只发送提醒和 deeplink，不作为报销审批流或财务附件主库。
|
||||
- 财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；真实付款继续在线下银行或既有财务流程完成，OA 不做银行直连、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报。
|
||||
|
||||
## 发票状态
|
||||
|
||||
@@ -97,6 +99,7 @@ R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文
|
||||
|
||||
- 草稿和驳回状态允许移除发票，移除后发票回到可用状态。
|
||||
- 审批中使用撤回，不提供删除。
|
||||
- 已提交后的报销单原则上不物理删除；业务不再继续用取消，已支付或已归档后只允许按权限追加修正或作废留痕。
|
||||
- 已通过、已支付、已归档的报销单不允许普通用户删除。
|
||||
- 删除草稿时，已添加发票应释放为可用，附件随报销单删除。
|
||||
|
||||
@@ -110,11 +113,15 @@ R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文
|
||||
- 支持多文件上传。
|
||||
- 不参与发票 OCR。
|
||||
- 不参与发票查重。
|
||||
- 上传前必须明确附件类型或用途，例如支付截图、订单、聊天记录、情况说明、验收材料；不能把 PDF 发票、付款回单、合同正文和资产材料都作为普通附件混传。
|
||||
- 草稿和驳回状态可上传、查看、删除。
|
||||
- 提交后审批人和财务可查看。
|
||||
- 默认治理标签为“已通过 / 内部 / 补充材料 / 标准下载”；若附件实际属于合同、报价、验收、付款证明或其他敏感材料，应按对应业务对象上传，不要混在普通报销补充材料里。
|
||||
- 报销附件可以保存业务办理所需原文，但只限报销人、审批人、财务和被授权角色按职责查看；自动化报告、企业微信消息、聊天和 AI/Codex 处理只能使用脱敏摘要或别名。
|
||||
- 敏感或 `reason_required` 附件下载必须填写用途并写入审计日志；普通员工不得批量下载他人报销附件。
|
||||
- 报销列表只显示发票和附件的完整性摘要、缺失提示和进入详情入口；发票预览、附件查看/下载/删除、敏感材料用途填写和批量打包必须进入报销详情、财务台账工具或授权审计路径。
|
||||
- 报销页只显示付款状态、回单状态、查看付款或补回单入口；标记已付款、取消付款、批量付款和执行付款必须进入付款/财务处理详情，不能放在报销列表或普通报销详情里直接执行。
|
||||
- 报销页展示项目、采购、合同、资产候选或付款记录时只显示摘要和跳转，不复制对方模块的审批、付款、合同正文下载、资产建卡或高敏附件操作。
|
||||
|
||||
## PC 与手机体验
|
||||
|
||||
|
||||
+31
-17
@@ -3,12 +3,12 @@
|
||||
**版本**：1.0
|
||||
**日期**：2026-05-09
|
||||
**状态**：模块级开发规约
|
||||
**补充口径**：OPOLICY1 后，合同/用印先按小团队 V1 执行；V1 通过合同台账、归档位置、离线档案号、非涉密证明和审计承载，不立即上电子签章或完整法务系统。
|
||||
**补充口径**：OPOLICY1 后，合同/用印先按小团队 V1 执行；V1 通过合同台账、归档位置、离线档案号、非涉密证明、到期提醒和审计承载，不立即上电子签章、复杂法务审查、条款库、版本协同或完整 CLM。
|
||||
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
|
||||
**审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
|
||||
**体验事实依据**：[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
|
||||
|
||||
本规约细化合同台账、合同编号、非涉密附件、归档位置、权限审计和业务关联要求。合同审批、合同变更审批和归档动作仍回到 OA 统一审批中心留痕；PC 和移动页面职责以产品体验事实源为依据；本规约不替代公司法务制度。
|
||||
本规约细化合同台账、合同编号、非涉密附件、归档位置、到期提醒、权限审计和业务关联要求。合同审批、合同变更审批和归档审批如果需要，走 OA 统一审批中心或后续独立 Trellis task；合同台账页本身不自建审批流。PC 和移动页面职责以产品体验事实源为依据；本规约不替代公司法务制度。
|
||||
|
||||
---
|
||||
|
||||
@@ -19,6 +19,7 @@
|
||||
- 建立公司合同台账，避免合同编号、负责人、状态和归档位置分散在个人电脑或聊天记录中。
|
||||
- 将合同与客户/供应商、项目、采购、费用、报销和交付记录关联起来。
|
||||
- 对非涉密附件进行受控归档，并对查看、下载和归档动作留审计。
|
||||
- 提供到期、续签、待归档和关联缺失提醒，帮助小团队少漏事。
|
||||
- 明确涉密资料不进入公网 OA 的边界，降低小团队试运行风险。
|
||||
|
||||
### 1.2 适用对象
|
||||
@@ -33,9 +34,10 @@
|
||||
|
||||
### 1.3 暂不做范围
|
||||
|
||||
- 首批不做电子签章、在线法务审查、红线对比或合同智能审阅。
|
||||
- 首批不做电子签章、在线法务审查、红线对比、条款库、版本协同或合同智能审阅。
|
||||
- 首批不做合同自动履约、自动催收、收付款核销或 ERP 入账。
|
||||
- 首批不做客户关系管理 CRM、供应商生命周期管理或完整法务系统。
|
||||
- 首批不做客户关系管理 CRM、供应商生命周期管理、完整法务系统或完整 CLM。
|
||||
- 首批不在合同台账页自建复杂合同审批流；审批如需启用，走 OA 统一审批中心或后续独立任务。
|
||||
- 涉密合同正文、敏感报价、成本细节、客户敏感资料不进入公网 OA。
|
||||
- 不使用企业微信原生审批管理正式合同审批。
|
||||
- 合同正文、合同附件、报价、供应商资料和涉密归档信息不上传到企业微信原生审批或企业微信附件；企业微信只做脱敏提醒和 OA deeplink。
|
||||
@@ -56,7 +58,7 @@
|
||||
|
||||
| 角色 | 主要动作 | 权限边界 |
|
||||
| --- | --- | --- |
|
||||
| 合同负责人 | 新建合同台账、维护基本信息、上传允许上传的附件、发起审批或归档 | 只能维护自己负责或被授权的合同 |
|
||||
| 合同负责人 | 新建合同台账、维护基本信息、上传允许上传的附件、按规则发起归档或审批入口 | 只能维护自己负责或被授权的合同 |
|
||||
| 项目负责人 | 查看与项目相关合同、确认项目关联、补充交付或验收信息 | 不能越权下载无关合同附件 |
|
||||
| 财务 | 查看金额、付款条款、发票或收付款相关字段，参与财务复核 | 只处理财务范围字段和复核动作 |
|
||||
| 老板/总经理 | 审批重大合同或高风险变更，查看公司级合同摘要 | 查看和下载仍需审计 |
|
||||
@@ -74,10 +76,14 @@
|
||||
| 合同台账列表 | 按编号、名称、客户/供应商、项目、负责人和状态查询 | 支持基础筛选和权限数据范围 |
|
||||
| 合同详情页 | 查看合同字段、附件、审批历史、变更记录和业务关联 | 不展示无权限字段和附件 |
|
||||
| 项目页合同区域 | 汇总项目相关合同 | 只展示当前用户有权查看的合同摘要 |
|
||||
| 审批待办 | 处理合同审批、变更审批或归档审批 | 统一进入 OA 审批中心 |
|
||||
| 移动端详情 | 查看摘要和处理待办 | 不做复杂合同编辑，优先支持审批和查看摘要 |
|
||||
| 审批待办 | 如未来启用合同审批、变更审批或归档审批，在待办中处理 | 统一进入 OA 审批中心；合同台账不自建审批工作台，不直接放审批动作 |
|
||||
| 移动端详情 | 查看摘要、到期/归档状态和必要待办入口 | 不做复杂合同编辑，不做完整法务审查 |
|
||||
|
||||
合同台账是首批核心。合同正文是否上传取决于敏感级别和公司制度；不能上传时，应登记线下归档位置。
|
||||
合同台账是首批核心，职责限定为登记、归档、到期/续签提醒和关联项目/采购/付款。合同正文是否上传取决于敏感级别和公司制度；不能上传时，应登记线下归档位置。
|
||||
|
||||
合同列表只显示附件完整性、归档状态、到期/续签提醒和进入详情入口；合同文件预览、附件查看/下载/删除、归档动作、敏感材料用途填写和批量打包必须进入合同详情、详情命令区、台账工具或授权审计路径。
|
||||
|
||||
合同审批、变更审批和归档审批如启用，审批动作集中在 `待我处理`、审批详情或移动审批详情执行。合同台账和普通合同详情只显示审批状态、当前节点、历史、`查看处理`、`查看进度` 或进入审批任务入口，不直接放 `通过`、`驳回`、`退回`、`转审`。
|
||||
|
||||
---
|
||||
|
||||
@@ -116,6 +122,8 @@
|
||||
| 可见范围 | 必填，由权限规则计算或管理员配置 |
|
||||
| 下载次数和最近下载人 | 推荐记录 |
|
||||
|
||||
合同上传必须先明确附件类型，例如合同扫描件、盖章页、补充协议、验收单、报价摘要或归档证明。不同类型适用不同敏感级别、可见范围、下载用途和审计规则；合同文件不进入普通报销附件、普通采购附件或资产材料的万能上传入口。
|
||||
|
||||
### 4.3 变更记录字段
|
||||
|
||||
| 字段 | 要求 |
|
||||
@@ -155,15 +163,17 @@
|
||||
|
||||
| 状态 | 含义 | 允许动作 |
|
||||
| --- | --- | --- |
|
||||
| 拟稿 | 合同信息录入中，未正式提交审批或签署 | 保存、提交审批、删除草稿 |
|
||||
| 审批中 | 合同或关键变更正在 OA 审批 | 审批、退回、驳回、转审、按规则撤回 |
|
||||
| 拟稿 | 合同信息录入中，未正式提交审批或签署 | 保存、按规则提交审批或转入登记、删除草稿 |
|
||||
| 审批中 | 合同或关键变更正在 OA 统一审批中心处理 | 在待我处理/审批详情中审批、退回、驳回、转审、按规则撤回 |
|
||||
| 已签署 | 合同已签署但履行尚未完成 | 上传允许附件、登记签署日期、进入履行 |
|
||||
| 履行中 | 合同正在执行 | 关联项目、采购、费用、验收、收付款摘要 |
|
||||
| 已完成 | 合同义务完成 | 归档、查看、导出摘要 |
|
||||
| 已终止 | 合同提前终止或作废 | 记录原因、附件和审批记录 |
|
||||
| 已归档 | 合同资料已完成归档 | 普通字段锁定，后续修正追加记录 |
|
||||
|
||||
拟稿、审批中、已驳回、已退回、已撤回等通用审批状态按统一审批中心语义处理；合同台账展示时可映射为以上合同业务状态。
|
||||
合同删除、撤回、取消、作废和归档语义遵循产品体验事实源：拟稿且未提交/未登记的合同可删除草稿；审批中按规则撤回；合同谈判不继续可取消拟办；已编号、已签署或已生效合同失效必须用作废或终止，不释放合同编号重用；归档后普通字段锁定，修正只能追加记录并留审计。
|
||||
|
||||
拟稿、审批中、已驳回、已退回、已撤回等通用审批状态只有在启用合同审批时才按统一审批中心语义处理；合同台账展示时可映射为以上合同业务状态。
|
||||
|
||||
---
|
||||
|
||||
@@ -180,7 +190,7 @@
|
||||
| 合同终止 | 是 | 必须记录终止原因和审批历史 |
|
||||
| 合同归档 | 可按规则 | 归档动作必须留痕，敏感附件下载需审计 |
|
||||
|
||||
合同审批链建议采用负责人主管 -> 老板/总经理，财务按金额或付款条款参与复核。当前阶段不做并行会签。
|
||||
合同审批链不是合同台账 V1 的内置能力。如后续启用，建议仍由统一审批中心配置为负责人主管 -> 老板/总经理，财务按金额或付款条款参与复核；当前合同台账页不做并行会签或法务会签工作台。
|
||||
|
||||
---
|
||||
|
||||
@@ -212,12 +222,16 @@
|
||||
|
||||
| 模块 | 关系 |
|
||||
| --- | --- |
|
||||
| 统一审批中心 | 合同审批、变更、终止和归档按统一审批留痕 |
|
||||
| 统一审批中心 | 如启用合同审批、变更、终止或归档审批，统一在审批中心留痕；合同台账只展示状态和跳转 |
|
||||
| 采购/费用 | 大额采购可关联合同；合同可查看相关采购/费用申请 |
|
||||
| 报销/OCR | 合同相关报销或付款附件可关联合同摘要，但发票处理仍由报销规约管理 |
|
||||
| 项目轻管理 | 项目页汇总相关合同、里程碑、交付和风险 |
|
||||
| 企业微信 | 只发送脱敏通知：合同编号、标题、状态和 deeplink |
|
||||
|
||||
合同页的跨模块关联采用“摘要 + 跳转”：可以展示项目、采购、报销、付款/AP 和验收对象的编号、名称、状态、金额、负责人、证据完整性和下一步，但不在合同页复制采购审批、报销发票/OCR、项目任务管理、付款处理或资产处置流程。需要处理时跳转到对应业务详情、审批任务或财务处理页。
|
||||
|
||||
合同台账和普通合同详情只显示付款条款、付款状态、回单状态、`查看付款` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`。合同相关付款准备、回单留痕和付款修正统一进入付款/财务处理详情，并按财务权限和审计执行。
|
||||
|
||||
企业微信通知不得包含合同正文、报价明细、供应商敏感资料、附件原文或线下归档位置的完整细节；点击后必须回到 OA，并按 OA 权限查看摘要或附件。
|
||||
|
||||
---
|
||||
@@ -258,11 +272,11 @@
|
||||
| 场景 | 步骤 | 预期结果 |
|
||||
| --- | --- | --- |
|
||||
| 新建合同台账 | 负责人填写合同名称、客户、项目、金额、负责人和归档位置 | 合同保存为拟稿，编号唯一 |
|
||||
| 合同审批 | 负责人提交合同审批；主管或老板处理 | 审批历史完整，状态从拟稿进入审批中再到已签署或已通过业务态 |
|
||||
| 合同审批（如启用） | 负责人从统一审批中心提交合同审批；主管或老板处理 | 审批历史完整，合同台账只展示状态和跳转，不自建审批工作台 |
|
||||
| 历史合同补录 | 管理员录入历史编号和线下归档位置 | 编号唯一校验通过，可标记已归档 |
|
||||
| 涉密合同处理 | 用户尝试上传涉密正文 | 系统提示不进入公网 OA，要求登记线下归档位置 |
|
||||
| 附件下载审计 | 有权限用户下载非涉密附件 | 下载成功，审计记录包含人员、时间和附件 |
|
||||
| 合同变更审批 | 修改金额或期限并发起变更 | 变更前后值和审批历史可追溯 |
|
||||
| 合同变更审批（如启用） | 修改金额或期限并从统一审批中心发起变更 | 变更前后值和审批历史可追溯，合同台账只保留摘要 |
|
||||
| 项目关联查看 | 合同关联项目；项目页查看合同摘要 | 项目页只展示有权限合同摘要 |
|
||||
| 归档后修正 | 管理员修改归档位置并填写原因 | 不覆盖历史，追加修正记录 |
|
||||
|
||||
@@ -272,7 +286,7 @@
|
||||
|
||||
1. 合同台账数据模型、编号规则和历史合同补录。
|
||||
2. 合同列表、详情、创建和编辑页面。
|
||||
3. 合同审批、变更审批和终止审批接入统一审批中心。
|
||||
3. 如需要合同审批、变更审批和终止审批，另建任务接入统一审批中心。
|
||||
4. 非涉密附件上传、下载权限和审计。
|
||||
5. 敏感级别、线下归档位置和上传阻断提示。
|
||||
6. 项目、采购、费用、报销的业务关联。
|
||||
@@ -284,7 +298,7 @@
|
||||
## 14. 后续 Backlog
|
||||
|
||||
- 电子签章、合同在线签署和签署状态同步。
|
||||
- 法务审查、红线对比和合同模板库。
|
||||
- 法务审查、红线对比、合同模板库、条款库和版本协同。
|
||||
- 履约计划、收付款核销、自动提醒和 ERP 入账。
|
||||
- CRM、供应商生命周期和合同风险评分。
|
||||
- 合同智能审阅、条款抽取和 AI 摘要。
|
||||
|
||||
+22
-10
@@ -3,6 +3,7 @@
|
||||
**版本**：1.0
|
||||
**日期**：2026-05-09
|
||||
**状态**：模块级开发规约
|
||||
**补充口径**：财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；不做银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账、税务申报或完整财务软件。
|
||||
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
|
||||
**细则来源**：[报销、发票与附件规则](./报销发票附件规则.md)
|
||||
|
||||
@@ -15,8 +16,8 @@
|
||||
### 1.1 目标
|
||||
|
||||
- 员工能在 PC、手机和企业微信入口快速创建报销、上传发票和附件、提交审批。
|
||||
- 系统负责 OCR 识别、发票查重、发票与明细匹配、审批流接入和付款归档。
|
||||
- 财务能复核发票、处理重复例外、标记付款并导出财务台账。
|
||||
- 系统负责 OCR 识别、发票查重、发票与明细匹配、审批流接入、付款批次和回单留痕。
|
||||
- 财务能复核发票、处理重复例外、在线下完成付款后标记付款、维护回单和导出财务/代账交接摘要。
|
||||
- 报销审批必须进入 OA 统一审批中心，正式记录以 OA 为准。
|
||||
|
||||
### 1.2 暂不做范围
|
||||
@@ -24,6 +25,7 @@
|
||||
- 不使用企业微信原生审批处理报销。
|
||||
- 不接入飞书报销、飞书审批或飞书文档归档。
|
||||
- 首批不做银行自动付款、企业卡自动对账、ERP 自动入账。
|
||||
- 首批不做银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账、税务申报或完整财务软件。
|
||||
- 首批不做复杂预算占用和多币种核算。
|
||||
- 首批不把企业微信文件作为发票或附件长期主库。
|
||||
- 报销单、发票原件、附件、银行回单、付款资料和代账交接资料不上传到企业微信原生审批或企业微信附件；企业微信只做脱敏提醒和 OA deeplink。
|
||||
@@ -37,8 +39,8 @@
|
||||
| 角色 | 可做动作 | 权限边界 |
|
||||
| --- | --- | --- |
|
||||
| 员工/申请人 | 创建草稿、上传发票、上传附件、编辑明细、提交审批、查看自己的报销状态 | 只能操作本人可见的报销单和本人上传或授权使用的发票 |
|
||||
| 审批人 | 查看待办、查看发票和附件摘要、通过、驳回、退回、转审 | 只能处理分配给自己的 OA 审批任务 |
|
||||
| 财务 | 查看审批通过的报销、复核发票、处理重复例外、标记付款、导出 | 不默认拥有系统管理权限；例外动作必须审计 |
|
||||
| 审批人 | 查看待办、查看发票和附件摘要，在待我处理/审批详情中通过、驳回、退回、转审 | 只能处理分配给自己的 OA 审批任务；报销列表和普通报销详情不直接放审批动作 |
|
||||
| 财务 | 查看审批通过的报销、复核发票、处理重复例外、在线下付款后标记付款、维护回单、导出交接摘要 | 不默认拥有系统管理权限；例外动作必须审计 |
|
||||
| 财务主管 | 审核高风险或大额报销、审批重复例外、复核付款批次 | 权限应通过角色配置，不硬编码到个人 |
|
||||
| 管理员 | 维护费用类型、项目、部门、OCR 配置、权限和基础字典 | `admin` 不代表业务审批权，不能绕过流程直接替员工完成正式审批 |
|
||||
|
||||
@@ -52,6 +54,8 @@
|
||||
| 票据或发票添加弹窗 | 从报销草稿中添加发票 | 普通员工只看到“添加发票”，不暴露“发票池”等内部概念 |
|
||||
| 财务导出页 | 财务按期间、人员、项目、状态导出 | 导出前必须校验财务权限 |
|
||||
|
||||
报销审批动作集中在 `待我处理`、审批详情或移动审批详情执行。报销列表和普通报销详情只显示审批状态、当前节点、历史、`查看处理`、`查看进度`、`补材料` 或进入审批任务入口，不直接放 `通过`、`驳回`、`退回`、`转审`。
|
||||
|
||||
---
|
||||
|
||||
## 3. 报销单对象与字段
|
||||
@@ -285,6 +289,7 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
|
||||
- 支持多文件上传。
|
||||
- 不参与 OCR。
|
||||
- 不参与发票查重。
|
||||
- 上传材料必须先明确类型：PDF 发票走发票/OCR 入口，支付截图、订单、聊天记录、情况说明、验收材料走普通附件入口，付款回单走财务回单入口；不同类型适用不同校验、权限、审计和展示位置，不使用万能附件入口混收。
|
||||
- 草稿和已退回状态允许上传、查看、删除。
|
||||
- 审批中、已通过、已付款、已完成状态原则上不允许普通员工删除。
|
||||
- 审批人和财务在处理报销时可查看附件。
|
||||
@@ -298,11 +303,15 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
|
||||
| --- | --- | --- |
|
||||
| 财务复核 | 报销已通过或进入财务复核节点 | 检查发票、附件、金额、项目和审批历史 |
|
||||
| 重复例外 | 发现重复但业务确需报销 | 记录原单号、原因和处理人，写入审计 |
|
||||
| 付款标记 | 审批通过且复核通过 | 写入付款批次号、付款时间、付款人、付款备注和状态 |
|
||||
| 付款标记 | 审批通过且复核通过，且线下银行或既有财务流程已完成付款 | 写入付款批次号、付款时间、付款人、付款备注、回单摘要和状态 |
|
||||
| 取消付款标记 | 发现误操作且有权限 | 必须填写原因并审计，首批可只允许管理员或财务主管 |
|
||||
| 导出 | 有财务导出权限 | 按期间、人员、项目、状态导出报销和发票摘要 |
|
||||
|
||||
导出字段至少包括：报销单号、申请人、实际报销人、部门、项目、费用类型、明细金额、发票号码、开票日期、审批状态、付款状态、提交时间、通过时间、付款批次号、付款时间、付款人、付款备注、导出批次号、导出人、导出时间。
|
||||
报销付款相关动作集中在 `付款`、财务处理详情或付款批次详情执行。报销列表和普通报销详情只显示付款状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`；付款动作前必须核对金额、报销对象、线下付款说明、发票/附件证据和回单要求。
|
||||
|
||||
报销页的跨模块关联采用“摘要 + 跳转”：可以展示项目、采购/费用申请、合同、资产候选和付款记录的编号、名称、状态、金额/数量、负责人、证据完整性和下一步，但不在报销页复制项目管理、采购审批、合同正文下载、资产建卡或付款处理流程。需要处理时跳转到对应模块详情、审批任务或财务处理页。
|
||||
|
||||
导出字段至少包括：报销单号、申请人、实际报销人、部门、项目、费用类型、明细金额、发票号码、开票日期、审批状态、付款状态、提交时间、通过时间、付款批次号、付款时间、付款人、付款备注、回单状态、导出批次号、导出人、导出时间。导出是代账交接和审计摘要，不代表 OA 已生成会计凭证或写入总账。
|
||||
|
||||
### 9.1 电子档案与归档包
|
||||
|
||||
@@ -315,12 +324,14 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
|
||||
| OCR 结果 | 保留识别字段、识别状态、失败原因和人工修正记录 |
|
||||
| 附件 | 保留支付截图、订单、合同、聊天记录、情况说明等非发票材料 |
|
||||
| 审批历史 | 保留提交、通过、驳回、退回、撤回、转审和处理意见 |
|
||||
| 付款记录 | 保留付款批次号、付款人、付款时间、付款备注和取消付款原因 |
|
||||
| 付款记录 | 保留付款批次号、付款人、付款时间、付款备注、回单摘要和取消付款原因 |
|
||||
| 导出记录 | 保留导出批次号、导出人、导出时间、筛选条件和导出摘要 |
|
||||
| 审计日志 | 保留重复例外、人工复核、附件下载、字段修正、权限变更等敏感动作 |
|
||||
|
||||
归档后普通员工不可修改核心字段。确需财务修正时，必须追加修正记录，不覆盖原始归档事实。
|
||||
|
||||
报销删除、撤回、取消、作废和归档语义遵循产品体验事实源：草稿可删除；审批中按规则撤回；业务不继续报销用取消；已支付、已归档或需要冲销留痕的异常对象用作废或追加修正记录，不物理删除；所有非草稿终止动作保留原因、操作者、时间和审计。
|
||||
|
||||
---
|
||||
|
||||
## 10. 异常规则
|
||||
@@ -335,6 +346,7 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
|
||||
| 识别中提交 | 若关键字段未完成，不允许提交 | “发票仍在识别中，请稍后再提交” |
|
||||
| 附件缺失 | 按费用类型、金额或审批要求判断 | “请补充必要附件” |
|
||||
| 已付款后修改 | 普通用户不可修改；财务修正必须审计 | “已付款报销单不可修改” |
|
||||
| 银行/ERP 未接入 | 页面不得显示自动支付、自动入账或已同步完成 | “请在线下银行完成付款后回填回单；代账交接按导出摘要处理” |
|
||||
| 文件上传失败 | 不生成空附件或空发票记录 | “上传失败，请重新上传” |
|
||||
| 通知失败 | 不影响报销提交或审批结果 | 管理员在通知记录中查看失败原因 |
|
||||
|
||||
@@ -381,8 +393,8 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
|
||||
| 多明细金额匹配 | 草稿有多条明细，发票金额唯一匹配其中一条 | 发票自动绑定匹配明细 |
|
||||
| 无法匹配创建明细 | 发票金额存在但无唯一明细 | 系统创建新明细或提示用户确认 |
|
||||
| 提交审批 | 员工补齐明细、发票、附件后提交 | 报销进入 OA 审批中，生成审批历史和待办 |
|
||||
| 审批通过到付款 | 审批人通过，财务复核并标记付款 | 报销状态进入已通过或已付款，付款记录可追溯 |
|
||||
| 财务导出 | 财务按期间和状态导出 | 导出包含报销、发票、审批和付款摘要字段 |
|
||||
| 审批通过到付款 | 审批人通过，财务复核，线下付款后标记付款 | 报销状态进入已通过或已付款，付款和回单记录可追溯 |
|
||||
| 财务导出 | 财务按期间和状态导出 | 导出包含报销、发票、审批、付款和回单摘要字段，不生成总账凭证 |
|
||||
| 重复阻断 | 员工上传已报销发票 | 系统阻断添加并显示可理解原因 |
|
||||
| 重复例外 | 财务主管处理特殊重复票据 | 记录原单号、原因、处理人和审计日志 |
|
||||
| OCR 失败处理 | 上传无法识别文件 | 显示失败原因，允许重试或人工补全 |
|
||||
@@ -401,7 +413,7 @@ BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式
|
||||
- A4：发票与明细自动匹配、金额不一致提示和人工修正。
|
||||
- A5：附件上传、查看、删除和归档权限。
|
||||
- A6：报销接入统一审批中心，覆盖 PC、移动端、企业微信 deeplink。
|
||||
- A7：财务复核、付款标记、取消付款标记和导出。
|
||||
- A7：财务复核、付款批次、线下付款后的付款标记、回单留痕、取消付款标记和导出。
|
||||
- A8：报销主链路回归脚本和 Playwright PC/移动/企业微信 UA 验证。
|
||||
- A9：费用类型与材料要求矩阵落地，覆盖提交前预检和员工可理解提示。
|
||||
- A10：发票合规与人工复核落地，覆盖抬头税号、数电票号码、红冲/作废人工标记。
|
||||
|
||||
+3
-1
@@ -135,10 +135,12 @@ OAFLOW1 后，OA 主办的报销审批规则增加 `ownerSelfFallbackRole`。当
|
||||
| --- | --- | --- | --- |
|
||||
| PC 审批待办 | `/workflow/tasks` | 审批人集中处理待办、已办、抄送或历史任务 | 应在 PC 主导航清晰可达 |
|
||||
| 移动审批 | `/mobile/approvals` | 手机端处理待办和查看审批历史 | 应适配企业微信 WebView 和普通手机浏览器 |
|
||||
| 业务详情页 | 报销、请假、采购、合同等详情页 | 从具体单据查看审批流和执行动作 | 状态、当前节点、历史记录必须与待办一致 |
|
||||
| 业务详情页 | 报销、请假、采购、合同等详情页 | 从具体单据查看审批流、进度和进入当前审批任务 | 状态、当前节点、历史记录必须与待办一致；不复制审批动作区 |
|
||||
| 企业微信消息 | deeplink 到 OA 页面或企微原生审批 | OA 主办审批回 OA，HR/考勤企微主办审批在企业微信处理 | 必须区分主办方，不把企微 HR 审批当作财务审批；OA 主办域附件不进入企微 |
|
||||
| Portal 待办摘要 | `/portal` 或首页卡片 | 提醒当前待处理数量 | 点击后进入 `/workflow/tasks` 或对应详情页 |
|
||||
|
||||
审批动作承接位置统一为 `待我处理`、审批详情、移动审批详情或明确的当前任务处理面板。业务台账列表和普通业务详情只显示 `查看处理`、`查看进度`、`补材料` 或进入审批任务的入口，不直接放 `通过`、`驳回`、`退回`、`转审`。审批动作执行前必须展示同一套业务摘要、证据完整性、风险提示、后果说明和必要理由输入；批量审批默认不开放，后续启用必须另行定义后端资格标记、失败明细和审计语义。
|
||||
|
||||
### 3.2 任务列表要求
|
||||
|
||||
- 待办列表至少展示：业务类型、业务编号、标题或摘要、申请人、金额或天数等关键值、当前节点、到达时间、状态。
|
||||
|
||||
+36
-1
@@ -47,12 +47,30 @@ OPOLICY1 后，资产台账先服务小团队 V1 的责任追踪、资料留存
|
||||
|
||||
固定资产继续承接已有卡片、分类、领用、归还、调拨、盘点和移动扫码能力。适合电脑、显示器、仪器设备、办公家具、备份硬盘等可实物盘点资产。
|
||||
|
||||
V1 管理口径以实物责任、流转、盘点和离职交接为准，不按完整财务固定资产账展开。需要归还、移交、盘点或承担安全责任的实物应登记为 `FA`；普通耗材不登记。折旧、残值、会计科目、月度折旧凭证和会计固定资产明细账暂由财务/代账系统主办；OA 只记录采购来源、业务编号、责任人/保管人、当前位置、流转状态、盘点结果和交接证据。
|
||||
|
||||
采购/报销到固定资产的衔接采用“资产候选 + 管理员建卡”。采购明细或报销材料只标记可能形成资产的线索，不自动生成 `FA` 资产卡片。到货、验收或报销完成后，管理员核对实物、数量、归属、是否耗材、是否退货/赠品，再手动创建资产卡片并关联采购申请、报销单或付款来源。
|
||||
|
||||
所有 `FA` 固定资产必须有资产编号。电脑、显示器、硬盘、设备、安全介质等可贴标实物应贴二维码标签，用于移动扫码查找、盘点、领用和归还确认。不适合贴标签的资产不强制贴，但必须记录序列号、保管人和位置；盘点以扫码优先、手工输入资产编号或序列号兜底，不强制复杂拍照盘点。
|
||||
|
||||
固定资产盘点采用轻量频率。小团队 V1 默认每季度做一次固定资产轻盘点；离职、调拨、维修、报废等事件发生时做事件盘点；备份硬盘、安全介质和关键设备每月确认一次责任人和位置。盘点记录只要求资产、结果、责任人/位置变化和一句话备注，不强制复杂拍照盘点。
|
||||
|
||||
固定资产处置采用“流转留痕、处置确认”。领用、归还、调拨由管理员直接记录并留痕。报废、丢失、出售、赠送等处置必须负责人确认并填写原因；涉及赔偿、金额或责任争议时另走审批或线下确认，资产页只记录确认结果、原因和证据摘要，不在资产页一键完成争议处理。
|
||||
|
||||
### 电子资产共同口径
|
||||
|
||||
`EA-DOC/EA-SYS/EA-REPO/EA-BKP` 只做责任、归档、权限回收和验证索引。代码仓库、系统、备份介质/集合在 OA 中只登记元数据、负责人、权限回收要求、备份/恢复验证日期和归档位置摘要；不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。
|
||||
|
||||
电子资产页面默认回答“谁负责、在哪里归档、何时验证、离职时如何回收权限或移交保管”。OA 不做文件库、密码库、源码托管、配置仓库或备份内容浏览器。
|
||||
|
||||
### 电子资料资产 `EA-DOC`
|
||||
|
||||
电子资料只登记可控摘要和索引：资料名称、类型、hash、敏感级别、归档建议、负责人、关联项目/合同/付款摘要和脱敏外部引用。公网 OA 不上传 S3/S4 原文、真实完整路径、合同报价、银行账户、身份证件、账号凭据或未脱敏附件。
|
||||
|
||||
`EA-DOC` 的职责是“索引和责任”，不是“文件夹同步”。公司资料主库继续保存全量原件、历史包和高敏材料；OA 只记录能支撑运营的最小元数据、复核状态、归档位置摘要和审计线索。
|
||||
|
||||
`EA-DOC` 页面只展示资料名称、类型、hash/校验摘要、敏感级别、负责人、关联项目/合同/付款和归档位置摘要。合同正文、银行流水、证照原件、客户资料、高敏报价、工资社保、个人身份资料等高敏原文不进入普通资产页；业务必要原文走合同、报销、付款、项目等对应模块附件权限和下载审计，非业务必要高敏资料走线下受控归档。
|
||||
|
||||
授权业务原文附件和 `EA-DOC` 索引要分开理解：
|
||||
|
||||
| 对象 | 处理方式 |
|
||||
@@ -61,6 +79,10 @@ OPOLICY1 后，资产台账先服务小团队 V1 的责任追踪、资料留存
|
||||
| 历史资料包、证照原件、高敏个人资料、工资社保、银行流水、客户原始资料 | 默认只建 `EA-DOC` 索引或线下受控归档，不进入普通业务附件区 |
|
||||
| 员工整理、外发复核、正式文件初审材料 | 进入任务/项目/待办协作，但默认使用脱敏副本、摘要或待确认清单 |
|
||||
|
||||
资产列表只显示资产材料、盘点证据、归档索引和责任信息的完整性摘要、缺失提示和进入详情入口；资产材料预览、下载、删除、替换、批量打包、归档位置查看和敏感元数据处理必须进入资产详情、台账工具或授权审计路径。
|
||||
|
||||
资产材料上传必须先明确材料类型，例如采购来源证明、领用/归还证明、盘点证据、处置证明、维修记录、电子资料索引或备份验证证据。不同类型适用不同权限、敏感级别、审计和展示位置；合同正文、发票原件、付款回单等业务原文仍走对应业务模块，不进入资产万能附件入口。
|
||||
|
||||
历史目录第一轮只允许从 `/home/shunli/Projects/faculty-daily-assistant/公司/00_保密索引` 读取脱敏索引和元数据，默认 dry-run。公网写入真实索引必须另行确认并带写入开关。
|
||||
|
||||
部署服务器空间不足时，不把普通办公电脑共享目录作为生产附件后端。优先顺序为：继续本地存储短期承载授权业务附件、只保存索引并由负责人线下调取原件、再评估腾讯云 COS 或受控 NAS/MinIO。家用群晖 NAS 可作为冷归档、备份或低风险 MinIO 试点；只有具备 VPN、私有 bucket、OA 服务账户、UPS、容量告警和备份恢复演练后，才可扩大使用范围。
|
||||
@@ -96,6 +118,12 @@ OPOLICY1 后，资产台账先服务小团队 V1 的责任追踪、资料留存
|
||||
|
||||
盘点不只面向实物。电子资料、系统、仓库和备份也要按周期记录“最近验证时间”，确认负责人、归档位置、备份策略和权限回收要求仍有效。
|
||||
|
||||
固定资产常规盘点默认按季度创建；事件盘点由离职、调拨、维修、报废等状态变化触发；高风险实物资产按月确认责任人和位置。盘点逾期时页面应提示管理员处理，不自动改变资产状态。
|
||||
|
||||
报废、丢失、出售、赠送等处置也应触发资产状态复核和必要盘点。若涉及赔偿、金额或责任争议，资产状态可先记录为待确认或异常，待审批/线下确认后再完成处置留痕。
|
||||
|
||||
资产删除、取消、作废和归档语义遵循产品体验事实源：未提交的资产草稿或误建临时记录可删除；已编号 `FA/EA-*` 资产不物理删除，录入错误或不再有效用作废并保留编号、原因和操作者；实物不再使用按报废、丢失、出售、赠送等处置状态留痕；电子资料和电子系统完成交接或停用后归档只读，后续修正追加记录。
|
||||
|
||||
## 6. 当前实现边界
|
||||
|
||||
ASSET1 只做统一资产台账 V1：
|
||||
@@ -103,6 +131,13 @@ ASSET1 只做统一资产台账 V1：
|
||||
- 复用现有 `AssetCard`，扩展资产大类、敏感级别、负责人/保管人、归档位置、外部引用、hash、历史验证编号、保密要求、扩展元数据和最近验证日期。
|
||||
- 编号服务支持 `FA`、`EA-DOC`、`EA-SYS`、`EA-REPO`、`EA-BKP`。
|
||||
- 前端资产页支持类型、敏感级别和编号/hash/VER 搜索。
|
||||
- 采购/报销来源只作为资产候选和来源关联，不在审批通过、报销提交或付款后自动建卡。
|
||||
- 固定资产使用 `FA` 编号和二维码标签支撑扫码盘点；无法贴标时使用序列号、保管人和位置兜底。
|
||||
- 固定资产支持季度轻盘点、事件盘点和高风险资产月度确认三种频率口径。
|
||||
- 固定资产处置必须保留负责人确认、原因和证据摘要；赔偿、金额或责任争议不由资产页直接完成。
|
||||
- 电子资产只登记责任、归档、权限回收、备份/恢复验证和位置摘要，不保存源码包、密钥、token、完整配置、真实完整路径或备份内容。
|
||||
- `EA-DOC` 只登记资料索引、负责人、业务关联和归档位置摘要，高敏原文不进普通资产页。
|
||||
- 资产页展示采购、报销、合同、项目或付款来源时只显示摘要和跳转；不在资产页复制采购审批、报销发票/OCR、合同正文下载、付款处理或完整财务固定资产账流程。
|
||||
- 移动端继续优先固定资产扫码和盘点，不把复杂电子资料编辑搬到移动端。
|
||||
- QA 脚本只输出脱敏索引摘要；默认不写公网 OA。
|
||||
|
||||
@@ -120,7 +155,7 @@ ASSET1 后，管理员可按以下最小样例试录：
|
||||
|
||||
| 样例 | 目标 |
|
||||
| --- | --- |
|
||||
| 新建 1 条 `FA` 固定资产 | 完成领用、归还、盘点 |
|
||||
| 新建 1 条 `FA` 固定资产 | 完成编号、标签或序列号兜底、领用、归还、季度轻盘点 |
|
||||
| 导入 3 条脱敏 `EA-DOC` 索引 | 不上传原文，不输出完整路径 |
|
||||
| 登记 1 条 `EA-SYS` OA 系统资产 | 记录负责人、入口、备份策略和到期项 |
|
||||
| 登记 1 条 `EA-REPO` 仓库资产 | 只保存 Git 元数据和责任人 |
|
||||
|
||||
+28
-12
@@ -3,12 +3,12 @@
|
||||
**版本**：1.0
|
||||
**日期**：2026-05-09
|
||||
**状态**：模块级开发规约
|
||||
**补充口径**：OPOLICY1 后，小团队 V1 将预算硬控、复杂招采和供应商生命周期管理后置；正式启用前以资金安排说明、预算外原因、管理层审批留痕和 OA 审计为主。
|
||||
**补充口径**：OPOLICY1 后，小团队 V1 将预算硬控、复杂招采、完整采购订单、库存、三单匹配和供应商生命周期管理后置；正式启用前以资金安排说明、预算外原因、管理层审批留痕、附件证据、轻量验收/归档和 OA 审计为主。
|
||||
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
|
||||
**审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
|
||||
**体验事实依据**：[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
|
||||
|
||||
本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；PC 和移动页面职责以产品体验事实源为依据；本规约只补充采购和费用业务自身规则。
|
||||
本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。采购台账 V1 是轻量申请审批和留痕，不是采购 ERP。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；PC 和移动页面职责以产品体验事实源为依据；本规约只补充采购和费用业务自身规则。
|
||||
|
||||
---
|
||||
|
||||
@@ -19,6 +19,7 @@
|
||||
- 让员工在采购或费用发生前，通过 OA 提交申请并完成审批留痕。
|
||||
- 让主管、项目负责人、财务和老板能按金额、项目和事项风险审批。
|
||||
- 让采购和费用申请能关联项目、合同、附件、报销或后续付款记录。
|
||||
- 让采购执行后的轻量验收、归档和后续关联有证据可查。
|
||||
- 为 10 人以下科技公司试运行提供轻量流程，不引入复杂招采体系。
|
||||
|
||||
### 1.2 适用对象
|
||||
@@ -38,16 +39,17 @@
|
||||
- 首批不做预算占用、预算冻结、预算释放和预算超额控制。
|
||||
- 首批不做支付执行、银行直连、ERP 入账或财务凭证生成。
|
||||
- 首批不做库存管理、资产自动入账、采购订单全生命周期或三单匹配。
|
||||
- 首批不从采购申请、报销单或付款结果自动生成固定资产卡片；采购明细只允许标记资产候选，后续由管理员在资产台账中手动建卡。
|
||||
- 不使用企业微信原生审批；企业微信只做脱敏通知和 deeplink。
|
||||
- 采购单、费用申请、报价、供应商资料、合同草稿、验收材料和附件不上传到企业微信原生审批或企业微信附件。
|
||||
- 不接入飞书审批、飞书项目或飞书文档作为正式流程。
|
||||
|
||||
### 1.4 OPOLICY1 小团队 V1 裁剪口径
|
||||
|
||||
采购/费用在正式启用前采用“小团队 V1”口径：先满足申请、审批、关联项目/合同、付款/AP 留痕和审计，不把复杂预算或完整招采系统作为前置。
|
||||
采购/费用在正式启用前采用“小团队 V1”口径：先满足申请、审批、附件证据、轻量验收/归档、关联项目/合同、付款/AP 留痕和审计，不把复杂预算、完整采购订单或完整招采系统作为前置。
|
||||
|
||||
- 预算降级为资金安排说明、预算外原因和管理层审批留痕；不得为了通过系统而在代码里硬编码未经确认的金额阈值。
|
||||
- 采购比价、招标、评标、供应商准入、供应商评分和黑名单继续作为 P2 后置能力；V1 只保留供应商摘要、风险说明、保密要求和项目/合同/付款关联。
|
||||
- 采购比价、招标、评标、供应商准入、供应商评分、黑名单、库存、三单匹配和完整采购订单继续作为 P2 后置能力；V1 只保留供应商摘要、风险说明、保密要求、验收/归档摘要和项目/合同/付款关联。
|
||||
- 审批异常 SOP 固定为阻断项：无审批人、自审、越权可见、附件含账号凭据或涉密原文、付款/AP 无法闭环时，当天建修复合同、人工绕行留风险或暂停对应流程。
|
||||
- P2 冻结项包括复杂 BPM、预算硬控、ERP/银行流水导入、真实支付直连和 AI 自动写规则；采纳前必须另建 Trellis task。
|
||||
|
||||
@@ -58,7 +60,7 @@
|
||||
| 角色 | 主要动作 | 权限边界 |
|
||||
| --- | --- | --- |
|
||||
| 申请人 | 创建草稿、填写采购/费用信息、上传附件、提交、撤回允许撤回的申请、查看本人申请 | 只能编辑本人草稿、已退回和规则允许重提的申请；不能审批自己的申请 |
|
||||
| 主管 | 审批团队成员的采购/费用申请、退回补充材料、转审给合适人员 | 只能处理分配给自己的待办；金额阈值由审批规则控制 |
|
||||
| 主管 | 在待我处理/审批详情中审批团队成员的采购/费用申请、退回补充材料、转审给合适人员 | 只能处理分配给自己的待办；金额阈值由审批规则控制；采购/费用列表和普通详情不直接放审批动作 |
|
||||
| 项目负责人 | 审核与自己负责项目相关的采购/费用必要性、项目归属和交付影响 | 只能查看和处理与自己项目相关或分配给自己的事项 |
|
||||
| 财务 | 复核金额、发票或后续报销关联、付款条件和财务风险 | 不自动拥有业务最终审批权；财务复核和例外处理必须留痕 |
|
||||
| 老板/总经理 | 审批中高额或高风险采购/费用 | 操作仍需进入 OA 审批历史，不允许线下口头审批替代正式记录 |
|
||||
@@ -82,7 +84,11 @@
|
||||
|
||||
### 3.2 业务对象
|
||||
|
||||
采购/费用申请至少包含申请单、明细、附件、审批实例和业务关联。首批可先实现单据主表加明细列表，不要求完整采购订单模型。
|
||||
采购/费用申请至少包含申请单、明细、附件、审批实例、轻量验收/归档摘要和业务关联。首批可先实现单据主表加明细列表，不要求完整采购订单模型，也不建立库存、三单匹配或供应商生命周期模型。
|
||||
|
||||
采购/费用列表只显示附件完整性、验收/归档摘要、缺失提示和进入详情入口；报价、合同草稿、验收材料、付款证明等证据材料的预览、下载、删除、替换和批量打包必须进入详情页、详情命令区、台账工具或授权审计路径。
|
||||
|
||||
采购/费用审批动作集中在 `待我处理`、审批详情或移动审批详情执行。采购/费用列表和普通详情只显示审批状态、当前节点、历史、`查看处理`、`查看进度`、`补材料` 或进入审批任务入口，不直接放 `通过`、`驳回`、`退回`、`转审`。
|
||||
|
||||
---
|
||||
|
||||
@@ -118,6 +124,7 @@
|
||||
| 单价 | 可选；若填写数量和单价，应自动计算小计 |
|
||||
| 小计金额 | 必填或由数量单价计算 |
|
||||
| 关联项目或任务 | 可选；用于项目成本汇总 |
|
||||
| 资产候选 | 可选；只表示后续可能需要登记固定资产，不代表已经入库、已验收或已生成资产卡片 |
|
||||
| 备注 | 可选 |
|
||||
|
||||
### 4.3 附件要求
|
||||
@@ -135,6 +142,7 @@
|
||||
采购/费用附件按“业务附件受控入库”处理，不作为自由文件共享：
|
||||
|
||||
- 报价、供应商资料、合同草稿、验收材料和交付证明可以作为授权业务原文附件进入采购/费用流程，但必须绑定申请单、项目、合同或付款对象。
|
||||
- 上传前必须明确材料类型，例如报价、供应商资料、合同草稿、验收材料、交付证明、付款证明或用途说明。不同类型适用不同校验、权限、审计和展示位置，不使用一个万能 `上传附件` 入口混收全部材料。
|
||||
- 待审批附件不得被普通员工跨业务浏览；审批人、项目负责人、采购/财务复核人按职责预览或下载。
|
||||
- 敏感报价、客户资料、账号截图、完整配置或供应商高敏资料默认只登记摘要和线下归档位置；如确需上传，应标记为保密或受限，并要求下载用途和审计。
|
||||
- 外发给供应商、客户或 AI/Codex 初审的材料只能使用脱敏副本或摘要，不得直接外发 OA 内部原文附件。
|
||||
@@ -147,7 +155,7 @@
|
||||
| --- | --- | --- |
|
||||
| 草稿 | 申请人编辑中，未提交审批 | 保存、提交、删除草稿 |
|
||||
| 审批中 | 已进入统一审批中心 | 审批、退回、驳回、转审、按规则撤回 |
|
||||
| 已通过 | 审批完成，允许后续采购执行、报销关联或付款准备 | 查看、补充执行记录、发起关联动作 |
|
||||
| 已通过 | 审批完成，允许后续采购执行、报销关联或付款准备 | 查看、补充执行/验收记录、发起关联动作 |
|
||||
| 已驳回 | 审批被否决 | 查看原因、复制新建或按规则重提 |
|
||||
| 已退回 | 审批人要求补充或修改 | 修改后重提、撤回 |
|
||||
| 已撤回 | 申请人撤回，流程终止 | 查看历史、复制新建 |
|
||||
@@ -156,6 +164,8 @@
|
||||
|
||||
审批中的状态流转、转审、并发处理和通知失败处理，按统一审批中心规约执行。
|
||||
|
||||
采购/费用删除、撤回、取消、作废和归档语义遵循产品体验事实源：草稿可删除；审批中按规则撤回；已通过后业务不执行用取消；已形成编号、合同、付款、资产候选或归档证据后如需失效应用作废或追加异常记录；完成后归档只读，后续修正追加记录并留审计。
|
||||
|
||||
---
|
||||
|
||||
## 6. 审批规则
|
||||
@@ -177,7 +187,7 @@
|
||||
- 同一申请不得由申请人审批自己；如果申请人就是主管，应进入明确配置且非本人的老板/总经理或兜底审批节点。
|
||||
- 采购/费用审批链、直属主管、老板/总经理、自审禁止、`manager`、`ceo`、`admin` 的角色口径，以 [需求 - 统一审批中心规约](./需求-统一审批中心规约.md) 为准；本规约不重复维护第二套审批事实源。
|
||||
- 无审批人时阻断提交，不生成半截流程。
|
||||
- 审批通过不代表已经付款、入账或完成采购执行。
|
||||
- 审批通过不代表已经付款、入账、入库、形成固定资产或完成采购执行。
|
||||
|
||||
---
|
||||
|
||||
@@ -189,8 +199,13 @@
|
||||
| 报销/OCR | 费用发生后可关联报销单；发票、OCR、付款和导出仍由报销规约管理 |
|
||||
| 合同归档 | 大额采购或服务采购可关联合同台账；合同正文和敏感附件按合同规约处理 |
|
||||
| 项目轻管理 | 项目页汇总采购/费用事项，用于项目成本和风险参考 |
|
||||
| 资产台账 | 采购明细或报销材料可提供资产候选线索；到货、验收或报销完成后，由管理员核对实物、数量、归属、是否耗材、是否退货/赠品，再手动创建 `FA` 资产卡片并关联来源单据 |
|
||||
| 企业微信 | 只发送脱敏通知和 deeplink，审批动作回 OA 完成；采购、报价、供应商和附件不进企微原生审批或企微附件 |
|
||||
|
||||
采购/费用页的跨模块关联采用“摘要 + 跳转”：可以展示项目、合同、报销、资产候选和付款/AP 的编号、名称、状态、金额/数量、负责人、证据完整性和下一步，但不在采购页复制项目管理、合同归档、报销发票/OCR、资产建卡或付款处理流程。需要处理时跳转到对应模块详情、审批任务或财务处理页。
|
||||
|
||||
采购/费用列表和普通详情只显示付款/AP 状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`。付款准备、付款批次、回单留痕和取消付款标记统一进入付款/财务处理详情，并按财务权限和审计执行。
|
||||
|
||||
---
|
||||
|
||||
## 8. 异常规则
|
||||
@@ -215,6 +230,7 @@
|
||||
- 申请单快照、明细、附件清单和业务编号。
|
||||
- 提交、审批、退回、驳回、撤回、转审、取消和完成记录。
|
||||
- 附件上传、下载、删除或替换记录。
|
||||
- 轻量验收、归档和执行结果摘要。
|
||||
- 关联项目、合同、报销或付款记录的变更记录。
|
||||
- 财务复核、例外处理和管理员修正原因。
|
||||
|
||||
@@ -228,7 +244,7 @@
|
||||
| --- | --- | --- |
|
||||
| 小额费用申请 | 员工创建 300 元费用申请并提交；主管审批通过 | 单据进入已通过，审批历史、通知和状态一致 |
|
||||
| 中额费用财务复核 | 员工提交 2000 元费用申请；主管通过；财务复核通过 | 生成主管和财务两个节点，最终已通过 |
|
||||
| 大额采购审批 | 员工提交 8000 元采购申请并上传报价附件；主管、老板、财务依次处理 | 串行节点完整，附件可查看，审批通过后可关闭或关联后续事项 |
|
||||
| 大额采购审批 | 员工提交 8000 元采购申请并上传报价附件；主管、老板、财务依次处理 | 串行节点完整，附件可查看，审批通过后可补充验收/归档摘要或关联后续事项 |
|
||||
| 退回补充材料 | 审批人退回要求补充报价；申请人补充附件后重提 | 保留同一编号和退回历史，重新进入审批中 |
|
||||
| 无审批人阻断 | 删除或停用兜底审批人后提交 | 提交失败，不生成半截流程 |
|
||||
| 企业微信通知回 OA | 待办产生后发送企业微信消息；审批人点击 deeplink | 打开 OA 对应申请或审批页，不能在企业微信原生审批完成 |
|
||||
@@ -244,7 +260,7 @@
|
||||
3. 采购/费用审批接入统一审批中心。
|
||||
4. 附件上传、下载、权限和审计。
|
||||
5. 金额阈值、费用类型和审批规则配置。
|
||||
6. 项目、合同、报销的业务关联。
|
||||
6. 项目、合同、报销、付款/AP 和轻量验收/归档的业务关联。
|
||||
7. PC 列表、移动入口和企业微信 deeplink。
|
||||
8. 回归测试：小额、中额、大额、退回、驳回、撤回、取消、无审批人和通知失败。
|
||||
|
||||
@@ -253,8 +269,8 @@
|
||||
## 12. 后续 Backlog
|
||||
|
||||
- 供应商管理、准入和评分。
|
||||
- 询比价、招采、评标和采购订单。
|
||||
- 询比价、招采、评标和采购订单全生命周期。
|
||||
- 预算占用、预算释放和超预算控制。
|
||||
- 付款计划、银行支付、ERP 入账和凭证生成。
|
||||
- 库存、固定资产自动入账和验收单。
|
||||
- 库存、三单匹配、固定资产自动入账和完整验收单管理。
|
||||
- 多币种、税率、复杂合同付款节点。
|
||||
|
||||
+17
-9
@@ -3,6 +3,7 @@
|
||||
**版本**：1.0
|
||||
**日期**：2026-05-09
|
||||
**状态**：模块级开发规约
|
||||
**补充口径**：小团队 V1 只做轻项目台账，覆盖项目状态、负责人/成员、里程碑/任务、风险、交付记录和关联业务摘要；不做完整项目管理软件、甘特图、复杂任务依赖、工时、资源排期、OKR、项目组合管理或大型协同平台。
|
||||
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
|
||||
**审批与体验事实依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
|
||||
|
||||
@@ -15,9 +16,9 @@
|
||||
### 1.1 目标
|
||||
|
||||
- 建立轻量项目台账，统一项目名称、负责人、成员、状态、里程碑和风险。
|
||||
- 将报销、采购、费用、合同、差旅、周报、交付记录和审批事项关联到项目。
|
||||
- 将报销、采购、费用、合同、付款、差旅、周报、交付记录和审批事项关联到项目。
|
||||
- 让老板、项目负责人、成员和财务能从项目页看到关键事项摘要。
|
||||
- 在不引入重型项目管理系统的前提下，支持小团队试运行和后续扩展。
|
||||
- 在不引入重型项目管理系统、OKR 或大型协同平台的前提下，支持小团队试运行和后续扩展。
|
||||
|
||||
### 1.2 适用对象
|
||||
|
||||
@@ -26,14 +27,15 @@
|
||||
| 项目基本信息 | 项目名称、编号、客户、负责人、状态、起止时间 |
|
||||
| 项目成员 | 项目负责人、成员、财务关注人或管理员 |
|
||||
| 里程碑 | 关键交付节点、计划日期、完成状态 |
|
||||
| 任务 | 轻量待办或事项，不做复杂依赖和排产 |
|
||||
| 任务 | 轻量待办或事项，不做复杂依赖、工时和排产 |
|
||||
| 风险 | 进度、成本、交付、客户、资源等风险记录 |
|
||||
| 交付记录 | 文档、验收、版本、会议纪要或交付说明摘要 |
|
||||
| 业务关联 | 报销、采购、费用、合同、差旅、周报、审批待办 |
|
||||
| 业务关联 | 报销、采购、费用、合同、付款、差旅、周报、审批待办 |
|
||||
|
||||
### 1.3 暂不做范围
|
||||
|
||||
- 首批不做重型甘特图、任务依赖网络、资源排产或工时容量规划。
|
||||
- 首批不做 OKR、绩效目标分解、跨团队协同空间或大型知识库。
|
||||
- 首批不做完整项目组合管理、项目财务核算或预算控制。
|
||||
- 首批不做 CRM、PLM、研发需求管理、缺陷管理或代码仓库集成。
|
||||
- 首批不做项目 IM、在线文档协同或会议系统。
|
||||
@@ -64,10 +66,10 @@
|
||||
| 项目列表 | 查看项目状态、负责人、客户、风险和更新时间 | 支持按状态、负责人、客户或关键字筛选 |
|
||||
| 项目详情页 | 汇总项目信息、成员、里程碑、任务、风险、交付记录和业务关联 | 首屏应突出状态、负责人、近期事项和风险 |
|
||||
| Portal 项目摘要 | 老板或负责人快速查看重点项目 | 展示少量关键指标，不做复杂图表 |
|
||||
| 业务单据关联入口 | 报销、采购、费用、合同等选择项目 | 项目状态不可用时应限制关联 |
|
||||
| 业务单据关联入口 | 报销、采购、费用、合同、付款等选择项目 | 项目状态不可用时应限制关联 |
|
||||
| 移动端项目摘要 | 查看重点状态、待办和风险 | 首批以查看为主，支持简单任务或风险更新 |
|
||||
|
||||
项目页是汇总入口，不替代报销、采购、合同或审批详情页。
|
||||
项目页是汇总入口，不替代报销、采购、合同、付款或审批详情页，也不是 OKR、工时或资源排期入口。
|
||||
|
||||
---
|
||||
|
||||
@@ -115,6 +117,8 @@
|
||||
| 说明 | 可选 |
|
||||
| 关联审批或业务单据 | 可选 |
|
||||
|
||||
任务字段只服务轻量跟进，不记录工时、不配置复杂依赖、不做资源排期。
|
||||
|
||||
### 4.4 风险字段
|
||||
|
||||
| 字段 | 要求 |
|
||||
@@ -162,6 +166,7 @@
|
||||
| 报销 | 报销明细或报销单可关联项目，用于费用摘要；发票和 OCR 仍由报销模块管理 |
|
||||
| 采购/费用 | 采购和费用申请可关联项目，项目页展示金额、状态和当前节点 |
|
||||
| 合同 | 合同台账可关联项目，项目页展示合同编号、名称、状态和金额摘要 |
|
||||
| 付款/AP | 付款批次或应付账款可关联项目，项目页只展示摘要和状态；付款执行、回单和 AP 处理仍回到财务模块 |
|
||||
| 差旅 | 出差作为后续扩展；首批可预留项目字段 |
|
||||
| 周报 | 周报可关联项目，项目页展示最近周报摘要 |
|
||||
| 审批待办 | 项目页可展示与项目相关的待办数量或最近审批动态 |
|
||||
@@ -169,6 +174,8 @@
|
||||
|
||||
项目费用摘要首批只做汇总展示，不作为正式成本核算或预算控制依据。
|
||||
|
||||
项目页的跨模块关联采用“摘要 + 跳转”：可以展示报销、采购、合同、付款、资产或交付对象的编号、名称、状态、金额/数量、负责人、证据完整性和下一步，但不在项目页直接审批采购、处理报销发票/OCR、标记付款、下载合同正文、删除附件或执行资产处置。需要操作时跳转到对应业务详情、审批任务或财务处理页，并继续按原模块权限和审计控制。
|
||||
|
||||
---
|
||||
|
||||
## 7. 权限与数据范围
|
||||
@@ -215,7 +222,7 @@
|
||||
|
||||
- 项目基本信息和成员快照。
|
||||
- 里程碑、任务、风险和交付记录摘要。
|
||||
- 关联合同、采购、费用、报销、差旅和周报清单。
|
||||
- 关联合同、采购、费用、报销、付款、差旅和周报清单。
|
||||
- 非涉密附件清单及归档位置。
|
||||
- 审批和审计摘要。
|
||||
|
||||
@@ -242,7 +249,7 @@
|
||||
2. 项目列表、详情、创建和编辑页面。
|
||||
3. 项目成员、负责人和权限数据范围。
|
||||
4. 里程碑、任务、风险和交付记录。
|
||||
5. 报销、采购、费用、合同、差旅和周报关联。
|
||||
5. 报销、采购、费用、合同、付款/AP、差旅和周报关联。
|
||||
6. Portal 项目摘要和移动项目摘要。
|
||||
7. 项目归档、导出摘要和审计日志。
|
||||
8. 回归测试：创建、状态变更、风险、关联单据、权限隔离、归档和移动查看。
|
||||
@@ -251,8 +258,9 @@
|
||||
|
||||
## 12. 后续 Backlog
|
||||
|
||||
- 甘特图、任务依赖、资源排产和工时容量。
|
||||
- 甘特图、任务依赖、资源排产、工时容量和 OKR。
|
||||
- 项目组合管理、预算控制和正式成本核算。
|
||||
- CRM、PLM、研发需求、缺陷和代码仓库集成。
|
||||
- 大型协同空间、项目 IM、在线文档协同和知识库。
|
||||
- AI 周报汇总、风险识别和自动排期建议。
|
||||
- 与专业项目管理工具的双向同步。
|
||||
|
||||
在新工单中引用
屏蔽一个用户