tw-ecom-invoice-void

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 (when filling in): This skill only writes the decision logic for "which path to choose", and does not repeat API call details. tw-ecom-invoice-ezpay Already has complete void_invoice / issue_allowance / trigger_allowance steps; tw-ecom-invoice-universalec Likewise. The Implementation guidance of this skill should only provide the judgment framework, and use "→ see tw-ecom-invoice-ezpay / -universalec" to point to the API layer.

Decision tree

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

Implementation guidance

TODO: SOP after the decision path (accounting entries, customer notification, 字軌 impact). Do not repeat the API parameters of void_invoice / issue_allowance / trigger_allowance — those are in the ezpay/universalec skill.

Gotchas

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

IRON LAW

TODO.

Output Format