बुकिंग के लिए सरल डिपॉज़िट और स्प्लिट‑पेमेंट ट्रैकर

बुकिंग भुगतान जल्दी क्यों गड़बड़ हो जाते हैं

डिपॉज़िट बुकिंग को सुरक्षित बनाते हैं। ग्राहक कम‑संभावना से नो‑शो होते हैं, और जो गंभीर नहीं हैं वे जल्दी ही हट जाते हैं।

समस्याएँ आम तौर पर पहले भुगतान के तुरंत बाद शुरू हो जाती हैं। अगर आपके पास शेष बैलेंस ट्रैक करने के लिए एक भरोसेमंद जगह नहीं है, तो हर बुकिंग छोटी-छोटी खोजबीन बन जाती है।

जब बैलेंस नोट्स, DMs, या स्प्रेडशीट में रहते हैं, तो तीन चीजें जल्दी बिगड़ जाती हैं: नंबर बहकते हैं, संदेश मिस होते हैं, और अलग‑अलग कर्मचारी अलग‑अलग सच्चाई पर काम करते हैं। एक व्यक्ति शीट अपडेट करता है, दूसरा आगमन पर नकद लेता है, और कोई नहीं जानता कि अभी क्या बकाया है।

असली ज़िन्दगी और अधिक रुकावटें जोड़ती है। ग्राहक समय बदलता है, अतिरिक्त सेवा जोड़ता है, बाकी भुगतान दो भागों में करता है, या रसीद माँगता है। अचानक आप आंशिक भुगतान, रिफंड और नए टोटल संभाल रहे होते हैं, जबकि बुकिंग कैलेंडर में कुछ भी नहीं दिखता।

दर्द के बिंदु आम तौर पर एक जैसे होते हैं:

• डिपॉज़िट दर्ज तो है, लेकिन शेष राशि अपॉइंटमेंट से जुड़ी नहीं है।
• कुल कीमत बदलती है, पर बैलेंस_due फिर से कैल्कुलेट नहीं होता।
• रिमाइंडर मैन्युअल भेजे जाते हैं, इसलिए वे देर से (या भूल जाते हैं)।
• स्टाफ बिना खोदे “कितना बचा है, और कब देय है?” का जवाब नहीं दे पाता।

अधिकतर टीमों की सरल मांग यही होती है: अपॉइंटमेंट के लिए डिपॉज़िट लें, हर बुकिंग के लिए एक सटीक बैलेंस नंबर रखें, और सही समय पर (जैसे 48 घंटे पहले) ऑटोमैटिक बैलेंस रिमाइंडर भेजें। अगर कोई व्यक्ति इन‑पर्सन भुगतान करता है, तो सिस्टम उसे रिकॉर्ड करे और रिमाइंडर बंद कर दे।

पहले अपने डिपॉज़िट और बैलेंस नियम तय करें

यह तभी सरल लगेगा जब आपके नियम सरल हों। कुछ भी बनाने से पहले अपने निर्णयों को लिख लें ताकि हर बुकिंग पर नए निर्णय न लेने पड़ें।

पहले डिपॉज़िट से शुरू करें। क्या यह फिक्स्ड राशि होगी (जैसे $30) या प्रतिशत (जैसे 20%)? फिक्स्ड समझाने में आसान है। जब कीमतें बदलती हैं तो प्रतिशत न्यायसंगत लगता है। फिर तय करें कि आप कब चार्ज करेंगे: बुकिंग के समय, पुष्टि के बाद, या कोट के बाद। तुरंत लेना नो‑शो घटाता है, लेकिन फिर आपको रिफंड के स्पष्ट नियम चाहिए होते हैं।

इसके बाद, तय करें कि शेष बैलेंस कब देय होगा। “आगमन पर” सबसे आसान है। “48 घंटे पहले” आखिरी मिनट की कैंसिलेशन को घटाता है। कुछ व्यवसाय भरोसेमंद ग्राहकों के लिए “सेवा के बाद” की अनुमति देते हैं, पर यह अपवाद होना चाहिए, नियम नहीं।

रिफंड और रिस्केड्यूल्स को एक‑दो वाक्य में समझाने योग्य रखें। उदाहरण के लिए: “डिपॉज़िट अपॉइंटमेंट से 24 घंटे पहले तक रिफंडेबल है। उसके बाद डिपॉज़िट रख लिया जाता है, पर आप 7 दिनों के भीतर एक बार रिस्केड्यूल कर सकते हैं।” सरल नियम झगड़ों को रोकते हैं।

