WebUI上的One order header和status是1:N的关系：在WebUI上的search结果里，会把一个order当前所有的status全部连接成一个string，并显示出来。
从Component design里也能看清楚，status绑的是CONCATSTAT,
这个状态连接是后台完成然后返回给前台的：
WebUI status render逻辑，在Search result和detail page不一样。
(1). 在Search result，显示所有的status:
(2). 在detail page，分两种情况：
(2.1): 如果order的transaction type没有配置user status profile，就只显示system status的第一个。例如590这个order从后台查询它有两个active的system status，但是在界面上只显示第一个 I1003:
(2.2): 如果order的transaction type配置了user status profile，即这种情况order在后台表里同时具有user 和system status，此时优先显示user status，如图：
- 在Smart template的list report页面里，list report 里的table column和CDS view 里的field都是一一对应的，1:1的关系。但是现在由于CRM里order status的design，一个order可能拥有N个status。
- HANA studio里Opportunity相关的view
结论 仍然是： Opportunity和Status的关系是1:N， 而非1:1.
HANA studio 里的model全是为了Analytic report设计的，而非我们将来要做的service process ( transaction application ).
因此，HANA studio里相关的model 只针对system status建模，并未包含user status。这个我们的scenario有所差异。
n How to get system status code and description
HANA model取system status code和description和我CDS的做法一样:简单描述如下：
All system status are queried from TJ02 table:
The description of status code is from TJ02T table:
And there is a view which joins the two views above in order to return both system status code and system status description.
Data preview looks like below:
但如果perform 一个where used list就能发现，这个calculation view并未用于opportunity相关的report里。
n OpportunityQuery
这个calculation view被大量用于CBA的tile里，it will show the total number of Opportunities with the following status:
- won
- lost
- hasError
- Open
- InProcess
下图右边Output里StatusXXXX 几个column都是calculated field，计算的逻辑就是看system status是否为对应值。例如下图isWon的判断。
Its modelling detail:
Final data preview result below:
From here we get the conclusion that the cardinality of Opportunity UUID : SystemStatus code is: 1:N.
要获取更多Jerry的原创文章，请关注公众号"汪子熙":