रिटर्न और रिफंड रिपोर्ट कैसे बनाएं: एक संपूर्ण गाइड

एक स्टोर 12% रिटर्न रेट की रिपोर्ट करता है। इसमें से एक-तिहाई मामलों में भौतिक रूप से कुछ भी वापस नहीं आया।
यह डेटा में कोई त्रुटि नहीं है। ऐसा तब होता है जब रिफंड को रिटर्न के रूप में दर्ज किया जाता है, और अधिकांश प्लेटफॉर्म बिल्कुल इसी तरह गणना करते हैं।
यह अंतर तब तक मामूली लग सकता है जब तक कि ऑपरेशन्स टीम का कोई व्यक्ति आपके इस आंकड़े के आधार पर वेयरहाउस की क्षमता की योजना न बनाने लगे।
यह गाइड बताती है कि रिटर्न और रिफंड रिपोर्ट में क्या होना चाहिए, और ये दोनों शब्द अलग-अलग घटनाओं को क्यों दर्शाते हैं। इसके बाद, यह उस तारीख की समस्या पर चर्चा करती है जो चुपके से मासिक तुलनाओं को बिगाड़ देती है, और एक्सपोर्ट से रिपोर्ट कैसे तैयार की जाए, यह सिखाती है।
रिटर्न और रिफंड रिपोर्ट में क्या होना चाहिए
एक ही व्यू में पांच चीजें होनी चाहिए, और रेट केवल उनमें से एक है।
रिफंड की गई राशि, रिफंड किए गए ऑर्डर की संख्या, अवधि, वह हर (denominator) जिससे आपने भाग दिया है, और पूर्ण व आंशिक रिफंड के बीच का विभाजन।
यदि आपका प्लेटफॉर्म रीज़न कोड कैप्चर करता है, तो उन्हें भी जोड़ें। रेट आपको समस्या का आकार बताता है, और कारण आपको यह बताते हैं कि समस्या वास्तव में क्या है।
शुरुआत में शिपिंग और टैक्स को बाहर रखें। आमतौर पर दोनों को अलग से ट्रैक किया जाता, और उन्हें मिलाने से बाद में आंकड़ों का मिलान करना असंभव हो जाता है।
रिटर्न और रिफंड एक ही चीज़ नहीं हैं
प्लेटफॉर्म के दस्तावेज़ इस बारे में बेहद स्पष्ट हैं, और इसके सटीक शब्दों को पढ़ना फायदेमंद होगा।
WooCommerce का analytics documentation दोनों को सीधे अलग करता है। इसमें कहा गया है कि "रिफंड उस ट्रांजेक्शन को दर्शाता है जो ग्राहक को पैसे वापस भेजता है।"
उस परिभाषा का दूसरा हिस्सा महत्वपूर्ण है। रिटर्न मीट्रिक रिफंड की गई राशि को रिकॉर्ड करता है "चाहे रिफंड पूर्ण हो या आंशिक और चाहे सामान भौतिक रूप से वापस किया गया हो या नहीं।"
इसलिए किसी क्षतिग्रस्त आइटम के लिए दिया गया गुडविल क्रेडिट भी रिटर्न में गिना जाता है, भले ही कोई सामान वापस न भेजा गया हो। प्राइस एडजस्टमेंट भी इसी में आता है।
यही एक वाक्य कारण है कि कॉमर्स एनालिटिक्स से लिए गए रिटर्न के आंकड़े को वेयरहाउस टीम को भौतिक रिटर्न के पूर्वानुमान के रूप में नहीं सौंपा जा सकता है।
शिपिंग और टैक्स को भी अलग रखा जाता है। रिफंड किए गए शिपिंग शुल्क और रिफंड किए गए टैक्स को रिफंड की संख्या में शामिल नहीं किया जाता है। इसके बजाय, वे शिपिंग और टैक्स के आंकड़ों में नकारात्मक मान के रूप में दिखाई देते हैं।
तारीख की समस्या
यह समस्या किसी एक सेल के बजाय आपकी पूरी ट्रेंड लाइन को बदल देती है, जो इसे और भी बदतर बना देती है।
WooCommerce रिफंड को "उस तारीख पर एक नकारात्मक संख्या के रूप में रिकॉर्ड करता है जिस दिन रिटर्न हुआ था (न कि उस तारीख को जब ऑर्डर दिया गया था)।"
सोचिए कि यह मासिक तुलना पर क्या असर डालता है। फरवरी के ऑर्डर के बदले मार्च में किया गया रिफंड मार्च के खाते में जाता है, और फरवरी के रेवेन्यू को कभी सुधारा नहीं जाता है।
अब दोनों महीने विपरीत दिशाओं में थोड़े गलत हो जाते हैं। फरवरी अपनी वास्तविक स्थिति से बेहतर दिखता है, और मार्च पर एक ऐसा खर्च आ जाता है जो उसने खुद नहीं किया था।
इसके दो उचित समाधान हैं, और आपको लिखित रूप में किसी एक को चुनना होगा।
रिफंड की तारीख पर रिपोर्ट बनाएं और रिपोर्ट को कैश व्यू के रूप में लेबल करें। यह आपके बैंक और आपके प्लेटफॉर्म से मेल खाएगा, लेकिन यह कभी भी कोहोर्ट एनालिसिस से मेल नहीं खाएगा।
या फिर प्रत्येक रिफंड को उसकी मूल ऑर्डर तारीख पर वापस असाइन करें। यह प्रत्येक बिक्री अवधि की वास्तविक तस्वीर देता है, और इसका मतलब है कि पिछले महीने का आंकड़ा आपके द्वारा प्रकाशित किए जाने के बाद बदल जाएगा।
दोनों में से कोई भी गलत नहीं है। बिना यह बताए रिपोर्ट प्रकाशित करना गलत है कि आपने किसका उपयोग किया है।
हर (Denominator) का चुनाव करना
रिटर्न रेट के लिए एक भाजक की आवश्यकता होती, और तीन सामान्य भाजक हैं जो तीन अलग-अलग आंकड़े देते हैं।
| Denominator | रेट का क्या अर्थ है | किसके लिए सर्वोत्तम है |
|---|---|---|
| Orders in the period | उन ऑर्डर्स का हिस्सा जिनमें पैसे वापस मिले | कस्टमर सर्विस लोड |
| Units shipped | वापस आने वाले आइटम्स का हिस्सा | वेयरहाउस और रीस्टॉकिंग |
| Net sales value | रिवर्स हुए रेवेन्यू का हिस्सा | फाइनेंस और मार्जिन |
दर्शकों के अनुसार चुनाव करें। फाइनेंस रिव्यू के लिए वैल्यू वाला संस्करण चाहिए, और ऑपरेशन्स रिव्यू के लिए यूनिट्स चाहिए।
फिर इसके आस-पास के बिक्री के आंकड़ों को लेकर सावधान रहें, क्योंकि वे भी परिभाषित हैं। WooCommerce ग्रॉस सेल्स को रिफंड, कूपन, टैक्स और शिपिंग को छोड़कर कीमत गुणा मात्रा के रूप में देता है, और नेट सेल्स को ग्रॉस सेल्स में से रिटर्न और कूपन घटाकर देता है।
वहां एवरेज ऑर्डर वैल्यू नेट सेल्स को ऑर्डर्स से विभाजित करके निकाली जाती है। इसलिए रिफंड पहले से ही उस AOV के अंदर मौजूद होते हैं जिसे आप कहीं और उद्धृत कर रहे होंगे।
रॉ ई-कॉमर्स ऑर्डर्स को सेल्स ट्रेंड रिपोर्ट में बदलने के बारे में हमारी गाइड turning raw e-commerce orders into a sales trend report उसी एक्सपोर्ट के रेवेन्यू पक्ष को कवर करती है।
इसे मैन्युअल रूप से कैसे करें
विकल्प 1: दो टोटल और एक डिवीज़न
उस अवधि के लिए रिफंड रिकॉर्ड्स को फ़िल्टर करें, फिर SUMIFS का उपयोग करके रिफंड की गई कुल राशि का योग निकालें।
COUNTIFS के साथ प्रभावित ऑर्डर्स की गणना करें COUNTIFS, और यदि एक ही ऑर्डर में कई रिफंड हो सकते हैं, तो पहले ऑर्डर आइडेंटिफायर्स को डुप्लिकेट-मुक्त करें।
अंत में एक बार भाग दें। दोनों टोटल को दृश्यमान रखने से ही कोई अन्य व्यक्ति आपके काम की जांच कर सकता है।
इसकी सीमाएं बहुत जल्दी सामने आ जाती हैं। आपको एक अवधि के लिए एक रेट मिलता है, जिसमें यह देखने का कोई तरीका नहीं होता कि किन प्रोडक्ट्स या कारणों से ऐसा हुआ।
विकल्प 2: प्रति रिफंड एक रो
प्रति रिफंड एक रो वाली एक टेबल बनाएं। इसमें ऑर्डर की तारीख, रिफंड की तारीख, बीच के दिन, रिफंड की गई राशि, पूर्ण या आंशिक, और कारण के कॉलम होने चाहिए।
बाद वाली तारीख से पहले वाली तारीख को घटाकर दिनों के अंतर की गणना करें। DATEDIF फ़ंक्शन पर Microsoft का मार्गदर्शन DATEDIF function चेतावनी देता है कि यह "कुछ विशेष परिस्थितियों में गलत परिणाम दे सकता है।"
अब रिपोर्ट को अलग-अलग हिस्सों में बांटा जा सकता है। प्रोडक्ट के अनुसार, कैटेगरी के अनुसार, चैनल के अनुसार, कारण के अनुसार, या रिफंड लैग के अनुसार।
लैग वाला कॉलम सबसे कम आंका जाने वाला कॉलम है। खरीदारी के 40 दिनों के बाद रिफंड का एक समूह टिकाऊपन की ओर इशारा करता है, और चार दिनों में रिफंड का समूह साइजिंग या विवरण की ओर इशारा करता है।
इसकी सीमा डेटा का वॉल्यूम और जॉइन्स हैं। रिफंड को ऑर्डर लाइन्स और प्रोडक्ट डेटा से मिलाना उस सीमा से बाहर चला जाता है जहां फॉर्मूले सरल और आसान बने रहें।
विकल्प 3: एक डेफिनिशन टैब
यह रिकॉर्ड करें कि आप किस तारीख पर रिपोर्ट कर रहे हैं, हर क्या है, और क्या शिपिंग और टैक्स शामिल हैं।
फिर एक्सक्लूशन्स रिकॉर्ड करें। रद्द किए गए ऑर्डर जो कभी शिप नहीं हुए, टेस्ट ट्रांजेक्शन और चार्जबैक, प्रत्येक के लिए एक स्पष्ट नियम की आवश्यकता होती है।
चार्जबैक वह चीज़ है जिसे लोग भूल जाते हैं। पैसे चले जाते हैं, कोई रिटर्न रिकॉर्ड नहीं होता है, और दोनों सिस्टम हमेशा के लिए असहमत रहते हैं।
सीमा यह है कि केवल नियम लिख देने से वह लागू नहीं हो जाता। अगले महीने कोई फिर से वही फ़िल्टर दोबारा बनाएगा।
साझा सीमा। ये तीनों मानकर चलते हैं कि एक्सपोर्ट में दोनों तारीखें मौजूद हैं। यदि इसमें केवल रिफंड की तारीख है, तो उस फ़ाइल से कोहोर्ट व्यू को वापस नहीं पाया जा सकता है।
मैन्युअल तरीका कहाँ धीमा पड़ जाता है
पहली रिपोर्ट बनाने में एक सुबह लगती है। चौथी रिपोर्ट में अधिक समय लगता है, क्योंकि तीन चीजें बदल चुकी होती हैं।
आंशिक रिफंड बढ़ते जाते हैं। तीन आंशिक रिफंड वाला एक ऑर्डर तीन रो बन जाता है, और रो गिनकर बनाई गई ऑर्डर की संख्या अब गलत हो जाती है।
प्रोडक्ट कैटलॉग बदलते रहते हैं। एक रीनेम किया गया SKU एक प्रोडक्ट के इतिहास को दो भागों में विभाजित कर देता है, और सबसे खराब प्रदर्शन करने वाला प्रोडक्ट आपकी सूची के शीर्ष से गायब हो जाता है।
फिर परिभाषाएं चुपचाप बदल जाती हैं। कोई इस महीने रिफंड किए गए शिपिंग को शामिल कर लेता है क्योंकि यह अधिक पूर्ण लग रहा था, और ट्रेंड टूट जाता है।
एक चौथा नुकसान भी है जो केवल मीटिंग में सामने आता है। जब कोई पूछता है कि फाइनेंस के पास एक अलग आंकड़ा क्यों है, तो इसका जवाब एक डेट कन्वेंशन होता है जो एक ऐसे टैब में होता है जिसे आप साथ नहीं लाए थे।
टूलिंग पक्ष का अपना विवरण AI tools for e-commerce analytics में है।
How to build it with Powerdrill Bloom
स्टेप 1: अपने ऑर्डर और रिफंड एक्सपोर्ट्स अपलोड करें
ऑर्डर फ़ाइल और रिफंड फ़ाइल को एक साथ अपलोड करें। Powerdrill Bloom आने पर कॉलमों का विश्लेषण करता है, इसलिए किसी भी रेट की गणना करने से पहले गायब रिफंड तारीखें, डुप्लिकेट ऑर्डर आइडेंटिफायर्स और असंगत SKU मान सामने आ जाते हैं।
स्टेप 2: रिपोर्ट का प्राकृतिक भाषा में वर्णन करें
नियमों को बनाने के बजाय उन्हें स्पष्ट रूप से लिखें। उस तारीख का नाम बताएं जिस पर आप रिपोर्ट कर रहे हैं, हर, क्या शिपिंग और टैक्स शामिल हैं, और किसे बाहर रखना है।
फिर वे प्रश्न पूछें जो त्रुटियों को पकड़ते हैं। पूछें कि कितने ऑर्डर्स में एक से अधिक रिफंड हैं। पूछें कि कौन से रिफंड उनके मूल ऑर्डर की रिपोर्टिंग अवधि से बाहर आते हैं। फिर प्रोडक्ट और रीज़न कोड के अनुसार रेट मांगें।
स्टेप 3: चार्ट, रिपोर्ट या डेक एक्सपोर्ट करें
इसके हर के साथ रेट, दिनों में रिफंड लैग का वितरण, या ऐसी स्लाइड्स निकालें जिनमें संख्या के बगल में डेट कन्वेंशन लिखा हो.
सामान्य गलतियाँ
रिटर्न को भौतिक रिटर्न मानना। प्लेटफॉर्म मीट्रिक्स रिफंड की गई राशि की गणना करते हैं, चाहे सामान वापस आया हो या नहीं। स्पष्ट करें कि आपका क्या मतलब है।
हर के बिना रेट की रिपोर्ट करना। ऑर्डर्स, यूनिट्स और वैल्यू तीन अलग-अलग उत्तर देते हैं। रिपोर्ट पर अपना वाला नाम लिखें।
रिफंड की तारीख और ऑर्डर की तारीख को मिलाना। कोई एक नियम चुनें, उसे लेबल करें, और कभी भी दोनों के बीच तुलना न करें।
चुपचाप रिफंड किए गए शिपिंग और टैक्स को शामिल करना। दोनों को आमतौर पर अलग से ट्रैक किया जाता है। उन्हें जोड़ने से फाइनेंस के साथ मिलान करना असंभव हो जाता है।
ऑर्डर्स के बजाय रो गिनना। आंशिक रिफंड प्रति ऑर्डर कई रो बनाते हैं। गिनने से पहले डुप्लिकेट हटाएं।
चार्जबैक को अनदेखा करना। बिना किसी रिफंड रिकॉर्ड के पैसे चले जाते हैं। तय करें कि वे कहाँ दिखाई देंगे और इसे लिख लें।
प्रकाशित उद्योग दर से तुलना करना। अन्य रिटेलर्स अन्य हर और अन्य तारीख के नियमों का उपयोग करते हैं। सबसे पहले अपने खुद के ट्रेंड से तुलना करें।
निष्कर्ष
रिफंड ट्रांजेक्शन को रिटर्न वैल्यू से अलग करें, एक डेट कन्वेंशन चुनें, एक हर चुनें, और उस बेस के बगल में रेट की रिपोर्ट करें जिससे वह आया है।
रेट अंतिम परिणाम नहीं है। प्रोडक्ट, कारण और रिफंड लैग के अनुसार विभाजन ही आपको यह बताता है कि लिस्टिंग, साइज चार्ट या सप्लायर में से किसे ठीक करना है।
यदि हर महीने उस विभाजन को फिर से बनाने में एक दिन लग जाता है, तो अपने ऑर्डर एक्सपोर्ट पर Powerdrill Bloom आज़माएं। CSV AI assistant और AI report generator पेज भी देखें।
अक्सर पूछे जाने वाले प्रश्न
रिटर्न और रिफंड में क्या अंतर है?
रिफंड वह ट्रांजेक्शन है जो पैसे वापस भेजता है। रिटर्न, एक मीट्रिक के रूप में, वस्तुओं और सेवाओं के रिफंड किए गए मूल्य को रिकॉर्ड करता है, चाहे कुछ भी भौतिक रूप से वापस किया गया हो या नहीं।
मैं रिटर्न रेट की गणना कैसे करूं?
रिफंड की गई गतिविधि को एक निर्दिष्ट बेस से विभाजित करें, फिर 100 से गुणा करें। बेस ऑर्डर्स, शिप की गई यूनिट्स, या नेट सेल्स वैल्यू हो सकता है, और प्रत्येक एक अलग आंकड़ा देता है.
क्या मुझे रिफंड की तारीख या ऑर्डर की तारीख पर रिपोर्ट करनी चाहिए?
दोनों में से कोई भी, जब तक आप इसे लेबल करते हैं। रिफंड की तारीख आपके प्लेटफॉर्म और आपके बैंक से मेल खाती है, जबकि ऑर्डर की तारीख प्रत्येक बिक्री अवधि की अधिक वास्तविक तस्वीर देती है।
क्या रिफंड किए गए शिपिंग और टैक्स गिने जाते हैं?
आमतौर पर रिफंड की संख्या के अंदर नहीं। WooCommerce इसके बजाय शिपिंग और टैक्स के आंकड़ों में रिफंड किए गए शिपिंग और टैक्स की रिपोर्ट करता है।
मेरा आंकड़ा फाइनेंस से अलग क्यों है?
अक्सर डेट कन्वेंशन के कारण, और उसके बाद यह कि क्या शिपिंग, टैक्स और चार्जबैक शामिल हैं। आंकड़ों की तुलना करने से पहले परिभाषाओं की तुलना करें।