RMA 생성시 CREDIT PRICE가 EXTENDED PRECISION이 적용되지 않는 문제

제품 : MFG_OE
작성날짜 : 2003-05-16
RMA 생성시 CREDIT PRICE가 EXTENDED PRECISION이 적용되지 않는 문제
=======================================================
PURPOSE
Original Order를 참조하여 RMA 생성시 Credit Price가 extended precision이 적용되지 않는다. 일반 user들은 이 상황을 문제로 제기하지만 이는 현재 standard function이며 11,11i 동일하게 design 되어 있다.
Explanation
Currency standard precision = 2, Extended precision = 5 로 정의되어 있
고, Prifle option-unit price precision type이 'Extended', OM(OE)에서
사용하는 price list rounding factor = -2 인 경우.
Order 생성시 selling price = 1.63200으로 입력,
이 order를 참조하여 RMA를 생성하면 Credir price = 1.63000으로 조회된다.
이 경우 대부분의 고객은 RMA credit price가 orginal order의 selling price
인 1.63200 으로 조회되는것이 맞는 function이라 생각하나, 현재 design은
extended precision 과 무관하게 사용한 price list rounding factor 값을
기준으로 credit price를 입력하고 있다.
다음은 bug 1316874에 developer가 update한 내용이며 이는 11i에서도 동일
하게 적용된다.
If Customer wants to see the price of the item up to 3 decimal place,
they should NOT make the rounding factor of the Price List -2.
Instead they should set the rounding factor as -3.
If the OE:Unit price Precision Type is EXTENDED and Extended Precision is 5, then it would be logical to set the rounding factor of Price List as -5 only, in order to avoid any rounding off.
While displaying the unit price, OE takes care of both Precision
and Price List Rounding Factor.
I checked both Sales Order form and RMA forms and the behavior is same.
Even the original price at discount screen (RMA form) also displayed
the price rounded to the price list rounding factor.
All of the fields show price in EXTENDED precision (as desired) and
round off the price to the PRICE LIST ROUNDING FACTOR (as desired).
결론적으로 OM(OE)의 보여지는 price 자리수는 extended precision을 따르지만,price의 round off는 price list rounding factor에 따라 결정된다.
Example
Reference Documents
bug 1316874

