बिक्री कैसे दर्ज करें

बिक्री दर्ज करते समय आप क्या बना रहे हैं

Skyline Nexus में एक बिक्री transactions तालिका की एक पंक्ति है जिसका प्रकार sell होता है, साथ में बिक्री लाइनों का एक समूह, और शून्य या अधिक भुगतान रिकॉर्ड। ये तीनों जान-बूझकर अलग रखे गए हैं। इनवॉइस ग्राहक पर दावा है। लाइनें वह हैं जो शेल्फ़ से गया। भुगतान वह पैसा है जो आया। ERP में बिक्री को लेकर लोगों का अधिकांश भ्रम इन तीनों को एक ही घटना मानने से आता है, क्योंकि दुकान के काउंटर पर ये आमतौर पर एक ही क्षण में होते हैं।

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

इसलिए बिक्री दर्ज करते समय व्यावहारिक प्रश्न केवल यह नहीं कि कौन-से बटन दबाने हैं। प्रश्न यह है: इन तीनों में से अभी क्या बनाया जा रहा है, और क्या जान-बूझकर अभी नहीं बनाया जा रहा? इसका उत्तर लगभग पूरी तरह फ़ॉर्म के एक फ़ील्ड से तय होता है, और वह है "स्थिति" फ़ील्ड, जिसकी चर्चा आगे की गई है।

एक ही दस्तावेज़ तक पहुँचने के तीन दरवाज़े

बाएँ मेनू में "बिक्री" नाम का एक ड्रॉपडाउन है। इसके नीचे कई प्रविष्टियाँ हैं जो सभी अंततः एक ही प्रकार का दस्तावेज़ लिखती हैं; अंतर केवल इतना है कि वे फ़ॉर्म का कितना हिस्सा दिखाती हैं और उन्हें पूरा करना कितना तेज़ है।

तैयार दस्तावेज़ "सभी बिक्री" (/sells) में सूचीबद्ध होते हैं, चाहे कोई भी दरवाज़ा इस्तेमाल किया गया हो। ड्राफ्ट और कोटेशन की अपनी सूचियाँ हैं, "ड्राफ्ट की सूची" (/sells/drafts) और "कोटेशन की सूची" (/sells/quotations), क्योंकि वे अभी वास्तविक इनवॉइस नहीं हैं और उन्हें बिक्री सूची में भीड़ नहीं बढ़ानी चाहिए। पॉइंट-ऑफ़-सेल रसीदें अलग से "POS सूची" (/pos) में भी दिखाई देती हैं।

एक कार्यान्वयन विवरण जानने लायक है क्योंकि वह कुछ व्यवहारों की व्याख्या करता है: "बिक्री जोड़ें" फ़ॉर्म उसी कंट्रोलर को सबमिट होता है जिसे POS स्क्रीन। ये एक ही सेव रूटीन पर बने दो फ़्रंट एंड हैं। इसीलिए कर नियम, स्टॉक नियम और खाता-बही पोस्टिंग एक जैसे रहते हैं, चाहे किसी भी स्क्रीन से शुरुआत हुई हो, और इसीलिए यह अपेक्षा नहीं करनी चाहिए कि लेखे POS रसीद और "बिक्री जोड़ें" इनवॉइस के साथ अलग व्यवहार करेंगे।

• "POS" (/pos/create) टच-प्रथम काउंटर स्क्रीन है। एक ग्राहक, उत्पादों की ग्रिड, एक भुगतान पैनल, और कुछ ही सेकंड में काम पूरा। रिटेल, रेस्तराँ और काउंटर पर होने वाले किसी भी व्यापार के लिए यही सही दरवाज़ा है।
• "बिक्री जोड़ें" (/sells/create) पूरा इनवॉइस फ़ॉर्म है। हर फ़ील्ड दिखाई देता है: इनवॉइस स्कीम, मुद्रा, भुगतान अवधि, शिपिंग, कस्टम फ़ील्ड, कई भुगतान पंक्तियाँ। B2B इनवॉइस, डिलीवरी-आधारित बिक्री, या क्रेडिट शर्तों वाली किसी भी बिक्री के लिए यही सही दरवाज़ा है।
• "सीधी बिक्री" (/sells/direct/create) सीधे-सादे इनवॉइस के लिए "बिक्री जोड़ें" का संक्षिप्त संस्करण है।
• "ड्राफ्ट जोड़ें" (/sells/create?status=draft) और "कोटेशन जोड़ें" (/sells/create?status=quotation) फिर वही फ़ॉर्म हैं, जो पहले से तय स्थिति के साथ खुलते हैं ताकि गलती से अंतिम रूप न दिया जा सके।
• "बिक्री आदेश जोड़ें" (/sells/create?sale_type=sales_order) ग्राहक का ऐसा ऑर्डर दर्ज करता है जिसका इनवॉइस बाद में बनेगा। यह केवल तभी दिखाई देता है जब POS सेटिंग्स में सेल्स ऑर्डर चालू हों।

