在接到业务需求之后，我认为重要的是理清楚自己该做什么。来实现业务。由于不了解业务，还是走了很多弯路。本可以不用这么做，还是这么做了。自然你最傻瓜的按照用户的方式去实现是没有问题的。
会使后面的人难以维护，可以精简的流程也变的复杂。冗余很多。那目前还不是我的层次，达不到。只能按照用户的想法去做。
因为是BW ON HANA 系统。能在BW 里将数据处理好 就在BW， 在HANA 视图里做简单的JOIN 。
WEBI 里复杂的逻辑判断做展示。没有什么绝对。看那个好做。我所掌握大体如此。
BW 里是我的弱项（业务以及ABAP）。 而HANA 的带参数的存储过程让我也挺苦恼的。（主要没有业务，或者轮不到我上手写存储过程）
接到业务报表需求：
将业务的陈述的逻辑，转为数据库关系，或计算机能理解的语言。
1 习惯用VISIO ，理清楚LOGIC。
画出每个DSO主表或者主数据表。相互涉及的关系。表关系，通过什么字段（主键或者维度字段）关系起来。
寻找解决的方法。
（这是个DEMO）很丑，我知道，可是有用
BW取数
纯BW 取数由于有主数据，导航属性。制作成QUERY 时可以直接拖出来使用。不会存在已经 经销商代码，还要在DSO取出明细的经销商名称的维度显示（一般做导航属性）。
可是HANA经常会碰到这样的情况，你取这DSO的激活表，可它并不会带出导航属性给你 。
那只能在HANA里做主数据（维度表），要是没做。只能反复JOIN 。不麻烦，影响美观，而且没必要。 最好还是在BW里清洗一遍。处理完整。
第一种方式取主数据表，单个值。
* 获取经销商名称
DATA : g_/BIC/Z0JXSDM TYPE /BIC/PZ0JXSDM-/BIC/Z0JXSDM .
LOOP AT RESULT_PACKAGE ASSIGNING <RESULT_FIELDS> .
CLEAR g_/BIC/Z0JXSDM .
g_/BIC/Z0JXSDM = <RESULT_FIELDS>-/BIC/Z0JXSDM .
SELECT SINGLE /BIC/Z0JXSMC FROM /BIC/PZ0JXSDM
INTO <RESULT_FIELDS>-/BIC/Z0JXSMC
WHERE /BIC/Z0JXSDM = g_/BIC/Z0JXSDM .
ENDLOOP.第二种获取DSO表中的值。
SELECT /BIC/ZMATERIAL CALQUARTER /BIC/ZSFZR /BIC/ZSFJRDGMB FROM
/BIC/AZCZJTO2600
INTO CORRESPONDING FIELDS OF TABLE IT_ZCZJTO26 FOR ALL ENTRIES IN
RESULT_PACKAGE
WHERE /BIC/ZMATERIAL = RESULT_PACKAGE-/BIC/ZMATERIAL AND CALQUARTER
=
RESULT_PACKAGE-CALQUARTER. *循环将内表里IT_ZCZJTO26 分配给工作区 WA_ZCZJTO26 。做了分配
LOOP AT RESULT_PACKAGE ASSIGNING <RESULT_FIELDS> .
READ TABLE IT_ZCZJTO26 INTO WA_ZCZJTO26
WITH KEY /BIC/ZMATERIAL = <RESULT_FIELDS>-/BIC/ZMATERIAL CALQUARTER
=
<RESULT_FIELDS>-CALQUARTER.
*执行成功 ，结果是否折让等于工作区 WA_ZCZJTO26-/BIC/ZSFZR.，是/BIC/AZCZJTO2600 里的字段。
IF sy-subrc = .
<RESULT_FIELDS>-/BIC/ZSFZR = WA_ZCZJTO26-/BIC/ZSFZR.
<RESULT_FIELDS>-/BIC/ZSFJRDGMB = WA_ZCZJTO26-/BIC/ZSFJRDGMB.
ENDIF.
ENDLOOP.
这就是我所知道的两种方式了。 都是比较简单易懂，取数操作。
其次充分应用BW DSO 转换模型，过滤 。很多读取主数据，读取DSO，公式方式，思考是不是一定要写这ABAP。（能不写就不写，后人维护交接工作难受。）
BW关建值汇总
插嘴说一句DSO 的特性。方便关建值汇总。
同一个请求中,加载的数据条数由主键决定,相同主键取一条.DSO中主键相同的数据会覆盖取最后一条记录.汇总时会取所有记录的汇总值.
用于再往上建一层DSO 取汇总值。关键在于主键的设置，例如只取经销商的提车量。那么你只需要将经销商设为主键就好。转换里更改提车量覆盖为汇总。
HANA 也可以做到。建一个project 映射 只取两个字段，上一层aggregate 汇总提车量就好。 具体看自己想怎么做吧。
我觉得BW做的话，会比较好。减少了HANA的视图，模型过多影响BW而已。有改动会比较麻烦。 走传输，basis，写报告
HANA 做的话灵活是灵活了，业务需求更改花不了多少，一下就好。但是会显得视图非常多，冗余。主要没必要贪轻松。还是看业务需求。
具体情况具体分析