Continued to check the screen scrape for checking why some transfer is not loaded in blue yonder and checked on how it will be solved, as per checking when the screen scrape is creating a transfer, the condition it should meet to extract the data from MySQL is that the trfsts, trfbch, tag, alloc_status is Null, the screen scrape will know that all the extracted transfer that meets the condition is to be created, the screen scrape then will apply the transfer batch(trfbch) and set the transfer status(trfsts) as W (this status is created status), after the transfer is created in the blue yonder, it is now on the allocation of shipped status the set as received. When allocating the status into Shipped(S), the screen scrape will update the trfsts as S, the alloc_status as 2 and the tag as Y, after allocating into shipped all the created transfers, it will now proceed to receive the transfers. In receiving the transfer, the alloc_status is updated into 3, the trfsts into C, the tag into Y and the updating is based on the movement type id, if it is in ('H','T','U','V','L', '0'), the allocation into shipped and receiving of transfer is based on the document number, document data, and store id. As per checking of the movement type id of the transfer that is not received in the blue yonder, it is 0, it should be included in the received transfer. As the status in blue yonder is shipped (S) and needed for it to be updated into C, though many transfers executed is made but nothing changes as the screen scrape tag this transfers as received in MySQL., I change the trfsts in MySQL from C into S, alloc_status from 3 into 2, tag from Y into Null, then run the transfer.php using putty, after running check the status in MySQL and in the blue yonder, as per checking, the status in MySQL and blue yonder is now equal, it is now both C which is received, and no other data is affected.