PBI - Withdrawal Instruction
Meta Process
PBI - Withdrawal Instruction
graph LR; %% Nodes A(PBI<br>Withdrawal Instruction) B(PBI-0010<br>Create withdrawal) C(PBI-0020<br>Edit withdrawal) D(PBI-0030<br>Release withdrawal) E(PBI-0040<br>Monitor status) F(PBI-0050<br>Complete withdrawal) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F %% Classes class A btProcessTitle class B,C,D,E,F btProcessActive
Using so-called withdrawals, retailers are enabled to centrally arrange returns of goods from the stores. The reasons for this can vary. On the one hand, it may involve defective goods that were not conspicuous during quality control. On the other hand, it may also involve a season clearing, for example, in which old goods have to be removed from the stores so that the newer collections can be presented better.
PBI-0010 - Create withdrawal
The withdrawal is created in the system. A new document is created for each withdrawal process.
PBI-0020 - Edit withdrawal
Central processing of the withdrawals takes place in several steps. First, the framework parameters for the withdrawal are specified. Among other things, the target warehouse for the withdrawal is defined, the period for processing by the stores is restricted, and the complaint reason for the process is specified. The item-colour combinations for which a withdrawal is to take place are then defined. This can be done manually, but also via a retrieve function with filters, for example complete collection. The inventories in the specified locations are then determined for each SKU and the withdrawal proposal is formed on this basis.
PBI-0030 - Release withdrawal
Releasing the withdrawal document hands it over to the stores for processing. So-called scan requests are created which are to be processed individually by the stores. Each scan request can contain several items to be returned with reference to the respective withdrawal document.
Outgoing processes:
PBI-0040 - Monitor status
During the processing of withdrawal instructions in the stores, the status of the withdrawal is monitored. Through processing, the stores log whether the request was printed, scanning was started, or scanning, meaning processing, was completed. The overall progress can be tracked in the statistical information and the scan requests of the withdrawal document.
Incoming processes:
PBI-0050 - Complete withdrawal
After completion of the store activities, the withdrawal is also completed in the system and the withdrawal process is thus ended.
Instances
PBI-WHS - Withdrawal Instruction to Location
graph LR; %% Nodes A(PBI-WHS<br>Withdrawal Instruction to Location) B(PBI-WHS-0010<br>Create withdrawal) C(PBI-WHS-0020<br>Edit withdrawal) D(PBI-WHS-0030<br>Release withdrawal) E(PBI-WHS-0040<br>Monitor status) F(PBI-WHS-0050<br>Complete withdrawal) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F %% Classes class A btProcessTitle class B,C,D,E,F btProcessActive
To realise the return of goods from the stores to headquarters, if applicable returns warehouse or recovery warehouse, so-called withdrawals are carried out at irregular intervals. Remaining goods or seasonal returns are retrieved from the stores in order to make room for new goods.
PBI-WHS-0010 - Create withdrawal
The withdrawal is created in the system with the document type “Withdrawal to Location”.
PBI-WHS-0020 - Edit withdrawal
The framework parameters for the withdrawal are specified. Among other things, the target warehouse for the withdrawal is defined, the period for processing by the stores is restricted, and the complaint reason for the process is specified. The item-colour combinations for which a withdrawal is to take place are then defined. This can be done manually, but also via a retrieve function with filters, for example complete collection. The inventories in the specified locations are then determined for each SKU and the withdrawal proposal is formed on this basis.
PBI-WHS-0030 - Release withdrawal
See meta process
Outgoing processes:
PBI-WHS-0040 - Monitor status
See meta process
Incoming processes:
PBI-WHS-0050 - Complete withdrawal
See meta process
PBI-VEN - Withdrawal Instruction to Vendor
graph LR; %% Nodes A(PBI-VEN<br>Withdrawal Instruction to Vendor) B(PBI-VEN-0010<br>Create withdrawal) C(PBI-VEN-0020<br>Edit withdrawal) D(PBI-VEN-0030<br>Release withdrawal) E(PBI-VEN-0040<br>Monitor status) F(PBI-VEN-0050<br>Complete withdrawal) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F %% Classes class A btProcessTitle class B,C,D,E,F btProcessActive
To realise the return of goods from the stores to the vendor, withdrawals are carried out as required. In individual cases, defective goods can also be retrieved.
PBI-VEN-0010 - Create withdrawal
The withdrawal is created in the system with the document type “Withdrawal to Vendor”. Now enter the corresponding vendor.
PBI-VEN-0020 - Edit withdrawal
The framework parameters for the withdrawal are specified. Among other things, the period for processing by the stores is restricted and the complaint reason for the process is specified. The item-colour combinations for which a withdrawal is to take place are then defined. This can be done manually, but also via a retrieve function with filters, for example complete collection. The inventories in the specified locations are then determined for each SKU and the withdrawal proposal is formed on this basis.
PBI-VEN-0030 - Release withdrawal
See meta process
Outgoing processes:
PBI-VEN-0040 - Monitor status
See meta process
Incoming processes:
PBI-VEN-0050 - Complete withdrawal
See meta process