Adjust Cost redesign/optimise

generic

Hello.

Adjust cost in Nav creates the buffer for entries to post. Actually the buffer is temporary Value entry record.

And then it loops through and creates an Item journal and posts the Item journal which then creates the value entries.


Creating item journal and then posting it is all good practice, but it does not make sense when you are running adjust cost.
I believe adjust should create the value Entry. Do all the testing that involves in posting and then insert the value entry.

This will improve the performance of adjust cost by a lot. And simplify the CU 22.

kine

Main precondition is: every entry is created through - journal line -> posting process. This is NAV core functionality which allows the flexibility we have in NAV. Some ways around can mean another problems and inconsistency.

generic

That's fine they would need to create a Value Journal Line -> and call a separate CU to Post.

The problem is that there are way to many fields on Item Journal, and CU 22 is getting to a point of not being managed.


Most people don't know what all the fields mean in Value entry. There are too many fields that service such specific purpose and there is no way to test for it.

So the idea for being flexible is not true in this case. If you are making any costing modification, I would say good luck.
Most MS consultants don't know it.

A few weeks ago MS had a costing webcast in 5.0 and 2009, and I asked a simple question. When do Valuation Date and Posting Date differ in Value Entry. And his answer was, "I've seen it when you go negative" HA.
The simple answer is when you ship in one day, and invoice on another, the Invoice entries in Value entry will have a different Posting Date compared to Valuation Date. The Valuation Date will equal the posting date of Shipment.

Alex_Chow

generic wrote:

The simple answer is when you in one day, and invoice on another, the Invoice entries in Value entry will have a different Posting Date and a different Valuation Date.

Simpler answer is Valuation Date is the item ledger date, and the value entry is the costing date.

If the Microsoft person did a search on Mibuso, he/she would've know the answer.

Alex_Chow

Generic, have you actually tested this out to see the performance gained? The posting routines are done to verify the business rules and ensure errors are caught before commiting to the ledgers.

If you do eliminate the journal -> ledger process, you would still need to put somewhere in your new posting routine to verify the business rules and checking errors.

Personally, I don't see much performance gained just removing the journals out of the picture. Just because people (MS consultants in this case) don't understand what the fields mean, doesn't mean it's not important.

Furthermore, the adjust cost process has already been enhanced by the introduction of the Inventory Periods. It allows you to adjust cost by period, instead of recalcuating everything since the beginning of time.

generic

First it does not make sense to create value entries through an Item journal. Item journal should only be used if you actually created Item Ledger. IF the item Ledger has a cost/price associated/ you can pass fill them on the journal. CU 22 then create Value Journal (New table) and Post that.


If you are posting Item charges or adjust cost. or Revaluation journal or invoicing of a shipment/receipt, You should be using Value Journal.


It's not just about performance, but flexibility and easy of understanding the code.

They are not making big changes mainly of legacy code. (pleasing ISV)

Alex_Chow

generic wrote:

If you are posting Item charges or adjust cost. or Revaluation journal or invoicing of a shipment/receipt, You should be using Value Journal.

:?: What's a Value Journal?

I understand your point. Making code easier is always good, we can certain make a case that certain part of NAV coding is over complicated i.e. Item Tracking.

However, I don't believe the adjust cost process can be changed without fundamental changes to how NAV works. The reason why NAV needs to use item journal is so the checking and posting process is in a central place. This also benefits developers when they need to do programming dealing with costing of item entries. They know that this is the one area they only need to consider, not a million different places.

Creating separate processes that does the similiar things in the name of simplicity will only complicate things down the line.

generic

You would still have a central place to post through. All Value Entries would go through one posting process (Value Journal).

Value Journal would be a new table that you would post through to create value entries.

CU 22 would create a value journal to create value entries.

The code is already complex for creation of value entries, and not flexible to make any modifications.

Alex_Chow

I guess we would need to see exactly how you propose to make this change. I don't think with the introduction of Value Journal will make it any easier, seems to be that this Value Journal operates the same way as the item journal.

Maybe it's just me, but I don't think the code is so inflexible that it cannot be modified.

Complexity is relative. There are many levels of developers, some people think that creating a new field and adding to the form is the most complex thing in the world. As such, some people think modifying posting routines is a simple process (although time consuming).

Some people believe they're pretty good developers, but compared to kine and kriki, they're just amatures.

generic

OK, so you want me to explain in relative terms how complex it is?

Well it's complex enough that MS has been working on it for 15-20 years and still hasn't got it right.

in 5.0 or 5.0 sp1 or in 2009

Just try to do a invoice with charge item for a Drop shipment PO for an average cost item.
Drop shipment are not part of Costing Period calculation. Navision excludes the sales side of the charge item, but Purchase side of the charge item is included in the Costing Period.

Alex_Chow

What I'm saying is, how complex it is is relative.

NAV costing is correct.

Why do you think that NAV haven't gotten costing right? Give me some examples.
Why should drop shipments be part of average cost calculation since the item never hits your warehouse?
Why would the allocation of the item charge on the sales affect cost of the item?

These are probably all separate questions unrelated to the topic. Post whatever you think is incorrect in NAV costing as a separate topic so others can search on it and we'll get them addressed one by one.

generic

Alex Chow wrote:

What I'm saying is, how complex it is is relative.

NAV costing is correct.

Why do you think that NAV haven't gotten costing right? Give me some examples.

Did you even read my response. I said that NAV adds the item charge part of the cost.

