Unit Selling Price - Round Off

Hi All,
My requirement is to round off the unit selling price in Sales Order screen,
for example
Item AS16101 unit selling price is 12.99, while entering this item it should be 13, and saved to database as 13
Item AS16103 unit selling price is 12.40, while entering this item it should be 12
In WHEN VALIDATE RECORD, i used round function in form personlization, but in data base its saving the original value.
Any help on this.
Regards,
Max

In Personalization i have shown the value in messages, its showing correctly but when i enabled the custom events, after my message with value it showing PRE_QUERY trigger and saving the actual value.
Regards,
Max

Similar Messages

Price per unit is getting round off to two decimal places.

Hi Gurus,
In the Billing output, the Price per unit is getting round off to two decimal places.
How can we avoid this or allow 4 decimal places for such cases.
In the same pricing procedure, we have two pricing condition types PR02 and ZR01.
When PR02 is being used,it doesnt rounds off Price per unit.e.g .578888 = .578888
But when ZR01 is being used the system rounds off price per unit.e.g.578888 = .58
Please suggest where is the setting for it.
Thanks
Montee

Hi,
Which currency you are using? If its INR, then it will do only for 2 decimal places.
The solution for ur problem can be ractified by changing the scales :
Also check OSS 80183
Thanks,
Raja

Manual override option for Unit selling price in Order line level.

In OM R-12
Our client wants manual override option for Unit selling price in Order line level.
But there is no solution available to fulfill this requirment. To be able to manually override the price on a Sales Order line you
must have defined a manual modifier that qualifies for the Sales Order line in question. Without a suitable manual modifier the price cannot be changed.
This is current standard functionality.
Anybody can give some suggestion/workaround to override selling price in Order header level without using the modifiers.
regards,

