समय और सीमा, उद्देश्य, उपयोग के उदाहरण बताएं। समय और सीमा के बिंदु, उद्देश्य, उपयोग के उदाहरण I. दस्तावेज़ की तारीख को आगे बढ़ाने का विश्लेषण

लेखांकन का आधार कंपनी के संचालन को दर्शाने वाले दस्तावेजों से बना है। उन्होंने कुछ खरीदा, कुछ बेचा। बहुत सारे दस्तावेज़ हैं और उन्हें किसी तरह व्यवस्थित किया जाना चाहिए। आख़िरकार, हम पहले कुछ बेच नहीं सकते और फिर कुछ खरीद नहीं सकते :)

दस्तावेज़ों को एक समय रेखा पर व्यवस्थित किया जाता है। प्रत्येक दस्तावेज़ में एक तारीख होती है, या यूं कहें कि दूसरे दस्तावेज़ में तारीख और समय होता है।

इसलिए, 1सी में तारीख का बहुत महत्व है और यह उतना सरल नहीं है जितना पहली नज़र में लगता है।

दस्तावेज़ दिनांक 1C

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

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

यदि बिक्री दस्तावेज़ की तारीख और समय खरीद दस्तावेज़ की तारीख और समय से अधिक है, तो 1सी आपको एक त्रुटि देगा - "स्टॉक में पर्याप्त सामान नहीं हैं..."।

समय में क्षण 1C

और यदि दस्तावेज़ों की तारीख और समय समान है, तो उन्हें कैसे अलग किया जा सकता है?

उपयोगकर्ता के दृष्टिकोण से - बिलकुल नहीं। हालाँकि, प्रोग्राम कोड की ओर से, उन्हें अतिरिक्त रूप से ऑर्डर किया जाता है - "समय में बिंदु" द्वारा।

एप्लिकेशन का सार एक ही समय में बनाए गए दस्तावेज़ों को व्यवस्थित करना है। इसलिए, समय में एक क्षण में शामिल हैं:

• तिथि और समय
• किसी विशिष्ट दस्तावेज़ का लिंक.

दिनांक 1С का अनुप्रयोग और समय 1С का क्षण

एक अद्भुत उदाहरण है-पार्टी लेखा-जोखा। ऐसा तब होता है जब हम एक ही उत्पाद को कई बार अलग-अलग कीमतों पर खरीदते हैं। और जब हम इसे बेचना शुरू करते हैं - हमने कौन सा उत्पाद बेचा - वह जो अधिक महंगा है या वह जो सस्ता है?

और उदाहरण के लिए, हम FIFO तकनीक का उपयोग करके इसकी गणना करना शुरू करते हैं - यानी। हम जो पहले आया उसे पहले बेचने में विश्वास करते हैं। लेकिन ऐसा करने के लिए, आपको गणना करने की आवश्यकता है - कौन सा दस्तावेज़ पहले पोस्ट किया गया था?

1सी का ऑपरेटिव और नॉन-ऑपरेटिव कार्यान्वयन

इसे तब क्रियाशील माना जाता है जब यह समयरेखा का अंतिम दस्तावेज़ होता है। जब हम "कल" ​​तारीख वाला दस्तावेज़ पोस्ट करते हैं तो यह निष्क्रिय हो जाता है।

उपयोगकर्ता की समझ में, परिचालन निष्पादन तब माना जाता है जब हम दस्तावेज़ को "अभी" ("वर्तमान तिथि पर") संसाधित करते हैं। साथ ही, आमतौर पर कुछ लोग यह सोचते हैं कि "अभी" क्या है।

पूरा सवाल यह है कि परिचालन कार्यान्वयन के दौरान शुद्धता के लिए सभी प्रकार की जांच की जाती है। उदाहरण के लिए, क्या हम इतना बेच सकते हैं, क्या हमारे पास स्टॉक में इतना है?

यदि यह निष्क्रिय है, तो यह माना जाता है कि अब जाँच करने की कोई आवश्यकता नहीं है, क्योंकि यह "कल का" ऑपरेशन है जो पहले ही हो चुका है, तो इसकी जाँच क्यों करें?

जैसा कि हम देख सकते हैं, दिनांक और समय का उपयोग करके आप न केवल लेखांकन परिणामों में हेरफेर कर सकते हैं, बल्कि सुरक्षा और अक्षम चेक भी कर सकते हैं।

1सी की प्रासंगिकता तिथि और 1सी के परिणाम

प्रत्येक दस्तावेज़ अपने परिणाम के कुछ आंकड़ों के आधार पर टुकड़ों या पैसों में लेखांकन को "चलता" है। वह परिणाम को एक बड़ी तालिका - एक रजिस्टर - में लिखता है। यानी सभी दस्तावेज रजिस्टरों के अनुसार किए जाते हैं।

सबसे पहले, हम तुरंत समझ जाते हैं कि इस तालिका में पंक्तियों का क्रम दस्तावेज़ की तारीख और उसके समय बिंदु पर निर्भर करता है।

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

जिस तिथि को उपयोग की गणना की जाती है उसे वास्तविक तिथि कहा जाता है।

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

अनुक्रम [दस्तावेज़ों का] 1 सी

प्रत्येक रजिस्टर (तालिका) पर अलग-अलग दस्तावेज़ लिखे जाते हैं। उदाहरण के लिए, गोदाम शेष तालिका में कम से कम माल की खरीद (माल को छोड़कर) और माल की बिक्री (माल को घटाकर) लिखें।

इनमें से प्रत्येक दस्तावेज़ को पीछे की ओर दर्ज किया जा सकता है (यानी, पिछली तारीख से, यानी पुरानी तारीख के साथ) और परिणामों को "बर्बाद" किया जा सकता है। इसके अलावा, उत्पाद की बिक्री की तारीख उत्पाद की खरीद की तारीख पर निर्भर करती है।

इसके अलावा, प्रत्येक दस्तावेज़ को कई रजिस्टरों के माध्यम से संसाधित किया जाता है। इस प्रकार हमारे पास कई दस्तावेज़ + कई रजिस्टर हैं।

ऐसे दस्तावेज़ों को तिथियों के सामान्य क्रम पर निर्भर करते हुए संयोजित करने के लिए एक क्रम होता है। हम दोनों दस्तावेज़ों को अनुक्रम में शामिल करते हैं और यह एक दस्तावेज़ के लिए नहीं, बल्कि कई दस्तावेज़ों के लिए सामान्य हो जाता है।

प्रासंगिकता कैसे बहाल करें? अनुक्रम में पंजीकृत सभी दस्तावेज़ों को एक-एक करके (तिथि के अनुसार!) दोबारा पोस्ट करें।

1सी संपादन पर प्रतिबंध की तिथि

उपयोगकर्ताओं की ऐसी घृणित आदत से निपटने का एक तरीका दस्तावेज़ों के संपादन पर प्रतिबंध की 1C तिथि (सीमा) है।

आमतौर पर, यह तिथि व्यवस्थापक द्वारा मानक कॉन्फ़िगरेशन सेटिंग्स में निर्धारित की जाती है और उपयोगकर्ता इस निर्धारित 1C तिथि से पहले कोई दस्तावेज़ नहीं बना या संपादित नहीं कर सकते हैं।

दिनांक 1C वास्तव में कहाँ है?

उपयोगकर्ता एक दस्तावेज़ दर्ज करता है। 1सी आपको दस्तावेज़ प्रविष्टि तिथि निर्धारित करने की आवश्यकता है। मैं इसे कहां से प्राप्त कर सकता हूं?

हमारे लिए यह सरल है - घड़ी को देखो। केवल कौन से?

1C के लिए कई दिनांक स्रोत हैं और जब कई उपयोगकर्ता विभिन्न कंप्यूटरों से एक साथ काम करते हैं, तो संभावित भ्रम पैदा करने में यह बहुत महत्वपूर्ण है, खासकर यदि यह विभिन्न समय क्षेत्रों में एक संघीय नेटवर्क है।

कंप्यूटर दिनांक

डिफ़ॉल्ट रूप से, 1C उस कंप्यूटर की तारीख [घंटे] का उपयोग करता है जिस पर उपयोगकर्ता काम कर रहा है। यह वह तारीख है जो 1सी - करंटडेट () में आमतौर पर उपयोग किए जाने वाले फ़ंक्शन द्वारा लौटाई जाती है।

इस स्थिति में, समस्या तब होती है जब नेटवर्क पर कई उपयोगकर्ता हों और उनकी कंप्यूटर घड़ी ख़राब हो सकती है।

उपयोगकर्ता 1C दिनांक

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

1C सर्वर दिनांक

जब सर्वर 1C का उपयोग किया जाता है तो यह विशेष रूप से दिलचस्प हो जाता है। इसका मतलब है कि प्रोग्राम का एक हिस्सा उपयोगकर्ता के कंप्यूटर पर चलता है, और कुछ सर्वर पर चलता है।

सर्वर पर समान कोड निष्पादित करते समय, currentDate() फ़ंक्शन सर्वर की 1C तिथि लौटाएगा, और यदि यह क्लाइंट कंप्यूटर पर 1C तिथि से भिन्न है, तो यह ठीक काम करेगा।

दिनांक समय क्षेत्र 1C

1सी संस्करण 8.2 में, बहुत पहले नहीं, जब वेब क्लाइंट सामने आया, तो उन्होंने समय क्षेत्रों के साथ काम करने का ध्यान रखा। वास्तव में, यदि एक वेब क्लाइंट का उपयोग किया जाता है, और यहां तक ​​कि रूस या दुनिया के विभिन्न हिस्सों में भी, तो सब कुछ और भी जटिल हो जाता है।

कॉन्फ़िगरेशन में अब currentSessionDate() फ़ंक्शन शामिल है, जो समय क्षेत्र के लिए समायोजित कंप्यूटर दिनांक लौटाता है।

हालाँकि, ट्रेड मैनेजमेंट 11 (थिन क्लाइंट) के एक विशिष्ट कॉन्फ़िगरेशन में, इस फ़ंक्शन का विशेष रूप से उपयोग नहीं किया जाता है और यदि आप कंप्यूटर पर घड़ी बदलते हैं, तो दस्तावेज़ क्लाइंट तिथि के साथ आज्ञाकारी रूप से बनाया जाएगा।

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

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

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

1सी के साथ मेरे अनुभव के बारे में कुछ शब्द

एक समय में, मैंने एक बड़े प्रोजेक्ट में 1C प्रोग्रामर के रूप में काम किया, फिर मैंने प्रोजेक्ट मैनेजर का पद संभाला, और काफी लंबे समय तक मैं प्रोजेक्ट विभाग का प्रमुख था, जो विशेष रूप से 1C में कार्यों से निपटता था।

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

दूसरी ओर, मैं 1सी उत्पादों के साथ निरंतर काम से दूर होता जा रहा हूं। यदि मेरे करियर की शुरुआत में 1C कार्यक्रमों के साथ काम करने से मुझे अपनी आय का 100% प्राप्त होता था, तो आज कुछ 1C समाधानों के कार्यान्वयन में मेरे काम का 20% से अधिक खर्च नहीं होता है, बाकी सब कुछ वेबसाइट, सीआरएम सिस्टम आदि हैं।

