SAP S/4HANA पोस्टिंग तिथि, दस्तावेज़ तिथि और पोस्टिंग पériode अस्वीकृति निदान
पोस्टिंग अस्वीकृति आमतौर पर एक पériode-नियंत्रण समस्या होती है, न कि दस्तावेज़-तिथि की गलती। जर्नल एंट्री तिथि दस्तावेज़ की जारी तिथि है, जबकि पोस्टिंग तिथि वह पériode तय करती है जिसे सिस्टम जांचता है। पोस्टिंग पériode वेरिएंट, फिस्कल वर्ष वेरिएंट नहीं, हेडर और प्रत्येक खाता प्रकार के लिए पériode खोलता और बंद करता है।
इस पृष्ठ पर
संक्षिप्त उत्तर
पोस्टिंग अस्वीकृति आमतौर पर एक पériode-नियंत्रण समस्या होती है, न कि तिथि-प्रविष्टि की गलती। जर्नल एंट्री तिथि दस्तावेज़ की जारी तिथि है, जबकि पोस्टिंग तिथि यह तय करती है कि सिस्टम कौन सा पोस्टिंग पériode जांचता है। पोस्टिंग पériode वेरिएंट, फिस्कल वर्ष वेरिएंट नहीं, यह तय करता है कि पériode दस्तावेज़ हेडर और लाइन आइटम पर प्रत्येक खाता प्रकार के लिए खुली है या बंद। एक पोस्टिंग तब भी विफल हो सकती है जब पोस्टिंग तिथि सही कैलेंडर महीने में गिरती है, यदि संबंधित पériode बंद है, यदि कोई विशिष्ट खाता प्रकार बंद है, या यदि उपयोगकर्ता के पास समायोजन अंतराल के लिए अधिकार नहीं है। फिस्कल वर्ष वेरिएंट केवल यह परिभाषित करते हैं कि कितनी पériode मौजूद हैं और वे कहाँ शुरू और समाप्त होती हैं; वे पériode खोलते या बंद नहीं करते। कॉन्फ़िगरेशन बदले बिना निदान करते समय, अस्वीकृति संदेश को पढ़ें, यह पहचानें कि क्या हेडर या लाइन-आइटम खाता प्रकार विफल हुआ, और तय करें कि क्या पोस्टिंग तिथि, दस्तावेज़ तिथि या खाता असाइनमेंट वास्तविक मुद्दा है। यह मानकर चलें कि बंद पériode को फिर से खोला जाना चाहिए; इसके बजाय इरादा पériode, वेरिएंट असाइनमेंट और उपयोगकर्ता के अधिकार की पुष्टि करें, फिर तिथि सुधारना, अलग खाता प्रकार उपयोग करना या पériode बनाए रखने वाले व्यक्ति को भेजना जैसा वैध कार्य चुनें।
दो तिथियों को अलग करें
दस्तावेज़ हेडर में जर्नल एंट्री तिथि और पोस्टिंग तिथि दोनों होती हैं, और वे आपस में बदलने योग्य नहीं हैं। जर्नल एंट्री तिथि मूल दस्तावेज़ की जारी तिथि है। पोस्टिंग तिथि आमतौर पर वह तिथि होती है जिसका उपयोग वित्तीय लेखांकन में दस्तावेज़ प्रविष्ट करते समय किया जाता है, और यह वह फ़ील्ड है जो पोस्टिंग पériode जांच को संचालित करती है। पोस्टिंग पériode स्वयं पोस्टिंग तिथि से व्युत्पन्न होती है, और वही पériode रिपोर्टिंग के लिए दस्तावेज़ मूल्यों को सही रिपोर्टिंग पériode में रखने के लिए उपयोग की जाती है। दूसरे शब्दों में, दस्तावेज़ तिथि बताती है कि व्यावसायिक दस्तावेज़ कब बनाया गया, जबकि पोस्टिंग तिथि सिस्टम को बताती है कि पériode नियंत्रण और रिपोर्टिंग के लिए पोस्टिंग कहाँ फ़ाइल करनी है।
यह अंतर महत्वपूर्ण है क्योंकि एक उपयोगकर्ता एक दस्तावेज़ तिथि प्रविष्ट कर सकता है जो तर्कसंगत लग सकती है और फिर भी अस्वीकृत हो सकता है यदि पोस्टिंग तिथि बंद पériode में गिरती है। सिस्टम की पériode जांच पोस्टिंग तिथि से जुड़ी होती है, केवल दस्तावेज़ तिथि से नहीं। यदि दोनों तिथियां भिन्न हैं, तो यह मानें कि दस्तावेज़ तिथि नियंत्रित मान है ऐसा न करें। पोस्टिंग तिथि को पériode स्वीकृति के लिए प्राथमिक मान के रूप में मानें, और जर्नल एंट्री तिथि को दस्तावेज़ की जारी संदर्भ के रूप में मानें।
एक ठोस उदाहरण के लिए, एक बिल की कल्पना करें जिसकी तिथि 28 सितंबर है और पोस्टिंग तिथि 30 सितंबर है। एक कैलेंडर फिस्कल-वर्ष वेरिएंट में, दोनों तिथियां सितंबर में गिरती हैं, इसलिए दस्तावेज़ तिथि और पोस्टिंग तिथि एक ही महीने की ओर इशारा करती हैं। फिर भी, उस alignment स्वीकृति की गारंटी नहीं देता, क्योंकि स्वीकृति इस पर निर्भर करती है कि क्या संबंधित खाता प्रकारों के लिए सितंबर पोस्टिंग पériode खुली है। उदाहरण काल्पनिक है और केवल दो तिथियों के अर्थ को यह पूछने से अलग करने के लिए उपयोग किया जाता है कि क्या पériode खुली है।
पोस्टिंग तिथि को फिस्कल कैलेंडर से संबंधित करें
पोस्टिंग तिथि कंपनी कोड को असाइन किए गए फिस्कल वर्ष वेरिएंट के माध्यम से एक फिस्कल पériode में मैप की जाती है। उस वेरिएंट यह परिभाषित करता है कि कितनी पériode मौजूद हैं और प्रत्येक पériode कहाँ शुरू और समाप्त होती है। यह स्वयं यह तय नहीं करता कि कोई पériode खुली है या बंद। यह अलगाव महत्वपूर्ण है: कैलेंडर तर्क सिस्टम को बताता है कि एक तिथि किस फिस्कल पériode से संबंधित है, लेकिन खुला/बंद निर्णय कहीं और लिया जाता है।
एक सरल कैलेंडर फिस्कल वर्ष में, 30 सितंबर की पोस्टिंग तिथि सितंबर की ओर मैप होती है। एक गैर-कैलेंडर फिस्कल वर्ष में, वही कैलेंडर तिथि एक अलग फिस्कल पériode में गिर सकती है, या एक फिस्कल पériode दो कैलेंडर महीनों के हिस्सों में फैल सकती है। यही कारण है कि 'सितंबर बराबर पériode 9' जैसा एक naive नियम किसी विशिष्ट सिस्टम में गलत हो सकता है। फिस्कल वर्ष वेरिएंट वह कारण है जिससे मैपिंग मौजूद है, लेकिन यह वह नियंत्रण नहीं है जो पोस्टिंग को स्वीकार या अस्वीकार करता है।
क्योंकि फिस्कल वर्ष वेरिएंट केवल पériode संरचना को परिभाषित करता है, इसलिए आपको इसका उपयोग तिथि-से-पériode मैपिंग की व्याख्या के लिए करना चाहिए, यह निष्कर्ष निकालने के लिए नहीं कि कोई पériode खुली होनी चाहिए। यदि मैपिंग स्वयं स्पष्ट नहीं है, तो समस्या पोस्टिंग तिथि प्रविष्टि के बजाय वेरिएंट की पériode सीमाओं की हो सकती है। सितंबर उदाहरण में, कैलेंडर मैपिंग केवल इसलिए सीधी है क्योंकि माना गया वेरिएंट स्पष्ट रूप से कैलेंडर-आधारित है; उस अनुमान को हर सिस्टम पर ले जाना नहीं चाहिए।
पोस्टिंग पériode वेरिएंट की जांच करें
पोस्टिंग पériode वेरिएंट वह ऑब्जेक्ट है जो नियंत्रित करता है कि कौन सी फिस्कल पériode खुली हैं या बंद हैं। इसका एक ID और विवरण होता है और यह एक या अधिक कंपनी कोड को असाइन किया जाता है, इसलिए एक ही वेरिएंट साझा करने वाले कंपनी कोड अपनी पériode को एक साथ प्रबंधित कर सकते हैं। वेरिएंट बनाए जाने के बाद, इसे वैश्विक कंपनी कोड सेटिंग्स में असाइन किया जाता है और यह लीडिंग लेजर के लिए उपयोग किया जाता है, अतिरिक्त लेजर उस असाइनमेंट से डिफ़ॉल्ट होते हैं जब तक कि किसी गैर-लीडिंग लेजर के लिए कोई अलग वेरिएंट परिभाषित न किया गया हो।
वेरिएंट की जांच पोस्टिंग तिथि के खिलाफ की जाती है। पहली जांच समग्र या हेडर लाइन है, जो दस्तावेज़ कुल को कवर करती है और हर पोस्टिंग के लिए पहले जांची जाती है। उस हेडर लाइन के लिए कम से कम उन्हीं पériode खुली होनी चाहिए जितनी कि कोई भी खाता प्रकार, क्योंकि यदि हेडर बंद है तो पोस्टिंग बिल्कुल नहीं गुजर सकती। यदि सभी खाता प्रकार एक ही तरीके से व्यवहार किए जाते हैं, तो हेडर लाइन ही एकमात्र आवश्यक लाइन हो सकती है। यदि खाता प्रकारों को अलग-अलग व्यवहार की आवश्यकता है, तो वेरिएंट प्रत्येक खाता प्रकार के लिए अलग-अलग इंटरवल परिभाषित कर सकता है।
खाता प्रकार विवरण महत्वपूर्ण है क्योंकि पériode-अंत बंद staggered हो सकता है। उदाहरण के लिए, ग्राहक या आपूर्तिकर्ता पोस्टिंग G/L खातों के पोस्टिंग से पहले बंद की जा सकती हैं। खाता प्रकारों में ग्राहक, आपूर्तिकर्ता, संपत्ति, G/L खाते, सामग्री और अनुबंध खाते शामिल हैं। इसलिए एक पोस्टिंग हेडर जांच पार कर सकती है और फिर भी एक लाइन आइटम पर विफल हो सकती है यदि उस लाइन के खाता प्रकार के लिए फिस्कल पériode बंद है। सितंबर उदाहरण में, पोस्टिंग तिथि हेडर के लिए वैध हो सकती है जबकि एक आपूर्तिकर्ता खाता बंद है, और सिस्टम रिपोर्ट करेगा कि उस फिस्कल पériode में उस आपूर्तिकर्ता खाते के लिए लेजर खुला नहीं है।
एक ठोस तिथि उदाहरण का पता लगाएं
28 सितंबर की तिथि वाले और 30 सितंबर को पोस्ट किए गए काल्पनिक बिल का उपयोग करके, पहला कदम यह है कि सिस्टम को असाइन किए गए फिस्कल वर्ष वेरिएंट के तहत पोस्टिंग तिथि को एक फिस्कल पériode में मैप करने दें। एक स्पष्ट रूप से माने गए कैलेंडर फिस्कल-वर्ष वेरिएंट के तहत, वह मैपिंग सितंबर की ओर इशारा करती है। यह केवल मैपिंग चरण है; यह अभी तक नहीं कहता कि क्या सितंबर खुला है।
अगला कदम पोस्टिंग पériode वेरिएंट जांच है। सिस्टम पहले पोस्टिंग तिथि के खिलाफ हेडर लाइन की जांच करता है। यदि सितंबर पériode हेडर इंटरवल में खुली है, तो हेडर जांच पार हो जाती है। यदि हेडर बंद है, तो पोस्टिंग उस बिंदु पर अस्वीकृत कर दी जाती है, लाइन आइटम की परवाह किए बिना। यदि हेडर पार हो जाता है, तो सिस्टम फिर प्रत्येक लाइन आइटम के खाता प्रकार की वेरिएंट के खिलाफ जांच करता है। एक सितंबर पोस्टिंग तिथि तब भी विफल हो सकती है यदि संबंधित खाता प्रकार सितंबर के लिए बंद है।
यह वह तरीका है जिससे एक पोस्टिंग तब भी अस्वीकृत हो सकती है जब दस्तावेज़ तिथि और पोस्टिंग तिथि दोनों एक ही महीने से संबंधित लगती हैं। उदाहरण कोई प्रेक्षित सिस्टम परीक्षण नहीं है; यह तीन प्रश्नों को अलग करने का एक तरीका है: पोस्टिंग तिथि किस पériode में मैप होती है, क्या उस पériode हेडर में खुली है, और क्या लाइन आइटम पर विशिष्ट खाता प्रकार खुला है। एक ही दस्तावेज़ में वे तीन प्रश्न अलग-अलग उत्तर दे सकते हैं।
Read the rejection before changing anything
जब कोई पोस्टिंग अस्वीकृत होती है, तो पहला निदानात्मक कदम तुरंत कॉन्फ़िगरेशन बदलने के बजाय अस्वीकृति संदेश को सावधानीपूर्वक पढ़ना है। सिस्टम की पériode जाँच विभिन्न विफलताएँ लौटाती है जो इस बात पर निर्भर करती हैं कि समस्या कहाँ उत्पन्न होती है। यदि पोस्टिंग तिथि किसी ऐसे वित्तीय पériode में आती है जो बंद है, तो सिस्टम यह जवाब देता है कि उस पériode में पोस्टिंग संभव नहीं है। यदि पोस्टिंग तिथि वैध है लेकिन किसी लाइन-आइटम खाता प्रकार बंद है, तो सिस्टम यह संदेश लौटा सकता है कि उस वित्तीय पériode और उस खाते के लिए बही खाता खुला नहीं है।
यह अंतर मुख्य निदानात्मक संकेत है। हेडर-स्तरीय अस्वीकृति पोस्टिंग तिथि और समग्र पोस्टिंग पériode वेरिएंट सेटिंग की ओर इशारा करती है। लाइन-आइटम अस्वीकृति खाता प्रकार, विशिष्ट खाता या उस खाता प्रकार को शासित करने वाले अंतराल की ओर इशारा करती है। दोनों विफलताओं को एक ही समस्या की तरह न Treat करें। अस्वीकृति पाठ आपको बताता है कि क्या सिस्टम हेडर जाँच पर रुका या बाद में लाइन-आइटम जाँच पर।
सितंबर उदाहरण में, हेडर अस्वीकृति का अर्थ होगा कि पोस्टिंग तिथि के लिए हेडर अंतराल में सितंबर पोस्टिंग पériode खुली नहीं है। लाइन-आइटम अस्वीकृति का अर्थ हो सकता है कि पोस्टिंग तिथि स्वीकार्य है लेकिन उस पériode के लिए आपूर्तिकर्ता, ग्राहक, संपत्ति, जीएल, सामग्री या अनुबंध-खाता अंतराल बंद है। संदेश को सटीक रूप से पढ़ने से आपको गलत चीज़ बदलने से बचाता है, जैसे दस्तावेज़ तिथि को समायोजित करना जबकि वास्तविक समस्या बंद पोस्टिंग पériode या बंद खाता-प्रकार अंतराल है।
Check scope and authorizations
पोस्टिंग पériode वेरिएंट में अलग-अलग अंतराल होते हैं, और शामिल अंतराल जाँच के क्षेत्र को बदलता है। अंतराल 1, जिसे कभी-कभी समायोजन अंतराल कहा जाता है, सामान्य व्यापार प्रसंस्करण के बाहर की पériode खोलने के लिए उपयोग किया जाता है और इसमें एक प्राधिकरण समूह हो सकता है। वह प्राधिकरण समूह उपयोगकर्ता की सुरक्षा प्रोफ़ाइल में प्रासंगिक अनुमति ऑब्जेक्ट के माध्यम से उस पériode में पोस्ट करने के लिए कौन कर सकता है, इसे सीमित करता है। अंतराल 2, जिसे कभी-कभी सामान्य अंतराल कहा जाता है, व्यापार लेनदेन के लिए वर्तमान पériode खोलता है और हर उपयोगकर्ता पर लागू होता है; इसे उसी तरह सीमित नहीं किया जा सकता। अंतराल 3 प्रबंधन लेखांकन से वित्तीय लेखांकन में पोस्टिंग के लिए उपयोग किया जाता है, और यदि यह भरा नहीं गया है, तो अंतराल 1 और 2 की सेटिंग भी उन पोस्टिंग पर लागू होती है।
इसका अर्थ है कि अस्वीकृति एक से अधिक स्रोत से आ सकती है। कोई उपयोगकर्ता बिना आवश्यक प्राधिकरण के समायोजन अंतराल में पोस्ट करने का प्रयास कर सकता है, भले ही पériode तकनीकी रूप से खुली हो। या सामान्य अंतराल केवल पोस्टिंग तिथि को कवर नहीं कर रहा हो। या सीओ- संबंधित पोस्टिंग को खुला एफआई पोस्टिंग पériode और एक अलग सीओ पériode लॉक की आवश्यकता हो सकती है। निदानात्मक प्रश्न केवल 'क्या पériode खुली है?' नहीं है, बल्कि 'कौन सा अंतराल लागू होता है, और क्या उपयोगकर्ता उस अंतराल तक पहुँच रखता है?' भी है।
सितंबर उदाहरण के लिए, यदि पोस्टिंग तिथि किसी ऐसी पériode में है जो केवल अंतराल 1 में खुली है और उपयोगकर्ता के पास आवश्यक प्राधिकरण समूह नहीं है, तो पोस्टिंग अस्वीकृत हो सकती है भले ही वह पériode अन्य लोगों के लिए खुली हो। यह एक ऐसी स्थिति है जो एक ऐसी पériode से अलग है जो सभी के लिए बंद है। इन मामलों को अलग करना महत्वपूर्ण है क्योंकि वैध अगला कदम इस बात पर निर्भर करता है कि समस्या प्राधिकरण, अंतराल कवरेज, या बंद पériode में से कौन सी है।
Choose a legitimate next action
एक बार अस्वीकृति को समझ लेने के बाद, अगला कदम निदान किए गए कारण से मेल खाना चाहिए और यह नहीं मानना चाहिए कि पériode को पुनः खोलना सही ठीक करने का तरीका है। यदि पोस्टिंग तिथि केवल बंद पériode में है और व्यापार इरादा किसी अलग पériode में पोस्ट करना है, तो उचित कदम पोस्टिंग तिथि को उस पériode में सही करना हो सकता है जो इच्छित खाता प्रकारों के लिए खुली है। यदि दस्तावेज़ तिथि और पोस्टिंग तिथि को आपस में उलझाया जा रहा है, तो स्पष्ट करें कि व्यापार प्रक्रिया वास्तव में कौन सी तिथि माँगती है और पोस्टिंग तिथि को उसी अनुसार दर्ज करें।
यदि हेडर पास हो जाता है लेकिन कोई लाइन-आइटम खाता प्रकार विफल होता है, तो समस्या खाता असाइनमेंट या उस खाता प्रकार के लिए पériode स्थिति हो सकती है। उस स्थिति में, वैध कदम यह सत्यापित करना है कि क्या खाता प्रकार इच्छित पériode के लिए खुला होना चाहिए या पोस्टिंग को अलग तरह से रूट किया जाना चाहिए। यदि विफलता समायोजन अंतराल से जुड़ी है और उपयोगकर्ता के पास प्राधिकरण नहीं है, तो कदम एक ऐसे उपयोगकर्ता का उपयोग करना है जिसके पास आवश्यक प्राधिकरण हो या पोस्टिंग को उचित प्रक्रिया के माध्यम से रूट करना है, न कि अनौपचारिक रूप से पहुँच को विस्तारित करना।
यदि पोस्टिंग सीओ- प्रासंगिक है, तो याद रखें कि एफआई और सीओ पériode नियंत्रण अलग हो सकते हैं। प्रबंधन लेखांकन से वित्तीय लेखांकन में पोस्टिंग के लिए खुला एफआई पोस्टिंग पériode आवश्यक हो सकता है और सीओ पériode लॉक से भी प्रभावित हो सकता है। वैध अगला कदम एक तरफ़ को अकेले बदलने के बजाय दोनों नियंत्रणों की पुष्टि करना हो सकता है। सभी मामलों में, लक्ष्य अस्वीकृति द्वारा पहचाने गए विशिष्ट नियंत्रण विफलता को हल करना है, न कि डिफ़ॉल्ट प्रतिक्रिया के रूप में कॉन्फ़िगरेशन बदलना।
Keep edition and configuration boundaries
उद्धरणों में दिए गए अवधारणाएँ सामान्य हैं, लेकिन मूर्त क्षेत्र, ऐप नाम, प्राधिकरण ऑब्जेक्ट और उपलब्ध नियंत्रण उत्पाद कॉन्फ़िगरेशन और संस्करण के अनुसार बदल सकते हैं। उद्धरणों में कहा गया है कि वित्तीय वर्ष वेरिएंट पériode की संख्या और उनकी शुरुआत और अंत तिथियाँ परिभाषित करते हैं, और कि पोस्टिंग पériode वेरिएंट खुलने और बंद होने का नियंत्रण करते हैं। यह भी कहा गया है कि हेडर लाइन पहले जाँची जाती है और खाता प्रकार अलग तरह से संभाले जा सकते हैं। ये वे सीमाएँ हैं जिनके भीतर आप काम करना चाहिए: वित्तीय वर्ष वेरिएंट का उपयोग पériode संरचना समझने के लिए करें, और पोस्टिंग पériode वेरिएंट का उपयोग खुला/बंद नियंत्रण समझने के लिए करें।
एक ही सिस्टम से अति-सामान्यीकरण न करें। एक कैलेंडर वित्तीय वर्ष सितंबर उदाहरण को सरल दिखा सकता है, लेकिन एक गैर-कैलेंडर वेरिएंट या विशेष पériode मैपिंग और स्वीकृति तर्क को बदल सकते हैं। गैर-लीडिंग बही खाते अलग पोस्टिंग पériode वेरिएंट का उपयोग कर सकते हैं, इसलिए लीडिंग-बही डिफ़ॉल्ट हमेशा पूरी कहानी नहीं होती। उद्धरणों में यह भी दिया गया है कि अंतराल 3 खाली छोड़ा जा सकता है, जिसमें मामले में अंतराल 1 और 2 सीओ- प्रासंगिक पोस्टिंग पर भी लागू होते हैं, जो एक और कॉन्फ़िगरेशन-निर्भर विवरण है।
निदानात्मक तर्क को उस चीज़ से बाँधे रखें जो सिस्टम वास्तव में जाँचता है: पोस्टिंग तिथि की पोस्टिंग पériode वेरिएंट के खिलाफ जाँच, पहले हेडर स्तर पर और फिर खाता-प्रकार स्तर पर, जहाँ लागू हो वहाँ अंतराल और प्राधिकरण प्रभावों के साथ। सितंबर उदाहरण का उपयोग केवल तिथि अर्थ, वित्तीय मैपिंग और पériode नियंत्रण को अलग करने के तरीके के रूप में करें। इसे यह साबित करने के लिए न Treat करें कि कोई विशिष्ट सिस्टम कैसे व्यवहार करेगा, और इसे एक अवलोकित परीक्षण परिणाम के रूप में प्रस्तुत न करें।
क्या जाँचें
- पुष्टि करें कि क्या अस्वीकृति दस्तावेज़ हेडर पériode को संदर्भित करती है या लाइन आइटम पर किसी विशिष्ट खाता प्रकार को।
- पोस्टिंग तिथि की जांच करें, केवल दस्तावेज़ तिथि नहीं, क्योंकि पोस्टिंग तिथि पériode जांच को संचालित करती है।
- फिस्कल वर्ष वेरिएंट की पहचान केवल यह समझने के लिए करें कि कितनी पériode मौजूद हैं; इसे खुला/बंद नियंत्रण न मानें।
- यह मानें से पहले कि कोई पériode खुली है, कंपनी कोड और लीडिंग लेजर को असाइन किए गए पोस्टिंग पériode वेरिएंट की पहचान करें।
- पुष्टि करें कि क्या विफल पériode इंटरवल 1, इंटरवल 2 या इंटरवल 3 में है, क्योंकि अधिकार और क्षेत्र भिन्न होते हैं।
- यदि उस इंटरवल शामिल है, तो पुष्टि करें कि क्या उपयोगकर्ता के पास समायोजन-इंटरवल पोस्टिंग के लिए आवश्यक अधिकार समूह है।
- एक बंद पériode समस्या को गलत जर्नल एंट्री प्रकार या गलत खाता असाइनमेंट से अलग करें, जो रिपोर्टिंग को भी विकृत कर सकते हैं।
- पहले कदम के रूप में कॉन्फ़िगरेशन बदलने से बचें; कारण को संकुचित करने के लिए पहले अस्वीकृति पाठ और दस्तावेज़ फ़ील्ड का उपयोग करें।
उपयोग की सीमाएँ
यह मार्गदर्शन दी गई SAP सीखने की उद्धरणों पर आधारित है और यह वर्णनात्मक है, कॉन्फ़िगरेशन प्रक्रिया नहीं। दस्तावेज़ फ़ील्ड नाम, ऐप नाम, अधिकार ऑब्जेक्ट और उपलब्ध नियंत्रण उत्पाद संस्करण, संस्करण और कंपनी कोड कॉन्फ़िगरेशन के अनुसार भिन्न हो सकते हैं। उद्धरण समझाते हैं कि फिस्कल वर्ष वेरिएंट पériode की संख्या और उनकी शुरुआत और अंत तिथियां परिभाषित करता है, जबकि पोस्टिंग पériode वेरिएंट खोलने और बंद करने का नियंत्रण करता है; वे सार्वभौमिक फ़ील्ड सूची या हर सिस्टम के लिए गारंटीड संदेश पाठ प्रदान नहीं करते। विशेष पériode, गैर-कैलेंडर फिस्कल वर्ष और अलग-अलग पोस्टिंग पériode वेरिएंट वाले गैर-लीडिंग लेजर एक सरल महीने-से-पériode अनुमान को तोड़ सकते हैं। चित्रात्मक सितंबर उदाहरण काल्पनिक है और यह निष्पादित सिस्टम परीक्षण या प्रेक्षित पुनर्प्राप्ति परिणाम नहीं है। इसे अपने वातावरण में वास्तविक सिस्टम संदेश, विशिष्ट वेरिएंट सेटअप या अधिकार डिज़ाइन के विकल्प के रूप में उपयोग न करें।