Create a custom event when saving supplier record to check a field is not null

Hi @JannetteC 

You can create the custom event for the based table where the window data stored, and on the action select SQL Query.

DECLARE

BEGIN

IF ('&NEW:SUPPLIER_NOTE' IS NULL) THEN

    ERROR_SYS.Record_General('CustomerOrder', 'Supplier Note field cannot be null.');

ELSE
    NULL;
    
END IF;

END;

On above, &NEW:SUPPLIER_NOTE is the column that you trying to validate. So you can change the code as per your requirement.

Hope this helps.

Cheers!

 

Thanks for the response, I am getting the following error now.

Hi @JannetteC ,

 You can try something like this. Let’s assume you are going to check if Association_No is not blank.

Hope this helps.

 

You have to type something in Action Description section. That’s why you get this error.

Thanks, Ihave made the change but the record is being created still

@JannetteC@JannetteC Supplier ID is a mandatory field. If you do not specify it system generates it through a sequence.

So you can't use Supplier ID for this scenario. Try something else 

Thanks - Is there a way to turn off the auto sequence

I think you will want this to fire Before the object is created, not “After” if you want it to prevent the write. Try changing “Fire before or after object is created” to “Before”.

Joe Kaufman

You can select Fire Before option. So your error should be raised. 

Hello both - I have amended to ‘Before’ but still the record is created

To clarify for sure: You get the error, but the record still creates? This is not my experience with a “Before” trigger. If Error_Sys.Record_General() is triggered, that rolls back any changes. I have tested this on CUSTOMER_INFO, and no data is saved.

Thanks,

Joe Kaufman

Hello Joe - I am not getting the error and the record is created

OK, well that is good -- at least consistent. If Error_Sys is not triggering, then the data change commits instead of rolling back.

Are you sure everything related to the event and action is saved and set to enabled? We need to reach the point of the Error_Sys.Record_General() triggering. Just put that code in the event and get things enabled/saved to the point where it triggers. Then put the IF around it until it fires when it should.

The bottom line is that if a “Before” event is firing, and it executes an Error_Sys.Record_General(), that should display a popup and roll back the save.

Joe Kaufman

Hi @JannetteC ,

Yeah, you should not get the error. I tested the same. You cannot try it out for SUPPLIER_ID. If you don’t enter a value for supplier ID manually, before saving system checks below.

Supplier_Info_General_API.

So before saving, it gets a value assigned. 

Hope this is clear for you.

Sorry I missed that you are triggering on SUPPLIER_ID… As Chamika points out, that isn’t going to work because IFS will never allow a supplier ID to be empty. It is one of those, “If you fill it out, great, and if you don’t I am going to fill it in” fields, just like Customer ID on CUSTOMER_INFO.

I am guessing you are facing a business scenario like the following: Your company wants to use its own Supplier ID field, and wants to make sure the user fills it in so that some Supplier IDs don’t end up being the serial number automatically generated? We faced the same issue and decided to let IFS generate the supplier IDs, starting at 1000. You can control the series ID on this screen:

For us, we only migrated around 1500 suppliers, so by starting at 1000 we end up with a consistent ID size (four digits) with plenty of room to grow. You may want to start at 10000, allowing for 90000 suppliers before the ID size changes and falls prey to potential sorting issues, etc.

But the decision that took a bit of discussion was to give up the old ID system that was based on letters in the supplier name -- a “natural” key that would often cease to make sense if a Supplier changed names or “doing business as” title. We decided to just go numeric with it and haven’t looked back. IFS generates the ID, and that is what we use.

You might also consider using the Identifier Reference field to store a key your business users need to identify the Supplier. You could enforce a “not null” requirement on that field and use it to store an alternative ID.

Thanks,

Joe Kaufman