Inconsistent dimension values

seckpin

Dear guru,

We have recently found out some errors in the posted entries for our system (NAV 4). The dimension value in the GL Entry (Shortcut Dimensions for the globals) is different from the one stored in the Ledger Entry Dimension.

After some investigation on our end, we realised that the error originated from the sales invoices, which had different dimension values between the Sales Header/Line and Document Dimension. The sales invoices are created through a dataport created by our vendor.

However, when we highlighted the issue to the vendor, they claimed that the issue was CAUSED by "changing of design without proper testing". In their dataport, they had set the default dimension value posting to "Same Code" in Customer Card, and we changed it to "Code Mandatory". They claimed that the dataport was designed only to handle "Same Code" whereby a checking will be in place to prevent inconsistent dimension values to be posted. By changing it to "Code Mandatory", the checking is removed and hence the inconsistent dimensions can be posted through. They claimed that if we now want the dataport to allow "Code Mandatory", it involves design change to the dataport.

Our point of view is that value posting setting is only checking the business rule for the transactions against the master data (e.g. a customer must have certain dimension), and it is not for checking the data consistency between two linked tables. Regardless of the setting of value posting, the inconsistency between the "pre-posting data", i.e. sales header/line vs. document dimension, should not have even existed in the first place. Proper coding of the dataport would not even have such situation, because data integrity and consistency should always be maintained in any database system. Hence the root cause is not about the setting of the standard feature of value posting but improper coding in the dataport that allows such inconsistency to exist.

What we found puzzling is that why NAV actually allows inconsistent dimension values to be posted through. Shouldn't this be handled in the posting routine to prevent such inconsistency? Is this a known issue with a hotfix?

Thanks in advance for your input.

jannestig

Its,s not a system issue really its the way you enforce the business rules and the coding,

If you create the sales header with dimension X which is carried through to the lines with whatever particular dimension items may carry with it.

Sounds like you haven't setup dimension posting rules to the GL so it only allows Dimension A and b but not X etc

Your vendor sounds pathetic not to have allowed different Dimensions coming in due to posting rules, i would have thought that unless dimensions come in with the import the system would have created and assigned the dimensions from the customer to the line straight away ?

But i haven't finished my first coffe yet =;

matttrax

Unless I misunderstand, this is what it sounds like they did.

Imported some data and VALIDATED the dimensions on the header.
Imported some data on the lines which was VALIDATED and thus filled in the dimensions on the lines.
Changed the dimensions on the line using a := instead of a VALIDATE.

I used to do this when I was starting out. Common mistake, but should be fixed for free.

Also your partner should be able to give you a document that you signed off on stating that you only expected it to work with Same Code or something similar. If the developer made an assumption based on something that was not in the statement of work then that's their problem. Goes both ways, though.

seckpin

Actually what the vendor wrote in their dataport code is like this:
- create the sales header and line using the dimension passed in from the source file (without validation on fields)
- then create the document dimension with reference to the default dimension on the customer card (without validation too)

Apparently, the dataport is assuming that the source file will NEVER pass in a dimension with different value than that on the customer card's default dimension. They claimed that this is the so-called "design" that was agreed upon. There is no technical specs or design document to prove if this is true or not, as they simply do not produce these documents.

However, we feel that what went wrong is not the design per se but the coding and logic:
- why grab the dimension from two different sources for sales invoice and document dimension? It should both come from customer card or the source file, and not one get from source file and the other from customer card
- why there is no validation at all in all the coding? If there is, even if the sources are different, standard NAV validation will kick in to ensure there will never be inconsistency between sales header/line table and document dimension table.

It doesn't matter whether it is "same code" or "code mandatory" if the codes are properly written. The dataport should never create data inconsistency between tables in the first place.

Anyway, we will have to sort this out with the vendor, and it is not easy to get the message across, as they kept on insisting it is about "design". It gets tiring. Sometimes i just wonder if anyone else is having as much problems with their vendor as us.

Thank you all for the comments.

idiot

seckpin wrote:

...
However, we feel that what went wrong is not the design per se but the coding and logic:
- why grab the dimension from two different sources for sales invoice and document dimension? It should both come from customer card or the source file, and not one get from source file and the other from customer card

This is quite vague, depends on what was the initial agreement with the vendor.

seckpin wrote:

- why there is no validation at all in all the coding? If there is, even if the sources are different, standard NAV validation will kick in to ensure there will never be inconsistency between sales header/line table and document dimension table.

Validation could mean taking the default value, or produce an error. What validation did you agree with the vendor?

seckpin wrote:

It doesn't matter whether it is "same code" or "code mandatory" if the codes are properly written. The dataport should never create data inconsistency between tables in the first place.

Dataport, as the name implies, is for import or export of data. Data can be amended after importing, before posting. The posting routine is where the checking for consistency should take place.

seckpin wrote:

Anyway, we will have to sort this out with the vendor, and it is not easy to get the message across, as they kept on insisting it is about "design". It gets tiring. Sometimes i just wonder if anyone else is having as much problems with their vendor as us.

