This content has been marked as final. Show 5 replies
RECEIPT_NUM in the database is a varchar2(30) field but based on your setup, you can use the receipt form to allow only numbers/alphanumeric and automatic/manual entry.
So, if you would want to treat this as a number. The maximum allowed digits including the number, the decimal and the numbers to the right
of decimal can not exceed 30 characters.
Ex: 9.1234567890123456789012345678 is max allowed
Ex:112345678901234567890123456789 is max allowed
hi srikanth somasila
thanks for your reply. what about the receipt quantity? how many digits are allowed after decimal point? Im not considering database field size, im considering valid form entry. i've seen in several for that the numbers are often rounded in receiving transactions form and other forms also which ofter create problem in receiving and closing POs. so please anyone help me.
What is the unit of measure being used, just wondering the need around having such requirement.
It has to be tested out on your end of the form, even though the field is a number I believe
on my instance it only takes 6 digits after the decimal
1.123456789123456789123456789 was taken as 1.123457
just want to share a little experience on similar problem.
there is already an open ER for this (I am not monitoring the ER, but I know it's out there)
Inventory transactions and your on hand balances are stored with a 5 digit precision
Receiving transactions, however, are supported to have more than 5 digits.
This has proven to cause problems in receiving activity, such as RTV and Corrections
Supposed a PO is open for 1.654321, received fully at 1.654321
if you want to return all of the received quantity, you should return all 1.654321. However, inventory transactions and onhand balance only exist for 1.65432 (rounded in 5 digit precision). In the receiving return form, if you enter 1.654321, system will prevent the transaction saying that there isn't enough quantity.
So, taken this into consideration, we always procedurely restrict to 5 digit precision in every quantity based transactions
(this happens in 11.5.10 instance, haven't checked the behaviour in R12, most likely be the same)
I have seen the issue with Billed quantity also. In our system there are several POs with billed quantity 11 digits after decimal point (.98373802501). but somehow the received quantity is .98374. probably this mismatch is because of rounding problem. in these cases what could be the solution. im thinking of restricting users from inputting not more than 5 digits after decimal point. pls suggest me what could be an ideal solution for oracle 11.5.10.