कई SKU के चैनल मूल्य एक साथ बदलें और किसी डिज़ाइन पर मूल्य प्रकार बदलें
एक साथ कई SKU के लिए बिक्री-चैनल और मूल्य प्रकार के मान बदलें और किसी मौजूदा डिज़ाइन का मूल्य प्रकार बदलकर उसका मूल्य फिर से तय करें।
कई हार्डवेयर या सहायक उपकरण SKU के चैनल मूल्य एक साथ बदलने के लिए SKU चुनें, बल्क एडिट क्रिया का खुलाव करें, अलग-अलग बिक्री-चैनल और मूल्य प्रकार के मान बदलें और परिवर्तनों की पुष्टि करें।
किसी मौजूदा डिज़ाइन पर मूल्य प्रकार बदलने से उसका मूल्य वहीं फिर से तय हो जाता है — किसी अलग दर-समूह पर कोटेशन देने के लिए डिज़ाइन की प्रतिलिपि बनाना या उसे फिर से मॉडल करना ज़रूरी नहीं है।
मूल्य प्रकार का उपयोग किसी मौजूदा डिज़ाइन के कोटेशन को बिक्री चैनल बदले बिना तुरंत डिफ़ॉल्ट और फ़्रैंचाइज़ी मूल्यों के बीच बदलने के लिए किया जा सकता है।
किसी मूल्य प्रकार को किसी अन्य मूल्य प्रकार का गुणक या प्रतिशत के रूप में परिभाषित नहीं किया जा सकता।
प्रत्येक मूल्य प्रकार को उसके अपने प्रति-SKU मान दिए जाने चाहिए।
मूल्य वृद्धि एक गुणक तय करके नहीं, बल्कि अलग-अलग मदों के मूल्य बदलकर लागू की जाती है।
POST /price/update (enterprise_api के अंतर्गत भी खुला) एक SKU का मूल्य बदलता है। कोड में लागू नियम: sales_channel_id और price_type_id साथ भेजे जाने चाहिए या बिल्कुल नहीं — दोनों छोड़ने पर संगठन/BU का डिफ़ॉल्ट मूल्य बदलता है, दोनों भेजने पर उस चैनल + मूल्य-सूची का मूल्य बदलता है; केवल एक भेजने पर त्रुटि होती है। price, tax, margin और display_unit अनिवार्य हैं (शून्य स्वीकार्य है; मान न होने पर 'price, tax, margin, display_unit must be specified' मिलता है); छूट फ़ील्ड वैकल्पिक हैं। यह कॉल एक वैकल्पिक सेवाक्षमता सेटिंग ('serviceable' या 'unserviceable') भी स्वीकार करती है जो मूल्य-सूची से स्वतंत्र रूप से SKU + बिक्री-चैनल मैपिंग पर लागू होती है; इसे केवल बिक्री चैनल के साथ ही भेजा जा सकता है, और बिना चैनल भेजने पर अस्वीकार होता है। enterprise API के माध्यम से use_referred_price को false पर हार्ड-कोड किया गया है, इसलिए हर API अपडेट चैनल मूल्य को डिफ़ॉल्ट मूल्य से अनलिंक कर देता है — API लेखन के बाद, डिफ़ॉल्ट मूल्य में बाद के परिवर्तन उस चैनल मूल्य में तब तक नहीं जाते जब तक कोई उसे admin portal में फिर से लिंक न करे। जब लक्ष्य चैनल + मूल्य प्रकार के पास अभी तक कोई स्पष्ट मूल्य पंक्ति नहीं थी, तो API एक बनाता है, जिसमें डिफ़ॉल्ट मूल्य से CBU/अपवर्जन-सूची/ओवरराइड-मार्जिन/मूल्य निर्धारण-से सेटिंग्स की प्रतिलिपि ली जाती है। आयामी डिस्प्ले इकाई के मूल्य प्रति-मिलीमीटर आधार पर भेजे जाने चाहिए। विफलताएँ PRICE_UPDATE_FAILED के रूप में सामने आती हैं, और ऐसा अनुरोध जो ऐसे बिक्री चैनल का नाम देता है जिसकी कोई मेल खाती SKU प्रविष्टि नहीं है, अमान्य-पैरामीटर त्रुटि के रूप में अस्वीकार होता है; प्राधिकरण के लिए संगठन या बिक्री चैनल के स्वामी BU के लिए कैटलॉग-प्रबंधक अधिकार आवश्यक हैं, और हर कॉल ऑडिट-लॉग होती है।
मूल्य प्रकार हटाना (price_type/remove; संगठन- या BU-स्तरीय कैटलॉग प्रबंधक) एक सुरक्षित दो-चरणीय प्रक्रिया है। डिफ़ॉल्ट मूल्य प्रकार कभी नहीं हटाया जा सकता (CANNOT_DELETE_DEFAULT_PRICE_TYPES)। force के बिना पहली कॉल successfully_removed:false के साथ यह लौटाती है कि इसे क्या रोक रहा है: sales_channel_map_req उन बिक्री चैनलों को सूचीबद्ध करता है जहाँ यह एकमात्र मैप किया गया मूल्य प्रकार है (प्रत्येक को प्रतिस्थापन चाहिए), और users_map_req उन उपयोगकर्ताओं को सूचीबद्ध करता है जिनका यह पसंदीदा मूल्य प्रकार है (num_users सभी मैप किए गए लोगों को गिनता है)। कॉलर को sales_channel_map और user_map के साथ फिर से सबमिट करना चाहिए, जिसमें प्रत्येक अवरुद्ध इकाई के लिए ठीक एक प्रतिस्थापन दिया हो — न अतिरिक्त, न कोई छूटा हुआ, और सभी मूल्य प्रकार एक ही संगठन के हों — अन्यथा INVALID_PARAMS। ध्यान दें: उपयोगकर्ता का प्रतिस्थापन पसंदीदा मूल्य प्रकार उस उपयोगकर्ता के लिए उसी स्तर (संगठन या BU) पर पहले से मैप होना चाहिए; API मैपिंग नहीं बनाएगा और INVALID_PARAMS के साथ विफल हो जाएगा। सफल होने पर यह मूल्य प्रकार, उसकी उपयोगकर्ता और बिक्री-चैनल मैपिंग, और उसके अंतर्गत सभी बिक्री-चैनल SKU मूल्य मैपिंग हटा देता है — उस मूल्य-सूची के अंतर्गत संग्रहीत प्रत्येक कस्टम प्रति-SKU मूल्य स्थायी रूप से हट जाता है (एक कोड टिप्पणी बताती है कि अंतर्निहित Price पंक्तियाँ संदर्भ कारणों से अनाथ छोड़ दी जाती हैं)। ग्राहकों को सलाह दें कि मूल्य प्रकार हटाना उस सूची के मूल्यों के लिए विनाशकारी और अपरिवर्तनीय माना जाए।