YAOF - रिपोर्टिंग रूपों की भाषा

तेरह साल पहले, मैंने वाईएओएफ का आविष्कार किया - रिपोर्टिंग रूपों की भाषा, और यहां तक ​​कि इसे मेरी लेखांकन पाठ्यपुस्तक में एक अध्याय के रूप में शामिल किया।

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

अब मैं समझाने की कोशिश करूंगा कि मामला क्या है।

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

मैं अपनी पूरी असहायता के कारण यहां आविष्कार किए गए "कोड" को लाने का जोखिम नहीं उठाऊंगा, लेकिन मैंने अभी भी उस तर्क को अस्वीकार नहीं किया है जो मुझे उस दूर के क्षण में ले गया था। शायद मेरे तर्क आईटी के कुछ विशेषज्ञों को समझदार विचारों के लिए प्रेरित करेंगे। संक्षेप में, विचारार्थ जानकारी।

रिपोर्टिंग रूपों के लिए एक भाषा बनाने का निर्णय लेने के बाद, मैंने जो पहली चीज़ की, वह रिपोर्ट को असंरचित और संरचित लोगों में विभाजित किया गया था:

• असंरचित रिपोर्टों, संकेतकों में, जिनमें से प्रत्येक को अलग-अलग गणना की जाती है, उन्हें टेबल पर रखा जाता है या एक शीट पर अनियंत्रित तरीके से व्यवस्थित किया जाता है, साथ में पाठ्य नाम और स्पष्टीकरण;
• संरचित रिपोर्ट - इसके विपरीत, एक स्पष्ट संरचना के साथ रिपोर्ट: अपने कुछ परिवर्तनों के माध्यम से स्रोत डेटाबेस से प्राप्त तालिकाओं के रूप में।

मुझे उनके स्पष्ट "गैर-कंप्यूटर" स्वभाव के कारण असंरचित रिपोर्टों का औपचारिकरण छोड़ना पड़ा।

"केवल संरचित रिपोर्ट, केवल परिवर्तित तालिकाएँ," मैंने तुरंत अपने लिए स्थापित किया, लेकिन रूपांतरण एक प्रारंभिक नमूने की कमी के खिलाफ आया।

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

मैंने एक मानक संरचना के साथ एक आधार को एक सामान्यीकृत तालिका कहा । किसी भी लेखांकन डेटाबेस को एक सामान्यीकृत तालिका में लाना संभव हो गया था, क्योंकि मेरे लिए किसी भी रुचि के डेटाबेस का लेखांकन किया गया था: कुछ वस्तुओं को इसमें पंजीकृत किया गया था, जिन्हें गुणों और मीटरों की एक सूची द्वारा व्यक्त एक निश्चित डेटा संरचना की आवश्यकता थी।

दी गई सरलतम सामान्यीकृत तालिका में, प्रत्येक पंक्ति एक वस्तु को दर्शाती है, एस वस्तुओं के गुण हैं, और मैं मीटर हैं:



यह काफी स्पष्ट है कि, चाहे आप लेखांकन डेटाबेस की संरचना के साथ कितने भी परिष्कृत हों, अंतिम (सरलतम) संस्करण में, यह सब उसके गुणों और मीटरों का वर्णन करते हुए, ऑब्जेक्ट को पंजीकृत करने के लिए नीचे आता है।

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

मान लीजिए कि i1 और i2 कुछ और दर्शाते हैं, वस्तुओं की संख्या नहीं है, और हमें संपत्ति 1 के अनुसार वस्तुओं की संख्या के साथ काम करने की आवश्यकता है। हमारे लिए अनावश्यक गुणों को त्यागकर, हम रूपांतरण के लिए एक तालिका प्राप्त करते हैं।



तब हम क्षेत्र S1 में प्रत्येक मान के साथ वस्तुओं की संख्या (i3) की गणना करके रूपांतरण करते हैं।



एक नया मीटर दिखाई देता है जो स्रोत तालिका में नहीं था।

इसी तरह, औसत मूल्य प्राप्त किए जा सकते हैं।

लेकिन मान लीजिए कि स्रोत तालिका में सभी आवश्यक मीटर जगह में हैं - सवाल यह है कि लेखांकन रिपोर्ट बनाते समय किस प्रकार के रूपांतरणों की आवश्यकता है? मैंने लंबे समय तक अपने आप से यह सवाल पूछा और मेरे द्वारा ज्ञात विभिन्न लेखा रिपोर्टों और बयानों को कम करने की कोशिश की (सौभाग्य से, केवल संरचित वाले) मानक परिवर्तनों के लिए।

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

पहले बहुत अच्छी तरह से जाना जाता है: एक पदानुक्रम में गुण सेट करना।

हम प्रारंभिक डेटा लेते हैं (हम केवल गुण S1 और S2 और मीटर i1 का उपयोग करते हैं - अर्थात, कुछ नमूने के बाद):



हम निम्नलिखित पदानुक्रम को परिभाषित करते हैं:



