Pricing discount based on daily order value

Dear All.
Any ideas on how to handle a scenario where a discount could be given if the customer meets a daily minimum order value?
Not sales order minimum order value, but if the cumulative order quantity across all sales orders for a customer in a given day meets the threshold they would then receive the discount.
Example:
mm/dd/yyyy (threshold = $100)
order 1 - 40, under threshold.
order 2 - 50, under threshold.
order 3 - 30, meets threshold.  Gets discount.
all remaining orders for the day get the discount.

Devon
1) My suggestion would be to include the threshold  by date in a custom Infostructure ( S500+)  in flexible planning- MC93.
2) Also activate Infostructure S001 for customer analysis to update synchronously.
3) Now include a Pricing Requirement  against the discount condition to compare the value in S001 with SXXX and  apply it only when the threshold is crossed.
4) Maintain Discount rate  in a (dummy) condition record, but you may need a alt. Cond. Base value formula also.
Hope this helps.

Similar Messages

  • How to handle vendor discounts based on the qty / value procured.

    Hello
           How to handle vendor discounts based on the qty / value procured.
    a.       Scenario: you have entered into a contract with vendor that you will buy goods worth Rs 10000/- and if you buy goods worth more than 100000 the vendor says he will give a discount of Rs 5000/- @ the end of the year.  
    i)                    How to handle this sceneriou2019s with SAu2019s
    ii)                   What does STD SAP offer.
    Regards
    Sapman man

    Hi,
    For the discucount condition type, you have to maintain scales.
    Take Condition type -  Discount Value ( RB00)
    Discount Value ( RB00) - Means Fixed discount. For this condition type, you have to maintain Scale basis as Value scale 'B' in the condition type customization.
    Transcation : M/06
    Select your condition type RB00 and click on the details icon.
    In the Scales block, you have to maintain and save.Calculation type = Fixed amount
    Scale basis = Value scale 'B'
    For this condition type, you have to maintain scales in the inforecord.
    Transcation : ME12
    Select this condition type, click on the Scales icon. There you have to maintain like
    From : 10,0000            Rate: 5000.
    It means, if the document value is reached 10,0000 then discount is 5000rs. If the value islessthen the 10,0000 then no discount.
    Regards
    KRK

  • How to get the freight based on the order value

    Hi Folks,
    I have a scenario..if the total order value is less than 2000/- the freight cost will be beared by the customer and if the total order value is more than 2000/- then the company will bear the freight cost. We are using two condition types for freight calculation for this scenario. What can be the way to get this?
    useful suggestions will be awarded points.
    Sunanda.p

    Hi
    SUNANDA.P
    U can achieve this by using scale in yr freight condition. Select yr freight condition and go to Tcode V/06 there u will find SCALE TAB -
    scale basis,  u select " B ". Now maintain condition scale value 2001 then freight rate will be e.g. 500 rs.
    In VK11u can go to scale by pressing F2.
    Try and this will help you
    Thx.
    Dwarkesh

  • Sales order value based invoicing

    Hi ,
    Present setting is that Invoicing is done based on the quantity, is it possible that I can do the invoicing based on sales order value.
    2) How to control that Invoicing value and quantity  should not exceed the sales order quantity and value.
    Regards

    Hi
    most of conditions used in sales pricing get copied directly from order to invoice, only freight and delivery charges are aded up while generation of invoice.
    So functionally  if you can estimate freight or delivery charge value in sales order ,you can always maintian routine to be triggered in pricing procedure while invoice generation  to indicate whether  invoice  freight value is exceeding either the individual freight value for sales order  or compare total sale order value  with total invoice value.
    You can set error message if value exceeds than allowed condition value and so the transaction will not be saved.
    Alternatively Condition types AMIZ,AMIW can also be used to have a control through estimation.
    Create appropriate pricing routines with the help of ABAP developer and apply to condition value. Use statistical condition types for control of conditions.and I think what you are trying to achieve can be done.
    Regards
    Mandar

  • Hi discount based on order

    i wan to give discount bASED on the orders placed by customer
    suppose customer has a given a order now
    in inthis week he has placed 4 orders
    for the fourth order i wan to give discount
    that is here it is not quantity based but order based
    plz help solve diz scenario asap
    anil

    Hi,
    Try this ....
    Frist the condition type you are using used be customized with conditon update and then condition record.
    T.code V/06 select the condition type you want the discount to be applied. Eg K04
    in the condition type screen
    Master data tab check the condition update check box.
    Now for this condition type create the condition record T.code VK11
    After maintaining the data select the line and click on maginfying glass.
    On the control data tab you find fields with
    sales order numbers
    value
    Once you maintain the number for sales order from that number the condition type will be active
    If you maintain value from that value the condition type will be active.
    Kindly Reward points if useful.
    Regards
    vK

  • Pricing - flat fee sales order discount based on the group of items

    Dear All.
    Has anyone came up with a process to offer a customer discount on a sales order as a flat fee to the whole sales order, not a % when specific products are ordered on the sales order.
    The problem that we're running in to is with no automatic pricing at the header level.  So we either need to manually enter the discount at the header level, or apply a group condition at the item level which then repeats the flat discount for all items in the group.  However we only want the discount to apply one time.
    Thoughts on how to best approach this?
    Many thanks.

    If you want to use Header condition for discounts, then you can't apply to only one line item. If you want to spread the total value among all the line items, then in t.code V/06, check the box group condition. While printing any of the documents like order confirmation or invoice, print the discount at the header level, so that this will not reflect on all items. Check with an ABAP'er for the same.
    Regards,

  • Discount in pricing for total amount sales order

    Hi developpers,
    You know a standard procedure for calculate, a particular discount for sold to party, with relation to the total amount of sales order.
    Thanks in advance
    Domenico

    Dear Manti,
    -->Create condition table with the field Slod-to-party
    -->Put that field in to access sequence
    -->You define the the discount condition type in the transaction V/06 or you copy standard discount condition type.
    (Based on the % or Value or Fixed)
    -->Assign acces sequence to that condition type.
    -->Put that condition type in your pricing procedure after gross price total.
    -->Calculate that discount condition type from gross value.
    -->Put net value after deduction of the Discount in the pricing procedure.
    -->Maintain the condition record for that discount in the VK11 transactio.
    Now you create sales order discount will come in the sales order.
    I hope it will help you
    Regards,
    Murali.

  • Pricing (header discount) based on VC characteristics

    Hi everyone,
    We manufacture and sell make-to-order products and use variant configuration to capture the specific characteristics required by the customer. The order quantity we use is EA. However, we wish to price by the square metreage of the product. At item level this is OK because VC can set a pricing variant according to its calculation of the square metreage and this is passed into the pricing conditions.
    However, we wish to offer a discount based on the TOTAL square metreage of product within the order that is distributed proportionately across the items in the order.
    Has anyone done anything similar?

    Devon
    1) My suggestion would be to include the threshold  by date in a custom Infostructure ( S500+)  in flexible planning- MC93.
    2) Also activate Infostructure S001 for customer analysis to update synchronously.
    3) Now include a Pricing Requirement  against the discount condition to compare the value in S001 with SXXX and  apply it only when the threshold is crossed.
    4) Maintain Discount rate  in a (dummy) condition record, but you may need a alt. Cond. Base value formula also.
    Hope this helps.

  • Cancelling order discounts when below Customer's Minimum Order value

    I've been reading what I can find about discount conditions etc and am slightly confused as all the examples seem to relate to item line situations. We need to have a setup where all possible discounts are cancelled if the order total value is less than a given minimum order value (or threshold) related to that particular customer - and not based upon any line item value.
    We do not use Minimum Order Value as per the SAP examples given i.e. orders not accepted below the MOV and therefore surcharges added. As mentioned we use a threshold value for most customers under which discounts do not apply.
    Because of this we cannot automatically email or fax acknowledgements, and we have a massive time consuming checking operation for orders added to ensure mistakes are not made i.e. discounts applied incorrectly before the acknowledgements are sent out.
    Can anyone advise as to where I can find the path to getting a solution to this problem.
    Thanks
    Jim Jackson
    Edited by: Jim Jackson on Feb 20, 2009 9:11 AM

    I understant AMIW is Header condtion type - statistical- and has the MOV value for the specified customer.
    Maintain AMIW as Header / Line condition type.( T Code V/06)
    Create the condition reocord for AMIW with EXCLUSIVE Indicator X.(VK11)
    Then create a requirement for all the discount condition types, if the total order value = or > AMIW value then do not check the exclusion indicator( KOMP - KZNEP), ELSE check the exclusion indicator.
    ( T Code VOFM)
    During order save - automatically repirce the order in Userexit_save_document_prepare or userexit_save_document.
    If there is a partial delivery, during Invoicing if the copy control(delivery to Invoice) has carry out new pricing B, the above setting might fail. Maintain the copy control setting to copy pricing elements unchanged and redetermine taxes OR try to determine the condition values in the invoice from the order.
    Hope this helps.
    Thanks
    Sai

  • Discount on Total Order Value

    Hi everybody ,
    We need the Discount to be calculated automatically on the Total Order Value.
    Its a promotion.
    Useful suggestions will be rewarded.
    Thanks
    Kartik

    Hi pls follow the procedure below, Hope it will help u out
    VOFM: ON PRICING
    This note is an explanation of function "Maintain: Requirements and Formulas", which is also known as "VOFM".
    By using descriptions and examples, this note explains how the VOFM function works in the R/3 Standard System, which objects are related to it and which restrictions exist.
    Chapter 2.7 explains possible causes of errors and solutions for problems with the VOFM function.
    To provide a good overview, this note is subdivided into the following sub areas:
    1. General information
    1.1 Definition of terms
    1.2 Application areas
    1.3 A frank word on the "source code responsibility"
    2. Technology
    2.1 Introduction
    2.2 Namespaces
    2.2.1 SSCR object registration
    2.3 Structure of a VOFM object
    2.3.1 Include file with ABAP form routine
    2.3.2 Table entries in TFRM and TFRMT
    2.4 Calling VOFM objects
    2.4.1 VOFM object carrier
    2.5 Activation, generation and RV80HGEN
    2.6 Transport
    2.7 FAQs: Possible causes of errors and problems
    Technical field names are displayed in angle brackets [].
    Note that this note only explains the mode of operation of the VOFM in an R/3 Standard Core System.
    For R/3 industry solutions or Add-Ons the VOFM function displays a different behavior in subareas, however, this is not dealt with in this note.
    Additional key words
    VOFM, SAPMV80H, TFRM, TFRMT, RV80HGEN, XPRA, formulas, requirements, data transport routine, copy routine, data transfer.
    Cause and prerequisites
    1. General information
    1.1 Definition of terms
    Depending on the business processes used it may be necessary to influence the standard behavior of R/3 applications. For that purpose the VOFM function provides a corresponding environment in order to be able to develop and manage customer-specific logic simply.
    The system stores the objects generated via the VOFM in the Customizing of the respective application area
    (Pricing, message determination and so on) and its programs call the objects correspondingly.
    Also SAP delivers certain functions in the form of VOFM objects.
    Consequently, the VOFM is an exit technology as explained in more detail in Note 381348.
    1.2 Application areas
    Typical VOFM objects are requirements, formulas and data transfer routines.
    These are used in processes of the purchase order, the delivery, billing, price determination, material determination, message determination, the free goods, the pricing and of others.
    In the entries of the R/3 core menu of Transaction VOFM you can find a precise overview of the supported application areas.
    1.3 A frank word on the "source code responsibility"
    As in user exits, in VOFM objects are many fields and tables available. Thus, the use of VOFM objects is very versatile and consequently also very critical under certain circumstances. For the use of "customer-specific" VOFM objects the statements in Note 381348 regarding the responsibility for customer enhancements (Maintenance responsibility, problems during the upgrade and so on) apply. Read this note carefully before you decide on the use of customer-specific VOFM objects.
    Errors and data inconsistencies that are caused by improper application or implementation of VOFM objects are not processed by the SAP Support but exclusively within the framework of the Consulting that has to be purchased separately.
    2. Technology
    2.1 Introduction
    A VOFM object is uniquely defined via characteristics "group indicator" [GRPZE] and "group number" [GRPNO].
    Here the group indicator, technically represented by a character field of length 4, is the logical connection to the calling environment.
    Examples:
    ABED copying requirement in the order
    ADAT data transfer in the order
    PBED requirements pricing
    CASC Data transfer for sales activities
    PBEK requirements account determination
    CHRG requirements batches
    REAK archiving for orders
    VFCL Multi-dimensional scales
    You can find all defined group indicators in the allowed values of the "GRPZE" domain in the ABAP Dictionary (Transaction SE11).
    The group number can have a value from 1 to 999.
    Exceptions are group indicators "PSTK" (= group key routine pricing) and "TDAT" (= data transfer for texts). For these the system can only assign group numbers from 1 to 99.
    2.2 Namespaces
    The VOFM has separate number ranges in order to distinguish VOFM objects delivered by SAP from customer-specific VOFM objects. These number ranges are often also called "VOFM namespaces".
    However, note that this is not a "real namespace" that is protected by corresponding entries in system table "TRESC" (= reserved names for Customizing tables and Customizing objects).
    Instead, only the VOFM logic itself does the definition and check of the number ranges.
    The following list displays the customer number ranges sorted according to group indicators:
    Indicator     Name     Number range customer
    FOFU     Subsequent functions     900 - 999
    PSTK     Group key routines     50 - 99
    TDAT     Data transfer routines f. texts     50 - 99
    all other group indicators           600 - 999
    In Note 356737 you can find more information on the available VOFM number ranges.
    2.2.1 SSCR object registration
    VOFM objects are subject to SSCR registration (= SAP Software Change Registration).
    The reason for that is the necessity that every VOFM object is physically assigned to that SAP development class, from whose programs a corresponding jump into the VOFM object later occurs.
    If you use the VOFM interface the system makes the assignment automatically. An assignment of customer-specific development classes is not possible.
    2.3 Structure of a VOFM object
    A VOFM object consists of the following parts:
    Include file with ABAP form routine
    TFRM table entry
    TFRMT table entry
    2.3.1 Include file with ABAP form routine
    In the ABAP form routine the desired function is programmed.
    Example pricing value formula number 001:
    Include name : FV64A001
    Form routine : FRM_KONDI_WERT_001
    Implementation: * * Profit margin considering rebate agreements
    form frm_kondi_wert_001.
    xkwert = komp-kzwi3 - komp-wavwr.
    endform.
    Dependending on the selected group indicator, the group number and the system type (SAP or customer system), the system assigns and generates the include name and form routine name automatically.
    For this reason, standard routines delivered by SAP generally have a different structure of the include name than customer-specific routines.
    Example:
    SAP standard value formula for the pricing
    => prefix FV64A + object number with 3 places from 'SAP namespace'
    => for example FV64A001
    Customer-specific value formula for the pricing
    => prefix RV64A + object number with 3 places from 'customer namespace'
    => for example RV64A905
    2.3.2 Table entries in TFRM and TFRMT
    The entries in tables TFRM and TFRMT belonging to a VOFM object are used for the status management and assignment. The system always analyzes them if the user calls Transaction VOFM or if a generation operation occurs (for details refer to section 2.5).
    The system generates exactly one TFRM table entry per VOFM OBjekt. In this TFRM entry the following information is stored:
    Group indicator     GRPZE
    Group number     GRPNO
    Routine 'active' indicator     AKTIV_TFRM
    Application     KAPPL
    Date of the last generation     GNDAT
    Time of the last generation     GNZEI
    Examples:
    GRPZE     GRPNE     AKTIV_TFRM     KAPPL     GNDAT     GNZEI
    PBED     001     X     V     06 13 2001     09 06 39
    TDAT     001     X           06 13 2001     09 06 39
    CHRG     003     X           06 13 2001     09 06 39
    The meaning of group indicators and group numbers has already been dealt with.
    The 'active indicator' controls whether a VOFM object is 'active' or 'inactive'. Active VOFM objects have characteristic value AKTIV_TFRM = 'X', inactive objects have characteristic value AKTIV_TFRM = initial.
    VOFM objects flagged as 'active' are 'known' to the calling program logic, that means they were included in the main program of the 'calling program' and can thus be addressed and
    processed during the runtime.
    You cannot delete VOFM objects that are still 'active'. In this case you have to reset the active indicator manually before.
    The content of the 'Application' field serves to filter the relevant VOFM objects in various display functions and Customizing functions.
    Example: Condition value formula 010 'Relevant Price'. This formula has characteristic value 'MS' for the 'Application' field (= External Services Management purchasing). Therefore the object is not open for selection in the input help during the maintenance of pricing procedure SD (Transaction V/08), because this is a Customizing transaction assigned to application 'V' (= Sales and Distribution).
    Storing an application key is optional.
    The generation date and the generation time record the time of the last registration of the VOFM object (the object carrier, refer to section 2.4.1).
    In addition to the respective TFRM entry a VOFM object can have 'n' entries in table TFRMT. The entries are used for the storage of language-dependent object descriptions, which are structured as follows:
    - Language key [SPRAS]
    - Group indicator [GRPZE]
    - Group number [GRPNO]
    - Description [BEZEI]
    Examples:
    SPRAS     GRPZE     GRPNO     BEZEI
    D     PBED     001     Regulierer abweich
    E     PBED     001     Different payer
    The system supplies the language key automatically with the logon language of the user during the creation of a new VOFM object.
    The length of the object description is limited to 20 characters.
    Important! A VOFM object is only consistent if both the Include file with ABAP form routine and a corresponding TFRM table entry exist. Entries in table TFRMT are optional.
    2.4 Calling VOFM objects
    As mentioned above, VOFM objects are called directly by the application logic of R/3 standard programs. Technically this is implemented by ABAP statement 'PERFORM ... IN PROGRAM'. With the aid of this statement you can specify both the name of the subroutine and the main program dynamically (during the runtime).
    Example: Call of a condition value formula from the pricing
    if xkomv-kofrm ne 0. <<< formula reference existing?
    xkwert = xkomv-kwert. <<< act. value in work variable
    frm_kondi_wert-nr = xkomv-kofrm. <<< set up object names
    perform (frm_kondi_wert) in program saplv61a if found. <<<CALL
    xkomv-kwert = xkwert. <<
    endif.
    In the example above the subroutine is determined by the contents of variable 'FRM_KONDI_WERT'; the main program, which is to be searched for the form routine, is SAPLV61A.
    If the called routine is not known in the main program, a program termination with the title 'PERFORM_NOT_FOUND' occurs.
    Therefore some users of the VOFM technology call ABAP statement 'PERFORM ... IN PROGRAM' together with the addition 'IF FOUND', which has the effect that a jump into the form routine is only executed if this in fact exists in the main program. This does indeed prevent a program termination, however, the result of the overall process may deviate from the
    result expected by the user, because in this case the system does not execute the source code implemented in the VOFM object.
    2.4.1 VOFM 'object carrier'
    Object carriers are required to make a VOFM object 'known' in the main program of the calling program (refer to section 2.4). The object carrier is integrated in the main program of the calling program as an independent include (for example SAPLV61A, SAPMV45A and so on).
    Example: Inclusion of object carriers for word processing in SD
    documents; Program 'SAPLV45T'
    System-defined Include-files. *
    INCLUDE LV45TTOP. "Global Data
    INCLUDE LV45TDEF.
    INCLUDE LV45TUXX. "Function Modules
    INCLUDE LV45TNNN. <<< 'carrier' copy requirements for texts
    INCLUDE LV45TENN. <<< 'carrier' copy routines for texts
    Every active VOFM object (for an explanation on the active indicator refer to section 2.3.2) must be registered in the 'carrier'.
    The system writes standard VOFM objects delivered by SAP directly into the 'carrier', VOFM objects from the number range reserved for customers (refer to section 2.2 'Namespaces') are sorted into a 'sub-include' included in the carrier.
    Exactly one carrier exists per group indicator. The names of all defined object carriers are hard-coded in program MV80HF0A, form routine 'AKTIVIEREN_TRAEGER_SETZEN'.
    Here the names of the sub-include for customer-specific VOFM objects belonging to the main carrier are also defined.
    Example: Carrier object 'FV63ANNN' for the registration of condition basis formulas in the pricing (Program SAPLV61A)
    FV63ANNN
    <<< main
    carrier-include
    |-INCLUDE RV63ANNN. "User-Routinen <<< sub-include customer objects
    | |- INCLUDE RV63A910. "Customer specific
    | |- INCLUDE RV63A911. "Customer specific
    | |- INCLUDE RV63A912. "Customer specific
    | |- ...
    |- INCLUDE FV63A001. "Volume
    |- INCLUDE FV63A002. "Net value
    |- INCLUDE FV63A003. "Net Price
    |- INCLUDE FV63A004. "Net Value Plus Tax
    |- INCLUDE FV63A005. "KZWI1
    |- ...
    Because the content of the VOFM object carriers is automatically created source code, you should avoid manual changes to them.
    SAP notes, which suggest manual changes to the object carriers, are therefore also incorrect. However, if you nevertheless receive such a note to solve a problem, contact the SAP
    Support with a reference to this note.
    2.5 Activation, generation and RV80HGEN
    The 'activation' is the inclusion of an VOFM object in an object carrier. A 'deactivation' results in the removal of the VOFM object from the object carrier.
    The overall process for the creation of a current object carrier is often called 'generation'.
    Generally the activation or generation fall into three types.
    - Individual activation
    - Collective activation
    - Generation of object carriers via report RV80HGEN
    The 'individual activation' causes the registration of an individual VOFM object in the corresponding object carrier. Which object carrier is relevant is determined with the aid of the group indicator and the group number. In addition to the entry of the VOFM object in the object carrier the system writes the date and time of the generation into table TFRM (refer also to section 2.3.2).
    You can start the individual activation only manually. It is always always executed when a user selects a line within the VOFM editing interfaces and afterwards selects activity
    'Activate' from the 'Edit' menu.
    The 'collective activation' causes the registration of all VOFM objects that belong to a certain group indicator. Analog to the individual activation the system determines the relevant object carrier automatically and writes date and time into table TFRM. The 'collective activation' is a process which you can start also only manually. For this purpose, choose activity
    'Activate all' from the 'Edit' menu.
    During the generation via report RV80HGEN the system sets up the object carriers of all defined group indicators again. However, the system includes only those VOFM objects that have set the 'active' indicator in the corresponding TFRM table entry. Nonactive VOFM objects are not included in object carriers during the generation via report RV80HGEN.
    Due to the quantity of the data to be processed,
    the generation via RV80HGEN can take between 0,5 and >5 minutes (depending on the system and the constellation).
    Because the RV80HGEN is defined as 'XPRA', it is executed automatically during a system upgrade.
    You can also use this XPRA feature for the transport of VOFM objects in order to implement an automatic update of the object carriers after the import of VOFM objects into the target system (section 2.6 provides more details on the transport).
    Both the collective activation and the activation via report RV80HGEN technically revert to the program components of the individual activation. For the separate control of the individual activation types form routine AKTIVIEREN_EINZELN (Include MV80HF0A) has a 'USING' parameter, which can have the following characteristic values:
    'E' Activate individually
    'A' Activate all (= collective activation)
    ' ' Deactivate individually
    During the generation via RV80HGEN the system executes a collective activation for every group indicator sequentially, that means a call of form routine
    AKTIVIEREN_EINZELN with characteristic value 'A'.
    2.6 Transport
    If you want to transfer VOFM objects from one system (= source) into another system (= target), this is generally made with an object transport.
    As of Release 4.0, the VOFM function has a connection to the SAP 'Change and Transport System' (CTS) in order to simplify the transfer process for the user.
    By the transport connection the system automatically adds newly created or changed VOFM objects to the object list of a transport request which was selected by the user before.
    All steps necessary for the execution of a VOFM transport are described in detail in Note 22808 'Transferring formulas'. Note that steps 1-4 are only needed
    if the VOFM maintenance environment providesno automatic connection to the transport system or if you want to combine a transport request manually. In any case you must execute step 5, regardless of how the transport request was created.
    In addition to Note 22808, Note 385067 contains an overview for releases >= 4.6C regarding which sorts of tasks and object entries are required in a
    transport request (depending on the activity carried out (create/change/activate/deactivate/delete)) in order to transport a VOFM object successfully.

  • Pricing type to re dtermine prices at invoice using order value for scales

    Hi ,
      I have requirement to redeterime prices during invoice generation. All conditions should be redetermine but the scale basis should be determined from the order. For e.g if it is a quantity based scale and order is for 500 pcs  and the invoice is only for 300 pcs the system should use 500 to determine the scale value. Is there any copying rule/ field in STEU that can help me achieve this?
    Regards,
    Hari.

    Hi,
    There is not standard functionality for this requirement. If you want this then you have to opt for customed copy routine in pricing type...
    For this u just  take help from ABAper and use the already existing pricing routines A and B by using these two source codes of routines and ask him to create new routine which meets your requirement..
    Regards
    sankar

  • How to get the pricing hierarchy based on the delivery date for sales order

    Hi,
    How to get the pricing hierarchy based on the delivery date for sales order other than system date.
    My requirement is to get the Pricing hierarchy based on the delivery date other than system date.
    Waiting for kind response.
    Best Regards,
    BDP

    HI Sai,
    please refer teh document already how to write FM based extration on generic extractors.
    and here  the logic to find the latest records values:-
    -> get the data in an internal table
    ->Sort the internal table data based from date descending
    -> Using READ statement , we can read the first record of the table which is nothign but your latest record.
    Regards.
    Sakthi

  • Surcharge should be automated  in pricing when order value is less

    Dear all,
    There is a client requirement where in if the order value is less than 1000 Rs. then a min surcharge of 2% has to be calculated in the pricing procedure automatically.
    Right now they are giving this condition manually.
    There is a cond type : SURG  this has to automatically flow into the system say 2% or 3% or Fixed amount say 200 or 300 ( client is yet to decide on the amount ) when the  order value that is when the user input  PR00 which is  lesser than 1000 then this surcharge condition type with whatever percentage or fixed amount kept in the condition record   should come automatically.
    Valuable inputs required.

    Hi, ram
    The thing is I dont want the system to replace the PR00 price. when ever the PMIn condition type comes.
    The senarion is  
    When ever the sales order value is less than 1000, say that PR00 is manually entered for 800 or 900 or 999 then there should be surcharge calculated say for 2% on basic price and the basic price should be there.  and this surcharge condition type should come automatically when the price is gettng inputed for 800  through PR00.
    And then finally total value will be displayed.
    Hope this above   example is clear , will the above logic which you have mentioned will work on this case.?

  • User based block the pricing field in the sale order

    HI FRIEND
    We have requirement user based block the pricing field in the sale order
    pls suggest me the configuration steps
    with regards
    dinesh

    hi friend
    when create a sale orde,r price and exchange rate is triigger from the master record.
    head department want not require to End user to change the price in the sale order .
    so head department only have authorisation to change price.
    selected user is not allow the change the price.
    so i need the configuration
    with regards
    dinesh

  • Freight based on order value before tax

    Similar  to the post regarding freight charges which are conditional on shipping address ( which looked as if customisation was the only route) , is there an easy way to implement an order value cut-off point on freight charges. ( i.e. orders below a certain amount are charged at a flat fee but above this limit are free )
    I'd presume that this would have to be set per shipping type it if could be done out of the box.
    If it requires custom code what steps would be involved how much of the checkout process would have to be re-built and is this a relatively straightforward customisation or one likely to be plagued with problems for someone who is not experienced in this area?
    Thanks in advance,
    Geoff

    Maybe I'm not sure, but i think that it's standard functionality,
    in expenses -> shipping
    edit shipping type
    on general:
    Basis - price (means value to be honest) charge type: flat charge
    on definition:
    Lower Rate     Upper Rate     Charge     Effective Date     Expiration Date     
         0.00      1000      £6.00      2009-Feb-24      3000-Apr-01 
    regards
    Greg.

Maybe you are looking for