What the documents look like
Near-expiry markdown handling manages the shelf-life of stock batches rather than weighing individual order lines. The working materials are expiry-approach lists, markdown approval forms, write-off sheets and promotional shelf labels. These come from POS stock-age data, store inspection rounds, ERP inventory and quality-check records, and they refresh by day or by shift.
For order fulfilment and after-sales answering, the practical question is which of those materials already carries a decision and which does not. A markdown approval form that has been signed records an approval. A write-off sheet that is still open records an unfinished step. A promotional label describes a price display, not a completed sale. The shared conversation entry does not read stock age and does not execute markdown approval, so a link that opens a chat cannot be treated as evidence that a batch may be sold at a reduced price.
Three steps consume most of the working time: identifying near-expiry batches, approving markdowns, and isolating unsellable goods. When a handover happens, the current stage of each material has to be stated, because the chat tool itself holds none of that state.
Constraints at the shared access step
The no-login window is created from the application detail page under publishing channels. The system generates a link, and copying it makes it usable. The link identifier serves access only; it is not an authorisation credential for markdown approval or write-off registration.
Expiry time, QPM, points cap and identity verification are configured for the intended scope, and some parameters are supported only in the commercial edition. Identity verification takes the root address of a POST request. Initialisation, conversation start and conversation end each send a request to a specific interface under that address. The server returns a success flag and a uid. The uid must be a string that excludes certain characters and does not exceed 255 bytes in length, and it is used to pull and save conversation records.
The anonymous path depends on the same device and the same browser. It allows pulling records from the last 30 days, limited to 20 entries. Switching device or clearing browser cache loses those records.
Hypothetical drill sample. A store loss-prevention administrator produces an expiry-approach list after a shift inspection. The list reads: "Shift of 10 June 2025, cold cabinet zone A, yogurt batch Y-0610, shelf life to 13 June 2025, inspection conclusion: markdown permitted, markdown approval form SP-0610-03 signed by the store manager." A drafted reply sentence reads: "This batch has been approved for markdown, so in the shared conversation answer the customer directly that purchase at the reduced price is possible." The authorisation boundary here is that the approval form carries a signature, while the conversation entry is not connected to the inventory system. The drafted sentence turns an approval status into a sales commitment.
Configuration and implementation checks
The values below are starting points for this drill, used for comparison against later observations. They are not official defaults.
| Setting or check | Hypothetical starting point for this drill | Reason and comparison object |
|---|---|---|
| Expiry time | Set to 20 June 2025 | Covers the shift cycle of this drill; compare with the list date of 10 June |
| QPM | No specific number entered | Set according to actual access scope; compare against the official parameter description |
| Points cap | No specific number entered | Charges fall to the team owning the application; compare against usage observations |
| Identity verification root address | Internal authentication service root address | Root address only; compare against the official POST interface format |
| authToken | Generated and appended by the internal system | Compare against the uid length and character restrictions |
| Conversation record scope | Last 30 days, 20 entries | Compare against the official no-login window description |
Identity verification and the points cap are subject to edition limits. Check the actual edition before configuring, and do not assume switches or automatic synchronisation that the documents do not describe.
Three common errors
- Treating the link identifier as business authorisation. The input is the share link together with markdown approval form SP-0610-03. The comparison is between the form's signature status and the link's usable status. The observable result is whether the two are conflated. A usable link does not mean the markdown approval is in force.
- Treating a success response from identity verification as an inventory or permission check. The input is the success flag and uid returned by the authentication interface. The comparison is between the uid format restrictions and any business permission field. The observable result is whether the interface performed identity recognition only. Retrieval and similarity scores do not carry permission or entity isolation.
- Treating a pending or signed item as executed. The input is the signature record on the markdown approval form and the status of the write-off sheet. The comparison is the value of the same field for the same batch. The observable result is whether approval signature and write-off registration sit at the same stage. A signature is not a completed write-off.
How to verify the setup
- Check against the hypothetical sample text. The input is the expiry-approach list text and the drafted reply sentence. The comparison is whether the drafted sentence goes beyond the fact that the approval form is signed. The observable result is whether the sentence presents an approval status as a sales commitment that can be made to a customer. If it goes beyond, the sentence is unsupported.
- Check against the authentication interface response. The input is a success flag of true and a uid that excludes the specified characters and does not exceed 255 bytes. The comparison is whether the uid meets the format requirement. The observable result is whether authentication permits the user to continue. If the success flag is not true, the message or msg is shown and the outcome is recorded as an identity error.
- Check empty-result handling. The input is an explicit paper input of []. The comparison is whether the downstream conversation design has a way to receive an empty reference. The observable result is whether any unstated automatic business action appears. No claim is made that a fictional rule search returns []. Libraries using different vector models cannot be associated together. Check the identifiers first, exclude those that do not match, and record what is observed rather than inferring missed recall or redundant results.