Sage 100

Another Visual Integrator question...in this case, the customer is running 4.50.4.0 of Sage 100 Standard. I'm trying to import into SO_SalesHistory. All of the fields are importing except for the numerical ones (DollarsSold, CostOfGoodsSold, and QuantityShipped). I've attached the VI job and some sample data. Could it be that the only way to import this data is to bring it into SO Invoice Data Entry and update?

Any error messages?

None at all. Both the test import and the actual import logs show everything importing perfectly, including the numeric fields. However, when I DFDM SO_SalesHistory, there are no numerics.

Only thought before I go rake leaves, should you specify a record type? I wouldn't since you are file assigning it, but might be worth a shot......

What? You're not watching the Redskins? I figured you would have converted by now. I tried the record type idea earlier. It returns a message of ""Invalid job definition. Record type is defined without a corresponding data element"". The KB says that the workaround is to delete the record type.

Sorry to say that I am not a huge footbal fan. Took me a month to figure out who RGIII was.... Is Alnoor out of bed yet?

@JohnShaver - I ran your import and got the numeric data imported...

Phil, that's even more mysterious. In a test company, I manually reinitialized the SO_SalesHistory table just to see if that would do the trick. No luck.

@PhilMcIntosh did you verify it through DFDM? I tested his as well and it LOOKED like it imported but it was not in the file when I looked in DFDM.

@ThereseLogeais - yes I did

Hmm, did you change anything? What version is it?

The only thing I changed was assigned the item number rather than create more items in ABX

How did you assign the item number @PhilMcIntosh? From what??

I did assign instead of replace. Not all the lines imported (the item is part of the key) but the ones that did had the quantity and dollar fields.

I tried to do the same and it didn't work for me. Can you export your VI job and post it @PhilMcIntosh ?

Here it is

Wow, that's weird @PhilMcIntosh. I changed it to assign the item number to an existing one and it worked. Very odd....

Looks like we have another VI program that doesn't actually use the objects...

But back to @JohnShaver's question, why are you importing sales history? I don't typically import directly into a history file.

Must be part of the KTA in setting up the new sysem. I've imported into AR History before but never to this file.

When is this file referenced? I don't see it in the customer sales history or the item's sales history (for what I imported)... Am I missing something???

Jeff is exactly right. It's a new implementation and the customer wants 24 months of customer sales history imported into 100 from their old system. Since they like the format of the reports in SO customer sales history, my thought was to import into SO_SalesHistory. I'll try Phil and Therese's suggestions. If no luck, I'll go with Jeff's idea of importing into AR history.

@JohnShaver - My assigning the itemcode may have helped point out where the bug is but it won't actually help you import the records, because the itemcode is part of the key - you will only get one record for each customer/item/date combo.

Thanks for the clarification. It's looking like AR history is the path to follow.

Try replacing or assigning the item type instead of reading it from the CI_Item file.

Jeff, still no luck.

@JohnShaver if you import this into SO invoice header and post it, it appears on the Customer Sales History report just fine. Attached is the import job I used.

Thanks @ThereseLogeais! I'll give it a try. Being able to import it straight into the history table would be so damned convenient since it ensures that no other tables are updated. Alas, that would just be too easy!

You'd have to remember to turn off the GL integration before posting it. I'd do this BEFORE you get the beginning balances in for IM as well otherwise you could do a physical to clear it out. You're right, importing directly to history would be sooo much easier!

Who do you think we are - QuickBooks Resellers?????

BTW, this is a good reason that, unless the customer needs a non-framework module, all new sales should be 100 Premium. With SQL, if VI won't behave you can import directly into the database.

Here's the path I decided to take: Since they are already using Sage 100 in a production environment, I'm going to copy the live company to a test company (once they are out of the system for the day), import the sales history files into invoice entry in the test company, update invoice entry, and copy just the SO_SalesHistory table back to their live company.

I thought about that option as well @JohnShaver since I wasn't sure where they were at.

And thanks to everyone for the ideas! All of the pieces finally clicked in my head. And that process in my head looks something like this: http://25.media.tumblr.com/tumblr_m8o6noM5Gs1ro8ysbo1_r1_400.gif