Skip to Content

A Widget for Cascading Recomputation of Quantities in “Treed” SAP Tables, e.g CKIS

CKIS is an “treed” SAP table (i.e. a table with “treed” rows) because the immediate children of row X are those rows in which the kalnr is equal to the ukaln of row X. Of course, the entire table is not one big tree because there are many “root” rows in CKIS in which the kalnr is the ukaln in no other row, thereby implying that CKIS is an unordered forest of unordered trees from a graph-theoretic point of view. So for the purposes of this blog, we restrict attention to one of the many trees in CKIS, i.e. one of the many trees whose “root” is a row in which the kalnr is the ukaln of no other row. There are many quantities that are often computed from CKIS rows, e.g. for a given row, we can compute a material scrap cost using various values in a row of CKIS. But according to some business experts in these matters, such computations must sometimes be “normalized” relative to a chosen lot size (menge). To do this, we first take the ratio of a “root” row’s menge to the chosen menge and adjust the quantities of all the children of this row by this ratio, including the menge of each of these children. Then when we proceed the next level of the tree (the grand-children of the original root), we normalize each of these menge’s relative to the adjusted menge’s of their parents – the ones we adjusted in the the original step. Then, when we proceed to the next level of the tree (the great-grandchildren of the original root), we normalize each of these menge’s relative to the adjusted menge’s of their parents – the ones we adjusted in the second step. And so forth and so on in a cascade down the tree. Since there are probably dozens of treed tables in SAP on which such cascading recomputations must be performed for business purposes, one would think that someone would have come up with a generic widget to perform this useful service. But I’ve looked for a such a widget in SAP-delivered code and haven’t found one. Not have I seen any such widget presented in any blog or forum post at SDN. And I can’t for the life of me figure out why a company built around doing top-notch business data-processing wouldn’t already have a widget to deliver such a useful and oft-needed business data-processing service. Nor can I figure out why some SDNer anxious to obtain code-sample points hasn’t yet presented such a useful widget here at SDN. Surely a truly generic widget capable of performing a cascading recomputation on any set of quantities in any treed table would constitute a very respectable candidate for a submittable SDN code-sample. But nope – there’s just no widget that performs this service to be found at SDN. So I guess each SAP developer will just have to program this widget each time he or she needs it, or at least program it once and clone it each time a different flavor of it is needed for a different cascading computation on a different table. Oh, wait a second. Did you think I was going to present such a widget here? If so, I’m sorry to disappoint you. Maybe when business data-processing comes back into fashion … if I’m still alive. But right now, “it don’t mean a thing if it ain’t got that bling.”

You must be Logged on to comment or reply to a post.
    • If Valery had the time, he could decide the basic algorithm, which is language-neutral.  I have all four volumes of Knuth but don’t pretend to understand any of them.

      If Rich had the time, he could provide the templates required for the dynamic programming needed to make the widget generic.  I’ve never done much dynamic ABAP.

      Based on these inputs from Rich, and Valery, I would do the grunt-work.

      And there could even be a task to write a white-paper on why an RDBMS is the stupidest place in the world to store a linked list.

      Oops – there goes my “RDBMS” fixation again.  I thought I had it under control …


      • There’s a WHOLE wiki here for collaboration and a whole “Community Projects” section feel free to start it.

        I also notice you are referring to the “outdated” term for “Widget”

      • David,

        Well, I have only 3 of 4 TACP books by Knuth while I buy them separately as they had been translated into Russian. The 4-th one is about graphs, so probably I’m of not much help here 😉 Just kidding.

        It would be great if you supply an example of original table entries (10-15 rows) then provide and example of resulted hierarchy over this data. Plus explanation how every level is formed.

        Who knows, probably afterwards you’ll be able to implement everything yourself as far as well-defined question is more then a half of the answer 😉

        Seriously, sample over some actual data would be really helpful to understand what you want to get.


  • For a recent client we came up with a nice recursive  approach to doing such calculations. My scenario was more financial and relation to nested line items. It was quite specific to that table and it worked really well. I am sure you could find recursion in Knuth.

    You could either do it top down – from the root and have the stopping case as no leaf node or from the leaf and stop when no parent can be found.

    You could probably make it generic by passing in tables and fields to calulate on but you could start with the specific set of tables you mention.

    There is probably a non-recursive solution that uses less memory but recursive solution I often (not always ) find are more elegant and easier to understand.

    Kind regards,

    BTW Widgets are things sold by ACME corporation that fail to blow up Road Runner. (beep beep)

  • Permit me to clarify something first – I’ve already written the recursion but instead of using “hold” values to store the parent ratio that has to be applied to the parent’s children, I’ve cheated with a hash table that I fill out on the way down the tree.

    This is why I asked Valery if he’d consider designing the “algorithm” – for two reasons:

    a) efficiency;
    b) taste.

    What I mean here by “efficiency” is that I’m pretty sure Valery can be counted on to design the most efficient algorithm from the point of view of: i) depth-first vs breadth-first tree traveersal; and ii) a “hold-area” vs a hashed look-up for the parent ratio at each step down the tree.

    What I mean here by “taste” is the same point that Rich Heilman often brings up – the machines are fast enough these days that the difference between two algorithms for this task may be inconsequential nanoseconds.

    But that doesn’t mean we shouldn’t look for the most “tasteful” algorithm, particularly if we’re really going to try and make this routine “generic”.  I’ve personally had the privilege of working with only one coding guru in this business, and from this experience, I’ve learned how important “taste” or “esthetics” are to good algorithms. 

    So yes, Valery, I will take your suggestion to provide a matrix with sample values for the original “tree-table” and how the values of each row in this original “tree-table” must be recomputed during the recursion.  (I am using the term “tree-table” for the matrix here because this is what the matrix would be called in the framework of ABAP Objects, WDA, and WDJ.

    Also, I will take Craig’s suggestion to provide this sample in a “collaboration start-up” in the appropriate section of SDN.  It will be easier to find it and refer to it there if anything really gets going on this.

    Finally, permit me to say that I’m really glad for your response here because this particular thread took some “heat” down in the Forums in a comment here:

    How about total and average “read” counts in the “Top Contributor” Section?

    (in my thread on publishing read counts.)

    Contrary to the opinion expressed in this comment, your responses taken together indicate that:

    a) there is still interest in real business computations at SDN (as opposed to interest in matters that really have nothing to do with core business computations per se.)

    b) the routine in question would have wide applicability if it were made “generic”.

    Again, thanks very much and best regards.

    • … some folks who responded here were so busy complaining that I had hijacked the latest buzz-word (“widget”) for satirical purposes that they neglected to comment on the post itself …

      Anyway, two comments:

      1) yes – ckis is really interesting because complex cost estimate trees can have multiple occurrences of (ukaln,parent_ukaln) pairs … this is why posnr is there;

      2) if you want to report on more than one “root” out of ckis, the hash-lookup table winds up storing a forest in which the key is tree#, ukaln (node), and cntl # (= posnr or your own in-stream accession #)

      Hey – if you like messing with ordered trees, ordered forests, and more generally, ordered DAG’s corresponding to N-free dim 2 posets, you might want to keep an eye on this thread here:

      The Shape of Trees to Come

      Best regards