Skip to Content

How to add condition type automatically in va01 base on incoterm-header?

I've created routine (VOFM->requirement->pricing) and write code like below.

I want to display condition type (ZC06) in VA01, when Incoterm header equal SCO or EXW.

but, wht happen now is ZC06 always appears in all incoterm.

routine.jpg (30.6 kB)
Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Posted on May 20 at 05:43 PM

    I do not understand why you need to create a VOFM routine for this, when you can simply use the incoterms field in the pricing table that you use for creating condition records. If you only have a pricing table with incoterms and if you only create condition records for SCO and EXW then you do not need additional coding.

    If the business is really worried that someone might create condition records for other incoterms - this can be handled via BTE 503305, but in many companies this would not be necessary, because pricing condition maintenance is typically centralized.

    Without knowing your pricing setup and without information on the troubleshooting steps that you have performed so far, it is hard to tell what you are not doing correctly.

    It seems that you are not a functional SD consultant. Have you spoken with your SD colleague about the case on which you are working? Apart from the development, there is a customizing part - the consultant has to assign the routine in the procedure and then transport the changes so that you can test the settings.

    I am not a developer, but in your routine I see nowhere a statement for setting sy-subrc to a non-zero value, which in my understanding means that even if the configuration is correct, that the condition will be always set - as long as it is determined in the sales document.

    The easiest way for me to troubleshoot routines is, after ensuring that the configuration is correct, is to place a break-point in the routine and go to the pricing screen. From there it is very easy to check why the code does not work as expected.

    I would try to avoid hard-coding in pricing routines, if I were you - business requirements may change often, it is usually more efficient to define a custom table to store the desired values and leave it to the functional consultant to maintain it.

    Add a comment
    10|10000 characters needed characters exceeded

    • saddam hussain what I meant by this was to use the standard functionality of SD pricing without resorting to development.

      Here is the simplified version: SD pricing uses condition technique. For the condition type you have an access sequence. The access sequence is a collection of pricing tables that are used for creating condition records. To determine a condition record in a sales document one of the prerequisites is that the values in the condition records match these in the sales document.

      Let's say we have a condition type Z007, for which you have an access sequence with a single pricing table, consisting of sales organization, distribution channel and incoterms. You create a condition record for sales organization 1000, distribution channel 10 and incoterms EXW, you set the validity of the record from 21.05.2020 to 15.06.2020. Then you create a sales order with pricing date 27.05.2020, sales organization 1000, distribution channel 10 and you set incoterms FH. The condition will not be determined, because there is no valid condition record for the combination of 1000/10/FH. Now you create an order for the same date, sales organization, distribution channel, but you use incoterms EXW. The condition will be determined, because you have a valid condition record for teh combination of fields and you have no routine or other custom logic to prevent the condition from being determined. Now what about SCO incoterms? What if the tell you a week after that they forgot about a special rule for sales organization 1100 and incoterms DDU? The business needs to create a condition record in VK11 for it (which takes a minute), you do not need to do anything. With a routine you will have to modify the code logic every time when they come up with something.

      If you ask your functional consultant the same question, they should be able to understand what I asked, if they do not understand the question or if they cannot give a good justification for not using the standard approach - then there is a high chance that development was not necessary.

  • Posted on May 20 at 04:58 PM


    If you create a routine you need to activate it as well. (and it needs to be assigned in the pricing scheme before it gets executed)

    A full guide can be found here:

    Also be careful with the check statements, these will exit the routine if the check fails. (in this case when inco1 = EXW, the routine will be exited and an sy-subrc = 4 will be set. (which will for sure not make the condition visible)

    I would go for something like:

    IF komk-inco1 = 'SCO' OR komk-inco1 = 'EXW'.
      sy-subrc = 0.
      sy-subrc = 4.

    Depending on which level (header or item) you might need to implement this logic in both KOBEV and KOBED routine.

    Best regards,

    Geert-Jan Klaps

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.