AGS call syntax help

It's been a while since I've done one of these, but I think you need to enter row numbers for your other detail fields.

...&LINE-FCr13=C&HEU-FIELD-KEYr13=12&HEU-A-FIELD r13 =N&...

I've always updated UserFields by using Personnel Actions (PA52) instead of direct updates (which we block for almost everything). Of course, PA52 adds other annoying complexities...

Have you done this type of update before? It sounds like the value is on the second screen, not the first screen. If you look at this KB - 1199962 - this is for the PR13, but the same general idea, that may not be possible with an AGS call. If the order of your user fields on that screen does not matter, one possible alternative would be to make it the first one on that screen (I have docs somewhere on how to do that), and then you could use something like:

PDL=DEV&_TKN=HR15.1&_EVT=CHG&_RTN=DATA&_LFN=ALL&_TDS=IGNORE&FC=C&LINE-FCr0=C&A-VALUEr0=9927&HEU-EFFECT-DATE=20151022&HEU-EMPLOYEE=1234&HEU-COMPANY=1&_DELIM=%09&_OUT=XML&_EOT=TRUE.

Aside from that or the PA52, have you thought about using something like importdb?

Thanks, guys, and you're right -- it's on the second screen. Lawson only allows for 10 lines, so "r13" doesn't work. Gary hit it on the head. My other idea was to use IPA, but if the AGS call won't work, I have ZERO faith that IPA will help. The Infor S3 InfoCenter has a blurb about details on extended screens, but the link for information on how to do it gets you back to the beginning. I am reluctant to reorder the fields because it may break something if suddenly the thing Lawson expects to see in row 18 is now in row 19.

Is there maybe a way to update a file -- sort of a reverse-DME?. I have everything I need to figure out whether this is an add or a change, so if there is a web-ish importdb-ish utility anybody knows of, I'm all ears. I could solve this with a background SQL call, but I would rather use official Lawson methods.

This is a simple Y/N question HR wants to put at the front of the Open Enrollment screens to track a single piece of data that is never used anywhere except as an informational tidbit. It shouldn't be this difficult.

sounds like you want to store a value in Lawson based on the employees answer at the start of open enrollment?
hmm..well, reordering the user fields just changes the order they display on the user field screen would not impact anything else - we have done it ourselves using the system before and after with no ill effects..would not break anything, but understand your concerns there...
As far as IPA, you could not update that screen, but you could do a SQL update from IPA.
Some things that come to mind in no particular order..This was mentioned above, but you could create a PAN action and then update via the PA52, but depending on the number of employees that could be a lot of PANS or workflows depending on what you do. Probably not a lot of time and maybe overkill, but create a small custom screen that only updates that value - then make a AGS call to that screen. Another option would be to use a value in another table that is accessible via AGS but may not be what it was created to hold - clock nbr (paemployee) on the hr11 as an example. Could extract values after open enrollment, and then clear it out (or keep it).

plancor

You could write to a csv and use IPA to process it via HR515.

Seems to me like a PA52 action that updates only that one UserField would be the best option. Then do an AGS call to PA52 instead of trying to do it to HR15.

We do this a lot with ESS changes.

I like Gary's custom program idea. We could make it bring up one record based on company, employee, field-key and not have to deal with the page-down nonsense. I will discuss this and see what we can do about it.

HR will stroke out if I add thousands of PA52 actions to be updated on top of all the things they have to do for OE plus hire, fire, transfer, etc. existing employees. It's a great idea, Kelly, but I don't know if it will fly. OTOH, there will be history and HR types like as much history as they can get. I would prefer that over plancor's suggestion of writing a file and running HR515. This, like PA52, would generate thousands of files/transactions, and I would like to avoid that. All of these appear to be better solutions than my dirty behind-the-scenes SQL fix (which I am trying very hard to avoid).

I'm very much in the kiddie pool section of AGS calls. So this might just be me ignoring the whole "Better to remain silent and be thought a fool than to speak out and remove all doubt." mantra.

And I'm not familiar with the difference between making a chance to a user field via HR11 and doing it via HR15.

But making this change via HR11 through the upload wizard only requires specifying the field key and selecting row 1. It doesn't matter what row the field is actually on, as passing the field key explicitly bypasses that issue.

