t+产品开发手册.docx

T+产品开发手册作者：T+产品研发部 版本号：1.0 时间：版权所有：畅捷通信息技术有限公司 ChanJet Corp. Ltd.- 58 -1.变更说明目前的 T+平台在不断的完善过程中，因此 T+产品开发过程也会不断变化。下面的表单 用于详细记录本开发手册变更过程。序号变更位置变更内容说明变更人变更日期1234567892.引言2.1. 编写目的随着 T+产品业务的不断扩大，个性化需求越来越多。如何能够让其他人员利用 T+平台 进行个性化开发是要面临的重要问题。同时，随着 T+产品开发人员流动，如何降低新员工 学习成本，更快的融入开发团队，也是亟待解决的问题。为解决以上问题，急需一个成熟的 开发手册。为此，撰写此 T+产品开发手册。2.2. 名词术语说明在开发描述中会涉及到一些通用的名词术语，为便于阅读者理解，对这些名词术语进行 进一步说明。具体说明如下：序号名称术语详细描述变更日期1234567892.3. 参考资料3.开发模型3.1. 拓扑模型IntranetInternet通数据库服务器通应用服务器移动PC通Web服务器 防火墙Web客户端Web客户端Web客户端PDA此系统是一个 B/S 架构的产品，服务器集中部暑。在内部局域网中，用户可以通过浏览 器直接访问 WEB 服务器；其它受管辖的局域网也可以通过专网访问内网中 WEB 服务器；另 外 Internet 用户可以跨越防火墙，通过代理服务器进行业务操作。为了提高性能，我们可以把 web 服务器与应用服务部署在一台服务器上，减少不必要的 远程调用；如果用户想要把 web 服务器与应用服务器进行物理上的分离部暑，我们的应用框 架也支持这种部暑，并且我们采用 http 的传输协议。此系统架构中，采用后台提供服务的架构设计，降低产品中各模块的偶合度。 逻辑模型上面所式三层服务体系结构基本上是一个松散的三层体系结构。三层分别是：表示层。表示层提供应用程序的用户界面 (UI)，处理用户和软件间的交互。主要职责 是向用户显示信息并把从用户获取的信息解释成业务层或者数据源层的各种动作。业务层。业务层实现应用程序的业务逻辑：根据输入或者已有的数据进行计算，对从表 现层输入的数据进行验证，处理从表现层接受到的命令来确定应该调用那些数据源逻辑。数据源层。数据层提供对外部系统（如数据库、和其它系统提供的服务）的访问。 每一层应当按下面各段落所述进行构造表示层： 包括一系列与用户交互的窗体（或页面）。每个窗体用来显示系统提供的信息以及传递 用户的输入信息。这种基于窗体的用户界面包括两种类型的组件：用户界面组件(UI)基于.NET Framework 提供的组件，包括 Win Form 组件和 Web Form 组件。第 三方提供的组件和平台开发的组件。例如：单据、参照、单据列表组件等。用户界面处理组件(UIP) 复杂的用户界面通常需要很多非常复杂的窗体。为了提高其可复用性、可维护性和可扩展性，需要创建一个分离用户界面处理的组件，以封装窗体和界面导航之 间的相关逻辑。可以对一个简单窗体中组件之间的依赖、确认和导航应用相同的概 念。业务层：大型的企业级应用通常围绕业务组件和业务过程进行构造。这些通常以业务层的很多组件、实体、 代理和接口展现出来。业务对象(BE)：业务对象封装一个业务中的元数据、存储、并发和一件事物的业务规则、过程或 事件。多个独立的但有关联关系的业务对象可以一起协作来完成一个应用。完成不同的任务需执行很多具有不同特点的业务对象。业务对象负责执行包括强制的业务 规则、应用规则、数据有效性、并发和存储等所有方面的内容。业务实体对象是业 务中实际存在的事物或概念，是对“ER”模型中概念的面向对象的扩展。业务处理对象(BP)：描述贯穿业务的工作流程和信息。这些处理驱动业务实体完成业务功能。业 务处理对象可能由工作流系统、业务对象管理器、面向对象语言、程序语言、或交 互过程定义系统实现。通过调度一个或多个业务对象实现业务处理。业务处理可以 作为对象的一部分在内部完成。服务接口(Interface)：一个应用可能会以服务的方式提供一些功能供其它应用使用。服务接口代表这种对外 的服务。它隐藏了实现细节，只提供必要的业务接口。表示和业务的调用：业务层的调用服务通过平台提供的服务工厂来实现。这样有 利于二次开发服务能够动态的扩展到应用程序中去。数据层：业务应用必须访问存储在数据库中的数据。这些数据库通常是关系数据库。数据访问组件负责访 问存储在这些数据库中的数据，并与业务层进行交互。数据访问组件隔离业务层和数据存储管理。这种隔离有以下好处：减少数据库提供者变更带来的影响；减少因数据对象变更带来的影响（如变更数据库的schema）；封装数据的处理操作，这将在很大程度上减少测试和维护工作； 通过平台提供的数据访问服务组件管理O-R mapping的复杂度，同时能够再不改变表现层和业务层的情况下来转换不同的数据库。 实体数据传递-EntityData在Web服务器端和应用服务器端通讯或应用之间通讯时，我们采用粗粒度的服务，使用DTO(Data Transfer Object)来传递数据。在设计时，我们将为每一个实体类自动产生一个EntityData数据类，该类中包 含与实体相同的属性。在前端可以使用数据类，但不能使用实体类。服务网关：业务组件经常必须访问内部或外部的服务或应用。一个服务网关是封装了接口、协议和使用这种服务 的代码的组件。服务网关可以模拟外部服务促进领域测试。技术平台（EAP）：基础引擎：服务总线，O-R Maping,系统日志，事务、缓存、Ajax，认证、安全 等内容， 基础组件和模版组件，工作流，数据交换业务平台（BAP）：根据小企业的特点定业业务模式框架3.2. 物理模型客户端（浏览器）0.*Http1.1Web服务器应用服务器T21协议UICUIPHttps协议1.1ServiceBPInterfaceEAPBEEAP1.1数据库服务器用户界面组件 (UIC) 和用户界面进程组件 (UIP)，和业务层接口（Interface） 是对 Internet 公开的，并且可能潜在地与许多客户端交互。由于这些表示层组件通常公开于公 司防火墙外部，因此其安全要求通常比未公开的组件具有多得多的限制。此外，许多组织要 求公开于 Internet 中的服务器不能包含任何敏感数据。因此，通过将表示层组件单独放入 一级并配置该级使其具有最高安全性，可显著提高解决方案的总体安全性，同时可尽量降低 对安全性要求相对较低的组件的影响。由于表示层组件公开于 Internet 中，因此其性能和可伸缩性要求通常不同于域和数据 访问层组件的性能和可伸缩性要求。表示层组件通常为处理以突发方式与组件交互的许多并 发用户而进行优化。域和数据访问层组件通常为处理来自相对较少的源所发出的稳定请求流 而进行优化。配置一个可充分支持这两组优化的级可能是非常困难的。因此，解决方案是使 用两级，并使每一层针对所驻留的组件类型进行优化3.3. 部署路径扩展纬度逻辑纬度T+核心应用层App 扩展层CoreExtendsWEB 服务器UFSmart/&Version/WebsiteUFSmart/Version/Website/Extends应用服务器UFSmart/&Version /AppServerUFSmart/Version/AppServer /Entends数据库服务器UFSmart/&Version /DatabaseUFSmart/&Version/Database/Extends说明:其中&Version 版本代表本版要发版的版本标识4.SDK 应用开发4.1. 开发环境准备4.1.1.硬件配置建议配置信息如下：CPU ：双核主频 2G 以上 内存：DDR2,2G 以上硬盘：普通 SCSI（或 SAS）硬盘，磁盘格式为 NTFS 容量磁盘剩余空间 40G 以上4.1.2.软件配置建议配置如下：数据库操作系统开发工具MSSQLServer2005 及以 上Windows XP、Window7、 Window8、Window2003、 Window2008Vs2010 及以上4.1.3. SDK 包T+提供相应的开发包4.1.4.开发规范开发限制，在后续中逐步完善4.2. 应用场景开发格式说明：1、 依赖动态库2、 实现接口3、 配置文件4、 案例4.2.1.开发表单.基础设置列表及表单开发.1.应用场景在现有 T+产品中，往往有这种应用场景：对某个业务表以列表的形式展示处理，并能 对这个业务表进行增、删、改操作。像 T+产品中的基础设置下的仓库、业务类型档案的实 现如下：1、进入档案，展示出档案列表信息界面2、新增、修改后进入档案编辑界面3、保存后退出，返回到列表，并把新增内容展示在列表中针对此种场景，我们进行了归纳总结，提供了总体实现方案。.2.设计思路这种场景主要依赖于三个组件：按钮组件、栏目组件和单据组件。通过对场景分析，抽 取出公共的特性进行分析，规范场景处理流程。对于个性化需求，通过提供扩建接口的方式 来实现。.3.应用举例现在以一个实例讲述这个场景的开发过程。需求如下：XX 公司想在 T+系统中增加一个基础档案：物流公司档案。.3.1. 第一步：确定菜单名称及编码，并创建菜单要创建 XX 公司二次开发菜单，开发主菜单我们暂命名为:xx 公司管理(这个名称由二次 开发公司自己命名或根据客户需求命名)，菜单编码命名为：AppCjtIDXX，其中 App 是 T+规 定，必须以此前缀命名，CjtID 是由畅捷通分配给二次开发公司的唯一 ID，XX 可以由二次 开发公司自己任意确定。对于物流公司档案这个子菜单，Code 可以命名为 AppCjtIDAA01.目 前 菜 单 创 建 已 提 供 可 视 化 工 具 ， 工 具 目 录 为 开 发 包 下 的 AppServerserverPrivilegeTool.exe,菜单创建过程如下：1、 进入工具，输入数据库连接信息及 T+产品账套，进入菜单预置主界面2、 进入菜单预置界面，创建“xx 公司管理”主菜单注意：红色标注的是要重点输入的地方3、 在“xx 公司管理”主菜单下创建“物流公司”子菜单至此，菜单创建工作完成。.3.2. 第二步：创建 DTO 项目文件1、 创 建Ufida.T.App.CjtID.DTO项 目 文 件 , 并 引 用Ufida.T.AA.DTO.dll, Ufida.T.EAP.DataStruct.dll 两个 T+开发包自动的 dll，其中 Ufida.T.AA.DTO.dll属于 T+基础档案类库，如果在二次开发 DTO 中用到 T+基础档案类库，可以引用此 dll， 如果没有引用到 T+基础档案类库，可以不引用。创建过程如下图所示：2、 修改 DTO 工程文件属性信息依据 T+产品框架结构，DTO 应该至于 Appseverserver 和 Websitebin 下，因此在创建 工程文件时，最好提前设置。本实例首先把 Ufida.T.App.CjtID.DTO.dll 生成到一个公 共文件 pubref 下，然后在生成后事件里，从 pubref 下 copy 到开发包 Appserverserver 和 Websitebin 两个目录下。如下图设置所示：.3.3. 第三步：创建物流公司档案 DTO目 前 已 提 供 DTO 可 视 化 工 具 ， 工 具 地 址 开 发 包 下 Appserverserver Ufida.T.EAP.Tool.StartDesigner.exe1、 对 DTO 包进行命名依据规则对“XX 公司管理”命名，包标题为：xx 公司管理 DTO（可根据开发者习惯 命名）,名称为 Ufida_T_App_CjtID_DTO（Ufida_T_App_CjtID 部分是 T+要求，后面 可以开发者自己确定），命名空间为 Ufida.T.App.CjtID.DTO（与第二步中 DTO 项目 保持一致）,vs 项目则选择第二步所创建的项目文件路径。如下图所示：2、 包保存成功后进入包，创建物流公司档案 DTOa)创建物流公司 DTO 基本属性目前已提供了 DTO 的基本属性，只需在创建界面上打勾选择即可，其中 DTO 名称根据开发者自己命名，为避免在引用中和 T+类库冲突，也便于通过 DTO 名称 直接区分，DTO 名称前建议加上 CjtID；数据库表名规定前面部分为 AppCjtID_； 而 Ts、upadateBy、updated、名称字段、编号字段必须打勾，如下图所示：b)添加物流公司 DTO 档案属性除了 DTO 公共属性，每个档案都有自己的属性。这可以根据需求，通过 DTO 设计器进行创建，如下图所示：其中物流公司名称、物流公司编码是文本类型的，而所属仓库是引用的 T+基 础档案。c)通过 DTO 设计器生成物流公司 DTO 代码选中 DTO，通过操作：“生成代码”-“选中 DTO”，则生成的 DTO 代码保存到 项目工程文件下。此操作只生成一个 DTO 代码，如果 DTO 比较多，可通过操作“生 成代码”-“按包生成”，全部生成最好不要操作，这个是生成的 DTO 设计器下的 所有 DTO，包括 T+产品原有的。操作过程如下所示：d)查看生成的 DTO 代码并编译通过生成后，我们会发现 DTO 项目文件中多了我们设计的 DTO 代码，编译此工 程文件，没有错误，则此档案 DTO 设计完成。如下图所示：e)导出 DTO 元数据脚本和数据库结构脚本通过 DTO 设计器中“元数据”菜单下的“导出 DTO 元数据”和“生成业务表脚 本功能”，导出 DTO 元数据脚本和数据库结构脚本，以供做包使用。至此，DTO 创建工作全部完成。.3.4. 第四步：创建程序代码依据 T+产品架构，创建新增业务前后台代码。 1、 创建 BE 层实体类BE 层主要用于处理实体类简单的业务逻辑，放在安装包 Appserverserver 层。创建流 程如下：其中 BE 项目文件需要引用 T+类库中的 Ufida.T.BAP.BusinessApplication.dll、 Ufida.T.EAP.DataStruct.dll 和自己开发 的 Ufida.T.App.CjtID.DTO.dll ， 实体 类 CjtIDLogisticBE 需要继承基类 BusinessEntityTemplate，其他的暂时 不管。编译BE生成dll2、 创建 BP 层实体类BP 层主要处理实体类的主要业务逻辑，放在安装包 Appserverserver 层。创建流 程如下：其中BP项目文件需要引用T+类库中的Ufida.T.Bap.Base.dll、 Ufida.T.Bap.BusinessApplication.dll、Ufida.T.EAP.DataStruct.dll三个类库以及自己 开发的Ufida.T.App.CjtID.DTO.dll、Ufida.T.App.CjtID.BE.dll。实体类CjtIDLogisticBP 需要继承基类BusinessEntityBpBase，其他的暂时不管。编译BP生成dll。3、 创建 Interface 层实体接口Interface 层主要用于提供外部接口，以供外部调用,放在安装包 Appserverserver 和 Websitebin 下。创建流程如下：其中Interface项目文件需要引用T+类库中Ufida.T.Bap.Base.dll、 Ufida.T.EAP.DataStruct.dll两个类库和自己开发的Ufia.T.App.CjtID.DTO.dll类库。接口 类ICjtIDLogistic需要继承基类接口IEntityService，其他的暂时不管。编译Interface生成dll。4、 创建 Service 层实体类Service 层主要用于接口的具体实现，可自己独立完成相应的业务逻辑处理，也可调用 BE、BP 辅助完成相应的业务逻辑处理。放在安装包 Appserverserver 下。创建流程如 下：其中Service项目文件需要引用T+类库中的Ufida.T.Bap.Base.dll、 Ufida.T.Bap.BusinessApplication.dll、Ufida.T.EAP.DataStruct.dll和自己开发的 Ufida.T.App.CjtID.DTO.dll、Ufida.T.App.CjtID.BE.dll、Ufida.T.App.CjtID.BP.dll。 服务类需要继承基类及实现自己的接口如下：BusinessEntityServiceBase, ICjtIDLogistic，其他暂时不管。 编译 Service 生成 dll。5、 创建 UIP 层实体类UIP 层主要用于处理前台逻辑。并通过接口调用方式完成前台与后台交互。放在安装包Websitebin 下。创建流程如下：其中UIP项目文件引用T+类库中Ufida.T.Bap.Base.dll、Ufida.T.Bap.Web.dll、 Ufida.T.EAP.DataStruct.dll和自己开发的Ufida.T.App.CjtID.DTO.dll、 Ufida.T.App.CjtID.Interface.dll。CjtIDLogisticCardController继承基类 BaseInfoCardController用于处理卡片表单的后台逻辑（需要 实现基类中的抽象方法），CjtIDLogisticListController继承基类 BaseInfoListController用于处理卡片列表的后台逻辑。编译生成dll。 至此，代码框架结构创建完成。总体来说，代码结构如下：所对应的dll放置位置结构如下： AppServerWebsite|-server|-Bin|-Ufida.T.App.CjtID.BE|-Ufida.T.App.CjtID.BP|-Ufida.T.App.CjtID.Service|-Ufida.T.App.CjtID.DTO|-Ufida.T.App.CjtID.Interface|- Ufida.T.App.CjtID.DTO|- Ufida.T.App.CjtID.Interface|- Ufida.T.App.CjtID.UIP.3.5. 第五步：列表栏目预置在列表展示时，该列表所展示的列是通过栏目预置的方式实现。栏目预置目前已提供相 应的可视化工具，目前的位置在开发包 Appserverserver T.EAP.IDE.exe(注：目前提供 的包里暂时不包括此工具，有待完善)。针对物流公司我需要展示“物流公司名称”、“物流 公司编码”、“所属仓库”等字段，则栏目预置过程如下：1、 确定栏目方案名称此栏目方案名称开发者可任意名称，为避免重复，建议前面加上 AppCjtID_,此栏目 预置为：AppCjtID_LogisticColumn。2、 进入栏目预置工具（暂时这样使用，以后会加以改进） 进入如下界面：点击栏目，进入栏目预置界面：3、 预置必输字段在栏目实现时，主要依赖于每个 DTO 的 ID 和 Ts 列，所以这两列必须预置，且是系 统字段和用于开发字段。如图所示：a) 新增方案b) 为方案新增必输字段其中这两个字段小数位数、精度必须为 null，是系统字段，且是必选字段。另外 ID、 Ts 名字也按照上述预置，区分大小写。 如果以上预置不符合条件，请通过如下语句修改：update Eap_ColumnSet set DecimalDigits=null,Precision=null where SolutionID= (select id from eap_ColumnSetSolution where Name= 自己 命名的方案 Name);update Eap_ColumnSet set IsSystem=1,IsDevField=1 where SolutionID=(select id from eap_ColumnSetSolution where Name= 自己 命名的方案 Name);4、 预置展示字段其中需要注意的：字符类型的小数位数和精度字段必须为 null，字段预置和 DTO 对应，如 果是引用关系，则依据 DTO 中属性层级关系预置，如上图所属仓库预置。5、 导出脚本 通过工具中“导出”菜单，则导出栏目预置脚本至此，栏目预置完成。.3.6. 第六步：卡片表单预置卡 片 表 单 目 前 有 可 视 化 预 置 工 具 ， 工 具 位 置 安 装 包 Appserverserver VoucherDesigner.exe,预置过程如下：1、 确定卡片所属分组目前包暂命名为 xx 公司管理，新建分组如下：2、 确定物流公司卡片表单名称并创建表 单 命 名 开 发 者 可 以 自 己 定 义 ， 对 于 物 流 公 司 卡 片 表 单 ， 命 名 为 ： AppCjtIDLogisticVoucher其中表单创建必须依赖于已存在 DTO。 3、 通过拖拽方式创建表单如上图所示，对于文本类型的属性，直接拖拽，一般不用进行修改即可。对于引用类型的则 需要设置对一些属性进行设置，以满足控件要求，比如下拉参照等。4、 导出元数据脚本 通过工具的“导出元数据”功能，实现对表单原始的导出，如下图所示：至此卡片表单预置完成。.3.7. 第七步：配置及功能实现通过以上 6 步数据及代码准备工作，基础设置列表及表单开发可以如下配置并实现： 1、 Website 创建独立的运行目录，命名为 AppCjtID2、 增加新增模块配置文件配置信息在 Website BAPFunctionMapping.config 中增加新增模块配置文件的配置信息如 下：3、 新增配置文件在 WebsiteAppCjtIDConfig 目录下创建 voucher.config 配置文件内容如下：其中红圈标注部分需要注意：a) subsystem 节点的 assembly 属性指的是前端对应的后台处理程序集名称。b) controller 节点中 viewName 为 baseInfoCard 对应的 type 指的是卡片表单后台 处理类名，templateName 属性节点对应的 value 值指的是该卡片表单对应的卡 片元数据名称（已在前面预置过）。c) controller 节点中 viewName 为 baseInfoListView 指的是卡片列表后台处理类 名，columnSetName 属性节点对应的 value 值指的是该卡片列表对应的栏目方案 名称（已在前面预置过）。4、 新建卡片表单前台处理脚本，并修改对应的后台处理类。a) 在 Website/AppCjtID/Js 下新增脚本文件 CjtIDLogisticCard.js 并添加内容如 下：其中$T.Bap.Declare 部分是声明命名空间，下面的部分是创建改卡片表单自己的 前台处理类并继承 自 Website/BAPView/Js/ Voucher-vsdoc.js 文 件 中 Ufida.T.BAP.Client.Card 脚本基类。b) 修 改 卡 片 表 单 对 应 的 后 台 处 理 类Ufida.T.App.CjtID.UIP. CjtIDLogisticCardController 如下：如红色标注所示：需要声明 ClientObject 属性，参数为前台 js 类名，并注册脚本。 5、 新建卡片列表前台处理脚步，并修改对应的后台处理类。a) 在 Website/AppCjtID/Js 下新增脚本文件 CjtIDLogisticList.js 并添加内容如下：其中$T.Bap.Declare部分是声明命名空间，下面的部分是创建改卡片表单自己的前 台处理类并继承自Website/BAPView/Js/ List-vsdoc.js文件中Ufida .T .BAP.Client.ReadOnlyList脚本基类。b) 修改卡片表单对应的后台处理类 Ufida.T.App.CjtID.UIP. CjtIDLogisticListController类 如下：如红色标注所示：需要声明 ClientObject 属性，参数为前台 js 类名，并注册脚本。c)重新编译此 dll6、 修改服务配置文件服务配置文件，在安装包 Appserverconfig 目录下涉及到配置文件的修改如下： 可以在原有配置文件的基础上新增服务接口配置，也可以重新创建自己的服务接口 配置文件，并把此配置文件添加上服务配置中，目前采用后者配置如下：a)修改 services.xml 如下：b)新增配置文件 services_appcjtid.xml 并配置如下：其中 name 为新增服务接口名称，className 是接口对应服务实现类名，loadFrom 是 服务所在程序集7、 修改菜单配置文件a)进入菜单预置工具，修改物流公司菜单对应的RequestUrl为： BAPView/BaseInfoList.aspx?sysId=AppCjtID&mId=AppCjtIDAA01&pId=bas eInfoListView&SourceType=FromMenu，其中sysId是新增的配置文件 voucher.config中subsystem节点对应的Name值，mId是module节点对应的Name 值。b)增加常用菜单按钮如下：经过以上 7 个步骤后，现在我们进入产品，就可以看到我们新增这个功能的效果了。.3.8. 第八步：看运行效果.单据表单开发.1.应用场景单据表单在 T+产品中非常常见，像采购订单、销售订单等，如下图所示：基于这类产品的共性，T+平台进行了抽取，实现了基本的功能。.2.设计思路.3.应用举例.3.1. 业务分析通过业务需求分析,确定数据传输对象实体（DTO），关于 DTO 设计可以通过平台提供的 DTO 设计器来完成。预置工具：AppServer/server/Ufida.T.EAP.Tool.StartDesigner.exe 操作界面：注意：必须有的增加属性如下 单据主 DTO:Code,DocNo,DocClass,AccountingPeriod,DocID,AccountingYear,VoucherState,Memo,Vou cherDate,MadeDate,Maker,Auditor,AuditedDate,MakerId,AuditorId, Reviser, IsCarriedForwardOut, IsCarriedForwardIn, IsModifiedCode, CreatedTime,SequenceNumber 非单据主 DTO：CreatedTime, SequenceNumberDTO 设计完成后，生成对应的表结构和源代码，这个都可以通过工具进行导出生成。.3.2. 代码框架生成.3.2.1.代码规划开发包路径/|-pubRef|-AppServer|-src|-AppName|-|- Ufida.T.App.ChanjetID.AppName.DTO|-Ufida.T.App.ChanjetID.AppName.BE|-Ufida.T.App.ChanjetID.AppName.BP|-Ufida.T.App.ChanjetID.AppName.Interface|-Ufida.T.App.ChanjetID.AppName.Service|-Ufida.T.App.ChanjetID.AppName.UIP|-WebSiete|-App|-ChanjetID|-AppName|-|-AppExtVoucher|-JS|-JS.3.2.2. DTO 代码工程设置程序集依赖项：.3.2.3. BE 代码工程文件设置：程序集依赖项：代码继承说明：BE 代码需要继承 BusinessVoucherTemplate 和 BusinessEntityTempalate.3.2.4. BP 代码工程文件设置：程序集依赖项：代码继承说明：BP 代码需要继承 BusinessVoucherBpBase.3.2.5. Interface 代码工程文件设置：程序集依赖项：代码继承说明：Interface 代码需要继承 IVoucherService.3.2.6. Service 代码工程文件设置：程序集依赖项：代码继承说明：Service 代码需要继承 BusinessVoucherServiceBase.3.2.7. UIP 代码工程文件设置：程序集依赖项：代码继承说明：UIP代码需要继承 VoucherController, IExecuted.3.2.8. JS 代码.3.3. 配置文件.3.3.1.voucher.config路径：WebSite/App/ChanjetID/AppName/voucher.config 内容：注意:现在还需要配置 WebSiteBAPFunctionMapping.config.3.3.2.service_appchanjetidappname.config路径：Appserverconfigservice_appchanjetidappname.config 内容：注意:现在还需要配置 AppServerconfigservices.xml.3.3.3.APPCHANJETIDAPPNAME.tc路径：AppserverconfigBAPConfig 内容：.3.4. 预置数据.3.4.1.单据模板预置预置工具：Appserverserver VoucherDesigner.exe.3.4.2.菜单与功能按钮预置预置工具：Appserverserver PrivilegeTool.exe.3.4.3.单据类型预置数据SM_VoucherType.4.单据运行效果4.2.2.开发报表.名词解释联查：是一个超链接，有时候在一个报表中某条记录是对明细项的汇总，我们需要通过联查 来知道这条记录所对应的明细项。分级汇总：以地区为例，现有：“华北区北京市海淀区”，如果按地区 1 级汇总，则把属于华北区的北京市的数据汇总到“华北区”，共显示一行；如果按地区 2 级汇总， 则把属于华北区的北京市的数据汇总到“华北区”，再把属于北京市的海淀区的 数据汇总到“北京市”，共显示两行。分组汇总：按指定的条件对明细项分组，最终显示的是每一组的汇总值，明细项不显示 分组小计：按指定的条件对明细项分组，每一组中明细项都显示出来，最后再对这一组的明细进行汇总。表头带入项：把查询条件带入到报表最终所展现的页面中来，带入的查询条件显示在报表的 头部。.报表整体介绍报表主要是有下面几部分组成的：（1）预置数据：包括字段预置、栏目预置、查询预置、分组预置、字段权限预置等。（2）报表服务 Server：获得动态 sql。（3）UIP：主要负责处理表头带入项，自定义的控制、显示。（4）联查处理：有模块内的联查和跨模块联查。（5）后置选项控制：根据设置，控制查询、分组、栏目中字段的可见性。（6）配置文件：配置 Server、UIP、账套选项前置校验和后置操作类配置。 下面的章节将详细介绍这几点.元数据预置步骤1 分析和设计数据源 SQL参照需要设计的报表需求文档，找到报表中使用到的概念、实体、属性形成报表字段。 这些字段包括报表要显示的内容，要过滤的条件、要考核的各类指标和指标项等等。通常报表是构建 SQL 查询语句获得数据，下面罗列的字段都写到 select 语句里。所形 成的 SQL 格式如下：SELECT TableAliasName.Date AS Date,Sum(TableAliasName.Quantity) Quantity,.FROMTableName AS TableAliasNameLEFT JOIN Voucher AS VoucherAliasName ON TableAliasName.id = VoucherAliasName.id.WhereTableAliasName.Date 2012-11-28 Group by TableAliasName.NameOrder by TableAliasName.Name.确定了字段和数据来源后，要通过把以上信息元数据化，元数据化最有效的办法是使 用工具，后面是有关工具使用的说明。2 配置报表工具环境用最新的安装包建立账套，进入安装包的 Appserverserver 目录下，运行 DBConfig， 配置数据库。3 报表预置工具(ReportBuilder.exe)的使用关于 Appserverserver 目录下的 ReportBuilder.exe，提供对报表的列显示、列排序、 分组、小计、合计、是否排序条件、排序方式以及客户可见进行设置，初始化客户在报表的 设置期间是否可以看见某一列的设置以及显示，字段成组，分级，自定义项，自由项的预置。a新增一张报表打开报表预置工具，右击，选择”新建报表”，在弹出的输入框里填入相应的”报表名 称”、”报表标题”，选择对应的”报表类型”，在”主 SQL”的输入框里粘贴 1 步骤形成的数据源 SQL，最后，”菜单功能编码”填入 EAP_Menu 对应的编码。有关”报表名称”的命名参见命名规范文档。 注意：”菜单功能编码”文本框不可为空或误填，否则报表的权限控制会失效。b 字段设置选择新建的报表标题，进入”字段设置”， 点击【从 SQL 导入】，就会解析 SQL，生成字 段（也可以点击【增加字段】），这样设计数据源 SQL 字段就都导入到 eap_reportfield 这张 表了，但其 title 字段还是 SQL 名称，且没有成组的信息，需要参照相应的需求文档做修改。【字段名称】SQL 中 AS 后面部分，也就是字段的别名。【字段标题】按照需求文档的【查询结果】的【字段】名称预置。【选择字段】SQL 中 AS 前面部分，如果命名规范，直接加点就行。【查询名称】将来拼写 where 条件的，由于这个字段会用到 eap_reporttablecol 中 selectfieldname，需要拼成类似与【selectfieldname】+”as”+【别名】。如果三个预置 数据都是一样，不符合 sql 语法规则，会报错。当报表工具左边的成组字段都改成需求文档的名称后，还需要手动点击“增加成组”按 钮，将逻辑成组的字段放在对应的组里。根据需求文档的【分组】设置可分组，也就是【列名】显示的名称都要勾选“可分组”。理解需求各字段的含义，自己总结增加逻辑上面的【成组】，每个成组有且只能有一个【主字段】。【小提示】：展现给用户的时候，成组内的字段位置只能在本组内移动，也可以整组移 动，联查传递数据是一个整体。明细表一般是一个引用型的对象包含一个组，特别要添加一个 ID，如【币种】，将来【分 组汇总】【汇总小计】【联查】的时候主要依据就是此成组中的【主字段】统计表，另外还要根据需求的【分组】显示内容【成组】，如例子中的【单据编号】 注意：分组字段的“主字段“的一定要选 ID 或编码字段。c栏目设置按照需求的【查询结果】顺序调整字段的排序，点击【上移】【下移】按钮，注意是操 作左边栏目数据的移动。【增加列头】点击后，弹出窗体，输入【名称】和【标题】，点击【确定】，左边会增加 列头，注意和逻辑上的【成组】区分，仔细看图标不一致。多列头实际运行时的效果，如下所示：根据需求的【查询结果】表设置显示情况：【可显示】对应于需求的【字段】列，【显示】对应于需求的【默认显示】列。 对于数值型还需要设置【可合计】【合计】，【可合计】根据需求设置成【1sum】。 注意：一些报表的“单价”或“报价”字段，还有些字段的需求规定“不进行小计与合计” 的都不需要设置【可合计】【合计】项。 统计表（或执行表）既不在分组，也不是合计的某些列，但是还要显示的设成【5-First】。【排序类型】按照需求设置【升序】【降序】【无】【格式】如金额设为 N，日期：D，加%为 P，具体参见帮助（红框的按钮）【样式】设置样式，具体看帮助；如数值型，如果为负数，则显示红色： Color:=IIf(not isNothing(Me.Value) And Me.Value0,Red,Black)bool 型字段数据：根据人机交互规范,需要居右显示，设置