"बिक्री जोड़ें" स्क्रीन भरना

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

"इनवॉइस नं." तक पहुँचना जान-बूझकर कठिन रखा गया है। यह केवल उन उपयोगकर्ताओं को दिखता है जिनके पास इनवॉइस नंबर संपादित करने की अनुमति है, और केवल तब तक जब दस्तावेज़ ड्राफ्ट है, सहायता पाठ "ऑटो जेनरेट करने के लिए खाली रखें" के साथ। यही सही डिज़ाइन है। जिस इनवॉइस नंबर को कैशियर बदलकर लिख सके, वह अनुक्रम नहीं है, और टूटा हुआ अनुक्रम वह पहली चीज़ है जिस पर कर लेखा परीक्षक का ध्यान जाता है।

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

स्थिति लगभग सब कुछ तय करती है

"बिक्री जोड़ें" पर "स्थिति" फ़ील्ड "अंतिम", "प्रारूप", "कोटेशन" और "प्रोफार्मा" विकल्प देता है। यह फ़ॉर्म का सबसे परिणामकारी फ़ील्ड है, क्योंकि आगे का लगभग हर व्यवहार इसी पर निर्भर है।

ड्राफ्ट नियम का एक जान-बूझकर रखा गया अपवाद है, और चौंकाने से पहले इसे जान लेना अच्छा है। POS सेटिंग्स के अंतर्गत एक व्यावसायिक सेटिंग, जिसका लेबल "ड्राफ्ट इनवॉइस के लिए स्टॉक घटाएं" है, शुद्ध ड्राफ्ट को सेव के समय स्टॉक घटाने वाला बना देती है और उन्हें बिक्री, लाभ, बिक्री की लागत और नकदी-प्रवाह रिपोर्टों में ठीक एक पूर्ण नकद बिक्री की तरह गिनती है। यह डिफ़ॉल्ट रूप से बंद है और उत्पाद का सहायता पाठ यह स्पष्ट रूप से कहता है। इसे केवल तभी चालू करें जब आप वास्तव में ड्राफ्ट को पिकिंग दस्तावेज़ के रूप में इस्तेमाल करते हों, और समझ लें कि तब आपने ड्राफ्ट को वित्तीय रूप से वास्तविक बना दिया है।

व्यावहारिक नियम: यदि माल जा चुका है और ग्राहक पर आपका बकाया है, तो स्थिति "अंतिम" है। इसके अलावा कुछ भी हो, तो आप एक इरादा दर्ज कर रहे हैं, लेन-देन नहीं। जिस गलती की आपको चिंता है उससे बचने के लिए ड्राफ्ट का उपयोग न करें, क्योंकि जो ड्राफ्ट कभी अंतिम नहीं होता वह ऐसी बिक्री है जो कहीं दिखाई ही नहीं देती।

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

बिक्री पर कर की गणना कैसे होती है

कर बिक्री में दो स्तरों पर आ सकता है, और यह अंतर मायने रखता है। लाइन कर वह कर दर है जो किसी एक उत्पाद पंक्ति से जुड़ी होती है। ऑर्डर कर पूरे दस्तावेज़ पर लागू एक दर है, जिसे उत्पाद ग्रिड के नीचे "ऑर्डर कर" फ़ील्ड में चुना जाता है। अधिकांश व्यवसाय इनमें से एक का उपयोग करते हैं। एक ही दस्तावेज़ पर दोनों का उपयोग वह जगह है जहाँ अन्य सिस्टमों में लोग मुश्किल में पड़ते हैं, और Skyline Nexus ठीक इसी त्रुटि को रोकने के लिए बना है।

ऑर्डर कर ऐसे आधार पर लगाया जाता है जिसमें वे लाइनें शामिल नहीं होतीं जिन पर पहले से अपना लाइन कर है। जिस लाइन की अपनी दर हेडर दर के बराबर हो, वह हेडर कर आधार में कुछ नहीं जोड़ती। सरल शब्दों में: सिस्टम वैट पर वैट नहीं लगाएगा, और दस्तावेज़ दर पर पहले से कर लगी लाइन पर दोबारा कर नहीं लगाएगा। यह इनवॉइस-योग रूटीन का एक गणना नियम है, कोई ऐसी सेटिंग नहीं जिसे टिक करना याद रखना पड़े।

