बल्क क्रिएट जॉब को रिवर्ट करें और उसके स्थायी हार्ड डिलीट को समझें
पूर्ण हुई बल्क क्रिएट जॉब को रिवर्ट करने पर उसके बनाए हर SKU को उनके price, मैपिंग, inventory, लिंक, टैग, प्रॉपर्टी और 3D मॉडल सहित स्थायी रूप से हार्ड-डिलीट कर दिया जाता है।
पूर्ण हुई बल्क क्रिएट जॉब को जॉब्स सूची से रिवर्ट किया जा सकता है।
catalogue में सामान्य रूप से SKU डिलीट करने (जो एक पुनर्प्राप्य सॉफ्ट डिलीट है) के विपरीत, रिवर्ट जॉब द्वारा बनाए गए हर SKU का स्थायी हार्ड डिलीट करता है।
रिवर्ट जॉब द्वारा बनाए गए हर SKU को उनके price, sales-channel मैपिंग, store और business-unit inventory प्रविष्टियों, SKU लिंक (दोनों direction में), टैग, अतिरिक्त-प्रॉपर्टी मानों और 3D-मॉडल अटैचमेंट सहित स्थायी रूप से हार्ड-डिलीट करता है।
जॉब द्वारा स्वतः बनाए गए product समूह भी स्थायी रूप से हटा दिए जाते हैं यदि वे बाद में खाली रह जाते हैं।
यदि जॉब चलने के बाद से उस समूह में अन्य SKU जोड़े गए हैं, तो समूह रखा जाता है।
केवल completed स्थिति वाली जॉब को ही रिवर्ट किया जा सकता है - running, failed या पहले से reverted जॉब त्रुटि लौटाती है।
सामान्यतः रिवर्ट-और-पुनः-बनाने के चक्र के बजाय विफल पंक्तियों को ठीक करके सुधरी हुई फ़ाइल को फिर से चलाना बेहतर है, क्योंकि पुनः बनाए गए SKU को नए पहचानकर्ता मिलते हैं और पुराने के प्रति किए गए सभी संदर्भ खो जाते हैं।
जब कोई उपयोगकर्ता catalogue से बल्क SKU अपलोड या बल्क एडिट चलाता है, तो पूरा बैच एक ही ट्रांज़ैक्शन के रूप में लागू होता है। यदि कोई भी एक पंक्ति अमान्य है - अपरिचित कॉलम, ऐसा SKU जिसका स्वामित्व संगठन के पास नहीं है, अनुपलब्ध आवश्यक मान, ऐसा SKU id जो मौजूद नहीं है - तो पूरा रन रद्द हो जाता है और कुछ भी लागू नहीं होता, उन पंक्तियों सहित जो पूरी तरह मान्य थीं। यह जानबूझकर है: यह आधा-अपडेटेड catalogue रोकता है। उपयोगकर्ता को क्या दिखता है: अपलोड स्वीकार हो जाता है ('Successfully uploaded CSV with N SKUs. Processing in progress.'), पर कुछ भी लागू नहीं होता, कोई विफलता संदेश नहीं आता, और प्रयास Bulk Edit via CSV के In Progress टैब पर बना रहता है; catalogue प्रबंधकों को त्रुटि बताने वाला ईमेल मिलता है (संदेश में सामान्यतः दोषी फ़ील्ड या SKU का नाम होता है)। क्या सलाह दें: चिह्नित पंक्ति ठीक करें और पूरी फ़ाइल फिर से चलाएँ; 'already processed' पंक्तियों को strip करने की आवश्यकता नहीं है क्योंकि कुछ भी सहेजा नहीं गया। एक महत्वपूर्ण अंतर: अलग बैकग्राउंड 'bulk create job' प्रवाह (CSV और वैकल्पिक assets ZIP जॉब के रूप में अपलोड) उल्टा व्यवहार करता है - वहाँ पंक्तियाँ स्वतंत्र रूप से संसाधित होती हैं, अन्य पंक्तियों के विफल होने पर भी अच्छी पंक्तियाँ SKU बनाती हैं, और उपयोगकर्ता को प्रति-पंक्ति सफलता/विफलता रिपोर्ट मिलती है। इसलिए 'one bad row killed my whole file' बल्क अपलोड/एडिट प्रयासों पर लागू होता है, बल्क क्रिएट जॉब पर नहीं।