zoukankan      html  css  js  c++  java
  • How to estimate the active condition records in a CRM system (1)

    image

    When we try to recommend the proper start_of_eviction/upper/critical parameters in VMC for the condition records, it’s always not so easy to give a number simply by a Note or something else. So far there is no fixed rules for such a estimation. And I want to open this discussion via this blog. Any comments after you reading through the following parts are welcome. :-)

    It’s more like a blog to review the pricing procedure determination for transactions. To know how many condition records we are about to use in the current system, we should trace back from where condtion records are fetched in the pricing determination steps.

    The CRM pricing procedure could be simply summarized like this:

    (1) Sales Area + Doc. Pricing Procedure (PP) + Cust. PP. => Pricing procedure (1 Tran. : 1 PP)

    (2) Pricing procedure => Condition Types (1:N)

    (3) Condition Types => Access Sequence (this is a one-one mapping)

    (4) Access sequences => Accesses (in the definition of AS, normaly 1:N)

    (5) Accesses => Condition Tables (1:N)

    (6) Condition Tables => Condition records (1:1)

    image

    Although only one result for each condtion type is required, we still should consider all the potential calculations. that means we need to consider all the 1:N relationships above instead of not only the 1:N between pricing procedure and the conditon types.

    After all the ideas is confirmed, it is quite clear how we should estimate the total number of condition records are estimated in the system.

    Let’s assume that all the 1-N relationships were maintained in a simple table and let’s naming it just after the step number (from 1 – 6) like T1, T2, T3, T4, T5, T6.

    Then the number result could be roughly estimated in such a calculation:

    Loop T1, get all the possible pricing processdures, set it as DATASET1.

    For all entries in DATASET1, loop T2, get all the combination of PP and CT, set it as DATASET2, here we need to delete the duplicated entries for the first time.

    For all entries in DATASET2, loop T3, get all the access sequences, and delete the dupliated entries again. Set it as DATASET3.

    For all entries in DATASET3, loop each Access Sequence and get the total dataset of the accesses (T4) and condition tables therefore with the mapping in T5. Here we get a DATASET4 containing all the condition tables which is supposed to be active.

    Then for each condition table, I think we could fetch either 1 or all the number of condition records in that condition table.

    This should work out anyway an estimated number. Although there are still a lot of other factors to be considered.

    I will do some research and continue explorering the series of tables!!!

    Raymond Zhang
    If you want to discuss with me about any idea, please contact me at raymond.zhang@sap.com

  • 相关阅读:
    性能测试应用领域
    性能测试---不同视角看性能和相关术语
    Jmeter(二十五)Jmeter之系统函数
    Jmeter(二十四)Jmeter-Question之“加密请求参数”
    Web应用层协议---HTTP
    协议栈CheckList
    数据报表类(BI)项目测试应该如何去啃?
    #单元测试#以karma+mocha+chai 为测试框架的Vue webpack项目(二)
    解决未安装unit测试和jest的Vue项目运行karma start时的错误
    npm run dev运行Vue项目报错:Node Sass does not yet support your current environment
  • 原文地址:https://www.cnblogs.com/rabbitzhang/p/2104794.html
Copyright © 2011-2022 走看看