transfer order:shipping 1 line creates 2 positive en

kriki

Italian Navision 3.70A.

Strange problem shipping of a transfer order:
We are transfering items from 1 location to another. The shipping is posted.
For each line there should be negative transfer entry for the old location and a positive transfer entry for the in-transit location.

EXCEPT for 1 line. In this line, the transfer created a negative transfer entry of 8 items and it created 2 positive entries in the in-transit location (6 and 2 items). When receiving, Navision complains because the Item Ledger Entry saved in the transferline to be applied has not a remaining quantity of 8.

Someone knows how that could happen and how to avoid it?

I already ruled out localisation-bugs.

kine

It is common that there are more positive lines. Which costing method you are using? It can be for example for FIFO or standard method. The system need to keep different cost. It means that the negative entry is applied to two positive entries in the system and the new pos. entries are "connected" to these two entries. The connection you can found in table 339 Item Application Entry.

kriki

kine wrote:

It is common that there are more positive lines. Which costing method you are using? It can be for example for FIFO or standard method. The system need to keep different cost. It means that the negative entry is applied to two positive entries in the system and the new pos. entries are "connected" to these two entries. The connection you can found in table 339 Item Application Entry.

And the fact that it generates an error when receiving? Is that a bug in 3.70A?
And how to fix the cases we already have?
And how can it be avoided in the future? I hope it is not necessary to upgrade to 3.70B and even less to 4.00SP1.

mrQQ

i think it's some customization problem. if you apply the line to a specific entry, then it will only create 1 positive entry. and if you don't, it wont spit an error..

kriki

I did some tests and found some strange things:
-I used the debugger to see what happens and I didn't get the error (after a few times I tried to post it without the debugger and getting the error).
-So I restored the DB, retried without debugger and got the error. Then with debugger:no error.
-I put the backup in a Navision-DB, retried without debugger and it worked!

So it seems to be a SQL-bug. But how to fix it? (apart a technical upgrade to 3.70B or 4.00SP1)

kine

http://www.mibuso.com/forum/viewtopic.php?t=9456
http://www.mibuso.com/forum/viewtopic.php?t=6267

etc. Try to use this workaround:

UPDATE [$ndo$dbproperty] SET diagnostics = 131072

kriki

kine wrote:

UPDATE [$ndo$dbproperty] SET diagnostics = 131072

Thanx. I had the idea I had seen something for it, but I couldn't find it.
I wonder what this statement does. Which effects it has on performance or other things. I searched around (MS, some SQL-forums,help) but found nothing.

gri

So? Is it a sql thing?
Even if this behavior can be linked to multiple purchases, the splitting of the line should be done in item application entry, where it is usually happening, not in item ledger entry.

Is it a bird? Is it a plane?
No, it's a bug!

ps:
Apologies, kriki, for misplacing the topic and for not searching thoroughly.

kine

No, the problem is not in the entry creation, it is in reading. That there is more than one entry is not the problem. Problem is, that Navision sometimes "do not see" the other entries...

kriki

gri wrote:

ps:
Apologies, kriki, for misplacing the topic and for not searching thoroughly.

No problem, it sometimes also happens to me. Like with this post.

kine wrote:

No, the problem is not in the entry creation, it is in reading. That there is more than one entry is not the problem. Problem is, that Navision sometimes "do not see" the other entries...

I noticed it, sometimes I have 2 sessions. In one I work and the other I see the result.
When I do a CTRL-HOME on the table I see the records, when I do CTRL-END the records disappear! :shock: I only have this with SQL.

sgg

I have read some postings in this forum about the

[$ndo$dbproperty] diagnostics field in SQL.


we have the following setup:

Database : Navision 3.60A US on SQL
Inventory Costing Method : Average
Observation : Inventory Valuation Report does not agree with G/L values.

is it possible that making the following setting in SQL will correct inconsistencies noticed between the Inventory Valuation Report and the G/L?


UPDATE [$ndo$dbproperty] SET diagnostics = 131072

kriki

I still haven't put [SOLVED] in the title because the customer didn't wait for a solution and they transferred the quantities manually.

But I am starting to wonder about this:
Wouldn't it be better to put this in all Navision on SQL-DB's? Or are there some negative side-effects putting it?

ningnongjin

Hi All,

I was wondering whether in Navision 4 SP1, is there a reversal procedure for items that have been posted as ship accidentally?Any help would be appreciated. Thanks in advance.

djswim

kriki wrote:

But I am starting to wonder about this:
Wouldn't it be better to put this in all Navision on SQL-DB's? Or are there some negative side-effects putting it?

This is exactly what I've been wondering, especially as we move towards an all-SQL database model for NAV.

I also have searched on any possible negative side effects but have found nothing. The optimist in me wants to assume that means there aren't any and people just haven't returned because their problem was solved. The pessimist in me wants to make sure this wasn't because they were taken into the street and shot afterwards

Any feedback?

kine

There were no problems. But this is too old thread. You do not need this anymore, just do the technical upgrade to latest client version...

djswim

We're on 6.0 R2...

Getting the following error message when attempting to post receipt of a PO of three lines that are all lot-tracked (Third line contains the same item and lot number as the first line to account for over-receipt):

"Item Entry Relation already exists
Identification fields & values:
Item Entry No.='21' "

I've looked in Table 6509 "Whse. Item Entry Relation" and there is no Entry 21, in fact, it's a new system, so there aren't any entries at all!

Hopefully some of that detail helps.

kine

Look into KnowledgeBase on the partner source. There are some bugs in the system and you should be able to find them there...

ara3n

this looks like a bug. Contact your partner.

The entry does not exist is because your transaction is posted multiple entries, and they are not incrementing correctly.

A workaround would be to post each lot separately.

djswim

kine wrote:

Look into KnowledgeBase on the partner source. There are some bugs in the system and you should be able to find them there...

I've been looking and can't seem to find anything by searching for the error message. Not sure what else to search by since it seems like that would be the most universal thing.

I am the partner

Not quite sure what you mean by post each lot separately...