Migrating data into Lawson subsystems

Welcome to LawsonTalk. We hope you enjoy your visit.

You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free. After registration, please check your e-mail within 24 hours for an message from us, read it, and reply to it.

Join our community!

If you're already a member please log in to your account to access all of our features:

Migrating data into Lawson subsystems; data conversion
Topic Started: Dec 31 2009, 12:59 PM (344 Views)
rsteedle	Dec 31 2009, 12:59 PM Post #1
Newbie Posts: 1 Group: Members Member #14,981 Joined: August 20, 2009	We are new to Lawson, and are implementing 9.0.1 with the assistance of consultants. We want to convert historical transactions for multiple years worth of into Lawson. We want the ability to use Lawson's drill-around functionality on the converted data as if the transactions had been created in Lawson originally. We have reviewed the various data conversion file layouts with our implementation consultants and do not see a way to link subsidiary transaction history to general ledger transactions. Is it possible to create the drill-around linkage on converted data for all subsystems(AP, AR, payroll, purchasing)?



schroncd	Jan 5 2010, 08:41 AM Post #2
Lawson Technorati Posts: 689 Group: Members Member #13 Joined: January 11, 2006	I don't usually answer questions that I'm unsure about, so let me tell you to take this with a grain of salt. I don't BELIEVE what you are trying to do is possible, due to the fact that there is now way to build the underlying links during the data conversion process that make the Drill Around capability possible. I'll wish you luck, and hope someone here knows of a way to do it of which I'm unaware.



3monkeys	Jan 6 2010, 01:00 PM Post #3
Super Member Posts: 168 Group: Members Member #240 Joined: January 13, 2006	Same caveat that Dave mentioned goes for me. I don't believe any conversion programs will do this since those generally import summary level data. What you're needing for drill-around detail is the transactional data. Maybe somebody else has a better answer.



Milo	Jan 19 2010, 10:05 AM Post #4
Rebmem Member Posts: 361 Group: Members Member #424 Joined: February 9, 2006	Well, it is possible, but .... If you read the .sr files they will give you specific information about how the drill-around linkage goes. In effect, they'll tell you what files and what fields need to be populated for drill-around lookup to work. Even of you have the information to populate the subsidiary tables, difficulties arise with specific linking information, such as Journal Book Number, Object Id's, etc. Your conversion system would have to link and/or create the proper linking information. Not for the faint of heart. We converted from a Lawson 7 system to a Lawson 9 system a couple of years ago, but, we kept our old system operational in case something needed looking up. I hope that helps.



MichaelLandis	Jan 21 2010, 01:33 PM Post #5
Member Posts: 17 Group: Members Member #14,907 Joined: July 14, 2009	I concur with Milo - I think that it could be done. But it would be very challenging and there are many dependencies, first of which is does the legacy system that you are converting FROM contain the links between GL and the subsystems needed to identify which GL transaction goes with which subsystem transaction. If those links don't exist, then I can't conceive of how you might pull this off. But if those links DO exist, then a solution might (might) look like this: First you must understand how Lawson ties this data back and forth to each other. Have a good look at the OBJ-ID fields (and there are frequently multiples of these) in the GLTRANS, APDISTRIB, PRDISTRIB, etc. Spend some time creating (NOT converting/importing) transactions and reviewing how they link up. This is the key to most (but not all) of the various drill-around features. Once you understand this well: 1) modify the GL165 (assuming you're using this to load your historical GL data) to create records in a custom table that captures the GLT-OBJ-ID for each transaction PLUS the identifying characteristics that links it to the subsystem (for AP that would be vendor, inv-no, gl-dist-co, gl-dist-account, gl-dist-acct-unit, distribution-seq-no, or whatever the legacy system uses for linkage.) Depending on what this linkage looks like, you might have to modify the GLTRANSREL table to include the additional columns/fields that you want to pump into your custom table. The GLT-OBJ-ID is a unique identifier created when GL165 creates the record. 2) modify the AP520 to read this custom table when you're loading your historical (closed) AP invoices, and assign the GL-OBJ-ID for each invoice distribution (APCDISTRIB rec) to the APD-GLT-OBJ-ID. I'm not sure, but I think the AP520 does not normally populate this field for closed/historical invoices. Again, you might have to modify the APCDISTRIB to hold the linkage data you'll need to read the custom table described in step 1 above. And that's just for AP. Rinse and repeat for every other subsystem/conversion program. I've never taken on a project exactly like this, but I've worked around the GLTRANS table and it's related tables enough to think it might be possible. You need to do your research, analysis and testing - lots of testing... GLTRANSREL and APCDISTRIB are staging tables used for batch data loads - once your data is loaded these tables are empty. Once conversion is through, restore these tables and GL165/AP520/etc/etc back to their original versions and drop the custom table. Good luck! Michael L.


« Previous Topic · Other · Next Topic »