कीमत कर-सहित बताई गई है या कर-रहित, यह उत्पाद का गुण है, इनवॉइस का नहीं। उत्पाद फ़ॉर्म पर "सेलिंग प्राइस टैक्स टाइप" नाम का फ़ील्ड है जिसमें "समावेशी" और "विशेष" विकल्प हैं। फिर लाइन दोनों आँकड़े संग्रहीत करती है, कर से पहले की इकाई कीमत और कर सहित इकाई कीमत, ताकि इनवॉइस दोबारा गणना किए बिना कोई भी दिखा सके। बिक्री फ़ॉर्म पर पंक्ति-वार कर चयनकर्ता केवल तभी दिखता है जब व्यवसाय के लिए इनलाइन कर चालू हो; यदि यह बंद है, तो कर उत्पाद से और ऑर्डर कर फ़ील्ड से आता है।

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

भुगतान इनवॉइस से अलग रिकॉर्ड है

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

यदि बिक्री उधार पर है, तो "क्रेडिट बिक्री — पूरी राशि देय" पर टिक करें। यह भुगतान राशि को शून्य कर देता है, भुगतान पंक्तियाँ छिपा देता है और सेव रूटीन को भुगतान रिकॉर्ड बनाना पूरी तरह छोड़ने को कहता है। इनवॉइस जारी होता है, प्राप्य राशि बनी रहती है, और पैसा बाद में वसूला जाता है। उधार बिक्री दर्ज करने का यही सही तरीका है; शून्य-मूल्य की भुगतान पंक्ति दर्ज करना सही तरीका नहीं है।

दस्तावेज़ की भुगतान स्थिति टाइप नहीं की जाती, निकाली जाती है। जब कुल प्राप्त राशि कम से कम इनवॉइस योग के बराबर हो तो यह "भुगतान हो चुका" होती है, जब कुछ प्राप्त हुआ हो पर सब नहीं तो "आंशिक", और जब कुछ भी न मिला हो तो "देय"। हर बार भुगतान जोड़ने, संपादित करने या हटाने पर यह गणना फिर से चलती है, इसीलिए बाद के भुगतान इनवॉइस संपादित करके नहीं, बल्कि बिक्री सूची पर "भुगतान जोड़ें" (/payments/add_payment/{id}) से वसूलने चाहिए। आँकड़े मिलाने के लिए इनवॉइस संपादित करना गलत प्रवृत्ति है, और इस पर लेन-देन रद्द करने और सुधारने वाली गाइड में चर्चा की गई है।

बिक्री स्टॉक के साथ क्या करती है

जब बिक्री "अंतिम" के रूप में सेव होती है, तो हर लाइन उस व्यावसायिक स्थान पर उस उत्पाद वेरिएशन की उपलब्ध मात्रा घटा देती है। जिन उत्पादों का स्टॉक ट्रैक नहीं होता उन्हें छोड़ दिया जाता है: जिस उत्पाद का स्टॉक प्रबंधन बंद है उसके लिए घटाने वाला रूटीन कुछ नहीं करता, और इसी तरह नकारात्मक इन्वेंटरी बनाए बिना उसी स्क्रीन से सेवाएँ और श्रम बेचे जा सकते हैं।

इसके बाद एक दूसरा चरण चलता है जिसे लोग शायद ही देखते हैं पर जिसके बारे में उन्हें जानना चाहिए। बेची गई हर मात्रा उन विशिष्ट खरीद लाइनों के सामने आवंटित की जाती है जिनसे वह आई, और यह आवंटन संग्रहीत होता है। यही मैपिंग बिक्री की लागत को अनुमानित के बजाय वास्तविक बनाती है: सिस्टम जानता है कि किस लागत पर हुई कौन-सी खरीद ने कौन-सी बिक्री की आपूर्ति की। यही बैच और एक्सपायरी नियम लागू करती है, और यही सॉफ़्टवेयर को वहाँ ओवरसेल से इनकार करने देती है जहाँ इसकी अनुमति नहीं है।