You'll be surprised at the problems others are facing with vendors, or vendors are facing with customers. Sit down with the vendor & reflect on what the exact requirements were, what were changed, etc why or if changing the "design" is so difficult...

seckpin

idiot wrote:

seckpin wrote:

...
However, we feel that what went wrong is not the design per se but the coding and logic:
- why grab the dimension from two different sources for sales invoice and document dimension? It should both come from customer card or the source file, and not one get from source file and the other from customer card

This is quite vague, depends on what was the initial agreement with the vendor.

Well, i would have to disagree with you on this, because we are talking about two linked tables here. When you key in the global dimension on the sales header/line, the document dimension table will always be updated with the same values, and vice versa. Now that we are not entering the data manually but to input it through a dataport, then the source data for linked tables should be the same.

idiot wrote:

seckpin wrote:

- why there is no validation at all in all the coding? If there is, even if the sources are different, standard NAV validation will kick in to ensure there will never be inconsistency between sales header/line table and document dimension table.

Validation could mean taking the default value, or produce an error. What validation did you agree with the vendor?

By "validation", i mean the programming code of ".VALIDATE" and ".INSERT(TRUE)" and ".MODIFY(TRUE)". I am not referring to the business rule of validation, so there is nothing to "agree with the vendor". One can't possibly expect business users telling the NAV consultants that "please make sure you validate the fields in your code", or "please make the sales header/line and document dimension values different by skipping the validation".

We feel that these are the very basic of programming to ensure the database rules and the coding in each triggers are enforced. There is a reason why those coding are placed in the fields or triggers by NAV in the first place, i.e. to ensure the data integrity and consistency. By not calling these validations or triggers, these rules are compromised.

idiot wrote:

seckpin wrote:

It doesn't matter whether it is "same code" or "code mandatory" if the codes are properly written. The dataport should never create data inconsistency between tables in the first place.

Dataport, as the name implies, is for import or export of data. Data can be amended after importing, before posting. The posting routine is where the checking for consistency should take place.

If the data is indeed amended manually after import before posting, i.e. the user types over the imported dimension values, there is NO WAY you can re-create the inconsistency between the sales header/line and document dimension tables. We have tried many times and could not do it. That is because when we type in the data, the field validation in standard NAV will always kick in to ensure the two tables are maintained to be the same.

As for the posting routine is where the consistency check should take place, that is exactly the question in my original post -- why NAV does not check for the consistency upon posting? I can only assume that it is because NAV programmer assumes that standard NAV validation will always take place and such inconsistency will not happen and hence there is no need to check again upon posting. Of course, what they did not think of is that there will be consultants who actually wrote such inconsistency in the dataport and post through the inconsistency.

idiot wrote:

seckpin wrote:

Anyway, we will have to sort this out with the vendor, and it is not easy to get the message across, as they kept on insisting it is about "design". It gets tiring. Sometimes i just wonder if anyone else is having as much problems with their vendor as us.

You'll be surprised at the problems others are facing with vendors, or vendors are facing with customers. Sit down with the vendor & reflect on what the exact requirements were, what were changed, etc why or if changing the "design" is so difficult...

We have tried with no avail. And there is no "proof" of requirements or designs because there was no documentation. We do not know what the business had discussed with the vendor, as our IT department has come into the picture only recently and the system was design years ago. Now it can only be based on "you say, i say"...

matttrax

seckpin wrote:

And there is no "proof" of requirements or designs because there was no documentation.

Lesson learned. I can understand their position, though. You can't prove that you didn't want it designed that way or that someone else didn't come in and change it after they did the initial work.

Sounds like a case of bad programming to me, though. Maybe time to switch partners?

seckpin

matttrax wrote:

You can't prove that you didn't want it designed that way or that someone else didn't come in and change it after they did the initial work.

True, but it's hard to imagine that our business users actually asked them to design the system in the way that unless it's same code, otherwise data inconsistency will happen? I highly doubt so.

matttrax wrote:

Sounds like a case of bad programming to me, though. Maybe time to switch partners?

Precisely, it is simply bad programming. Yet, you should know how NAV partners work. Once you are engaged with one and have your system customised and implemented by them, it is hard to change partner because they are too invovled in your system.

David_Singleton

seckpin wrote:

Once you are engaged with one and have your system customised and implemented by them, it is hard to change partner because they are too invovled in your system.

That is not really true. If the relationship with your partner is irreparable, then you need to make the break as soon as possible before it gets worse.

On the other hand, in my experience, if you can work with the partner and resolve the issues, its a better path than changing. BUT be aware that unless you have some magic clause in your contract, either option will be expensive.

It all comes down to how important the partner sees their relationship with you. And how much you feel you can pay to save the relationship. A site with 11 countries that has 11 happy sites working smoothly is a veritable gold mine for the partner in terms of having a solid reference to allow them to "move to the next level" so I would imagine them wanting to jump though hoops to solve these issues. I think its time for a "Come To Jesus Meeting" as they would say in The States (well the Southern ones at least) and get this solved.