Views:

Our client was receiving an error 'Wrong number of arguments to 'GetDates' when running the Detailed Historical Stock Status Report. I found out from MS its a bug caused by this:

'I found that the error occurs for items that have valuation method of 0 in the IV10200 regardless if the layer is mark as sold or not. These are old layers from prior to version 8.0 (before the IV10201 and SEE30303 table structure was created). These layers were linked to PO shipment/invoices that had a cost changed. Example; I was able to identify that the errors seem to occur on an item that had a Shipment that was posted for one cost ($100) and later matched at a different cost on the invoice ($150) , AND the transaction was done on an OLD version of GP where we stamped the IV10200 table with 0 for valuation method. Then the system would then throw the error. If I did a shipment/invoice at the same time where the valuation was stamped at 0, that would not throw the error. If I did a shipment and later matched and invoice at the SAME cost with the valuation method of 0 in the IV10200, that would not throw the error. So it’s a VERY specific data steps and VERY old layers that this occurs on. 

The blog helps identify potential problem layers that could potentially cause the error. 


https://community.dynamics.com/gp/b/dynamicsgp/archive/2018/03/20/wrong-number-of-arguments-to-39-getdate-39-printing-the-historical-stock-status-report-hssr 

For sold layers we can't just update the table and set the valuation method with a sql script because the Receipt Sequence field would be duplicated (1). And when you stamp the open layers the system treats them differently when consumed and writes to the IV10201. Plus, again we would have duplicate receipt sequence numbers if all we did was stamp the valuation method and it would cause more issues down the line. So unfortunately we can't just update the field with SQL.

The only other to try to get around this was to remove old sold layers from the IV10200 and then run the HITB reset to re-sequence the open layers and stamp the layers. That should clear the error. However, I had one partner that had an item that was VERY old and all old layers that were sold. So he removed the entire IV10200 (nothing in the (IV10201). However, the error didn't go away. Only after he removed history on the item did the error go away. So I know there has to be other data conditions or code issue that causes the issue, but I don't know what. For other partners, the workaround above worked. 

Hope this helps. I'm happy to look at the data results for the item if you want. If you want me to send me the results of the following scripts ran in Text. First script looks at sold receipts with valuation method of 0. 

SELECT * FROM IV10200 WHERE VCTNMTHD = 0 AND RCPTSOLD = 1 

The next script is showing me layers that are still open with valuation method of 0.

SELECT * FROM IV10200 WHERE VCTNMTHD = 0 AND RCPTSOLD = 0 

from Microsoft.