क्योंकि यह आवंटन बिक्री के क्षण में बनता है, इसलिए हफ़्तों देर से दर्ज की गई बिक्री, ऐसे स्टॉक के सामने जो तब से हिल चुका है, उस समय की तुलना में अलग ढंग से आवंटित होगी। यह बग नहीं, अंकगणित है, और बिक्री को उसी दिन दर्ज करने का यह सबसे मज़बूत व्यावहारिक तर्क है जिस दिन वह होती है।

सामान्य खाता-बही में क्या पोस्ट होता है

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

तीन शर्तें सभी पूरी होनी चाहिए वरना कुछ पोस्ट नहीं होता, और यह निष्कर्ष निकालने से पहले कि खाता-बही ख़राब है, तीनों जाँच लेना उचित है। पहली, बिक्री "अंतिम" होनी चाहिए। ड्राफ्ट, कोटेशन और प्रोफार्मा डिज़ाइन के अनुसार छोड़ दिए जाते हैं। दूसरी, व्यवसाय के लिए /accounting/settings पर लेखांकन सेटिंग्स में "बिक्री लेन-देन स्वतः पोस्ट करें" चालू होना चाहिए। तीसरी, खाते मैप होने चाहिए: एक प्राप्य खाता, एक राजस्व खाता और एक आउटपुट वैट खाता, जो /accounting/settings/mapping पर कॉन्फ़िगर होते हैं। मैपिंग न होने से कुछ भी दूषित नहीं होता, बस पोस्टिंग से इनकार हो जाता है।

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

ई-इनवॉइसिंग, जहाँ लागू हो

सऊदी अरब में, बिक्री "अंतिम" के रूप में सेव होते ही ई-इनवॉइसिंग मॉड्यूल इनवॉइस अपने आप बनाता और दाखिल करता है। यह पूरे व्यवसाय के लिए नहीं, बल्कि व्यावसायिक स्थान-वार सक्षम होता है, ताकि कोई कंपनी एक स्थान को ई-इनवॉइसिंग व्यवस्था के तहत चला सके जबकि दूसरा अभी नामांकित न हो। कॉन्फ़िगरेशन /zatca/configuration पर है।

दाखिल करना इडेम्पोटेंट है: सिस्टम दर्ज रखता है कि क्या पहले ही दाखिल हो चुका है और एक ही इनवॉइस को दो बार दाखिल नहीं करेगा। यदि दाखिल करना विफल हो जाए, तब भी बिक्री सेव रहती है। यह जान-बूझकर लिया गया निर्णय है, क्योंकि कर प्राधिकरण का एंडपॉइंट उपलब्ध न होने के कारण बिक्री खो देना उसे कुछ मिनट देर से दाखिल करने से कहीं बुरा होगा। विफल दाखिले को बिक्री से ही दोबारा भेजा जा सकता है।

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

सेव करने के बाद

बिक्री "सभी बिक्री" में अपने इनवॉइस नंबर, ग्राहक, योग, भुगतान स्थिति और, जहाँ प्रासंगिक हो, ई-इनवॉइस स्थिति के साथ दिखाई देती है। पंक्ति मेनू से इसे देखा, प्रिंट किया जा सकता है, इसमें भुगतान जोड़ा जा सकता है, इसके भुगतान देखे जा सकते हैं, या इसके सामने वापसी शुरू की जा सकती है। /sells/show/{id} पर विवरण दृश्य लाइनें, कर विवरण और भुगतान इतिहास एक ही जगह दिखाता है, और जब कोई पूछे कि किसी विशेष इनवॉइस पर क्या हुआ, तो यही स्क्रीन खोलनी चाहिए।

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

एक छोटी चेकलिस्ट

• क्या स्थान सही है? यह स्टॉक, क्रमांकन, भुगतान खाते और ई-इनवॉइसिंग तय करता है।
• क्या स्थिति "अंतिम" है? इसके अलावा कुछ भी हो, तो वह अभी बिक्री नहीं है।
• क्या बिक्री तिथि वह तारीख है जब बिक्री वास्तव में हुई, न कि वह तारीख जब इसे टाइप किया जा रहा है?
• यदि ग्राहक ने भुगतान नहीं किया है, तो क्या शून्य भुगतान पंक्ति के बजाय "क्रेडिट बिक्री — पूरी राशि देय" टिक किया गया है?
• यदि यह उधार बिक्री है, तो क्या भुगतान अवधि तय है ताकि इनवॉइस की एजिंग सही हो?
• क्या सेव करने से पहले, बाद में नहीं, योग पट्टी पर कर के आँकड़े सही दिखते हैं?