SAP SD: यह क्या करता है और इम्प्लीमेंटेशन कहाँ टूटते हैं

SAP SD (Sales and Distribution) SAP में order-to-cash चलाता है: कोटेशन, सेल्स ऑर्डर, डिलीवरी, बिलिंग और फ़ाइनेंस को हैंडऑफ़। S/4HANA पर यह उन तरीकों से बदलता है जो प्रोजेक्ट के स्कोप के लिए मायने रखते हैं। ग्राहक बिज़नेस पार्टनर बन जाते हैं, क्रेडिट मैनेजमेंट SAP Credit Management में चला जाता है, रिबेट कंडीशन कॉन्ट्रैक्ट में चले जाते हैं, और बिलिंग सीधे Universal Journal में पोस्ट होती है। यह गाइड सेल्स ऑपरेशन लीड, फ़ाइनेंस कंट्रोलर और प्रोजेक्ट मैनेजर के लिए है, जिन्हें जानना है कि SD क्या करता है और कहाँ टूटता है। दूसरे सवाल का छोटा जवाब: कस्टमर मास्टर डेटा, प्राइसिंग कंडीशन, अवेलेबिलिटी चेक और अकाउंट डिटरमिनेशन। go-live से पहले इन चारों को असली डेटा के साथ टेस्ट करें।

एक रोलआउट में, पूरे SAP इम्प्लीमेंटेशन के बाद, order-to-cash के सारे कदम ठीक वैसे ही बने थे जैसे डिज़ाइन में थे। प्रोसेस मैप पर वे ठीक दिखते थे। किसी ने यह नहीं जाँचा था कि प्रोडक्शन से स्टॉक अपडेट कैसे आ रहे हैं।

सेल्स ने ग्राहकों को पाँच दिन बताए। मैन्युफ़ैक्चरिंग को पता था कि यह दस के करीब है।

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

SD लॉजिस्टिक्स की शृंखला के सबसे आगे बैठता है। यह डॉक्यूमेंट की एक कड़ी के ज़रिए ग्राहक की दिलचस्पी को इनवॉइस में बदलता है:

1. इन्क्वायरी: ग्राहक कीमत या उपलब्धता पूछता है
2. कोटेशन: वैधता अवधि के साथ कीमत और डिलीवरी का औपचारिक प्रस्ताव
3. सेल्स ऑर्डर: ग्राहक वचनबद्ध होता है, अवेलेबिलिटी चेक चलता है और डिलीवरी की तारीख़ पक्की होती है
4. डिलीवरी: वेयरहाउस पिक और पैक करता है, गुड्स इश्यू से स्टॉक घटता है
5. बिलिंग: इनवॉइस बनता है, अपने अकाउंटिंग डॉक्यूमेंट के साथ
6. पेमेंट: फ़ाइनेंस आने वाले भुगतान को ओपन आइटम के सामने क्लियर करता है

हर डॉक्यूमेंट अपने पिछले डॉक्यूमेंट का हवाला देता है। यही डॉक्यूमेंट फ़्लो order-to-cash को ट्रेस करने लायक बनाता है। कड़ी साफ़ हो, तो आप हर इनवॉइस को मूल अनुरोध तक वापस ट्रेस कर सकते हैं। अगर डॉक्यूमेंट क्रम से बाहर बनाए जाएँ या बायपास हों, तो रिपोर्टिंग टूटती है और विवाद खड़े होते हैं।

1. 01इन्क्वायरीकीमत या उपलब्धता पूछी गई
2. 02कोटेशनवैधता की तारीख़ के साथ औपचारिक प्रस्ताव
3. 03सेल्स ऑर्डरअवेलेबिलिटी चेक तारीख़ की पुष्टि करता है
4. 04डिलीवरीपिक, पैक, गुड्स इश्यू
5. 05बिलिंगइनवॉइस और अकाउंटिंग डॉक्यूमेंट
6. 06पेमेंटफ़ाइनेंस ओपन आइटम क्लियर करता है

