यूनिवर्सल वर्क शेड्यूल बनाने का तर्क

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

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

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

परिणामस्वरूप, हमने कार्य अनुसूचियों के लिए निम्नलिखित आवश्यकताओं का गठन किया

1. configurability
   उन्हें वेब इंटरफ़ेस से पूरी तरह से कॉन्फ़िगर किया जाना चाहिए।
2. चर पिच
   उनके पास एक चर ग्रिड पिच होना चाहिए।
   एक क्लिनिक में, प्रति मरीज 30 मिनट के लिए नियुक्ति का समय निर्धारित किया जा सकता है, और दूसरे 20 में, तीसरे घंटे में
3. कस्टम टोपी
   ग्राफ़ का हेडर अद्वितीय हो सकता है, अर्थात यह डॉक्टरों, सुविधाओं, शिक्षकों, टीमों, आदि का एक सेट हो सकता है। सामान्य तौर पर, सिस्टम में क्लाइंट के पास जो कुछ भी है। यहां तक ​​कि जो हम कल्पना भी नहीं कर सकते हैं।
4. चार्ट रिकॉर्ड में - खेतों का एक मनमाना सेट
   सिस्टम में किसी भी जानकारी से खेतों का एक सेट मनमाने ढंग से सेट किया जा सकता है। और प्रविष्टियों को हेडर के अनुसार व्यवस्थित किया जाता है।
5. CRUD
   खेतों की मनमानी सेट के बावजूद चार्ट प्रविष्टियां CRUD (बनाएं, पढ़ें, अपडेट, हटाएं) होनी चाहिए। और सिर्फ इतना ही नहीं, बल्कि जटिल इंटरैक्शन को व्यवस्थित करने के लिए प्रक्रियाओं का उपयोग करना।
   
   

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

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

   उदाहरण के लिए, यदि उपयोगकर्ता को रिकॉर्ड पर की गई कार्रवाइयों पर कुछ प्रकार के लॉग लिखने हैं, या कर्मचारियों को सूचनाएं भेजनी हैं, या sms क्लाइंट को भी भेजना है या यहां तक ​​कि जो हम नहीं कर सकते हैं उसे भेजें।

10. क्रॉस रिकॉर्ड
    क्रॉस-रिकॉर्ड एक ग्राफ में संयुक्त विभिन्न रेखांकन से रिकॉर्ड हैं। या अन्य ग्राफ़ में प्रविष्टियों की उपस्थिति, जब प्रविष्टियां वर्तमान में दिखाई देती हैं।
    
    

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

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

    
    
12. रिपोर्ट
    ताकि अनुसूची के अनुसार रिपोर्ट बनाना संभव हो सके। डेटा स्टोरेज सिस्टम को व्यवस्थित किया जाना चाहिए ताकि इसे रिपोर्ट कॉन्फ़िगरेशन में उठाया जा सके।
    

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

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

    उदाहरण के लिए, इंगित करें कि केवल लेखक ही अपने पद, या अपने समूह या इकाई को संपादित कर सकता है।

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

हमारा मानना ​​है कि हम इन आवश्यकताओं को प्रभावी ढंग से लागू करने में कामयाब रहे और यह लेख यह वर्णन करेगा कि यह कैसे किया जाता है।

फिलहाल, मैं सिस्टम को समान रूप से बहुमुखी ग्राफ़ के साथ नहीं जानता (यदि आप जानते हैं, तो टिप्पणियों में लिखें, यह देखना दिलचस्प है)

ग्राफ़ के कॉन्फ़िगरेशन का सामान्य आरेख कुछ इस तरह दिखता है (कड़ाई से न्याय न करें, मैंने इसे खुद आकर्षित किया)। प्रत्येक तत्व की यहां जरूरत है, कोई अतिश्योक्ति नहीं है।


सभी कार्य यह समझने के साथ शुरू होते हैं कि डेटा सेट रिकॉर्ड में क्या होना चाहिए और इस अनुसूची के लिए डेटाबेस में एक तालिका बनाना चाहिए।


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

इसलिए, हम एक तालिका बनाते हैं जहां रिकॉर्ड रिकॉर्ड आईडी के साथ यह सभी जानकारी + सेवा फ़ील्ड है। (पुनश्च: तालिकाएँ हम ब्राउज़र से सीधे क्लाउड में संपादित कर सकते हैं)।



यह एक साधारण मामला है, लेकिन यह बहुत अधिक जटिल हो सकता है, जहां अधिक क्षेत्र या कई टेबल हैं।

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


क्योंकि यदि डेटा सेट और भंडारण संरचना मनमानी हो सकती है, तो इस संरचना को संग्रहीत प्रक्रिया के माध्यम से नियंत्रित किया जाना चाहिए।


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

