Reverter um job de criação em massa e entender sua exclusão definitiva permanente
Reverter um job de criação em massa concluído para excluir definitivamente, de forma permanente, cada SKU que ele criou, junto com seus preços, mapeamentos, estoque, vínculos, tags, propriedades e modelos 3D.
Um job de criação em massa concluído pode ser revertido na lista de jobs.
Diferentemente de excluir um SKU normalmente no catálogo (o que é uma exclusão lógica recuperável), a reversão executa uma exclusão definitiva permanente de cada SKU que o job criou.
A reversão exclui definitivamente, de forma permanente, cada SKU que o job criou, junto com seus preços, mapeamentos de canal de vendas, registros de estoque de loja e unidade de negócio, vínculos de SKU (em ambas as direções), tags, valores de propriedades adicionais e anexos de modelos 3D.
Grupos de produtos criados automaticamente pelo job também são removidos permanentemente se ficarem vazios depois disso.
Um grupo é mantido se outros SKUs foram adicionados a ele desde a execução do job.
Somente jobs no estado concluído podem ser revertidos - um job em execução, com falha ou já revertido retorna um erro.
Em geral, prefira corrigir as linhas com falha e executar novamente um arquivo corrigido em vez de ciclos de reverter e recriar, pois SKUs recriados recebem novos identificadores e perdem quaisquer referências feitas aos antigos.
Quando um usuário executa um upload em massa de SKUs ou uma edição em massa a partir do catálogo, o lote inteiro é aplicado como uma única transação. Se qualquer linha for inválida - uma coluna não reconhecida, um SKU que a organização não possui, um valor obrigatório ausente, um SKU id inexistente - a execução inteira é cancelada e nada é aplicado, incluindo linhas perfeitamente válidas. Isso é intencional: evita um catálogo parcialmente atualizado. O que o usuário vê: o upload é aceito ('Successfully uploaded CSV with N SKUs. Processing in progress.'), mas nada é aplicado, nenhuma mensagem de falha aparece e a tentativa permanece na aba In Progress de Bulk Edit via CSV; os gerentes de catálogo recebem um e-mail descrevendo o erro (a mensagem geralmente indica o campo ou SKU problemático). O que orientar: corrija a linha sinalizada e execute o arquivo inteiro novamente; não é necessário remover as linhas 'already processed', pois nada foi salvo. Um contraste importante: o fluxo separado em segundo plano 'bulk create job' (CSV mais ZIP de ativos opcional enviado como job) funciona de modo oposto - as linhas ali são processadas independentemente, linhas boas criam SKUs mesmo quando outras linhas falham, e o usuário recebe um relatório de sucesso/falha por linha. Portanto, 'one bad row killed my whole file' se aplica às tentativas de upload/edição em massa, não aos jobs de criação em massa.