What the documents look like
Near-expiry markdown work tracks the shelf-life stage of stock rather than weighing individual order lines. The working documents are the near-expiry list, the markdown approval, the damage report, and the promotional price tag. Source data comes from POS stock age, store inspection, ERP inventory, and quality-check records, and it updates by day or by shift. For order fulfilment and after-sales answering, the dialogue has to keep three states apart: a batch that appears on the near-expiry list, a batch whose markdown approval is still pending, and a batch already recorded on a damage report. The same physical batch can move through these stages, and one stage does not stand in for another in a reply.
Constraints at the multi-turn prompts step
Multi-turn context comes from the conversation record tied to a chatId. When a non-empty chatId is passed, the system reads the conversation from the database and uses the last element of the messages array as the user question; the remaining messages are ignored. A follow-up about a near-expiry batch therefore has to stay under the same chatId, or the earlier content is not referenced. Memory rounds control how many earlier rounds the AI may reference; a value that is too small may fail to use prior information. A low temperature suits customer service and rule-bound scenarios. Reply format is changed only when a downstream flow needs to read a fixed structure, and choosing json_schema requires filling in the corresponding format requirement.
Hypothetical drill sample: a store inspection record dated 10 March 2026 states "Cold cabinet A, batch 20260309-02, yogurt, 12 units, shelf life to 12 March, entered on the near-expiry list, markdown approval SP-0310-07 status pending review." A proposed copy sentence reads "This batch has been approved for markdown and can be ordered for sale." The comparison is between the proposed sentence and the inspection record: the record states only that the approval status is pending review, and does not state an approval result, so the proposed sentence goes beyond the source text.
Configuration and implementation checks
| Configuration item | Setting relevant to this page | How to check |
|---|---|---|
| Memory rounds | Customer service and knowledge-base Q&A usually keep a small number of history rounds | Check whether the follow-up sits under the same chatId and whether prior content is referenced |
| Temperature | Low is suggested for customer service and rule-bound scenarios | Compare whether the same follow-up reply stays stable at a low value |
| Reply format | Ordinary Q&A keeps the default; change only for a fixed structure | When json_schema is selected, fill in the format requirement and verify the returned structure |
| Multimodal recognition | Requires model support and the corresponding type enabled | Check whether image input is converted into model-readable content |
| Hide AI output | When opened, content is not shown directly and can still pass to a later node | Check whether the downstream node receives that output |
| Thinking configuration | Simple questions can use no thinking; complex questions can use a higher strength | Compare whether switching produces an error |
Three common errors
- Treating pending review as approved. In the sample, approval SP-0310-07 has status pending review, while the proposed sentence says "has been approved for markdown." The input is the proposed sentence and the inspection record; the comparison is how each describes the approval status; the record does not state an approval result.
- Following up across chatIds. The input is the same user's follow-up under a different chatId; the comparison is whether the system retrieves the earlier batch information; under a different chatId the prior content is not referenced.
- Treating retrieval as authorization. The input is a near-expiry list entry returned by retrieval; the comparison is whether the dialogue uses it to execute a markdown or a damage report; a retrieval result does not constitute an approval or an isolation action.
How to verify the setup
- Input the sample inspection record text and the proposed sentence "This batch has been approved for markdown and can be ordered for sale." Compare whether the proposed sentence goes beyond the pending-review status stated in the record. The reply must indicate that the approval result is not stated and remains to be verified.
- Input two follow-up rounds under the same chatId. Compare whether the second round references the batch number from the first round. The reply must show that prior content is referenced.
- Input a paper empty result []. Compare how the downstream node is designed to handle the absence of retrieved content, and check whether it is treated as an empty result. Do not claim that a fabricated rule retrieval necessarily returns empty.
This page addresses only near-expiry markdown handling for order fulfilment and after-sales answering at the multi-turn prompts step. During operations handover, the authorization state of materials, actions, and requests must not be confused with retrieval or form submission.