Strange BC variable behaviour

JMast

Reputable Poster
Hello All,

I am having trouble with a standard JDE report. While any advice you have on this specific report is great, I am also interested if you have seen the same symptoms in other reports and how you resolved them.

We run the R10211B Income Statement and have not had problems until running it for this year. Running it for 2010 works fine.

What we are seeing is accounts being rolled up (subtotaled, for the non financials like me out there
smile.gif
) incorrectly. An account will print on the report, but the numbers will include the next account to be processed and the next account will not print. Essentially, Acccount 1 consumes Account 2 before the report breaks and prints Account 1.

The report uses V830001 which I have noticed has some history on JDEList. The view joins F0901 and F0902 on AID. Both tables contain MCU/OBJ/SUB fields which should match for a given AID. The MCU/OBJ/SUB fields from both tables are on the V8300001.

When I debug, I am seeing one set of MCU/OBJ/SUB advance to the next record, but the other set does not. The report then seems to be breaking on the set that is not advancing which means it doesn't break until after the next account has been processed.

I have attached screen shots of the debug variables. The first account is OBJ 7320 and works fine. 7330 is the problem. 7340 comes after 7330, but ends up in the 7330 totals. 7350 is shown to demonstrate that the report gets it right on the next account.

I read on the list the fact that V8300001 is left outer join, so I tested by changing the join to simple on my dev machine, but it still broke. As far as I can see in Access and UTB, the records in the database are all correct values.

I do have Oracle working on the case, but I know there is much expertise on the List which may give me things to look at or take to Oracle.

Has anyone seen a report business view do this before?

Thanks for your time,

Jer
 
Jer,

Yes - the V830001 matches F0901/F0902 on AID.... And there is a potential problem....


Users look at account as MCU.OBJ.SUB - and sometimes those values are changed in either the F0901 or F0902 and are not updated in Both locations....

Run yourself a query - look for differences of MCU, OBJ or SUB where F0901.AID=F0902.AID. If you come across the issue, you may want to run a process to Update the F0902 to match the F0901 (or at least forward the list to the users and make them aware of the issue).

Level of Detail is based on the MCU.OBJ.SUB - not the AID, so you may see some really interesting results...

I think I'm writing a book on Financials - be looking for it, early next year.... I, too, gotta lot to learn, before it is completed...
grin.gif


Review this post:
http://www.jdelist.com/ubb/showflat.php?Cat=&Board=OW&Number=159121

(db)
 
Daniel,

Thanks for the quick reply. I had actually seen that post as part of my search on R09806. I have done a check in Access joining on AID and looking at the accounts with the targeted OBJs (putting the OBJ criteria on F091 then trying F0902) and everything looks good, even doing left and right outer joins the query comes back with the same rows.

It just seems like it has to be something with the F0902 FY 11 rows since I can run the report for Dec 2010 right now and they will work fine. I just don't see anything wrong with those rows.

I think this may be one for the X Files.

Jer
 
Jer,

Two more things to just toss out there (remember, I am not a Functional Consultant)....

1 - has the setup for 2011 been completed? I recall 'something' about Year End dates and such - and that each year a new year has to be created in some table. My recall is extremely fuzzy on the issue - and your team should have been getting errors if it hadn't been setup correctly.
2 - You guys have applied the Century Change for 2011, right? Resetting a couple DD Values 'out there' so 2011 is not considered 1911?

Just a couple guesses?

(db)
 
Jer,

Confirm your LOD of the Report? Switch it to '9' - just for kicks?

(db)
 
Daniel,

1. Yes, setup is complete. The GL Year End UBE, I forget the name, is run to create records in the F0902 for the new fiscal year and calculate and move beginning balances into those records. It is reading those records since I am seeing the correct dollar amounts on the report (except for the rollup, obviously).

2. We were fortunate that the consultants that helped us go live made those changes at the beginning to 25, so we are good there.

Thanks for the checks. I a beginning to think this going to be something small that you would normally overlook.

Jer
 
We are seeing the problem at LOD 5. When we run it at LOD 6, life is good except it shows the detail we don't want.

Another oddity that I should have mentioned in the original post is that 'Online Consolidations' (P09218) works successfully at a LOD of 5. This is what they used for the January financials. The downside here is that it does not include the prior year comparatives.

Also, I sent Oracle the ER code and they say there are no SARs we are missing for that UBE.

Jer
 
Jer,

If I remember correctly, it has been a few years though and this may have changed, the setup for a new year can create accounts for the new year in the F0902 in 2 ways:

1) Only for those active accounts that have a non-zero year end balance, I'm not sure if this includes roll-up accounts with a zero balance.
2) All active accounts.

If the new year was setup using method one and some of the roll-up accounts were missed, it would create some interesting problems. I'm not sure if this would create the situation you are experiencing.
 
Jer,

LOD Reporting in EnterpriseOne - it's a mess! In World, you could skip around - and it worked. In E1, if you skip - you break the process.

Make sure that your Level-Break/Sequence matches with the Level of Detail. Otherwise, you can end up with issues where values are summarized incorrectly.

Here's a fun discussion to follow:
http://www.jdelist.com/ubb/showflat.php?Cat=&Board=OW&Number=161476

Now, and underlying question... Why do you reports work for 2010, but not for 2011 - and in that question, my interest is peaked...

(db)
 
Peter,

You have found the solution! The 7340.1 and 7340.2 accounts had records for 2011 but the 7340 did not. I copied the 7340 2009 record and added it as 2010 and 2011 zeroing out all the Amount fields and the report worked.