हर इनवॉइस मूल अनुरोध तक ट्रेस हो सकता है

अच्छी तरह हो, तो यह कड़ी हाथ से होने वाले हैंडऑफ़ हटा देती है। एक मैन्युफ़ैक्चरिंग क्लाइंट ने SD के go-live के बाद अपना order-to-cash साइकिल 40% घटा लिया, ज़्यादातर सेल्स, वेयरहाउस और फ़ाइनेंस के बीच के हैंडऑफ़ हटाकर।

सेल्स ऑर्डर और अवेलेबिलिटी चेक

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

अवेलेबल-टू-प्रॉमिस (ATP) सबसे अहम बिज़नेस हिस्सा है। यह जाँचता है कि माँगी गई तारीख़ स्टॉक, योजनाबद्ध रिसीट और मौजूदा प्रतिबद्धताओं से पूरी हो सकती है या नहीं। ठीक से कॉन्फ़िगर हो, तो सेल्स ग्राहकों को वही बताता है जो सिस्टम सच में कमिट कर सकता है। ख़राब कॉन्फ़िगर हो, तो सेल्स वह बताता है जो वह डिलीवर करने की उम्मीद रखता है।

शुरू में बताए रोलआउट में किसी ने नहीं जाँचा था कि प्रोडक्शन से स्टॉक अपडेट कैसे आ रहे हैं। सेल्स ऐसी तारीख़ें बता रहा था जो प्लांट पूरी नहीं कर सकता था।

प्राइसिंग और कंडीशन

प्राइसिंग SD का सबसे कम आँका जाने वाला सेटअप है। पहले इनवॉइस विवाद तक यह सीधा दिखता है।

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

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

प्राइसिंग गवर्नेंस प्रोसेस का फ़ैसला है, कॉन्फ़िगरेशन का नहीं। किसी को कंडीशन रिकॉर्ड के रखरखाव का ओनर बनना होगा।

शिपिंग

डिलीवरी प्रोसेसिंग में पिकिंग, पैकिंग और गुड्स इश्यू आते हैं। गुड्स इश्यू निर्णायक घटना है: वह स्टॉक की कटौती पोस्ट करता है, डिलीवरी को बिलिंग ड्यू लिस्ट पर डालता है और डिलीवरी की असली तारीख़ दर्ज करता है। शिपिंग पॉइंट और रूट डिटरमिनेशन तय करते हैं कि डिलीवरी कैसे बनती हैं। जटिल वितरण नेटवर्क वाली कंपनियाँ इसे SAP Transportation Management (TM) से बढ़ाती हैं।

बिलिंग, अकाउंट डिटरमिनेशन और टैक्स

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

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

क्रेडिट मैनेजमेंट

क्रेडिट चेक उन ऑर्डर को ब्लॉक या फ़्लैग करते हैं जो ग्राहक को उसकी क्रेडिट लिमिट के पार ले जाएँगे। यह तभी चलता है जब लिमिट अपडेट रखी जाएँ। go-live पर तय की गई स्थिर लिमिट का भुगतान के व्यवहार और वॉल्यूम बदलने के साथ कोई मतलब नहीं रह जाता।

जब लिमिट किसी ग्राहक के सामान्य ऑर्डर के आकार से नीचे गिर जाती है, तो हर ऑर्डर अपने आप ब्लॉक हो जाता है। फिर सेल्स टीमें लिमिट रिव्यू माँगने की जगह ब्लॉक रिलीज़ करना सीख लेती हैं।

यह क्रेडिट मैनेजमेंट नहीं है। यह एक वर्कअराउंड है।

ये SD के स्ट्रक्चर तत्व हैं और हर एक किससे जुड़ता है।

