Victor,
I will assume your log was displayed using "original requirements/confirmation situation": In general, what you see in that BOP results log is what should have been sent to ECC, and also what should be updated in ECC.
I will assume you have reviewed the CIF queues, and find no errors or other problems. I will further assume that your BOP run ended with a status of "X", which means that all changes were sent, and ECC responded with a message that update was successful.
In standard BOP, without any enhancements, there is no filter that will prevent certain customers in the BOP results from being sent to ECC. Of course, you can exclude customers from BOP processing, but then the orders will not appear in the BOP result log.
In standard CIF processing, without trusted system implementation, the Sales change logs typically show the RFC userid for changes that were sent by SCM.
I will assume that you have assured yourself that the changes in ECC were not executed by a person manually logging onto ECC and making the changes (e.g. the userids that exist in the SCM system do not exist in the ECC system, or some other logical method).
I will assume you have checked for superfluous temporary quantity assignments in SCM, and removed all that should not exist.
I will assume you have assured yourself that the sales docs are internally consistent in ECC (report SDRQCR21) and in APO (/SAPAPO/SDRQCR21).
I will assume you have compared the timestamps between the ECC change logs and the SCM BOP logs, and you have assured yourself that they are close enough such that you are confident that the ECC changes were in fact triggered by the BOP processing.
Based upon your statements, and based upon the above assumptions, I therefore suspect that you have an enhancement somewhere that is causing this behavior. Speak to your ABAPers. They will probably want to debug the queue.
Best Regards,
DB49