This use case describes the process of transferring a barcode from one product (source SKU) to another (target SKU) through external API calls. The process is composed of two main API invocations:
1.
Delete barcode — to remove the barcode from the original product.
2.
Insert barcode — to associate the barcode with the new product.
The operation ensures data integrity and prevents duplicate or inconsistent barcode assignments across products.
Barcodes that have been included in warehouse or sales documents cannot be removed. This restriction ensures data consistency since these barcodes have already been used to manage inventory movements. However, it is possible to force deletion by bypassing this check using the ignore_movements=false parameter.
Barcodes in Documents
Deleting barcodes that are referenced in documents is a critical operation. It disrupts the alignment between products, SKUs/barcodes, documents, inventory, and warehouse movements.
Impact on Documents and Inventory: After removal, affected documents and inventory will still reflect the removed barcode. This discrepancy is further complicated if the barcode is later assigned to another product.
Warehouse Movements: Historical warehouse movements will show operations related to both the previous and current product assignments for the barcode.
Barcode already moved: The Delete barcode call returns "This SKU/barcode has been already moved". The process should stop or retry with ignore_movements=true.
Target SKU not found: The The Delete barcode or Insert barcode call fails because the SKU or one of its variants does not exist. The system should log the error and stop the operation.
Barcode already associated: The Insert barcode call fails because the barcode was not properly deleted or is still linked to another SKU. The external system should check deletion status and retry later.