tw-ecom-invoice-void

asgard-ai-platform ｜ 商業與營運 ｜ 原文 ｜ MIT

同期作廢、跨期開折讓的判斷邏輯與 SOP（內文待補）

---
name: "tw-ecom-invoice-void"
description: "在同一雙月期間內作廢台灣電子發票，或為跨期更正開立折讓。當處理會影響發票狀態的退貨 / 退款時使用。初次開立「不要」用這個，請看各加值中心專屬的 skill。STATUS: SKELETON — 內文待補。"
metadata:
  category: "WP-05 台灣創業"
  domain: "ecommerce-tw"
  layer: "invoice"
  related_mcps: []
  related_skills: ["tw-einvoice-guide", "tw-ecom-invoice-ezpay", "tw-ecom-payment-dispute"]
  last_verified: "2026-04"
  status: "skeleton"
  tags: ["taiwan", "e-invoice", "void", "allowance"]
---

# 發票作廢與折讓

> **STATUS: SKELETON**：內文待補。

## 何時使用這個 skill

- 退貨 / 退款發生在同一雙月期間內 → 作廢
- 退貨 / 退款跨越雙月界線 → 折讓
- 除錯退款後發票狀態不一致
- 建立作廢 / 折讓的 SOP

## 何時「不要」使用

- 初次開立 → 開立層的 skill
- 對報稅的影響 → `tw-tax-basics`

## 核心概念

TODO: 作廢 vs 折讓、雙月界線、會計上的影響。
NOTE (填充時): 此 skill 只寫「選哪條路」的決策邏輯，不重複 API 呼叫細節。
`tw-ecom-invoice-ezpay` 已有完整的 void_invoice / issue_allowance / trigger_allowance 步驟；
`tw-ecom-invoice-universalec` 同理。此 skill 的 Implementation guidance 應只提供判斷框架，
並用 "→ see tw-ecom-invoice-ezpay / -universalec" 指向 API 層。

## 決策樹

TODO: 依退款日期 vs 開立日期 → 作廢或折讓。

## 實作指引

TODO: 決策路徑後的 SOP（accounting entries, customer notification, 字軌影響）。
不重複 void_invoice / issue_allowance / trigger_allowance 的 API 參數 — 那些在 ezpay/universalec skill。

## 常見陷阱

TODO: 5-6 個陷阱（邊界差一、字軌保留、對獎失效、折讓編號）。

## IRON LAW

TODO.

## 輸出格式

TODO.

## 相關

- `tw-ecom-invoice-ezpay`
- `tw-ecom-payment-dispute`

_Last verified: 2026-04_

---
name: "tw-ecom-invoice-void"
description: "Void Taiwan e-invoices within the same bimonthly window, or issue allowances (折讓) for cross-period corrections. Use when handling returns / refunds that affect invoice state. Do NOT use for initial issuance — see the 加值中心-specific skills. STATUS: SKELETON — body pending."
metadata:
  category: "WP-05 台灣創業"
  domain: "ecommerce-tw"
  layer: "invoice"
  related_mcps: []
  related_skills: ["tw-einvoice-guide", "tw-ecom-invoice-ezpay", "tw-ecom-payment-dispute"]
  last_verified: "2026-04"
  status: "skeleton"
  tags: ["taiwan", "e-invoice", "void", "allowance"]
---

# Invoice Void & Allowance (作廢 / 折讓)

> **STATUS: SKELETON** — body pending.

## When to use this skill

- A return / refund occurs within same bimonthly → void
- A return / refund crosses bimonthly boundary → 折讓
- Debugging invoice state inconsistency post-refund
- Building void / allowance SOP

## Do NOT use when

- Initial issuance → issuance-layer skill
- Tax filing impact → `tw-tax-basics`

## Core concepts

TODO: void vs 折讓, bimonthly boundary, accounting implications.
NOTE (填充時): 此 skill 只寫「選哪條路」的決策邏輯，不重複 API 呼叫細節。
`tw-ecom-invoice-ezpay` 已有完整的 void_invoice / issue_allowance / trigger_allowance 步驟；
`tw-ecom-invoice-universalec` 同理。此 skill 的 Implementation guidance 應只提供判斷框架，
並用 "→ see tw-ecom-invoice-ezpay / -universalec" 指向 API 層。

## Decision tree

TODO: given refund date vs issuance date → void or 折讓.

## Implementation guidance

TODO: 決策路徑後的 SOP（accounting entries, customer notification, 字軌影響）。
不重複 void_invoice / issue_allowance / trigger_allowance 的 API 參數 — 那些在 ezpay/universalec skill。

## Gotchas

TODO: 5-6 pitfalls (boundary off-by-one, 字軌 reservation, lottery invalidation, allowance numbering).

## IRON LAW

TODO.

## Output Format

TODO.

## Related

- `tw-ecom-invoice-ezpay`
- `tw-ecom-payment-dispute`

_Last verified: 2026-04_