यह भी तय करें कि आपके बिज़नेस में “पेड” का क्या मतलब है। अगर आप कार्ड, नकद और बैंक ट्रांसफर स्वीकार करते हैं, तो हर विधि को स्पष्ट रूप से ट्रैक करना होगा। रसीदें ग्राहकों और आपके रिकॉर्ड्स के लिए मायने रखती हैं, इसलिए इसे अस्पष्ट न छोड़ें।

इनको लॉक करें:

• डिपॉज़िट प्रकार (फिक्स्ड बनाम प्रतिशत) और कोई न्यूनतम राशि
• डिपॉज़िट कब चार्ज किया जाता है (बुकिंग, पुष्टि, या कोट के बाद)
• बैलेंस कब देय है (आगमन पर, X दिन पहले, या सेवा के बाद)
• रिस्केड्यूल और रिफंड नीति सरल भाषा में
• स्वीकृत भुगतान विधियाँ और आप कौन‑सी रसीद देते हैं

इनको लिखने के बाद, बनाना ज्यादातर कॉन्फ़िगरेशन है।

ट्रैक करने के लिए सरल डेटा

लक्ष्य सब कुछ स्टोर करना नहीं है। लक्ष्य कुछ ऐसे तथ्य स्टोर करना है जिन पर आप भरोसा कर सकें जब कोई पूछे, “क्या बकाया है, कब तक, और क्या हमने रिमाइंड किया?”

बुकिंग से शुरू करें। हर बुकिंग में होना चाहिए:

• सेवा का नाम (या प्रकार)
• अपॉइंटमेंट तारीख और समय
• ग्राहक रिकॉर्ड (नाम, ईमेल, फोन)
• बुकिंग स्टेटस (requested, confirmed, completed, canceled)

इसके बाद पेमैंट शेड्यूल। अगर आपका मॉडल डिपॉज़िट + बैलेंस है, तो उसे दो लाइन में रखें। हर लाइन में राशि और ड्यू डेट होनी चाहिए। इसे साधारण रखें।

पेमैंट्स को एक रनिंग टोटल के रूप में नहीं, बल्कि अलग‑अलग ट्रांज़ैक्शन के रूप में रिकॉर्ड करें। हर भुगतान के लिए राशि, समय, विधि (card, cash, transfer) और प्रोवाइडर ID (उदा. Stripe payment intent या charge ID) रखें। अगर आप रिफंड प्रोसेस करते हैं, तो रिफंड राशि, समय और प्रोवाइडर रिफंड ID ट्रैक करें।

रिमाइंडर्स को संदेश की तरह ट्रैक करें: किस टेम्पलेट का उपयोग हुआ, प्लान्ड सेंड टाइम, वास्तविक सेंड टाइम, और डिलीवरी स्टेटस (sent, failed, bounced)। इससे “क्या हमने नोटिफ़ाई किया?” का जवाब अनुमान नहीं लगाकर मिल जाएगा।

अंत में, एक ऑडिट ट्रेल रखें: किसने बुकिंग, शेड्यूल, या स्टेटस बदला और कब। यह तब काम आता है जब ग्राहक किसी सहमति पर विवाद करे।

अगर आप AppMaster में बना रहे हैं, तो ये कुछ टेबल्स में आसानी से फिट हो जाते हैं और बैलेंस व रिमाइंडर्स की लॉजिक Business Process Editor में संभाली जा सकती है।

स्पष्ट बुकिंग और पेमैंट स्टेटस सेट करें

पेमैंट तब ही मैनेजेबल रहते हैं जब हर कोई जल्दी जवाब दे सके: अगला कदम क्या है?

दो अलग अवधारणाओं का उपयोग करें:

• बुकिंग स्टेटस (अपॉइंटमेंट लाइफलाइकल)
• पेमैंट स्टेटस (पैसे का लाइफलाइकल)

यह "Completed" और "Paid" को मिलाने जैसी गड़बड़ी रोकता है।

एक व्यावहारिक पेमैंट स्टेटस सेट इस तरह दिखता है:

