Closed orders/invoices posting in current period--repeated problem

unknown

Hi:

If this sounds familiar, ring me up

Old closed orders are getting costed in the shipments journal, throwing financials way out of whack. We've come up with a bunch of journal entry work-arounds but every month posting is a nerve-wracking experience and we can't get a clean financial report. We have put in several support tickets and can't seem to get to the basic question, which is:

Why does Visual post something from 7 years ago with no current activity at all, period. End of sentence. We've dug deeply into the data held in the tables and reviewed product codes, links to work orders, etc. and there seem to be no rhyme or reason why this happens (at least that we can tell).

So, we're looking for someone out there who is currently struggling with a similar issue and could perhaps share some insight on your end.

Thanks for taking time to read this.

unknown

Irritatingly, we've been struggling with the same problem for quite a while and support has no clue why. Last week at the Infor Visual Connect user conference in Orlando the problem was mentioned and the consultants there were instantly aware of the problem and solution, as apparently they see it "all the time" (I can and did rant to some Infor people at the conference about a problem they're consultants consider "common" and their support personnel have apparently never heard of, but I digress).

Basically, according to the consultants last week, closed orders recosting and trickling out for months or even years with tiny adjustments every month is what happens when a product code is incorrectly changed in the system. Visual accounting really really hates it when a product code is changed. When a product code is changed, everything that product code ever touched is recosted, no matter how far back in time it goes. Even if the product codes in question use the same G/L accounts, it still tries to recost everything and will make these adjustments for months, potentially years, a tiny bit at a time every order every month. Maddening.

There is a procedure (handed out last week, and apparently also available if you search Infor365 for "change part product code") for the proper way to change a product code, and the same procedure (below) will supposedly fix the problem even after the product code was incorrectly changed in the first place. A couple notes on this process: A) I haven't tested it myself; the reason I haven't tested it yet is that if you set this many posting candidates (see step 4's SQL) in a large database (whether lots of activity or lots of years) it can take a long long time to process. Like a weekend or longer. Every single purchase order, work order, and customer order will get recosted, and a decent sized chunk of inventory transactions as well, all the way back to when you went live with your current database. The very strong recommendation was that this first be done in a test copy of the database to make sure it works and see how long it will take, because you'll need to kick everyone out of the system so there are no other costing activities going on (which basically means no shipments, inventory transactions of any kind, labor transactions, etc., so basically everything) while it runs and posts the batch. The procedure is:

1. Make sure no activity is taking place while performing these steps.
2. Run Costing Utilities, Prepare and Post all journals to get all the daily transactions posted.
3. Make all desired account changes
4. Turn on all post candidates in all journals affected by the change, see SQL statements below:
UPDATE PURCHASE_ORDER SET POSTING_CANDIDATE = 'Y';
COMMIT;
UPDATE INVENTORY_TRANS SET POSTING_CANDIDATE = 'Y' WHERE CLASS = 'A';
COMMIT;
UPDATE WORK_ORDER SET POSTING_CANDIDATE = 'Y' WHERE TYPE = 'W' AND SUB_ID='0';
COMMIT;
UPDATE CUSTOMER_ORDER SET POSTING_CANDIDATE = 'Y';
COMMIT;
5. Run Costing Utilities, Prepare and post all entries. All entries should be resulting from a reevaluation with the new accounts information.
6. If you do NOT want history to be changed, Transpose all entries resulting from Step #5. (General Journal Entry, Batch Information, Transpose Button). If you want the history to be changed do not transpose these entries.

Note the last step reverses the journal entries so, in theory, none of your history will get changed. I would guess that if you don't care about that then it doesn't matter so much if other people are active in the database when you do this (it would just mean their activity would get mixed in with this massive re-costing run when utilities is running).

In my opinion this whole issue is more than a little ridiculous, and more evidence of how poorly constructed Visual's accounting module is, but "it is what it is" according to the consultants last week.

0712131256598360.doc