Posting Date is not within your range

lloydsmods

Okay, we've all seen this one before, but before you give up on me and go somewhere else, give me a sec. I got this ticket passed to me by a client. My client is a VAR and their customer is seeing this error. This issue has been going on for two years, I am told. Apparently it works like this:

One person gets the error, then multiple users get it, then nobody can post because of it. The only known workaround is to run Adjust Cost-Item Entries. Once that runs, everyone can post.

I am told they have verified that nobody has invalid posting date ranges. The VAR suggested that the customer change Inventory Setup to Automatic Cost posting at one point but that only made the problem occur more frequently.

Even if the Adjust Cost Item Entries is run the previous evening, users will get the error the next morning. To resolve the problem, they must run it again. It only helps after an error message occurs.

They have debuggered the issue and found the error occurring in Codeunits 21, 90, and 201.

The customer is using NAV 4.0 SP3 with customizations to Jobs.

My client is at a loss and thought that I could put fresh eyes on it, but I cannot reproduce the error with my local copy of the customer database. Anyone ever seen anything like this?

ara3n

std nav doesn't check posting date ranges in CU 90, so it must be a modification.

They should change back automatic adjust cost in Setup. And run it manually. What you are describing is definitely caused by this.
Since it's turned on, if an old entry needs to be adjusted, NAV tries to post adjust it and one user gets the error. Then anybody who is posting will get the error as well.

Are they using User Setup to control posting date ranges or GL setup?
Adjust cost is using GL Setup.

CU5895

IF GLSetup.IsPostingAllowed(ItemLedgEntryPostingDate) THEN
ItemJnlLine."Posting Date" := ItemLedgEntryPostingDate
ELSE
ItemJnlLine."Posting Date" := PostingDateForClosedPeriod;


I suggest to tell them that next time they get the error to call you.

Albertvh

How is the Adjust Cost being run?
Through Nav or Nas?
I would suggest to look at the adjust cost and check to see that the object does not update the user setup table posting dates and then resets it once it is complete.

Hope this helps.

Albert

lloydsmods

Thanks guys. The problem occurs with Adjust Cost-Item Entries being run manually. They changed it to automatic hoping it would help but it made it worse so they switched it back. It appears they are using User Setup date ranges and, yes, they modified CU 90. I will look at the adjust cost code to see if it changes the dates in some way.

David_Singleton

I think you should look more at What ar3an suggests I think he is right (which he normally is). A back dated entry would cause this issue. The reason running adjust cost fixes this, is that it then creates the back dated entry, meaning things can progress.

Fundamentally you need to check why you have so many back dated entries.

Alex_Chow

Change your Allow Posting From date on the General Ledger Setup.

This will address the error. No modifications needed.

lloydsmods

According to the customer the problem occurs daily for multiple users. If they open the range in G/L Setup, how does that work if they use User Setup date ranges?

They do not want, under any circumstances, to open the date range for all users. They understand that if they open the date ranges that the problem is resolved, but they don't want users posting in the wrong fiscal period.

Inventory setup is for Expected Cost Posting to G/L. They run ACIE and Post Inventory Cost to G/L two to three times per week.

Alex_Chow

Correction: The problem occurs daily for different items, not users.

If you change your Automatic Cost Adjustment setting, it will go back and adjust the cost and post it on the date of the outgoing transaction.

If there are no modifications in this area, then I'm pretty sure changing the Allow Posting From on the General Ledger Setup will solve your problem.

From your questions, it sounds like you're pretty new to NAV. Make sure you understand how costing works before you proceed so you can explain it to your customer. My blog actually have a few articles about costing and how it works and what to watch for in case you're interested.

lloydsmods

Not new to NAV, just don't have many customers doing inventory costing, so I'm a little rusty.

Alex_Chow

lloydsmods wrote:

Not new to NAV, just don't have many customers doing inventory costing, so I'm a little rusty.

:shock:

lloydsmods

Okay, let me clarify that...A number of my clients have inventory, but they never ask me about costing and none of my projects are related to costing (aside from reports and such). Obviously if they have inventory, they are doing costing, but this is the first question about inventory costing I've gotten in over two years. I know. I have weird clients.

golfer

Actually I am pretty sure this is a rounding issue. It can occur when a user post a positive transaction in a posting date within the range in user setup, and the transaction applies to a negative stock before the allowed posting date range to update it´s cost. In some cases there could be a small rounding amount that NAV wants to post on the date of the outbound entry (outside the allowed posting date for the user). With Automatic Cost Adjustment set, it of course causes the error when posting the positive transaction (purchase, output or positive adjustment), when ACIE runs manually the same error occurs then.
If I remember correctly this problem was introduced in version 4.0 and was addressed by the Inventory Period functionality in version 5.0. With this functionality the inventory period could be closed and the eventual rounding amount as above will be posted to the first date of an open period instead.

Although the Inventory Period functionality is not present in version 4 as I recall, I hope this information can help you in this case. Otherwise the only solution I can think of is to actually allow the users to post in earlier periods, and that can of course lead to a lot of undesired problems. As David says, focus on why there is negative stock in the first place (which I am guessing is the issue in this case).

EDIT:
I just reproduced in Cronus (ver 2009 R2) and the scenario I described does not have to be just a rounding issue (I was stuck thinking of another scenario but that´s another story), but can be the adjustment cost. Consider you have a negative transaction and negative stock in August, by that time the expected cost was 10. In G/L Setup you allow posting in August as well as September. In September you post a receipt at the cost of 20. This positive transaction causes an adjustment of 10 on the outbound transaction in August, if the user would be allowed to post in August. But if the users allowed range for posting date would be September, the error occurs and this is triggered in CU 21.

If however the G/L Setup would only include September in the scenario, and that would be the same in actual users setup, the adjustment would be posted in September.

Alex_Chow

Thanks. So the conclusion is change your Allow Posting From on the General Ledger Setup.

golfer

Yes, Alex is right (although it could be appropriate to clarify to narrow the range in G/L setup rather than open it up. The posting from in G/L Setup should be the same as defined in the User Setup).

Alex_Chow

golfer wrote:

Yes, Alex is right (although it could be appropriate to clarify to narrow the range in G/L setup rather than open it up. The posting from in G/L Setup should be the same as defined in the User Setup).

I would disagree. The importance of the Allow Posting From in relations to the books is no joke.

The dates defined on the User Setup and the dates defined on the G/L Setup should be 2 different discussions.

Brice

We have had numerous incidents with a variation of this error and it is usually related to a combination of our GL Setup dates, User Dates and/or our Inventory Setup. We normally get past the issue by synching the GL Dates and the User Dates although we can also fix it by changing the Automatic Cost Adjustment flag on our Inventory Setup screen to "Never" - we normally have it set to "Week".

We are now seeing an error with an Inventory Transfer complaining about blocked dimension combinations that are no longer used and are not part of the current transaction - and if I change the Inventory setup flag to "Never" I am able to process the transaction. What is the standard setup for this flag and are there any issues with leaving it set to "Never"?