इसलिए, जबकि मैं अभी तक 1सी कार्यक्रम से संबंधित मुद्दों से बहुत दूर नहीं गया हूं, मैंने अपने ज्ञान को व्यवस्थित करने, इन सॉफ्टवेयर उत्पादों के साथ काम करने के महत्वपूर्ण पहलुओं और बारीकियों को इकट्ठा करने और रिकॉर्ड करने का फैसला किया।

1सी के बारे में थोड़ा और और मैं यह सब क्यों लिख रहा हूं

मैं स्वयं जानता हूं कि मैं, जैसा कि वे कहते हैं, विशालता को अपनाने वाला हूं। इसलिए, एक और चेतावनी:

1. मैं 1सी के बारे में लेखों की एक पूरी श्रृंखला बनाने की योजना बना रहा हूं, जहां मैं विभिन्न दृष्टिकोणों से इस सॉफ्टवेयर उत्पाद के बारे में बात करूंगा। यह आलेख मुख्य रूप से प्रोग्रामर्स के लिए है। इसीलिए मैं इसे हैबे पर पोस्ट कर रहा हूं। निम्नलिखित अवधारणाओं की एक विस्तृत श्रृंखला को कवर करेगा, जिसमें व्यवसायियों और 1सी सॉफ्टवेयर उत्पादों के उपयोगकर्ताओं की रुचि भी शामिल है, और इसलिए उन्हें मेगामाइंड पर पोस्ट किया जाएगा।
2. मैं कोड या अन्य तकनीकी विवरणों का उपयोग करने की बारीकियों में नहीं जाऊंगा, जिन्हें आप में से प्रत्येक आधिकारिक 1सी वेबसाइट, समर्थन साइटों, प्रसिद्ध मंचों आदि पर स्वयं पढ़ सकता है।
3. मैं इस बात की बारीकियों पर चर्चा नहीं करूंगा कि प्लेटफ़ॉर्म का यह या वह संस्करण कैसे काम करता है। इसके अलावा, अक्सर मैं लेखन के समय नवीनतम प्लेटफॉर्म 8.3 के बारे में बात करूंगा, साथ ही विशिष्ट कॉन्फ़िगरेशन के बारे में भी बात करूंगा जो मेरे ग्राहकों (मध्यम और छोटे व्यवसायों) के बीच सबसे अधिक मांग में हैं।

साथ ही, मैं किसी वेब प्रोग्रामर या अन्य विशेषज्ञ को यह समझने में मदद नहीं करना चाहता कि कोड का सही टुकड़ा कहां देखना है, मैं उन्हें यह समझने में मदद करना चाहता हूं कि यह क्या है - 1सी।

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

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

मैं "ऑक्टोपस के तम्बू" को सुलझाने की कोशिश करूंगा और 1C प्रणाली कैसे काम करती है इसकी एक सामान्य समझ तैयार करूंगा।

हम प्रोग्रामर्स को यह भी याद दिलाना चाहेंगे कि आप 1सी वेबसाइट पर कोई भी तकनीकी जानकारी पा सकते हैं। मैं इन बारीकियों पर ध्यान केंद्रित करने की बिल्कुल भी योजना नहीं बनाता। जहां तक ​​संभव होगा मैं बुनियादी मुद्दों पर सरल भाषा में लिखूंगा।

और यदि आपको 1C की किसी विशिष्ट तकनीकी बारीकियों की आवश्यकता है, तो आप हमेशा निम्नलिखित संसाधनों का उपयोग कर सकते हैं:

1. 1सी वेबसाइट और पार्टनर फोरम। http://www.1c.ru
2. अन्य संसाधन

अधिकांश मामलों में, आपके प्रश्नों के उत्तर इनमें से किसी एक संसाधन पर मिलेंगे। बहुत सारे मंच और अन्य चीजें हैं, लेकिन अधिकांश समाधान वहीं हैं।

एक पारिस्थितिकी तंत्र के रूप में 1C

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

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

लेख में मैंने पहले ही कहा था कि वास्तव में 1C को संपूर्ण पारिस्थितिकी तंत्र के रूप में माना जाना चाहिए। यह वह दृष्टिकोण है जो आपको यह समझने में मदद करेगा कि 1सी क्या है और इसकी आवश्यकता क्यों है।

तो, तकनीकी पारिस्थितिकी तंत्र के दृष्टिकोण से, 1C में निम्नलिखित घटक शामिल हैं:

1. 1C प्लेटफ़ॉर्म वह आधार है जिस पर कॉन्फ़िगरेशन लिखे जाते हैं, जिसके साथ प्रोग्रामर काम करते हैं, आदि। इसे संस्करण दर संस्करण अपडेट किया जाता है, और इसलिए यह हो सकता है: 6.0, 7.7, 8.0, 8.2 या 8.3।
2. विन्यास। यह विशिष्टता का अगला स्तर है. कॉन्फ़िगरेशन को 1C कोड का उपयोग करके प्लेटफ़ॉर्म पर लिखा जाता है। उपयोगकर्ता कॉन्फ़िगरेशन के साथ काम करते हैं.
3. 1सी बिट्रिक्स। वेबसाइटों के साथ काम करने की एक प्रणाली, इसके बारे में अलग से बात करने लायक है।

एक अन्य पहलू जिसमें 1सी कार्य को संरचित किया जा सकता है वह है संगठनात्मक स्तर। और यहाँ 2 भाग हैं जो एक दूसरे के बिना काम नहीं करते हैं:

1. 1सी कंपनी स्वयं और उसके विशेषज्ञों का स्टाफ।
2. 1C भागीदार (फ़्रेंचाइज़िंग) और सिस्टम रखरखाव में शामिल विशेषज्ञ। वे पारिस्थितिकी तंत्र के घटकों में से एक के रूप में भी उजागर करने लायक हैं। 1सी को अंतिम रूप देने और लागू करने वाले विशेषज्ञों के बिना, सिस्टम काम नहीं करेगा। ये 1सी पार्टनर कंपनियां या एकल फ्रीलांसर हो सकते हैं, इससे कोई फर्क नहीं पड़ता, उन्हें बस होना ही होगा, अन्यथा सिस्टम व्यवहार्य नहीं होगा।

इसके बाद, मैं 1सी इको-सिस्टम के हिस्सों पर करीब से नज़र डालने का प्रस्ताव करता हूं।

प्लैटफ़ॉर्म

प्लेटफ़ॉर्म वह आधार है जिस पर 1C प्रोग्रामर, 1C प्रोग्रामिंग भाषा का उपयोग करके, उपयोगकर्ताओं के लिए तैयार प्रोग्राम (कॉन्फ़िगरेशन) लिखते हैं। प्लेटफ़ॉर्म वह आधार है जिसके बिना कोई भी घटक या कॉन्फ़िगरेशन काम नहीं करेगा। उसी समय, कॉन्फ़िगरेशन के बिना प्लेटफ़ॉर्म विशेष रूप से 1C प्रोग्रामर के लिए रुचिकर हो सकता है; अन्य सभी (उपयोगकर्ताओं, विभिन्न विशेषज्ञों) के लिए यह बेकार है।

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

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

1C के साथ काम करते समय, प्रोग्रामर एक विशेष प्रोग्रामिंग भाषा का उपयोग करते हैं जिसे 1C डेवलपर्स द्वारा 1C प्लेटफॉर्म के साथ काम करने के लिए बनाया गया था। आज यह रूसी और अंग्रेजी में उपलब्ध है, लेकिन मूल रूप से रूसी में लिखा गया था, और इसलिए मानक कॉन्फ़िगरेशन भी पारंपरिक रूप से रूसी में लिखे गए हैं, हालांकि ऑपरेटरों के अंग्रेजी संस्करणों का सही जगह पर उपयोग करना हमेशा संभव होता है, अगर यह अधिक सुविधाजनक हो। प्रोग्रामर उस तरह से काम करने के लिए। यह भाषा क्वेरी लिखने के लिए SQL के अतिरिक्त बेसिक और C+ का मिश्रण है। इसके अलावा, यह विभिन्न कंस्ट्रक्टर और प्लगइन्स का उपयोग करने की क्षमता प्रदान करता है।

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

एक और टिप्पणी जो आशा के साथ आग की लपटों और विवादों से बचने में मदद करेगी:

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

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

प्लेटफ़ॉर्म डिलीवरी विकल्प

प्लेटफ़ॉर्म चुनते समय समाधान वितरण विकल्पों पर ध्यान देना बहुत महत्वपूर्ण है। पहली चीज़ जो आपके लिए महत्वपूर्ण है वह है डेटा के साथ काम को व्यवस्थित करने की विधि:

• फ़ाइल समाधान
• क्लाइंट-सर्वर विकल्प

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

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

इस समस्या को हल करने के लिए, 1C कंपनी डेटा कैशिंग आज़माने की कोशिश कर रही है, लेकिन यह विधि अब तक और भी अधिक समस्याएँ लाती है। यदि किसी को इस विषय में रुचि है, तो बस खोज इंजन में "1C कैश समस्याएँ" टाइप करें; खोज में इस बारे में विभिन्न प्रकार की समस्याओं के साथ बहुत सारे फ़ोरम और चर्चाएँ होंगी, जो अंततः इस तथ्य पर आकर टिक जाएंगी कि कैशिंग क्या करता है हमेशा सही ढंग से काम नहीं करते.

डेटा भंडारण का क्लाइंट-सर्वर संगठन सर्वर पर तालिकाओं में डेटाबेस का संगठन है। यह MSSQL, Oracle या कोई अन्य डेटाबेस संगठन विकल्प हो सकता है।

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

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

विभिन्न प्लेटफार्मों के लिए 1सी के संस्करण

आज आप अलग-अलग प्लेटफ़ॉर्म पर काम करने के लिए 1C सॉफ़्टवेयर के विभिन्न संस्करण चुन सकते हैं। यहां यह भी पता लगाने लायक है कि किस मामले में क्या खरीदने लायक है।

तो, 1C के संस्करण हैं:

• विंडोज के लिए,
• लिनक्स के लिए.

लेखन के समय, Mac OS के लिए कोई संस्करण विकसित नहीं किया गया है।

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

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

घटक आधार 1C

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

हम 1सी प्लेटफॉर्म के घटकों के बारे में क्या कह सकते हैं:

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

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

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

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

1C प्लेटफ़ॉर्म में कई अलग-अलग घटक शामिल हैं जिन्हें लगातार जोड़ा जा रहा है, जिससे इस उत्पाद की क्षमताओं का विस्तार हो रहा है। दस्तावेज़ों, निर्देशिकाओं, विभिन्न रजिस्टरों के अलावा, सूचना के इनपुट/आउटपुट के लिए विभिन्न घटक भी हैं, अर्थात्। उपयोगकर्ता इंटरफेस।

इस सुविधा के आधार पर, आप चुन सकते हैं:

1. मूल 1C क्लाइंट. यह एक पारंपरिक सॉफ़्टवेयर इंटरफ़ेस है जब 1C को 1C से एक्सेस किया जाता है।
2. ब्राउज़र के माध्यम से कार्य करें.
3. मोबाइल एप्लिकेशन के माध्यम से कार्य करें.

प्रत्येक विकल्प की कुछ सीमाएँ हैं; आप आधिकारिक 1सी वेबसाइट पर उनके बारे में अधिक पढ़ सकते हैं।

स्थानीय ग्राहक

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

इन उप-ग्राहकों के बीच क्या अंतर है?

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

वेब क्लाइंट (ब्राउज़र के माध्यम से काम करें)

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

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

मोबाइल वर्शन

1C से क्लाइंट का यह संस्करण अपेक्षाकृत हाल ही में सामने आया है और अभी तक इसकी बहुत अधिक मांग नहीं है। इस रवैये के कारण:

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

मोबाइल संस्करण में बहुत सी चीज़ें संयोजित होनी चाहिए; इसमें कई विशेषज्ञों के काम की आवश्यकता होती है जो एक साथ काम करेंगे और एक दूसरे की मदद करेंगे:

• बाहर से डेटाबेस तक पहुंच स्थापित करना;
• सुरक्षा संबंधी समस्याओं का समाधान;
• मोबाइल एप्लिकेशन के साथ काम करने के लिए सर्वर स्थापित करना;
• 1सी सॉफ़्टवेयर उत्पाद स्थापित करना;
• वेब एप्लिकेशन सेट करना (यदि आवश्यक हो)।

1सी मोबाइल एप्लिकेशन के सही संचालन को सुनिश्चित करने के लिए यह सब आवश्यक है। यह स्पष्ट है कि विशेषज्ञों की ऐसी टीम को इकट्ठा करना कठिन और महंगा है, और इसलिए यह समाधान छोटे और मध्यम आकार के व्यवसायों में लोकप्रिय नहीं है।

प्लेटफार्म 1सी: सारांश

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

ऐसे प्रोग्रामर को ढूंढना बहुत मुश्किल है जो प्रोग्राम स्तर पर सब कुछ एक साथ समझ सके: 1सी के साथ काम करना, वेब प्रोग्रामिंग, मोबाइल एप्लिकेशन के साथ काम करना आदि। यह वैचारिक स्तर पर संभव है, अर्थात। उस पर जहां मैं अब अपना ज्ञान साझा कर रहा हूं।

लेकिन ग्राहक आमतौर पर इसे नहीं समझते हैं, और मांग करने लगते हैं कि 1सी प्रोग्रामर विभिन्न क्षमताओं को लागू करे।

दूसरी ओर, 1C प्लेटफ़ॉर्म लगातार बदल रहा है, इसमें बड़ी संख्या में विकल्प, कई अलग-अलग समाधान हैं, और परिणामस्वरूप - बड़ी संख्या में बग और उनके समाधान हैं।

यह सब मिलकर स्थिति निर्धारण की समस्या उत्पन्न करता है:

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

तो, संक्षेप में 1C प्लेटफ़ॉर्म के बारे में: संभावनाओं की एक बड़ी संख्या, लचीलेपन का एक उच्च स्तर, कई अलग-अलग समाधान। और साथ ही: कार्यान्वयन की निम्न गुणवत्ता, समाधान की लगातार बढ़ती जटिलता, प्रत्येक संस्करण में बड़ी संख्या में बग।

वैचारिक स्तर पर, मुझे लगता है कि पर्याप्त जानकारी है। और आप हमेशा उन 1सी संसाधनों पर तकनीकी बारीकियाँ पा सकते हैं जिनकी मैंने ऊपर अनुशंसा की थी।

विन्यास

1C कॉन्फ़िगरेशन तैयार सॉफ़्टवेयर समाधान हैं जो प्लेटफ़ॉर्म के एक विशिष्ट संस्करण के आधार पर बनाए जाते हैं। कॉन्फ़िगरेशन वह है जिसके साथ उपयोगकर्ता सीधे काम करते हैं, सॉफ़्टवेयर वातावरण जिसमें वे वर्तमान रिकॉर्ड रखते हैं, दस्तावेज़ प्रवाह, निर्देशिकाओं आदि के साथ काम करते हैं। उपयोगकर्ता अक्सर यह नहीं जानते होंगे कि उनके पास किस प्रकार का प्लेटफ़ॉर्म है। लेकिन वे हमेशा जानते हैं कि किस विशिष्ट कॉन्फ़िगरेशन का उपयोग किया जाता है।

कॉन्फ़िगरेशन हैं:

1. मानक - 1सी कंपनी द्वारा लिखित। वे सभी 1सी वेबसाइट पर मौजूद हैं।
2. असामान्य - साझेदार कंपनियों द्वारा लिखित।

उपयोगकर्ता स्तर पर, दो प्रकार इस प्रकार प्रतिष्ठित हैं:

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

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

गैर-मानक कॉन्फ़िगरेशन भी दो प्रकार में आते हैं:

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

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

सारांश

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

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

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

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

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

बेशक, लेखांकन कार्यों के लिए, कॉन्फ़िगरेशन (बाद में बीपी के रूप में संदर्भित) 2.0 के फायदे और सुविधाएं हैं, लेकिन फिर भी, यूपीपी का मुख्य आकर्षण इसका उत्पादन सर्किट है, जिसका किसी भी 1 सी समाधान (सिवाय) में कोई एनालॉग नहीं है। दुर्भाग्य से, इस विशेष मनोवैज्ञानिक लाभ को उलटना मुश्किल है; यह केवल प्रबंधन के दृढ़ इच्छाशक्ति वाले निर्णय से ही प्राप्त किया जा सकता है कि जो लोग दोबारा प्रशिक्षण नहीं लेंगे उन्हें निकाल दिया जाएगा।

1सी यूपीपी और 1सी अकाउंटिंग के बीच अंतर

मुख्य नकारात्मक बिंदु जो यूपीपी को बीपी से अलग करते हैं, जिनका मुझे अभ्यास में सामना करना पड़ा:

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

1सी पर 267 वीडियो पाठ निःशुल्क प्राप्त करें:

अब हमें इन और अन्य तकनीकी संभावनाओं के बारे में अधिक विस्तार से बात करनी चाहिए जो लेखांकन को प्रभावित कर सकती हैं। और साथ ही, 1C UPP हमें क्या विकल्प प्रदान करता है?

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

उदाहरण: अधिकांश एकाउंटेंट एक ऑपरेशन का उपयोग करके जारी किए गए ऋणों पर ब्याज दर्शाते हैं, जो पत्राचार Dt91 Kt76 को दर्शाता है, हालांकि, 1C UPP में यह दृष्टिकोण प्रभावित नहीं करेगा, उदाहरण के लिए, समकक्षों के साथ पारस्परिक निपटान का रजिस्टर। आपको वस्तुओं और सेवाओं की बिक्री दस्तावेज़ का उपयोग करना चाहिए।

यह अलग से उल्लेख करने योग्य है कि ऑपरेशन दस्तावेज़ का उपयोग करना संभव है, लेकिन केवल रजिस्टर समायोजन दस्तावेज़ के संयोजन में, और यह दस्तावेज़ किसी भी अप्रस्तुत उपयोगकर्ता को भ्रमित कर सकता है।

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

1सी यूपीपी में कुछ "ऑफ-बैलेंस शीट" खातों की अनुपस्थिति, उदाहरण के लिए, एमसी खाते। दरअसल, परिचालन में आने वाली सामग्रियों को एमसी खाते में बीपी खाते में शामिल किया जाता है। यूपीपी में, संचालन में हस्तांतरित सामग्रियों के बारे में जानकारी को "संचालन में सामग्री" रजिस्टर में ध्यान में रखा जाता है; उनके बारे में जानकारी "संचालन में सामग्रियों का विवरण" रिपोर्ट का उपयोग करके प्राप्त की जा सकती है।

माह के अंत में समापन प्रक्रिया का अभाव, जो बहुत करीब और समझने योग्य है। हां, ऐसी प्रोसेसिंग एससीपी में शामिल नहीं है। एक महीने का समापन "माह समापन प्रक्रिया" व्यवसाय प्रक्रिया का उपयोग करके किया जाता है, जो "माह समापन सेटअप" निर्देशिका तत्व का उपयोग करता है।

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

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

भरने के लिए विवरणों की संख्या में वृद्धि। बेशक, विवरणों की संख्या में वृद्धि हुई है। हालाँकि, उपयोगकर्ता सेटिंग्स के लिए धन्यवाद, ऐसे अधिकांश विवरण स्वचालित रूप से भरे जा सकते हैं।

इस स्थिति से बाहर निकलने के उपाय

एक नियम के रूप में, हमारे सामने आने वाली अधिकांश समस्याओं के कई समाधान होते हैं। इस स्थिति में, उदाहरण के लिए, मैं इस पर प्रकाश डाल सकता हूँ:

एक कंपनी में लेखा विभाग की स्थिति बहुत मजबूत थी, वे वास्तव में 1C UPP 1.3 पर अतीत में वापस जाना पसंद नहीं करते थे, परियोजना विफलता के खतरे में थी... सौभाग्य से, कंपनी के पास उत्कृष्ट वित्तीय क्षमताएं थीं... परिणाम सभी लेखांकन रिपोर्टों को पूरी तरह से फिर से लिखना और उन्हें बीपी 2.0 के रूप में लाना, दस्तावेज़ लॉग में नए दस्तावेज़ जोड़ना, दस्तावेज़ लॉग फ़ॉर्म पर खोज फ़ॉर्म प्रदर्शित करना था। यह महंगा साबित हुआ: विकास के संदर्भ में और आगे के समर्थन के संदर्भ में, लेकिन लेखा विभाग ने इसके महत्व को महसूस किया, और परियोजना जारी रही।

हालाँकि यह विकल्प बहुत प्रभावी नहीं लगता है, लेकिन यह जीवन में मौजूद है।

एक बिल्कुल विपरीत समाधान प्रबंधन की ओर से केवल मौजूदा कार्यक्षमता का उपयोग करने का सख्त निर्देश होगा। वैसे, यह संपूर्ण लेखांकन की अनुमति देता है और इसमें सभी नियंत्रण तंत्र हैं। यह दृष्टिकोण कंपनी के लिए इष्टतम है!

उन कार्यान्वयनकर्ताओं के लिए जो मानक या अपने स्वयं के कॉन्फ़िगरेशन के साथ काम करते हैं - और जो 1सी: प्लेटफ़ॉर्म विशेषज्ञ पर प्रमाणन की तैयारी कर रहे हैं।

इस लेख में हम देखेंगे:

• कैसे प्रबंधित ताले का सही ढंग से उपयोग करेंदस्तावेजों के ऑपरेटिव और नॉन-ऑपरेटिव प्रसंस्करण के लिए
• इससे क्या हो सकता है कोई अवरोध नहीं
• उन गलतियों से कैसे बचें जिनका तुरंत पता नहीं चलता और जिनके गंभीर परिणाम हो सकते हैं :)

पढ़ने का समय: 20 मिनट.

तो, 1C:Enterprise 8.3 में संतुलन को नियंत्रित करने की दो विधियाँ

