आर्थिक गणना के विवरण के लिए भाषा - कार्यक्रम का विचार

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


आर्थिक गणनाओं का वर्णन करने के लिए भाषा का मुख्य विचार यह है कि अर्थशास्त्र की पाठ्यपुस्तकों में यह कैसे संभव है, गणनाओं के विवरण को सक्षम किया जाए। वह है, कुछ इस तरह:

लाभ = राजस्व - लागत

राजस्व = Unit_price_title * Quantity_title

आदि

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

निम्नलिखित सुविधाएँ प्रदान की जानी चाहिए:
1. डेटाबेस से डेटा निकालना
2. संदर्भ के आधार पर, विभिन्न गणनाओं का विवरण प्रदान करें।

ऐसा करने के लिए, निम्नलिखित संस्थाओं को भाषा में पेश किया जाता है:
1. शर्तों के साथ सूत्र:
सूत्रों के एक समूह से पहले या एक इकाई सूत्र से पहले, एक शर्त रख सकता है जिसके तहत इस सूत्र का उपयोग किया जा सकता है।
2. डेटा स्रोत:
उद्यम के डेटाबेस से नमूने जिसके लिए गणना की जा रही है।
(मानक डेटा स्रोत: SQL क्वेरी, DBF तालिका, सीएसवी फ़ाइल, आदि)
नाम, फ़ील्ड - स्ट्रिंग, संख्यात्मक, दिनांक
डेटा स्रोतों का उपयोग केवल डेटाबेस से डेटा निकालने के कार्यों में किया जाता है
3.Funktsii:
मानक गणित
तारीखों के साथ काम करें
डेटाबेस से डेटा निकालें
अलग-अलग कार्य: योग, अधिकतम, न्यूनतम, आदि।
4. विवरण:
टैग प्रकार:
संख्या
तिथि
बहुत
पंक्ति

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

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

लाइन में निम्नलिखित उदाहरण के पहले सूत्र में:
लाभ = राशि (लाभ [Object_Type = Shop], Object_code = Extract_Set (दुकानों की सूची, Object_ID, Parent_code = Object_code)
विकल्प लाभ [Object_Type = Shop] के विकल्प में, Object_Type टैग का मान OGPD से शॉप में बदल जाता है ताकि आगे की गणना एक ही वर्कशॉप में की जाए, और इन गणनाओं का योग OGPD के लिए हो जाता है।
प्रपत्र की एक पंक्ति {[Object_Type = OGPD] का अर्थ है कि घुंघराले कोष्ठक के बीच स्थित सभी सूत्र केवल तभी उपयोग किए जा सकते हैं यदि Object_Type = OGPD।

एक उदाहरण:

{[Object_type = NGDU]

लाभ = राशि (लाभ [Object_Type = Shop], Object_code = Extract_Set (दुकानों की सूची, Object_ID, Parent_code = Object_code)
}

{[Object_type = कार्यशाला]
लाभ = प्रोडक्शन_ऑल * प्राइस_ऑल - लागत
Oil_Oil = Sum (Oil_Oil [Object_type = Well], Object_code = Extract_Multiple (Well_list, Object_code, Parent_code = Object_code, Well_type = Injection))
}

{[Object_Type = खैर]
Oil_Oil = Ivlec_Value (उत्पादन_by_well, उत्पादन, Code_Holes = Object_code, दिनांक = निपटान तिथि)
}

यह उदाहरण परिभाषित करता है:
OGPD पर लाभ इसमें शामिल कार्यशालाओं पर लाभ की राशि है।
विभाग द्वारा लाभ को तेल की बिक्री और लागत से राजस्व के बीच अंतर के रूप में परिभाषित किया गया है। कार्यशाला में तेल उत्पादन को कुओं में उत्पादन की मात्रा के रूप में परिभाषित किया गया है।
इसका तात्पर्य 3 डेटा स्रोतों की उपस्थिति से भी है - उद्यम डेटाबेस से नमूनों की तालिकाएँ:
कार्यशालाओं की सूची कम से कम दो क्षेत्रों, Object_code और Parent_code के साथ एक तालिका है, जो निर्धारित करती है कि कौन सी कार्यशाला किस OGDU की है।
कुओं की सूची - कार्यशालाओं की सूची के समान, एक तालिका जो कुओं की संबद्धता को कार्यशालाओं में परिभाषित करती है।
इस अवधि के लिए अच्छी तरह से उत्पादन डेटा - कम से कम 3 क्षेत्रों के साथ एक तालिका: उत्पादन,
खैर कोड, तारीख।

कोड 1 के साथ OGPD के अनुसार गणना शुरू करने के लिए, आपको क्वेरी इनपुट विंडो में कुछ दर्ज करना होगा:
Object_Type = OGPD
Object_code = 1
निपटान तिथि = '01 .01.2009 '
? लाभ

मुख्य कोर में 3 मॉड्यूल होते हैं:
1. गणना के लिए सूत्रों का संपादन
2. क्वेरी विंडो
3. डेटा स्रोतों को जोड़ने के लिए एक मॉड्यूल।

यह कंप्यूटिंग कोर है।
सुविधा के लिए सेवा कार्यों का विस्तार करना काफी संभव है।
उदाहरण के लिए, निम्नलिखित विशेषताएं मेरे लिए सबसे अधिक प्रासंगिक लगती हैं:
1. एक तालिका के रूप में क्वेरी, एक भी मूल्य नहीं
2. गणना की वस्तुओं पर जानकारी दर्ज करने की क्षमता कोड से नहीं, बल्कि नामों से, यानी निर्देशिकाओं के संगठन द्वारा।
आदि

इस दृष्टिकोण के लाभ:
1. लचीलेपन - एक बार किए जाने के बाद, गणना को सहज तरीके से फिर से किया जा सकता है। इसके अलावा, अर्थशास्त्री स्वयं सरल परिवर्तन कर सकते हैं। आप एक व्यवसाय योजना के साथ शुरू होने वाली परियोजना का संचालन भी कर सकते हैं, धीरे-धीरे वास्तविक संकेतकों के साथ पूर्वानुमान मॉडल के अनुसार गणना किए गए सूत्रों से डेटा की जगह ले सकते हैं
2. बहुमुखी प्रतिभा - आप एक गणना कर सकते हैं जो विषम स्रोतों से जानकारी लेगी। कई अपेक्षाकृत स्वतंत्र सहायक कंपनियों से मिलकर बड़े संगठनों के लिए यह बहुत महत्वपूर्ण है।
3. पारदर्शिता - किसी भी परिमित मूल्य के लिए, आप गणनाओं का एक पेड़ बना सकते हैं, सभी मध्यवर्ती मूल्यों को दिखा सकते हैं। बड़ी परियोजनाओं के लिए वास्तविक जिसमें त्रुटियां अपरिहार्य हैं, जिसका मूल कारण आमतौर पर खोजना मुश्किल है।

विपक्ष:
1. सीखने की कठिनाई। फिर भी, यह पूरी तरह से एक नई भाषा है, हालांकि काफी सरल है।
2. गणना स्थापित करने की जटिलता। छोटी गणना के लिए, यह विधि बहुत बोझिल हो सकती है।

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

हो सकता है कि ऐसे लोग हैं जो उनके मालिक हैं और जो इस विचार में रुचि रखते हैं?