Why should drop shipments be part of average cost calculation since the item never hits your warehouse?

It shouldn't but NAV does it. I feel like you don't read anything I write and you just march with BS responses.

Why would the allocation of the item charge on the sales affect cost of the item?

The Cost of an item at the end of a day after Adjust cost has run, is Sum of value Entry
"Cost amount (Actual)" +"Cost amount (Expected)" / sum ("Item Ledger Entry Quantity").
I'm simplifying this and pretend it's only the first day.
So it's all value entries including Sales.

These are probably all separate questions unrelated to the topic. Post whatever you think is incorrect in NAV costing as a separate topic so others can search on it and we'll get them addressed one by one.

As I stated before. Nav screws up the cost if you do an item charge to a drop shipment PO.

Alex_Chow

<EDIT>

generic

I have done it in Cronus. Here is the screen shot.

generic

saw your response before the edit.

That was very naughty.

Alex_Chow

If you drill down on the ledger entries, the cost being applied and the G/L postings are correct. So the financials and the inventory valuations are all correct.

But it seems that subsequent transactions are based on the new average cost as well. :oops:

I was wrong.. :oops:

Good catch, did you report this to Microsoft?

Alex_Chow

generic wrote:

saw your response before the edit.

That was very naughty.

Indeed, but I edited the comments because I thought my response was rude. Not because of anything else.

generic

I was just joking.

I think I will report it.

The problem is that the charge item value entry does not have the drop shipment flag checked.


There are so many fields in value entry btw that do specific thing, and one field is not inserted correctly, your cost is screwed.

One more thing that they can simplify and prevent, if they had a Value Journal that would enforce all the rules, but unfortunately there is no testing/ validation when value entries are posted/created.

generic

I would even settle for a function in 22 that would be called something like TestValueEntry

And it would test all the rules, to make sure the value entry is correctly created before it's posted.

In order to implement that, They would have to create an option type field with all the different type of Value Entries.

Now wouldn't that be nice.

Alex_Chow

generic wrote:

I was just joking.

I think I will report it.

The problem is that the charge item value entry does not have the drop shipment flag checked.


There are so many fields in value entry btw that do specific thing, and one field is not inserted correctly, your cost is screwed.

One more thing that they can simplify and prevent, if they had a Value Journal that would enforce all the rules, but unfortunately there is no testing/ validation when value entries are posted/created.

Yeah, you should definately report this. This is a serious problem with Average Cost. I didn't even realize this until you've shown me the light. I spent all last night going through our client databases to see which customers are affected. I'm surprised our clients didn't catch this when they evaluate their inventory.

Will be a rough day today...

generic

Alex Chow wrote:

Furthermore, the adjust cost process has already been enhanced by the introduction of the Inventory Periods. It allows you to adjust cost by period, instead of recalcuating everything since the beginning of time.

Could you show me the code for this?

Looking at adjust cost. It simply uses Inventory period for posting date when you close a period.
For Average Costing you need to look from beginning of time. Unless you store the Cost for the Costing Period in a table. Nav doesn't store it anywhere, so it has to calculate from beginning of time.

Alex_Chow

Hmm... I can't...

The closest thing I got was the AvgValueEntriesToAdjustExist function. I got this impression from the introduction at a Microsoft roadshow previewing NAV 5.0. The inventory period was explained as a way to control how far back cost are considered when running the adjust cost process.

I had assumed they meant that when you run adjust cost, it would be from the inventory period forward. I never bothered to check the code. Now looking at the help, it just won't allow you to post into prior periods so historical costs are not changed...

generic

Right it is just used to control the dates. They should store the Average period Amount and $ in the "Avg. Cost Adjmt. Entry Point" table
and that way they don't have to calculate average cost from beginning of time.

If somebody posts in previous period, they right now NAV unflags the "cost is adjusted" field.
They could zero the Avg Qty and and Avg "Cost Amount" (new fields) as well.

This way they don't have to calculate back from beginning of time.


But what do I know. At most of my post I get barked at.

Alex_Chow

generic wrote:

But what do I know. At most of my post I get barked at.

The only thing you can do is recommend the changes directly to Microsoft.

generic

recommendation to MS? Ha

There are hundreds of post in here about things users wants in NAV, and I'm sure MS has read them.

The way I see it, anything suggested to them, they look at it this way.

1. Is there a vertical solution out there? IF yes ignore the suggestion.
2. would we loose sells without the feature? If no ignore the suggestion.
3. Does it complicate NAV? If yes ignore suggestion.
4. would 50K companies out there would use the feature? If no ignore suggestion.

Alex_Chow

generic wrote:

recommendation to MS? Ha

There are hundreds of post in here about things users wants in NAV, and I'm sure MS has read them.

The way I see it, anything suggested to them, they look at it this way.

1. Is there a vertical solution out there? IF yes ignore the suggestion.
2. would we loose sells without the feature? If no ignore the suggestion.
3. Does it complicate NAV? If yes ignore suggestion.
4. would 50K companies out there would use the feature? If no ignore suggestion.

Well, you won't know if you try. For serious bugs like the one you pointed out, they should address it since it undermines the integrity of the system.

generic

I tried to find out where to report, but I can't find anything on partner source. I've given up.

DenSter

You can provide feedback on Connect, and also in the 'official' newsgroup (follow the links).

generic

And to report a bug?

kine

You need to access into Partnersource and in section support you can create new support incident...

DenSter

generic wrote:

And to report a bug?

You don't think posting a bug is providing feedback?