• Unpaid: अभी तक कोई पैसा प्राप्त नहीं हुआ।
• Deposit paid: डिपॉज़िट मिला, बैलेंस अभी देय है।
• Part-paid: डिपॉज़िट से अधिक मिला पर पूरी तरह से भुगतान नहीं हुआ।
• Paid: कुल देय राशि का भुगतान हो गया है।
• Refunded / Part-refunded: पैसा वापस किया गया (अगर आप रिफंड सपोर्ट करते हैं)।

Completed और Canceled को बुकिंग के परिणाम के रूप में रखें, पेमैंट परिणाम के रूप में नहीं। एक बुकिंग Completed + Paid हो सकती है, या Canceled + Refunded, आपके नियमों के अनुसार।

ट्रिगर्स परिभाषित करें जो स्टेटस को आगे बढ़ाएँ ताकि स्टाफ को हर बार याद न रखना पड़े। उदाहरण के लिए: सफल भुगतान पेमैंट स्टेटस को अपने आप अपडेट कर दे; रिस्केड्यूल ड्यू डेट्स और रिमाइंडर फिर से कैलकुलेट कर दे।

अगर आप दो से ज़्यादा भुगतान अनुमति देते हैं, तो “Second payment”, “Third payment” जैसा न बनाएं। हर भुगतान को अलग रिकॉर्ड के रूप में स्टोर करें और बचा बैलेंस को योग से निकालें। स्टेटस एक सारांश बन जाता है।

स्क्रीन और संदेशों पर स्टेटस के साथ एक स्पष्ट नंबर दिखाएँ: “$120 paid, $80 due by May 12.” यह अनावश्यक बातचीत बंद कर देता है।

कदम‑दर‑कदम: डिपॉज़िट और स्प्लिट‑पेमेंट फ्लो बनाना

सबसे बेहतर बुकिंग पेमैंट वर्कफ़्लो उबाऊ लगे — यही मकसद है। स्पष्ट नंबर, साफ़ स्टेटस, और कुछ टाइम्ड संदेश जो काम कर दें।

हर बुकिंग को एक सरल टाइमलाइन मानें: बनाई गई, डिपॉज़िट देय/भुगतान हुआ, बैलेंस देय/भुगतान हुआ, पूरा (या रद्द)। हर स्टेप को टाइमस्टैम्प और कैसे हुआ (online, cash, card, transfer) चाहिए।

एक सरल फ्लो:

• बुकिंग बनाएं, फिर तुरंत डिपॉज़िट और शेष बैलेंस कैल्कुलेट करें। किस डिपॉज़िट नियम को लागू किया गया यह स्टोर करें (fixed या percent)।
• डिपॉज़िट लें, ट्रांज़ैक्शन सेव करें, और बुकिंग कन्फ़र्म करें। अगर डिपॉज़िट फेल हो, तो इसे अनकन्फ़र्म्ड रखें ताकि आप अपना कैलेंडर ब्लॉक न करें।
• अपॉइंटमेंट तारीख के आधार पर बैलेंस ड्यू डेट सेट करें, फिर उस तारीख के सापेक्ष रिमाइंडर शेड्यूल करें (उदा. 7 दिन पहले और 24 घंटे पहले)।
• जब ग्राहक बाकी चुकाता है, तो भुगतान रिकॉर्ड करें, बैलेंस को शून्य सेट करें, और बुकिंग को Paid मार्क करें (और अपॉइंटमेंट के बाद Completed)।
• अगर बुकिंग मूव या कैंसल हो, तो पहले अपॉइंटमेंट समय अपडेट करें, फिर ड्यू डेट्स और रिमाइंडर्स अपने आप शिफ्ट हों। रिफंड आपकी लिखित नीति के अनुसार हैंडल करें।

उदाहरण: ग्राहक 20 मार्च के लिए बुक करता है। डिपॉज़िट $20, बैलेंस $40। $20 मिलते ही बुकिंग कन्फ़र्म हो जाती है। सिस्टम 13 मार्च और 19 मार्च के रिमाइंडर शेड्यूल कर देता है। जब $40 आ जाता है, बुकिंग Paid दिखती है और आगे के रिमाइंडर रुक जाते हैं।