उदाहरण के लिए, स्वचालित रूप से बनाई गई ऐड प्रक्रिया का एक टुकड़ा इस तरह दिखता है



सभी प्रक्रियाओं को सीधे वेब इंटरफेस से संपादित किया जाता है। संकलन तर्क PL-SQL के समान है।

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

प्रत्येक क्रिया में शेड्यूल इंगित करता है कि इस क्रिया के लिए कौन सी प्रक्रिया जिम्मेदार है।


"में निर्मित" अनुसूची सेटिंग्स

लेकिन "वायर्ड" सेटिंग्स भी हैं जिन्हें केवल कॉन्फ़िगर किया जा सकता है, लेकिन बदला नहीं गया है। यह केवल आवश्यक नहीं है।

- तिथि-समय निर्देशांक किसी भी रिकॉर्ड का एक अभिन्न गुण हैं
- सिस्टम में ग्राफ का स्थान। यह इंटरफ़ेस के अंतर्निहित संपादक का उपयोग करके संपादित किया गया है और ग्राफ़ से ही ऐसा करने की कोई आवश्यकता नहीं है।
- उपयोगकर्ता की स्मृति जहां थी - इस संपत्ति को सीधे कॉन्फ़िगर करने की आवश्यकता नहीं है।



सेटिंग्स में, चरण (उदाहरण के लिए, 20 मिनट या 30 का ग्रिड) और काम के घंटे की सीमा (उदाहरण के लिए, 8 से 20 तक) को भी निर्दिष्ट किया जा सकता है।

उदाहरण के लिए, अतिरिक्त समय में कटौती करने के लिए समय सीमा की आवश्यकता होती है, यदि सभी कर्मचारी 8 घंटे एक मानक कार्य दिवस काम करते हैं, तो यह घंटे को प्रदर्शित करने के लिए कोई मतलब नहीं है।

चरण - चार्ट ग्रिड को परिभाषित करता है। उदाहरण के लिए, एक क्लिनिक में 20 मिनट के लिए डॉक्टर की नियुक्ति का कार्यक्रम हो सकता है, दूसरे 15 में, तीसरे 30 में। यह सब विन्यास योग्य है।

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

चरणों की सीमा हम 5, 10, 15, 30, 60 मिनट निर्धारित कर सकते हैं।

रिकॉर्ड उत्पादन

यह एक प्रक्रिया बनाने और निर्दिष्ट करने के लिए पर्याप्त नहीं है। यह आवश्यक है कि शेड्यूल समझता है कि इसके भाग के लिए इसके साथ कैसे काम करना है।


टोपी

सबसे महत्वपूर्ण बात यह है कि चार्ट के हेडर को इंगित करें। प्रक्रिया के आउटपुट फ़ील्ड में से कौन सा शीर्षक होना चाहिए।

एक शैक्षिक संगठन में एक वर्ग अनुसूची के निर्माण के तर्क पर विचार करें। मान लीजिए कि एक रिकॉर्ड में शिक्षक-समूह का एक सेट है।

यहां आप शिक्षकों के लिए एक शीर्षक बना सकते हैं, फिर अनुसूची निम्नानुसार बनाई जाएगी:



लेकिन आप समूह द्वारा कर सकते हैं, फिर इस तरह:


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

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

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

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

क्या आउटपुट नहीं है

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

क्या छिपाना

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

संदर्भ

यह बहुत सुविधाजनक है जब कुछ क्षेत्र एक कड़ी हो सकते हैं।

उदाहरण के लिए, यदि हम कार्यों के लिए समय निर्धारित करते हैं, तो कार्य में आने के लिए इसकी संख्या पर क्लिक क्यों नहीं करते हैं।

हमारे पास विन्यासकर्ता में एक मानक लिंकिंग तंत्र है। आप उन्हें वहां बना सकते हैं, और ग्राफ़ में फ़ील्ड के साथ संबद्ध कर सकते हैं। सब कुछ काम करता है।

नाम

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

उदाहरण के लिए, हमारे साथ उपरोक्त सभी इस तरह दिखते हैं। इस प्रक्रिया के क्षेत्रों की जाँच करें।



रिकॉर्ड का आउटपुट इस तरह दिखेगा:



एक नई प्रविष्टि जोड़ना

एक नया रिकॉर्ड जोड़ने के लिए क्षेत्रों को जोड़ने की प्रक्रिया द्वारा निर्धारित किया जाना चाहिए। प्रक्रिया के प्रत्येक इनपुट पैरामीटर को जानकारी प्रदान की जानी चाहिए।

