Can't get new pay code to work on YR36

Why did you need to use Design Studio to add a new pay code? Adding a value to a Design Studio form doesn't mean it's valid in Lawson.

She's not adding the paycode in Design Studio, she's saying she can't enter a timerecord against it. The paycode already exists, as she can see it in the PRPAYCODE table.
.
I'm assuming YR36 is your custom version of PR36?? Is it a COBOL customization or just Design Studio?

When you say you "added it" what does that mean?

The YR36 is Biweekly Time Entry. I didn't realize it was a custom form but after looking at the PR36, I guess it is. It would have to be a COBOL customization which means I need to look at the COBOL code.

When I added it in Design Studio, I just clicked on the drop-down box for the code and hit custom and added a new option. The payroll people added it to the PRPayCode table using (I believe) the PR20.4. At least that's what they sent me a screen shot of. I looked in the PRPayCode table using TOAD to verify.

I'll look at the COBOL code on Monday and report back. Thanks.

In case someone else needs this information...

I had to change the YR36.scr file to include the new field. Then I had to recompile the YR36.scr file using qcompile.

YR36.scr was located in $LAWDIR/productline/prsrc and you want to be sure it changes YR36.1.xml to include the new field which is in $LAWDIR/productline/map/defaullt

I'm quite confused. Why creat a new field? Pay code is an array field with drill down capability to PRPAYCODE table. If your new pay code is not in the table then you won't see it. When you mentioned changing the .scr file does that mean the field TRD-PAY-CODE has field values in $EDIT? When you added the new field did you also changed the cobol routine to edit the new field?

What I think is that your YR36 program (cloned from PR36) is trying to validate any pay code entered and by putting an edit(values), this would eliminate data entry error. What I have done with PR36 to avoid data entry error is to validate all fields in the cobol programs and issue messages if errors are found. What happen if you added another pay code do you have to change your screen file everytime?

Sam, I'm guessing elizb means she added a new field value not a new field.

What it sounds like is that they cloned PR36 to become YR36, and then customized YR36 to only allow entry of certain paycodes. Not a best practice certainly. Ideally, and assuming this is the only customization, you shouldn't be cloning / customizing if you can avoid it, since it then requires retrofitting future CTP/MSP updates.

This is something I inherited because I went to Design Studio class and someone said you had to add the new code in Design Studio.  The person who use to handle this form is gone.  I have been working with Lawson for 6 months and I was hired to do Process Flow. The form was customized in 2002 by installation partner DigiTerra.  I do not know why the form was customized this way. With the upgrade to 9.0 and new modules added, we are trying to get away from customizations and do "out of the box" with Design Studio customizations as much as possible but we are not re-doing the existing customizations at least not right now.

The form has PPT-PAY-CODE as its Data Source (in Design Studio) but when you hit Custom, you have a custom list, not the usual ... Output Only, Allow Select, etc. so it is not getting its values from PRPAYCODE. If anyone knows how to make Design studio do a custom list instead, I'd like to know.  I have another form I would like to do it to so that only the active codes show up. I do not want to do COBOL modifications. Wondering if I can do it with JavaScript??

>When you mentioned changing the .scr file does that mean the field TRD-PAY-CODE has field values in $EDIT? YES 

>When you added the new field did you also changed the cobol routine to edit the new field? NO. 

>What happen if you added another pay code do you have to change your screen file everytime? YES, happens about once a year

Just as John said this is not the best practice of doing it but since you don't want to validate the field using the cobol program, the list of values in $EDIT should work fine as long the values are also present in PRPAYCODE table. Otherwise, that can be a problem. As for your other question, you can create a portal page by doing a DME to the file and display only active records. Another way is if the field has a drill down, then you can simply filter it using the status field. You can also do it if you have knowledge in creating indexes (dbdef), screen rules, object rules and key definitions.

The values are in the PRPAYCODE table.  Timekeepers are using the revised form and are happy.

As to my other question... The field does have drill around but I don't see anyway to filter it using the status field.  I can "search" for those that are active but that's not what I want.  I want the drill around to already be filtered when you get there.  Can I write JavaScript to filter it? 

What if I just replace the textbox with a drop down list that I manually add the field values to and set the data source to what the textbox had?  Then as long as these field values were in the appropriate table, wouldn't everything work ok?  This is an original Lawson form with no customization.

In Design Studio if I look at the properties of a textbox and hit custom, I see ...Output Only, Allow Select, Allow Drill, Has Rule, and Has Define.  Could I write a rule that says only use the active field values?  Where do the rules go?

Portal Page.  Essentially I would recreate the form as a portal page so that I can do a DME on the file to display only the active fields.  But I would lose the functionality of the form.  ??

Thanks for your continued help and patience.

You have a couple of different options. 

1) You *could* modify the drill-around itself by:
  a) adding a conditional index to PRPAYCODE to exclude inactive paycodes
  b) adding a new drill/select rule to PR.sr
 
Frankly, this is not a difficult change, but would be pretty intrusive, and you'd be modifying base code which would need to be retrofitted whenever you get a CTP/MSP, and therefore isn't recommended.

I'd really prefer that Lawson just make this change in the base code...

2) Using a little ingenuity you could customize the form in Design Studio using JavaScript.  You would hide the standard paycode field, and substitute the standard field with your own text field, which you could load with acceptable values using a DME call against the PRPAYCODE table.  You would then trap the add/change to copy the value from your custom field to the standard field. 

Before you go to far though, ask yourself "why am I doing this?".  What is the worst that can happen if an inactive paycode is used? The user will just get an error message that the paycode is inactive, right?

I will try your second option after I re-examine why it needs to be done. Good advice. Thank you.