अगर आप AppMaster इस्तेमाल कर रहे हैं, Data Designer बुकिंग्स, पेमैंट शेड्यूल, और ट्रांज़ैक्शंस रख सकता है, और Business Process Editor कैलकुलेशन, स्टेटस परिवर्तन, और शेड्यूल किए गए रिमाइंडर टास्क बिना कोड के संभाल सकता है।

लोगों को परेशान किए बिना रिमाइंडर्स ऑटोमेट करें

स्वचालित पेमैंट नोटिफिकेशन का मतलब ज़रूरी तौर पर ज़्यादा संदेश नहीं होना चाहिए। इसका मतलब है सही संदेश सही समय पर, और जैसे ही ग्राहक भुगतान कर दे, संदेश रुक जाएँ।

सामान्यतः काम करने वाला टाइमिंग:

• 7 दिन पहले: हल्की सूचना (जब बुकिंग हफ्तों पहले की हो)
• 48 घंटे पहले: प्रैक्टिकल रिमाइंडर (अधिकतर अपॉइंटमेंट के लिए काम करता है)
• सुबह में: केवल अगर नो‑शोज़ आम हैं या विवरण अक्सर मिस होते हैं

रिमाइंडर संक्षिप्त रखें, पर हमेशा शामिल करें:

• देय राशि और उसके लिए क्या है (शेष बैलेंस, डिपॉज़िट नहीं)
• देय समय/तारीख और अगर मिस हुआ तो क्या होगा
• बुकिंग विवरण (तारीख, समय, स्थान या ऑनलाइन जानकारी)
• एक स्पष्ट भुगतान तरीका

सबसे तेज़ तरीका ग्राहकों को परेशान करने का है भुगतान या कैंसिलेशन के बाद रिमाइंडर भेजना। इसे गैर‑मोलभाव्य बनाएं: रिमाइंडर सिर्फ तब भेजे जाएं जब बुकिंग सक्रिय हो और बैलेंस > 0 हो। भुगतान रिकॉर्ड होते ही भविष्य के किसी भी रिमाइंडर को रद्द कर दें।

अगर आपको एस्केलेशन चाहिए, तो उसे मानव रखिए। पहला संदेश यह मानकर चले कि उन्होंने चूका है; आखिरी संदेश सख्त, विशिष्ट और टाइम‑बाउंड हो।

सामान्य गलतियाँ और उन्हें कैसे टालें

अधिकतर समस्याएँ भुगतान की वजह से नहीं होतीं। वे अस्पष्ट नियमों, गंदे स्टेटस अपडेट्स, और ऐसे रिमाइंडर्स से आती हैं जो असली ज़िन्दगी से मैच नहीं करते।

सबसे आम जाल

• डबल‑चार्जिंग या डुप्लिकेट पेमेंट: लोग दो बार टैप कर देते हैं, कार्ड के बाद ट्रांसफर कर देते हैं, या किसी साथी ने भी भुगतान कर दिया। हर भुगतान को अलग रिकॉर्ड करें और बैलेंस को पुष्टि किए गए भुगतानों के योग से निकालें। अगर आपका प्रोवाइडर सपोर्ट करता है तो idempotency keys का उपयोग करें।
• अस्पष्ट डिपॉज़िट शर्तें: “Non-refundable” अक्सर झगड़े में बदल जाता है। नियम को सटीक शब्दों में लिखें और कन्फ़र्मेशन व रसीद में दिखाएँ।
• मैनुअल स्टेटस ही सच्चाई का एकमात्र स्रोत होना: अगर स्टाफ को हर भुगतान के बाद स्टेटस बदलना याद रखना पड़ता है, तो चीजें भटकीं। “Deposit paid” और “Balance due” को भुगतान रिकॉर्ड्स और ड्यू डेट्स से व्युत्पन्न करें।
• टाइमज़ोन और डेलाइट सेविंग की गलतियाँ: “24 घंटे पहले” गलत समय पर फायर कर सकता है अगर आप सिर्फ लोकल डेट/टाइम स्टोर करते हैं। अपॉइंटमेंट समय स्पष्ट टाइमज़ोन के साथ स्टोर करें (या UTC प्लस ग्राहक का टाइमज़ोन) और रिमाइंडर टाइम वहीं से कैलकुलेट करें।
• रिस्केड्यूल का अराजकता: जब अपॉइंटमेंट मूव होता है, पुराने रिमाइंडर रद्द होने चाहिए। रिमाइंडर्स को करंट अपॉइंटमेंट टाइमस्टैम्प से जोड़ें ताकि सिर्फ नवीनतम समय ही नोटिफ़ाई कर सके।

