We are going with EPIC to interface Pt Refund files to Lawson. I provided specs on the APCINVOICE (csv) file but when AP tried to process the pt refund a couple things happened:


1) The acct# (12110) is not coming over. Is there another process that pulls this into the file? EPIC has been saying that they did not include the acct# because it wasn't in the specs. APCINVOICE does not have the acct# field. I know that this is in the APCDISTRIB table, but how do I get this included?

2) Where is the Vendor # being created. EPIC says they do not provide Vendor #'s

Really, I am the wrong person to answer this, but when has that stopped me before? Understand that I work primarily the Materials side of the shop, and the A/P side of the room is the proverbial "black box" to me.

This I do know. We receive PT Refund information from MS4 (we are getting to EPIC) in a routine interface. There might be some transmformation as a part of that interface, but I cannot say exactly how much or in what context. See? I told you I was the wrong person.

But, I also know that our PT Refund vendor numbers auto-generate. Our little schema was to use a full nine-digit number that started "999000001" and rolled out from there. If a returning patient has another refund, that goes out under a separate vendor number. This probably has more to do with the auto-generation process rather than a conscious decision.

I'll suck it up and ask the A/P and Interace folks and try to get back with more info.
rw

The vendors are ususally created as ontime vendors. In the APCINVOICE table there is a field where you flag the one-teime vendor to yes and fields to include the name and address.

If the account and department are always the same for the distribution, you can create a distribution code. The APCINVOICE fiel has a field for distribution code and you will not have to import the distibution throught the APCDISTRIB file

Well, I poked around a bit. Actually, I asked my favorite AP person about this. I didn't get too far into it, but I was able to discern a few things.

1 - Our process is surprsingly vanilla. This was more of a personal revelation.

2 - Our Interface team's role is simply to transport the data from the MS4 system to the Lawson server. There is no transformation of the data. They also do not send over the vendor number...

3 - The auto-generation of the vendor numbers is a by-product of running the AP520 (and not some design decision on our part). I was told you would not see the vendor number until the AP520 is run in update.

My guess is that if you are not getting the 12110 account information you are looking for, there is something amiss or askew in the background AP build. The form help for the AP520 mentions about five or six prepatory tables that need to be built out for the AP520 to function correctly.

Probably still not helping much, but hopefully getting you a little closer to your truth,
rw

Are you referring to CVI-DIST-CODE? If so, we are using that for our "PTR" code which is simply "Patient Refund" - but, it is not gl related.

That is the correct Dist Code field. You just have to set up that code in AP so it links to your account number. Otherwise, go ahead and use the APCDISTRIB file, and all you do is load that file and the APCINVOICE one after the other, and when you run your AP520, all the data from both files will show up. You can do it either way.

look at my error:


File TEST/APCINVOICE.
tsStoreDBRec error is Database error (94).
Additional information is 1843.
Additional Text is:
StoreSqlRec(LAWSON.APCINVOICE)
OCIStmtExecute() returned OCI_ERROR code 1843 parse offset 88997888 (
ORA-01843: not a valid month
)
File TEST/APCINVOICE.
tsStoreDBRec error is Database error (94).
Additional information is 1843.
Additional Text is:
StoreSqlRec(LAWSON.APCINVOICE)
OCIStmtExecute() returned OCI_ERROR code 1843 parse offset 88997888 (
ORA-01843: not a valid month
)

3 Record(s) Processed

0 Record(s) Added
0 Record(s) Modified
3 Record(s) Skipped
0 Record(s) the Same


Import Comma-Delimited File

Doesn't make any sense. I mapped the fields to spec..?

Sorry to ask a dumb question, but, it looks like you're having problems with the date format. Can you format the incoming date(s) in a different way? When I've dealt with data transfer, date formats can be a huge problem.

Can you post those 3 lines here (assuming it's not sensitive info) and some of us could try it ourselves?

Yeah - that was it. Changes it from YYYY/MM/DD to MM/DD/YYYY

Got it to load the records ok. Now, I can't seem to get the records processed with AP520? Am I missing a step?

SMS has built a step -interface- SM140 to load the mapping then it looks like AP520 is run to process them. I built an SM140 job the same way and it's not working .... hmmm :whip:

So I got the 2 files to load ok - APCINVOICE / APCDISTRIB, ran AP520 and there are no invoices to cnvert?? No errors either...