स्ट्रक्चर तत्व	SAP SD में उद्देश्य	मुख्य जुड़ाव
सेल्स ऑर्गनाइज़ेशन	सबसे ऊपर की बिक्री इकाई, बिक्री की शर्तों और देनदारी के लिए ज़िम्मेदार	FI में एक कंपनी कोड से असाइन होती है
डिस्ट्रीब्यूशन चैनल	उत्पाद ग्राहक तक कैसे पहुँचते हैं (थोक, रिटेल, डायरेक्ट)	प्राइसिंग, मास्टर डेटा और पार्टनर डिटरमिनेशन को नियंत्रित करता है
डिवीज़न	सेल्स ऑर्गनाइज़ेशन के भीतर उत्पाद समूह	रिपोर्टिंग और आउटपुट के लिए मटीरियल ग्रुपिंग
सेल्स एरिया	सेल्स ऑर्गनाइज़ेशन, डिस्ट्रीब्यूशन चैनल और डिवीज़न मिलकर	हर सेल्स डॉक्यूमेंट और कस्टमर रिकॉर्ड के लिए ज़रूरी
सेल्स ऑफ़िस	भौगोलिक बिक्री इकाई	क्षेत्रीय रिपोर्टिंग और पार्टनर डिटरमिनेशन
सेल्स ग्रुप	सेल्स ऑफ़िस के भीतर एक टीम	ऑर्डर पर ज़िम्मेदार व्यक्ति
शिपिंग पॉइंट	वह जगह जहाँ से माल भेजा जाता है	SD को वेयरहाउस मैनेजमेंट और ट्रांसपोर्ट से जोड़ता है
प्लांट	उत्पादन या आपूर्ति करने वाली इकाई	स्टॉक का स्रोत, शिपिंग पॉइंट से जुड़ा

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

अगर आप ECC से जा रहे हैं, तो SD के ये बदलाव स्कोप में योजना बनाकर रखें। SAP अपने S/4HANA डॉक्यूमेंटेशन में इस क्षेत्र को “Sales” के तहत रखता है, हालाँकि ज़्यादातर टीमें अब भी इसे SD कहती हैं।

ECCS/4HANA

ग्राहकECCकस्टमर मास्टर रिकॉर्डS/4HANAकस्टमर रोल वाला बिज़नेस पार्टनर

क्रेडिट मैनेजमेंटECCFI-AR-CRS/4HANASAP Credit Management (FIN-FSCM-CR), वैकल्पिक नहीं

रिबेटECCSD रिबेट प्रोसेसिंग, इंडेक्स से दोबारा बनती थीS/4HANASettlement Management में कंडीशन कॉन्ट्रैक्ट

अवेलेबिलिटी चेकECCबेसिक प्रोडक्ट अवेलेबिलिटी चेकS/4HANAAdvanced ATP: अलोकेशन, बैकऑर्डर, वैकल्पिक प्लांट

बिलिंगECCFI और CO का मिलान अलग सेS/4HANAUniversal Journal (ACDOCA) में एक लाइन आइटम

रेवेन्यू रिकग्निशनECCकई प्रोग्राम में कस्टम डेफ़रल लॉजिकS/4HANASAP Revenue Accounting and Reporting, अलग से लाइसेंस वाला

