The order may have been confirmed twice on the system, resulting in duplicate quantities being recorded as despatched. The issue was picked up while completing the service level report. The user found 3 delivery notes relating to the same order.
The customer thankfully only received the order once so we will credit the additional delivery note to rectify our records.
How did this has happen and advise whether it is possible for the same order to be confirmed twice within the system?
Also, please identify what may have caused the duplicate confirmation and preventative measures.
Yes, it is technically possible for the same sales order to be confirmed (despatched) more than once in Access Supply Chain, and the pattern of despatch note numbers you see is consistent with that. Below is how the confirm/despatch flow works and where the gap is.
How confirmation and despatch numbering work
Confirming a delivery runs the CONFDEL section of DSPINV.cbl. Its own comments describe exactly what "confirm" does: it prepares the despatch, lets the user amend the quantities, then updates the customer‑order record and writes a "to‑be‑invoiced" (TBI) record.
The critical side effect is that each confirmation adds the processed quantity onto the order's delivered quantity:
So if an order is confirmed twice, COR-QTY-DELIVERED (the COR_QTY_DELI column) is incremented twice.
Despatch note numbers themselves are allocated separately, at print time, by GETNO calling the stored procedure ASC_API_GET_NEXT_NUM_S for number type "DN" (despatch note).
Each call hands back the next sequential number. Importantly, CISDSP/CCSDSP group order lines by order type and get a separate despatch note number per order type on the same run.
One of the order lines clearly sits on a different despatch note from the rest of the order, which is a legitimate order‑type split; those two consecutive numbers are almost certainly on one confirmation run. The third number, being a subsequent load of numbers later, points to a second, separate despatch run against the same order.
Why a second confirmation can happen
There is no persistent "this order has already been confirmed" block in the CONFDEL loop. The only per‑line guard is a skip when the current delivery quantity is zero and after a successful confirm the delivery quantity is zeroed on the order record.
However, when the order is re‑opened for despatch, the quantity offered to despatch again is driven by what is still allocated/outstanding (COR-QTY-ORDERED − COR-QTY-DELIVERED), and in auto‑despatch / "include items to despatch" modes it defaults the despatch quantity to the outstanding amount. So if any outstanding quantity remained (or the operator manually re‑keyed quantities), a second confirmation will process and produce another TBI record, another despatch note number, and another increment to COR-QTY-DELIVERED.
The concurrency gap
The order record is only locked for the initial on‑screen display, via DB-COR-BROWSE-NEXT-LOCK (change J23229 "Hold on locked COR records before displaying"). The actual update loop in CONFDEL re‑reads the lines with an unlocked browse.
This means two operators (or two sessions) confirming the same order at nearly the same time are not mutually excluded during the update phase. Each run independently reads the order, adds its quantity to COR-QTY-DELIVERED, writes its own TBI record and pulls its own despatch note number from GETNO.
Most likely cause
Given the evidence (two consecutive numbers from an order‑type split, plus a third number a few sequence values later), the order was most probably confirmed for despatch twice either:
the same order was re‑opened and confirmed again because outstanding/allocated quantity was still present, or
two users/sessions confirmed it near‑simultaneously (the update loop does not hold an order lock).