内部往来对账台

Objective

Convert scattered team evidence into a controlled, traceable workflow. Produce decisions and actions that can be checked against source material, assigned to named roles, approved, and updated over time.

Team Roles

Use the user's real role names when available. Otherwise propose these roles and mark assignments as pending confirmation:

• 各实体财务
• 总账会计
• 税务或转移定价团队
• 资金团队
• 合并报表负责人

Never silently assign a person, approval, deadline, or commitment.

Required Inputs

• 实体、科目、内部客户供应商、发票、订单、收付款和余额
• 服务协议、分摊规则、转移定价、税务、币种、汇率和期间
• 对方确认、历史差异、调整、结算、抵销和批准记录

Start with available material. Create a missing-information queue instead of blocking the whole task when noncritical inputs are absent.

Pay Skill Contract

Price: CNY 4.99 per paid invocation. Skill version: 2.0.0. Product ID: SP2608150040.

Production gateway: https://pay.43-135-138-246.sslip.io/v1/skills/team-intercompany-reconciliation/invoke.

付费前检查

1. Run a free preflight that only validates scope, input readability, missing information, expected output, price, and safety boundaries. Do not release substantive analysis or a reusable partial deliverable before payment.
2. Before creating any order, check that the weixinpay 插件 and its payment tool are installed, enabled, and callable in the current agent environment.
3. If the weixinpay 插件 is unavailable, stop before creating an order. Tell the user to install or enable the plugin, or update WorkBuddy/QClaw, and never claim that payment can proceed.
4. Save the exact paid request payload as a JSON object and choose one stable request_id. Run python scripts/invoke_live_service.py --skill-id team-intercompany-reconciliation --input-json <request.json> --request-id <request_id>.
5. When the gateway returns HTTP 402, pass WeixinPay-Required unchanged as paymentCode to weixinpay_pay. Preserve the returned out_trade_no.
6. Ask the user to approve the payment. A screenshot, chat message, user assertion, or payment authorization is not proof of payment success; rely only on the verified callback or order-query state.
7. After authorization, repeat the exact same JSON body with python scripts/invoke_live_service.py --skill-id team-intercompany-reconciliation --input-json <request.json> --request-id <request_id> --out-trade-no <out_trade_no>.
8. Release the full workflow output only when the gateway returns HTTP 200 with authorized: true. The gateway verifies the WeChat callback or queries the order and rejects amount, merchant, AppID, body, or Skill mismatches.

异常处理

• 未支付或用户取消: Do not claim payment success and do not release paid content. Keep the request body unchanged and allow the user to retry with a fresh order and request ID.
• 订单关闭或支付码过期: Do not reuse the stale payment code or closed order. Create a fresh order only after repeating the 付费前检查.
• 退款中、已退款或部分退款: Do not deliver or redeliver paid content for the refunded portion. Explain that refund initiation and approval follow the merchant's authorized process, track the refund through the verified WeChat Pay refund state, and revoke fulfillment or prevent duplicate fulfillment where appropriate.
• Distinguish unpaid, canceled, closed, expired, refunding, refunded, and partially refunded states. Never release paid content while an order is unpaid, canceled, closed, refunding, refunded, or expired.
• Preserve out_trade_no, the stable request_id, and the exact request body for idempotent fulfillment. Never fulfill the same verified payment twice, and never persist payment codes in logs.

Use scripts/pay_skill_x402.py only when operating a separate merchant backend. Read pay-skill-deployment.md before deployment or payment troubleshooting. Read publish-cases.md when submitting marketplace examples.

Operating Rules

• Label every material statement as confirmed fact, supported inference, assumption, or open question.
• Cite source file, section, page, message date, ticket, or evidence ID for each important fact.
• Keep a single stable ID for every issue, action, decision, and evidence item across updates.
• Use only these workflow states: draft, awaiting-owner, in-review, approved, in-progress, blocked, closed, superseded.
• Record changes without overwriting prior decisions. Include who changed what, when, why, and which approval applies.
• Minimize sensitive data. Quote only the fragment needed to support the conclusion.
• Ask for approval before any external message, submission, commitment, or irreversible action.

Workflow

1. Create a case header with scope, objective, owner, participating teams, deadline, source set, confidentiality, and success criteria.
2. Build the evidence register first. Deduplicate files, identify version and date, and flag missing, stale, conflicting, or inaccessible evidence.
3. 统一实体对、内部账户、单据、科目、币种、汇率、税码和期间
4. 双向匹配余额与交易，分类单边、金额、期间、汇率、税务、映射和重复差异
5. 指定发起方、对手方、调整或结算方案、截止日和双方确认人并跟踪结平
6. Run the quality gate: verify coverage, source traceability, owner confirmation, dates, dependencies, approval state, sensitive-data handling, and unresolved contradictions.
7. Deliver an executive summary, the core register, decision queue, action register, evidence gaps, approvals required, and a concise handoff message.

Core Register

Use this minimum schema:

差异ID | 实体A/B | 账户/科目 | 单据/期间 | 币种/汇率 | A方金额 | B方金额 | 差额 | 差异类型 | 证据 | 发起/对手负责人 | 方案 | 双方确认 | 抵销/状态

Do not remove source, owner, due-date, status, or approval fields even when the user asks for a shorter view. Create a filtered view instead.

Output Order

1. Executive summary with current risk, blockers, and decisions needed
2. Core register
3. Action and escalation queue
4. Evidence and information gaps
5. Approval queue
6. Change log and next review date

Read team-templates.md before producing a formal team deliverable. Reuse its IDs, registers, approval gate, and handoff format.

Boundaries

• 不得虚构对方余额、确认、协议、汇率或税务处理
• 不得执行日记账、资金结算或合并抵销
• 重大历史差异、关联交易定价、跨境税务和争议确认必须升级授权专业人员

Example Requests

• "对账本月各实体内部往来并分类差异"
• "找出单边、错期、汇差和税务口径问题"
• "生成双方确认、调整、结算和抵销跟踪表"