लेकिन एक तरकीब है। फ़ील्ड केवल पाठ ही नहीं, बल्कि सूचियाँ भी हो सकती हैं।

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

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



सामान्य तौर पर, एक प्रक्रिया जो एक अन्य प्रक्रिया के क्षेत्र में ट्विच होती है।

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

यह इंगित करना भी आवश्यक है कि कौन सा जोड़ा फ़ील्ड हेडर होगा। हमें संपादन प्रणाली में इसकी आवश्यकता होगी।

यह हमारे लिए इस तरह दिखता है:



रिकॉर्ड संपादित करें

यह अभी भी यहाँ दिलचस्प है। यह सूची के सभी क्षेत्रों को परिशिष्ट के रूप में प्रदर्शित करने के लिए पर्याप्त नहीं है। इन सूचियों में वर्तमान स्थिति (चयनित) का चयन करना आवश्यक है। हम संपादन कर रहे हैं।

ऐसा करने के लिए, आपको सृजन फ़ील्ड को आउटपुट फ़ील्ड के साथ जोड़ना होगा। और एक सूची बॉक्स के मामले में, यह न केवल आउटपुट से जानकारी का एक हिस्सा है, बल्कि इस जानकारी का पहचानकर्ता भी है।

यानी यहाँ यह आवश्यक है:

a) संपादन प्रक्रिया इंगित करें
b) इसके खेतों को जोड़ के क्षेत्रों के साथ जोड़ दें
ग) सूची में वर्तमान डेटा डालने के लिए रिकॉर्ड डेटा के आउटपुट के क्षेत्रों के साथ अपने खेतों को संबद्ध करें

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

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

हमारे साथ ऐसा दिखता है



रिकॉर्ड हटाएं

हटाना सबसे आसान है। एक इनपुट पैरामीटर के साथ विलोपन प्रक्रिया को केवल संकेत दिया गया है: चार्ट का रिकॉर्ड आईडी।

रिकॉर्ड्स को जोड़ने / संशोधित / हटाने के दौरान इवेंट हैंडलिंग। ट्रिगर। क्रॉस रिकॉर्ड।

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

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

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

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

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

रिपोर्ट

चार्ट रिपोर्ट की भी आवश्यकता होती है, और इस तरह की संरचना के साथ उन्हें किया जा सकता है।

उदाहरण के लिए, यह रिपोर्ट करना आवश्यक था कि पिछले महीने कितने कर्मचारी यात्रा कर रहे थे। हम रिपोर्ट विन्यासकर्ता के पास जाते हैं, वांछित तालिका का चयन करते हैं जहां चार्ट प्रविष्टियां संग्रहीत होती हैं, आवश्यक फ़िल्टर और एकत्रीकरण फ़ंक्शन सेट करते हैं - और वाओल, रिपोर्ट तैयार है।

चार्ट डेटा के अन्य उपयोग

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



समय की अति

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

बेशक, अगर समय बीत जाता है, तो सबसे अधिक संभावना कुछ योजनाबद्ध नहीं होती है।एक व्यक्ति एक साथ दो स्थानों पर नहीं हो सकता है, लेकिन यहां तक ​​कि ऐसी स्थितियों को सही ढंग से प्रदर्शित किया जाना चाहिए।



पहुँच और सुरक्षा

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

अगला शेड्यूल के आंतरिक अधिकार आते हैं। वे

1 हो सकते हैं ) संपादन

- केवल लेखक
- केवल लेखक का समूह (उन सभी कर्मचारियों को शामिल किया जाता है, जिनमें रिकॉर्ड का लेखक सदस्य है)
- केवल लेखक का विभाजन (स्टॉक के अनुसार लेखक के विभाजन में शामिल सभी कर्मचारी)

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

2) निष्कासन समान है।

- केवल लेखक
- केवल समूह
- केवल विभाजन

हमें आंतरिक अधिकारों की आवश्यकता क्यों है?

यदि यह एक व्यक्तिगत अनुसूची है, या कुछ विशेषताएं हैं, तो यह केवल लेखक को रखने के लिए समझ में आता है।

लेकिन शिफ्ट कर्मचारी और परिस्थितियां हैं जहां रिकॉर्ड को संपादित करने की आवश्यकता है और कर्मचारी काम पर नहीं है। क्या करें?यह समूह या इकाई द्वारा संपादन के लिए ऐसे कार्यक्रम निर्धारित करने के लिए समझ में आता है ताकि अन्य पारी कर्मचारी इन रिकॉर्डों के साथ काम कर सकें।

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

---

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

इसके अलावा, हम सिस्टम के अन्य तत्वों के साथ सबसे गहरी कॉन्फ़िगरेशन क्षमताओं और बातचीत की संभावना भी प्राप्त करते हैं।