आइए इस तथ्य से शुरू करें कि पदनाम "पुरानी पद्धति" और "नई पद्धति" काफी मनमाने हैं। वास्तव में, यदि 2010 से एक "नई तकनीक" का उपयोग किया जा रहा है, तो यह अब बहुत नई नहीं है :)

हालाँकि, हम एक बार फिर यहीं रुकने को मजबूर हैं, क्योंकि इन दृष्टिकोणों के बीच अंतर करना आवश्यक है और यह महत्वपूर्ण है.

"पुरानी पद्धति" अवशेषों को नियंत्रित करने का एक दृष्टिकोण है जिसका उपयोग 1C:एंटरप्राइज़ 8.0 के दिनों से किया जा रहा है।

2010 से, प्लेटफ़ॉर्म के विकास और 1C:Enterprise 8.2 के साथ नई क्षमताओं को जोड़ने के साथ, एक "नई पद्धति" लागू की गई है ( हालाँकि - हर जगह नहीं).

क्या अंतर है?

मूलभूत अंतर अवशेषों के नियंत्रण के क्षण में है:

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

नई तकनीक के फायदे और नुकसान पर एक अलग लेख में विस्तार से चर्चा की गई है, इसलिए हम खुद को केवल सामान्य थीसिस तक ही सीमित रखेंगे - नई तकनीक प्रदर्शन और स्केलेबिलिटी के मामले में अधिक इष्टतम है.

ठीक है, तो पुरानी तकनीक अतीत की बात हो गई है और यही यूटी 10.3 की नियति है?

नहीं, यह पूरी तरह सच नहीं है.

नई पद्धति का उपयोग माल को बट्टे खाते में डालते समय किया जा सकता है सभी आवश्यक डेटा दस्तावेज़ में है और इसकी गणना करने की आवश्यकता नहीं है.

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

इसलिए, यदि मात्रा और लागत पर डेटा अलग-अलग रजिस्टरों में संग्रहीत किया जाता है तो नई पद्धति को सफलतापूर्वक लागू किया जा सकता है।

उदाहरण के लिए, इस तरह:

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

यहां मात्रा और लागत दोनों के लिए एक रजिस्टर का उदाहरण दिया गया है:

विशिष्ट विन्यास के बारे में क्या? यह सिर्फ एक नई तकनीक है, है ना?

हमेशा नहीं!

उदाहरण के लिए, "1C: ट्रेड मैनेजमेंट 11.3" में 2 रजिस्टर हैं:

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

यूटी 11 एक नई तकनीक का उपयोग करता है, क्योंकि दस्तावेजों को पोस्ट करने के लिए सभी डेटा नियंत्रित रजिस्टरों तक पहुंच के बिना प्राप्त किया जा सकता है।

जहाँ तक "1सी: लेखांकन" का सवाल है, मात्रा और लागत दोनों वहां संग्रहीत हैं एक रजिस्टर मेंलेखा विभाग, संबंधित लेखा खातों पर।

इसीलिए BP 3.0 पुरानी तकनीक का उपयोग करता है.

कृपया ध्यान दें कि यूटी 11 में मात्रात्मक और लागत लेखांकन अलग-अलग विश्लेषणों के साथ किया जाता है। उदाहरण के लिए, लागत को संगठन, प्रभाग, प्रबंधक, गतिविधि के प्रकार, वैट इत्यादि द्वारा अतिरिक्त रूप से बनाए रखा जाता है।

इस लेख में, हम संतुलन को नियंत्रित करने के पुराने और नए दोनों तरीकों के लिए अवरोधन का विश्लेषण करेंगे।

दस्तावेजों के शीघ्र प्रसंस्करण के बारे में

इस सरल प्रश्न के बारे में अक्सर ग़लतफ़हमियाँ होती हैं।

कभी-कभी यह माना जाता है कि परिचालन कार्यान्वयन एक नई विधि का उपयोग करके अवशेषों का नियंत्रण है। यह "बिल्कुल" शब्द से सत्य नहीं है।

अवशेषों की निगरानी करते समय परिचालन प्रदर्शन का विश्लेषण किया जा सकता है, लेकिन यह आवश्यक नहीं है।

परिचालन कार्यान्वयन- यह दस्तावेज़ की यहां और अभी, यानी वास्तविक समय में उभरती घटनाओं को रिकॉर्ड करने की क्षमता है।

इसे एक विशेष दस्तावेज़ संपत्ति का उपयोग करके कॉन्फ़िगर किया गया है:

"यहाँ और अभी पंजीकरण करें" का क्या मतलब है? त्वरित रूप से संसाधित दस्तावेज़ों के लिए प्लेटफ़ॉर्म कई कार्य करता है:

• आज पोस्ट किए गए दस्तावेज़ों को वर्तमान समय निर्दिष्ट किया गया है
• यदि दो दस्तावेज़ एक साथ पोस्ट किए जाते हैं, तो प्रत्येक का अपना समय होगा (अर्थात, सिस्टम दस्तावेज़ों को अलग-अलग सेकंड में स्थान देगा)
• दस्तावेज़ भविष्य की तारीख पर पोस्ट नहीं किए जा सकते.

लेकिन मुख्य बात यह है कि सिस्टम संचारित करता है कार्यकुशलता का प्रतीकप्रसंस्करण के लिए दस्तावेज़:

तुरंत पोस्ट किए गए दस्तावेज़ों के लिए, आप अनुरोध में पैरामीटर निर्दिष्ट करना छोड़ सकते हैं; वर्तमान शेष राशि 31 दिसंबर, 3999 तक प्राप्त की जाएगी:

वर्तमान शेष राशि सिस्टम में संग्रहीत की जाती है और जितनी जल्दी हो सके प्राप्त की जाती है (ज्यादातर मामलों में अन्य तिथियों के लिए शेष राशि गणना द्वारा प्राप्त की जाती है)।

इस प्रकार अवशेष नियंत्रण के पुराने और नए दोनों तरीकों के लिए परिचालन कार्यान्वयन को अपनाया जा सकता है.

दिलचस्प तथ्य।

यूटी 11 में, नामकरण लिखने वाले दस्तावेज़ों को तुरंत निष्पादित करने से प्रतिबंधित किया गया है। उदाहरण के लिए, ये दस्तावेज़ हैं "वस्तुओं और सेवाओं की बिक्री", "माल की असेंबली", "माल की आवाजाही", "माल की घरेलू खपत" और अन्य।

ऐसा क्यों किया गया?

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

एक नई विधि का उपयोग करके शेष राशि का नियंत्रण - बिना अवरोध के

आइए मॉडल कॉन्फ़िगरेशन का उपयोग करके दस्तावेज़ "वस्तुओं और सेवाओं की बिक्री" को पूरा करते समय शेष राशि को नियंत्रित करने के लिए एल्गोरिदम पर संक्षेप में विचार करें।

दो रजिस्टर हैं:

• उपलब्ध शेष - मात्रात्मक लेखांकन के लिए
• माल की लागत - लागत लेखांकन के लिए

उत्पाद शेष को नियंत्रित करने के लिए, "निःशुल्क शेष" रजिस्टर के साथ काम करना पर्याप्त है।

पोस्टिंग प्रोसेसिंग कोड इस तरह दिखेगा:

अनुरोध = नया अनुरोध;

#क्षेत्रक्षेत्र1
Query.TemporaryTableManager = NewTemporaryTableManager;
#अंतक्षेत्र

#क्षेत्रक्षेत्र2
अनुरोध.पाठ=
"चुनना

|सामान दस्तावेज़ रखें
|से
|कहां
|
|समूह द्वारा
|
|इंडेक्स बाय
| नामपद्धति
|;

|चुनें
| &दिनांक एएस अवधि,
| मूल्य (आंदोलन का प्रकार, संचय, व्यय) आंदोलन के प्रकार के रूप में,
| उत्पाद दस्तावेज़. मात्रा के रूप में मात्रा
|से
";
Query.SetParameter('दिनांक', दिनांक);
#अंतक्षेत्र

// 4. डेटाबेस में गतिविधियों को रिकॉर्ड करना
#क्षेत्रक्षेत्र4
आंदोलन.रिकॉर्ड();
#अंतक्षेत्र

#क्षेत्रक्षेत्र5
अनुरोध.पाठ=
"चुनना
| -निःशुल्कशेषशेष. मात्राशेष कमी के रूप में
|से
| उत्पाद दस्तावेज़ उत्पाद दस्तावेज़ कैसे करें
| इनर जॉइन रजिस्टरएक्युमुलेशन.फ्रीरेमेन्स.रेमेन्स(
| &समय का क्षण,
| नामकरण बी
| (चुनना
| उत्पाद दस्तावेज़.नामपद्धति नामकरण के रूप में
| से
| दस्तावेज़ के उत्पाद दस्तावेज़ के उत्पाद के रूप में)) AS निःशुल्क शेष शेष
| सॉफ़्टवेयर उत्पाद दस्तावेज़.नामपद्धति = उपलब्धशेषशेष.नामपद्धति
|कहां
| उपलब्धशेषशेष.मात्राशेष< 0";
#अंतक्षेत्र

#क्षेत्रक्षेत्र6
शेष नियंत्रण का क्षण =
?(मोड = दस्तावेज़ होल्डिंग मोड। परिचालन,
अपरिभाषित,
नई सीमा(टाइमप्वाइंट(), बाउंड्रीव्यू.सहित));
Request.SetParameter ("समय का क्षण", शेष नियंत्रण का क्षण);
RequestResult = Request.Execute();
#अंतक्षेत्र

#क्षेत्रक्षेत्र7
यदि नहीं क्वेरी परिणाम.खाली() तो
इनकार = सच;
ErrorSelect = QueryResult.Select();
जबकि SetErrors.Next() लूप
Message.Text = "मात्रा में पर्याप्त उत्पाद नहीं:"+SelectionErrors.Shortage;
संदेश.फ़ील्ड = "उत्पाद["+(ErrorSelection.LineNumber-1)+"].मात्रा";
संदेश.संदेश();
अंतचक्र;
अगर अंत;
#अंतक्षेत्र

#क्षेत्रक्षेत्र8
यदि असफलता हो तो
वापस करना;
अगर अंत;
#अंतक्षेत्र

प्रक्रिया का अंत

आइए अवशिष्ट नियंत्रण एल्गोरिदम के मुख्य बिंदुओं पर विचार करें।

1. अस्थायी टेबल मैनेजर को प्रारंभ करना

प्रबंधक की आवश्यकता होगी ताकि क्वेरी में बनाई गई अस्थायी तालिका बाद की क्वेरी में उपलब्ध हो।

इस प्रकार, सारणीबद्ध भाग से डेटा एक बार प्राप्त किया जाता है, एक अस्थायी तालिका में सहेजा जाता है और फिर बार-बार उपयोग किया जाता है।

2. क्वेरी समूहन सारणीबद्ध डेटा

क्वेरी सारणीबद्ध अनुभाग से समूहीकृत डेटा का चयन करती है।

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

