otif-analysislisted

# OTIF Analysis Most "delivery problems" are measurement problems first. Before recommending any operational fix, establish what the honest number is and which definition choices inflate the reported one. ## Required data Order-level rows with: `order_id`, `requested_delivery_date` (what the customer asked for), `promised_delivery_date` (what was confirmed), `actual_delivery_date`, completeness info (lines ordered vs delivered, or qty ordered vs delivered), and a status/cancelled flag. Useful cuts: carrier, region, customer, product family. If `requested_delivery_date` is missing, say so explicitly: only the promised-date rungs are computable, and the analysis cannot see sales-padding. Recommend capturing the requested date going forward. ## Workflow 1. **Validate before computing.** Count duplicated order rows; flag impossible dates (actual before order date); count cancelled orders and state how they will be treated. Report these counts in the output - an audit that silently cleans data is not an audit. 2. **Compute the metric ladder** on the same population, strictest last: - L1: on-time vs promised date, with the tolerance window currently in use (ask what it is; if unknown, show +3 days and label it) - L2: on-time vs promised, zero tolerance - L3: on-time vs *requested*, zero tolerance - L4: **OTIF** = on-time vs requested AND order complete (all lines / full qty). In-full is judged at order level - a 9-of-10-lines delivery is not 90% on-time, it is one