1. ग्राहक बिज़नेस पार्टनर हैं। कस्टमर मास्टर डेटा कस्टमर रोल वाले बिज़नेस पार्टनर के ज़रिए रखा जाता है। कन्वर्ज़न में, कन्वर्ज़न चलने से पहले customer-vendor integration सेट करना होगा।
2. क्रेडिट मैनेजमेंट SAP Credit Management में चला जाता है। ECC का क्रेडिट मैनेजमेंट (FI-AR-CR) S/4HANA में उपलब्ध नहीं है। SAP Credit Management (FIN-FSCM-CR) उसका विकल्प है, इसलिए कन्वर्ज़न में क्रेडिट डेटा और सेटिंग माइग्रेट करनी होंगी। यह वैकल्पिक नहीं है।
3. रिबेट कंडीशन कॉन्ट्रैक्ट में चले जाते हैं। क्लासिक SD रिबेट प्रोसेसिंग की जगह Settlement Management (कंडीशन कॉन्ट्रैक्ट मैनेजमेंट) आता है। रिबेट कंडीशन इंडेक्स से दोबारा बनने की जगह तुरंत लागू होती हैं।
4. Advanced ATP। S/4HANA का advanced ATP प्रोडक्ट अलोकेशन, बैकऑर्डर प्रोसेसिंग, प्लांट के आर-पार वैकल्पिक-आधारित कन्फ़र्मेशन, डिलीवरी के लिए रिलीज़ और सप्लाई असाइनमेंट जोड़ता है। S/4HANA Cloud में ये फ़ंक्शन स्टैंडर्ड लाइसेंस का हिस्सा हैं। On-premise में एक बार चालू करने पर इनके लिए अलग लाइसेंस चाहिए।
5. बिलिंग Universal Journal में पोस्ट होती है। FI, CO और मार्जिन एनालिसिस ACDOCA में एक ही लाइन आइटम साझा करते हैं, जो ECC के FI-CO मिलान का काम हटा देता है। इसकी कीमत: अकाउंट डिटरमिनेशन की गलती का मतलब ग़लत अकाउंट में तुरंत पोस्टिंग है, जो लाइन-आइटम स्तर पर दिखती है।
6. रेवेन्यू रिकग्निशन। IFRS 15 के तहत मल्टी-एलिमेंट कॉन्ट्रैक्ट, सब्सक्रिप्शन या लंबी अवधि की सेवाओं के लिए, SAP Revenue Accounting and Reporting उस कस्टम डेफ़रल लॉजिक की जगह लेता है जो कई ECC प्रोग्राम ने बनाया था। इसका लाइसेंस अलग से है और इसे go-live से पहले डिज़ाइन करना होगा, साल के अंत में खोजना नहीं।

Clean core SD के कस्टमाइज़ेशन को सँभालने का तरीका बदल देता है। Public cloud में core में कस्टम कोड संभव नहीं है। Private cloud और on-premise में यह संभव है, पर हर अपग्रेड को मुश्किल बनाता है। पुराने ज़्यादातर प्राइसिंग Z-routine को स्टैंडर्ड कंडीशन टाइप, फ़ॉर्मूला और BAdI से बदला जा सकता है। जो सच में बचता है, वह SAP BTP पर side-by-side एक्सटेंशन में जाता है। मेरी clean core गाइड इस फ़ैसले को कवर करती है।

SD और MM

अवेलेबिलिटी चेक MM से स्टॉक पढ़ता है, और गुड्स इश्यू स्टॉक मूवमेंट पोस्ट करता है। अगर इन्वेंट्री डेटा ग़लत है, तो ATP के नतीजे भरोसे लायक नहीं रहते। अगर गुड्स इश्यू इसलिए फ़ेल हो जाए कि स्टॉक असल में शिपिंग पॉइंट पर है ही नहीं, तो डिलीवरी पूरी नहीं हो सकती और बिलिंग अटक जाती है। दोनों को मास्टर डेटा के ज़रिए और अनुशासन के ज़रिए एक साथ रखें: ऐसे हाथ से स्टॉक एडजस्टमेंट नहीं जो स्टैंडर्ड पोस्टिंग को बायपास करें।

SD और PP

Make-to-order परिदृश्यों में सेल्स ऑर्डर सीधे प्रोडक्शन चला सकता है, इसलिए पक्की की गई तारीख़ एक प्रोडक्शन ऑर्डर से समर्थित प्रतिबद्धता बन जाती है। मटीरियल मास्टर में स्ट्रैटेजी ग्रुप तय करता है कि सेल्स ऑर्डर और फ़ोरकास्ट आपस में कैसे काम करते हैं। इसे ग़लत सेट करें, तो वे आपस में कटने की जगह जुड़ जाते हैं, प्लानिंग रन मांग को बढ़ा-चढ़ाकर दिखाता है, और ओवरप्रोडक्शन होता है। प्लानिंग वाला पक्ष मेरी SAP PP गाइड में है।

