时间相关导航属性在query中随关键值的限制时间展示

关键值的展示，那是跟着交易数据里的日期来的。
按日期会汇总聚集。
比如说展示2022年1月份到12月份的销售总额。

但是此时你说，你有一个销售组有时间相关的导航属性叫销售人员。2022年1-5月孙红这个人在1组，6-12月在2组。
如果你现在去跑报表，发现，怎么这个人只显示在2组？

因为query上的KEY DATE来决定的是取主数据相应时间内的可用值。

默认是你跑query的这天，今天8月10号，你去跑query，然后系统只会去取8月10号这天这个人在的组。就是当前天。
或者你去用变量，或者是常量，但也只是能确认一个单值。。。那这有什么用。我需要的是1-12月每个月这个销售人员在哪个组。我要看到的是有改变的。。。
从query这里下手是搞不了了。

看看时间相关特性，它那个时间相关属性的时间是：dateto和datefrom

这个主数据相关的时间，和你交易数据上记录发生的时间，比如合同日期，不是一回事。那我怎么把主数据这个时间和交易数据的时间相关联？怎么实现把这个人的销售额按照1-12月来分配呢？

SAP是说用到Temporal Join.

我看了SAP给的解释，但是看完还是啥都不知道。

比如说成本中心有个时间相关的属性利润中心，成本中心交易相关的ADSO里要展示所有的成本中心和利润中心。
那这里我们就得把这个成本中心交易数据ADSO和我们的成本中心信息对象做temporal join. 再把他俩放到一个CP里。
这里涉及到的Temporal join, 很显然我们的成本中心信息对象里的属性是有dateto和datefrom这两个时间字段的。那我在ADSO里同样需要一个时间，这样我可以用来和dateto以及datefrom来做对比，如果我ADSO里有calmonth,那我按照calmonth1-12月来展示金额的时候，dateto和datefrom都会来对比calmonth来做profit center的展示。

Profit center 1 从2022年1月到3月是属于cost center1 ,从4月到12月属于cost center 2.
那么calmonth 4月对比datefrom 和 dateto的时候，就会展示profit center属于 cost center2.
这个对比在RSRT的SQL的WHERE语句里。

特性上本来就有时间了，那么ADSO上面的时间怎么搞？
在CP里，有两个地方可以设置：
右键点这个ADSO可以从定义时间相关和设置key-date两种方法来。

这两种方法的解释就几句话，也是含糊不清。
中心思想就是，把ADSO当成伪时间相关，那么要么是这个ADSO里有时间特性，要么就是有参考0DATE的信息对象。这样才能用SQL来生成一个时间区间。

ADSO时间相关两种设置中：

1. 定义时间相关
   有两个方法：

   1. 选择时间特性。比如这个ADSO里面已经有的0CALMONTH，0CALQUARTER，0CALWEEK，0CALYEAR，0FISCPER，0FISCYEAR。选择这些特性后，时间相关性就能从附加的0DATEFROM和0DATETO这个里面得来。这两个附加的字段会出现在你选的时间特性的底下。
      比如你选了0CALYEAR, 这个有值2022，那就会生成datefrom20220101 datato20221231.
   2. 选一个Date类型的特性当成开始日期（validfrom）再选一个Date特性当成结束日期（valid to）。这个你就得考虑你这个数据集是不是有效了，别开始日期最后大于结束日期。而且这个Date类型的特性还必须得把0DATE作为一个参照。我觉得一看这个就麻烦的很。

2. 设置Key Date
   要么就是第二种方法设置key date.参照0DATE的有Date类型的特性或者时间特性0CALDAY都能被当成key date.然后还有一个key date派生类型可以用来显示一个区间。（基于0CALMONTH，0CALQUARTER，0CALWEEK，0CALYEAR，0FISCPER，0FISCYEAR）。我看了下，我那个ADSO就适合这种情况，因为我那个里面没有0CALDAY这个字段，我也懒得去弄，正好有0CALMONTH。那正好去弄一个派生类型，我理解这个就是SAP帮你去写个代码了，你的ADSO里有0CALMONTH，那就去建一个基于0CALMONTH的派生的关键日期。这个派生的Key Date帮你把日都给你拿到了。而且你可以选first day或者last day当成key date. 或者一个固定的date。然后这个派生类型会造一个CALDAY到你的ADSO里。这个CALDAY最后在这里：
   
   我简单搞了下，确实最后报表里出来的数据能按照calmonth展示，没毛病。
   按这个派生类型的步骤如下：
   随便找个infoarea建：
   
   我选了month，因为ADSO里确实没有day。
   
   对比了主数据的valid from, 我这里选了第一天。
   
   随便在那个infoarea上建，最后会自动保存到global objects底下。
   
   接下来就是在CP里面，source那里的ADSO上右键用这个Set Key Date然后选calmonth,再选这个类型ZKEYDATE。 Temporaljoin就搞好了。然后主键关联也给搞一下。然后要用的数据拖拖拉拉。
   最后就做好了。

如果ADSO里有DATE类型的，我觉得可能更好搞了。但是我没搞。。。

然后我做好了才发现，这个temporal join只能用在纯join里。
我的那个CP里本来还有Union，那这种情况是不行的。

那我不就白做了？
单独做一个join是测试出来数据没问题。但是关键我还要和其他的union啊。

于是我只能把这个先保存一个单独的CP，然后把这个CP给加到之前那个CP的union节点里，但是问题来了。我不能激活了，说什么导航属性不激活的问题。然后temporal join里面的导航属性不能用。我就尴尬了。
搞了一天。
于是又重复加了一个ADSO在union的节点里，还是不行，还是提示我那个新的CP的导航属性不激活的问题。

到这里我卡住了，我总不能去HANA那里手写一个temporal join吧。

我也不知道该怎么弄，明天再看。。

今天周五。。。没心情看。。。

今天周一，还是没心情看。。。
混到下午。

只看到了一个说法：也就是否定了我的想法：对于用纯的temporal join的CP，它如果被复用了，那么他的导航属性就不能在这个新的CP里面被用了。
尽管它自己个是可以用导航属性了。
那我就没办法。了。
只能继续混了。。。

或者去建calculation view，用 inner join和subselect. 然而我并没有实战过这个啊。。。我不会啊。。。

–还有一点就是，作为ADSO来说，其实主要是用来存储数据的。
而CP是用来专门为报表服务的，所以CP上才可以在output里把导航属性展示出来。

那么在HANA里面执行，可以先把ADSO作为一个external HANA view，然后在calculation view里结合infoobjects和这个ADSO的view。