What the documents look like
Creator commission settlement and commission deduction sit after a sale has closed. The objects being checked are the orders that count as valid promotion and the commission that must be recovered once a refund occurs. The main materials come from the Selected Alliance backend, order after-sales data, the finance system, and creator contracts. The daily documents include commission setting records, settlement statements, refund deduction details, and invoices. Workflow routing handles the order in which these materials move through order fulfilment and after-sales question handling: first confirm which order falls inside the settlement scope, then judge whether after-sales handling triggers a deduction, and finally hand the result to the invoicing and payment stage. Materials update weekly or monthly, so routing is designed around batch checking rather than per-order real-time linkage.
Two features of this category shape the routing task. Settlement happens after the transaction, so the unit of work is a completed order plus its after-sales state, not a live promotion event. Deduction is a recovery action tied to a refund, so the same order can appear in a settlement statement and in a refund deduction detail with different values for the same commission field. Routing must keep those two documents connected to the same order, period, and field.
Constraints at the workflow routing step
The Form Input node is a user interaction node. When it triggers, the conversation enters an interaction state, the workflow state is recorded, and after the user fills in the required information and submits, the node passes the collected information to later nodes. The User Selection node is also a user interaction node. When the user makes a choice, the node judges that choice and executes the corresponding branch. Interaction waiting, state recording, and hiding the dialog box are documented behaviours of these nodes. The documents do not describe a control switch for those behaviours, a submission count limit, or automatic judgement capability.
Retrieval results do not constitute authorization. Commission amounts, deduction scope, and payment conditions need to be checked by a business system or by staff against the contract and the statement. The nodes collect and pass information; they do not verify it.
Hypothetical paper test case: a settlement statement reads "Creator A, settlement period June 2026, total commission on valid orders RMB 8,000, of which order A was refunded on 20 June 2026 and the corresponding commission of RMB 400 has not yet been deducted." A refund deduction detail reads "Order A, refund completion date 20 June 2026, commission to be deducted RMB 400, status is pending deduction." A handover request awaiting a decision reads "Please submit Creator A's June commission for payment at RMB 8,000." When checking, compare the statement total with the deduction detail: same order A, same refund completion date, same commission field, the statement shows no deduction while the detail shows pending deduction. The two documents give inconsistent values for the same field. The request lacks a deduction basis and is pending verification.
Configuration and implementation checks
| Configuration item | Use on this page | Basis and checking method |
|---|---|---|
| Form Input node | Collect settlement period, creator identifier, order number | Official documentation states submitted information is passed to later nodes; check that required fields match the passed object |
| User Selection node | Ask operations to choose a handling branch for a deduction dispute | Official documentation states the chosen branch is executed; verify each branch connection |
| Interaction state check | Confirm the interaction state is entered and recorded on trigger | Official documentation describes this as node behaviour; no separate global state switch is set |
| Output handover check | Pass collected information to a later judgement or interface node | Compare each node output against the downstream input field |
| External action division | Order writes, document backfill, external status synchronisation | Official documentation does not describe automatic execution; a business interface or later process must be connected separately |
The hypothetical trial starting values for this page are the statement total of RMB 8,000 and the pending deduction of RMB 400. These were selected because the sample text states both figures directly. The comparison object is the amount to be deducted in the deduction detail and whether the statement has already deducted it. This does not indicate an official default value.
Three common errors
- Treating form submission as an executed deduction. In the sample, submission occurs at the collection stage, the detail status is pending deduction, and the deduction required by the payment request is not complete. The input is the statement and the detail; the compared field is the commission value for the same order; an observed mismatch means the condition is not met.
- Treating the result of a user selection branch as approval. In the sample, the operations choice only determines the later path. The documentation does not state that a choice equals approval. The input is the selection record and the authorization material; the comparison is whether a signed or approved document exists; when it is absent, record the matter as pending verification.
- Treating a retrieval hit as the right to read that creator's statement. The input is the retrieval return and the access scope; the comparison is the subject and the authorization boundary. Retrieval only provides candidate content and does not constitute a permission decision.
How to verify the setup
- Run the routing with the sample statement text and deduction detail text. The input is the two texts. Compare the refund completion date and the commission field for the same order A. If the statement shows no deduction while the detail shows pending deduction, the output should stop at pending verification and retain the gap.
- Run the user selection branch with the sample handover request. The input is the request text and the selection record. Compare whether a deduction basis or approval material exists. If neither is provided, the branch must not proceed to payment submission.
- Check empty-result handover with the paper input []. The input is an empty list. Compare whether the downstream node handles it through an empty-value branch. If the downstream still requires populated fields, record this as a design gap. Do not claim that this input necessarily returns an empty result.
This page addresses only creator commission settlement and deduction, order fulfilment and after-sales question handling, and workflow routing. When operations hand over materials, actions, and requests, the authorization state of each must be clear. Retrieval and form submission cannot be treated as authorized execution.