So, whatever process she is using to create the new F0902 records each year must be creating just for balance forward accounts.

Do you have the job name and/or the process to use to copy all actives handy? Also, is this something we can run at this point without damaging existing records?

I have a few other known problem accounts to look at, but I think you have put me on the path.

Nicely done. I have had Oracle looking at this since middle of January. Lesson learned. I should have come to the great minds of the List much sooner.

Thank you for your time,

Jer
 
Daniel,

Yes, I think our COA is a mess also. Not quite to the level mentioned in that post since I have not had to do many custom reports yet, but we need an overhaul. It is disappointing to hear you can't skip, but it would still be better than what we have.

In the defense of our Accountants, the Financial consultant during the JDE implementation was lousy, so we didn't have much of a chance to get things right.

Peter suggested the solution which was the fact that records for the LOD 5 account were not available for FY 10 and FY 11. There had been no activity on that account since 2009 (All the activity was moved to the SUBs in 2010). My best guess as to why the report worked last year is that it looks at both prior year and current year records. This would mean that since the 2009 record existed the report could break. -- This is just a theory.

I really appreciate your time and quesions. You have helped me learn a great deal about the Financials which I haven't had to learn until now.

Jer
 
Jer,

I had considered that maybe records hadn't been created - but couldn't recall the process well enough to place the finger on it. Now, thanks to Peter, we all know (and Knowing is Half The Battle!)...

One final thought/recommendation - regarding Financial Reporting... it fits under the Tips/Traps area:

Always Use the F0901 Fields, then the F0902 fields. Select/Sequence/Break by the F0901 columns - in the event that the MCU.OBJ.SUB.WHATEVER are out of sync between the tables - F0901 is the Ruler.

Enjoy!

(db)
 
Yeah, that is a good tip that I try to follow in all of my development. It also is why I was so confused in this situation since the F0901 LOD 5 record existed and the FY11 F0902 records existed for the accounts. The report sequences and breaks on the F0901 as far as I can tell. It never occured to me to look for F0902 records for the LOD 5 account.

I still don't get why the report BCs broke like they did. I would have expected the records to be skipped. However, that is something I am just going to let slide and move on.

Jer
 
Steve,

1) I agree to an extent. If I had not done any research and was just confused about why the account is not showing up I would have posted to Applications. The trick here is that I had already done a lot of research and discovered the BCs not looking the way they should which led me down the path of Business View / Event Rules problem which fits in the Developer Forum.

You may be correct that I may have gotten a faster fix in Applications, but the beauty of the List is that many people read all the forums. This is a great example of that since Peter and Daniel helped me out pretty quickly even though it may be in the wrong forum.

2) I don't know what R09804 does, but in our system we use R09806 which did not uncoer any problems. Using Access is often, for most techies/CNC (like me), a very quick and flexible tool to uncover specific data issues. Access allowed me to come at the situation from different angles (join types, data criteria...). I have also seen Access find problems you don't see in JDE reports or forms since a corrupted record can sometimes simply be ignored by JDE.

Just providing insight into my thinking...
Jer
 
Jer,

1) I meant my comment to be more along the lines of a helpful plug rather than a slam. I should have separated my responses and then it might not have been taken so. There are always 6 different ways to get to the same answer.

2) You can run R09804 in proof to be able to find differences between the MCU.OBJ.SUB in the F0901 versus the F0902 and F0911. Which of course you can also do with SQL or Access or... Just another tool to put in your box.
 
Jer,

I'm glad that information helped.

I can't remember all the details, but I think it had something to do with the Annual Close Report (R098201). I also think that the process, what ever it was, was re-runable. I had a quick look, but couldn't find any more information.

As for the other UBE's mentioned:

R09804 - Copy Accounts to Business Units - As far as I know it only operates on the F0901.

R09806 - Global Update BU/OBJ/SUB to F0902/F0911 from F0901 - As far as I know it only updates existing records, based on the AID - it does not create new records. So I doubt if accounts "missing" from the F0902 would be reported.
 
Steve,

I was surprised to see you delete your post. Other than the one minor comment at the end (which you labeled well as IMHO), I didn't take any of it as a slam or negative. I am sorry if you thought I was being defensive. I was simply relaying my thought process and more detail on the approaches we used on this case. Like you, the intent is simply to provide understanding for those who come after looking for help in similar situations.

It can be hard sometimes on forums since there is no tone of voice, facial expressions... So, please don't be concerned about stating your perspective. This is the main reason I am so wordy since I think it helps sometimes to communicate context. Caveat: Some people on the forums can sometimes be intentionally mean. I try to have a thick skin and give posters the benefit of the doubt unless their words clearly state otherwise.

I do appreciate your post of explanation, by the way.

Jer
 
Peter,

Ok, good. R098201 is what she already runs for Year End. I looked at the P/O and there is one for creating Profit Loss records which we have as blank. I think I am off to the PY environment for a test spin!

Thanks again,

Jer
 

Similar threads

E9.2 Account Number invalid Error
Replies
2
Views
530
markdcci
markdcci
E9.2 India Audit Regulation
Replies
0
Views
343
BCampbell
account lockout
Replies
1
Views
133
markdcci
markdcci
JohnDanter2
E9.2 BSVW left outer join behaviour
Replies
7
Views
1K
JohnDanter2
JohnDanter2
Rauf
E8.12 Show paragraphs in RDA print
Replies
7
Views
1K
Rauf
Rauf
Back
Top