（这里说的ABAP报表是用来区分BW报表的。）
说说报表的开发思路吧，通过最近的学习，个人还是有一些想法的。
报表的自主开发设计主要逻辑都是依托于选择屏幕上字段，也就是提供给用户让他们得到自己想要结果的选择条件途径。其中最重要的就是必选字段，因为必选字段是取数逻辑的精华所在，他可以很巧妙的限制很多非必要的情况出现，减少代码开发人员的开发量，还能让用户最直接最快捷的得到与实际业务相关的展现结果。
对于一个报表程序的代码编写，一般都会有几个INCLUDE.(X代表任意自定义字母)
REPORT ZXXXXXX.
INCLUDE ZXXXX_INIT.
INCLUDE ZXXXX_F01.
INCLUDE ZXXXX_block.
很多都是个人习惯吧，但是有一些习惯，能够让其他人在读你写的程序或者修改的时候，很快捷，有规律可循。
INCLUDE ZXXXXX_BlOCK。
里面有无非就是以下几个部分
INITIALIZATION.（初始化。在所有以下事件块运行之前运行的，只运行一次的事件块）
AT SELECTTION-SCREEN OUTPUT.（PBO事件块）
AT SELECTION-SCREEN ON VALUE-REQUEST FOR 选择屏幕字段名称。（自定义搜索帮助事件块）
AT SELECTION-SCREEN.（PAI事件块）
START-OF-SELECTION.（程序运行事件块）
PS(我的个人见解）：SAP中的程序还是有很多类型的.尤其是类报表程序，有可执行程序（REPORT 开头）还有MODULE POOL（PROGARM 开头）2种形式.
那么他们什么区别呢？有教材解释SAP的ABAP开发属于事件驱动开发。这和VB很类似。但是恰恰是这句话，很精华的解释了SAP程序的必然结构。对于事件驱动，那么，SAP程序就需要是由一个个事件去触发才能够执行的程序，当我们使用SE38去创建1类型的可执行性程序（EPORT 开头）这样的程序，我们可以直接调试，我们会发现，这个程序是按照我所写的以上事件块的顺序去依次执行的。它的事件块的顺序是指定好的。所以我们能够F8，去运行。我们去创建MODULE POOL就不能去执行，因为它需要用TCODE的去指定运行入口，一般都会在MODULE POOL 里面创建 SCREEN . 在一个SCREEN里 就会有两个事件块，就是PBO 和PAI.我们使用多个大量的屏幕，或者使用TABLECONTROL控件，再或是使用子屏幕范围控件嵌套各种SUBSCREEN(子屏幕),其中都是需要PAI 和 PBO 相互联系的，一个屏幕的PAI中，必然后会有一个CALL SCREEN 或者CALL SUBSCREEN ... INCLUDIG....命令去调用另一个屏幕或者子屏幕，然后另一个屏幕先运行PBO，有屏幕上的操作，就执行被操作屏幕的PAI。个人感觉正式这种灵活的编写方式，导致了这种类型（MODULE POOL）的程序不能直接F8，编译器无法获取程序从哪里开始，而TCODE就会指定从哪个屏幕开始。
我的前辈们，一般都习惯使用以下的习惯。
1、 INCLUDE ZXXXX_INIT.
进如程序的第一个INCLUDE。
PS(个人见解):INCLUDE 是什么？(CR:就是产生的请求号，也可以理解为一个程序的代码版本，所有的SAP程序都是在D系统（DEVELOPMENT SYSTEM）然后传到Q（测试）系统由顾问进行测试，又不干扰生产系统的程序运行，最后再传到P（生产）系统，覆盖原来的代码，变成修改后代码逻辑)恩，我感觉它是一种封装起来的思想。我研究一下，它单独产生CR,而和它的主程序没有任何关联。这也是必然的，因为INCLUDE是一个全局全系统的声明，一旦你取了一个名字，那么其他人也能够引用使用，这就导致它的修改CR是单独产生的。
这里定义各种只有在本程序里面生效的结构，例如TYPES定义类型。只有使用TYPES定义的类型后，我们才能使用DATA ..TYPE (我们TYPES的类型) 。使用DATA来定义结构，我们只能用LIKE来定义和他类似的结构DATA ... LIKE （DATA的结构）。
再然后就是SELECT-SCREEN 的相关定义了。
2、习惯使用PERFROM来封装代码，取有意义的名字，然后把所有的FORM都丢进
INCLUDE ZXXXX_F01中。
3、在START-OF-SELECTION中，我们一般都会写以下几个PERFORM,
PREFORM SUB_GET_DATA.(取数逻辑)
PERFORM SUB_DATA_PROCESS. （处理取出来的数据，按照想要的格式展现）
PERFORM SUB_BUILD_ALV. （创建ALV显示格式）
PERFORM SUB_SHOW_ALV.（调用ALV函数）
到此为止，一个报表程序的框架就出来了。当然，其中在注意使用一下宏等小地方，来节省代码的行数。
尽可能实现代码的复用。注意在FORM里定义的变量在离开FORM后，就会被系统释放掉，回收内存空间。
尤其注意的就是再优秀的报表开发中，BC414中的LUW概念（数据库的更新回滚，如果多个屏幕的操作会导致操数据库语句隐式的COMMIT ,导致背离NOTHING OR ALL 的原则，无法做到数据的全部回滚，还有使用PERORM ... ON COMMIT等方式可以是暂时制止隐式DB COMMIT），与标准程序使用的数据库表互锁（审批程序）(SAP的锁概念，是很有意思的。) （再就是解释BDC其中DB COMMIT选项的妙用，会跳过类似COMMIT的控件继续录屏，而不会终止当前录屏操作。）（BC414中还很全面的解释了 SAP工作的框架，以及一些负载平衡的初级概念）等等。
SAP程序优化，是BC490的范畴，最近比较忙，还没有去研究，BC414是基础。
SAP报表程序只是我们了解SAP的一种直观手段，不是所有ABAPER工作的全部。
自己也总结了些在MM SD模块遇到的数据表与业务之间的联系。