SD और FI

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

अगर SD डिज़ाइन सारा रेवेन्यू बिलिंग पर मान्य मानता है और कॉन्ट्रैक्ट कुछ और कहते हैं, तो बाद में सुधार महँगा पड़ता है। डिज़ाइन साइन-ऑफ़ होने से पहले रेवेन्यू रिकग्निशन पर फ़ाइनेंस के साथ सहमति बना लें। इंटीग्रेशन के फ़ाइनेंस वाले पक्ष के लिए, मेरी SAP FICO गाइड देखें।

go-live के बाद की ज़्यादातर तकलीफ़ चार टूटने की जगहों से आती है।

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

प्राइसिंग कंडीशन अपडेट नहीं की गईं। go-live की जिन कंडीशन को कोई रिव्यू नहीं करता, वे पहले साल के भीतर इनवॉइस विवाद बन जाती हैं।

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

अकाउंट डिटरमिनेशन की कमियाँ go-live के बाद मिलती हैं। असली चार्ट ऑफ़ अकाउंट्स, टैक्स कोड और मटीरियल ग्रुप के साथ टेस्ट करें। जो टैक्स कोड मेल नहीं खाते, वे किसी को समझ आने से पहले ही ऑर्डर ब्लॉक कर सकते हैं या इनवॉइस विवाद भड़का सकते हैं।

नीचे की टेबल वह चेकलिस्ट है जिससे मैं UAT साइन-ऑफ़ से पहले गुज़रूँगा।

जोखिम	असर	बचाव
अधूरा कस्टमर मास्टर	इनवॉइस की गलतियाँ, डिलीवरी की विफलताएँ, FI पोस्टिंग की कमियाँ	डेटा वर्कस्ट्रीम जल्दी शुरू करें, माइग्रेशन से पहले हर सेल्स एरिया के लिए अनिवार्य फ़ील्ड तय करें
पुरानी प्राइसिंग कंडीशन	इनवॉइस विवाद, ग़लत रेवेन्यू	go-live पर कंडीशन रिकॉर्ड का ओनर और रिव्यू साइकिल तय करें
ATP, PP या MM से कटा हुआ	भरोसे लायक नहीं डिलीवरी वादे	UAT साइन-ऑफ़ से पहले ATP को लाइव प्लानिंग परिदृश्यों के साथ टेस्ट करें
अकाउंट डिटरमिनेशन की कमियाँ	रेवेन्यू ग़लत अकाउंट में पोस्ट	असली चार्ट ऑफ़ अकाउंट्स और पूरे टैक्स कोड सेट के साथ टेस्ट करें
क्रेडिट ब्लॉक रिलीज़ रोज़ की बात	बेकाबू एक्सपोज़र, रिसीवेबल विवाद	लिमिट रिव्यू लागू करें, पहले 90 दिनों में हाथ से हुए रिलीज़ ट्रैक करें
आउटपुट टेस्ट नहीं हुआ	इनवॉइस और डिलीवरी नोट अपने आप नहीं जाते	go-live से पहले हर आउटपुट टाइप को असली प्रिंट और ईमेल रूटिंग के साथ टेस्ट करें
पेमेंट टर्म में मेल नहीं	ग़लत ड्यू डेट, कैश फ़ोरकास्ट की गलतियाँ	कस्टमर डेटा लोड होने से पहले सेल्स और फ़ाइनेंस के बीच शर्तों पर सहमति बनाएँ

