What the documents look like
Creator commission settlement and deduction happen after a sale closes. The work centers on checking valid promotion orders, removing commission tied to refunds, and completing invoicing and payment. Compared with dedicated creator sessions, settlement depends on four sources: the Selected Alliance backend, order after-sales data, the finance system, and creator contracts. Updates arrive weekly or monthly. In store service and internal training, three roles hand work across: finance settlement, Selected Alliance operations, and creator business affairs. They exchange four document types: commission setting records, settlement statements, refund commission deduction details, and invoices.
The interactive forms step collects information and routes choices. The nodes themselves only gather submitted values and pass them to later nodes. Business database writes, approval, and external synchronization need separate implementation.
Constraints at the interactive forms step
The form input node enters an interaction state when triggered, records the workflow state, and continues after the user completes interaction. The user selection node evaluates the user's choice and executes the corresponding branch. Both are user interaction nodes, can be added repeatedly, and trigger execution. Field validation, business approval, write-back, and batch operations are implemented in external systems or later nodes as needed. The nodes do not carry a business database function.
Hypothetical paper exercise: a store submits an internal training handover request. The source material reads: "Settlement statement number JS-2024-07-018, settlement period July 2024, commission setting record for creator A shows a commission rate of 15%, refund commission deduction details show order 20240712-003 was refunded with the corresponding commission deducted, and the invoice has not yet been issued." The draft sentence to be judged is: "This settlement statement has completed invoicing and payment." The invoicing and payment status in that draft sentence is not stated in the source material and remains unsupported.
Configuration and implementation checks
| Configuration item | Setting on this page | Implementation check |
|---|---|---|
| Form input node | Enters interaction state on trigger, collects submitted information and passes it to later nodes | Check whether the required-information list covers settlement statement number, settlement period, and creator identifier |
| User selection node | Executes a branch based on the user's choice | Check whether branch conditions distinguish "materials complete" from "materials pending" |
| Interaction state | Records workflow state and waits for the user to complete interaction | Check whether the workflow continues downward after interaction completes |
| Required-information check | Lists information this task cannot omit | Test the missing-item behavior and the completed-item behavior separately |
| Downstream division of labor | Field validation, business approval, write-back, and batch operations are implemented in external systems or later nodes | Check whether form submission triggers an external system write or approval action |
Three common errors
- Treating form submission as completed business approval. The form input node only collects submitted information and passes it to later nodes; approval requires an external system or a later node. Judging "settlement statement number JS-2024-07-018 submitted" as "approval completed" mistakes a collection action for an approval action.
- Treating a user selection branch as a business data selector. The user selection node executes a branch based on the user's choice and does not act as a personnel directory or business data selector. Reading the branch option "materials complete" as automatic verification of material authenticity goes beyond the node documentation.
- Judging an unstated invoicing and payment status as completed. In the hypothetical sample, the source material contains only the settlement statement number, settlement period, commission rate, refund deduction details, and the fact that the invoice has not been issued. The draft sentence "this settlement statement has completed invoicing and payment" lacks corresponding evidence. An unstated status is recorded as unsupported and cannot be judged as completed or as negated.
How to verify the setup
- Input the hypothetical source material and the draft sentence "this settlement statement has completed invoicing and payment," then compare whether the source material states the invoicing and payment status. The source material shows only that the invoice has not been issued and does not show payment status. The expected observation is that the draft sentence is judged unsupported, and it can be re-judged only after invoicing records and payment evidence are added.
- Input the hypothetical line "refund commission deduction details show order 20240712-003 was refunded with the corresponding commission deducted," then compare whether those details belong to the same settlement period and the same creator as settlement statement number JS-2024-07-018. The expected observation is that when the period matches and the creator identifier matches, the refund deduction details can serve as a checking basis for that settlement statement; when the period or creator identifier does not match, the result is recorded as pending verification.
- Input the hypothetical line "the invoice has not yet been issued," then compare whether that status contradicts the draft sentence "invoicing and payment completed." The expected observation is that the same settlement statement, same period, and same invoice field carrying mutually exclusive values is judged contradictory; when the source material does not state the invoice status, the result is judged unsupported. For empty-result handling, a clearly written paper input
[]can be used to check downstream design; this does not assert that a retrieval will necessarily return an empty array.