(late edit - I forgot that you actually have to pass it twice. Once as HRU_FLD_NBR1 and once as WS-FLD-NBR - note no # at the end of the field name)

Given the upload wizard does it's magic via AGS, wouldn't the same hold true here?

If not, would someone mind educating me on what the difference is?

[Updated on 10/23/2015 1:39 PM]

Attached is the docs I received a good while ago during one of the Lawson webinars concerning it.

[Updated on 10/23/2015 1:42 PM]

I think Sal was looking to update a table from EMSS as part of open enrollment - 'This is a simple Y/N question HR wants to put at the front of the Open Enrollment screens to track a single piece of data that is never used anywhere except as an informational tidbit. It shouldn't be this difficult. ' - i.e., from within EMSS while doing the enrollment process - and so using the upload wizard from Excel would not work in that case.

Right, but the upload wizard is essentially just a fancy wrapper on AGS calls. If you can do it via the upload wizard then you should be able to do the same thing via a raw AGS call while in EMSS.

I'm just trying to drill down on why you'd have to account for what row the user field is on here, when you wouldn't have to when doing it via the upload wizard. I'm fairly certain the form itself only cares because the form gives you the option of doing multiple rows of changes at the same time and needs to keep your changes from row 1 distinct from the changes you entered for row 10.

Again though, I'm still in the kiddie pool when it comes to AGS. I'm sure I'm missing something, I'd just like to know what.

If you look at the KB article I mentioned - 1199962 - it says that you can't access the second screen in a AGS call, but shows how you can do it with the upload wizard..it could be with some additional playing around it might be possible - I'm just going by what the article says...

This is the AGS call I just lifted from a quick upload wizard session. After swapping out the raw field numbers for field names, passing it raw to my browser, did receive a "Change Complete"

/servlet/Router/Transaction/Erp?
_PDL=HOPE
&_TKN=HR15.1
&_EVT=CHG
&_RTN=DATA
&_TDS=IGNORE
&FC=Change
&HEU-COMPANY=1
&HEU-EMPLOYEE=909
&HEU-EFFECT-DATE=20151023
&HRU-FLD-NBRr0=2066
&PT-FLD-NBR=2066
&A-VALUEr0=Y
&LINE-FCr0=C
&_OUT=XML
&_EOT=TRUE

So I think the problem here was simply that the AGS call was attempting to call row 13 (edit) and that it wasn't refering to the field number correctly. You have to add 2000 to the raw number, so my call is actually touching the user field assigned a field number of 66 (which btw is on the fifth page of user fields for our system).

[Updated on 10/23/2015 4:39 PM]

OK, so the problem is that HR11 can't get you there no matter what you do and HR15 does not respect the "position-to" nonsense. Even though the AGS call requests PT-FLD-NBR=2012, the form never pulls it up. That said, I cannot understand why the AGS call runs "successfully" with a "Change Complete" message but changes neither the value of the User Field with HEU-FIELD-KEY=12 nor the value of the User Field in the first row (using LINE-FCr0=C). Infor has broken AGS.

I played with the AddIns for a bit, and I was unable to modify anything anywhere if the data was in an HR User Field. Every time, however, the transaction reported success. It appears that, in Version 10, Infor has broken MOAs worse than they have ever been broken before.

On Friday, I quick-painted a program which was broken out of the box. PGMDEF now adds "@ symbols randomly, generates the PD with 200+character-long lines, changes the PL, System, program, screen, and transaction names to XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, and misaligns EVERY line in the generated .scr file. I spent 6 hours Friday and today fixing the generated code" so it could compile. In their infinite wisdom Infor broke the entire AMT tool set. It would have taken me less time to write the damned program from scratch than it did to "quick" paint a screen. Infor has made the easy-peasy COBOL tools unusable.

It's really sad to see that in an effort to move "forward" Infor has broken the parts of their product that actually work.

Thanks to all -- Kelly for quickly trying to get me sysntax, Gary for the custom program idea, and Sam for taking the time to play with the MOAs and the AGS call. I am curious to know if you were able to successfully change information in HREMPUSRF with that "successful" call -- I was not, and if you were it is only a testament to the fact that nothing works the same way twice.

I was, it even updated the groups tied to that field. But I'm actually on 9.x rather than 10.

I am oh so looking forward to the forced update to 10 next year if this is truly the case.

jreese

I have created multiple quick paints in v10 and we have used the AMT tool to upload patches with no issues here.