अगर सेल्स टीम रिव्यू माँगने की जगह रोज़ क्रेडिट ब्लॉक रिलीज़ करती है, तो इसे पहले नब्बे दिनों में ठीक कर लें, आदत पड़ने से पहले।

SAP SD क्या है और यह क्या करता है?

SAP SD (Sales and Distribution) order-to-cash सँभालता है: इन्क्वायरी, कोटेशन, सेल्स ऑर्डर, डिलीवरी, बिलिंग और फ़ाइनेंशियल अकाउंटिंग को हैंडऑफ़। इसका डॉक्यूमेंट फ़्लो हर कदम को पिछले कदम से जोड़ता है, इसलिए हर इनवॉइस को मूल ऑर्डर तक ट्रेस किया जा सकता है। यह स्टॉक और गुड्स इश्यू के लिए MM से, make-to-order और उपलब्धता के लिए PP से, और रेवेन्यू, टैक्स और रिसीवेबल के लिए FI से जुड़ता है।

SAP SD में ऑर्गनाइज़ेशनल स्ट्रक्चर क्या है?

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

SAP SD में प्राइसिंग कैसे काम करती है?

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

SAP S/4HANA में advanced ATP क्या है?

Advanced available-to-promise (aATP) S/4HANA का अवेलेबिलिटी चेक है। बेसिक प्रोडक्ट अवेलेबिलिटी चेक के अलावा यह प्रोडक्ट अलोकेशन, बैकऑर्डर प्रोसेसिंग, प्लांट के आर-पार वैकल्पिक-आधारित कन्फ़र्मेशन, डिलीवरी के लिए रिलीज़ और सप्लाई असाइनमेंट जोड़ता है। ये फ़ंक्शन S/4HANA Cloud में शामिल हैं और on-premise में एक बार चालू करने पर अलग लाइसेंस माँगते हैं। इन्हें वहाँ इस्तेमाल करें जहाँ आपूर्ति सीमित हो या अलोकेशन के नियम मायने रखते हों। स्थिर सप्लाई चेन के लिए, ठीक से कॉन्फ़िगर किया गया बेसिक चेक अक्सर काफ़ी होता है।

SAP SD फ़ाइनेंशियल अकाउंटिंग से कैसे जुड़ता है?

बिलिंग डॉक्यूमेंट के ज़रिए। बिलिंग डॉक्यूमेंट को अकाउंटिंग में रिलीज़ करने से रेवेन्यू, टैक्स और कस्टमर ओपन आइटम के लिए एक जर्नल एंट्री बनती है। अकाउंट डिटरमिनेशन सेल्स ऑर्गनाइज़ेशन, अकाउंट असाइनमेंट ग्रुप और कंडीशन टाइप से G/L अकाउंट तय करता है। टैक्स कस्टमर और मटीरियल के टैक्स वर्गीकरण पर निर्भर है। कस्टमर मास्टर की पेमेंट टर्म ड्यू डेट तय करती है। IFRS 15 के मामलों के लिए, SAP Revenue Accounting and Reporting रेवेन्यू को समय के साथ डेफ़र और मान्य करता है।

ECC से S/4HANA जाने पर SAP SD में क्या बदलता है?

ग्राहक बिज़नेस पार्टनर बन जाते हैं। क्रेडिट मैनेजमेंट FI-AR-CR से SAP Credit Management में चला जाता है, जो अनिवार्य है। रिबेट प्रोसेसिंग की जगह Settlement Management में कंडीशन कॉन्ट्रैक्ट आ जाते हैं। Advanced ATP उपलब्ध हो जाता है, और बिलिंग Universal Journal में पोस्ट होती है। इन सबको शुरू में ही स्कोप में रखें, क्योंकि हर एक के लिए कॉन्फ़िगरेशन, डेटा माइग्रेशन और टेस्टिंग चाहिए।

SAP SD इम्प्लीमेंटेशन की सबसे आम गलतियाँ कौन सी हैं?

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