DynamicsNAV posting date is not with in your range

Product Version 2015

When posting Sales Invoice i get this error “posting date is not with in your range”.

*User posting date set 08/01/16…08/31/16

*G/L Setup date set 09/01/16…09/30/16

*Invoice Posting date 08/20/16

Please i tried to look into this issue and no solution. and i noticed this issue mostly surfacing at the end of the month after adjust cost batch job run.

I didn’t field invoice date 082016 (08/20/16?) in g/l setup or user setup.
can you check again please.
please activate the debugger to check exact place of error and values available there.

Hi Alemayehu,

The posting date rules are that if the user has an individual posting dates setup, then that “wins”.

But in your case August 20th. is not within any of the allowed ranges.

So what is your question?

Read My Lips, Erik

Sorry Erik Typo error.I corrected the error in the original post like this
*User posting date set 08/01/16…08/31/16

*G/L Setup date set 09/01/16…09/30/16

*Invoice Posting date 08/20/16

Still cannot the invoice

Ok, then you’r right, then it looks like something is wrong.
And I assume that the user who gets this error is the user with the date setup?

Then I would follow Mohana’s suggestion. Run it with the debugger activated, then it will stop exactly where the error occurs, and here you can see why it didn’t check the users date setup.

Thanks Erik
I will try that .

Hello everybody
I followed your suggestion and the debugger traced the error on Code unit 21
CheckAllowedPostingDate(ItemJnlLine : Record “Item Journal Line”)
WITH ItemJnlLine DO BEGIN
IF (AllowPostingFrom = 0D) AND (AllowPostingTo = 0D) THEN BEGIN
InvtSetup.GET;
GLSetup.GET;
IF USERID <> ‘’ THEN
IF UserSetup.GET(USERID) THEN BEGIN
AllowPostingFrom := UserSetup.“Allow Posting From”;
AllowPostingTo := UserSetup.“Allow Posting To”;
END;
IF (AllowPostingFrom = 0D) AND (AllowPostingTo = 0D) THEN BEGIN
AllowPostingFrom := GLSetup.“Allow Posting From”;
AllowPostingTo := GLSetup.“Allow Posting To”;
END;
IF AllowPostingTo = 0D THEN
AllowPostingTo := 31129999D;
END;
IF (“Posting Date” < AllowPostingFrom) OR (“Posting Date” > AllowPostingTo) THEN
FIELDERROR(“Posting Date”,Text001)//Right here
END;

What would be the case since my Posting date on the invoice falls between the date range given for the user??

Please place your cursor on Posting date field, AllowPostingFrom and AllowPostingTo in above debugger. you will see the dates.

Is Automatic cost posting is ticked in Inventory setup? If Yes then try to remove the tick and post the transactions
As it may be system is trying to post the transaction and adjusting the cost
Hope this helps

I captured posting dates ,allowed to and allowed from dates from the debugger.take a look at it.

https://drive.google.com/open?id=0B9ygEdPPOckpc1pOWlVnQjN4SjQ

hope you understand the issue now.
AllowPostingFrom is 08/01/16
AllowPostingTo is 08/31/16
Posting Date is 09/01/16 which is not in above range

yes that’s why i was confused i can share you the posting date on the invoice it is 08/19/16.
it is odd.

Hi Amol
I tried your suggestion and no change.But i am sure when it is trying to post the invoice i see it is bringing the “adjusting value entries Windows” this means it is running adjust cost batch job.If i am not mistaken.

If it is adjusting inventory then you need to adjust the posting date range given to user

I think you are right the system is trying to adjust inventory during the posting of an invoice and when it tries that it is limited by the user level posting date range.Due to that i have to allow the user posting date further back that he/she supposed to be allowed and where is the posting date limitation use here.It is confused me for long time i hope this thing is a bug in the system and MS has a fix for it.Thank a lot

I have been on many NAV projects where one of the required changes was that absolutely no posts could be done in the old period, after the month was closed. So many you have a similar in your setup?
To what I can see, then NAV has no error in this area. Tried in my own system, works fine here. It’s doing it exactly the way it was designed.
So my guess that the standard code has been changed. Could that be the case?