View Full Version: Pa52.4: Get Preassigned Emp Number In Pf?

LawsonTalk > BCI, Processflow and Addins > Pa52.4: Get Preassigned Emp Number In Pf?


Title: Pa52.4: Get Preassigned Emp Number In Pf?


satterw - October 14, 2006 03:57 PM (GMT)
We use Lawson's auto-generation of employee numbers. When we hire an applicant (PA52.4), we would like to pre-assign the employee number - this way, a preciously can kick off and alert our various departments about the impending hire (including what their employee ID will be) as quickly as possible. The problem is that I can't figure out where the employee number is stored while the hire is pending (i.e., before PA100 is run). The pending change is kept in table PERSACTION, but the EMPLOYEE field holds the applicant number, not the emp. number. The only place I can find the correct number is in PERSACTION.PARTICIPNT, but dbdoc says that has to do with COBRA IDs, so I'm not sure that's "official."

Am I missing something? This seems pretty basic, but no one seems to know how to do it. The processflow variable EMPLOYEE doesn't have it either. Thanks. 8.1 applications 8.0.3 processflow.

Also posted in HR forum and Lawson Community.

satterw - October 18, 2006 02:26 PM (GMT)
Got a Lawson resource to check this out - pending employee IDs are stored in PERSACTION.PARTICIPNT like I thought. dbdoc does not say this, it's incomplete.

Milo - October 18, 2006 05:37 PM (GMT)
QUOTE
dbdoc does not say this, it's incomplete.


That's because Lawson expects you to read the COBOL to know what the business logic is. :bonk: (What, don't you read COBOL printouts while drinking your morning coffeel?? :cof: )

satterw - October 18, 2006 07:12 PM (GMT)
/sticks fingers in ears and starts saying "la-la-la-i-can't-hear-you"

I've been fighting having to look at COBOL since we were installed. Guess I'll have to bite the bullet eventually. Right about the time it changes to java, I'm sure.

Milo - October 18, 2006 07:17 PM (GMT)
Sorry, I sat in on the CUE_06 session LSF06 "Lawson Landmark Technology Overview" and the Lawson Pattern Language (LPL) is just as complex as COBOL coding. :bonk: It has to be, since it has to handle real-life problems. Anything simpler simply would not 'cut the mustard'.



Hosted for free by InvisionFree