हमारे पास रूपांतरण के परिणामस्वरूप है:



लेखांकन में, ऐसे मामलों में, यह लिखने के लिए प्रथागत है: सहित ...

दूसरा तरीका संपत्ति को शीर्षक में रखना है (इस पद्धति का नाम या तो लेखांकन या कंप्यूटर विज्ञान में नहीं था, मुझे इसे स्वयं आविष्कार करना पड़ा)।

यह निम्नलिखित के बारे में है।

हम अपनी प्रारंभिक सामान्यीकृत तालिका लेते हैं:



फिर ऑब्जेक्ट के गुणों में से एक - कहते हैं, S3 - हम हेडर में, मीटर के क्षेत्र में, निम्नलिखित के साथ डालते हैं:



डेटा समान है, लेकिन तालिका का रूप पूरी तरह से अलग है। क्यों नहीं, यदि आप रिपोर्टिंग उपयोगकर्ता को इतना चाहते हैं - जिसके लिए रिपोर्टिंग डेटा का इरादा है?

जाहिर है, आप पदानुक्रम के अनुसार हेडर में रख सकते हैं - उदाहरण के लिए, ऐसे पदानुक्रम सेट करें:



इस स्थिति में, निम्न तालिका दृश्य दिखाई देता है (पहली शाखा के लिए एक टुकड़ा दिया गया है):



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

सामान्यीकृत तालिका के शेष संभावित रूपांतरण - उदाहरण के लिए, परिणामस्वरूप पंक्तियाँ - अधिक डिजाइनर हैं।

विचार किए गए उदाहरणों में, सबसे सरल प्रारंभिक डेटा का उपयोग किया गया था: वास्तविक व्यवहार में, डेटाबेस तारीख और आय-व्यय (एक विकृत लेखांकन संस्करण, डेबिट और क्रेडिट में) से जटिल है, और एक वस्तु की आय और व्यय एक साथ दर्ज नहीं किए जाते हैं। इस प्रकार, वस्तु दो बार पंजीकृत होती है: एक बार आने पर, दूसरी बार खपत पर। मीटर, प्राप्त द्वारा गणना की जाती है, लेकिन सेवानिवृत्त वस्तुएं नहीं, संतुलन (आम बोलचाल में, संतुलन)। हालाँकि, यह मीटर तालिका रूपांतरण क्षमताओं में कुछ नया नहीं जोड़ता है।

इन प्रारंभिक परिवर्तनों के लिए संरचित रिपोर्टों को कम किया जा सकता है।

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

PS लेख को पहले ही समाप्त कर चुका है, मैंने यह पता लगाने की कोशिश की कि किस अकाउंटेंट या प्रोग्रामर ने कम से कम (कम से कम) एक ही समस्या हल की है।

लेखाकारों में से, दो के दिमाग में आता है, लेखांकन में लोग प्रसिद्ध हैं।

पहला निकोलाई उस्तीनोविच पोपोव (1843 -?) है। हालांकि वह लंबे समय तक जीवित रहे और रिपोर्टिंग रूपों को औपचारिक रूप देने की समस्या को हल नहीं किया, लेकिन व्यक्तिगत लेखांकन प्रणालियों के गणितीय औचित्य की। उन दिनों, प्रोग्रामिंग तंग थी, लेकिन इसमें कोई संदेह नहीं है, अगर निकोलाई उस्तीनोविच हमारे समकालीन थे, उनकी गणितीय क्षमताओं को आवेदन मिलेगा।

स्पॉइलर के तहत, एन.यू की पुस्तक के कुछ पृष्ठ। पोपोव की "लेखांकन की गणितीय विधि" (1906), ताकि हैबरचियन इस व्यक्ति को क्या श्रेणियों के बारे में सोच सकें।



दूसरा एकाउंटेंट जिसने हल किया (और सफलतापूर्वक हल किया गया!) लेखा रिपोर्टों को औपचारिक रूप देने की समस्या हमारे समकालीन हैं, प्रोफेसर ओलेग इवानोविच कोलवाख (जन्म 1946)। उनकी अवधारणा के अनुसार, लेखांकन रिपोर्टों (प्रारंभिक डेटा, भी) को मैट्रिक्स बीजगणित के ढांचे में औपचारिक रूप दिया जाता है, इसलिए सिस्टम का नाम मैट्रिक्स लेखांकन है ।

स्पॉइलर के तहत, ओ.आई. के काम से दो पेज। कोलवाहा "लेखांकन का मैट्रिक्स मॉडल और बैलेंस शीट का गठन।"



मैट्रिक्स लेखा ओ.आई. कोलवाख को मेरी लेखांकन पाठ्यपुस्तक से पहले बनाया गया था, मैं तब इससे परिचित नहीं था, अन्यथा मैं परमाणु हथियारों के आविष्कार से बच जाता। दुर्भाग्य से, मैट्रिक्स लेखांकन, गणित के मेरे सभी ज्ञान के लिए, व्यावहारिक उपयोग में गणितीय कठोरता नहीं मिली है।

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