Similar Messages

  • ITEM CREDIT PRICE CHANGED

    Hello Gurus,
    We have an issue in sale order. It is like this. When we change the confirmed quantity in the sales order the item price is changing by few decimals. When we searched for notes we found in one note that it is system standard behaviour. But we asked SAP to check the issue in our system.
    In the example sales order from the production system the change log mentions that item credit price is changed in VKM4 but we could not replicate the same in quality system. We could only replicate the change in VA02.
    Now my question is how can we make any changes in the sales order from t-code VKM4
    Can anybody suggest me.
    Regards
    Prabhu

    Generally, In the change log the system takes,  the base transaction which is used. when we use VKM3/VKM4 the system goes into the sales order and makes the relavant changes like status change etc. The change mode of the sales order is called inside the VKM4 transaction.
    This is applicable to any transaction,  if you are using any FM to change the data in the sales order,the system shows SE37 as the transaction code used..

  • Convert binary bytes to Labview Extended Precision type

    Hello All:
    I am reading a binary file that was written in Windows. One of the types used in the data structure
    is the Delphi extended precision type, which is 10 bytes. When reading this in using Labview's
    "read binary file" VI, there is only one choice, and that is to read it in as an array of 10 bytes
    (Labview's extended precision is 16 bytes.) I have tried using the type cast with no results.
    So....how to convert the data in the 10 byte array to a 16 byte extended precision format in
    Labview? I guess part of the problem is not really understanding how the extended precision
     type is stored in IEEE format.
    Has anyone performed this conversion before that could help out? I'm sure this must have
    been done by someone....somewhere....I have no hair left....
    Any help would be appreciated!
    Thanks,
    Gary.

    Uhm, something must have gone wrong, the link TST sent,
    mentions that LabVIEW stores extended data as 80 bit (10 bytes) on Intel platform.
    Complex double is stored as two doubles (=16 byes). My guess is that Altenbach's latest note mentioning the endianess should help you.
    If the endiannes is right you should be able to just typecast the data:
    Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
    Nederlandse LabVIEW user groep www.lvug.nl
    My LabVIEW Ideas
    LabVIEW, programming like it should be!

  • Credit price field in  VBRP

    Hello ,
    Why  some  of  the  discounts  are  not  included
    in the  credit  price  field  calculation  VBRP-CMPRE?
    Is  this  customizing  issue  of  the  discount  conditions?
    Thanks and  Best  regards
    L

    Hi,
    Your question is not clear.
    If your credit management is active and if you assign Subtotal as 'A' in your pricing procedure after all your calculations are done, the Net amount while will be verified for credit check will appear in VBRP-CMPRE.
    This has nothing to do with dicount conditions. If you want some discount condition to appear in VBRP, you will have to assign a subtotal to it, and then it will update VBRP for KZWI1, KZWI2, etc fields.
    Hope it is clear.
    Regards,
    Amit

  • Extended precision variable declaratio​n in formula node?

    I'm looking for a way to define my variables inside my formula node as extended precision but everytime I attempt this, I get an error.  To my understanding, the declaration should be "long double" but it does not seem to work.  Anyone have any ideas?
    Greycat

    Thanks Dennis ... I guess sometimes it seems quicker to ask instead of looking... but then I found what you were referencing very quickly.  Just being lazy I suppose!!!  Anyway, thanks for the help.
    Greycat

  • Item credit price changed in Sales order - credit management.

    Dear Friends,
    In Sale order item change log shows ' item credit price changed' . Item credit price  comes from 'Total ' value line in pricing which is the sum or prices and taxes. But where as none of prices and taxes that contribute to this total have been changed,  the change long shows item credit price as changed from a value to other .
    This sale order has many items and for most items same is the case. For some items it looks like quanity got confirmed eventually through back order or availability check from VA02. The  change log for the document also shows 'credit released value' also as changed.
    User wants to know how item credit price which is nothing but total value line is shown as changed when none of the prices and taxes have been changed
    Could someone throw light on this?
    Regards
    Mahesh.

    Hi Murali ,
          First, Thanks for the reply .
        In this issue what happened is,  after couple of items  added, the sales order was released for credit check. Later changes have been made to this credit released document either by way of adding new items or by confirming the availability check for some items . Because of this change log is showing ' realeased credit vlaue' as changed from certain vlaue to the other . How this could have affected change in item credit price    which is coming form toal value line which is nothing but netvalue ( price -disccount+ taxes assingend with subtoal 'A' ) ?
    What exactly is the concept of released credit value and its relation to item credit price ?
    As per releasing the document that is not a problem but user's request is he  wants to know why this is happening .
    Please help me in understanding this better.
    regards
    Mahesh

  • Do numerical indicators display extended precision floats correctly?

    I'm using windows XP sp2 on a new computer with a new intel processor, nothing weird. I'm displaying an extended precision floating point number using a numeric indicator that is set to display an extended data type with thirty digits of precision. I expect to see at least 19 or 20 significant digits out of my extended precision float, but the numeric indicator only ever displays 17 significant digits before going to a trail of zeros. Does the display routine that converts the float to a display string use double precision or what?
    global variables make robots angry

    Yes, I understand what you are saying and you are completely correct. The problem I have is not that I expect a mathematically perfect representation of a number, but rather that LabVIEW calculates and produces an 80-bit extended precision number on my computer and then appears to convert it to a 64-bit representation of that number before displaying it!
    If you convert the extended precision value into an unflattened string in order to attempt to access the binary representation of the data, you’ll find that it is represented by 80-bits. This is a 64-bit fraction plus a 15-bit exponent plus one bit for the sign. Delightfully, the flatten to string function appears to scramble the bits into “noncontiguous” pieces, so about all I can tell for certain is that we have, as expected, an 80-bit extended precision number in memory. The documentation for the other number-to-Boolean array and bit manipulation functions I looked at (even the exponent-mantissa function) all claim to only be able to handle a maximum input of a 64-bit number (double precision float max) -correct me if I’m wrong on this one, because I’d really like to be able to see the contiguous binary representation of 80-bit extended floats.
    It turns out though that what you said about not being able to tell whether we have twenty digits of precision without bit fiddling is not true at all. If you look at the program I wrote, you can prove with simple addition and subtraction that beyond the shadow of a doubt the extended numbers are being stored and calculated with twenty digits of precision on my computer yet being displayed with less precision.
    As you can plainly see in the previous example I sent:
    A =          0.1111111111
    B =         0.00000000001111111111
    A+B=C= 0.11111111111111111111
    We know that
    C-A=B
    The actual answer we get is
    C-A=0.00000000001111111110887672
    Instead of the unattainable ideal of
    C-A=0.00000000001111111111
    The first nineteen digits of the calculated answer are exactly correct. The remainder of the actual answer is equal to 88.7672% of the remainder of the perfect answer, so we effectively have 19.887672 digits of accuracy.
    That all sounds well and good until you realize that no individual number displayed on the front panel seems to be displayed with more than 16-17 significant digits of accuracy.
    As you see below, the number displayed for the value of A+B was definitely not as close to being the right answer as the number LabVIEW stores internally in memory.
    A+B=0.11111111111111111111 (the mathematically ideal result)
    A+B=0.111111111111111105     (what LabVIEW displays as its result)
    We know darned well that if the final answer of A+B-A was accurate to twenty digits, then the intermediate step of A-B did not have a huge error in the seventeenth or eighteenth digit! The value being displayed by LabVIEW is not close to being the value in the LabVIEW variable because if it were then the result of the subtract operation would be drastically different!
    0.11111111111111110500       (this is what LabVIEW shows as A+B)  
    0.11111111110000000000       (this is what we entered and what LabVIEW shows for A)
    0.00000000001111110500    (this is the best we can expect for A+B-A)
    0.00000000001111111110887672 this is what LabVIEW manages to calculate.
    The final number LabVIEW calculates magically has extra accuracy conjured back into it somehow! It’s more than 1000 times more accurate than a perfect calculation using the corrupted value of A+B that the display shows us – the three extra digits give us three orders of magnitude better resolution than should be possible unless LabVIEW is displaying a less accurate version of A+B than is actually being used!
    This would be like making a huge mistake at the beginning of a math problem, and then making a huge mistake at the end and having them cancel each other out. Except imagine getting that lucky on every answer on every question. No matter what numbers I plug into my LabVIEW program, the intermediate step of A+B has only about 16-17 digits of accuracy, but miraculously the final step of A+B-A will have 19-20 digits of accuracy. The final box at the bottom of the program shows why.
    If you convert the numbers to double and use doubles to calculate the final answer, you only get 16-17 digits of accuracy. That’s no surprise because 16 digits of accuracy is about as good as you’re gonna do with a 64-bit floating point representation. So it’s no wonder all the extended numbers I display appear to only have the same accuracy as a 64-bit representation because the display routine is using double precision numbers, not extended precision.
    This is not cool at all. The indicator is labeled as being able to accept an extended precision number and it allows the user to crank out a ridiculous number of significant digits. There is no little red dot on the input wire telling me, ‘hey, I’m converting to a less accurate representation here, ok!’ Instead, the icon shows me ‘EXT’ for ‘Hey, I’m set to extended precision!’
    The irony is that the documentation for the addition function indicates that it converts input to double. It obviously can handle extended.
    I’ve included a modified version of the vi for you to tinker with. Enter some different numbers on the front panel and see what I mean.
    Regardless of all this jazz, if someone knows the real scoop on the original question, please end our suffering: Can LabVIEW display extended floating point numbers properly, or is it converting to double precision somewhere before numerals get written to the front panel indicator?
    Message Edited by Root Canal on 06-09-2008 07:16 PM
    global variables make robots angry
    Attachments:
    numerical display maxes out at double precision 21.vi ‏17 KB

  • Credit Price--Sales Order

    Hi all,
    I want to know for a sales document, where is the u2018credit priceu2019 stored?
    Thanks,
    Akash.

    Hello Akash,
    The credit price can be found in VBAP-CMPRE.
    I hope this helps.
    Rgds,
    Raghu.

  • RMA Credit only

    Hi,
    There is a std feature wherein we can process credit through RMA without any actual receipt of product. I understand that Credit memo is generated which is linked AR Invoice. However, I want to understand the impact on Inventory?
    Is it advisable to accept return of damanged goods and thereafter writ-off in inventory to have real picture of stock??
    Please advice.
    Thanks
    supriya

    Do you physically receive the goods?
    If you don't, you can simply use the RMA account for identifying how much material was bad.
    Most businesses received the goods back. This is done to ensure valid RMA and to analyze defects in the products.
    You can receive the RMA into an Expense subinventory. This way, you hit the expense account automatically and there is no need to perform another write off tranaction.
    Hope this helps,
    Sandeep Gandhi

  • Requisition Lines price decimal precision

    Dear All,
         I enter a price in Requisition Lines as follow:
           Price             Price (SGD)       Amount (SGD)
        120USD      151.524962766302          151.52It is expected that the price will appear as 151.52 rather than 151.524962766302
    My environment is: ORACLE R12.1.3
    Regards
    Terry

    Hi Terry,
    Your issue seems to be related to Price and linked to GL Currency conversion and rounding. Basically you are creating a requisition with foreign currency and don't want to restrict the rounding to 2 decimal places.
    You can address this issue by setting up the precision under Currencies setup of GL for SGD (GL --> Setup --> Currencies --> Define --> Change Precision as per your requirement) . But the risk is, this change in precision will affect across all modules. It is widely accepted to use rounding to 2 decimal places.
    Choice is yours. :)
    Kind Regards,
    S.P DASH

  • AppleCare vs. credit card extended warranty

    Hi, I'm considering buying my first Mac (the Macbook Pro). Regarding the AppleCare extended warranty: is this worthwhile? My credit card company provides an additional year of warranty coverage (for a total of two years), although I don't know how this would relate to having the Mac serviced by an authorised Apple technician.
      Windows XP Pro  

    I have to agree with the other poster. With my TiBook Apple took such good care of me that I think AppleCare with a laptop is a great deal.
    I was able to use my tibook for 4 1/2 years thanks to applecare. One of the great examples of AppleCare is simple things like get the mac to them and back.
    Apple shipped me a great padded box/shipping kit, overnight. Then I shipped it back to them overnight and they got it back to me the next day. It was like magic. Your credit card is not going to help with that.

  • String convert extended precision

    I'm writing a vi that sets a time stamp using the "Get Date/Time In Seconds.vi", converting the time stamp format into a double to get seconds, then I'm saving it as a string to a text file. When I read in the string from the file and use the "Decimal String To Number.vi" the output is limited to I32, which truncates the number to the upper I32 integer limit value of 2^31-1.
    Is there a better way to store a time stamp and do a later comparison, or convert the string directly into a double format from the file?
    Thanks!

    wawatts wrote:
    Is there a better way to ... convert the string directly into a double format from the file?
    Use the "Fract/Exp String To Number" function, not "Decimal String To Number" which converts strings to base10 integers (as you found out).
    =====================================================
    Fading out. " ... J. Arthur Rank on gong."

  • Possible bug: Saving array with extended and double precision to spreadshee​t

    If one concatenates a double precision array and an extended precision array with the "build array" vi and then saves using "Write to Spreadsheet File" vi any digits to the right of the decimal place are set to zero in the saved file. This happens regardless of the format signifier input (e.g. %.10f) to the  "Write to Spreadsheet File" vi.
    I am on Vista Ultimate 32 bit and labview 9.0
    This is a possible bug that is easily circumvented by converting to one type before combining arrar to a spreadsheet. Nonetheless, it is a bug and it cost me some time.
    Solved!
    Go to Solution.
    Attachments:
    Spreadsheet save bug.vi ‏9 KB

    Hi JL,
    no, it's not a bug - it's a feature
    Well, if you would look more closely you would recognize the "Save to Spreadsheet" as polymorphic VI. As this polymorphic VI doesn't support EXT numbers internally (it only supports DBL, I64 and String) LabVIEW chooses the instance with most accuracy: I64 (I64 has 64 bits precision, DBL only 53...). So your options are:
    - set the instance to use as DBL (by right-click and "Select type...")
    - make a copy of this VI, save it with a different name and make it support EXT numbers (don't rework the polymorphic VI as you would break compatibility with other LV installations or future revisions)
    And yes, those coercion dots always signal some conversions - you should atleast check what's going on there...
    Message Edited by GerdW on 05-21-2010 10:01 PM
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • 11,10.7 VERSION에서 RMA 생성 방법

    제품 : MFG_OE
    작성날짜 : 2003-04-22
    11,10.7 VERSION에서 RMA 생성 방법
    ===========================
    PURPOSE
    11i version에서는 모든 process가 workflow를 통해 진행되어 WF background engine만 running 중이면 user가 특별히 취해야 할 action이 없다. 하지만 10.7, 11의 order entry의 경우 WF process를 이용하지 않기 때문에 business process에 따라 user의 특별한 action이 필요한 경우가 있다.
    RMA 생성중엔 user가 해 주어야 할 작업이 많이 있으며 그 steps을 상세히 기술하였다.
    Explanation
    1. 이미 생성되어진 order를 이용
    2. NAV:Order/Return
    3. Customer 선택
    4. Type에 'RMA Credit'을 선택, 이 type은 seeded value
    5. Salesperson 입력
    6. Price List 선택
    7. 'Lines' area로 이동
    8. Type을 입력
    9. Invoice 번호를 선택
    This invoice must be from an order in Order Entry.
    You can also leave blank or Choose Purchase Order, or
    Sales Order, putting in their appropriate values.
    If you choose Sales Order then select your Sales Order number.
    If you choose Purchase Order, then you need to select your line
    (which associated with the Purchase Order)
    If you choose Invoice, your invoice needs to exist in Order
    Entry, but doesn't have to exist in Accounts Receivable yet.
    10. Reason 선택
    11. 반품 수량을 입력, positive amount를 이용
    12. 저장
    13. RMA를 book, Entry status가 'Booked'로 되는지 확인
    14. 생성된 Order number/RMA number를 기억
    15. NAV:View/Order 에서 RMA number를 입력 후 조회
    16. Cycle Status를 확인
    만약 'Sales Review'라면 이 status를 pass,
    NAV:Order/Approve
    Cycle action 선택하여 RMA number를 입력,
    Result를 'Pass'로 change
    17. NAV:View/Orders
    18. Next Zone to Line
    19. Status가 'RMA eligible'인지 확인
    20. NAV:Run/RMA Interface, parameter 없음
    21. RMA interface가 처음 실행되면 RMA 내역을 Inventory로 interface,
    Inventory에서 RMA data를 receive 해야만 함
    NAV:View/Orders
    Status가 'RMA Order Interfaced'인지 확인
    22. Responsibility를 Inventory로 변환
    23. Warehouse 선택
    24. NAV:Inventory/Transaction/RMA/Receive
    25. RMA number입력
    26. 조회
    27. Subinventory 선택 (ex,STORES)
    28. 저장
    29. Order Entry Responsibility로 전환
    30. NAV:View/Order
    31. RMA Number 입력
    32. Cycle Status가 'Interfaced'로 되었는지 확인
    33. NAV:Run RMA/Interface 재실행
    34. NAV:View/Orders
    Partially accepted or fully accepted 로 표시
    35. NAV:Run/Receivables/Interface
    Invoice source can be 'OE Import Standard' even though this is
    a credit memo. You can put the RMA number in the Order Field
    on the submission parameters.
    36. Receivable Responsibility로 전환
    37. Autoinvoice 실행,Source parameter에 'OE Import Standard',Order
    Number parameter에 'RMA number'를 입력
    Example
    Reference Documents
    -------------------

    No one 'round here works for MSI. We cannot help you with this.
    Please contact MSI (again....) in your region to get an answer to this question.
    >>How to contact MSI.<<
    Sorry, but this is all we can do for you... 

  • Letter of Credit for Vendor Payments

    Hi All,
    We are implementing ECC 6.0 Version.
    The client requirement is to create Letter of Credit for Vendors and to capture data relating issue of Letter of Credit, Terms of Payment and Expirition Date. Against a Single Letter of Credit issued to a vendor client may receive more than one Invoice till the Expiry period of the Letter of Credit and Value. Further, client may also amend the Old Letter of Credit by extending the validity period or the value of the LC.
    I know that we can create letter of credit through Special GL indicator 'L'. But it is one Letter of Credit to One invoice for clearing. How to map one letter of credit to multiple invoices and how we can capture expirition date of LC.
    Further same vendor can have multiple LC opened against them for different projects. Please let me know detailed configuration steps.
    Best Regards,
    Bhargav.
    Edited by: Bhargava  Ram on Oct 3, 2008 3:40 PM

    Hi,
    Sorry i guess my question is not clear. It is not to link any LC with PO
    The client will raise a single LC against any import vendor. Since these are large CAPEX related purchases, the vendor will send multiple invoices. The bank will adjust the LC against the invoices. Post adjustment the bank will send th advice to the company.
    My question was how we can adjust multiple invoices against a single LC
    THanks
    Sembian

Maybe you are looking for