Recently we started to develop a tool to be able to react flexible and fast to the changing requirements in product configuration. I will show in this blog the current solution and you are invited to comment, improve or also mention pros and cons of the shown solution. Do not hesitate to share your opinion and questions.

The main goals of the desired solution are:

           1. Every – also complicated – variant configurations can be done by pure configuration and there is no need for writing any ABAP code.

           2. The whole configuration of one product can be viewed and managed on one screen

           3. The solution is based entirely on the existing SAP ECC variant configuration.

Lets assume you have a packaging company for sweet tasty chocolate and you parcel the different bar sizes into different cases and place diffrent label on top of the closed case.

The products have different heights, widths and lenghts and you have lets say 3 different boxes small medium and large.

     How to you assign the products to the boxes?

     Further how you configure the text on the label. Lets say you want to print the first word of the product description on the label?

Well, the variant configuration of SAP offers a bunch of features to solve this things. The two above tasks could be solved with Variant functions and some ABAP code behind (you can find a good introduction in Variant Functions with an example.)

But what happens if you want to make some small changes – do you want really want that for every configuration change you have to find a developer who makes the necessary code changes for you?

So in the current solution the user view on the product configuration looks like this (simplified):

characteristic selection criteria value expression
TrayType Length > 200 or Width > 50 or Heigth > 20 BIG
TrayType Length < 100 and Width < 20 and Heigth < 10 SMALL
TrayType DEFAULT MEDIUM
ChocolateType DEFAULT FirstWord(MaterialCode)
ChocolateType MaterialCode = “chocolate mix” materialCode
WEIGHT TrayType = ‘BIG’ ROUND(Length * Width * Height*2, 2, ‘X’) + 20
WEIGHT TrayType = ‘SMALL’ ROUND(Length * Width * Height*2, 2, ‘X’) + 10

That mean for example an customer order with the materialCode “white chocolate” and a characteristic Length = 250 should get additional characteristics TrayType=BIG and ChocolateType=White. In another customer order with characteristic Length=100 the TrayType will be MEDIUM and so on.

If the BIG box should for example only be used if the Length > 210 or the weigth for a big box changes from 20 to 25 the user can change this object dependency by simply changing the corresponding table entry.

So how this can be implemented, what would you suggest?

In my opinion the above mentioned variant functions fits best to get there and the solution is already working quite good with them. With some adaptions the variant functions get rather generic and to apply a change the only thing which remains for the user is to change the configuration.

Some thougths about the implementation in ABAP you can find in the followup:

Enhanced variant configuration tool – Coding thoughts

I am looking forward to your feedback, ratings, comments and especially your ideas to improve the shown solution.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Shai Sinai

    Nice blog.

    Just a short warning from my (bad) experience:

    In case you have ERP-CRM integration, you should reconsider this solution since these functions aren’t synchronized to the CRM JAVA IPC and you’ll to re-write exactly the same logic in the in JAVA (p)functions (What might get little complex).

    (0) 
    1. Andreas Gautsch Post author

      Thanks for your hint. We do not have The ERP-CRM integration.

      You are right, if you want to use or switch Java there is sure some extra effort, but that’s the case with every customer specific implementation.

      (0) 
  2. Paul Hardy

    The elephant in the room when using VC from within the SAP GUI environment is that the standard VC screen is as hideous as hideous can be.

    For example the F4 help, if called when a field already has a value, does not show all possible values, bur rather just the selected value. You have to manually delete the value and then do an F4 to see all possible values again. Not much fun when changing an existing value. I could go on, but the whole thing is horrible. Don’t even get me started on the so called error handling.

    The constraints and dependency nets and such forth are written in a pseudo programming language meant to be “simpler” than ABAP but the end result was just something that was much harder to read with very limited functionality and when you had a syntax error you are stuffed, trying to make sense of the syntax error pop ups would be beyond Sherlock Holmes.

    You end up doing as much as you can in Z function modules, as you alluded to.

    So what I (and my colleagues) have been doing in my day job the last two years is writing my own variant configuration system in ABAP. I still use the classes / characteristics and the SAP documents and production orders are unaware the standard SAP VC has been bypassed, but entry of customer requirements and all the default values, allowed values, dependences and so forth are done in ABAP, with a much more intuitive UI for maintain the rules than the weird and inefficient standard VC mechanisms.

    I don’t think I will be going to Marco Island to talk about this though, as I would be tied to a stake and burnt as a witch.

    (1) 
    1. Andreas Gautsch Post author

      Interesting view and with many techniques you mentioned I also settled.

      One point which I found especially interesting is that you bypasseed the SAP VC but are working sitll with the SAP documents and production orders.

      Are you writing back your calculated values to the customer or production order and if yes how.

      Finally we are doing the whole calculation in ABAP (with configuration tables and of course also an much more intuitive UI .-) . But stayed with writing back the calculated characteristics with the object dependencies, if they are needed in the customer order.

      I did not found an easy to use BAPI to change the production order and I am also not comfortable with changing such core document of SAP.

      How do you handle this?

      (0) 
      1. Paul Hardy

        We store the customer requirements as characteristics against the sales document (contract / quotation / sales order). This can be done by a BAPI easily (well sort of easily, you have to make sure the ship-to purchase order item number contains the same number as the document item number for some reason, that took a lot of working out).

        There are no characteristics stored against the production order, I did not even think this was possible, but in any event there is no need for them to be there.

        The configurable material has a Super-BOM which consists of a bunch of class items, each one identical, each one pointing to a dependency which calls a function module which calls a method with all the ABAP that for the first item calculates the whole BOM based on the sales order characteristics and all the custom logic. the result is held in memory and the items fed back one at a time into the BOM result with the final material and quantity.

        This is all pretty much bog-standard SAP apart from the actual Z code called. the super-BOM is evaluated when a sales order is saved, when the press the “result” button in a sales order, during costing in the sales order, and when the production order is created. Standard user exits are all that is needed, there was no need for me to hack the system using the enhancement framework or anything.

        One vital aspect is to have all the Z configuration data time dependant, so you can re-explode the BOM three months later and see how all the values were calculated on the day the production order was created.

        Cheersy Cheers

        Paul

        (0) 
  3. Tapio Reisinger

    Hello Andreas,

    based on your requirements written in your blog, I think this can be fully implemented with Easy Cost Planning (ECP), without any ABAP coding. With ECP you can define your own characteristics and value constraints in a model, which derives other characteristics and values from there.

    But beware! Easy doesn’t really mean it is less complex than ABAP development (at least for most consultants). It has some other drawbacks and pitfalls too. But for your simple example above it should work nicely.

    Best regards, Tapio

    (0) 
    1. Andreas Gautsch Post author

      Hello Tapio!

      Thanks for the input. ECP seems to be a highly configurable tool, I did not know yet. After a quick read over it, I assume it can handle a lot of mathematical issues. But the main reason to create the above ABAP tool are requirements where a sales order characteristic should be populated with a combination of text.

      An easy example would be, you want to have a characteristic dimension which contains the following text: “Product group is: AT2”  where “AT2” comes from a customer order characteristic, where the first three letters are taken.

      I do not see the possibility to populate a characteristic of a sales order with a combination of variable text in ECP.

      Furthermore I need the possiblity to call user defined functions which process text (eg.: take the first 3 characters) or also to recursive call functions, in the examples above “TrayType = ‘BIG'” where TrayType is the output of another function.

      Thats not covered by ECP. May I am wrong?

      Regards, Andreas

      But anyway good to know about ECP, it will serve for sure in other arising requirements. Thanks

      (0) 

Leave a Reply