What the documents look like
Producer export tax processes combine the offset of domestic sales tax with the export refund calculation. This differs from the calculation path used by trading-company export refunds. The practical effect is that a single producer export tax refund declaration detail sheet carries both domestic offset information and export refund information. Export contracts, sales detail ledgers and export customs declarations need to correspond to that sheet period by period. The data updates monthly. During handover, transferring only the current period sheet without the matching contracts and customs declarations leaves the receiving accountant unable to determine whether a given export has already been collected.
The materials in scope are the export tax refund declaration detail sheet, export contracts, sales detail ledgers and export customs declarations. Access control and data isolation must address who can read, write and manage these materials, and which operations or requests remain in a pending authorization state during handover. A pending request is not approval, and an offered option is not execution.
Constraints at the access controls step
Knowledge base permission is a threshold. File-level permission cannot bypass it. When file-level permission is off, file readability matches the knowledge base. When it is on, each file or folder generates a complete permission snapshot, and list, detail and retrieval recall are authenticated against that snapshot item by item. Retrieval recall filters by the files the current member can read, and this applies only when authentication is by current member identity. A scenario that preselects a knowledge base without authentication by member identity does not filter by file-level permission.
A team administrator does not bypass file-level permission. The team owner and system root are treated as having all file permissions. The creator cannot be granted or modified through collaborator configuration, and a submitted collaborator list must include the current creator, otherwise it is rejected. Collaborator configuration uses full-overwrite semantics. Deleting a file is limited to the creator. Under inherited state, modifying or deleting a collaborator that comes from the parent triggers a conflict prompt, and after confirmation the node becomes independent. Closing file-level permission deletes all collaborator configuration for every file and folder under that knowledge base, and this cannot be rolled back.
An external system's authentication does not replace FastGPT resource permission. A relevance score is not a category, entity or permission filter, and a similarity setting does not exclude unrelated business or unauthorized records. Retrieval is not authorization.
Configuration and implementation checks
The table below addresses this page's sample and lists only settings or implementation checks that the official documents describe.
| Configuration or check item | Value or action | Basis and explanation |
|---|---|---|
| Knowledge base file-level permission | Enabled | Only after enabling can single-file collaborators be configured; write operations are rejected while off |
| Sample file collaborators | Submitted list must include the current creator | Full-overwrite semantics; a missing creator is rejected |
| Sample file roles | Read, write or administrator | The creator arises from creation or ownership transfer, not from collaborator configuration |
| Handover request authorization state | Record as pending authorization | Pending review does not show absent operating permission, and does not equal execution |
| Retrieval recall authentication condition | Authenticated by current member identity | A preselected knowledge base without member-identity authentication does not filter by file |
| External system authentication | Verified separately from FastGPT resource permission | An external interface authentication does not replace resource permission |
If the sample needs a number, it is only a hypothetical starting point for this exercise: assume the sample file collaborator list is to submit 3 subjects, including the creator. The reason for choosing 3 is that the sample involves one creator, one receiving accountant and one reviewer. The comparison object is whether the collaborator list returned after submission still contains the creator.
Three common errors
- Treating retrieval relevance as permission isolation. A relevance score does not constitute a category, entity or permission filter, and a similarity setting does not exclude unrelated business or unauthorized records. Retrieval is not authorization.
- Treating a pending handover request as authorized and executing it. In the hypothetical exercise sample, the handover request states: request to transfer administrator permission on the sample file to receiving accountant C, and the request status is pending review. At this point the permission cannot be treated as transferred.
- Directly rewriting a collaborator that comes from the parent under inherited state. The system prompts a conflict, and after confirmation the node automatically becomes independent while the parent permission is not silently rewritten. Treating the parent as already modified causes later checks to be misaligned.
How to verify the setup
The following verification uses a hypothetical exercise sample. Sample material text: "The sample file is a producer export tax refund declaration detail sheet for a producer enterprise, and the creator is tax accountant A. The current collaborators of the sample file are A (administrator) and B (write permission)." One draft sentence to be assessed: "Request to transfer administrator permission on the sample file to receiving accountant C, and the handover request status is pending review."
- Verification one: Input the material text above and the draft sentence, and compare the claimed transfer of administrator permission to C against the collaborator list and request status recorded in the text. The text does not record that permission has been transferred, and the request is pending review. The observable result is that the claimed transfer is not supported and should be recorded as pending verification.
- Verification two: Input the collaborator list to be submitted for the sample file (including creator A, B and C), and compare whether the submitted list contains the current creator. The observable result is that when the list contains A the submission is not rejected; if the submitted list omits A, the system rejects it, and the rejection phenomenon is recorded at that point.
- Verification three: Input a retrieval request authenticated by current member identity, and compare the returned file scope against the files the current member can read. The observable result is that unreadable files are not recalled; if retrieval is not authenticated by member identity, it does not filter by file-level permission, and that unmet condition is recorded. An empty result can be checked against downstream design using the explicit paper input
[], without claiming that a given rule necessarily returns empty.
This page addresses only producer export tax processes, operations permission and handover management, and permission and data isolation. During operations handover, which materials, operations and requests are in which authorization state must be determined, and retrieval or a form must not be treated as authorized execution.