I recently came across the following error when trying to post an Inventory Pick in Dynamics NAV 2018
On investigation this is being caused because although the Inventory Pick had been created from the Sales Order, the Sales Order had subsequently been shipped and invoiced directly from the Sales Order screen rather than via the Inventory Pick. (this surprised me as I assumed the system would prevent the Sales Order from being shipped and invoiced from the Sales Order if an unposted Inventory Pick existed for it)
For clarity, as I understand things when a location has the “Require Pick” option ticked in the location setup (important to note “Require Shipment” isn’t ticked) the usual process for shipping and invoicing a Sales Order would be:
Create the Sales Order.
Release the Sales Order.
Create the Inventory Pick in a push or pull fashion from the Sales Order.
Post the shipment from the Inventory Pick.
Post the Invoice from the Sales Order.
It seems that somewhere between point 3 and 4 someone had opened the Sales Order and clicked “Post” and selected “Shipment and Invoice” even though the Inventory Pick was still unposted.
On investigation this removes the internal “Warehouse Request” from the warehouse request table and when you try and post the Inventory Pick you are presented with the error “The Warehouse Request does not exist”.
As far I can see the only option here is to delete the Inventory Pick as it can’t be progressed. (I also assume the goods have been shipped)
I’ve tested this same process on a version of Dynamics 365 Business Central and it seems to prevent the Sales Order being shipped and invoiced if an Inventory Pick exists for it. When you do try you get the message below:
This does make more sense to me, I’m just surprised Dynamics NAV doesn’t prevent it.
As with all issues I did learn something new and also had fun looking at the importance of the internal Warehouse Request with all this. This is something I’m hoping to look at it more depth in future.
This week I dealt with a very bizarre issue affecting all Sales Order Processing Transactions that I thought was worth documenting. It started with a simple support request explaining that Sales Order Processing Invoice transactions weren’t posting due to missing distributions. See below
Missing SOP Distributions
When I connected to investigate further I found the Sales Order Processing Distribution Work\History table (SOP10102) was, with the exception of a hand full of rows, completely blank. (and those rows related to the most recently added SOP transactions)
As this table contains the distributions for both Work and History documents all distributions on posted Sales Order Processing transactions had been lost as well.
Before I even considered how this could have happened I set about trying to find out which user could have done this, and when it happened, so I could recover the missing data.
The first clue for when this could have happened lay with the SQL transaction log backups. As this table would have had hundreds of thousands of rows, I suspected this would have generated lots of SQL transaction log, so I checked the size of the transaction log backups and this highlighted a larger than normal LOG backup at midday (I could do this as the SQL database is in FULL recovery model and the client performs hourly transaction log backups)
Large transaction log backup at midday
I now suspected the issue had arose between 11am and midday so I set about querying the contents of this SQL transaction log backup file looking for transactions with deletes on the SOP10102 table using the query below.
select
[begin time] as BeginTime,
[End Time] as EndTime,
SUSER_SNAME ([transaction sid]) as UserID,
object_name(object_id) as TableName, *
FROM fn_dump_dblog
(NULL, NULL, N'DISK', 1, N'D:\...\backup_2019_10_07_120002_5428125.TRN',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) as log1
left join sys.partitions part
on part.partition_id=log1.partitionid
where
[transaction id] IN
(select
[transaction id]
FROM fn_dump_dblog
(NULL, NULL, N'DISK', 1, N'D:\...\backup_2019_10_07_120002_5428125.TRN',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) as log1
left join sys.partitions part
on part.partition_id=log1.partitionid
where
operation = 'LOP_DELETE_ROWS' and
object_name(object_id) in ('SOP10102'))
order by [Transaction ID]
I scanned through the results and found the transaction id below which was logging lots of deletes on the SOP10102 table
Transaction showing deletes on SOP10102
I then took this Transaction ID and ran the following SQL query to get full details on this SQL Transaction
select
[begin time] as BeginTime,
[End Time] as EndTime,
SUSER_SNAME ([transaction sid]) as UserID,
object_name(object_id) as TableName, *
FROM fn_dump_dblog
(NULL, NULL, N'DISK', 1, N'D:\...\backup_2019_10_07_120002_5428125.TRN',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) as log1
left join sys.partitions part
on part.partition_id=log1.partitionid
where [transaction id] IN ('0000:088fba17')
This query returned 1,466,128 rows all of which are deletes to SOP10102. (this is more than the number of rows in the table which is likely because of the additional deletes on the SQL non clustered indexes that also need maintaining)
Lots of deletes on SOP10102 table
Following on from this I’m now know the user who has caused the deletes, and the exact time it happened. I also know this SQL Login ID relates to a GP user which means this has to have happened inadvertently while using GP. (you can’t use a Dynamics GP SQL Login to access the data via any tool other than Dynamics GP as the password is encrypted)
I asked the user in question if they noticed anything strange at this time like GP crashing or hanging but unfortunately they don’t recall. Therefore this is still a total mystery I’m afraid.
To recover the data I restored the backup to a new database right up to the point of the data going missing i.e. I restored the FULL SQL backup and all LOG backups with NORECOVERY with the exception of the last LOG backup which I restored as per below
I then copied the data back using the SQL query below
INSERT INTO LIVEDB..SOP10102 (SOPTYPE, SOPNUMBE, SEQNUMBR, DISTTYPE, DistRef, ACTINDX, DEBITAMT, ORDBTAMT, CRDTAMNT, ORCRDAMT, CURRNIDX, TRXSORCE, POSTED, Contract_Exchange_Rate) SELECT A.SOPTYPE, A.SOPNUMBE, A.SEQNUMBR, A.DISTTYPE, A.DistRef, A.ACTINDX, A.DEBITAMT, A.ORDBTAMT, A.CRDTAMNT, A.ORCRDAMT, A.CURRNIDX, A.TRXSORCE, A.POSTED, A.Contract_Exchange_Rate FROM RESTOREDDB..SOP10102 A LEFT JOIN LIVEDB..SOP10102 b on a.SOPNUMBE=b.SOPNUMBE and a.SOPTYPE=b.SOPTYPE WHERE B.SOPNUMBE IS NULL
After running the INSERT query the client confirmed that all the data had been recovered.
Although I didn’t get to the bottom of the missing POP data I did have my suspicions however there are no related third parties that could have caused this issue with SOP10102.
Unfortunately I suspect this will also remain an unsolved mystery I just hope it doesn’t happen again.
Thanks for reading!
Thinking of making the move to Business Central? We can help
I recently ran into an issue drilling back on a Purchase Order from a Sales Order with drop shipment lines. The exact error was “Purchase Order No. must have a value in Sales Line…….It cannot be zero or empty” as shown in the screen shot below:
Purchase Order No. must have a value in Sales Line
On investigation this only affected the lines on the Sales Order that had been shipped and invoiced. If I drilled back on an outstanding line on the Sales Order the Purchase Order is displayed without issue. After troubleshooting this it seems when you receive and invoice the line item on a drop shipment the system removes the link back to the Purchase Order and consequently you receive an error trying to drill down.
I’ve detailed how you can recreate the issue below, with a neat trick that can be used to view the data in the Sales Order tables via your browser.
To recreate the error first add a Sales Order with more than one drop shipment line as per below:
Sales Lines marked as Drop Shipment
Next create the Purchase Order and pull through the Sales Order using the function below
Function to Get Sales Order lines
Finally go back to the Sales Order and ship and invoice the first line
The first line has been shipped and invoiced
Now highlight the first line and try and drill back to the Purchase Order using the option below
On doing this you are prompted with the error
Purchase Order No. must have a value in Sales Line
Therefore following this document I added &table=37 to the end of my URL to view the full contents of the Sales Line table
On viewing the data in the table I can see the Purchase Order Number has been removed from the shipped and invoiced line
Purchase Order No. and Purch Order Line No. removed once shipped and invoiced
This is preventing me from drilling back on the Purchase Order. If you check the Purchase Line table (table 39) you can see the Sales Order number has also been removed, so you wouldn’t be able to drill down on the Sales Order from the Purchase Order either.
I also worked through the issue on my local Dynamics NAV install and observed the same behaviour, therefore I’m sure this is by design, however I’m unsure of the reasons. It seems the link to the Purchase Order is permanently removed once the sales line has been shipped and invoiced.
I also checked table 113, which is the Sales Invoice Line table, but this also doesn’t seem to keep the link back to the purchase order.
I’d be interested to know if I’m missing something here. Perhaps there is a way to get back to the Purchase Order from the sales document once its been posted. If there is I’d be very grateful if you could let me know.
thedynamicsexplorer.com 