STEERP系统升级项目-项目方案书-V1.0.docx

正本深圳证考交易所SHEZHSTOCKEHCHOGE深圳证券交易所ERP系统升级项目项目方案书Deloitte德勤德勤管理咨询（上海）有限公司2013年6月28日1 .证明文件错误味定义书签。1.1. 公司概况简介61.1.1. 德勤全球错误!未定义书签。1.1.2. 德勤中国错误!未定义书签。1.2. 营业执照错误!未定义书签。1.3. 项目咨询及实施人员简历错误味定义书签。1.4. 税务登记证副本错误!未定义书签。1.5. 公司经营相关项目业绩和类似合同完成简况错误味定义书签。1.5.1. 竞价单位业绩表错误!未定义书签。1.5.2. 德勤咨询在ORACLEERP相关领域部分大型案例介绍错误!未定义书签。1.6. 投标方近两年经审计的财务报表错误!未定义书签。1.6.1. 财务状况及资信说明书错误!未定义书签。1.6.2. 近两年的财务报表错误!未定义书签。1.7. 认证或其它资质证明错误味定义书签。1.7.1. 德勤获奖情况（部分）错误!未定义书签。1.7.2. Oracle原厂授权证明错误!未定义书签。1.7.3. Oracle高级实施合作伙伴资质证明错误!未定义书签。1.7.4. 合同范本错误!未定义书签。1.7.5. 投标方认为有必要提供的声明及文件错误!未定义书签。1.7.5.1. 德勤OradeERP实施及支持服务能力.错误!未定义书签。1.7.5.2. 德勤咨询业务能力特色和方法论.错误!未定义书签。1.7.5.3. 德勤知识管理体系错误!未定义书签。2 .项目实施方案（技术参数）错误!未定义书签。2.1. 功能方案92.1.1. 总体概览92.1.2. 多组织访问102.1.2.1. R12新功能102.7.2.2. 升级考量要点102.1.3. 法律实体112.1.3.1. R12新功能112.7.32升级考量要点122.1.4. 子分类帐会计132.1.4.1. R12新功能132.1.4.2. 升级考量要点142.1.5. 税务管理151.1.1 .1.R12新功能162.1.52 升级考量要点172.1.6. 高级公司间管理错误!未定义书签。2.1.6.1. R12新功能172.1.6.2. 升级考量要点182.1.7. 应付管理182.1.7.1. R12新功能182.1.7.2. 升级考量要点202.1.8. 总帐管理212.1.8.1. R12新功能212.1.8.2. 升级考量要点222.1.9. 资产管理221.1.1 .1.R12新功能222.1.92 升级考量要点232.1.10. 现金管理232.1.10.1. R12新功能232.1.10.2. 升级考量要点232.1.11. 应收管理232.1.11.1. R12新功能232.1.11.2. 升级考量要点242.1.12. 采购管理242.1.12.1. R12新功能242.1.12.2. 升级考量要点242.1.13. 库存管理252.1.13.1. R12新功能252.1.13.2. 升级考量要点252.1.14. 订单管理错误!未定义书签。2.1.14.1. R12新功能252.1.14.2. 升级考量要点252.1.15. OPM升级步骤举例错误!未定义书签。2.2. 技术方案262.2.1. 系统升级方案262.2.1.1. 背景262.2.1.2. 前提262.2.1.3. 要求的范围和目标.262.2.1.4. 升级技术方案.272.2.1.5. 技术方案概览.282.2.1.6. 技术方案阐述.302.2.1.7. 技术方案补充.342.2.1.8. 升级方案风险与应对.342.2.2. 客户化迁移方案352.2.2.1. 客户化总览352.2.2.2. 功能迁移（Form）352.2.2.3. 报表迁移（RDF类型的报表）362.2.2.4. 报表迁移（WEBPL/SQL报表）372.2.2.5. 客户化开发工具372.3. 关键需求点对点应答422.4. 升级测试策略452.4.1. 制定升级测试计划452.4.2. 细化测试内容462.4.3. 技术层面数据检查472.5. 系统切换方案472.5.1. 第一次模拟切换482.5.2. 第二次模拟切换482.5.3. 上线切换492.6. 项目实施方案502.6.1. 项目组织架构502.6.2. 服务排期（项目计划）502.6.3. 项目任务分工512.6.4. 项目交付物清单542.6.5. 服务承诺及优惠内容552.6.6. 项目实施方法602.6.7. 附：项目关键成员简历633 .竞价文件错误!未定义书签。3.1. 附件一、竞价函683.2. 附件二、法人代表授权书错误床定义书签。3.3. 附件三、竞价一览表错误味定义书签。1概述1.l需求分析和理解（HeiII7）1-2项目难点分析（HelIry）2 技术应答（功能顾问戚术顾问）M财务管理功能模块需求主要功能需求要求实现方式相关模块备注说明1.FSG财务报表改进借助FSG行集和xmlpublisher,对FSG进行开发，保证报表运行速度快，美观总帐主要功能需求要求实现方式相关模块备注说明2，人力资源功能模块需求主要功能需求要求实现方式相关模块备注说明主要功能需求要求实现方式相关模块备注说明多组织功能修改修改客户化form,workflow,package,二次开发主要功能需求要求实现方式相关模块备注说明table,view中的代码，增加多组织安全代码提供ERP数据脱敏解决方案，建立满足脱敏要求的开发测试环境。系统技术方案参考克隆环境脱敏方案Discoverer报表100多张系统技术方案参考技术方案中的Discoverer迁移方案历史数据迁移标准模块的数据在Ili升级时，OraCIe补丁会自动转换；对应客户化数据表，在数据迁移过程中会具体根据功能方案，考虑转换策略系统技术方案3 整体技术解决方案Vl功能方案总体概览在ERP升级过程中，如何保持原有系统功能可用性和历史数据准确性，是最核心的要求，因此，本次ERP升级，我们建议在立足“平稳过渡”的基础上，以“保证数据融合”为目标，通过多种应对策略，实现功能的平移和数据的融合。平稳过渡，需要把握三个原则： 保持功能完整性：原系统所用的功能，在升级后的系统中，应保持完整可用； 保持系统稳定性：升级后的系统，在系统性能方面，应具有一定的稳定性，确保日常业务正常处理； 保持数据准确性：系统升级是数据库底层技术架构的问题，应不能对历史数据的准确性产生影响。在以上原则下，要实现从RII“平稳过渡”至岷12.1.3的跳跃，将会面临多方面的难题，如所有原客户化程序需要重新移植；如此升级，功能范围涉及非常广，测试很难保证全面性等。针对这多方面的问题，德勤建议从“功能匹配，差异分析”和“多次模拟升级切换”两个方面去考虑。“多次模拟升级切换”的方式。系统标准功能随着ERP应用系统版本升级而升级，无需另外进行移植安装。为检验标准功能是否完整可用，需要对升级后的系统，进行完整的测试。为确保测试的完整性，我们建议对所用到的系统进行，进行完整的功能匹配，对每一项原有功能，明确列出新系统功能，新旧系统功能间是否存在差异，差异是什么，并对该差异的合理性进行评估。通过完整的ERP升级功能匹配清单，检查升级后的系统对原有功能的支撑情况。多组织访问R12新功能多组织访问控制（MoAC）是R12一项重要的新功能，通过多组织访问控制实现允许单一职责访问不同业务实体的权限控制，用户在权限范围内可以不必再申请多职责即可访问多业务实体的应用。通过将“安全性配置文件”分配给用户，限定用户可访问的数据权限，用户无需切换职责即可执行多业务实体的应用，用户可通过单一职责，在应用界面中，根据指定的业务实体进行数据输入、处理、提交请求等操作。升级考量要点设置多组织控制，需要定义包含多业务实体的安全性配置文件，分配至系统配置文件“MO:安全性配置文件”。通过定义系统配置文件“MO:默认的业务实体”可指定在表单或页面应用中的默认业务实体。11到R12的升级，需要考量用户多组织访问的业务需求，补充相关设置和验证数据迁移。法律实体2.1.2.1.R12新功能在R12版本中，法律实体在ORACLEEBS中由隐含的定义转为明确的法律实体。可以通过法律实体定义来应对不同国家法规和报告需要。法律实体结构允许分离于业务组织结构而表现法律组织结构。R12的新功能是具有指引用户创建法律实体流程的法人主体管理器。法人主体管理器，可以通过定义法律实体以应对多国家或法律制度的法规和报告需求。法律实体定义应用于以下业务处理：o基于法律实体的付款o公司间事务处理（法律实体间的贸易往来）o税计算（基于税务的权限而登记的法律组织）o银行帐户的所有权o子分类帐事务处理的所有权（例：应付或应收）o法律实体层的报告子分类帐事务处理题头除标识业务实体以外会额外标识法律实体。法律实体由以下信息确定：o每一笔事务处理都会存在于一个业务实体，该业务实体归属于当前事务处理记帐的分类帐。如果该分类帐具有一个以上的法律实体与之关联，那么，法律实体层次结构会用于默认的法律实体。例如：在AR中法律实体层次结构应用于事务处理：1 .事务处理类型2 .批来源分配法律实体至事务处理类型或批来源是可选择的，只有映射至与业务实体关联的分类帐的法律实体才可以用于分配。o如果没有其他的法律实体存在，业务实体的法律实体上下文中默认当前的法律实体。在默认法律实体上下文的值列表中显示的值（法律实体）必须关联了业务实体关联的分类帐。o如果任何来源都无法找到默认的法律实体，用户在输入事务处理时需要明确提供法律实体。2.1.2.2.升级考量要点配置变更:o移值当前数据到法律实体o创建法律实体并分配至会计科目设置。'GRELE类型的组织在R12升级中将做为创建法律实体的来源。数据迁移之后与'GRELE类型的HR组织之间不存在链接，应用法人主体管理器创建法律实体。o虽然作为法律实体升级的来源，在R12K,HR组织不能用于创建新的法律实体。o配置现有的组织成为法律实体或适当的组织。o使用法律实体的关联来维护业务架构（业务实体，库存组织、库存地点等）和法律架构间的关联。o分配法律实体至公司间组织（如果使用AGIS）H到R12的升级，需要考量数据迁移的验证和相关设置补充。 总帐和资产模块未涉及法律实体，而是应用帐簿或平衡段值。 事务处理仍然基于分类帐排序，而非基于法律实体。 如果多个法律实体共享相同的分类几属性（如：会计科目表，日历，会计方法），这些法律实体一一根据业务需要共用相同的分类帐。可以为共享同一分类帐的法律实体分配平衡段值一一推荐的，易于区分事务处理和报表。注意：共享相同分类帐的法律实体间的内部帐户要求标识公司段。 如果法律实体的4Cs或分类帐选（如：日平均额，日记帐审批或序列）不一致，则必须分离主分类帐。如果基于法律的原因需要设置多个分类帐，也可以将多个分类帐组成分类帐集以便于事务处理。在R12中，业务实体与法律实体没有直接关系。通过分类帐同时关联法律实体和业务实体来确定业务实体与法律实体的关联。注意：法律实体与业务实体间没有单独的关联关系。2.1.3. 子分类帐会计子分类帐会计(SLA)Ili息帐模块R12总帐模块2.1.3.1. R12新功能Oracle子分类帐会计(SLA)在子分类帐应用中提供了一个通用的会计引擎以代替当前的会计处理流程。SLA升级包括从从11至R12迁移当前数据以确保业务操作的连续性. 子分类帐会计的由11中各子模块的会计规则设置变更为统一在SLA进行设置，会计规则、事务处理创建会计科目的产生、标准报表等都有相应的变化。此功能有如下优点： 会计科目产生的规则，在11中的部分客户化程序解决的问题可以通过应用层的设置完成，不必再进行客户化开发。 会计科目的创建，11中基于各子模块创会计分录传送至总帐，在R12中,基于统一的SLA的共用程序创建并传送会计分录至总帐。 系统预置的SLA的设置与11相同，用户的特殊需求，可以复制体系统标准设置而进行必要的修改。 能够按照不同的会计事件自定义不同的会计科目组合，实现原先EBS无法实现会计分录个性化（如应付发票负债科目带上发票上的供应商信息） 在子模块便能生成基于单据的会计凭证信息（如一张发票一张凭证的需求）以预付款举例，实施流程如下： 以往来段为例说明SLA的优势，在原来11冲负债和预付的往来段科目需要在供应商地点单个维护，现在只需要设置SLA规则即可以自动生成。2.1.3.2. 升级考量要点H中，有部分需求是通过客户化开发实现的（应收、应付、资产等），基于R12中的SLA的新功能，11到R12的升级完成后，需要考量新功能对客户化开发的影响和取舍、适当的方案优化以及数据的融合。高级公司间系统（AGlS）会计科目生成规则需要根据SLA的功能变化而进行相应的调整。SLA的变化对标准报表、客户化表、Bl等的影响。2.1.4. 税务管理（吴伟）Il中的税，分别在应收、应付模块中设置税码，由应收、应付税务引擎在产生事务处理时进行计税。R12cfeDMtHtetfmm清晰整合税务相关的服务2.1.4.1. R12新功能R12中，统一在税务管理中完成税的相关设置，税务相关事务处理调用统一的税务引擎进行计税。税务的应用和税务信息产生的规则更加灵活。 固定的计税规则变化为由用户可配置的计税规则； 由各应用产品的单独设置变化为跨应用产品的设置； 由各组织的单独设置变化为跨组织的设置； 由多税务引擎变化为统一的税务引擎； 由多个数据存储结构变化为统一的数据存储结构R12的税务管理的主要组成： 税务配置选项和补充 税务配置管理器 税务确定处理 税报表税模拟2.1.4.2. 升级考量要点税的功能不会从11迁移至R12,在R12中税的相关设置需要补充: 基于1】中的税务需求，补充R12中的税相关设置； 测试税务相关的业务流程，如采购到付款、销售到收款等 税的相关标准报表的变化 税的相关客户化报表的调整2.1.5. 高级公司间（吴伟）2.1.5.1. R12新功能在R12中，高级公司间系统是一个新的模块（AGlS）,取代了11中的公司间系统（GIS）,其主要组成部分如下： 公司间平衡公司间事务处理 公司间开票 公司间调节2.1.5.2. 升级考量要点高级公司间管理，匹配R12的新功能功能,根据业务需求完善系统设置和新功能的应用方案。根据SLA的新功能的变化： 应用事务处理会计科目生成器定义事务处理默认帐户； 将通过SLA事务处理会计科目生成器定义的默认帐户分配至应用的分类帐。 高级公司间系统相关设置的补充 标准报表的变化 客户化报表的调整 客户化功能的调整2.1.6. 应付管理(MaOZhimin) .1.6.1.R12新功能应付模块相关的银行信息、供应商信息、应付选项、财务选项、付款等在R12中都有相应的变化，根据具体业务需求，需要完善相关设置和数据迁移和验证。银行信息:BgC>>m9Bge«wiC8JndR(WFwOXtdP*ymr4*cw»3CJB<*Chir9MftJrtCrrortdoazOKO115,C0DCO2ZT-一qtrcfioMnnCMP4yat>t<Mrk*9*QjrwncyP<mruCoodctrMac tfruln PaywMMmmjmPjiymeni财务选项:财务选项F3Potoimz/wanomFvturt P<to>o>2jMo0>cooSgIMMraMSo3,皿 7MMMOO pt<bodxcbPfHy*r<FwbrOaMPymereOscouftT.8POPMVrcOwtPORrt*VwnctlMEpmCmMrtcetvttovsRatH”1.jza.xxabl7Q侬XHCO1./MM32Ma)OX)OOSooYeC0*MAMvn*c<供应商信息:应付模块的功能变化:供应商信息在交易社区进行管理发票行的功能变化应收一应付的对冲付款的功能变化由ORACLE报表技术实现到标准的XML支付格式由多模块管理的银行帐户信息变化为统一的银行帐户管理由多模块管理的信用卡信息变化为统一在付款中管理多组织访部控制的功能应用由基于外部系统的付款管理变化为内部的付款控制 .1.6.2.升级考量要点 H中的供应商和供应商地点信息会自动在R12交易社会中创建供应商信息； 数据库中供应商信息存储的表和相关视图的变化对客户化报表的影响； R12中供应商和供应商地点的变化，对应的交易方和交易方地点的影响（供应商合并）; 供应商合并对合同管理的影响；员工供应商数据的迁移; 供应商的开放接口仍然可用； 11中的系统预置的自动付款程序和付款格式在R12中已失效，需要在R12中通过的付款设置完成； 电子支付安全性控制的功能变化对相关应用产品的影响 发票行的功能变化，数据库相关表的变化对客户化开发的影响 汇兑损益和发票价格差异的分配行的变化 发票中费用型分配行的数据迁移的变化 数据库中的费用分配表已失效 付款的功能变化对标准功能和报表的影响 客户化的单据类别不能自动升级 支付类型已失效，对所有报表的影响 自定义的付款格式须修改为XML以适用于R12 在R12中检查付款和电子支付的单据类别，需注R12中不再支持的单据类别； 应收-应付对冲功能的应用2.1.7. 总帐管理（吴伟）2.1.7.1. R12新功能总帐模块在系统设置、数据访问、事务处理等方面都有功能加强： 集中的会计科目设置 分类帐和分类帐集的应用 数据访问权限集和访问权限集的应用 替代帐户的应用2.1.7.2. 内含标准的现金流量表解决方案R12中新增了基于直接法出具的现金流量表功能，此功能:1、通过在不同的现金相关的会计单据（应付发票、应收发票、总帐凭证、银行手续费等）上标识现金流量表识，对表识的记录进行分类汇总后，出具现金流量表；2、基于系统中记录的现金流量表识，能方便地进行现金流量对帐，支持出具例外核对报表；3、出具符合国家审计署出具的（核算软件数据接口国家标准）的现金流量表（需结合XmlPublisher）。2.1.7.3. 升级考量要点 单据序列（凭证编号）在R12中的变化 报告币种设置的变更及相关测试 运行预升级诊断报表以检查总帐、多报告币种、应收、应付、资产、财务模块的相关设置 数据访问权限集的应用对于安全性控制的影响 访问权限集的应用对于安全性控制和影响和表单个性化的调整 分类帐、分类帐集的应用对会计期的管理、运行标准报表和FSG报表的安全性控制、对客户化报表的影响 替代帐户的应用对于相关需求方案的影响2.1.8. 资产管理（吴伟）2.1.8.1. R12新功能资产管理在R12中的功能改进点： 会计科目的生成完全基于SLA；成批增加功能的加强; 自动准备成批增加 自动的折旧回滚 报表的发布等2.1.8.2. 升级考量要点对固定资产类帐默认帐户的检查、调整R12可延用Il的帐簿设置，特殊的帐户生成需求可通过调置SLA实现2.1.9. 现金管理(MaOzhimin)2.1.9.1. R12新功能现金模块的新功能： 集中的银行帐户管理模式 银行帐户的传送 银行帐户余额管理等2.1.9.2. 升级考量要点 升级时，系统会自动迁移在11中定义的银行信息至R12 对于在11中在各业务实体分别定义的相同的银行帐户信息，需要考虑数据问题，以便在R12中进行银行帐户的统一管理和数据统计 银行对帐的客户化功能的迁移2.1.10. 应收管理(Maozhimin)2.1.10.1. R12新功能现金模块的新功能主要体现在：收入的管理客户信息接口表2.1.10.2. 升级考量要点 收入、未获收入的应用及报表的影响 SLA的应用对应收模块会计分录的影响 客户的功能菜单在升级中会被自动替换成R12的功能客户信息在升级中不会受到影响2.1.11. 项目会计（吴伟）2.1.11.1. R12新功能2.1.112升级考量要点2.1.12. 采购管理（分销顾问）2.1.12.1. R12新功能采购模块的新功能主要体现在：采购协议的功能变化税务管理的功能变化对采购模块的体现2.1.12.2. 升级考量要点采购协议的数据迁移税务管理的功能变化对采购模块的影响2.1.13. 库存管理（分销顾问）2.1.13.1. R12新功能库存模块的新功能主要体现在： ORACLE库存模块取代了OPM库存管理，R12中，ORACLE库存模块同时支持流程制造和离散制造的库存管理（包括OPM特殊的业务功能，如双计量单位等）： 销售成本的确认； 挑库存规则功能的加强； 库存保留功能的改进；2.1.13.2. 升级考量要点 OPM库存管理的功能变化对OPM业务的影响； 销售成本的确认的功能变化的应用 挑库规则的应用 库存保留功能的应用2.1.14. 人力资源管理（JaCky）2.1.14.1. R12新功能订单管理模块的新功能主要体现在：部分系统配置文件选项的变化订单管理模块的部分默认规则的失效2.1.14.2. 升级考量要点 系统升级数据迁移对配置文件选项的影响 订单管理模块的部分默认规则的失效的影响 库存模块挑库规则的功能变化对订单发运的的影响3.2技术方案（苟林/孙洪祥）3.2.1. 系统升级方案3.2.1.1. 背景目前伊利集团使用的OraCleEBS版本为11.5.10.2,OraCleEBS使用的数据库版本Iog。使用的EBS生产服务器操作系统为AIXo在目前的情况下，伊利集团希望升级OraCleERP到最新的OracleEBSR12。以更好更方便的实现各种功能。4.2.1. 2.前提为确保升级项目能够顺利开展和进行，有一些前提条件必须满足。 配备有测试机，磁盘空间可以做2-3套测试环境 测试机的操作系统应该与将来要上线的正式环境的正式机的操作系统保持一致 如果需要测试与别的系统的接口，外围系统同样需准备测试环境 现有系统数据库做了RAC为了将来的正式环境能够实现同样的功能，需要保证一定的硬件资源进行RAC的测试工作4.2.1. 3.要求的范围和目标根据前期的调查情况，本升级项目的范围如下：OraeleEBS系统升级,从OraeleEBS0.5.10.2升级到oraCIeEBSRI2.1.3,由于R12的要求其中包括数据库的升级，另外如果需要还有操作系统的升级。系统升级 将OracleApplications由Rl1.5.10.2升级到R12.1.3 将数据库由版本IOg升级到1lgR2 需要实施方提供相关文档根据我们团队在其他客户那里丰富的升级经验，我们觉得企业在升级OracleEBS的项目中的难点和重点有：（一）客户化开发的部署与修改由于从Rl1.5.10.2升级到R12,标准对象变更很大，可能会导致很多的客户化开发对象无效。这样就会导致大量的客户化开发对象的修改，这项工作内容非常难以在事先估计清楚。所以，基于旧版本OracleEBS的客户化的开发的是否规范与文档是否齐全，对此升级项目是非常重要的。（二）测试的全面性与准确性对于升级与升级项目来说，测试的全面性与准确性是具有决定意义的。这里测试包括标准功能的测试和客户化开发的测试，如果上面一项里关于客户化开发的相关文档不够齐全和完备的话，测试的全面性和准确性就显得尤其重要了，甚至关系到项目的成功与否。所以测试的全面性与准确性是项目中的一个重点。（三）历史数据的影响在升级过程中，需要打一系列的PatCh,这些PatCh可能会对历史数据有些处理操作，如果历史数据有异常，可能会在Pateh过程中出错，对于这些错误的处理，有时是比较复杂的。4.2.1.4. 升级技术方案目前，对于OraCleEBS的升级OraCle提供的标准方法是通过OraCIe标准的官方文档UpgradeGuide:Release11toRelease12.1.1里的方法具体实现的。对于OraCleR12,可以从OradeReIeaSell直接升级上来，所以对于深交所的版本升级，可以直接升级到R12,这里我们先升级到R12中的初始版本R12.1.1,然后再安装RUP包升级到最新版本R12.1.3概括的讲，我们的升级方案是这样的：1 .先安装R12.1.1环境的一套代码，然后在此机器上通过打12.1.1MaintenancePack的补丁实现数据库的数据升级到12.1.1,然后用安装的R12.1.1的应用代码连接此数据库，实现整个EBS系统升级到R12.I.1,紧接着应用最新的R12.1.3补丁包和后续系列补丁.2 .先安装一套DalabaSe1lgR2并配置好RAC环境，通过DBUA完成EBS数据库的版本升级,并进行应用和数据库的RAC转换，实现整个EBS系统升级到Rl20通过上面的2个升级步骤,实现OracleEBS从Rl1.5.10.2到R12的升级。4.2.1. 5.技术方案概览根据Oracle的技术方案以及我们实施过的成功案例，我们推荐下面的升级方案：应用从R1L5.10.1到R12.1.3步骤号内容预先步骤1用Rapidinstall安装R12.1.1代码Pre-Update步骤2判定需要的升级前步骤3执行升级前的各项工作，包括前补丁与各模块业务准备OPM模块的历史数据需要预处理参照OPMRelease12Migration(DocID:376683.1)应用升级步骤14执行adpatch升级EBS的版本到12.1.15应用系统中间件升级和代码合并应用升级步骤26执行adpatch升级EBS的版本到12.1.3Post-Update步骤7执行升级后的各项工作，启动环境数据库从IOg升级到Ilg,并进行RAC转换步骤号内容预先步骤8安装并配置RAC环境Pre-Update步骤9判定并执行需要的升级前步骤数据库升级步骤10升级数据库RDBMS的版本到IIgRAC转换步骤11数据文件转换到ASM中12AdCOnfig配置，系统运行参数修改Post-Update步骤13实现已升级完成的R12应用代码和RAC数据库的合并14执行升级后的各项工作，启动环境4.2.1. 6.技术方案阐述下面将针对技术方案概览的关键点进行较详细的说明：步骤1：Rapidinstall-安装12.1.1代码操作目的：安装出一套R12.1.1的代码操作方法：根据环境配置（如文件系统位置、TCP/IP端口等）安装新的12.1.1的代码，安装完成后通过备份或移走的方式，将其暂时保存。Rapidinstall的代码包括： ISIDJappl->OracleEBS产品文件（如Form,Report文件） SIDora->OracleEBS应用层technologystack（如formserver,reportserver,iAS等） lSIDcomn->OracleEBScommon文件（如一些java文件和脚本文件）步骤2：判定需要的升级前步骤操作的目的是判断升级技术步骤。OraeIe提供了一个脚本运行后输出的tums.html可以供用户判断哪些升级操作是需要做的，哪些操作是不需要做的。对后面的升级操作具有基本的指导意义。步骤3：执行升级前的各项工作，包括前补丁与各模块业务准备此步骤是根据tums.html的结果，执行升级前的各项必须的准备工作，其中有一些是需要打一些先补丁，也有一些是业务上的准备。这其中包含很多的内容，根据伊利集团的实际情况，我们只选取了系统共通部分与财务部分，具体包括 SystemAdministrationTasks ApplicationObjectLibraryTasks OracleFlexBuilderZAccountGeneratorTasks OracleAlertTasks OracleWorkflowTasks OracleCashManagementTasks OraclePayablesTasks OracleReceivablesTasks OracleFinanciaIsforLatinAmericaTasks OracleGeneralLedgerTasks GlobalAccountingEngineTasks OracleiPaymentTasks OracleFinanciaIsforAsia/PacificTasks OracleFinanciaIsCommonCountryTasks这上面的准备工作有些根据tums.html的结果和实际业务情况，是不用做的。下面举两个例子，说明升级前大概都有哪些工作需要做：OraclePayables1：导入所有接口表数据2:确认/取消所有未完成的批ProcessManufacturing参考文档OPMRelease12Migration(DocID:376683.1)。1:预处理OPM的基础数据（库存组织和物料的调整）2:对未完成的批进行快照记录，升级完成后重建这些批3:处理所有未结业务（完成或取消），并记录，升级完后继续处理步骤4：升级ADPATCH升级EBS的版本到12.L1升级ORACLEERP数据库内的数据从Rl1.5.10.2到R12.1.1的版本升级。经过此步骤后OraCIeEBS内部的数据结构已经完全升级到R12.1.1。步骤5：应用系统中间件升级和代码合并升级ORACLEERP应用的中间件到所需的版本，并进行R12.1.1应用系统和IOg数据库的代码合并，启动应用系统，进行简单的集成测试和升级确认。步骤6：执行ADPATCH升级EBS的版本到12.1.3升级ORACLEERP数据库内的数据从R12.1.1至R12.1.3的版本升级。经过此步骤后OradeEBS应用层已经完全升级到R12.1.3。步骤7：执行升级后的各项工作，启动环境升级后的工作主要包括在线帮助，环境配置，启动，基本检查等等。然后就可以开放供测试使用。步骤8：安装并配置RAC代码操作目的：安装并配置出一套可用的Ilg数据库的RAC代码操作方法：根据环境配置（如文件系统位置、TCPzlP端口等）安装并配置新的IIgRAC的代码，步骤如判定需要的升级前步骤操作的目的是判断升级技术步骤。OraCIe提供了一个脚本运行后输出的tums.html可以供用户判断哪些升级操作是需要做的，哪些操作是不需要做的。对后面的升级操作具有基本的指导意义。此步骤是根据tums.html的结果，执行升级前的各项必须的准备工作，其中有一些是需要打一些先补丁，也有一些是业务上的准备。这其中包含很多的内容，根据伊利集团的实际情况，我们只选取了系统共通部分与财务部分，具体包括 SystemAdministrationTasks ApplicationObjectLibraryTasks OracleAlertTasks OracleGeneralLedgerTasks OracleiPaymentTasks OracleInternetExpensesTasks OraclePayablesTasks OracleSubledgerAccountingTasks这上面的准备工作有些根据tums.html的结果和实际业务情况，是不用做的。步骤10：升级数据库RDBMS的版本到IIg安装一套新的Ug数据库代码，并通过DBUA来完成数据库升级操作。步骤11:RAC转换步骤-数据文件转换到ASM中将所有文件系统下的数据文件通过RMAN转换到ASM中。步骤12：RAC转换步骤-adconfig配置，参数修改该步骤安装并配置数据库的adconfig工具。经过此步骤后OracleEBS数据库层可通过一些简单的工具/命令进行日常维护，这些工具亦可配合EBS的应用系统，进行系统层的管理维护。步骤13：实现已升级完成的R12应用代码和RAC数据库的合并此时实现R12.1.3代码和已经升级过的RAC数据库层结合在一起。实现数据库层的系统升级，这样使整个OraICeEBS系统升级到RI2步骤14：执行升级后的各项工作，启动环境升级后的工作主要包括在线帮助