Bug or setup issue? Close Income Statement report.

jeremyd

I am baffled here.

When a client of ours runs the Close Income statement batch job, and closes by Dimensions: (Department and Job), the resulting entries should be seperated out for each department and job code in each income statement account. And it works this way, correctly, for most of the accounts. However, for around 20(seemingly random) accounts, what it does is, it correctly divides an entry for a couple of the department codes/jobs, but then it clumps the remainder into an entry with a blank department code. Ex:

(what we anticipate:)
Account No. Amount: Department Code: Job Code:

50110 500.00 ADMIN SUMMER
50110 250.00 HR SUMMER
.....

(what we get:)

50110 500.00 ADMIN SUMMER
50110 13,000.00 -- --

And these accounts definitly have entries with (like in the above example)
department codes other than admin. Does anybody know what the case might be here? Like I said, for most of the income statement accounts, it closes correctly by dimension...but it is just a few that the report seems to ignore the department and job codes and clumps the total into a blank
department code GJ line. Make sense? There is seemingly nothing different about the accounts that don't work correctly either, as I've compared fields from the GL Account table.

Any help would be greatly appreciated. Thanks!

themave

Is is likely that there we g/l entries made without department codes for those few accounts. search your entries for those effected accounts and see if any are missing the department codes.

Just a guess, but that is most likely the case.

jeremyd

Thanks for the reply...

That was the first thing that was checked, and there are definitly GL entries with other department codes during that time frame. I wish that were the case Any other ideas?

themave

This is even a wilder guess, do you have g/l accounts set up, with code manadatory or code the same, or it might be dimension setting on the account card that are causeing default values,

50110 500.00 ADMIN SUMMER
50110 250.00 HR SUMMER
.....

(what we get:)

50110 500.00 ADMIN SUMMER
50110 13,000.00 -- --

So maybe account 50110 doesn't have a combination allowed for HR Summer, so all those enteries and any others that don't have a dimension combination are all summarizing in the -- -- department job combo.

Hope this makes since

jeremyd

Yes, that makes sense...

But since they have no dimension value combinations set up, and it works for almost all other accounts despite this, It doesn't appear to be a dimension value combo issue. G/L entries appear to have the same information for accounts that it works correctly for, and ones that it doesn't.

So I'm still stumped. There is something about the entries or something that the report doesn't like.

Any additional help?

Joe_Mathis

Hi,

Have you found a solution?

I am experiencing the same problem with the report.

I am pretty sure it has something to do with the "Close Income Statement Dim. ID" field on the GL Entry table.

I ran the debugger and then looked at the code to try figure out where it's going wrong. (or right) and it has a lot to do with that field.

In a copy of the database, I changed them all to the same number ("2") and then I got the expected results. But I haven't found the code that is creating the number as of yet. There isn't any code in the OnValidate of the Global Dimensions. Probably in the journal posting code, or maybe the form?..

So I looked to the good people in this forum for already done answers and found your post

Any luck or did it just go away?

I just checked the Navision online (never any) help and it had this to say..

When you run a Close Income Statement batch job, the system groups the G/L entries with the same dimensions before summarizing the amounts for each group. The system applies the same Close Income Statement Dim. ID to all entries within the same group. This field displays the Close Income Statement Dim. ID of the group that the G/L entry belong to.

So somewhere along the line this field did get messed up. Now to just figure out how to fix it.

Joe_Mathis

I created code to zero the Close Income Statement Dim. ID field.

GLE.SETRANGE(GLE."Entry No."); 
IF GLE.FIND('-') THEN
    REPEAT
      GLE."Close Income Statement Dim. ID":= 0;
      GLE.MODIFY(TRUE);
    UNTIL GLE.NEXT=0;

and then ran the Close Income Statement report (94) again.

Then went back and looked at the G/L entry table and it had changed the field back to different numbers which corresponded to which dimensions were assigned to it.

Anyone know of any other use for this field that I just screwed royally by changing it?

Otherwise I would like to say [Solved] \:D/

madsh

I got the exact same problem ass Jeremyd but unfortunately Jondoba’ solution dosen’t seem to work for me. Anyone else has a solution or ideer to solve this problem :-k

ecclectic

what version are u guys using. i think there has been some amendments in SP2

ssingla

Dear Friends,

I have checked in SP2 and I am finding no problems with the statement. The system has properly totaled the amount as per the respective dimension.

madsh

Okay maybe I were a little to quick about the “Close Income Statement Dim. ID” :oops: . This is what it says in the Navision help:

When you run a Close Income Statement batch job, the system groups the G/L entries with the same dimensions before summarizing the amounts for each group. The system applies the same Close Income Statement Dim. ID to all entries within the same group. This field displays the Close Income Statement Dim. ID of the group that the G/L entry belong to.

Yet the strange part are when I look at General ledger entries for those entries that say it has no dimensions in the General Journals, when I have run Close Income Statement report (94) then the dimensions fields are correctly but when I look only on the dimensions for one of the entries (shift+ctrl+d) then it has no dimensions. :-k

Strange but I just has to repost the entries and see what happens then.

ssingla

Dear Madsh,

Yet the strange part are when I look at General ledger entries for those entries that say it has no dimensions in the General Journals, when I have run Close Income Statement report (94) then the dimensions fields are correctly but when I look only on the dimensions for one of the entries (shift+ctrl+d) then it has no dimensions.

Please elaborate. I am a little bit confused. ](*,)

madsh

Ok i'll give it a try.
According to “Close Income Statement” (report 94): If there aren’t any Dimensions in the “Ledger Entry Dimension” for the G/L Entrie then "Close Income Statement Dim. ID" is set to 1.

According to those of my G/L entries how has a 1 in "Close Income Statement Dim. ID" they all has Global Dimensions but when I look at the same entries Ledger Entry Dimensions they are empty. Anyone who can tell me why that is so? :?

ssingla

Dear Friend,

Strange things do happen.

In Indian Version 4.0 SP 2 all entries has this Close Income Statement Dim id is zero. ](*,) ](*,)

madsh

I tried to set the "Close Income Statement Dim. ID" too 0 like u and jondoba have suggested and it solved some of the problem but still I wonder what's the different between Global Dimensions at the General Ledger Entries and Ledger Entry Dimensions (shift+ctrl+d) aren't those the same? :?
It seems that "Close Income Statement" (report 94) is using the Ledger Entry Dimensions and not the Global Dimensions at the General Ledger Entries :-k

jversusj

We are seeing a similar problem.

We have code mandatory set for the G/L account in question, and additional reporting currencies, so the batch job errors out when creating the journal line for this account -> define a dimension code message.

I sat through debugger and found this little block in report 94

TempJnlLineDim.DELETEALL;
      TempDimBuf2.DELETEALL;
      DimBufMgt2.GetDimensions(EntryNoAmountBuf."Entry No.",TempDimBuf2);
      DimMgt.MoveDimBufToJnlLineDim(
        TempDimBuf2,TempJnlLineDim,DATABASE::"Gen. Journal Line",
        GenJnlLine."Journal Template Name",GenJnlLine."Journal Batch Name",GenJnlLine."Line No.");

      GenJnlLine."Shortcut Dimension 1 Code" := '';
      IF FIELDACTIVE("Global Dimension 1 Code") AND ClosePerGlobalDim1 THEN BEGIN
        IF TempDimBuf2.GET(
             DATABASE::"G/L Entry",EntryNoAmountBuf."Entry No.",GLSetup."Global Dimension 1 Code")
        THEN
          GenJnlLine."Shortcut Dimension 1 Code" := TempDimBuf2."Dimension Value Code";
      END;

In our case, the GenJnlLine has a valid Dimension code. It then gets deleted in the above code. The system then fails to find the new tempDim value, so it never repopulates GenJnlLine."Shortcut Dimension 1 Code". A short time later it fails altogether and we cannot close the income statement.

Using your advise, I confirmed that the account in question has dimensions on the G/L entries, but did find entries where the Ledger Entry dimensions are undefined.

I look forward to more discussions on this topic.

jversusj

hi. i'm dragging this back up again.

i hope maybe some new eyes see it and have some advice.

We have some historical G/L entry data that lacks a Ledger Entry Dimension. As luck would have it, for some G/L accounts, the first entry being found by report 94 is a record that lacks Ledger Entry Dimensions - even though a dimension is defined on the G/L entry itself. The bottom line is that we had 2006 closing entries with no dimension and this is giving our accounting staff trouble in preparing necessary documents. we currently use only 1 dimension - global dimension 1.

Is there anything that can be done to "correct" the 'bad' closing entries? For example, say report 94 sorts the G/L records descending (and thus first finds a record with valid ledger entry dimensions). Would it post a correct closing entry (with the proper dimension)? what other options are out there? we are not developers and do not have permissions to modify G/L entries (or report 94), so i'm looking for any advice here that can get us on a proper path with our NSC.