A little perspective please...

djswim

Before I get really angry about this I thought I'd share my situation here and get some perspective. I'm on a project right now where I'm helping fix a botched implementation. I've seen quite a few of these before, so it takes a lot for me to have a "Whaaaaaaa....?!?" moment, but this is one:

During the migration of the master data, the field that was used as the product group code was migrated to the "Product Group Code" field on the item master. So far so good.

The client, however, needs to do financial analysis by this code, so it was suggested to them that they set up a "Product Line Code" dimension. Again, no problem.

During master record verification, the controller noticed that the "Product Group Code" was filled out everywhere, but that the "Product Line Code" was not. A request was made to copy from PGC to PLC on all the item masters.

Here's where the problem is: it never happened. Now, they have $9mil in inventory transactions (net) that don't have this dimension. Granted, these are all entries that were made in the system the way they should be, and therefore we can use journal entries and NAV's own tools to fix it, but it's still going to be a STUPID amount of work; all due to an oversight that a second year consultant should be able to avoid.

So I have two questions:

1. Besides the obvious (consolidated correction entires out of/into accounts to fix this), any tips?
2. I feel like this falls under the category of "gross negligence"... am I completely off base? There were a minimum of 4 sets of eyes on this from the VAR side and it got completely boffed.

#-o #-o #-o

ara3n

Here's where the problem is: it never happened. Now, they have $9mil in inventory transactions (net) that don't have this dimension. Granted, these are all entries that were made in the system the way they should be, and therefore we can use journal entries and NAV's own tools to fix it, but it's still going to be a STUPID amount of work; all due to an oversight that a second year consultant should be able to avoid.

Well if a request was asked to populate a field and i'm guessing it was a global dim 1 or 2? and it wasn't' done, and client never looked at their financial data to confirm and test this and they did this after go-live?


Migration needs to be tested way ahead of of golive- and data is needs to be reconciled.

Missing a dimension is though is a big one.

How long before client realized that they financial statements didn't bring the data.
And why wasn't Code mandatory setup on GL accounts?

If it's a global dimensions, I would change it to 3rd or forth dimensions.
Write a processing reports to populate the ledger dimensions.

ajhvdb

If it's a global dimensions, I would change it to 3rd or forth dimensions.

May i ask why?

DenSter

djswim wrote:

I feel like this falls under the category of "gross negligence"... am I completely off base?

It is so tempting to scream bloody murder, especially when you inherit a "bad" implementation from someone else. The fact is though that this type of stuff falls between the cracks all the time, and many times it happens with seasoned veterans as well. You've been in go-live situations, you know how stressful that can get. Many times people are more concerned about grand total reconciliation and forget about (some of the) details just to make the deadline.

djswim wrote:

During master record verification, the controller noticed that the "Product Group Code" was filled out everywhere, but that the "Product Line Code" was not. A request was made to copy from PGC to PLC on all the item masters.

So when did this happen? Before go-live? After? We all like to assign blame, and the easiest thing is to blame the partner. The truth of the matter is that the customer is ultimately responsible for verifying the data, not the partner. As much as the consultants should be aware of all the data requirements (by keeping a checklist for instance), the customer needs to take responsibility for this just as much.

I would say this is unfortunate, but it happened, and both parties share the responsibility. From here on out it's either "solve the problem", or "find the culprit".

ara3n

ajhvdb wrote:

If it's a global dimensions, I would change it to 3rd or forth dimensions.

May i ask why?

You would only fix the ledger dim tables and then change it back to global.

djswim

DenSter wrote:

It is so tempting to scream bloody murder, especially when you inherit a "bad" implementation from someone else. The fact is though that this type of stuff falls between the cracks all the time, and many times it happens with seasoned veterans as well. You've been in go-live situations, you know how stressful that can get. Many times people are more concerned about grand total reconciliation and forget about (some of the) details just to make the deadline.

So when did this happen? Before go-live? After? We all like to assign blame, and the easiest thing is to blame the partner. The truth of the matter is that the customer is ultimately responsible for verifying the data, not the partner. As much as the consultants should be aware of all the data requirements (by keeping a checklist for instance), the customer needs to take responsibility for this just as much.

I would say this is unfortunate, but it happened, and both parties share the responsibility. From here on out it's either "solve the problem", or "find the culprit".