बैच में पहला अनुरोध एक अस्थायी तालिका बनाता है। दूसरी क्वेरी में, अस्थायी तालिका डेटा का चयन किया जाता है और प्रत्येक रजिस्टर प्रविष्टि के लिए आवश्यक 2 फ़ील्ड जोड़े जाते हैं - अवधि और आंदोलन प्रकार।

इस दृष्टिकोण के लाभ:

• प्री-क्लीनअप करने की कोई आवश्यकता नहीं है, यानी क्लियर() विधि का उपयोग करें
• चयन या सारणीबद्ध भाग के आधार पर लूप को व्यवस्थित करने की कोई आवश्यकता नहीं है।

वैसे, एक समान दृष्टिकोण का उपयोग मानक कॉन्फ़िगरेशन में किया जाता है, विशेष रूप से यूटी 11 और बीपी 3.0 में।

4. डेटाबेस में गतिविधियों को रिकॉर्ड करना

रिकॉर्डिंग एक कमांड (दो के बजाय) के साथ की जा सकती है - मूवमेंट्स.फ्रीरेमेन्स.रिकॉर्ड()।

और हमारे मामले में, जब एक रजिस्टर लिखा जाएगा, तो कोई अंतर नहीं होगा।

लेकिन यह दृष्टिकोण अधिक सार्वभौमिक है:

• सबसे पहले, रजिस्टर रिकॉर्ड के आवश्यक सेट के लिए लिखें ध्वज सेट करें
• फिर मूवमेंट संग्रह की Write() विधि को कॉल करें, जो डेटाबेस में राइट फ़्लैग सेट के साथ सभी सेट लिखता है

"मूवमेंट्स.रिकॉर्ड()" कमांड निष्पादित करने के बाद, सभी सेटों के लिए रिकॉर्ड ध्वज गलत पर रीसेट हो जाएगा।

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

विशिष्ट समाधान आंदोलनों को रिकॉर्ड करने के लिए एक समान योजना का उपयोग करते हैं। क्यों?

मूवमेंट संग्रह की लिखें() विधि विभिन्न दस्तावेज़ों के लिए भी, एक ही क्रम में रिकॉर्ड के सेट लिखती है।

गतिविधियों को मैन्युअल रूप से रिकॉर्ड करने से समस्याएँ हो सकती हैं।

चलिए एक उदाहरण देते हैं.

यदि आप "कार्यान्वयन" दस्तावेज़ में इस तरह लिखते हैं:

आंदोलन.मुक्तशेष.लिखें();
...
हलचलें। माल की लागत। लिखें();

और दस्तावेज़ में "माल की आवाजाही" क्रम बदलें:

आंदोलन. वस्तुओं की लागत.लिखें();
...
आंदोलन. FreeRemainings.Write();

इससे वस्तुओं के एक दूसरे को काटने वाले सेट पर दस्तावेज़ों में गतिरोध उत्पन्न हो सकता है।

यदि दस्तावेज़ गुणों में उचित गति रिकॉर्डिंग मान निर्दिष्ट किया गया है तो उपरोक्त गति रिकॉर्डिंग दृष्टिकोण का उपयोग किया जा सकता है:

5. नकारात्मक शेष प्राप्त करने वाली क्वेरी

अनुरोध दस्तावेज़ से आइटम के अनुसार नकारात्मक शेष का चयन करता है।

ऋणात्मक संतुलन किसी उत्पाद की कमी (कमी) है।

दस्तावेज़ से आइटमों का कनेक्शन केवल लाइन नंबर प्राप्त करने के लिए किया जाता है।

यदि हमने संदेशों को दस्तावेज़ फ़ील्ड से लिंक करने की योजना नहीं बनाई है, तो क्वेरी को बहुत सरल बनाया जा सकता है - डेटा एक तालिका (रजिस्टर के शेष) से ​​प्राप्त किया जाएगा।

6. अवशेषों को नियंत्रित करने के लिए समय का निर्धारण करना

यहीं पर परिचालन निष्पादन काम आया।

यदि दस्तावेज़ तुरंत निष्पादित किया जाता है, तो शेष राशि प्राप्त करने का क्षण अनिश्चित है, जिसका अर्थ है वर्तमान शेष प्राप्त करना।

यदि यह एक गैर-ऑपरेटिव लेनदेन है, तो हमें दस्तावेज़ के "बाद" में एक समय मिलता है - अभी किए गए आंदोलनों को ध्यान में रखने के लिए।

आइए याद रखें कि किसी मनमाने समय बिंदु पर शेष राशि प्राप्त करने की तुलना में वर्तमान शेष प्राप्त करना एक त्वरित ऑपरेशन है।

शीघ्रता से निष्पादित दस्तावेज़ों का यही लाभ है।

7. यदि अनुरोध खाली नहीं है, तो इसका मतलब है कि नकारात्मक शेष बन गए हैं

लूप में, हम सभी नकारात्मक अवशेषों से गुजरते हैं और सारणीबद्ध भाग की पंक्तियों से जुड़ा एक संदेश प्रदर्शित करते हैं।

डायग्नोस्टिक संदेश इस प्रकार दिखेगा:

8. यदि त्रुटियां हैं, तो इवेंट हैंडलर से वापस लौटें

यदि कम से कम एक गलती हुई, तो हम प्रक्रिया से बाहर निकल जाते हैं।

चूँकि लेन-देन जारी रखने का कोई मतलब नहीं है, लेन-देन वैसे भी रिकॉर्ड नहीं किया जाएगा (और फिर हम बैचों को लिखने के लिए एक कोड विकसित करेंगे)।

बैच द्वारा लागत बट्टे खाते में डालने का कार्यान्वयन

शेष राशि की जाँच सफल होने के बाद, आप बैचों को लिखना शुरू कर सकते हैं।

फीफो द्वारा बट्टे खाते में डालने का कोड इस प्रकार होगा:

// I. दस्तावेज़ की तारीख आगे बढ़ने का विश्लेषण

और यहऑब्जेक्ट नहीं.यहनया()
और ThisObject.तब आयोजित किया गया

अनुरोध = नया अनुरोध;
अनुरोध.पाठ=
"चुनना
| दस्तावेज़. दिनांक AS दिनांक
|से
|कहां

RequestResult = Request.Execute();
चयन दस्तावेज़.अगला();

अन्यथा
झूठ);
अगर अंत;

प्रक्रिया का अंत

रिकॉर्डिंग करते समय प्रक्रिया (इनकार)

