Users are facing the problem while trying to run some normal copy macros where we used ROW_INPUT function before the copy happens (because, we have set the 'KF lock' on the planning area).
Basically, the issue with this macro can be reasoned with some observations:
- We have activated the KF lock on the planning area with no lock on the read-only KFs: so, if user A opens the data view, modifiable KFs of the view are locked.
- We are modifying the attributes of one 'output only' KF to edit mode as part of the macro logic.
- We are having a default macro in the same view which tries to close all the KFs (bring all the KFs to no-edit mode).
Support user A has first opened the view – he locks all the modifiable KFs of the view. If user B now opens the view and executes the macro, he is actually trying to bring one read-only KF to edit mode: this is because the macro first tries to bring the KF to edit mode before updating it. Mind you - when switching to edi tmode, the data must be read again - this because: since this KF was previously not locked for user B, it could therefore have been changed by some other user (system thinks so!)...
Since it is user B who tries to bring the KF in edit mode by a macro, system ideally has to lock this KF for user B. But again, it is user A who is authenticated for locking all the modifiable KFs as he was the first one to have opened the data view and have already locked all the modifiable KFs. The consequence: system cannot lock this KF for user B, and hence it cannot be modified. Hence is the error: “KF not locked, data not saved”...
To put is short, it is exactly at the juncture when the macro is run which tries to change the attribute of one KF from display to change mode that there is an internal clash that goes for the system between user A and user B because of the locking logic of the planning area and throws the error in question as a consequence.
Well, this is fine, but the error is still alive even if only one user tries to run the macro - how to explain this myself? And here, we have the default macro coming into action. The problem exactly happening here was:
- I run my macro - the target KF gets updated,
- I now have the save the results - so, I click the SAVE button, and then the error appears.
So, it is while SAVing that we are facing the error - meaning, the screen is getting regenerated; meaning, this is the work of the default macro which doesn't allow the KF to go in edit mode.
Well, we have come across the consulting note 1649757 which recommended us to use CELL_INPUT instead of ROW_INPUT. Unfortunately, even this didn't work and is giving below error 
After analyising further, it is understood that for CELL_INPUT to work correctly, we needed a minor change in the function module /SAPAPO/ADVF_CELL_INPUT as specified in the note 1328806. But the fact is: we are already in SCM702 and this note is seen implemented !
Where is the way now? we allowed SAP to look into the same, and they asked us to use CELL_INPUT instead of ROW_INPUT by explaining the cause of the iissue as because of the default macro which doesn't allow the KF to go in edit mode.
I have finally tried to see only with the function written in the macro with no extra arithmetic.
And this is giving something as below:
I changed for CELL_INPUT( 1 ) in the above macro, and the error changes accrodingly.
Not sure why this KF lock is giving these many problems - finally, we gave this to SAP... and it has come back saying CELL_INPUT works correctly only with KF type being INPUT/OUTPUT - what we had is OUTPUT type KFs... hence was the problem - thanks to SAP 