रियलिटी चेक: अगर कोई 10:00 से 15:00 पर शिफ्ट करता है, तो आप चाहेंगे कि सिर्फ 15:00 के 24 घंटे पहले एक रिमाइंडर हो, न कि दो रिमाइंडर और एक भ्रमित ग्राहक।

लाइव जाने से पहले क्विक चेकलिस्ट

असली ग्राहकों को सिस्टम देने से पहले 3–5 नकली बुकिंग के साथ “बुक, पे, रिमाइंड” टेस्ट चलाएँ। अलग‑अलग तारीखों का उपयोग करें ताकि टाइमिंग बग दिखें।

हर बुकिंग को स्पष्ट रूप से डिपॉज़िट राशि, डिपॉज़िट देय तिथि (यदि लागू हो), और बैलेंस देय तिथि दिखानी चाहिए। अगर इनमें से कुछ भी अस्पष्ट है, तो स्टाफ अनुमान लगाएगा और ग्राहकों को मिश्रित संदेश मिलेंगे।

लॉन्च से पहले के चेक जो ज़्यादातर समस्याएँ पकड़ लेते हैं:

• डिपॉज़िट स्टेटस वास्तविक भुगतानों से मेल खाता है (और रिफंड पर वापस फ्लिप होता है)
• बैलेंस देय सही है (कुल कीमत माइनस सभी प्राप्त पेमेंट)
• रिमाइंडर शेड्यूल अपॉइंटमेंट टाइमलाइन पर आधारित है, न कि बुकिंग क्रिएशन समय पर
• कैंसिलेशन सब कुछ रोकते हैं (कोई रिमाइंडर नहीं, कोई "unpaid" कतार नहीं)
• किनारे‑के मामलों की जाँच (सैम‑डे बुकिंग, रिस्केड्यूल, और "अभी पूरा भुगतान")

एक परिदृश्य सत्यापित करें: $200 की बुकिंग बनाएं जिसमें आज $50 डिपॉज़िट और अपॉइंटमेंट से दो दिन पहले $150 देय हो। डिपॉज़िट को पेड मार्क करें, फिर $30 अतिरिक्त भुगतान जोड़ें। बैलेंस $120 दिखना चाहिए, और अगला रिमाइंडर अपॉइंटमेंट तारीख पर ही टार्गेट होना चाहिए।

एक उदाहरण परिदृश्य: डिपॉज़िट से फाइनल पेमेंट तक एक बुकिंग

एक सैलून 90‑मिनट कलर अपॉइंटमेंट $200 में ऑफर करता है। नियम सरल है: बुकिंग पर 30% डिपॉज़िट लिया जाता है ($60), और शेष 48 घंटे पहले देय है।

जब ग्राहक शुक्रवार 3:00 PM के लिए बुक करता है, तो सिस्टम एक बुकिंग और दो-पार्ट पेमैंट प्लान बनाता है: डिपॉज़िट (अब देय) और बैलेंस (बुधवार 3:00 PM देय)। डिपॉज़िट तुरंत मिल जाता है, इसलिए बुकिंग कन्फ़र्म हो जाती है। बैलेंस अभी भी देय है।

मंगलवार सुबह ग्राहक इसे शनिवार 1:00 PM पर रिस्केड्यूल करता है। डिपॉज़िट पेड रहा, पर बैलेंस ड्यू डेट अब नए समय के 48 घंटे पहले यानी गुरुवार 1:00 PM पर शिफ्ट हो जाता है। स्टाफ को कुछ भी फिर से कैलकुलेट करने की ज़रूरत नहीं पड़ती।

रिमाइंडर रिस्केड्यूल के बाद अपने आप एडजस्ट हो जाते हैं। पुराने फ्राइडे‑आधारित "बैलेंस कल देय" संदेश नहीं भेजे जाते; शेड्यूल नए अपॉइंटमेंट के चारों ओर फिर से बन जाता है। शनिवार सुबह तक स्टाफ के पास वर्तमान सच्चाई होती है, न कि एक भ्रमित इतिहास।

दिन‑प्रतिदिन प्रबंधन को आसान बनाएं

यह तभी काम करता है जब स्टाफ सेकंडों में देख सके। रोज़ाना लक्ष्य सरल है: आज क्या हो रहा है, क्या पेड है, और किसको नज़रअंदाज़ करने की ज़रूरत है।

एक साफ़ एडमिन व्यू से शुरू करें जो आने वाले कार्य पर केन्द्रित हो। इसे आने वाली बुकिंग्स (आज और अगले 7–14 दिन), ग्राहक और सेवा, अपॉइंटमेंट समय, पेमैंट स्टेटस, और बैलेंस देय/ड्यू डेट दिखानी चाहिए।

अपडेट्स तेज़ होने चाहिए। स्टाफ को बिना मेनू में खोजे भुगतान रिकॉर्ड करना, नोट जोड़ना, और रसीद जारी करना आना चाहिए।

ग्राहकों को भी स्पष्टता चाहिए। डिपॉज़िट भरने के बाद एक साधारण सारांश दिखाएँ: क्या चुका दिया गया है, क्या अभी बकाया है, और डेडलाइन क्या है। अगर स्प्लिट पेमैंट की अनुमति है, तो हर भुगतान को अलग लाइन‑आइटम के रूप में दिखाएँ ताकि "मैं पहले ही चुका चुका हूँ" के तकरार कम हों।

बुनियादी रिपोर्टिंग को दो सवालों का जवाब देना चाहिए: “हमने कितने डिपॉज़िट इकट्ठा किए?” और “अब कितना बकाया है?” इसे हल्का और फ़िल्टर करने योग्य रखें (तिथि रेंज, स्टाफ सदस्य, सेवा प्रकार से)।

भूमिकाएँ सरल रखें:

• स्टाफ बुकिंग देख सकता है, भुगतान रिकॉर्ड कर सकता है, और रसीद जारी कर सकता है
• मैनेजर रिफंड कर सकते हैं, डिपॉज़िट नियम बदल सकते हैं, ड्यू डेट ओवरराइड कर सकते हैं, और गलतियाँ ठीक कर सकते हैं

अगले कदम: वर्कफ़्लो को असल ऐप में बदलना

एक बार जब आपके डिपॉज़िट नियम और रिमाइंडर कागज़ पर काम कर रहे हों, तो उन्हें एक छोटे ऐप में डालना वही तरीका है जिससे आप स्केल करने पर एक समानता बनाये रखें।

सबसे छोटा ऐसा वर्शन चुनें जो फिर भी वास्तविक लगे। एक सेवा, एक डिपॉज़िट नियम, और एक रिमाइंडर शेड्यूल चुनें। फ्लो को सही करें, फिर धीरे‑धीरे एज़‑ए‑सर्विस जोड़ें।

एक मजबूत पहले बिल्ड में आम तौर पर बुकिंग लिस्ट, एक पेमैंट व्यू जो डिपॉज़िट और बैलेंस दिखाता है, एक्शन बटन्स: डिपॉज़िट रिकॉर्ड करने के लिए, अंतिम भुगतान रिकॉर्ड करने के लिए, और एक रिमाइंडर टेम्पलेट जो दुबारा उपयोग किया जा सके।

ग्राहकों को दिखाने से पहले अपनी पॉलिसी टेक्स्ट सामान्य भाषा में लिखें और कुछ असली लोगों के साथ टेस्ट करें। उनसे पूछें कि अगर वे कैंसिल करें तो क्या होता है और बैलेंस कब देय है — अगर उन्हें उत्तर देने में हिचक हो, तो फिर से लिखें।

अगर आप बिना कोड पूरे सिस्टम बनाना चाहते हैं, तो AppMaster (appmaster.io) एक व्यावहारिक विकल्प है जो इस वर्कफ़्लो को प्रोडक्शन‑रेडी बैकएंड, वेब ऐप और मोबाइल ऐप में बदल सकता है, डेटाबेस मॉडल और रिमाइंडर लॉजिक को एक ही जगह रखें।

जब बेसिक्स स्थिर हों, तो एक‑एक कर के सुधार जोड़ें: सेवा के अनुसार अलग डिपॉज़िट अमाउंट्स, वेटलिस्ट, बैलेंस के लिए पेमेंट लिंक, या ओवरड्यू बैलेंस पर एक अतिरिक्त रिमाइंडर।