job queue and inventory item cost post routine changes

Reading the changes made in Micrososft dynamics Nav 5.0 document I have a two initial questions

Job Queue – replaces job scheduler

Is this going to be something the end user can setup, or will it now require the solution center to program it. As is the case with the NAS now, because the codeunit has to be modified to run jobs…


A50) Revised posting rules for inventory cost posting to G/L

This says it now will require closed periods be opened so the g/l entries can be posted to closed period.

What if Generally acceptable accounting principles, and bank requirements say you can’t post items to closed periods. Do you now have to open the period, run the routine, and make adjusting journal entries to reverse the entries just made by the “Post cost to g/l batch job”

I would guess that to be just a Danglish translation error. As you say there is no way that this would be acceptable accounting poilcy anywhere. (Well anywhere that I know of). My read on this is that there was a bug that allowed you to post into closed periods, and that bug has now been fixed.

Which document did you read that from, it looks like the change log. Could you upload the file here:

I would like to read the whole paragraph. By the way, this is completely contrary to what they were telling us in then MVP 5.0 sessions.

It is from the document I downloaded from this forum

page 21

A50) Revised Posting Rules for Inventory Cost Posting to G/L


Previously, value entries in the inventory ledger with posting dates before the Allow Posting From date were posted to G/L with the date the user entered in the Closed Period Entry Posting Date field. This made it difficult to analyze and compare the inventory ledger and G/L per period.

The Post Cost to G/L batch job is now blocked if one or more value entries have posting dates outside the allowed posting period. This ensures that value entries with posting dates before the Allow Posting From date are posted to G/L with their proper date.

In order to complete the batch job, users must enable the posting of those old value entries by temporarily changing or removing the date in the Allow Posting To field in order to open G/L for posting. The Closed Period Entry Posting Date field is removed from the request form of the Post Inventory Cost to G/L batch job.

This redesign has been implemented.

Thanks, very usefull. Maybe we need to have front page posting when something new is uploaded.

Anyway this is only for Value entries. So it would not be a problem, you just make sure that posting cost to the G/L is done before the Period is closed. ANy futhre adjustments will be made by creating new Value Entries, and those new entries will be with todays date.

At first it did look very strange, but after 3 or 4 reads, i think it makes sense. It does mean an extra check before closing the period though.

What did you have in mind?

Not sure really. Last night I down loaded a few files, and did not realize just how much more there was there. I think it would be nice to have some sort of a simple list on the front page indicating that there are new downloads available. Or maybe have them show in the forums much like new threads do. On that matter, maybe blogs also.

I know that we should be using RSS, but it just so much easier if its all in a web page.

I think this is going to be a big problem, for example today is march 31, and I have just closed February 2007, (in reality I closed February weeks ago) produced my financial statements and sent reports to the bank. I used Nav 4.0 report to account for items recieved not invoice and made accrual entries for them.

Next week, I get a vendor invoice for an item received back in February, not uncommon at all to receive invoices this long after receipt of goods.

I post the invoice and it closes the purchase order. Now when I run the adjust item cost routine it is going to make entries for the item, it is going to try to make them in February to match the period the item was received into inventory. Which is the closed period, the whole batch job will stop and tell me I have to reopen February, allow the g/l entry to post.

Am I reading it wrong ?

No you are not reading wrong, but you are maybe leaving out that the Value Ledger will have the same posting date as the Purchase invoice, which will be in April. So when you run the batch, the posting of the adjustment will be made into April.

BUT where it will cause a problem, is if you posted the purchase invoice back in February, BUT a/ you don’t have auto post to g/l switched on AND you forgot to run the Post Inventory costing to G?L routine before closing the month. I can see this happening but not all that often.

The key is to remember that adjustments to the Item Ledger Entry are made by creating NEW value entries, its not done by editing an existing entry.

Not allowing posting G/L entries to closed periods I don’t think is a problem. I consider a safe way of posting. The user must know what adjust cost is doing. It’s not uncommon to a user close a period and start complaining about entries posted to closed periods. Now the user must do some steps to allow that. It’s just a protection to users.

You don’t understand what my concern was, the current routine would not post in a closed period instead you entered a date you in an open period you wanted entries to be made for anything that applied to a closed period. This new version, does away with that, and forces you to open the previously closed period to allow the routine to post in that period.

My routine, was to select a date in an open period, where our company was closed for business like a Sunday, any entries that would apply to a closed period would post to this date, and I could see what they where. Now, if I have any entries like that, I will have to open the closed period, and just let the entries post, then figure out what they were, make reversing entries, so that my closed period doesn’t change for bank and audit reasons.

True, if I always run everything just right, and post everything in the correct period, never making a mistake, then this won’t be a problem. My concern is this is the real world, with real users who make mistakes. And this is going to cause problems for a lot of people.