OTIF calculation: OTIF क्या है, फ़ॉर्मूला और कैलकुलेटर
OTIF (On Time In Full, इसे DIFOT भी कहते हैं) कुल की गई डिलीवरी में से उन डिलीवरी का हिस्सा है जो समय पर और पूरी मात्रा में पहुँचीं: समय पर और पूरी मात्रा में हुई डिलीवरी ÷ की गई डिलीवरी × 100, ग्राहक द्वारा रद्द ऑर्डर छोड़कर। संख्या तीन चुनावों पर निर्भर है जो उसके साथ लिखे जाने चाहिए: क्या “समय पर” गिना जाएगा (उसी दिन, बुक की गई विंडो या ± घंटे, और जल्दी डिलीवरी गिनी जाए या नहीं), गिनती लाइन के हिसाब से है या ऑर्डर के हिसाब से, और मात्रा की कौन-सी टॉलरेंस लगेगी। यह समय पर % × पूरी मात्रा % नहीं है: नीचे के उदाहरण रिकॉर्ड में 50.0% × 50.0% = 25.0% बनता है, पर OTIF 16.7% है। भारत में सड़क से माल ढुलाई पर देरी की क़ानूनी देयता goods forwarding note में आपसी सहमति से लिखी अवधि से जुड़ी है (Carriage by Road Act, 2007 की धारा 10(2)), ख़रीदार की डिलीवरी विंडो से नहीं। Logistivo इस गणना का कच्चा माल हर लोड पर रखता है: डिलीवरी की तारीख़, ETA और हर स्टेटस बदलाव का तारीख़-समय वाला इतिहास, ड्राइवर द्वारा ऐप में दर्ज बदलाव सहित।
स्रोत: ASCM · India Code (भारत सरकार) · PRS Legislative Research · legislation.gov.uk · संयुक्त राष्ट्र · VDI · Wikipedia (en).
डेटा अंतिम बार अपडेट:
.
डिलीवरी रिकॉर्ड
डिलीवरी रिकॉर्ड — अपनी डिलीवरी टाइप या पेस्ट करें, परिभाषा चुनें और देखें कि कौन-सी डिलीवरी OTIF स्कोर गिराती हैं।
गणना सिर्फ़ आपके ब्राउज़र में होती है: रिकॉर्ड कभी किसी सर्वर पर भेजा या सहेजा नहीं जाता।
यह कैलकुलेटर डिलीवरी की विश्वसनीयता (समय और मात्रा) मापता है। दस्तावेज़, क्षति और स्टॉक उपलब्धता अलग KPI हैं, जो शब्दावली में दिए गए हैं।
ऑर्डर रेफ़. — ऑर्डर या लोड का रेफ़रेंस। ऑर्डर के हिसाब से गिनने पर एक ही रेफ़रेंस वाली लाइनें एक ऑर्डर बनाती हैं।
लाइन — वैकल्पिक: ऑर्डर लाइन नंबर।
वादा / शुरू — वादा किया गया समय या बुक की गई विंडो की शुरुआत, जैसे 14/09/2026 08:00; पूरी विंडो एक ही सेल में भी लिख सकते हैं: 14/09/2026 08:00-12:00।
विंडो का अंत — वैकल्पिक: विंडो उसी दिन बंद होती हो तो सिर्फ़ समय (12:00), वरना तारीख़ और समय।
डिलीवर हुआ — जब माल कंसाइनी के हवाले किया गया, उसकी तारीख़ और समय। ख़ाली = डिलीवरी अभी बाक़ी।
ऑर्डर — ऑर्डर में पक्की मात्रा (पेटी, पैलेट या यूनिट — डिलीवर मात्रा वाली ही इकाई)।
डिलीवर — प्राप्त मात्रा। अगर लाइन कई खेपों में आई तो कुल मात्रा, आख़िरी खेप के समय के साथ।
चुनी जा सकने वाली परिभाषाएँ
समय पर तब — विंडो में — डिलीवरी समय पर है अगर असल समय बुक की गई विंडो की शुरुआत और अंत के बीच पड़ता है (दोनों सिरे शामिल)। अंत के बाद देरी है, शुरुआत से पहले जल्दी। अगर सिर्फ़ समय दिया हो और विंडो का अंत न हो तो विंडो वही एक सटीक समय है; सिर्फ़ तारीख़ हो तो विंडो पूरा दिन है।
समय पर तब — उसी दिन — डिलीवरी समय पर है अगर असल तारीख़ वादे वाला दिन (या विंडो के दिनों में से एक) है। दिन का समय नहीं गिना जाता: अगला दिन देरी है, पिछला दिन जल्दी।
समय पर तब — ± घंटे — वादा की गई विंडो (या वादे का समय) दोनों तरफ़ N घंटे बढ़ा दी जाती है। इस दायरे के बाहर डिलीवरी देरी से या जल्दी मानी जाती है।
N घंटे — 2 घंटे की शुरुआती वैल्यू सिर्फ़ नियम आज़माने के लिए है: अपने कॉन्ट्रैक्ट या SLA में लिखा दायरा ही रखें।
जल्दी डिलीवरी — विफलता है — विंडो खुलने से पहले (या दायरे से पहले) की डिलीवरी समय की विफलता है, देरी की तरह।
जल्दी डिलीवरी — समय पर गिनी जाए — विंडो से पहले की डिलीवरी समय पर गिनी जाती है: ग्राहक की अनुरोधित तारीख़ के मुक़ाबले SCOR मेट्रिक RL.3.59 का “उस तारीख़ पर या उससे पहले” वाला मापदंड।
गिनती का आधार — लाइन — रिकॉर्ड की हर पंक्ति एक इकाई है: OTIF उन पंक्तियों का हिस्सा है जो समय पर और पूरी मात्रा में पहुँचीं।
गिनती का आधार — ऑर्डर — एक ही रेफ़रेंस वाली पंक्तियाँ एक ऑर्डर बनाती हैं। ऑर्डर तभी समय पर है जब उसकी सारी लाइनें समय पर हों, और तभी पूरा है जब सारी लाइनें पूरी हों (सबसे कड़ा रूप, SCOR के परफ़ेक्ट ऑर्डर RL.1.1 जैसा)। अगर कोई लाइन खुली या पढ़ी न जा सकने वाली हो तो पूरा ऑर्डर गणना से बाहर रहता है।
ज़्यादा डिलीवरी — विफलता है — टॉलरेंस से ऊपर की मात्रा “पूरी” नहीं मानी जाती: SCOR RL.2.1 के अनुसार कोई अतिरिक्त आइटम नहीं दिया जाना चाहिए।
ज़्यादा डिलीवरी — पूरी मानी जाए — टॉलरेंस से ऊपर की मात्रा को पूरी माना जाता है — कुछ कॉन्ट्रैक्ट ऐसा करते हैं, जो SCOR की परिभाषा से अलग है।
टॉलरेंस — डिलीवरी “कम” है अगर डिलीवर मात्रा ऑर्डर × (1 − टॉलरेंस) से कम हो, और “ज़्यादा” है अगर ऑर्डर × (1 + टॉलरेंस) से ऊपर हो। कैलकुलेटर 0% से शुरू होता है: यह इस टूल की सेटिंग है, कोई मानक नहीं। SCOR “आपसी सहमति वाली टॉलरेंस” की बात करता है।
फ़ॉर्मूले
OTIF % — समय पर और पूरी मात्रा में हुई डिलीवरी ÷ गिनी गई डिलीवरी × 100 — SCOR RL.1.1 (कुल परफ़ेक्ट ऑर्डर ÷ कुल ऑर्डर × 100%); OTIF की आम परिभाषा डिलीवरी, ऑर्डर या ऑर्डर लाइन के हिसाब से गिनती है।
समय पर (OTD) % — समय पर हुई डिलीवरी ÷ गिनी गई डिलीवरी × 100 — SCOR RL.2.2: मूल कमिटमेंट तारीख़ पर पहुँचे ऑर्डर ÷ डिलीवर हुए ऑर्डर × 100%; मात्रा का कोई तत्व नहीं।
पूरी मात्रा % — पूरी मात्रा में हुई डिलीवरी ÷ गिनी गई डिलीवरी × 100 — SCOR RL.2.1: पूरे डिलीवर हुए ऑर्डर ÷ डिलीवर हुए ऑर्डर × 100%; समय का कोई तत्व नहीं।
समय पर × पूरी मात्रा — OTIF के बराबर तभी, जब देरी और कमी डिलीवरी पर एक-दूसरे से स्वतंत्र रूप से पड़ें — गणित; उदाहरण रिकॉर्ड में 50.0% × 50.0% = 25.0%, जबकि OTIF 16.7% है।
गिनती की इकाई — डिलीवरी, लाइन या ऑर्डर — कभी मात्रा नहीं — कुल मात्रा के हिस्से पर OTIF निकालना “पूरी मात्रा” के सिद्धांत के ख़िलाफ़ है (Wikipedia, DIFOT)।
पत्तियाँ: हर डिलीवरी ठीक एक में
OTIF — समय पर और पूरी मात्रा में।
सिर्फ़ देरी — देरी से, मात्रा सही।
सिर्फ़ जल्दी — जल्दी (जब जल्दी को विफलता माना गया हो), मात्रा सही।
सिर्फ़ कम मात्रा — समय पर, पर मात्रा टॉलरेंस से कम।
सिर्फ़ ज़्यादा मात्रा — समय पर, पर मात्रा टॉलरेंस से ऊपर (जब ज़्यादा डिलीवरी को विफलता माना गया हो)।
समय और मात्रा दोनों — समय की विफलता और मात्रा की विफलता एक साथ (देरी + कम, देरी + ज़्यादा, जल्दी + कम, जल्दी + ज़्यादा)। छहों पत्तियों का जोड़ हमेशा गिनी गई डिलीवरी के बराबर होता है।
गणना से बाहर रखी गई पंक्तियाँ
खुली — असल डिलीवरी अभी नहीं हुई: SCOR डिलीवर हो चुके ऑर्डरों से भाग देता है, इसलिए जो डिलीवरी हुई ही नहीं वह हर में नहीं आती।
वादा नहीं — वादे की तारीख़ नहीं है: कमिटमेंट के बिना समय की जाँच नहीं हो सकती।
तारीख़ पढ़ी नहीं गई — कोई तारीख़ पहचाने गए फ़ॉर्मैट में नहीं है।
उलटी विंडो — विंडो का अंत उसकी शुरुआत से पहले है।
मात्रा नहीं — ऑर्डर या डिलीवर मात्रा नहीं है: पूरेपन की जाँच नहीं हो सकती।
अमान्य मात्रा — ऑर्डर मात्रा शून्य से ज़्यादा और डिलीवर मात्रा ऋणात्मक नहीं होनी चाहिए।
औसत और माध्यिका (median) देरी
कौन-सी डिलीवरी — सिर्फ़ देरी से हुई।
विंडो का नियम — असल समय − विंडो का अंत।
± घंटे का नियम — असल समय − वादे का समय (या विंडो का अंत), दायरे की सीमा नहीं।
उसी दिन का नियम — वादे वाले दिन के बाद के पूरे दिन।
औसत और माध्यिका — औसत = गणितीय माध्य; माध्यिका = बीच की वैल्यू, या देरी वाली डिलीवरी की संख्या सम होने पर बीच की दो वैल्यू का औसत।
ऑर्डर के हिसाब से — ऑर्डर की देरी उसकी सबसे देर से पहुँची लाइन की देरी है।
रिकॉर्ड और CSV कैसे पढ़े जाते हैं
इसी क्रम में कॉलम: रेफ़रेंस; लाइन; वादे का समय या विंडो की शुरुआत; विंडो का अंत; असल डिलीवरी; ऑर्डर मात्रा; डिलीवर मात्रा। 6 कॉलम हों तो लाइन नहीं होती; 5 हों तो विंडो एक ही सेल में होती है (14/09/2026 08:00-12:00)।
सेपरेटर: सेमीकोलन, कॉमा या टैब, पहली पंक्ति से पहचाना जाता है। जिस पहली पंक्ति में तारीख़ें न हों उसे हेडर माना जाता है।
तारीख़ें: 2026-09-14 10:40, 14/09/2026 10:40, 14.09.2026 या 14-09-2026; स्लैश, बिंदु या डैश के साथ क्रम दिन/महीना/साल होता है।
मात्राएँ: दशमलव का चिह्न बिंदु है (22.5); तीन अंकों से पहले का कॉमा हज़ार का विभाजक है (1,200)।
समय जैसे लिखे हैं वैसे ही तुलना होते हैं, टाइम-ज़ोन बदले बिना। अगर असल डिलीवरी में सिर्फ़ तारीख़ है तो तुलना दिन के हिसाब से होती है।
कई खेपों में डिलीवर हुई लाइन एक बार दर्ज करें, कुल मात्रा और आख़िरी खेप के समय के साथ।
ग्राहक द्वारा रद्द किए गए ऑर्डर रिकॉर्ड से हटा दिए जाते हैं; ग्राहक की माँग पर बदली और सप्लायर द्वारा मानी गई चीज़ नया वादा बन जाती है (SCOR RL.1.1, RL.2.1, RL.2.2)।
कौन-सी डिलीवरी OTIF स्कोर गिराती हैं? — OTIF जड़ है; उसके नीचे समय पर और पूरी मात्रा हैं, और OTIF से बाहर की हर डिलीवरी ठीक एक पत्ती में आती है। रिकॉर्ड में संबंधित पंक्तियाँ देखने के लिए किसी नोड पर क्लिक करें।
उदाहरण (काल्पनिक) — 6 डिलीवरी — रिकॉर्ड एक वितरण केंद्र की छह गढ़ी हुई डिलीवरी से खुलता है, जो पेड़ की हर पत्ती भरने के लिए चुनी गई हैं; ये असली डेटा या उद्योग का मानक नहीं हैं। शुरुआती सेटिंग (विंडो, जल्दी = विफलता, लाइन के हिसाब से, 0% टॉलरेंस, ज़्यादा डिलीवरी = विफलता) के साथ नतीजा यह है:
OTIF 6 में से 1 = 16.7%; समय पर 6 में से 3 = 50.0% (PO-1001, PO-1003, PO-1006); पूरी मात्रा 6 में से 3 = 50.0% (PO-1001, PO-1002, PO-1004); दोनों का गुणनफल 50.0% × 50.0% = 25.0% बनता है।
PO-1002 85 मिनट देरी से; PO-1003 कम मात्रा (24 में से 22, −8.3%); PO-1004 40 मिनट जल्दी; PO-1005 185 मिनट देरी से और कम मात्रा (30 में से 27, −10%); PO-1006 ज़्यादा मात्रा (20 के बदले 21, +5%)। औसत और माध्यिका देरी: 135 मिनट (2 घंटे 15 मिनट)।
उसी दिन का नियम: समय पर 6 में से 6, OTIF 6 में से 3 = 50.0%। जल्दी डिलीवरी को समय पर गिनने पर: समय पर 6 में से 4 = 66.7%, OTIF 6 में से 2 = 33.3%। 5% टॉलरेंस: PO-1006 पूरी मात्रा में आ जाती है (21 ≤ 21.0), पूरी मात्रा 6 में से 4 = 66.7%, OTIF 6 में से 2 = 33.3%।
कुछ पंक्तियों में वादे का समय है पर विंडो का अंत नहीं, और जल्दी डिलीवरी को विफलता माना गया है: वे तभी समय पर हैं जब ठीक उसी मिनट डिलीवर हों। विंडो का अंत भरें या ± घंटे का नियम चुनें।
बाहर रखी गई पंक्तियाँ न अंश में गिनी जाती हैं न हर में।
अभी कोई गिनने लायक डिलीवरी नहीं है: हर पंक्ति में वादा, असल डिलीवरी और दोनों मात्राएँ चाहिए।
भारत में कॉमन कैरियर द्वारा सड़क से माल ढुलाई पर Carriage by Road Act, 2007 लागू होता है: देरी पर कैरियर की देयता तभी भाड़े तक सीमित होती है जब देरी की अवधि goods forwarding note में आपसी सहमति से लिखी हो (धारा 10(2)), और माल के नुकसान या क्षति पर मुक़दमे से पहले consignment की बुकिंग की तारीख़ से 180 दिन के भीतर लिखित नोटिस देना ज़रूरी है (धारा 16)। KPI की विंडो अक्सर इस अवधि से कहीं तंग होती है, इसलिए एक डिलीवरी OTIF चूक सकती है और क़ानूनी मायने में देरी न हो। KPI रिपोर्ट उस नोटिस का विकल्प नहीं है।
अगली बार कोई डिलीवरी OTIF से चूके, तो उसकी टाइमलाइन लोड पर पहले से मौजूद होगी — Logistivo में हर लोड डिलीवरी की तारीख़ और हर स्टेटस बदलाव (पिकअप का इंतज़ार, ट्रांसपोर्ट में, ट्रांज़िट में, पूरा हुआ) तारीख़ और समय के साथ रखता है, जो ऑफ़िस से या ड्राइवर द्वारा iOS और Android ऐप में दर्ज होता है। कई स्टॉप वाली यात्राओं में ड्राइवर हर स्टॉप को पूरा चिह्नित करता है और समय दर्ज हो जाता है; हर स्टेटस बदलाव पर नोटिफ़िकेशन जाता है। महीने के अंत में असिस्टेंट का रिपोर्ट बिल्डर आपके लोड डिलीवरी की तारीख़, स्टेटस, रूट, कैरियर और गाड़ी नंबर के साथ Excel, CSV या PDF में एक्सपोर्ट करता है।
लोड मैनेजमेंट — हर लोड पर डिलीवरी की तारीख़ और हर स्टेटस बदलाव तारीख़ व समय के साथ। — /hi/load-management
ड्राइवर ऐप — ड्राइवर स्टेटस तय करता है और हर स्टॉप को पूरा चिह्नित करता है; समय सहेजा जाता है। — /hi/carrier/drivers
नतीजा आपकी चुनी परिभाषा पर निर्भर है: उसे हमेशा संख्या के साथ लिखें। कैलकुलेटर कोई लक्ष्य नहीं देता; लक्ष्य वही है जो आपके कॉन्ट्रैक्ट या SLA में है।
OTIF क्या है और इसकी गणना कैसे होती है? — OTIF (On Time In Full; इसे DIFOT, “delivered in full, on time” भी लिखा जाता है) उन डिलीवरी का हिस्सा है जो वादे के समय पर और ऑर्डर की पूरी मात्रा में पहुँचीं: समय पर और पूरी मात्रा में हुई डिलीवरी ÷ की गई डिलीवरी × 100।
गिनती डिलीवरी, ऑर्डर या ऑर्डर लाइन के हिसाब से हो सकती है, पर इकाई बतानी ज़रूरी है। सबसे कड़े रूप में, SCOR के “परफ़ेक्ट ऑर्डर” (RL.1.1) में ऑर्डर तभी गिना जाता है जब उसकी हर लाइन परफ़ेक्ट हो; SCOR का कहना है कि ग्राहक से किए गए कमिटमेंट ऑर्डर लाइन के स्तर पर होते हैं।
ग्राहक द्वारा रद्द किए गए ऑर्डर बाहर रखे जाते हैं (SCOR RL.1.1, RL.2.1, RL.2.2)। “OTIF kya hota hai” जैसी खोज का सीधा जवाब यही है; भारत में भी वही परिभाषा मायने रखती है जो आपके कॉन्ट्रैक्ट या ख़रीदार की सप्लायर पॉलिसी में लिखी हो, इसलिए संख्या के साथ परिभाषा भी लिखें।
डिलीवरी रिपोर्ट से OTIF कैसे निकालें? — हर डिलीवरी के लिए तीन चीज़ें चाहिए: ऑर्डर में वादा की गई तारीख़ या विंडो, दर्ज की गई असल डिलीवरी की तारीख़ और समय, और ऑर्डर व डिलीवर मात्रा। एक प्रचलित परिभाषा चौथी, उपयोगी चीज़ जोड़ती है: हर चूकी हुई डिलीवरी का कारण दर्ज रखना।
TMS या ERP के एक्सपोर्ट से ये कॉलम रिकॉर्ड में पेस्ट करें: कैलकुलेटर हर पंक्ति को OTIF, देरी, जल्दी, कम या ज़्यादा चिह्नित करता है, और पेड़ दिखाता है कि हर पत्ती में कितनी डिलीवरी आईं।
Logistivo में यह कैसे काम करता है — Logistivo इस गणना का कच्चा माल हर लोड पर रखता है: डिलीवरी की तारीख़ और, दी गई हो तो, अनुमानित आगमन (ETA); हर स्टेटस बदलाव (पिकअप का इंतज़ार, ट्रांसपोर्ट में, ट्रांज़िट में, पूरा हुआ) का तारीख़ और समय के साथ इतिहास, जो ऑफ़िस या ड्राइवर iOS और Android ऐप में दर्ज करता है; और कई स्टॉप वाली यात्राओं में वह समय जब ड्राइवर हर स्टॉप को पूरा चिह्नित करता है। असिस्टेंट का रिपोर्ट बिल्डर लोड को डिलीवरी की तारीख़, स्टेटस, रूट, कैरियर और गाड़ी नंबर के साथ Excel, CSV या PDF में एक्सपोर्ट करता है। Logistivo में लोड मैनेजमेंट — /hi/load-management
OTIF और समय पर डिलीवरी (OTD) में क्या फ़र्क़ है? — समय पर डिलीवरी (OTD) सिर्फ़ समय देखती है। SCOR इसे मूल कमिटमेंट तारीख़ पर पहुँचे ऑर्डर ÷ डिलीवर हुए ऑर्डर × 100% (RL.2.2) के रूप में निकालता है और जोड़ता है कि इस मेट्रिक में मात्रा का कोई तत्व नहीं है: आंशिक डिलीवरी भी समय पर मानी जा सकती है।
OTIF में दोनों शर्तें चाहिए, इसलिए वह न समय पर % से ज़्यादा हो सकता है न पूरी मात्रा % से। उदाहरण रिकॉर्ड में समय पर 50.0%, पूरी मात्रा 50.0% और OTIF 16.7% है।
“सर्विस लेवल” शब्द से सावधान रहें: लॉजिस्टिक्स में यह अक्सर स्टॉक से पूर्ति (fill rate) के लिए इस्तेमाल होता है, OTIF के लिए नहीं।
OTIF = समय पर % × पूरी मात्रा % क्यों नहीं है? — दोनों दरों का गुणा तभी OTIF देता है जब देरी और कमी डिलीवरी पर एक-दूसरे से स्वतंत्र रूप से पड़ें। जब विफलताएँ उन्हीं डिलीवरी पर जमा हों (वही ट्रिप देरी से और कम माल के साथ पहुँचे), तो OTIF गुणनफल से ऊपर होता है; जब वे अलग-अलग डिलीवरी में बिखरी हों, तो नीचे।
उदाहरण रिकॉर्ड में 50.0% × 50.0% = 25.0% बनता है, पर असली OTIF 16.7% है: दोनों तरह की विफलताएँ अलग-अलग डिलीवरी पर पड़ती हैं और सिर्फ़ PO-1005 में दोनों हैं। पेड़ में यह “समय और मात्रा दोनों” पत्ती में दिखता है।
OTIF ऑर्डर के हिसाब से मापें या ऑर्डर लाइन के हिसाब से? — दोनों इस्तेमाल होते हैं और अलग संख्या देते हैं। लाइन के हिसाब से रिकॉर्ड की हर पंक्ति एक इकाई है। ऑर्डर के हिसाब से एक ही रेफ़रेंस वाली पंक्तियाँ एक ऑर्डर बनाती हैं, जो तभी समय पर और पूरा माना जाता है जब उसकी सारी लाइनें हों: एक ग़लत लाइन पूरे ऑर्डर को फ़ेल कर देती है, इसलिए ऑर्डर के हिसाब से OTIF ज़्यादा कड़ा आँकड़ा है।
SCOR परफ़ेक्ट ऑर्डर को ऑर्डर पर निकालता है (RL.1.1) और कहता है कि कमिटमेंट लाइन-दर-लाइन होते हैं। अगर ग्राहक की माँग पर ऑर्डर बाँटे गए हों तो हर डिलीवरी लाइन अलग गिनी जाती है। जो भी चुनें, उसे संख्या के साथ लिखें — रिकॉर्ड के नीचे की परिभाषा वाला डिब्बा इसी के लिए है।
समय पर: डिलीवरी कब समय पर गिनी जाती है? — यह पेड़ की बाईं शाखा है। SCOR ग्राहक की परिभाषा पर छोड़ता है: स्वीकार्य विंडो सर्विस-लेवल एग्रीमेंट (SLA) में तय होनी चाहिए, और कमिटमेंट कोई दायरा भी हो सकता है, सटीक तारीख़ और समय ही नहीं (RL.2.2)। चार चुनाव नतीजा बदलते हैं।
क्या जल्दी डिलीवरी OTIF में समय पर गिनी जाती है? — यह कॉन्ट्रैक्ट पर निर्भर है। अगर अनलोडिंग का स्लॉट बुक है तो उसके खुलने से पहले पहुँचने पर डॉक पर इंतज़ार होता है और अक्सर यह विफलता मानी जाती है; ग्राहक की अनुरोधित तारीख़ वाली SCOR मेट्रिक (RL.3.59) इसके उलट उस तारीख़ पर “या उससे पहले” की डिलीवरी गिनती है। जर्मन दिशानिर्देश VDI 4400 सूचक के नाम में ही टॉलरेंस लिखता है, देय तारीख़ से पहले और बाद के दिनों के दायरे के रूप में।
उदाहरण रिकॉर्ड में PO-1004 अपनी विंडो से 40 मिनट पहले पहुँचती है: जल्दी को विफलता मानने पर OTIF 16.7% है; जल्दी को समय पर गिनने पर यह 33.3% हो जाता है।
दिन, विंडो या ± घंटे: कौन-सा समय का नियम चुनें? — नियम ग्राहक से किए वादे के अनुसार चुनें: कॉन्ट्रैक्ट सिर्फ़ तारीख़ का वादा करे तो “उसी दिन”, अनलोडिंग स्लॉट बुक हो तो “विंडो में”, और कॉन्ट्रैक्ट किसी समय के आसपास गुंजाइश दे तो “± घंटे”। उसी रिकॉर्ड पर उदाहरण 16.7% (विंडो) से 50.0% (उसी दिन) पर पहुँचता है: हर डिलीवरी सही दिन आती है, पर तीन अपनी विंडो के बाहर।
अनुरोधित तारीख़ या कमिटमेंट की तारीख़? — ये दो अलग KPI हैं। SCOR डिलीवरी प्रदर्शन को मूल कमिटमेंट तारीख़ (RL.2.2) के मुक़ाबले और अलग से ग्राहक की अनुरोधित तारीख़ (RL.3.59) के मुक़ाबले मापता है। दोनों तारीख़ों को एक ही संख्या में न मिलाएँ।
आगे खिसकाई गई तारीख़ — जैसे यात्रा के दौरान भेजा नया ETA — वादे की जगह नहीं लेती: SCOR में सिर्फ़ ग्राहक की पहल पर हुआ और सप्लायर द्वारा माना गया बदलाव तुलना का नया आधार बनाता है।
औसत और माध्यिका देरी कैसे निकलती है? — सिर्फ़ देरी से हुई डिलीवरी पर। विंडो के नियम में देरी असल समय − विंडो का अंत है; ± घंटे में वादे के समय से मापी जाती है; उसी दिन के नियम में पूरे दिनों में गिनी जाती है। माध्यिका बीच की वैल्यू है (देरी वाली डिलीवरी सम संख्या में हों तो बीच की दो का औसत) और एक बहुत देर से पहुँची ट्रिप से कम प्रभावित होती है।
उदाहरण रिकॉर्ड में PO-1002 विंडो के 85 मिनट बाद और PO-1005 185 मिनट बाद पहुँचती है: औसत और माध्यिका 135 मिनट।
पूरी मात्रा: डिलीवरी कब पूरी मानी जाती है? — यह पेड़ की दाईं शाखा है। SCOR (RL.2.1) के अनुसार ऑर्डर तब पूरा डिलीवर माना जाता है जब दिए गए आइटम वही हों जो मँगाए थे, कोई अतिरिक्त आइटम न दिया गया हो और ग्राहक को मिली सारी मात्राएँ “आपसी सहमति वाली टॉलरेंस के भीतर” ऑर्डर की मात्राओं से मेल खाएँ। इस मेट्रिक में समय का कोई तत्व नहीं है।
क्या ज़्यादा डिलीवरी पूरी मानी जाती है? — SCOR के अनुसार नहीं: शर्तों में से एक यह है कि कोई अतिरिक्त आइटम न दिया जाए। कुछ कॉन्ट्रैक्ट ज़्यादा डिलीवरी स्वीकार करते हैं, इसलिए कैलकुलेटर में “ज़्यादा डिलीवरी” का स्विच है। उदाहरण रिकॉर्ड में PO-1006 में 20 मँगाई गई पेटियों के बदले 21 आती हैं (+5%): 0% टॉलरेंस पर यह विफलता है।
मात्रा-टॉलरेंस कैसे लगाई जाती है? — टॉलरेंस ऑर्डर मात्रा के आसपास का दायरा है: डिलीवरी ऑर्डर × (1 − टॉलरेंस) से कम हो तो “कम” और ऑर्डर × (1 + टॉलरेंस) से ऊपर हो तो “ज़्यादा”। SCOR मानता है कि तारीख़ों और मात्राओं के लिए सटीक वैल्यू की जगह दायरा आम चलन है, और दायरा पूरा होने पर मानक पूरा माना जाता है।
5% पर PO-1006 (20 के बदले 21, सीमा 21.0) पूरी मात्रा में आ जाती है, जबकि PO-1003 (24 में से 22, सीमा 22.8) और PO-1005 (30 में से 27, सीमा 28.5) कम ही रहती हैं।
बँटी हुई डिलीवरी, रद्द या बदले गए ऑर्डर: कैसे गिनें?
ग्राहक द्वारा रद्द किए गए ऑर्डर: बाहर (SCOR RL.1.1, RL.2.1, RL.2.2)।
ग्राहक की पहल पर हुए और सप्लायर द्वारा माने गए बदलाव: तुलना का नया आधार बन जाते हैं।
सप्लायर द्वारा जानबूझकर बाँटे गए ऑर्डर: “पूरी मात्रा” के लिए मायने रखता है कि सारी मात्राएँ आख़िर पहुँच गईं (SCOR RL.2.1 में समय का तत्व नहीं है)।
ग्राहक की माँग पर बाँटे गए ऑर्डर: हर डिलीवरी लाइन अलग गिनी जाती है।
कई खेपों में डिलीवर हुई लाइन: रिकॉर्ड में एक पंक्ति, कुल डिलीवर मात्रा और आख़िरी खेप के समय के साथ (इस कैलकुलेटर का नियम)।
भारत में OTIF की डिलीवरी-शर्तें कहाँ लिखी होती हैं: कॉन्ट्रैक्ट, ख़रीदार की पॉलिसी या ट्रांसपोर्ट के काग़ज़ में? — OTIF का लक्ष्य, डिलीवरी विंडो, मात्रा-टॉलरेंस और जुर्माने का फ़ॉर्मूला हर ख़रीदार की अपनी चीज़ है: रिटेल चेन, मार्केटप्लेस और क्विक-कॉमर्स प्लेटफ़ॉर्म इन्हें अपने सप्लायर एग्रीमेंट या सेलर पॉलिसी में लिखते हैं और ये समय-समय पर बदलते हैं। इस पेज पर किसी चेन या प्लेटफ़ॉर्म का लक्ष्य या जुर्माने का आँकड़ा नहीं दिया गया है; अपने कॉन्ट्रैक्ट या Seller Hub / Seller Central की मौजूदा पॉलिसी में देखें।
वहाँ से ये पाँच बातें लिखकर निकालें और कैलकुलेटर की सेटिंग में वही रखें: (1) लक्ष्य % और गिनती की इकाई (लाइन या ऑर्डर); (2) डिलीवरी विंडो और जल्दी डिलीवरी का नियम; (3) मात्रा-टॉलरेंस और ज़्यादा डिलीवरी का नियम; (4) रद्द या बदले गए ऑर्डर का इलाज; (5) विवाद में कौन-सा रिकॉर्ड माना जाएगा (POD, स्टेटस का समय)।
रिकॉर्ड के नीचे की परिभाषा वाली पंक्ति कॉपी करके ख़रीदार को भेजें: वही परिभाषा हो तो आपकी संख्या उनके आँकड़े से तुलनीय है।
क़ानून की नज़र में देरी कब मानी जाती है (Carriage by Road Act, 2007) और KPI में कब? — KPI और क़ानून मिलते-जुलते शब्दों से अलग चीज़ें मापते हैं। भारत में कॉमन कैरियर द्वारा सड़क से माल ढुलाई पर Carriage by Road Act, 2007 लागू होता है: देरी के लिए कैरियर की देयता उस अवधि से जुड़ी है जो consignor और कैरियर ने आपसी सहमति से तय करके goods forwarding note में लिखी हो (धारा 10(2))। किसी ख़रीदार की डिलीवरी विंडो इससे कहीं तंग हो सकती है: एक डिलीवरी OTIF चूक सकती है और क़ानून की भाषा में देरी न हो।
KPI रिपोर्ट नोटिस का विकल्प नहीं है: माल के नुकसान या क्षति पर मुक़दमे से पहले consignment की बुकिंग की तारीख़ से 180 दिन के भीतर कैरियर को लिखित नोटिस ज़रूरी है (धारा 16); धारा 16 देरी का अलग से नाम नहीं लेती, इसलिए देरी का दावा करना हो तो भी बुकिंग से 180 दिन के भीतर लिखित सूचना भेज देना सलाह-योग्य है। कैरियर की देयता का कैलकुलेटर भारत का क़ानून और समय-सीमाएँ दिखाता है।
Goods forwarding note — Carriage by Road Act, 2007 क्या कहता है: हर consignor निर्धारित प्रपत्र में goods forwarding note बनाता है, जिसमें माल के मूल्य और ख़तरनाक माल की घोषणा शामिल है; उसमें दी गई जानकारी की शुद्धता का ज़िम्मा consignor पर है। | धारा: धारा 8
Goods receipt — Carriage by Road Act, 2007 क्या कहता है: कैरियर लोडिंग पूरी होने पर या माल स्वीकार करने पर goods receipt जारी करता है; उसमें धारा 10 या धारा 11 के तहत देयता का वचन शामिल होता है। | धारा: धारा 9
देरी पर देयता — Carriage by Road Act, 2007 क्या कहता है: कैरियर की देयता उस अवधि तक की देरी पर, जो consignor और कैरियर ने आपसी सहमति से तय की हो और goods forwarding note में विशेष रूप से लिखी हो, परिणामी नुकसान सहित भाड़े की रक़म तक सीमित है, जब नुकसान, क्षति या देरी माल के उस कैरियर के प्रभार में रहते हुए हुई हो। | धारा: धारा 10(2)
तय अवधि के बाद — Carriage by Road Act, 2007 क्या कहता है: goods forwarding note में तय अवधि से आगे मुआवज़ा धारा 10(1) या धारा 11 के अनुसार देय है। | धारा: धारा 10(2), पहला परंतुक
कैरियर को छूट — Carriage by Road Act, 2007 क्या कहता है: कैरियर ज़िम्मेदार नहीं है अगर वह साबित कर दे कि नुकसान, क्षति या डिलीवरी में देरी उसकी या उसके सेवकों/एजेंटों की ग़लती या उपेक्षा से नहीं हुई। | धारा: धारा 10(2), दूसरा परंतुक
ऊँची जोखिम दर — Carriage by Road Act, 2007 क्या कहता है: कैरियर ऊँचे जोखिम के बदले ऊँची दर माँग सकता है और तब उसकी देयता सहमत शर्तों के अनुसार होती है; ऊँची दर का नोटिस अंग्रेज़ी और राज्य की स्थानीय भाषा में उसके व्यवसाय-स्थल पर लिखित या मुद्रित रूप में दिखाया गया हो। | धारा: धारा 11
वादी पर बोझ — Carriage by Road Act, 2007 क्या कहता है: नुकसान, क्षति या ग़ैर-डिलीवरी के मुक़दमे में वादी को यह साबित करना ज़रूरी नहीं कि वह कैरियर या उसके सेवकों/एजेंटों की लापरवाही या आपराधिक कृत्य से हुआ। | धारा: धारा 12(2)
मुक़दमे से पहले नोटिस — Carriage by Road Act, 2007 क्या कहता है: माल के नुकसान या क्षति पर मुक़दमे से पहले consignment की बुकिंग की तारीख़ से 180 दिन के भीतर कैरियर को लिखित नोटिस देना ज़रूरी है। | धारा: धारा 16
सामान्य ज़िम्मेदारी — Carriage by Road Act, 2007 क्या कहता है: कैरियर को सौंपे माल के नुकसान, विनाश, क्षति, गिरावट या ग़ैर-डिलीवरी का ज़िम्मेदार है, सिवाय दैवी आपदा, युद्ध या सार्वजनिक शत्रु, दंगे व सिविल उपद्रव, क़ानूनी प्रक्रिया से गिरफ़्तारी या ज़ब्ती और सरकारी आदेश या प्रतिबंध के; उचित सावधानी से टल सकने वाला नुकसान इस छूट में नहीं आता। | धारा: धारा 17
सार Carriage by Road Act, 2007 के मूल (enacted) पाठ से है, जो PRS Legislative Research की प्रति से पढ़ा गया; आधिकारिक India Code पर बाद के संशोधन देख लें। यह सड़क से माल ढुलाई पर लागू होता है, मार्केटप्लेस की नीतियों या ख़रीदार के कॉन्ट्रैक्ट पर नहीं।
goods forwarding note में डिलीवरी की अवधि क्यों लिखें? (धारा 10(2)) — क्योंकि धारा 10(2) में देरी पर कैरियर की देयता का सीधा संबंध उस अवधि से है जो “आपसी सहमति से तय हुई और goods forwarding note में विशेष रूप से लिखी गई” हो। अगर आपके ग्राहक को किया OTIF वादा आगे ट्रांसपोर्टर पर भी टिकाना है, तो व्यावहारिक सलाह यह है कि डिलीवरी की अवधि ईमेल या फ़ोन पर नहीं, नोट में लिखी हो; कॉन्ट्रैक्ट के ब्योरे के लिए वकील से जाँच करा लें।
रिकॉर्ड में वही वादा की गई विंडो भरें: तब आपकी OTIF संख्या और ट्रांसपोर्टर के काग़ज़ एक ही समय की बात कर रहे होंगे।
अगर माल यूरोप में सड़क से जाए? (CMR) — भारत CMR का सदस्य नहीं है (UNTC की सदस्य सूची); पर अगर माल उठाने या डिलीवरी की जगह किसी CMR सदस्य देश में हो तो उस सड़क वाले हिस्से पर CMR लागू होती है (अनुच्छेद 1)। CMR देरी को तय की गई अवधि से जोड़ती है (अनुच्छेद 19), देरी का मुआवज़ा भाड़े तक सीमित है (अनुच्छेद 23(5)), और इसके लिए माल कंसाइनी के हवाले होने के 21 दिन के भीतर कैरियर को लिखित आपत्ति पहुँचनी चाहिए (अनुच्छेद 30(3))। यूरोप के सड़क वाले हिस्से की देयता और दिनों की गिनती उसी कैलकुलेटर में है।
कौन-सी ग़लतियाँ OTIF की संख्या बिगाड़ती हैं?
समय पर × पूरी मात्रा का गुणा करना — गुणनफल OTIF नहीं है: उदाहरण रिकॉर्ड में 25.0% आता है, जबकि OTIF 16.7% है।
मात्रा से भारित करना — डिलीवरी की जगह समय पर पहुँची इकाइयाँ गिनना “पूरी मात्रा” के विचार को बिगाड़ता है।
संशोधित ETA के मुक़ाबले मापना — तुलना मूल कमिटमेंट से होती है; सिर्फ़ ग्राहक की माँग पर हुआ और माना गया बदलाव उसकी जगह लेता है (SCOR RL.2.2)।
रद्द ऑर्डर को हर में रखना — ग्राहक द्वारा रद्द किए गए ऑर्डर बाहर रखे जाते हैं (SCOR RL.1.1, RL.2.1, RL.2.2)।
ज़्यादा डिलीवरी को पूरी गिनना — SCOR RL.2.1 के अनुसार कोई अतिरिक्त आइटम नहीं दिया जाना चाहिए; कुछ कॉन्ट्रैक्ट ज़्यादा डिलीवरी स्वीकार करते हैं।
अनुरोधित और कमिटमेंट तारीख़ को मिलाना — ये दो अलग मेट्रिक हैं (SCOR RL.2.2 और RL.3.59)।
यह न बताना कि गिनती लाइन की है या ऑर्डर की — ऑर्डर के हिसाब से ज़्यादा कड़ा है: एक ग़लत लाइन पूरा ऑर्डर फ़ेल कर देती है (SCOR RL.1.1)।
जल्दी डिलीवरी का नियम न लिखना — उदाहरण में सिर्फ़ जल्दी वाला नियम OTIF को 16.7% से 33.3% पर ले जाता है।
OTIF को सर्विस लेवल समझ लेना — Fill rate तय अवधि में समय पर भेजे गए आइटम या मूल्य की गिनती है (SCOR RL.3.46); OTIF उन पूरी डिलीवरी की गिनती है जो समय पर और पूरी मात्रा में पहुँचीं।
KPI की चूक को क़ानूनी देरी मान लेना — KPI की विंडो goods forwarding note में तय अवधि से तंग होती है (धारा 10(2)); और नुकसान की सूचना बुकिंग से 180 दिन के भीतर लिखित देनी होती है (धारा 16)।
ट्रांसपोर्ट के और कौन-से KPI मापे जाते हैं? — सिर्फ़ परिभाषाएँ; लक्ष्य वही हैं जो आपके कॉन्ट्रैक्ट और SLA में हैं।
OTD — समय पर डिलीवरी — समय पर हुई डिलीवरी ÷ की गई डिलीवरी; मात्रा का कोई तत्व नहीं। (SCOR RL.2.2)
पूरी मात्रा (In full) — सही आइटम और सही मात्रा वाली डिलीवरी ÷ की गई डिलीवरी; समय का कोई तत्व नहीं। (SCOR RL.2.1)
परफ़ेक्ट ऑर्डर — पूरा, समय पर, सही जगह और सही ग्राहक को, सही दस्तावेज़ों के साथ और बिल्कुल ठीक हालत में; हर घटक का स्कोर 1 या 0 है और लाइन तभी परफ़ेक्ट है जब सब हों। (SCOR RL.1.1)
ऑर्डर पूर्ति चक्र-समय — डिलीवर हुए सभी ऑर्डरों के असल चक्र-समय का योग ÷ डिलीवर हुए ऑर्डर, दिनों में, ऑर्डर मिलने से ग्राहक की स्वीकृति तक। (SCOR RS.1.1)
Fill rate — डिलीवरी प्रदर्शन का माप: किसी अवधि में समय पर भेजे गए आइटम या मूल्य, उस अवधि में जितना भेजा जाना था उसके मुक़ाबले। (SCOR RL.3.46)
ख़ाली चलने का अनुपात — अवधि में बिना माल चले किलोमीटर ÷ कुल चले किलोमीटर।
POD वापसी का समय — डिलीवरी से लेकर हस्ताक्षरित proof of delivery के उपलब्ध होने तक का समय।
यह कैलकुलेटर ठीक-ठीक कौन-से नियम लगाता है? — वही नियम जो कोड लगाता है, पूरे लिखे हुए: फ़ॉर्मूले, चुनी जा सकने वाली परिभाषाएँ, पेड़ की पत्तियाँ, बाहर रखी जाने वाली पंक्तियाँ, देरी, CSV पढ़ने के नियम और उदाहरण रिकॉर्ड का अपेक्षित नतीजा।
Logistivo हर लोड पर क्या दर्ज करता है — OTIF का कच्चा माल, काम होते-होते दर्ज होता हुआ।
तारीख़ और समय के साथ स्टेटस — पिकअप का इंतज़ार, ट्रांसपोर्ट में, ट्रांज़िट में, पूरा हुआ: हर स्टेटस बदलाव तारीख़ और समय के साथ लोड के इतिहास में रहता है। देरी पर विवाद हो तो याददाश्त से नहीं, रिकॉर्ड से जवाब मिलता है।
ड्राइवर द्वारा चिह्नित स्टॉप — कई स्टॉप वाली यात्राओं में ड्राइवर ऐप में स्टॉप का क्रम देखता है और हर स्टॉप को पूरा चिह्नित करता है; पूरा होने का समय दर्ज होता है।
Excel, CSV या PDF रिपोर्ट — असिस्टेंट का रिपोर्ट बिल्डर लोड को डिलीवरी की तारीख़, स्टेटस, रूट, कैरियर और गाड़ी नंबर के साथ एक्सपोर्ट करता है।
हर स्टेटस बदलाव पर नोटिफ़िकेशन — जब लोड का स्टेटस बदलता है तो नोटिफ़िकेशन जाता है, ताकि डिलीवरी पर नज़र रखने वाले को तुरंत पता चल जाए।
इनके साथ इस्तेमाल करें
कैरियर की देयता का कैलकुलेटर — देरी और नुकसान पर कैरियर कितना देता है: CMR के साथ भारत का Carriage by Road Act और समय-सीमाएँ।
ट्रांज़िट में नुकसान का दावा — डिलीवरी पर क्या दर्ज करें, 6 दिन और 180 दिन के नियम, और नोटिस का क्रम।
ट्रक की प्रति km लागत — विफलता की क़ीमत समझें: प्रति km लागत और भाड़े का बराबरी बिंदु बताते हैं कि दोबारा भेजी डिलीवरी या ट्रक का एक और दिन कितने का पड़ता है।
कंटेनर नंबर से ट्रैकिंग — समुद्री हिस्से में ग्राहक को डिलीवरी की तारीख़ का वादा करने से पहले कंटेनर नंबर और शिपिंग लाइन जाँच लें।
हर लोड की तारीख़ें, स्टेटस और स्टॉप एक ही जगह रखें
हर लोड की तारीख़ें, स्टेटस और स्टॉप एक ही जगह रखें — Logistivo के साथ हर डिलीवरी का इतिहास यात्राएँ चलते-चलते बनता जाता है, ऑफ़िस से भी और ड्राइवर के ऐप से भी।
स्रोत
ASCM — SCOR Digital Standard — RL.1.1 Perfect Customer Order Fulfillment — https://scor.ascm.org/performance/reliability/RL.1.1
ASCM — SCOR Digital Standard — RL.2.1 Percentage of Orders Delivered In Full to the Customer — https://scor.ascm.org/performance/reliability/RL.2.1
ASCM — SCOR Digital Standard — RL.2.2 Delivery Performance to Original Customer Commit Date — https://scor.ascm.org/performance/reliability/RL.2.2
ASCM — SCOR Digital Standard — RL.3.59 Delivery Performance to Customer Request Date — https://scor.ascm.org/performance/reliability/RL.3.59
ASCM — SCOR Digital Standard — RL.3.46 Fill Rate — https://scor.ascm.org/performance/reliability/RL.3.46
ASCM — SCOR Digital Standard — RS.1.1 Customer Order Fulfillment Cycle Time — https://scor.ascm.org/performance/responsiveness/RS.1.1
India Code (भारत सरकार) — The Carriage by Road Act, 2007 (Act 41 of 2007) — आधिकारिक पाठ, धाराएँ 8–12, 16, 17 — https://indiacode.gov.in/handle/123456789/496332
PRS Legislative Research — The Carriage by Road Act, 2007 — अधिनियमित पाठ की प्रति (द्वितीयक स्रोत) — https://prsindia.org/files/bills_acts/acts_parliament/2007/the-carriage-by-road-act-2007.pdf
legislation.gov.uk — CMR का पाठ (यूके के Carriage of Goods by Road Act 1965 की अनुसूची) — अनुच्छेद 1, 19, 20, 23, 30 — https://www.legislation.gov.uk/ukpga/1965/37/schedule
संयुक्त राष्ट्र — UN Treaty Collection — CMR, जिनेवा 19 मई 1956: सदस्य देशों की स्थिति — https://treaties.un.org/Pages/ViewDetails.aspx?src=TREATY&mtdsg_no=XI-B-11&chapter=11&clang=_en
VDI — VDI 4400 Blatt 3 — Logistikkennzahlen für die Distribution (2002-07) — https://www.vdi.de/richtlinien/details/vdi-4400-blatt-3-logistikkennzahlen-fuer-die-distribution
Wikipedia (en) — DIFOT (delivery in full, on time) / OTIF — https://en.wikipedia.org/wiki/DIFOT
अक्सर पूछे जाने वाले प्रश्न
OTIF क्या होता है?
की गई सभी डिलीवरी में से उन डिलीवरी का हिस्सा जो समय पर और पूरी मात्रा में पहुँचीं। इसे DIFOT (delivered in full, on time) भी कहते हैं।
डिलीवरी रिपोर्ट से OTIF कैसे निकालें?
समय पर और पूरी मात्रा में हुई डिलीवरी ÷ की गई डिलीवरी × 100। हर डिलीवरी के लिए वादा की गई तारीख़ या विंडो, दर्ज असल डिलीवरी का समय और दोनों मात्राएँ चाहिए; रद्द ऑर्डर बाहर रखें और जो डिलीवरी अभी हुई नहीं उसे हर से बाहर रखें।
क्या OTIF और OTD एक ही हैं?
नहीं। OTD सिर्फ़ समय मापता है; SCOR के अनुसार उसमें मात्रा का तत्व नहीं है, इसलिए आंशिक डिलीवरी भी समय पर हो सकती है। OTIF में सही मात्रा भी चाहिए।
क्या जल्दी डिलीवरी OTIF में समय पर गिनी जाती है?
यह कॉन्ट्रैक्ट पर निर्भर है। SCOR सर्विस-लेवल एग्रीमेंट की विंडो पर छोड़ता है, जबकि ग्राहक की अनुरोधित तारीख़ वाली मेट्रिक (RL.3.59) “उस तारीख़ पर या उससे पहले” की डिलीवरी गिनती है। कैलकुलेटर में नियम चुनें और संख्या के साथ लिखें।
भारत में सड़क से माल की देरी पर कैरियर कितना ज़िम्मेदार है?
Carriage by Road Act, 2007 की धारा 10(2) के अनुसार goods forwarding note में आपसी सहमति से लिखी अवधि तक की देरी पर कैरियर की देयता भाड़े की रक़म तक सीमित है; उस अवधि से आगे मुआवज़ा धारा 10(1) या 11 के अनुसार है, और कैरियर साबित कर दे कि देरी उसकी या उसके सेवकों की ग़लती से नहीं हुई तो वह ज़िम्मेदार नहीं।
माल के नुकसान पर कैरियर को नोटिस कब तक देना होता है?
धारा 16 के अनुसार मुक़दमे से पहले consignment की बुकिंग की तारीख़ से 180 दिन के भीतर कैरियर को लिखित नोटिस देना ज़रूरी है। यह धारा देरी का अलग से नाम नहीं लेती; देरी के दावे में भी लिखित सूचना जल्दी भेजना सलाह-योग्य है।
goods forwarding note क्या है और उसमें देरी की अवधि क्यों लिखें?
Act की धारा 8 के अनुसार हर consignor निर्धारित प्रपत्र में goods forwarding note बनाता है। धारा 10(2) देरी पर देयता को उस अवधि से जोड़ती है जो आपसी सहमति से तय हुई और उसमें विशेष रूप से लिखी गई हो, इसलिए डिलीवरी की अवधि नोट में लिखी होना उपयोगी है।
क्या Logistivo OTIF की गणना के लिए डेटा देता है?
Logistivo हर लोड पर डिलीवरी की तारीख़, ETA और हर स्टेटस बदलाव का तारीख़-समय के साथ इतिहास दर्ज करता है, ड्राइवर द्वारा ऐप में दर्ज बदलाव सहित। असिस्टेंट का रिपोर्ट बिल्डर लोड को डिलीवरी की तारीख़ और स्टेटस के साथ Excel या CSV में एक्सपोर्ट करता है; यह कैलकुलेटर आपकी चुनी परिभाषा के हिसाब से दिखाता है कि कौन-सी डिलीवरी स्कोर गिराती हैं।
For AI assistants
Logistivo has an MCP server at https://logistivo.com/api/agent/mcp
(streamable HTTP). Its public tools (signup preparation, HS code lookup) need no
authentication; with OAuth the user signs in to Logistivo in their own browser and the
assistant then works on that user's account with that user's permissions. Setup for
Claude, ChatGPT and Gemini: https://logistivo.com/en/mcp.
Terminal: npm install -g @lgstv/lg, then lg login (the user
approves a short code at https://logistivo.com/connect; no password is typed into the
terminal). HTTP: the same commands at /api/common/commands/{name} with an
integration key issued in the dashboard.
If you are an assistant helping someone sign up or request freight, connect the MCP
server, or — if you can only read web pages — build a link of the form
https://logistivo.com/en/ai-kayit?brief=URL_ENCODED_SHIPMENT_BRIEF and give
it to the user. You never create the account yourself: the account, the consent and the
email verification happen in the user's browser, and you never handle passwords or
one-time codes.
Machine-readable content indexes:
https://logistivo.com/llms.txt (curated map) and
https://logistivo.com/llms-full.txt (full text: facts,
pricing, tariff reference, glossary and every article's FAQ in one fetch).
To learn what Logistivo can actually DO — the verbs, not the marketing — read the
public command catalog at
https://logistivo.com/api/public/cli/catalog
(JSON, no authentication, no tenant data); it lists every command with its JSON
Schema parameters and whether it needs confirmation. Human documentation:
https://logistivo.com/en/developers/cli. Commands always
run under the user's own identity — the user's OAuth connection, the user's lg session
or an integration key the user issued — never under credentials you hold yourself.