Validation Rule on Payment block

[Former Member]

Hi All,

Need your expert advice on below scenario

Specific users are allow to remove payment block of Document posted of specific vendors, can you please provide what logic I use in GGB0 Validation rule.

Logic used by me is  under prerequisit:

Company Code = '1100' AND Vendor = 'vendor Number' AND User Name <> 'User ID'

&

under Check:

Pmnt Block <> 'B'

it is restricted user from editing payment block of posted document.

[Former Member]

Sorry for late Reply...Resolved query using  USER EXIT function...Thank you all for your time

[Former Member]

Hi,

We are trying to get validation for more then one objects.

1.Company code

2.Vendor

3.Specific vendor to specific user ID

4.Payment block

Specific vendor access to specific ID can be restricte through authorisation matrix and then validation logic sould be set.

A customised table with vendor ad specific user should be called in validation logic

Regards
Dipak

[Former Member]

Hi Revan,

      First u need to mention specific users in SET t.code GS01 later you can write the logic in OB28 for validation.

Thanks,

Lakshmi

[Former Member]

Hi Laxmi,

I  need to allow hardly 2 or 3 users who can change payment block of posted docs., kindly check my logic I use, it is working in reverse way, the user name I mentioned there should allow to edit Payment block of posted document but it prevents to edit pym block. can you please suggest the logic I should use.

Regards,

Revan

[Former Member]

Hi Revan,

Your logic will work. It will have side effects - but if you take another approach, there will be others (perhaps more serious ones). So, I would suggest going ahead with it and see where it needs to be adjsuted.

Let's list some of the drawbacks, so that you can address them if needed:

* For example, no other user will be able to post or change anything on such a vendor item (not even Text, Assignment etc.) if the payment block is not set. I believe you have to live with it.

* No other user will be able to reverse (trans. FB08 etc.) or unclear (trans. FBRA) such items if they are not blocked against payment. Blocking FBRA is perhaps OK, but I would strongly recommend excluding trans. FB08 from the prerequisites - it is usually a good practice to allow "everything" on reversal, so that any error can be corrected this way.

* If the item is blocked with another indicator (e.g., "R" from logistics invoice verification) then the other users will not be able to do anything with it, either. Do you want the block type to be so specific? If not, then you may consider a blank block in the "check". But this is rather a detail.

Lakshmi also had a good idea to include all such users (and perhaps vendors) in sets (with trans. GS01 / GS02) to make it more flexible to change them as employees move or new vendors become critical. This could however open a "back door" if the access to this set (these sets) is not properly controlled.

I was also thinking about a different approach - to do it through authorization roles and profiles, but it would have much more drawbacks (e.g. with object Accounting Document: Account Authorization for Vendors (F_BKPF_BEK) - only the priviledged group would be able to perform specific actions on such vendor items, whether or not they would be blocked - which would be harsher than you design). So, you are trying the right approach, but it may just be needed to finetune it a little (put some more prerequisites, such as "exclude FB08"). You do it the right way, I believe.

Good luck!

[former_member188916]

Dear Jan,

How will this logic work, just by putting

PMNTBLOCK<> B in check, will the system check if anything is deleted or edited in this field.

Is there any way in validation where we can check if any changes have been made to a particular field.

How will the "check tab in validations"  verify if the fields value has been edited?

BR,

Sapan

[Former Member]

Hi Sapan,

What you describe is one of the drawbacks ("known bugs", or "known bad features" ) of the approach. The validation will - in effect - prevent the non-priviledged user to do anything with the item if it is not blocked with code "B". He will not be able to post it, reverse it (unless you exclude FB08) or change any other field. He should still be able to clear it (so e.g. F110 for the released items should be no problem) and display it.

A validation normally looks at a document "as is" (what the fields contain in a given moment) rather than "how they changed". I have not seen yet a validation that would analyze the changes made. So, the validation will in effect force the "other" users to block the item with "B" if they want to make any change to it. It is harsher than what Revan wanted, but it is hard to think about something radically different.

But you are right - the validation does not look at what the user did, but how the item looks on saving (if the "B" is there or not). Does it make sense?

[former_member188916]

Dear Jan,

Yes I got your point but I think transaction variant can work in this case.

Although I am not fully versed with SHD0, but it has a capability to make the fields in display mode only for some users.

If you have full knowledge of the same can you please guide us, if it can be used in this case?

Br,

Sapan

[Former Member]

Hi Sapan,

Thank  you for  your comments, you wrote that "SHD0, but it has a capability to make the fields in display mode only for some users." but I want specific vendor also to be included.

Regards,

Revan

[Former Member]

Hi Laxmi,

I have created a set of user's GS01 and mention the same in GGB0, it is working. Set of user dont have access to change payment block but when I delete any user name from there still the effect would be same user cant change payment block. Ideally if the user is removed from the set should allow to change payment block but it is not happening. and more  interesting part is when I remove my ID from the set I would be able to change payment block. Kindly provide solution on the same.

Regards,

Revan