How can I programatically click the Refresh button

[Sunny]

We are doing a background update on the Sales order No. but need to refresh the form so that the changes are visible. How can we programmatically click the refresh button on the Sales Order Form?
Thanks.

[Mike.Sheen]

We are doing a background update on the Sales order No. but need to refresh the form so that the changes are visible. How can we programmatically click the refresh button on the Sales Order Form?
Thanks.

I'm not sure what you mean by background update - but clicking the refresh button will cause the sales order to discard any changes and re-read the order. Is that what you want?

[Sunny]

Hi Mike,
We have written a subroutine to prefix the default sales order no. created by JIWA, and write it back to the database. This is in the SaveEnd routine, so there are no changes post this. We need to refresh the form so that the user can see the new Sales Order No.
Thanks.
Sunny

[Scott.Pearce]

There is a RefreshRecord() method on the form object that you can call.

[Sunny]

Thanks Scott. Got that working.
Regards.
Sunny

[Mike.Sheen]

Hi Mike,
We have written a subroutine to prefix the default sales order no. created by JIWA, and write it back to the database. This is in the SaveEnd routine, so there are no changes post this. We need to refresh the form so that the user can see the new Sales Order No.
Thanks.
Sunny

I'd like to add that there is perhaps a better way to do what you want, other than programmatically clicking the refresh button - which I might add results in a double read of the order on save, and has an integrity risk.

If you want to customise the sales order number to be something other than the auto-generated one, you can hook into the SaveStart event and set the InvoiceNo property there. We won't try to set the InvoiceNo property using the built-in sequence numbering system on new orders if it is not blank. That way you don't need to cause a second subsequent read (by programmatically clicking the refresh button). When the save finishes, the form will correctly display the invoice number. It also means any other aspect of Jiwa or plugins examining or using the InvoiceNo field on save will have your invoice number.

Altering the InvoiceNo using a SQL update on SaveEnd, then forcing a refresh may appear to work, but anything between SaveStart and SaveEnd will be misinformed as to what the InvoiceNo really is. You also run the risk of not actually setting the invoice no. - if it is a duplicate in SO_Main, the unique index on SO_Main.InvoiceNo will cause an exception, and it will already have saved with the generated invoice no. anyway - so your user gets an exception about a unique index violation, and the order is already committed with the auto-generated invoice no.

TLDR; I think you're doing it wrong.

[Sunny]

Hi Mike,
I understand where you are coming from.
The aim was to prefix a designated Warehouse code for SOME Warehouses, to the JIWA generated built-in sequence numbering system (not generate a new one). Customer would like the numbering to be in sequence to instances where no prefix is done.
This JIWA generated number is only available at the Save End event.
Going by your logic, we will have to build a suitable numbering system to generate a unique number and prefix the Warehouse code by the rule.
Will look into this.
Thanks for the insights.
Sunny

[Mike.Sheen]

Hi Mike,
I understand where you are coming from.
The aim was to prefix a designated Warehouse code for SOME Warehouses, to the JIWA generated built-in sequence numbering system (not generate a new one). Customer would like the numbering to be in sequence to instances where no prefix is done.
This JIWA generated number is only available at the Save End event.
Going by your logic, we will have to build a suitable numbering system to generate a unique number and prefix the Warehouse code by the rule.
Will look into this.
Thanks for the insights.
Sunny

I see what you're doing now. I recommend you hook into the Save Ending event, as at that point the InvoiceNo generated is known, then perform an update of the SO_Main.InvoiceNo field there (using the current transaction), that way your update is wrapped up in the same transaction as the sales order save uses, so any problems will cause the whole lot to rollback and you won't have any integrity issues - and there is no need to perform a re-read or refresh.

[Sunny]

That's pretty straightforward. Will do.
Thanks Mike.
Best Regards.
Sunny