RQ10 on Add script

Do you have Design Studio? You could add a script there to do this.

After you do an Add - you can execute lawForm.setFormValue("text??", Req Number) and then execute a tranMagic.transact("C") to force a Change.

Posted By Queue on 01/19/2010 11:14 AM

Without using Process Flow, is there a way to execute some sort of script that when a user adds a record on RQ10, that I could take the form Req Number generated by the add, and then populate that value into PO User Field 5 and then execute a change request to save the update? 

I know I can use lawForm.getDataValue("RQH-REQ-NUMBER");
and I'm fairly certain I can figure out how to set the RQH-PO-USER-FLD-5 (whatever the command is) to that value.
Just not sure how to execute it on add or how to save the update.

I'm fairly certain this is easy to do in process flow, and this seems like a process flow function to me, but I guess they want to try to do it without Process Flow since they are having some kind of unknown problems with it I guess (I dunno my boss didn't quite make that clear to me).

 

Thanks,

This is the ideal usage of a user exit.

yes I'm trying to do this in Design Studio. And thank you ConsultDavidW that's what I needed. :-) Didn't know how to force the change. How do i check or know when the add occurs, so the script knows when to run the script? The add, inquire and etc buttons aren't part of the RQ10 form so it's not as simple as just attaching an "OnClick()" event to the add button. Is there another magic transaction code to know if Add has been executed?

John Henley, can you explain what you mean by "a user exit" ?

function FORM_OnAfterTransaction()

{

var sMsg = lawForm.getStatusMessage()

if (sMsg=="Add, complete continue")

{

--run script--

}

}

I am curious as to the reason you are attempting to do this? Is this to do one requisition to one PO functionality? We did something similar but with triggers. The one requisition to one PO functionality is better in Lawson Apps 9... Here is what the trigger looks like on SQL Server. Oracle etc. will be a little different. This is code for Apps 8.1 it looks a little different for 9.0....

CREATE TRIGGER [xxReqHeaderInsertUpdate] ON [dbo].[REQHEADER]
FOR INSERT, UPDATE
AS
SET NOCOUNT ON --If you don't do this Lawson will not like it.

UPDATE REQHEADER
SET REQHEADER.PO_USER_FLD_3 = rhdr.REQ_NUMBER
FROM inserted rhdr
WHERE REQHEADER.COMPANY = rhdr.COMPANY
AND REQHEADER.REQ_NUMBER = rhdr.REQ_NUMBER
AND REQHEADER.REQUESTER = rhdr.REQUESTER
AND (REQHEADER.PO_USER_FLD_3 <> rhdr.REQ_NUMBER)

SET NOCOUNT OFF --If you don't do this Lawson will not like it.

You may want to use a user exit instead as John suggested.  Especially if you are using RSS.  If you do a design studio form this functionality will not port over to RSS even though RQ10 is the form called within it.

A user exit is "black box" coding you can tack on to any on-line form.  There are three types Begin, Middle and End.  The end user exit is where you put your logic after the Add, Change, Delete was successful.   It is COBOL, it has a set name requirement  (ie  HR11 End user exit Procedure Division is HR11EPD) and has to be compile seperate to and before the main form (with -u option).  

The nice part about user exists is when you do an app upgrade, as long as the field names are still defined on the screen that you use in a user exit, you do not "lose" the code because they don't get overwritten on upgrades.

Another advantage of user exits is that they are part of the core logic executed by the transaction form. So, unlike Design Studio, they are used whether the transaction originated is LID, Portal, RSS, etc. =