locked
SalesOrder Details - How to force prices calculation ? RRS feed

  • Question

  • Hi all !

    I'm currently working on the order process for my organization. When I add a product to my order, the prices are calculated at the save time.

    My problem is that I need to do some calculations before saving the detail, but those calculations have to be based on the priceperunit value... wich doesn't get set before saving...

    I've tried to force the save by script on the uom change, but the save method reloads the form...

    Is there any way to force priceperunit calculation out of the save process ?

    How can i prevent the save method to calculate prices if I manage to calculate them on my own ?

    Thanks in advance !

    EuG

     

    Tuesday, April 27, 2010 9:24 AM

Answers

  • Hi EuG, 

    We had similar requirement in my first CRM project. We ended up using custom price attribute in order to have complete control. It was my very first CRM project, I was not the one who made the decision, I believe there was probably some struggle around native price attribute, so a decision was made before I joined the team. It was a CRM4 project as well, about one and half years ago. 

    Not sure if it will help, just a heads up. 

    Cheers,


    Daniel Cai | http://danielcai.blogspot.com
    • Marked as answer by EugeneMoulin Friday, May 7, 2010 9:42 AM
    Tuesday, April 27, 2010 2:02 PM
  • Hi !

    Finally, i've followed Daniel Cai's advice :

    We had similar requirement in my first CRM project. We ended up using custom price attribute in order to have complete control. It was my very first CRM project, I was not the one who made the decision, I believe there was probably some struggle around native price attribute, so a decision was made before I joined the team. It was a CRM4 project as well, about one and half years ago. 

    Not sure if it will help, just a heads up. 

    I've replaced all the prices fields by cutom ones, changed the views too, and every thing is goo now.

    Problem solved !

    EuG

    • Marked as answer by EugeneMoulin Friday, May 7, 2010 9:42 AM
    Friday, May 7, 2010 9:41 AM

All replies

  • Hi,

    Using "override price" option for Order Product might be helpful in your case.

     

    Regards,

    Nishant Rana

     


    http://nishantrana.wordpress.com
    Tuesday, April 27, 2010 11:25 AM
  • you could do a javascript web service call. on the OnChange event of the Unit (or product) you can pass this information thru a webservice call and retrieve the price per unit where pricelist = "selected pricelist" & product= "selected product" & unit = "selected unit". See http://blog.customereffective.com/blog/2008/02/calling-the-crm.html for more help!

     

    HTH

    bshah1985.

    Tuesday, April 27, 2010 12:47 PM
  • Thanks Nisha, but I need to keep the original prices, I just need to add some calculations to make the price.

    My prices are stored in a pricelist, and I use units, and so on...

    Thanks anyway !

     

    EuG

    Tuesday, April 27, 2010 12:54 PM
  • Thanks bshah !

    That's the way i figured out... But i wondered if there was another way.

    And I'm not sure the basic calculations will not override my owns..

    Thanks for your answer !

     

    EuG

    Tuesday, April 27, 2010 12:56 PM
  • Hi EuG, 

    We had similar requirement in my first CRM project. We ended up using custom price attribute in order to have complete control. It was my very first CRM project, I was not the one who made the decision, I believe there was probably some struggle around native price attribute, so a decision was made before I joined the team. It was a CRM4 project as well, about one and half years ago. 

    Not sure if it will help, just a heads up. 

    Cheers,


    Daniel Cai | http://danielcai.blogspot.com
    • Marked as answer by EugeneMoulin Friday, May 7, 2010 9:42 AM
    Tuesday, April 27, 2010 2:02 PM
  • Hi Daniel !

    Thanks for sharing this experience.

    I've thought about a custom price attribute, but, i'm afraid in this case that i have to do all the calculation by my side and that my attributes will propagate properly in invoices...

    I havn't thought about that much, had lots of things to do today...

    As I'm not short timed on this project, I'll try some different approaches tomorrow morning and i'll come back to you with my results...

    EuG

     

    Tuesday, April 27, 2010 3:43 PM
  • Hi !

    I've found a way through !

    I do all the calculations by my side and i fill thefields with my results.

    'all the calculations' include discount, tax, price per unit, price before tax, tax included price... all the prices are calculated by script.

    EuG

    • Marked as answer by EugeneMoulin Thursday, April 29, 2010 2:34 PM
    • Unmarked as answer by EugeneMoulin Monday, May 3, 2010 3:42 PM
    Thursday, April 29, 2010 2:34 PM
  • Sounds cool, glad that you have figured out on your own.

    One thing worth noting is that your CRM users may need to have Price Override privilege if you do so. If you use new role, the chances are the role may not have the privileges by default. 


    Daniel Cai | http://danielcai.blogspot.com
    Thursday, April 29, 2010 2:37 PM
  • Hi Daniel !

    Thanks a lot for this precision !

    As i'm working as admin, I didn't figured it out...

    But i've got a question anyway : I did not use the 'ispriceoverridden' attribute, i left it at false. I force the fields' content by using the DataValue and, as far as my tests went, i've seen no struggle with automatic calculation... Is that normal ? To be more precise, the priceperunit's value is read using the productpricelevel associated with the choosen unit.

    In fact, users only choose the product and a unit, and on the change event of the uom field, the calculations are done.

    Do you think i'd run in trouble this way ?

    I'll add the privilege to my users anyway, it can't hurt...

    EuG

    Thursday, April 29, 2010 2:46 PM
  • Hi all !

    Clouds have obscured the bright sky of my hopes...

    There is an issue with my prices calculation... 

    The fact is that in my business, discount is not governed by quantity of products in the same order, but by the number of orders fullfilled by the selected dealer on its contract duration. (that's why i needed dates as parameters in another post...)

    I've managed to implement this rule by adding a combo with the possible discount percentages (15%, 30%...) and I compute the discount and put my result in the volumediscountamount field. The manualdiscountamount is used for another purpose : make gifts in certain cases. So i can't use it to put my calculated discount.

    Then i've replaced the extendedprice field by one of my own. And i use it int the views instead of the original extendedprice It works well at the salesorderdetail level.

    The problems begin when i recompute the order. Recomputation seems to recompute the volumediscountamount instead of using the recorded value for volumediscountmaount for each salesorderdetail. And as the quantity is always 1, the discount is always 0...

    I'll open a new thread to ask if there is any way to override the recomputation process to have it using the recorded values instead of recomputing each of them...

    EuG

     

    Monday, May 3, 2010 3:42 PM
  • Hi !

    Finally, i've followed Daniel Cai's advice :

    We had similar requirement in my first CRM project. We ended up using custom price attribute in order to have complete control. It was my very first CRM project, I was not the one who made the decision, I believe there was probably some struggle around native price attribute, so a decision was made before I joined the team. It was a CRM4 project as well, about one and half years ago. 

    Not sure if it will help, just a heads up. 

    I've replaced all the prices fields by cutom ones, changed the views too, and every thing is goo now.

    Problem solved !

    EuG

    • Marked as answer by EugeneMoulin Friday, May 7, 2010 9:42 AM
    Friday, May 7, 2010 9:41 AM
  • Cool, great to know that you have got the solution!

    Cheers,


    Daniel Cai | http://danielcai.blogspot.com
    Friday, May 7, 2010 11:51 AM