ThisObject.AdditionalProperties.Insert("DocumentDateMovenForward",
ThisObject.Date>

अगर अंत;

प्रक्रिया का अंत

प्रसंस्करण प्रक्रिया (विफलता, मोड)

अनुरोध = नया अनुरोध;

// 1. अस्थायी तालिका प्रबंधक का आरंभीकरण
#क्षेत्रक्षेत्र1
...
#अंतक्षेत्र

// 2. क्वेरी समूहन तालिका डेटा
#क्षेत्रक्षेत्र2
...
#अंतक्षेत्र

// 4. डेटाबेस में गतिविधियों को रिकॉर्ड करना
#क्षेत्रक्षेत्र4
...
#अंतक्षेत्र

// 5. नकारात्मक शेष प्राप्त करने वाली क्वेरी
#क्षेत्रक्षेत्र5
...
#अंतक्षेत्र

// 6. संतुलन को नियंत्रित करने के लिए समय बिंदु का निर्धारण
#क्षेत्रक्षेत्र6
...
#अंतक्षेत्र

// 7. यदि अनुरोध खाली नहीं है, तो नकारात्मक शेष बन गए हैं
#क्षेत्रक्षेत्र7
...
#अंतक्षेत्र

// 8. यदि त्रुटियां हैं, तो इवेंट हैंडलर से वापस लौटें
#क्षेत्रक्षेत्र8
...
#अंतक्षेत्र

// द्वितीय. "माल की लागत" रजिस्टर के लिए रिकॉर्ड के सेट तैयार करना
#क्षेत्रक्षेत्रII

आंदोलन.रिकॉर्ड();
अगर अंत;
हलचलें। माल की लागत। रिकार्ड = सत्य;
#अंतक्षेत्र

// III. FIFO का उपयोग करके राइट-ऑफ़ के लिए बैच बैलेंस प्राप्त करने का अनुरोध करें
#क्षेत्रक्षेत्रIII
अनुरोध.पाठ=
"चुनना
| उत्पाद दस्तावेज़.नामपद्धति नामकरण के रूप में,
| उत्पाद दस्तावेज़.लाइन नंबर एएस लाइन नंबर,

| अवशेष। पार्टी के रूप में पार्टी
|से
| उत्पाद दस्तावेज़ उत्पाद दस्तावेज़ कैसे करें
| &समय का क्षण,
| नामकरण बी
| (चुनना
| से

|आदेश द्वारा
|परिणाम
| अधिकतम(मात्रा),
| योग(शेष मात्रा)
|सॉफ्टवेयर
| नामपद्धति";
RequestResult = Request.Execute();
#अंतक्षेत्र

// चतुर्थ। दस्तावेज़ नामकरण द्वारा चक्र
#क्षेत्रक्षेत्रIV

// वी. बट्टे खाते में डालने के लिए राशि प्राप्त करें
//VI. फीफो द्वारा बैच चक्र
जबकि सिलेक्शनबैच.नेक्स्ट() और रिमेनिंगराइट>0 लूप
// सातवीं. शून्य शेष की जाँच करें
यदि सैंपलबैच.क्वांटिटीरेमेनिंग=0 तो
जारी रखना;
अगर अंत;
आंदोलन.अवधि = दिनांक;

// आठवीं। बट्टे खाते में डाली जाने वाली मात्रा और राशि की गणना

// IX. हम बट्टे खाते में डाली जाने वाली राशि कम कर देंगे
अंतचक्र;
अंतचक्र;
#अंतक्षेत्र

प्रक्रिया का अंत

आइए FIFO का उपयोग करके बैचों को राइट-ऑफ़ करने के लिए एल्गोरिदम के मुख्य बिंदुओं पर नज़र डालें।

I. दस्तावेज़ की तिथि का विश्लेषण आगे बढ़ें

यहां हम समझते हैं कि पोस्ट किए गए दस्तावेज़ की तारीख आगे बढ़ती है या नहीं। गतिविधियों की सफ़ाई करते समय नीचे दी गई यह जानकारी उपयोगी होगी।

दस्तावेज़ दिनांक परिवर्तन का विश्लेषण करने के लिए, 2 घटनाओं की आवश्यकता है:

• रिकॉर्डिंग से पहले- दस्तावेज़ की पुरानी तारीख प्राप्त करने और दस्तावेज़ पोस्टिंग मोड की जांच करने के लिए
• रिकॉर्डिंग करते समय- नई दस्तावेज़ तिथि प्राप्त करने के लिए

हम ऑब्जेक्ट के एक विशेष संग्रह - "अतिरिक्त गुण" के माध्यम से घटनाओं के बीच डेटा स्थानांतरित करते हैं। यह तब तक मौजूद रहता है जब तक ऑब्जेक्ट का वर्तमान संस्करण मेमोरी में है, अर्थात यह निष्पादन के दौरान सभी घटनाओं के लिए उपलब्ध है।

एक समान तकनीक का उपयोग मानक "1C: लेखांकन 8" में किया जाता है। लेकिन वहाँ एक घटना "रिकॉर्डिंग से पहले" का प्रयोग किया जाता है।

बीपी में "ऑन रिकॉर्डिंग" का उपयोग करना क्यों आवश्यक नहीं है?

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

द्वितीय. "माल की लागत" रजिस्टर के लिए रिकॉर्ड के सेट तैयार करना

दस्तावेज़ के लिए मूवमेंट विलोपन मोड सेट है - "जब पोस्टिंग रद्द कर दी जाती है":

इस प्रकार, ऐसी संभावना है कि दोबारा पोस्ट करते समय, हम दस्तावेज़ की गतिविधियों को ही ध्यान में रख सकते हैं। लेकिन यह तभी होगा जब दस्तावेज़ की तारीख आगे बढ़ा दी जाएगी। अर्थात्, आंदोलनों को स्पष्ट करना तभी समझ में आता है जब दस्तावेज़ की तारीख आगे बढ़ा दी जाती है।

यहाँ एक उदाहरण है:

• दस्तावेजों के समय एलजी मॉनिटर का संतुलन 10 पीसी है।
• एक दस्तावेज़ पोस्ट किया गया है जो 8 टुकड़ों को बट्टे खाते में डालता है।
• उसी दस्तावेज़ में, समय 1 मिनट बढ़ा दिया गया है, आइए दोहराएँ

यदि पुराने आंदोलनों को हटाया नहीं जाता है, तो सिस्टम 6 मॉनिटरों की कमी की रिपोर्ट करेगा, क्योंकि वर्तमान दस्तावेज़ आंदोलनों ने 10 उपलब्ध मॉनिटरों में से 8 को पहले ही बंद कर दिया है।

टिप्पणी। कभी-कभी सलाह दी जाती है - केवल सर्जरी के दौरान ही हरकतों को दूर करें।

लेकिन यह गलत है: वे "गैर-ऑपरेटिव" दस्तावेजों (कल और पहले वाले) को बदलने की स्थिति को ध्यान में नहीं रखेंगे।

यानी, इस मामले में "6 मॉनिटर की कमी" (ऊपर देखें) की समस्या केवल आज संशोधित दस्तावेजों के लिए हल की जाएगी।

तृतीय. अनुरोध जो FIFO का उपयोग करके राइट-ऑफ़ के लिए बैच शेष प्राप्त करता है

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

कुल स्तर पर, दस्तावेज़ से मात्रा प्राप्त की जाती है - अधिकतम(मात्रा) और बैच का शेष - योग(मात्राशेष)।

क्या आपको लगता है कि दस्तावेज़ की मात्रा सभी बैचों के लिए आइटम की कुल शेष राशि से अधिक हो सकती है?

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

चतुर्थ. दस्तावेज़ नामकरण द्वारा चक्र

बाहरी लूप में क्वेरी के परिणामों के लिए धन्यवाद, हम दस्तावेज़ से नामकरण को बायपास करते हैं।

वी. बट्टे खाते में डालने के लिए राशि प्राप्त करें

आइए याद रखें कि आपको कितना बट्टे खाते में डालने की जरूरत है। आगे यह रकम घटेगी.

VI. फीफो द्वारा बैच चक्र

नेस्टेड चक्र में वर्तमान आइटम के अनुसार बैच होंगे।

सातवीं. शून्य शेष की जाँच करें

सामान्य तौर पर, वह स्थिति जब बैच बैलेंस शून्य होता है, सिस्टम डेटा में एक त्रुटि होती है (फिर भी, ऐसी स्थिति संभव है)। मुद्दा यह है कि इस मामले में योग शून्य नहीं है (रजिस्टर शेष की आभासी तालिका शून्य संसाधन मान वाले रिकॉर्ड नहीं लौटाती है)।

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

आठवीं. बट्टे खाते में डाली जाने वाली मात्रा और राशि की गणना

बट्टे खाते में डाली जाने वाली मात्रा बैच के शेष भाग और बट्टे खाते में डाली जाने वाली मात्रा के बीच का न्यूनतम मूल्य है।

राशि की गणना प्राथमिक अनुपात द्वारा की जाती है।

यदि किसी बैच का संपूर्ण शेष बट्टे खाते में डाल दिया जाता है, तो उस बैच की पूरी राशि भी बट्टे खाते में डाल दी जाएगी। यह एक संकीर्ण स्कूल में तीसरी कक्षा का गणित है: X*Y/X = Y:)

यानी, यह सुनिश्चित करने के लिए कि पूरी राशि बट्टे खाते में डाल दी गई है, अतिरिक्त जांच करने की कोई आवश्यकता नहीं है (कभी-कभी वे ऐसी सलाह देते हैं)। इस सलाह का अपना नाम भी है - " पैसे की समस्या».

और जो लोग बुरी सलाह देते हैं, उनके लिए "1सी: अकाउंटिंग 8" कॉन्फ़िगरेशन पर गौर करना उचित है। वहाँ (ओह, डरावनी!) कोई जाँच नहीं है कि पूरा बैच बट्टे खाते में डाल दिया गया है :)

यहां सामान्य मॉड्यूल "माल लेखांकन", "शेष माल को बट्टे खाते में डालना" विधि का एक स्क्रीनशॉट है:

नौवीं. हम बट्टे खाते में डाली जाने वाली राशि कम कर देंगे

आपको यह समझने की जरूरत है कि बट्टे खाते में डालने के लिए कितना कुछ बचा है। ऐसा करने के लिए, रजिस्टर मूवमेंट से मात्रा घटाएं।

प्रबंधित तालों की आवश्यकता क्यों है?

यहां हम नियंत्रित अवरोधन पर आते हैं।

ऐसा प्रतीत होता है कि ऊपर प्रस्तुत एल्गोरिदम घड़ी की कल की तरह काम करते हैं। आप स्वयं उनका परीक्षण कर सकते हैं (लेख के अंत में डेटाबेस डाउनलोड के लिंक)।

लेकिन वास्तविक बहु-उपयोगकर्ता ऑपरेशन के दौरान, समस्याएं शुरू हो जाएंगी, और, जैसा कि अक्सर होता है, समस्याओं का तुरंत पता नहीं लगाया जाएगा...

आइए किसी वस्तु को बट्टे खाते में डालते समय सबसे आम समस्या का एक उदाहरण दें, जब 2 उपयोगकर्ता लगभग एक साथ किसी वस्तु को बट्टे खाते में डालने (बिक्री करने) का प्रयास करते हैं:

इस उदाहरण में, दो उपयोगकर्ता लगभग एक साथ माल की बिक्री करते हैं - दस्तावेज़ संख्या 2 को दस्तावेज़ 1 की तुलना में थोड़ी देर बाद बेचा जाना शुरू हुआ।

शेष राशि प्राप्त होने पर, सिस्टम रिपोर्ट करता है कि शेष 10 इकाइयाँ हैं, और दोनों दस्तावेज़ सफलतापूर्वक संसाधित हो गए हैं। दुखद परिणाम यह है कि स्टॉक में शून्य से 5 एलजी मॉनिटर हैं।

लेकिन साथ ही, अवशेष नियंत्रण भी काम करता है! अर्थात्, यदि दस्तावेज़ संख्या 2 को दस्तावेज़ संख्या 1 की समाप्ति के बाद पोस्ट किया जाता है, तो सिस्टम दस्तावेज़ संख्या 2 को पोस्ट नहीं करेगा:

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

ये बहुत खतरनाक तर्क.

यहां तक ​​कि दो उपयोगकर्ता भी लगभग एक साथ दस्तावेज़ पोस्ट कर सकते हैं, उदाहरण के लिए, यदि उनमें से एक दस्तावेज़ों की समूह पोस्टिंग करता है।

इसके अलावा, आप उपयोगकर्ताओं की संख्या में वृद्धि से प्रतिरक्षित नहीं रह सकते। यदि व्यवसाय आगे बढ़ता है, तो नए बिक्री लोगों, स्टोरकीपरों, लॉजिस्टिक आदि की आवश्यकता होगी। इसलिए, आपको तुरंत ऐसे समाधान बनाने की आवश्यकता है जो बहु-उपयोगकर्ता वातावरण में स्थिर रूप से काम करेंगे।

समानांतर में दस्तावेज़ पोस्ट करते समय समस्या का समाधान कैसे करें?

समाधान सरल है - एलजी मॉनिटर को टी1 समय पर ब्लॉक करें, ताकि अन्य लेनदेन इस उत्पाद के शेष तक नहीं पहुंच सकें।

फिर समय T2 पर सिस्टम LG मॉनिटर के अनलॉक होने का इंतजार करेगा। और इसके बाद, सिस्टम को माल का वर्तमान संतुलन प्राप्त होगा और माल का बट्टे खाते में डालना पूरा हो जाएगा (या पूरा नहीं हुआ)।

अवरोधन के वर्गीकरण के बारे में बस कुछ शब्द।

ताले 2 प्रकार के होते हैं:

• वस्तु
• लेन-देन संबंधी.

सीधे शब्दों में कहें तो, ऑब्जेक्ट लॉक अनुमति नहीं देते हैं सहभागितापूर्ण तरीके सेदो उपयोगकर्ताओं के लिए एक ऑब्जेक्ट (निर्देशिका तत्व या दस्तावेज़) बदलें।

और लेन-देन लॉक अनुमति देते हैं प्रोग्राम के रूप मेंरजिस्टरों में गतिविधियां करते समय वर्तमान डेटा के साथ काम करें।

इस लेख में हम लेन-देन संबंधी तालों में रुचि लेंगे, फिर केवल ताले में।

अवरोधन कब लागू किया जाना चाहिए?

डेटाबेस प्रारंभ होते ही लॉक सेट करने का कार्य प्रासंगिक हो जाता है एक से अधिक उपयोगकर्ता पर काम करें.

लेन-देन पर ताले लगाने की आवश्यकता है, लेकिन लेन-देन कब होता है? यह सही है, सबसे आम मामला दस्तावेज़ प्रसंस्करण का है।

अर्थात्, सभी दस्तावेज़ों को संसाधित करते समय अवरोधन लागू किया जाना चाहिए?

किसी भी मामले में नहीं। यह निश्चित रूप से "बस मामले में" ताले लगाने लायक नहीं है।. आख़िरकार, ताले स्वयं उपयोगकर्ताओं की समवर्तीता (सिस्टम स्केलेबिलिटी) को कम कर देते हैं।

ताले को उन संसाधनों (तालिका पंक्तियों) पर रखा जाना चाहिए जिन्हें लेनदेन में पढ़ा और संशोधित किया जाता है। उदाहरण के लिए, दस्तावेज़ ले जाते समय।

उपरोक्त उदाहरण में, ऐसा संसाधन उत्पाद का संतुलन है। सिस्टम को बैलेंस डेटा प्राप्त होने के क्षण (T1) से लेकर लेनदेन के अंत (T3) तक बैलेंस को ब्लॉक करना था।

