Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
We have had some sporadic costing issues in purchasing. Several times I have tracked the issue down to a problem with the combination of Unit Cost, Quantity, and Extended cost on the purchasing documents.
The curious thing is that often I find the "problem" item doesn't have a currency symbol in front of the unit cost amount. Can anyone tell me how this happens? We have many different currencies, so I have setup each currency to start with the letter for the currency and then symbol. So USD is U$XXX.XX SGD would be S$XXX.XX, etc.
As you can see from the screen shot, the Unit Cost doesn't have the symbol or the letter, so am curious how this happens because as I mentioned I often track back problems to transactions like this. The missing symbol can occur on a single line of the document, when others appear normal. Any ideas?
One note, the transaction was entered in originating currency of USD, while this company has functional currency of SGD.
What version of GP are you using? I'm on GP2010 and I don't see the expansion arrows next to Unit Cost or Extended Cost.
Is this an Alternate Window from a 3rd party product?
Are the items having the issue Non-Inventory Items?
We are on GP 2013 R2. This is not an alternate window or even modified. The Items are Inventory items (Sales Inventory). The screen shot is of the Shipment Receipt, not the PO.
The PO was entered in USD, but when I switch to show functional currency, the symbol and "S" (for SGD) is missing. The receipt shows the same way. But I have other POs (and receipts) entered in USD that show the S$ fine when switching to show functional currency.
I just want to be certain we are not missing something during PO or Shipment entry that could be causing this.
This is most likely due to one of the currency fields in either POP10110, or POP10310 being set incorrectly.
I recommend you find a line that is displaying incorrectly, and one that is displaying correctly, then query the above 2 tables to see what is different (I'd suspect that it's one of the currency dependent fields such as "DECPLCUR", "CURRNIDX", or "CURNCYID", but check them all as a matter of course).
From this you should hopefully find out where the problem is going wrong...for example the PO lines (POP10110) are the same/correct, and it's POP10310 where they differ.
Once you've identified that, then see what sort of addon's, customizations, SQL triggers, etc... you have in place that could potentially be causing the problem.
Also try to identify if the problems is coming from a particular user/workstation/import/etc...
Please let me know your findings.
No issues with the tables that I was able to find.
But I did figure out that this typically happens when receiving in a currency different from the companies functional currency.
In my example the functional currency is AUD; but the PO was entered and received in USD. When I select to view the receipt in "originating currency." Everything appears fine; when I switch to "functional currency" I get the missing currency symbol. And most recently the "functional currency" unit cost is zeroed out. So unit cost for originating currency is like 1.95, but when switched to functional currency shows as zero.
Since the functional currency for this company is AUD; GP then updates Current Cost on the Item Maintenance window with zero. Which causes problems with the GL because those items are now in the system at zero.
Confusing. If anyone can shed any light on this, or would like me to generate more data, let me know, thanks.
Hmm, so more research shows that a "good" receipt (properly shows both functional and originating currency without issue) has "Rcvg Trx Entry" in the BCHSOURC field in the POP30300 table; but the "bad" receipts have "*Rcvg Trx Entry" in that field.
I believe I read that the asterisk can mean a failed posting (except in the case of users that have not yet saved their transactions to a batch). But when I returned and re-entered the receipt I got no messages about posting issues.
I believe I may have uncovered the problem behind this issue.
It appears that when multicurrency is used the POP tables use a different DECPLCUR scheme than the other tables (IV00101 for example).
Previously I had run a script to update decimal precision to reduce split receipts. But I used the 0 - 6 scheme where as the POP tables use 7 - 12.
DECPLCUR (Decimal Places for Currency):
7 – 0
8 – 1
9 – 2
10 – 3
11 – 4
12 – 5
I don't know why there is a difference for multi-currency, but when I ran a script to update the 0 - 6s in the POP tables (POP10110 POP30310) to the MC version (7 - 12) the currency symbols are showing up as expected.
Business Applications communities