Hi Kashif,
I'm finding it little difficult to buy Oracle Support's feedback with regards to R12 functionality for direct List Price update without using any modifier (manual or whatever). After all it is Oracle's product and they should know better. But test results in Solution Beacon's Vision 12.0.6 instance (http://www.solutionbeacon.com/tools_r12vision.htm) and documentation updates in R12 (R12.0.4) OM user guide & implementation manuals potray a different picture.
After your last post, I did a test in Solution Beacon's Vision 12.0.6 instance with following details:
OM: List Price Override Privilege = "Unlimited Access" at user level
OM: Discounting Privileges = "None" at user level
No manual modifiers defined and Order status = "Entered"
I could display the "List Price" field from folder under Line Items >> Main tab, override the list price to a new value and save. The unit selling price showed the new value based on updated List Price as soon as I tabbed out of the list price field after overriding. After saving it showed the new selling price. _Please note that under Line Items >> Pricing tab there is another "List Price" field and that is not editable_. For such overrides "View Adjustments" (from Line >> Actions) will not show any adjustment details as it is a direct update of list price.
Also please note that, if "Enforce List Price" checkbox is selected for the order type, the list price cannot be overridden even if the profile option is set to "Unlimited Access".
Document References:
Oracle® Order Management User's Guide
Release 12, Part No. B28099-03, September 2007 >> R12.0.4
Page No. 10-74
+Note: Note: If any order line for an order has the Calculate Price Flag value equal to Partial Price or Freeze Price new order level adjustments will not be applied or allowed to be overridden. _The profile option OM: List Price Override Privilege controls your ability to override the unit list price. If you have this profile set to Unlimited, you may modify the unit list price by editing the current value displayed_. The original list price is saved in a hidden folder field, so you can display it if necessary+.
Page No. 10-94
User Procedures
_A new profile option, OM: List Price Override Privilege controls whether or not you can update the List Price_. It is enabled and updated at the application, responsibility and user level. It is not user visible and updatable. The values include+:
- View Only: This is the default value. If set to this value, the current behavior is retained, which means unit list price field is protected.
- Unlimited Privilege: If set to this value, you can override the unit list price field from the main tab and immediately see selling price adjusted accordingly.
To use Override List Price:
+1. Navigate to the Sales Orders/Quick Sales Orders window.+
+2. Enter the header and line information, including the ordered item and quantity, then tab to the next field. The Selling Price and List Price display+.
+3. If the profile is set to Unlimited Privilege, you can enter a new list price in the List Price field. You can either proceed to the next line or save your work+.
+4. You can see the new, entered list price, and if there are automatic discounts applied, they will be based on the new list price+.
+5. If the folder has been modified to show the Original List Price, the original list price displays+.
+6. To change the List Price again, go to the list price field and enter a new value, replacing a previously entered value. If Audit Trail is enabled for List Price and a reason is required, a window appears to enter a reason and optional comments+.
Note: Subsequent overrides of the List Price, after the order line is saved, can be captured by Audit Trail, depending on the setup of Audit Trail (entered or booked state) and any processing constraints that have been set up.
In the OM Implementation Manual also there are notes related to this.
OM Implementation Manual
Release 12, Part No. B25975-03, September 2007 >> R12.0.4
You can refer to page no. 2-59, C-4 etc.
Thanks
Supro

Unit Selling Price Override through PROCESS_ORDER API

Hi All,
I have this below requirement to be achieved through process_order API.
1. In the Order Oganizer UI, I open the Order Entry form.
2. Open the Lines tab
3. For the Unit Selling Price, I change the price manually and tab out.
4. Its gives me a LOV to select a Surcharge modifier.
5. I select one of the surcharge and click save.
6. The price is overridden and a manual price adjustment is created for the above selected surcharge.
This functionality I want to acieve through the PROCESS_ORDER API. Basically, I want to override the unit selling price and apply a surchage modifier. This should change the selling price and create a adjustement record for the above line.
Please let me know if anyone knows about this. That would help me.
Thanks,
Anand

Anand
I tested this in 12.0.4 vision and works. Also if you need to use update option if you are applying the same modifier more than once(not create), just like the way screen changes behave.
DECLARE
l_return_status VARCHAR2 (30);
x_msg_data VARCHAR2 (2000);
x_msg_count NUMBER;
l_adj_rec oe_order_pub.line_adj_rec_type;
l_adj_tbl oe_order_pub.line_adj_tbl_type;
l_x_header_rec oe_order_pub.header_rec_type;
l_x_header_adj_tbl oe_order_pub.header_adj_tbl_type;
l_x_header_scredit_tbl oe_order_pub.header_scredit_tbl_type;
l_x_line_tbl oe_order_pub.line_tbl_type;
l_x_line_adj_tbl oe_order_pub.line_adj_tbl_type;
l_x_line_scredit_tbl oe_order_pub.line_scredit_tbl_type;
l_x_lot_serial_tbl oe_order_pub.lot_serial_tbl_type;
l_x_action_request_tbl oe_order_pub.request_tbl_type;
l_x_header_price_att_tbl oe_order_pub.header_price_att_tbl_type;
l_x_header_adj_att_tbl oe_order_pub.header_adj_att_tbl_type;
l_x_header_adj_assoc_tbl oe_order_pub.header_adj_assoc_tbl_type;
l_x_line_price_att_tbl oe_order_pub.line_price_att_tbl_type;
l_x_line_adj_att_tbl oe_order_pub.line_adj_att_tbl_type;
l_x_line_adj_assoc_tbl oe_order_pub.line_adj_assoc_tbl_type;
l_list_line_type_code VARCHAR2 (30) := NULL;
l_list_line_id NUMBER;
l_x_header_payment_tbl oe_order_pub.header_payment_tbl_type;
l_x_line_payment_tbl oe_order_pub.line_payment_tbl_type;
l_prc_adj_request oe_order_pub.request_tbl_type;
l_prc_adj_index NUMBER := 1;
l_price_adj_id NUMBER;
v_msg_index_out NUMBER;
x_header_rec_type oe_order_pub.header_rec_type;
x_header_val_rec_type oe_order_pub.header_val_rec_type;
x_header_adj_tbl_type oe_order_pub.header_adj_tbl_type;
x_header_adj_val_tbl_type oe_order_pub.header_adj_val_tbl_type;
x_header_price_att_tbl_type oe_order_pub.header_price_att_tbl_type;
x_header_adj_att_tbl_type oe_order_pub.header_adj_att_tbl_type;
x_header_adj_assoc_tbl_type oe_order_pub.header_adj_assoc_tbl_type;
x_header_scredit_tbl_type oe_order_pub.header_scredit_tbl_type;
x_header_scredit_val_tbl_type oe_order_pub.header_scredit_val_tbl_type;
x_line_tbl_type oe_order_pub.line_tbl_type;
x_line_val_tbl_type oe_order_pub.line_val_tbl_type;
x_line_adj_tbl_type oe_order_pub.line_adj_tbl_type;
x_line_adj_val_tbl_type oe_order_pub.line_adj_val_tbl_type;
x_line_price_att_tbl_type oe_order_pub.line_price_att_tbl_type;
x_line_adj_att_tbl_type oe_order_pub.line_adj_att_tbl_type;
x_line_adj_assoc_tbl_type oe_order_pub.line_adj_assoc_tbl_type;
x_line_scredit_tbl_type oe_order_pub.line_scredit_tbl_type;
x_line_scredit_val_tbl_type oe_order_pub.line_scredit_val_tbl_type;
x_lot_serial_tbl_type oe_order_pub.lot_serial_tbl_type;
x_lot_serial_val_tbl_type oe_order_pub.lot_serial_val_tbl_type;
x_request_tbl_type oe_order_pub.request_tbl_type;
x_header_payment_tbl_type oe_order_pub.header_payment_tbl_type;
x_header_payment_val_tbl_type oe_order_pub.header_payment_val_tbl_type;
x_line_payment_tbl_type oe_order_pub.line_payment_tbl_type;
x_line_payment_val_tbl_type oe_order_pub.line_payment_val_tbl_type;
l_control_rec oe_globals.control_rec_type;
BEGIN
fnd_global.apps_initialize (1005902, 21623, 660);
mo_global.set_policy_context ('S', 204);
l_x_line_tbl (1).line_id := 319799;
l_x_line_tbl (1).header_id := 155008;
l_adj_rec := oe_order_pub.g_miss_line_adj_rec;
l_adj_rec.price_adjustment_id := fnd_api.g_miss_num;
l_adj_rec.list_header_id := 8988; --Modifier id
l_adj_rec.list_line_id := 16596; --Modifier line id
l_adj_rec.automatic_flag := 'N';
l_adj_rec.list_line_type_code := 'DIS'; --Change this is it is surcharge
l_adj_rec.arithmetic_operator := 'AMT'; --Percentage or amount
l_adj_rec.operand := 10; --How much?
l_adj_rec.operation := oe_globals.g_opr_create;
l_adj_rec.line_index := 1;
l_adj_rec.update_allowed := 'Y';
l_adj_rec.applied_flag := 'Y'; --this is required to change the price of the line
l_adj_rec.change_reason_code := 'MANUAL';
l_adj_rec.change_reason_text := 'Manually applied adjustments';
l_adj_tbl (1) := l_adj_rec;
l_control_rec.process_entity := oe_globals.g_entity_line_adj;
l_control_rec.process := TRUE;
oe_order_pub.process_order (p_api_version_number => 1.0
, x_return_status => l_return_status
, x_msg_count => x_msg_count
, x_msg_data => x_msg_data
, p_header_rec => l_x_header_rec
, p_header_adj_tbl => l_x_header_adj_tbl
, p_header_scredit_tbl => l_x_header_scredit_tbl
, p_header_payment_tbl => l_x_header_payment_tbl
, p_line_tbl => l_x_line_tbl
, p_line_adj_tbl => l_adj_tbl
, p_line_scredit_tbl => l_x_line_scredit_tbl
, p_line_payment_tbl => l_x_line_payment_tbl
, p_lot_serial_tbl => l_x_lot_serial_tbl
, p_action_request_tbl => l_prc_adj_request
, p_header_price_att_tbl => l_x_header_price_att_tbl
, p_header_adj_att_tbl => l_x_header_adj_att_tbl
, p_header_adj_assoc_tbl => l_x_header_adj_assoc_tbl
, p_line_price_att_tbl => l_x_line_price_att_tbl
, p_line_adj_att_tbl => l_x_line_adj_att_tbl
, p_line_adj_assoc_tbl => l_x_line_adj_assoc_tbl
, x_header_rec => x_header_rec_type
, x_header_val_rec => x_header_val_rec_type
, x_header_adj_tbl => x_header_adj_tbl_type
, x_header_adj_val_tbl => x_header_adj_val_tbl_type
, x_header_price_att_tbl => x_header_price_att_tbl_type
, x_header_adj_att_tbl => x_header_adj_att_tbl_type
, x_header_adj_assoc_tbl => x_header_adj_assoc_tbl_type
, x_header_scredit_tbl => x_header_scredit_tbl_type
, x_header_scredit_val_tbl => x_header_scredit_val_tbl_type
, x_header_payment_tbl => x_header_payment_tbl_type
, x_header_payment_val_tbl => x_header_payment_val_tbl_type
, x_line_tbl => x_line_tbl_type
, x_line_val_tbl => x_line_val_tbl_type
, x_line_adj_tbl => x_line_adj_tbl_type
, x_line_adj_val_tbl => x_line_adj_val_tbl_type
, x_line_price_att_tbl => x_line_price_att_tbl_type
, x_line_adj_att_tbl => x_line_adj_att_tbl_type
, x_line_adj_assoc_tbl => x_line_adj_assoc_tbl_type
, x_line_scredit_tbl => x_line_scredit_tbl_type
, x_line_scredit_val_tbl => x_line_scredit_val_tbl_type
, x_line_payment_tbl => x_line_payment_tbl_type
, x_line_payment_val_tbl => x_line_payment_val_tbl_type
, x_lot_serial_tbl => x_lot_serial_tbl_type
, x_lot_serial_val_tbl => x_lot_serial_val_tbl_type
, x_action_request_tbl => x_request_tbl_type
DBMS_OUTPUT.put_line (l_return_status);
IF x_msg_count > 0
THEN
FOR v_index IN 1 .. x_msg_count
LOOP
oe_msg_pub.get (p_msg_index => v_index, p_encoded => 'F', p_data => x_msg_data, p_msg_index_out => v_msg_index_out);
x_msg_data := SUBSTR (x_msg_data, 1, 200);
DBMS_OUTPUT.put_line (x_msg_data);
DBMS_OUTPUT.put_line ('============================================================');
END LOOP;
END IF;
END;
Thanks
Nagamohan

Unit Selling Price in OM

Hi All,
I am new in OM. i just want to know when my user enter and modified unit selling price the message shows no list of values contain no entries, please advice how can i add its list or how can i use range of list against list.
Thanks

Dear All,
Please advice above issue
thanks

Cannot manual adjustment unit selling price for Retrobill order

Dears,
I try formpersonalzation to set to update allowed and alterable,but still cannot update unit selling price?
there is a message:
Get_manual_adjustment#2 ORA-01403:no data found in Package oe_order_adj_pvt Procedure oe_line_adj.calulate_adjustments
Edited by: user6911393 on 2011/5/18 下午 9:00
Is there method can find the way to adjustment unit selling price manually fro Retrobill order?
Thank you very much!

Dears,
I try formpersonalzation to set to update allowed and alterable,but still cannot update unit selling price?
there is a message:
Get_manual_adjustment#2 ORA-01403:no data found in Package oe_order_adj_pvt Procedure oe_line_adj.calulate_adjustments
Edited by: user6911393 on 2011/5/18 下午 9:00
Is there method can find the way to adjustment unit selling price manually fro Retrobill order?
Thank you very much!

Unit selling price is not updating

Hi
I am updating unit selling price of an item using API.
code:
   v_line_tbl (1).request_date := SYSDATE;
   v_line_tbl (1).unit_selling_price := 299;
in the above code request_date is updating to sysdate but selling price is not updating.
how to do this?
Thanks

The CALCULATE_PRICE_FLAG is in the OE_ORDER_LINES_ALL table. This setting could override determines pricing engine calls which could be overriding your update.
Values -
Calculate Price (Y)
Partial Price (P)
Freeze Price (N)
Thank you,
Debbie

Sales Order - Unit Selling Price - Format Mask

Hi,
I want to change Format Mask of Unit Selling Price column on Sales Order Form. By using Forms Personalization it is not being done.
Please guide me how could I change its format mask from 5 decimal places to 2 decimal places.
Regards
Waqas Hassan

Hi Waqas,
In the define Currency form in GL setup, change the existing currency code precision to 2.
this should resolve your issue.
Make sure you logout and login back to recheck the issue.
General Ledger Super User-->Setup-->Currency-->Define.
Thanks
-Arif.

Need Sample API code to update Quote Line level Unit Selling Price alone.

Hi,
i want to update Unit Selling Price alone using API, can any one have sample code to do that.
ASO_QUOTE_PUB.Update_Quote_Line
Thanks!
Kishore

Hi,
please find the code below for ASO Quote Line Update. Here this sample only shows an DFF Attribute update. You can try the same for the Unit Selling price Update.
DECLARE
l_Api_Version_Number NUMBER;
l_Init_Msg_List VARCHAR2(1000);
l_Commit VARCHAR2(1000);
l_Validation_Level      NUMBER;
l_Qte_Header_Rec ASO_QUOTE_PUB.Qte_Header_Rec_Type;
l_Qte_Line_Rec ASO_QUOTE_PUB.Qte_Line_Rec_Type;
l_Control_Rec ASO_QUOTE_PUB.Control_rec_Type;
l_Qte_Line_Dtl_TBL ASO_QUOTE_PUB.Qte_Line_Dtl_tbl_Type;
l_Line_Attribs_Ext_Tbl ASO_QUOTE_PUB.Line_Attribs_Ext_Tbl_type;
l_Payment_Tbl ASO_QUOTE_PUB.Payment_Tbl_Type;
l_Price_Adj_Tbl ASO_QUOTE_PUB.Price_Adj_Tbl_Type;
l_Price_Attributes_Tbl ASO_QUOTE_PUB.Price_Attributes_Tbl_Type;
l_Price_Adj_Attr_Tbl ASO_QUOTE_PUB.Price_Adj_Attr_Tbl_Type;
l_Shipment_Tbl ASO_QUOTE_PUB.Shipment_Tbl_Type;
l_Tax_Detail_Tbl ASO_QUOTE_PUB.Tax_Detail_Tbl_Type;
l_Freight_Charge_Tbl ASO_QUOTE_PUB.Freight_Charge_Tbl_Type;
l_Sales_Credit_Tbl ASO_QUOTE_PUB.Sales_Credit_Tbl_Type;
l_Quote_Party_Tbl ASO_QUOTE_PUB.Quote_Party_Tbl_Type;
l_Update_Header_Flag VARCHAR2(100);
X_Qte_Line_Rec ASO_QUOTE_PUB.Qte_Line_Rec_Type;
X_Qte_Line_Dtl_TBL ASO_QUOTE_PUB.Qte_Line_Dtl_TBL_Type;
X_Line_Attribs_Ext_Tbl ASO_QUOTE_PUB.Line_Attribs_Ext_Tbl_type;
X_Payment_Tbl ASO_QUOTE_PUB.Payment_Tbl_Type;
X_Price_Adj_Tbl ASO_QUOTE_PUB.Price_Adj_Tbl_Type;
X_Price_Attributes_Tbl ASO_QUOTE_PUB.Price_Attributes_Tbl_Type;
X_Price_Adj_Attr_Tbl ASO_QUOTE_PUB.Price_Adj_Attr_Tbl_Type;
X_Shipment_Tbl ASO_QUOTE_PUB.Shipment_Tbl_Type;
X_Tax_Detail_Tbl ASO_QUOTE_PUB.Tax_Detail_Tbl_Type;
X_Freight_Charge_Tbl ASO_QUOTE_PUB.Freight_Charge_Tbl_Type;
X_Sales_Credit_Tbl ASO_QUOTE_PUB.Sales_Credit_Tbl_Type;
X_Quote_Party_Tbl ASO_QUOTE_PUB.Quote_Party_Tbl_Type;
lX_Return_Status VARCHAR2(1000);
lX_Msg_Count NUMBER;
lX_Msg_Data VARCHAR2(1000);
     lc_last_update_date date;
     l_file varchar2(2000);
     CURSOR c_quote(c_qte_header_id NUMBER) IS
     SELECT last_update_date
     FROM ASO_QUOTE_HEADERS_ALL
     WHERE quote_header_id = c_qte_header_id;
BEGIN
     BEGIN
     MO_GLOBAL.init('SQLAP');
     MO_GLOBAL.set_policy_context('S',83);
     fnd_global.apps_initialize(1175,50689,280);
     END;
     OPEN c_quote(l_qte_header_rec.quote_header_id);
     FETCH c_quote INTO lc_last_update_date;
     CLOSE c_quote;
     aso_debug_pub.SetDebugLevel(10);
aso_debug_pub.Initialize;
l_file:= ASO_DEBUG_PUB.Set_Debug_Mode('FILE');
aso_debug_pub.debug_on;
aso_debug_pub.add('Update Quote',1, 'Y');
dbms_output.put_line('File :'||l_file);
dbms_output.put_line( to_char(sysdate, 'mm/dd/yyyy:hh24:SS') );
     l_qte_header_rec.quote_header_id := 24649;
     l_qte_header_rec.last_update_date := lc_last_update_date;
     l_control_rec.last_update_date := lc_last_update_date;
     l_qte_line_rec.quote_header_id := 24649;
     l_qte_line_rec.quote_line_id := 27712;
     l_qte_line_rec.attribute12 := 1000;
     ASO_QUOTE_PUB.Update_Quote_Line(
P_Api_Version_Number => '1.0',
P_Init_Msg_List =>     l_Init_Msg_List,
P_Commit =>     l_Commit,
P_Qte_Line_Rec =>     l_Qte_Line_Rec,
P_Control_Rec =>     l_Control_Rec,
P_Qte_Line_Dtl_Tbl =>     l_Qte_Line_Dtl_Tbl,
P_Line_Attribs_Ext_Tbl =>     l_Line_Attribs_Ext_Tbl,
P_Payment_Tbl =>     l_Payment_Tbl,
P_Price_Adj_Tbl =>     l_Price_Adj_Tbl,
P_Price_Attributes_Tbl =>     l_Price_Attributes_Tbl,
P_Price_Adj_Attr_Tbl =>     l_Price_Adj_Attr_Tbl,
P_Shipment_Tbl =>     l_Shipment_Tbl,
P_Tax_Detail_Tbl =>     l_Tax_Detail_Tbl,
P_Freight_Charge_Tbl =>     l_Freight_Charge_Tbl,
P_Update_Header_Flag =>     l_Update_Header_Flag,
X_Qte_Line_Rec =>     X_Qte_Line_Rec,
X_Qte_Line_Dtl_Tbl =>     X_Qte_Line_Dtl_Tbl,
X_Line_Attribs_Ext_Tbl =>     X_Line_Attribs_Ext_Tbl,
X_Payment_Tbl =>     X_Payment_Tbl,
X_Price_Adj_Tbl =>     X_Price_Adj_Tbl,
X_Price_Attributes_Tbl =>     X_Price_Attributes_Tbl,
X_Price_Adj_Attr_Tbl =>     X_Price_Adj_Attr_Tbl,
X_Shipment_Tbl =>     X_Shipment_Tbl,
X_Tax_Detail_Tbl =>     X_Tax_Detail_Tbl,
X_Freight_Charge_Tbl =>     X_Freight_Charge_Tbl,
X_Return_Status =>     lX_Return_Status,
X_Msg_Count =>     lX_Msg_Count,
X_Msg_Data =>     lX_Msg_Data
fnd_msg_pub.count_and_get( p_encoded => 'F'
, p_count => lx_msg_count
, p_data => lx_msg_data);
dbms_output.put_line('no. of FND messages :'||lx_msg_count);
for k in 1 .. lx_msg_count loop
lx_msg_data := fnd_msg_pub.get(
p_msg_index => k,
p_encoded => 'F');
dbms_output.put_line('Error msg: '||substr(lx_msg_data,1,240));
end loop;
dbms_output.put_line(lx_return_status);
dbms_output.put_line(to_char(lx_msg_count));
dbms_output.put_line(lx_msg_data);
dbms_output.put_line('end');
END;
COMMIT;
Thanks
Sunil Devulapally
Edited by: user13150483 on 05-Jan-2012 10:59

Unit of measure - rounding off during creation of planned order

Dear All,
We have defined one material OIL in MM41 and its UoM is EA also we have put alternative UoM is L(liter).
now we create BOM of semifinished material we use this oil as a component and enter its value in decimal points.
e.g 0.375 EA
During planned order creation or REM backflush system convert this quantity to 1 EA ,WE dont want this automatic conversion .
We have uploaded all master data in production and now it is very difficult to change all BOM
So what is the solution of this that system can not convert qty (rounding off).EA
Kindly reply
Sunil

Hi Sunil,
IN CUNI Transaction Field Decimal Places is for displaying the decimals,there is a decimal place Rounding off field below,there try to maintain 3 decimals and check whether it is working.
One more thing is Unit EA will be used always as non decimal unit,But i dont know in your buisness how for unit EA there is a decimal qty
Edited by: Girish Adaviswamy on Mar 2, 2010 10:59 AM

Unit selling price and list price

all

>
I am getting internal_function within explain plan filter section at step 17 ,18 and 22, i know it is an overhead but why it is happening how can i come to know please help
>
That is just how Oracle is processing your IN clause
oha.org_id In
('122', '82', '222', '166', '142', '182', '162', '164', '203', '262')It caches' those hard-coded values in a hash table and uses an internal function to implement the 'IN' part of your query by using 'oha.orgid' as the search parameter to the hash table.
Nothing to worry about from a performance issue unless maybe you had hundreds or thousands of hard-coded values for the IN clause. Even then a hash table is far quicker that accessing a real table.

How to round off quantity in inventory

Hi,
How to avoid decimal places for PC(Piece) in the goods movement transactions.. I have given 0 decimal places in CUNI transaction. It is working properly for Production Order during Conrimation but it is not working in Inventory transactions like MIGO, MB1C,MB1A....
for example When I enter Unint of entry In Alternate Unit say '10 KG' System Automatically Caliculates quantity in base unit in decimal places say 115.012 PC based on the conversion factor defined in material master.
My requiremet is the base unit quantity PC rounded off to nearest value in as 115 (PC).
The same thing is working fine for production order.
please suggest me how to do.
Thanks,
Shekar

this all depends on your conversion rate enterd in material master.
if 115.012 PC equals 10 KG.
what do you actually want the system to do,
it would now that you would get 115.012
you want it to be 115,
this would then mean that you have to modify the entered quantity from 10 to 9something
Is it that what oyu want?
you certainly cannot have 115 PC and 10 KG if you dont change the conversion rate in your material master

How to selling price is derive in Sale order

Hi ,
I have an selling price rounding issue. Price list of an item is 5.25 and the discout is 2.125 generaly selling price should be 3.075. But it showing 3.07... is there any setup in oracle to round the selling price in oracle?

I have gone through some documents and I found some information about rounding of price.
QP: Selling Price Rounding Options :- is the profile having different values. and for each value different different property
Values
NO: = unrounded listprice + unrounded adjustments: No rounding is done.
Individual: = round (listprice) + round (adj): The adjustments are calculated using rounded list price.
Additive: = round (listprice + adj); unrounded Freight: The adjustments are calculated using unrounded list price.
In my application this profile is set to :"Additive". So for the example which I posted above, the selling price should come 3.8,round(5.25 + (-2.175),2). But it came as 3.07.
Can anyone tell why this is truncating the value instead of rounding? or is there any other standard functionality behind it?

Find out the Selling Price and Unit Price.

Hi All,
Am trying to get the Selling and Unit Price Before an Order Creation and Quote , from the API of " QP_PREQ_PUB.PRICE_REQUEST " ,. based on Item ID , Quantity and two Modifiesrs(Price List ID and Order Type ID).
i can get Selling Price and Unit from Temp table " qp_preq_lines_tmp ". after execution of Above API .
but I am getting Unit Price correctly and about Selling Price, its dispaly the Priec as same as Unit Price only .
I Dont' know what step i missed .
Have anyone developed similar API for getting the Selling Price and Unit Price for an Item ?.
Any suggestions are appreciated.
Regards,
Shan

Hi Shan,
I saw your posting on Oracle forum that is why I am sending this email to you.
I have been using QP_PREQ_PUB.PRICE_REQUEST to pass item to get item list price thru Oracle Price Engine. I get Item list price without any issues the only thing I am stuck is when that item has multiple modifiers then item price I get is without applying modifiers.
My case: When Item KD653 3/3MAT has 'X' price list and price of that item is set to 600.00. I have a modifier defined and that includes/qualifies above item for 10% discount. So when I pass my pameters like inv_item_id, list_header_id etc I get 600.00 not 540.00. So I am passing two lines one for regular item list price (600.00) and second for modifier that I have created for this item.
Result: I get 600.00 Item Price but I don't get modified (10%) price applied to unit price. Also it doesn't recognize my list_header_id that I am passing for my modifier.
I may be missing something to trigger the modifier part. If you got case details then that will be great.
Your help will be highly appreciated in this case.
Regards,
Prakash

Rounding off value problem in sales order

Hi All,
This is related to a rounding off value problem in sales order.
The problem is described by an example which is as follows -
Selling Price of Material A = Rs. 176.76
Excise charged = Rs. 21.80
Total Price = Rs.176.76 + Rs.21.80 = Rs. 198.56
On this total Trade Discount (ZDTD) having access sequence,is calculated at the rate of 4% = Rs. 7.94
But the condition base value after the discount is showing Rs.198.60 instead of Rs.198.56
I want the system to reflect the value as Rs.198.56 intact and it should not round up to the nearest value i.e. Rs. 198.60
Why is this happening? Is it possible to reflect the exact value? If yes what is needed to be done?
The commercial round off is activated for the DIFF Condition Type.
Looking forward to some valuable suggestions.
Thanks & Regards
Priyanka Mitra

Hi Ramesh,
Thanks for your suggestion but the problem has been solved by me.
Regards
Priyanka Mitra

Unit Selling Price - Round Off

Similar Messages

Maybe you are looking for