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