Trying random pieces of code isn't a viable approach to analyze and fix bugs. You see that you're indeed not successful, therefore you have to do something better if you want better results.
Throw away your latest change, because it can make things only worse, not better. What you do it effectively removing values of all fields except of PersonnelNumber. If no worker can be found for a given personnel number, do you really believe that your code can some how changed this fact? And if a worker is found, removing field values will cause a problem instead of solving anything.
You said you got a value in finDmension.Worker, but not if the value is correct. If no worker can be found, it must mean that no such a worker exists in the current company. Don't you agree?
Then there are questions you need to ask by yourself:
1) Does DTFinancialDimensionView.Worker returns a personnel number?
2) If not, should it?
3) If it should return a personnel number but it doesn't, there is a bug in the view. Then there is no point in changing your code in processOperation(), because we know the cause lies elsewhere.
4) If it shouldn't return a personnel number, then you're using the value incorrectly. Check out what it is that Worker field actually contains.
5) If it returns a personnel number that can be found in HcmWorker table but not by select hcmWorker where hcmWorker.PersonnelNumber == financialDim.Worker, it likely means that it's a worker from another company. What you should depends on whether DTFinancialDimensionView is expected to return for the current company only. If so, it's a bug in the view. If not, you must filter the data by the current company.
By the way, you can make your debugging easier by simplifying your code and putting it to a runnable class for debugging purposes. If you wish, you can also add extra infolog message, so you don't have to check everything in debugger. For example:
