How to check BP fields on save

[Former Member]

Hi all,

is there a way to check BP fields (like BP Code) on save?

Possibly, due to performance issue, I wouldn't like to use post transaction notifications.

Thanks!

Fabio

[Former Member]

Hi Fabio,

What kind of check do you want? By post transaction notifications, you can only get message, nothing will be blocked.

Thanks,

Gordon

[Former Member]

Hi Gordon,

I'm using a formatted search to generate BP code automatically (Fxxxx for vendors, Cxxxx for customers).

What I want to do is to check that nobody changes BP code before saving BP master data

Thanks

Fabio

[Former Member]

It is better not do this check in real time by SP. You need try SDK or you can always run a query to find if you have gap or not in your BP code.

[Former Member]

This should be checked in real time, as if the user creates a BP with a wrong code and then posts a transaction, you can not then go and change the code.

On the FORM_DATA_ADD event, you can check on the BusinessObjectInfo.BeforeAction == true to see if the code that is in the field on the form is still in the format triggered by your FMS.

To be even more secure, you could use the UI API to trigger the FMS in that field again just before they add. Again use the same event as above, but put the cursor in the BP Code field and then use oApplciation.SendKeys("^F2") which will trigger the FMS.

[Former Member]

Hi njmog1,

your comment about real time check is absolutely right: I need to be 100% sure noboby posts transactions for a BP with wrong code.

Now, do you think there is a simple solution based on formatted search only?

Thanks

Fabio

[former_member204969]

You might use the SBO_SP_TransactionNotification stored procedure (not the SBO_SP_PostTransactionNotice) for this purpose. It does not need too much resource for a simple check.

[Former Member]

Hi Istvan,

thanks for your reply but as I said in my post I prefer not to use post transaction notification.

Regards

Fabio

[Former Member]

Well there is a difference between post transaction and the transaction notification. Transaction notification happens before the transaction has been committed so you can block it and roll back (and display an error message to the user). It would be the preferred solution - and was created by SAP for exactly this purpose.

But if you have your reasons for not using stored proc, then maybe this FMS workaround would work?

How about putting the FMS on the CardCode field, and trigger it to update when the CardCode value changes? That way if the user ever tries to change it, the FMS will instantly be called again and update the value.

Hopefully it will not result in an infinite FMS loop, but it shouldn't as once it has worked once, the value isn't changing any more. It is worth testing.

[Former Member]

Hi,

I'm worried it is not possible to trigger a field (CardCode) on itself

Fabio

[Former Member]

That is my initial concern. It is better by daily checking instead of real time check.