टिप्पणी। दस्तावेज़ संख्या 1 पोस्ट करते समय लेन-देन शेष राशि प्राप्त होने के क्षण से पहले शुरू होता है। लेकिन सरलता के लिए, हम मानते हैं कि T1 दस्तावेज़ प्रसंस्करण का प्रारंभ समय और शेष राशि की प्राप्ति का क्षण दोनों है।

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

स्वचालित और नियंत्रित अवरोधन

यहां हम सिद्धांत में नहीं जाएंगे (यह एक अलग लेख का विषय है), लेकिन केवल यह कहेंगे कि प्रबंधित ताले अधिक इष्टतम हैं।

सिद्धांत के बजाय, हम प्रमाण दे सकते हैं - सभी आधुनिक मानक विन्यास नियंत्रित इंटरलॉक पर काम करते हैं।

इसलिए, हमारे मॉडल कॉन्फ़िगरेशन में उपयुक्त मोड का चयन किया जाएगा:

नई अवशेष नियंत्रण तकनीक में नियंत्रित ताले

हम "फ्री बैलेंस" रजिस्टर और केवल दस्तावेज़ में पाए जाने वाले आइटम आइटम पर लॉक लगाएंगे।

इसके अतिरिक्त सही अवरोधन विकल्प- जितना हो सके उतनी देरी से।

शेष राशि को नियंत्रित करने की नई पद्धति में, इसे "फ्री बैलेंस" रजिस्टर में गतिविधियों को रिकॉर्ड करने (या रिकॉर्डिंग के समय) से पहले किया जाना चाहिए, ताकि अन्य लेनदेन इस साझा संसाधन को बदल न सकें।

अवरोधन को मैन्युअल रूप से (प्रोग्रामेटिक रूप से) लागू किया जा सकता है और थोड़ी देर बाद हम दिखाएंगे कि यह कैसे किया जाता है।

लेकिन नई बैलेंस कंट्रोल तकनीक का एक अतिरिक्त बोनस यह है कि यह साझा संसाधनों को लॉक करने के लिए कोड की केवल एक पंक्ति लेता है।

आपको बस रजिस्टर प्रविष्टि सेट पर ब्लॉकफॉरचेंज प्रॉपर्टी सेट करने की आवश्यकता है:

//3.1. रजिस्टर शेष को लॉक करना
#क्षेत्रक्षेत्र3_1
Moves.FreeRemainders.BlockForChange = सत्य;
#अंतक्षेत्र

// 4. डेटाबेस में गतिविधियों को रिकॉर्ड करना
#क्षेत्रक्षेत्र4
आंदोलन.मुक्तशेष.लिखें = सत्य;
आंदोलन.रिकॉर्ड();
#अंतक्षेत्र
...

परिणामस्वरूप, 2 लेनदेन एक आइटम के लिए निःशुल्क शेष राशि को बदलने में सक्षम नहीं होंगे।

वास्तव में, जब संपत्ति ब्लॉकफॉरचेंज है प्रबंधित लॉकिंग स्थापित नहीं करता है, यह केवल लिखते समय रजिस्टर कुल को अलग करने के मोड को बंद कर देता है।

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

वैसे, मानक यूटी 11 में "फ्री बैलेंस" रजिस्टर के लिए ब्लॉकफॉरचेंज प्रॉपर्टी की सेटिंग ढूंढना इतना आसान नहीं है। तथ्य यह है कि यह रजिस्टर रिकॉर्डसेट मॉड्यूल में, "लिखने से पहले" इवेंट में किया जाता है।

बस इतना ही, कोड की एक पंक्ति के साथ सिस्टम का सही संचालन सुनिश्चित किया गया!

महत्वपूर्ण. हम "माल की लागत" रजिस्टर को लॉक नहीं करते हैं।

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

इसलिए, माल को "मुक्त शेष" से अवरुद्ध करके, हम इन सामानों से पहले और "माल की लागत" रजिस्टर में अन्य लेनदेन की अनुमति नहीं देंगे।

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

अवशेष नियंत्रण की पुरानी विधि

हम आपको याद दिला दें कि यदि मात्रा और लागत को एक रजिस्टर में ध्यान में रखा जाए तो पुरानी पद्धति लागू की जा सकती है।

इसे "माल की लागत" रजिस्टर होने दें:

फिर दस्तावेज़ "माल की बिक्री" पोस्ट करने का एल्गोरिदम इस तरह दिखेगा:

// 1. इवेंट हैंडलर "रिकॉर्डिंग से पहले"
रिकॉर्डिंग से पहले की प्रक्रिया (विफलता, रिकॉर्डिंग मोड, संचालन मोड)

यदि रिकॉर्डिंग मोड = दस्तावेज़ रिकॉर्डिंग मोड। पोस्टिंग
और यहऑब्जेक्ट नहीं.यहनया()
और ThisObject.तब आयोजित किया गया

अनुरोध = नया अनुरोध;
अनुरोध.पाठ=
"चुनना
| दस्तावेज़. दिनांक AS दिनांक
|से
| दस्तावेज़। दस्तावेज़ के रूप में वस्तुओं और सेवाओं की बिक्री
|कहां
| दस्तावेज़.लिंक = &लिंक";
Request.SetParameter("लिंक", ThisObject.Link);
RequestResult = Request.Execute();
चयन दस्तावेज़ = क्वेरी परिणाम. चयन करें();
चयन दस्तावेज़.अगला();

ThisObject.AdditionalProperties.Insert("OldDocumentDate", चयनDocument.Date);

अन्यथा
अगर अंत;

प्रक्रिया का अंत

रिकॉर्डिंग करते समय प्रक्रिया (इनकार)

यदि ThisObject.AdditionalProperties.Property("DocumentDateShiftedForward") नहीं है तो

ThisObject.AdditionalProperties.Insert("DocumentDateMovenForward",
ThisObject.Date>ThisObject.AdditionalProperties.OldDocumentDate);

रिपोर्ट(ThisObject.AdditionalProperties.DocumentDateMovenForward);
अगर अंत;

प्रक्रिया का अंत

प्रसंस्करण प्रक्रिया (विफलता, मोड)

// 2. "पुरानी" दस्तावेज़ गतिविधियों को हटाना
यदि ExtraProperties.DocumentDate को आगे की ओर स्थानांतरित कर दिया गया है
हलचलें। माल की लागत। रिकार्ड = सत्य;
हलचलें.उत्पाद लागत.स्पष्ट();
आंदोलन.रिकॉर्ड();
अगर अंत;

// 3. लेन-देन के अंत में गतिविधियों को रिकॉर्ड करने के लिए ध्वज को सेट करना
हलचलें। माल की लागत। रिकार्ड = सत्य;

// 4. अनुरोध जो दस्तावेज़ के समय बैच द्वारा शेष राशि प्राप्त करता है
अनुरोध = नया अनुरोध;
अनुरोध.पाठ=
"चुनना
| उत्पादों की बिक्री। नामकरण के रूप में नामकरण,
| रकम(बिक्रीउत्पाद.मात्रा) मात्रा के रूप में,
| न्यूनतम(सेल्सप्रोडक्ट्स.लाइननंबर) एएसएललाइननंबर
|सामान दस्तावेज़ रखें
|से
| दस्तावेज़। वस्तुओं और सेवाओं की बिक्री। सामान, सामान कैसे बेचें
|कहां
| SalesProducts.Link = &Link
|समूह द्वारा
| उत्पादों की बिक्री. नामकरण
|इंडेक्स बाय
| नामपद्धति
|;
|////////////////////////////////////////////////////////////////////////////////
|चुनें
| उत्पाद दस्तावेज़.नामपद्धति नामकरण के रूप में,
| उत्पाददस्तावेज़.मात्रा मात्रा के रूप में,
| उत्पाद दस्तावेज़.लाइन नंबर एएस लाइन नंबर,
| ISNULL(शेष.संख्याशेष, 0) शेष मात्रा के रूप में,
| ISNULL(शेष.राशिशेष, 0) शेष राशि के रूप में,
| अवशेष। पार्टी के रूप में पार्टी
|से
| उत्पाद दस्तावेज़ उत्पाद दस्तावेज़ कैसे करें
| बायां कनेक्शन रजिस्टर संचय। माल की लागत। शेष(
| &समय का क्षण,
| नामकरण बी
| (चुनना
| टी. नामकरण के रूप में नामकरण
| से
| उत्पाद दस्तावेज़ एएस टी)) एएस बचे हुए
| सॉफ़्टवेयर उत्पाद दस्तावेज़.नामपद्धति = शेष.नामपद्धति
|आदेश द्वारा
| अवशेष.बैच.समय का क्षण
|परिणाम
| अधिकतम(मात्रा),
| योग(शेष मात्रा)
|सॉफ्टवेयर
| पंक्ति नंबर";

Request.SetParameter('TimePoint', TimePoint());
Request.SetParameter("लिंक", लिंक);

RequestResult = Request.Execute();

चयननामपद्धति = क्वेरी परिणाम। चयन करें (BypassQueryResult.ByGrouping);

// 5. आइटम दर चक्र - यह जाँचना कि मात्रा राइट-ऑफ़ के लिए पर्याप्त है या नहीं
जबकि सिलेक्शननोमेनक्लेचर.नेक्स्ट() लूप

नामकरण घाटा = नमूनानामपद्धति.मात्रा - नमूनानामपद्धति.मात्राशेष;

यदि नामकरण घाटा>0 है तो
संदेश = नया MessageToUser;
Message.Text = "मात्रा में पर्याप्त उत्पाद नहीं:"+नामकरण की कमी;
संदेश.फ़ील्ड = "उत्पाद["+(चयननामपद्धति.लाइननंबर-1)+"].मात्रा";
Message.SetData(ThisObject);
संदेश.संदेश();
इनकार = सच;
अगर अंत;

यदि असफलता हो तो
जारी रखना;
अगर अंत;

// 6. बट्टे खाते में डालने के लिए राशि प्राप्त करें
शेषलिखें = नमूनानामपद्धति.मात्रा;
चयनबैच = चयननामपद्धति.चयन();

// 7. बैच चक्र
जबकि सिलेक्शनबैच.नेक्स्ट() और रिमेनिंगराइट>0 लूप

आंदोलन = आंदोलन। माल की लागत। व्यय जोड़ें();
आंदोलन.अवधि = दिनांक;
आंदोलन.नामपद्धति = चयनबैच.नामपद्धति;
मूवमेंट.बैच = चयनबैच.बैच;
// 9. बट्टे खाते में डाली जाने वाली मात्रा की गणना
संचलन.मात्रा = न्यूनतम(शेषलिखें, बैचचयन.मात्राशेष);
// 10. बट्टे खाते में डाली गई राशि की गणना
संचलन.राशि = संचलन.मात्रा*
नमूनाबैच.राशिशेष/नमूनाबैच.मात्राशेष;

// 11. बट्टे खाते में डाली जाने वाली राशि कम करें
शेषलिखना = शेषलिखना - गति.मात्रा;

अंतचक्र;
अंतचक्र;

क्या मुझे 1C:Enterprise 8.2 पर स्विच करने की आवश्यकता है? यदि आप यह लेख पढ़ रहे हैं, तो इसका मतलब है कि आपने संभवतः इस प्रश्न का उत्तर पहले ही हाँ में दे दिया है। इसलिए, अब हम नए प्लेटफॉर्म पर स्विच करने के फायदों के बारे में दोबारा बात नहीं करेंगे, बल्कि सीधे इस प्रक्रिया के विवरण और विशेषताओं पर ध्यान केंद्रित करेंगे।

1. सामान्य एल्गोरिदम

तो, आपने "आठ" पर स्विच करने का निर्णय लिया है और यह पता लगाना चाहते हैं कि यह कैसे किया जाता है और यह आपके लिए क्या "खतरा" है। अपने सबसे सामान्य रूप में, संक्रमण आरेख इस तरह दिखता है (चित्र 1)।

चावल। 1. 1सी:एंटरप्राइज 7.7 प्लेटफॉर्म से 1सी:एंटरप्राइज 8.2 प्लेटफॉर्म पर संक्रमण के लिए एल्गोरिदम

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

2. अद्यतननवीनतम वर्तमान रिलीज़ तक वर्तमान कॉन्फ़िगरेशन।

3. स्थानांतरण के लिए डेटाबेस तैयार करना।इसमें डेटाबेस का बैकअप लेना, वर्तमान बिलिंग अवधि को बंद करना, हटाने के लिए चिह्नित वस्तुओं के डेटाबेस को साफ़ करना और लेखांकन त्रुटियों (यदि कोई हो) को ठीक करना शामिल है।

4. डेटा ट्रांसफर.यह मुख्य स्टेज है. प्रत्येक विशिष्ट मामले में एल्गोरिदम और श्रम तीव्रता भिन्न होती है।

5. नये विन्यास के साथ कार्य करने हेतु कार्मिकों का प्रशिक्षण।चूँकि प्लेटफ़ॉर्म 7.7 और 8.2 पर कॉन्फ़िगरेशन इंटरफ़ेस और कार्यक्षमता दोनों में भिन्न है, इसलिए आपको नए कॉन्फ़िगरेशन के साथ काम करने के लिए प्रशिक्षण की आवश्यकता हो सकती है। आप उपयुक्त पद्धति संबंधी साहित्य का उपयोग करके स्वयं इसका अध्ययन कर सकते हैं, लेकिन 1सी पर एक विशेष पाठ्यक्रम लेना बेहतर है।

6. ऑपरेशन.इस स्तर पर, जब उपयोगकर्ता नए प्रोग्राम में काम करना शुरू करते हैं, तो इसे डीबग किया जाता है और स्वचालित डेटा ट्रांसफर में संभावित त्रुटियों को ठीक किया जाता है।

आइए कॉन्फ़िगरेशन के संदर्भ में एक नए प्लेटफ़ॉर्म पर माइग्रेट करने की प्रक्रिया पर विचार करें "1सी अकाउंटिंग".

2. "1सी: अकाउंटिंग 7.7" को "1सी: अकाउंटिंग 8.2" में बदलें

"1C: अकाउंटिंग 7.7" से "1C: अकाउंटिंग 8.2" में डेटा स्थानांतरित करने की रणनीति और तंत्र निम्नलिखित कारकों द्वारा निर्धारित किए जाते हैं:

• नए कार्यक्रम में लेखांकन का प्रारंभ समय;
• आपके कॉन्फ़िगरेशन के वर्तमान संस्करण में संशोधनों की उपस्थिति और जटिलता;
• पिछली अवधि के व्यापारिक लेनदेन के इतिहास को संरक्षित करने की आवश्यकता।

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

उपरोक्त कारकों के संयोजन के आधार पर स्थितियाँ इस प्रकार हो सकती हैं।

स्थिति 1:

नए वर्ष से परिवर्तन, विशिष्ट कॉन्फ़िगरेशन, पुराने कार्यक्रम में सही खाता शेष उत्पन्न होता है

यह विकल्प सरल और सीधा है, लेकिन व्यवहार में यह अत्यंत दुर्लभ है। नए कार्यक्रम में काम शुरू करने से तुरंत पहले पुराने कार्यक्रम में सही शेष राशि उत्पन्न करना कई छोटी कंपनियों में ही संभव है, और केवल इस शर्त पर कि पिछली अवधि के सभी प्राथमिक दस्तावेज़ प्रदान किए जाएं और कार्यक्रम में दर्ज किए जाएं।

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

स्थिति 2:

नए वर्ष से परिवर्तन, विशिष्ट कॉन्फ़िगरेशन, पुराने कार्यक्रम में कोई सही खाता शेष नहीं है

इस मामले में मानक अभ्यास है पुराने और नये कार्यक्रम में एक साथ काम करना . "संक्रमण अवधि" (छवि 2) के दौरान, कर्मचारी पुराने कार्यक्रम में अपने पिछले लेनदेन को बंद कर देते हैं और नए लेनदेन पर दस्तावेजों को नई प्रणाली में दर्ज करना शुरू कर देते हैं।

चावल। 2. प्लेटफॉर्म बदलते समय संक्रमण अवधि

इस अवधि को न्यूनतम नुकसान के साथ पार करने के लिए, आप निम्नलिखित रणनीतियों का उपयोग कर सकते हैं:

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

स्थिति 3:

वर्ष के मध्य से संक्रमण, विशिष्ट विन्यास

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

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

1. मानक समाधान "1सी: डेटा रूपांतरण 2.1". इस सॉफ़्टवेयर उत्पाद का उपयोग किसी भी संरचना और जटिलता के 1C प्लेटफ़ॉर्म पर कॉन्फ़िगरेशन के बीच जानकारी स्थानांतरित करने के लिए किया जा सकता है।

2. 1सी फ्रेंचाइजी का विकास। कंपनी समेत कई कंपनियां «आरजी-सॉफ्ट" (), इस समस्या को हल करने के लिए सिद्ध तरीके हैं, जो डेटा ट्रांसफर कार्य के समय और बजट को काफी कम कर सकते हैं।

स्थिति 4:

पिछली अवधि के दस्तावेज़ों के स्थानांतरण के साथ मानक कॉन्फ़िगरेशन से संक्रमण

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

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

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

स्थिति 5:

1सी:एंटरप्राइज़ 7.7 प्लेटफ़ॉर्म पर गैर-विशिष्ट कॉन्फ़िगरेशन से संक्रमण

ऊपर वर्णित विकल्पों का उपयोग मानक "1C:एंटरप्राइज़ 7.7" कॉन्फ़िगरेशन से माइग्रेट करते समय किया जाता है, लेकिन व्यवहार में आपको अक्सर संशोधित कॉन्फ़िगरेशन से निपटना पड़ता है। इस स्थिति में परिवर्तन का आयोजन एक विशेष विकल्प है जिस पर विचार किया जाना चाहिए।

प्रोग्राम में किए गए परिवर्तनों की प्रकृति के आधार पर, निम्नलिखित डेटा स्थानांतरण प्रौद्योगिकियाँ उपलब्ध हैं:

· यदि कॉन्फ़िगरेशन थोड़ा बदल दिया गया है और बुनियादी तंत्र मानक 1सी समाधान के समान हैं, तो आप पिछले विकल्पों की तरह, मानक संक्रमण उपकरण का उपयोग कर सकते हैं। आपको केवल अपने प्रोग्राम के अनुरूप उन्हें कॉन्फ़िगर या थोड़ा संशोधित करने की आवश्यकता है। शायद सबसे अधिक परीक्षण किया गया और विश्वसनीय उपकरण पहले से ही उल्लेखित "1C: डेटा रूपांतरण 2.1" है। इस टूल को उपयोगकर्ता से कुछ ऑपरेटिंग कौशल की आवश्यकता होगी, लेकिन इसकी मदद से कॉन्फ़िगरेशन के बीच वस्तुओं के स्वचालित हस्तांतरण को व्यवस्थित करना संभव है।

· यदि उपयोग के वर्षों में कॉन्फ़िगरेशन को मौलिक रूप से पुन: डिज़ाइन किया गया है, तो मानक माइग्रेशन उपकरण स्थापित करना इन उद्देश्यों के लिए अपनी स्वयं की प्रसंस्करण लिखने की तुलना में अधिक श्रम-गहन हो सकता है। ऐसी ही स्थिति एक लेखांकन कार्यक्रम से संक्रमण के आयोजन के मामले में उत्पन्न होती है जो 1C प्लेटफ़ॉर्म से संबद्ध नहीं है। ऐसा परिवर्तन करना भी संभव है, लेकिन पहले से ही सार्वभौमिक विनिमय के साथ आना संभव नहीं होगा। प्रत्येक विशिष्ट मामले में समस्या के प्रति एक व्यक्तिगत दृष्टिकोण की आवश्यकता होती है। हमारी कंपनी विभिन्न प्रारूपों, जैसे डीबीएफ, की फ़ाइलों के माध्यम से डेटा स्थानांतरित करने में अपना अनुभव प्रदान कर सकती है। xls(एक्सेल से 1सी तक यूनिवर्सल लोडर), एक्सएमएल।

प्लेटफ़ॉर्म 7.7 से 8.2 तक संक्रमण के संबंध में एक और बात ध्यान देने योग्य है डेटाबेस समेकन.

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

ऊपर दिए गए तरीकों का उपयोग करके, आप प्रत्येक डेटाबेस के साथ अलग-अलग इंटरैक्शन स्थापित कर सकते हैं। हालाँकि, कई उपकार्य उत्पन्न होते हैं जो इस मामले के लिए विशिष्ट हैं।

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

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

3. संभावित कठिनाइयाँ जिनसे आपको अवगत होना चाहिए

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

3.1. स्रोत डेटा में त्रुटियाँ

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

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

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

3.2. कॉन्फ़िगरेशन अंतर

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

उदाहरण के लिए, डाउनलोड किए गए दस्तावेज़ की संख्या में एक अतिरिक्त उपसर्ग जोड़कर इस समस्या का समाधान किया जाता है। दस्तावेज़ की प्रत्येक विशेषता के लिए, यह उपसर्ग अलग से आवंटित किया गया है। यह उस डेटाबेस की विशेषता हो सकती है जिससे दस्तावेज़ डाउनलोड किए गए हैं या दस्तावेज़ का प्रकार जिससे डाउनलोड किया गया था। यहां ऐसे उपसर्ग के गठन का एक उदाहरण दिया गया है। क्रास्नोयार्स्क में शाखा आधार उपसर्ग "केआर" देता है। दस्तावेज़ प्रकार "सामग्री की प्राप्ति" जिससे डाउनलोड किया जाता है उसे उपसर्ग "एम" दिया गया है। इसलिए, यदि सात में दस्तावेज़ संख्या 00000031 थी, तो आठ संख्या इस प्रकार होगी:

"केआर" + "एम" + "00000031" = "केआरएम00000031"

परिणामस्वरूप, डेटाबेस में एक अद्वितीय नंबर दर्ज किया जाएगा।

3.3. तकनीकी समस्याएँ

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

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

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

निष्कर्ष

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