GP 2010 - IV30300

(0) Share

Report

Posted on by VJ Shah

373

Review/run the SQL query below against the TWO or Fabrikam database. Can anyone tell me why QTYBSUOM field would be set to 0 in the Fabrikam for some of the Inventory transactions?

My understanding of this field is that it is a QTY In Base U Of M. For any transaction, if the Quantity in base is never 0 - system does not allow it on the Unit of Measure Schedule setup window. Any thoughts?

Select QTYBSUOM, * From TWO.dbo.IV30300 where QTYBSUOM = 0

*This post is locked for comments

I have the same question (0)

All responses (7)

Answers (0)

Sort by

Mahmoud Saadi 32,738 on at

Like (0)

Report
Copy link

Link copied!
Actually, this is not the quantity in the base unit of measurement. This field is used primarily in IV30300 and setup table of the UOM (IV40202)

This field is used to store the factor required to convert the stored quantity in IV30300 into the quantity in the base UOM. Let me provide a simple example.

Suppose you have a UOM as follow;

Box = 1 Box

Case = 6 Box

When entering an adjustment, for 6 boxes, the following record will be stored in IV30300

ItemNumber     UOFM        TRXQTY     QTYBSUOM

X                           box            6                  1

On the other hand, when entering 10 cases of the same item, the following record will be thrown in IV30300

ItemNumber     UOFM        TRXQTY     QTYBSUOM

X                           Case         10                 6

The bottom line is, this field is not supposed to be zero as you indicated. Additionally, it is used to convert the quantity into the quantity in base UOM, in reports such as (Historical Stock Status) and Inquiry such as (Item Stock Inquiry)

As for Fabrikam, zero values are not supposed to be correct. It is not the normal case.

Your feedback is highly appreciated,

Was this reply helpful? Yes No
VJ Shah 373 on at

Like (0)

Report
Copy link

Link copied!

I have the same thing happening to my production data as well. We have several lines in IV30300 where this field is 0. Can someone help provide an answer? Or Is this a bug in the system?

Was this reply helpful? Yes No
Mahmoud Saadi 32,738 on at

Like (0)

Report
Copy link

Link copied!

It is not a bug. It could be a result of data integration in your Dynamics GP

Actually, having a QTYBSUOM with a zero value could sometimes result from posting corruption, or back end integration on the database level. It usually results with the common "Divide by zero error when printing the Historical Stock Status Report"

Through several implementation of Dynamics GP with heavy inventory transactions on a daily bases along with eConnect integration, I have never seen one single record on the IV30300 with a QTYBSUOM of zero. It is not the standard behavior and you need to track down the source of the problem.

As mentioned above, you may need to look for one of two issues, either posting corruption of improper integration.

Your feedback is highly appreciated,

Was this reply helpful? Yes No
VJ Shah 373 on at

Like (0)

Report
Copy link

Link copied!

Hi Mahmoud:

The intent of the question is to help narrow down the scope of the issue. If this same issue exists in our production data (different environments) as well as the test data provided by Microsoft in terms of Fabrikam, Inc., I would say there is an issue somewhere in GP for this to occur on a consistent basis. I have identified this column to be 0 across two completely different environments where we process inventory. One of these environment is running core GP with no 3rd parties or any integration.

I will continue to research this further to see if there is an underlying issue that helps me reproduce the issue. I would like to keep this thread open to see if someone else is able to share their findings in the meantime.

Thanks for your input - very much appreciated.

Was this reply helpful? Yes No
Richard Wheeler 75,852 Moderator on at

Like (0)

Report
Copy link

Link copied!

VJ mentioned the value of QTYBSUOM should not be zero. Now I did just run this query on my database and I did find hundreds of them. However, upon further inspection I discovered they were all on records before we converted from GPA for DOS. I scanned other companies databases from other clients and I cannot find any records where that value is zero. Is this occurring on records that are recent or are they old prior to some conversion? By the way, when I scan for them in my Fabrikam database there are 158 records like that. Perhaps these records were also converted from GPA for DOS.

Was this reply helpful? Yes No
VJ Shah 373 on at

Like (0)

Report
Copy link

Link copied!

In my case, both environment are about 30 months old data and they have been on single version of GP 2010 R2. They have not been upgraded from previous versions or have not upgraded to the latest version. I have not been able to replicate the issue either. Thanks for looking into it.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,061 Moderator on at

Like (0)

Report
Copy link

Link copied!

We have about 7 GP companies, all using Inventory transactions and from which one is used with the Manufacturing module of GP... we use a lots of 3rd party and even had some attempts of implementing an external WMS into production (for Mo's and inventory tracking)... None of our companies DB's have records showing up with your query... But I have 158 in our TWO database that range from dates going 2014 to 2017 (which is normal given de default data in Fabrikam)... However, can't explain from where those errors can come. The transaction types goes across all the modules in GP : SOP, INV, POP, IVC & BOM.

Was this reply helpful? Yes No