A4186.Purchasing.png"/resized-image.ashx/__size/550x0/__key/CommunityServer-Components-UserFiles/00-00-04-03-61-Attached+Files/1031.Receiving.png" border="0" />
Screenshot of purchase Receipts Inquiry:
*This post is locked for comments
A4186.Purchasing.png"/resized-image.ashx/__size/550x0/__key/CommunityServer-Components-UserFiles/00-00-04-03-61-Attached+Files/1031.Receiving.png" border="0" />
Screenshot of purchase Receipts Inquiry:
*This post is locked for comments
so in this case, system will select which cost while posting invoice or an assembly transaction posting
Wow, never mind this is correct. Forgot to do my math. :)
qty of 1 at $313.35
Qty of 803 at $0.15 = 120.45
Qty of 1196 at $.016 - 191.36
Total cost is $625.16/2000 = .31 cents.
So the cost is coming from all the layers. And the one line entry for the bigger dollar amount in the Purchase Receipts Inquiry window is due to rounding to handle the true cost of the qty received. with all the layers.
I got it now, thanks all!
Sheila
The qty sold was split between 3 different cost layers in the purchase receipts cost inqury window.
If I drill down the invoice shows up on all these layers.
Qty 803 was at $0.15
Qty 1196 was at $.16
Qty of 1 was at $313.35
If you add all the qty up, it is qty of 2000 which is the total sold on the invoice. if you add the dollar value it is $313.66/2000 which is .16 cents.
Yet on the invoice it shows the unit cost is .31 cents.
Sheila
Hello Lesli, they are using FIFO. Sometime it is confusing with all the layers. The sales invoice shows the cost was at .31 cents. When I manually add up the different cost on the layers I get .16 cents so I dont understand how the item unit cost on the sales invoice came up with .31.
This is actually normal by application design, such a transaction has to be done to maintain differences related to rounding and multicurrency, in your situation you indeed has a difference between unit cost and extended cost as explained below:
Your receiving had the EXTENDED COST of 3016.8, so 3016.8/18000 Unit = 0.1676 per unit.
Since you have two decimal places in your setup, the unit cost will be 0.16, so you will have a difference of 0.0076 which cannot be handled during to your existing decimal places setup.
The actual difference between your extended cost and unit cost is: 0.0076 * 18000 = 136.8.
To manage this difference, the system will receive 17,999 with the truncated cost which is 0.16 and will add all the difference in one piece as below:
136.8 + 0.16 (the unit cost) = 136.96 which is the number you currently see.
Hope that this clarifies your situation.
Hi - can you post a copy of the Invoice line (I presume the above is a Shipment and not a Shipment / Invoice? Just curious if there was a Purchase Price Variance.
Splitting quantities is a thing that GP does when it cannot divide the Extended Cost by the Quantity evenly. It will enter a FIFO line for so many at an equal cost, and the one left over at the balance. In your case above, there is a big difference, but its only .007 per item quantity. Overall, your client makes the correct gross profit on the sale of the entire inventory.
You might set up a test enviornment where the decimal places for quantities and currency is set to 3 decimal places. See if it helps with this particular case of large volume, low cost items.
Ian.
Sheila,
What valuation method are they using? That probably doesn't make any difference, but I thought I'd ask.
Kind regards,
Leslie
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,280 Super User 2024 Season 2
Martin Dráb 230,214 Most Valuable Professional
nmaenpaa 101,156