What the documents look like
Producer export tax processes combine the offset of domestic-sale tax against export refund in a single calculation. This differs from the calculation path used by trading-company export refund work. The main data sources are the electronic tax bureau, ERP sales records, customs electronic information, and financial ledgers. The routine documents are the exemption, offset and refund declaration detail schedule; export contracts; the sales detail ledger; and export customs declarations. Data updates monthly. Operating reporting and exception review revolve around three time-consuming steps: aggregating self-produced exports, calculating the exemption, offset and refund, and handling free-on-board price differences.
Workflow routing in this setting has a narrow job. It arranges material collection, difference comparison and exception logging into a reusable execution order, and it separates what a node does from what a person checks and what requires a separate system connection. The form input node enters an interaction state when triggered, records workflow state, collects required information, and passes that information to later nodes after submission. The user selection node also enters an interaction state, and after the user makes a choice it executes the corresponding "yes" branch. Interaction state is recorded by the node itself. No separate global state-recording switch is documented. Collected values must be passed explicitly to later retrieval, judgment or interface nodes, and each output must be compared against its input.
Constraints at the workflow routing step
A form submission is not an authorization to act. The sample below shows collected fields and a handover request whose authorization boundary is not stated. Retrieval and relevance scores do not perform permission or entity isolation. Libraries built on different vector models cannot be associated together; identifiers must be checked first and non-matching items excluded. Order writes, document backfill and external status synchronization require a separate business interface or a later process. A pending request is not an approval, and an offered option is not execution.
Hypothetical paper exercise sample: a producer export enterprise submits an exemption, offset and refund declaration detail schedule showing export sales of RMB 1.2 million for the period May 2024. The attached export contract states FOB as the trade term. The sales detail ledger for the same period records export sales of RMB 1.18 million. A handover request states: "Please complete this period's exemption, offset and refund declaration based on the above materials and synchronize it to the electronic tax bureau." The request does not state an authorization boundary, and the material difference is not explained. This sample is a paper exercise for comparison only. No declaration, synchronization or approval has occurred.
Configuration and implementation checks
| Configuration item | Use on this page | Comparison method |
|---|---|---|
| Form input node | Collect period, export sales amount and trade term fields | After submission, compare each field against the source text |
| User selection node | Branch on how the difference is handled | Check the selected branch against its downstream node connections |
| Output handoff | Pass collected information to later retrieval or judgment nodes | Compare downstream input against form output |
| Interaction state | Node records state after triggering and waits for submission | Observe whether the dialogue enters the interaction state |
| External action split | Declaration submission and synchronization are handled by a business interface | Check interface calls against authorization records |
| Retrieval scope | Limit to target materials with access rights | Check library identifiers and vector model identifiers |
No default values, limits or units are documented for these items in the supplied material. The table lists documented node behavior and implementation checks, not tunable settings.
Three common errors
- Treating a form submission as authorized execution. In the sample, the handover request states no authorization boundary. Collecting the period and sales amount through a form does not mean the declaration submission or electronic tax bureau synchronization has been authorized.
- Treating retrieval or a relevance score as entity isolation. The sample materials come from different sources. A retrieval hit does not replace checking the subject, period and field. Libraries on different vector models cannot be associated together.
- Treating an unexplained difference as a contradiction. In the sample, RMB 1.2 million and RMB 1.18 million come from the declaration schedule and the sales detail ledger respectively. The reason for the difference is not stated, so it can only be recorded as pending verification. It cannot be declared a filing error.
How to verify the setup
- Input the sample source text and the handover request. Compare the period, sales amount and trade term collected by the form against the materials. When they match, the condition is met. When they do not match, record the differing fields.
- Input the two amounts, RMB 1.2 million and RMB 1.18 million. Compare whether they share the same subject, the same period and the same field. A contradiction requires mutually exclusive values in the same field. Otherwise, record the item as unsupported.
- Input the sample handover request. Compare whether the request states an authorization scope and an execution target. When these are absent, record the authorization gap and do not execute the declaration submission or external synchronization.
These steps describe what to compare and what to expect. They do not report a completed test, a deployment or an approval. Where the sample lacks a stated authorization boundary or a stated reason for the amount difference, that evidence remains missing.