What the documents look like
Reverse returned-goods inspection handles returned parcels and item grades. It does not handle outbound picking for new orders. The working records come from the WMS returns module, platform after-sales, carrier returns, and the inspection bench. The four document types on this page are the returns inbound order, inspection photos, the grade determination table, and the re-sale listing order. Product-data and selection questions must answer which product record a returned item maps to, which grade determination table governs its selection, and whether it can enter the re-sale listing process. Those answers depend on document subject, object, status, and validity scope.
Two characteristics shape this task. First, the same physical returned item can carry several statuses at once across documents, so a retrieval hit on one document does not settle the status recorded in another. Second, the records update per item and per day, which means a question about a specific return must be checked against the specific order and grade table rather than against a daily aggregate.
A retrieval hit on related material does not mean the return has been authorized for re-sale, and it does not mean the inspection conclusion has taken effect. The model connection and configuration task is to let the question-answering path reach these documents and keep answers inside what the documents state.
Constraints at the model connections step
The question objects are the returns inbound order, inspection photos, grade determination table, and re-sale listing order. Answers must distinguish "grade determined," "pending determination," "listed," and "pending listing." Retrieval is not authorization, and a form that collects values is not a business verification.
Hypothetical paper exercise, used only to show the comparison method: returns inbound order RB-2026-0412 records a returned insulated bottle, return quantity 2, receipt date 12 April 2026, status "pending inspection." Grade determination table DJ-2026-0412 for the same batch records 1 unit as "resellable" and the other unit as "scrap pending review," with the reviewer field blank. Inspection photo TP-0412-03 shows a scratch on the bottle body and carries no handling note. Draft sentence to be checked: "Both bottles in RB-2026-0412 have been determined resellable and a re-sale listing order can be generated directly." The comparison is: the inbound order status is "pending inspection," the grade table marks only 1 unit "resellable," the reviewer field is blank, and the draft expands 1 unit to 2 and skips review. The draft is unsupported.
The AI Proxy dependency applies from V4.17.0. Both the App and an Admin service that reuses App/Service configuration must set AIPROXYAPIENDPOINT and a non-empty AIPROXYAPITOKEN. Missing either causes startup validation failure. Legacy OpenAI environment variables or a single-model custom request address do not replace these two settings. A language model and an index model are the minimum for normal use. Same-vector-model association is limited to the knowledge base and its index model; it does not extend to external systems.
Configuration and implementation checks
The table lists only documented settings or implementation checks tied to this page's documents. The hypothetical trial starting values are exercise values compared against the sample material; they are not official defaults.
| Configuration item | Hypothetical trial starting value and reason | What to compare against |
|---|---|---|
| AIPROXYAPIENDPOINT | Enter the AI Proxy service root address, without appending /v1 or /chat/completions | The actual server root address |
| AIPROXYAPITOKEN | Enter the non-empty administrator token consistent with the server | The server configuration value; an application API key does not substitute |
| Language model capability | Check vision and toolChoice fields against the text input the question needs | The actual input type of the application |
| Index model | Confirm it is enabled and matches the knowledge base vector model identifier | The vector model identifier used by the knowledge base |
| Model status probe | Enable automatic probing with an interval set to an integer between 5 and 60 minutes | The probe panel status and the alert events |
| File parsing concurrency | Check DATASETPARSEMAX_PROCESS and similar values against the queue | The actual parsing queue load |
Retrieval only returns text chunks. It does not perform permission or entity isolation. The probe scope covers only currently enabled system models; disabled models are not probed and produce no history. A probe request retries at most 3 times after a first failure, so a single round attempts at most 4 times, and only 4 failures produce an abnormal result.
Three common errors
- Treating a retrieval hit as authorization. Input the draft sentence with the RB-2026-0412 material. If the answer says a re-sale listing order can be generated directly, compare the inbound order status "pending inspection" and the blank reviewer field; the conclusion is unsupported.
- Expanding a partial determination to the whole batch. Input DJ-2026-0412. If the answer says both units are resellable, compare the table's 1 unit "resellable" and 1 unit "scrap pending review"; both the quantity and the status differ.
- Treating a pending review as an existing permission. Input the blank reviewer field. If the answer says review is complete, compare that the field is empty; this writes a pending verification as confirmed.
How to verify the setup
- Input the hypothetical sample text and the draft sentence. Compare whether the answer restates only 1 unit resellable and 1 unit pending review, and points out the blank reviewer field. The condition is met when the answer preserves that gap.
- Input "Has RB-2026-0412 been listed for re-sale?" Compare whether the answer states that the material contains no re-sale listing order record. The condition is met when the answer does not produce a listing conclusion.
- Input an empty-result continuation, using the paper input [] to check whether the downstream design distinguishes "nothing retrieved" from "determined that no such return exists." The condition is met when the answer does not turn an empty result into a negative conclusion. All three describe expectations only and were not actually executed.