I completely understand what you're saying here, and having worked as a partner more years than having been independent, I completely understand. There were mistakes on both sides for absolute certain but ultimately the partner is in business to implement NAV, they're supposed to be the ones to provide expert guidance and in this case I think they failed. In terms of data verification, there are certain things that the partner can't know... Vendor addresses, balances, names, etc... that's 90% customer/10% partner. Having a global product line dimension that is 99% not filled in on items and can be easily confused with Product Group Code? That's where the % responsibility reverses in my mind.

There are also other things that add to my frustrations, primarily the reams of emails they have from the partner explaining things that "Can't be done without modification" which I was doing in their test environment days after I arrived. This is what happens when a fixed price bid goes over budget, the partner often will lose interest in the client because they're no longer profitable, and send in the C-team to take care of the rest and move their more experienced resources to bigger and/or more profitable endeavors. I'm not talking about all partners of course, but in this case I think that's what happened.

Like I said, there were mistakes made here too... going live too soon being one of them, but it seems like some really easy things got missed. I also know a lot of the people that work for this partner, and they absolutely positively switched out their good people after crossing the profitability threshold... No one knows what the last consultant did for the last week he was here, if that gives you any idea #-o

My focus now is on solving the problem of course, but a little healthy ranting never hurt anyone... I know better than to name names or anything like that. We've all made mistakes I know, it just seems like the frequency/intensity of the mistakes in this implementation were well above the average and I wanted to get thoughts from the community on if I was being completely unreasonable in feeling like I do. I appreciate the feedback.

David_Singleton

djswim wrote:

Before I get really angry about this I thought I'd share my situation here and get some perspective. I'm on a project right now where I'm helping fix a botched implementation. I've seen quite a few of these before, so it takes a lot for me to have a "Whaaaaaaa....?!?" moment, but this is one:

Wow, I think you need to come with me and see some of the stuff I have to fix. An issue as minor as a missing dimension, probably wouldn't make the top 50 list of issues in the majority of recoveries I have worked on. #-o

I can show you things that I am pretty sure would make you go gray over night. :shock:

I know it looks bad, but as Rashed points out, it is at least fixable.

djswim

I've seen worse, I understand what you're saying

I was just a little taken aback at what a simple thing it is... anyone with even a basic checklist should have caught this.

djswim

ara3n wrote:

ajhvdb wrote:

If it's a global dimensions, I would change it to 3rd or forth dimensions.

May i ask why?

You would only fix the ledger dim tables and then change it back to global.

Could you explain this a bit more? I'm not quite understanding how changing it to a 3rd/4th dim and then back again will do anything...

ara3n

Well I'll give an example.

Customer wanted to combine two dimensions values for Global Dim 1. Let's Global Dim 1. As Department. Depart had Values A,B,C.

And they wanted to combine B and C. C No longer existed and they wanted all their historical data to represent as B.


Global Dim1 is in a lot of tables. Master tables, Journals. Orders, order details. Production orders, Posted documents, GL Entry, and Subledgers.

So in order to write a routine to update all the history, it was easier to change it to none global dimensions. You are left with a lot less tables. 4 or 5 tables where the data resides, so writing the routine to change C to B is much easier and faster.

Then you make Department back a GLobal dimensions and Standard Nav moves the data back to all the tables. This is available in GLSetup.

djswim

So you're suggesting that I:

1. "Change Global Dimensions" function in the GL Setup
2. Delete "Prod Line"
3. Add "Prod Line" to Dim 3 or 4
4. ????
5. Delete "Prod Line from Dim 3 or 4
6. Add "Prod Line" back to my Global Dim 1 field

Could you explain the ???? part?

David_Singleton

djswim wrote:

ara3n wrote:

ajhvdb wrote:

If it's a global dimensions, I would change it to 3rd or forth dimensions.

May i ask why?

You would only fix the ledger dim tables and then change it back to global.

Could you explain this a bit more? I'm not quite understanding how changing it to a 3rd/4th dim and then back again will do anything...

because changing or updating data in the global dimensions is quite complex and very slow. Its much faster and easier to do it in a different dimension, and then move it back.

djswim

But if I update the value of the default dimension in an Item, it doesn't go change anything for me... all those transactions are still missing their data. Honestly if there's a way for NAV to go back to all those transactions and update with the new Dimension information on all those transactions I don't care how slow it is, I can do it overnight!

