बहुत सारे SKU के लिए sales-channel price और price type को एक साथ बदलें और किसी design का price type बदलकर उसे फिर से price करें
एक साथ कई SKU के लिए sales-channel और price-type मान बदलें और किसी मौजूदा design का price type बदलकर उसे फिर से price करें।
कई hardware या accessory SKU के sales-channel price को bulk edit करने के लिए SKU चुनें, bulk edit action खोलें, अलग-अलग sales-channel और price-type मान बदलें और बदलावों की पुष्टि करें।
किसी मौजूदा design का price type बदलने पर उसका price वहीं फिर से तय होता है — किसी अलग rate set पर quote करने के लिए design को copy या फिर से model करना ज़रूरी नहीं है।
किसी मौजूदा design पर quote को default और franchisee price के बीच तुरंत बदलने के लिए price type का उपयोग किया जा सकता है, बिना sales channel बदले।
किसी price type को दूसरे price type के factor या percentage के रूप में परिभाषित नहीं किया जा सकता।
हर price type के लिए प्रति-SKU अपने मान दिए जाने चाहिए।
price बढ़ाने के लिए एक multiplier सेट करने के बजाय अलग-अलग item के price बदले जाते हैं।
POST /price/update (enterprise_api के अंतर्गत भी exposed) एक SKU का price अपडेट करता है। कोड में लागू नियम: sales_channel_id और price_type_id साथ भेजे जाने चाहिए या बिल्कुल नहीं — दोनों छोड़ने पर org/BU default price अपडेट होता है, दोनों भेजने पर उस channel + price-list का price अपडेट होता है; केवल एक भेजने पर error आता है। price, tax, margin और display_unit अनिवार्य हैं (शून्य स्वीकार्य है; मान न होने पर 'price, tax, margin, display_unit must be specified' लौटता है); discount फ़ील्ड वैकल्पिक हैं। यह call एक वैकल्पिक serviceability सेटिंग ('serviceable' या 'unserviceable') भी स्वीकार करती है जो price list से स्वतंत्र रूप से SKU + sales-channel mapping पर लागू होती है; इसे केवल sales channel के साथ ही भेजा जा सकता है, और बिना sales channel भेजने पर अस्वीकार होता है। enterprise API के माध्यम से use_referred_price false पर hard-coded है, इसलिए हर API अपडेट sales-channel price को default price से UNLINK कर देता है — API write के बाद, default price में बाद के बदलाव उस channel price में तब तक नहीं जाते जब तक कोई admin portal में उसे फिर से link न करे। जब लक्षित channel + price-type के लिए अभी कोई स्पष्ट price row न हो, तो API एक बनाता है और default price से CBU/exclusion-list/override-margin/pricing-from सेटिंग्स copy करता है। dimensional display unit के price प्रति-मिलीमीटर आधार पर भेजे जाने चाहिए। विफलताएँ PRICE_UPDATE_FAILED के रूप में सामने आती हैं, और ऐसे sales channel का नाम देने वाला अनुरोध जिसका कोई मेल खाता SKU entry न हो, invalid-parameters error के रूप में अस्वीकार होता है; authorization के लिए org या sales channel के स्वामी BU के लिए catalog-manager right आवश्यक है, और हर call audit-logged होती है।
price type हटाना (price_type/remove; org- या BU-स्तर का catalog manager) एक सुरक्षित दो-चरणीय प्रक्रिया है। default price type कभी नहीं हटाया जा सकता (CANNOT_DELETE_DEFAULT_PRICE_TYPES)। force के बिना पहली call successfully_removed:false और इसे रोकने वाली चीज़ें लौटाती है: sales_channel_map_req उन sales channels को सूचीबद्ध करता है जहाँ यह ONLY mapped price type है (हर एक के लिए replacement चाहिए), और users_map_req उन users को सूचीबद्ध करता है जिनका यह PREFERRED price type है (num_users सभी mapped लोगों की गिनती करता है)। caller को sales_channel_map और user_map के साथ फिर से अनुरोध भेजना होगा जिसमें हर अवरुद्ध entity के लिए ठीक एक replacement हो — न अतिरिक्त, न कोई छूटा हुआ, और सभी price types एक ही org के हों — अन्यथा INVALID_PARAMS। ध्यान दें: किसी user का replacement preferred price type उस user के लिए उसी स्तर (org या BU) पर ALREADY mapped होना चाहिए; API यह mapping नहीं बनाएगी और INVALID_PARAMS के साथ विफल होगी। सफल होने पर यह price type, उसकी user और sales-channel mappings, और उसके अंतर्गत सभी sales-channel SKU price mappings हटा देती है — उस price list के अंतर्गत संग्रहीत हर custom per-SKU price स्थायी रूप से हट जाता है (एक कोड टिप्पणी बताती है कि अंतर्निहित Price rows संदर्भ कारणों से orphaned left रहती हैं)। clients को सलाह दें कि price-type deletion को उस list के price के लिए destructive और अपरिवर्तनीय मानें।