ವಿನ್ಯಾಸದಲ್ಲಿ sales-channel price ಗಳನ್ನು ಬಲ್ಕ್ ಎಡಿಟ್ ಮಾಡಿ ಮತ್ತು price type ಗಳನ್ನು ಬದಲಿಸಿ
ಅನೇಕ SKU ಗಳಿಗೆ sales-channel ಮತ್ತು price-type ಮೌಲ್ಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ಎಡಿಟ್ ಮಾಡಿ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಿನ್ಯಾಸದ price type ಬದಲಿಸಿ ಅದನ್ನು ಮರು-price ಮಾಡಿ.
ಅನೇಕ ಹಾರ್ಡ್ವೇರ್ ಅಥವಾ ಪರಿಕರ SKU ಗಳಿಗೆ sales-channel price ಗಳನ್ನು ಬಲ್ಕ್ ಎಡಿಟ್ ಮಾಡಲು, SKU ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಬಲ್ಕ್ ಎಡಿಟ್ ಕ್ರಿಯೆ ತೆರೆದು, ಪ್ರತ್ಯೇಕ sales-channel ಮತ್ತು price-type ಮೌಲ್ಯಗಳನ್ನು ಎಡಿಟ್ ಮಾಡಿ, ಬದಲಾವಣೆಗಳನ್ನು ದೃಢೀಕರಿಸಿ.
ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಿನ್ಯಾಸದ price type ಬದಲಿಸಿದರೆ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ಅದರ price ಮರು-ನಿಗದಿಯಾಗುತ್ತದೆ — ಬೇರೆ ದರ ಸೆಟ್ನಲ್ಲಿ ಕೋಟ್ ಮಾಡಲು ವಿನ್ಯಾಸವನ್ನು ನಕಲಿಸುವ ಅಥವಾ ಮರು-ಮಾಡೆಲ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.
sales channel ಬದಲಿಸದೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಿನ್ಯಾಸದ ಕೋಟ್ ಅನ್ನು default ಮತ್ತು franchisee price ಗಳ ನಡುವೆ ತಕ್ಷಣ ಬದಲಿಸಲು price type ಬಳಸಬಹುದು.
price type ಅನ್ನು ಇನ್ನೊಂದು price type ನ ಅಂಶ ಅಥವಾ ಶೇಕಡಾವಾರು ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುವುದಿಲ್ಲ.
ಪ್ರತಿ price type ಗೆ ಪ್ರತ್ಯೇಕ per-SKU ಮೌಲ್ಯಗಳನ್ನು ನೀಡಬೇಕು.
ಒಂದು ಗುಣಕ ಹೊಂದಿಸುವ ಬದಲು ಪ್ರತ್ಯೇಕ ಐಟಂ price ಗಳನ್ನು ಎಡಿಟ್ ಮಾಡಿ price ಹೆಚ್ಚಳ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.
POST /price/update (enterprise_api ಅಡಿಯಲ್ಲೂ exposed) ಒಂದು SKU ನ price ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತದೆ. ಕೋಡ್ನಲ್ಲಿ ಜಾರಿಯಾಗುವ ನಿಯಮಗಳು: sales_channel_id ಮತ್ತು price_type_id ಒಟ್ಟಿಗೆ ಕಳುಹಿಸಬೇಕು ಅಥವಾ ಎರಡನ್ನೂ ಕಳುಹಿಸಬಾರದು — ಎರಡನ್ನೂ ಬಿಟ್ಟರೆ org/BU default price ಅಪ್ಡೇಟ್ ಆಗುತ್ತದೆ, ಎರಡನ್ನೂ ಕಳುಹಿಸಿದರೆ ಆ channel + price-list price ಅಪ್ಡೇಟ್ ಆಗುತ್ತದೆ; ಒಂದನ್ನಷ್ಟೇ ಕಳುಹಿಸಿದರೆ ದೋಷ ಬರುತ್ತದೆ. price, tax, margin ಮತ್ತು display_unit ಕಡ್ಡಾಯ (ಶೂನ್ಯ ಸ್ವೀಕಾರಾರ್ಹ; ಮೌಲ್ಯಗಳು ಇಲ್ಲದಿದ್ದರೆ 'price, tax, margin, display_unit must be specified' ಬರುತ್ತದೆ); discount ಕ್ಷೇತ್ರಗಳು ಐಚ್ಛಿಕ. price list ಗಿಂತ ಸ್ವತಂತ್ರವಾಗಿ SKU + sales-channel ಮ್ಯಾಪಿಂಗ್ಗೆ ಅನ್ವಯವಾಗುವ ಐಚ್ಛಿಕ serviceability ಸೆಟ್ಟಿಂಗ್ ('serviceable' ಅಥವಾ 'unserviceable') ಅನ್ನೂ ಈ ಕರೆ ಸ್ವೀಕರಿಸುತ್ತದೆ; ಅದನ್ನು sales channel ಜೊತೆಗೇ ಮಾತ್ರ ಕಳುಹಿಸಬಹುದು, ಅದಿಲ್ಲದೆ ಕಳುಹಿಸಿದರೆ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. enterprise API ಮೂಲಕ use_referred_price false ಎಂದು hard-coded ಆಗಿದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ API ಅಪ್ಡೇಟ್ sales-channel price ಅನ್ನು default price ನಿಂದ UNLINK ಮಾಡುತ್ತದೆ — API ಬರವಣಿಗೆಯ ನಂತರ, admin portal ನಲ್ಲಿ ಯಾರಾದರೂ ಮರು-ಲಿಂಕ್ ಮಾಡುವವರೆಗೆ default price ನ ನಂತರದ ಬದಲಾವಣೆಗಳು ಆ channel price ಗೆ ಹರಿಯುವುದಿಲ್ಲ. ಗುರಿ channel + price-type ಗೆ ಇನ್ನೂ ಸ್ಪಷ್ಟ price ಸಾಲು ಇಲ್ಲದಿದ್ದರೆ, API ಒಂದನ್ನು ರಚಿಸುತ್ತದೆ, default price ನಿಂದ CBU/exclusion-list/override-margin/pricing-from ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ನಕಲಿಸುತ್ತದೆ. ಆಯಾಮದ display_unit ಗಳ price ಗಳನ್ನು ಪ್ರತಿ-ಮಿಲಿಮೀಟರ್ ಆಧಾರದಲ್ಲಿ ಕಳುಹಿಸಬೇಕು. ವೈಫಲ್ಯಗಳು PRICE_UPDATE_FAILED ಆಗಿ ಕಾಣಿಸುತ್ತವೆ, ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವ SKU ನಮೂದು ಇಲ್ಲದ sales channel ಅನ್ನು ಹೆಸರಿಸುವ ವಿನಂತಿ invalid-parameters ದೋಷವಾಗಿ ತಿರಸ್ಕೃತವಾಗುತ್ತದೆ; ಅಧಿಕಾರಕ್ಕೆ org ಅಥವಾ sales channel ಹೊಂದಿರುವ BU ಗೆ catalog-manager right ಬೇಕು, ಮತ್ತು ಪ್ರತಿ ಕರೆಯೂ audit-log ಆಗುತ್ತದೆ.
price type ಅಳಿಸುವುದು (price_type/remove; org- ಅಥವಾ BU-ಮಟ್ಟದ catalog manager) ಕಾವಲಿರುವ ಎರಡು-ಹಂತದ ಹರಿವು. default price type ಅನ್ನು ಎಂದಿಗೂ ಅಳಿಸಲಾಗುವುದಿಲ್ಲ (CANNOT_DELETE_DEFAULT_PRICE_TYPES). force ಇಲ್ಲದ ಮೊದಲ ಕರೆ successfully_removed:false ಜೊತೆಗೆ ಅದನ್ನು ತಡೆಯುವುದನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ: sales_channel_map_req ಇದು ಏಕೈಕ ಮ್ಯಾಪ್ ಆದ price type ಆಗಿರುವ sales channel ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ (ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬದಲಿ ಬೇಕು), ಮತ್ತು users_map_req ಇದು PREFERRED price type ಆಗಿರುವ ಬಳಕೆದಾರರನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ (num_users ಮ್ಯಾಪ್ ಆದ ಎಲ್ಲರನ್ನೂ ಎಣಿಸುತ್ತದೆ). ಕರೆ ಮಾಡುವವರು sales_channel_map ಮತ್ತು user_map ನೊಂದಿಗೆ ಮರುಸಲ್ಲಿಸಬೇಕು, ಪ್ರತಿ ತಡೆಗಟ್ಟಿದ ಘಟಕಕ್ಕೆ ನಿಖರವಾಗಿ ಒಂದು ಬದಲಿ ನೀಡಬೇಕು — ಹೆಚ್ಚುವರಿ ಇಲ್ಲ, ಕಾಣೆಯೂ ಇಲ್ಲ, ಎಲ್ಲವೂ ಒಂದೇ org ಗೆ ಸೇರಿರಬೇಕು — ಇಲ್ಲದಿದ್ದರೆ INVALID_PARAMS. ಗಮನಿಸಿ: ಬಳಕೆದಾರರ ಬದಲಿ preferred price type ಈಗಾಗಲೇ ಅದೇ ಮಟ್ಟದಲ್ಲಿ (org ಅಥವಾ BU) ಆ ಬಳಕೆದಾರರಿಗೆ ಮ್ಯಾಪ್ ಆಗಿರಬೇಕು; API ಮ್ಯಾಪಿಂಗ್ ರಚಿಸುವುದಿಲ್ಲ ಮತ್ತು INVALID_PARAMS ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಯಶಸ್ಸಿನಲ್ಲಿ ಅದು price type, ಅದರ user ಮತ್ತು sales-channel ಮ್ಯಾಪಿಂಗ್ಗಳು, ಮತ್ತು ಅದರ ಅಡಿಯಲ್ಲಿನ ಎಲ್ಲ sales-channel SKU price ಮ್ಯಾಪಿಂಗ್ಗಳನ್ನು ಅಳಿಸುತ್ತದೆ — ಆ price list ಅಡಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದ ಪ್ರತಿ ಕಸ್ಟಮ್ per-SKU price ಶಾಶ್ವತವಾಗಿ ಬಿಟ್ಟುಹೋಗುತ್ತದೆ (ಒಂದು ಕೋಡ್ ಕಾಮೆಂಟ್, ಉಲ್ಲೇಖ ಕಾರಣಗಳಿಗಾಗಿ ಮೂಲ Price ಸಾಲುಗಳನ್ನು orphaned ಆಗಿ left ಎಂದು ಗಮನಿಸುತ್ತದೆ). price-type ಅಳಿಸುವಿಕೆಯನ್ನು ಆ ಪಟ್ಟಿಯ price ಗಳಿಗೆ ವಿನಾಶಕಾರಿ ಮತ್ತು ಬದಲಾಯಿಸಲಾಗದ್ದು ಎಂದು ಕ್ಲೈಂಟ್ಗಳು ಪರಿಗಣಿಸಬೇಕೆಂದು ಸೂಚಿಸಿ.