It's late and I've been looking at code almost all day (which I'm not used to)... in order for me to understand this I'm going to need a real step-by-step.

Let me restate the problem, all the G/L entries and Item Ledger entries are missing Glob. Dim. 2 data because it wasn't filled in. It sounds like you're telling me there's a way to do this automatically. Even if it's slow, I'd do it that way to know I caught everything.

ara3n

The ???? part is
You need to populate the following tables

355 Ledger Entry Dimension
356 Journal Line Dimension
357 Document Dimension
358 Production Document Dimension
359 Posted Document Dimension



If you are using any analysis views. delete them and recreate them.

ara3n

The Revenue entries for Sale won't be split by product line, so you have to write an additional report to create journal entries to reverse the original entry and create based on product line.

David_Singleton

djswim wrote:

...

I don't care how slow it is, I can do it overnight!

It's late and I've been looking at code almost all day (which I'm not used to)... in order for me to understand this I'm going to need a real step-by-step.

Sorry to be blunt here, but I assumed from your posts that you had extensive experience in both development and analysis, sorry about that assumption.

This is not something that can be explained step by step, all you can really get here is the general idea. The reason is that every company uses dimensions differently, so you need to analyze how they need to dimensionalize their data, then write the code that will do this. By automatic, I meant that you can write a function/batch routine to do this. Not that there was a function in Nav that will do it for you.

The point (I think) Rashed was making, is that the code is much much simpler on Dim 3 than on dim 4, which is also my experience.

But maybe best is to sit with your lead developer, and analyze this from both the business and the technical side together.

As an FYI, I have done this many times for various clients, but in every case, the code required was different, and virtually unusable for the next client. This a major (actually possibly the ONLY) good feature of dimensions, is their flexibility.

Personally though I think if I ever met the developer that wrote the Dimension functionality in NAV, I would be in too minds whether to strange them, or to thank them for all the work they have made for me over the years.

DenSter

djswim wrote:

anyone with even a basic checklist should have caught this.

ehm..... I mean this in the most respectful way possible djswim, and I do not mean to be offensive.... but the same type of statement could be made about writing code, something along the lines of "anyone that writes any code at all should at least know how to use the basic C/AL keywords like GET"

If this post is related to your question about how to write the C/AL code, please follow your own advice and get some help from a NAV developer. You figure out WHAT needs to be done, and let the developer take care of HOW it is done.

You can always sit with them and learn from it, but I think in this situation the risk of screwing something up is too great to experiment writing C/AL code.

djswim

I understand your point, but the fundamental difference is that I know what I don't know and am willing to ask for help as opposed to letting a client go-live without complete data.

Like I think a lot of people were discussing in another thread, I'm not pretending to know everything, that's why I'm on here. And you can bet that anything I do to fix this is going to be much more completely tested than what they went live with

DenSter

Point taken

As to "letting a client go-live without complete data" we can argue whose responsibility that is. Without having been part of the implementation, and without been at go-live there is no way for me to know how much of an issue this product hierarchy was during implementation.We don't know if they even tested it then, let alone during go-live. Maybe they tested it during implementation, and at that point the consultant assumed (based on competency of the CFO) that when he asked during go-live "is that financial statement OK?" and the CFO said "tied it to the penny!!" that this would assumed to be including the product hierarchy.

I'm starting to repeat myself though (which I've been known to do ), so there...

djswim

David Singleton wrote:

Sorry to be blunt here, but I assumed from your posts that you had extensive experience in both development and analysis, sorry about that assumption.

Well, I wouldn't say I have "extensive" experience in development, but I used to do it quite a bit... now I'm rusty (as you can tell from my other posts). As far as analysis, I do have extensive experience with that... I misunderstood some of the posts to mean that a small change on the front end would make NAV go correct all the ledger entries and the G/L on its own. I had never heard of this, so clearly I was excited.

I know what I need to do here, I was just making sure that there wasn't a stupidly easy way to get it done

djswim

I hate to ressurect this evil topic, but it turns out my plans have been thwarted by my license, so I have almost everything figured out but have one more question:

Assuming I get the Value Entry and Item Ledger updated with these dimension codes, how do I then get the G/L entries updated?

Thank you!

David_Singleton

djswim wrote:

I hate to ressurect this evil topic, but it turns out my plans have been thwarted by my license, so I have almost everything figured out but have one more question:

Assuming I get the Value Entry and Item Ledger updated with these dimension codes, how do I then get the G/L entries updated?

Thank you!

I would imagine that what ever method you used to twart the licensing issues to update Value And Item Ledger entries would be the same for the General Ledger.

djswim

Preferably I'd rather not thwart the license... can a Solution Developer license or a Partner license change the Dimension Code on a G/L entry?

kine

Of course, SD or Partner License (which is SD license) allows you to do what you want with the data - and this is why the granule is so expansive and why Partner must have big know how to not mess data up...

djswim

Thank you!