Allowable Posting Dates Error in Nav 4 vers SP2 on SQL 2000

Hi Forum, can anyone shed light on this problem I’m having with a client. Users are getting the error message “Posting date is not within your range of allowed posting dates” when trying to recieve Orders that have Order Date, Expected Receipt Date, Posting/Tax Point Date and Document Date all set to 04/01/07. The General Ledger Setup has Allow From of 27/11/07 and Allow To of 31/12/07. The User Setup in all cases has Allow From of 01/01/07 and Allow To of 31/12/07. What makes it stranger is I have the same User Setup but I can post them. Please can anyone advise. Thanks

Not trying to sound smart but are the dates you listed above correct? You have 27/11/07 and that would still be future date. I’ve had the same problem with a simple oversight. Maybe only the month and day were filled in a Nav auto filled the current year?

It might not be looking at either date. I would use the debugger to find out which field it is looking at.

it does look as if someone put in 1127 while in jan not thinking about the year.
It’s not completely undocumented

Hi All, sorry that was a typo error, it should have read 27/11/06. As for putting the debugger on, the problem there is it doesn’t happen to me but happens the other users and yet I am governed by the same controls. I would have to go to the clients site and run the debugger on a users machine.

in standard application that control is done in codeunit 11 by function DateNotAllowed. Is that function customized?

Hi Patty, I have just been looking at CodeUnit 11 and no it has not been customised. I even compared it to a different Navision version (3.70) CU 11 to see if there was a bug in the code.

What has made this problem even more strange is…the user can now post IF in User Setup his Allow Posting From is moved back into last year. So instead of his Allow Posting From being 01/01/07 and Allow To being 31/12/07 it is now Allow From 30/10/07 and Allow To 31/12/07 he can post. The General Ledger Setup is still Allow From 27/11/06 and Allow To 31/12/07.

They only have 2 years defined in their Calendar and both are still open and these are 01/01/06 to C31/12/06 and 01/01/07 to C31/12/07.

Do you have any thoughts…Paul

It was actually a bug in table 99000757…Paul

In standard, or was it customized?

Hi David, it was standard. The thing is, I cant see why changing code in this table should solve the problem as there was nothing in the table to start with, do want me to paste the code change into this thread?..Paul

Yes please,

this looks like something that might bite more of us later.

Hi David, see copy and paste below.Paul

Table 99000757, CheckRedundancy function

Old code:

CalendarEntry.SETRANGE(Date, Date);

CalendarEntry.SETRANGE(“Starting Time”,0T,“Ending Time” - 1); CalendarEntry.SETFILTER(“Ending Time”,’%1…%2|%3’,“Starting Time” + 1,235959T,000000T); …

New code:

CalendarEntry.SETRANGE(Date, Date);

CalendarEntry.SETFILTER(“Starting Time”,’<%1’,“Ending Time”); CalendarEntry.SETFILTER(“Ending Time”,’>%1|%2’,“Starting Time”,000000T);

[8-)] table 99000757 contains the calendar for Work Center and Machine Center, I cannot understand how this could impact posting of receipt … unless is a subcontractor order … [8-)]

Also, the error message coming from that function is different from the one you wrote:

“There is redundancy in %1 %2s calendar. From %3 to %4. Conflicting time from %5 to %6.”

anyway this is the code from sp3 and is equal to your new code:

CalendarEntry.SETRANGE(“Capacity Type”,“Capacity Type”);
CalendarEntry.SETRANGE(Date, Date);
CalendarEntry.SETFILTER(“Starting Time”,’<%1’,“Ending Time”);
CalendarEntry.SETFILTER(“Ending Time”,’>%1|%2’,“Starting Time”,000000T);

Hi Patty, nor can I but the client says he nolonger has the problem…Paul

Hi All, as suspected, this did not resolve the problem as it has returned. Does anyone know if SQL could cause the problem as all users were re-sync’d last Friday? Paul

I think you can probably eliminate SQL, but now I have said that and not being technical it is probably SQL[:D]. The rights to posting come from the user dates and then the company info. You would get a permission error if this were the case not a date allowed posting error.

Can you login remotely as the user with debugger on? I know you are both governed by teh same controls, but clearly there are differences in the control!

Hi Steve, I can login remotely BUT they wont let me have his password as they use Windows Logins. However I think it might be to do with the fact that they have Adjust Costs set to Always and the routine is adjusting entries where the date is not within Roys range. Have emailed the FD and asked him to blank out or extend his dates and run the Adjust Costs routine and see if this eliminates the problem. Other option would be to set the Adjust Costs to Never I suppose. Havent forgotten the beer but dont get over to Eastleigh too often…Paul

I don’t think Adjust Cost would be the reason, since adjust costs normally posts the same date as the Item Ledger entry, which would be the posting date on the document. Though anything is possible. It could be rounding on additional currency, for example.

My first step would be to find a document that gives the error, then log in as SUPER, and post the document, and then check EVERY new entry created. Do this by going to File Database Information, copy to excel, before and after posting, and then compare to see what was created. Then check dates on all created records.

There are two other areas I can see as problems.

1/ Expected Cost posting. This can do reversals back dated in some cases.

2/ Back to the time issue. Manufacturing used Datetime, so you could be in a scneario where you have a bad calendar set up, and the filter on TIME is finding the wrong calendar, and thus the wrong date. This date will be passed to the GL psoting, and thus the error. This may be related to the Auto Cost posting, but it would really be just a side effect.

How about taking remote control of the users sesssion?