I处理业务伙伴地址问题.docVIP

业务伙伴姓名地址问题 目录： 1. 需求和问题描述 1 问题简述 2 问题详细描述： 2 2. 需求分析和问题根源分析 4 重现问题 5 问题原因解释： 9 3. 实现方案分析 9 须用户回答：用户希望的业务解决方案 9 须用户回答：现有需求和过去的需求相互冲突，如何处理？ 11 4. 代码和开发实现 12 5. 单元测试 14 6. 用户测试 14 7. 知识转移和重要提示 14 需求和问题描述 [需求和问题描述环节，主要由用户提供主要内容，一定要使用图片来帮助清楚的描述用户的需求或者问题，图片需要使用圆圈标注关键的错误的地方。 用户的操作过程（涉及到的T-code和操作界面） 至少提供一笔的例子数据； 出现问题的时候，错误的数据的样子 希望达到的正确的效果是什么样子 本环节一定要用户清楚、无误的、具体的、充分的表达问题和需求。过于笼统的需求和问题表达，对后续的处理都会带来障碍。] 例子： 用户最初提到： 以上信息是非常不完整的，没有提到任何的具体问题。 我们需要用户进一步详细到： 提供问题简述和问题的详细描述。 问题简述： 通过Stering的中间件把网站的信息通过IDOC方式传递给SAP生成销售订单时，销售订单的业务合作伙伴上的NAME和 Street的信息有错误。 （不知后面的邮政编码和区域是否也有错误？） 问题详细描述： 通过T-code WE19导入Idoc 3300291 2.IDOC的数据状态 3 通过调用Inbound function module处理：IDOC_INPUT_ORDERS 4. 得到的结果销售订单：（ T-code：VA03，输入销售订单，然后转到的Partner界面） 5. 客户本身希望的样子。 其实上图的说明有问题的。只是Name不对么？Street和Post code等呢？ 需求分析和问题根源分析 [需求分析和问题根源分析环节，这个环节主要有顾问负责，无需用户参与，本环节的最佳实践包括; 利用用户所提供的数据，重现用户的错误。如果问题无法重现，表示偶尔性的操作问题。 利用另外的数据来重新错误，如果另外的数据操作没有问题，表示是数据问题。一般无需修改ＳＡＰ的程序代码。 利用程序的 Debug功能，一步步的调试，以便于了解程序的内部处理过程和特殊的内部处理过程] 重现问题： 利用Idoc: 3300291,使用WE19重新产生销售订单，出现Idoc处理错误。无法产生销售订单。 更换另外一个IDOC: 3294554 在处理3294554之前的销售订单：查看今天的销售订单数据： WE19处理： IDOC: 3294554 SE11查询订单： 进过对比分析分析，知道订单100107152是这次产生的。 查看订单： 修改Idoc的数据： 再次产生销售订单： 弹出了这个一个错误： 这表示Idoc 的处理是利用SAP的标准的BDC接口在做的。 从以上错误界面可以看出：SAP本身从客户主数据得到地址信息，我们观察对比其他几行的数据就可以看到。 校正以上问题：把邮政代码修改为6位数，重新开始。 得到的销售订单： 从以上分析，了解问题的所在： 问题原因解释： 整个程序本身看起来运行合理，主要是因为IDOC的结构中，没有维护或者维护的客户的地址信息不对。Idoc的处理是按照IDOC的信息来修改销售订单的。要解决这个问题：有两个方案： 从第三方的软件得到的 Idoc的消息，正确维护这些地址信息即可。（此方案无需编程修改。） 完全忽略Idoc所带过来的地址信息。只依照客户编号，其他的信息采用SAP的主数据而定。 中间状态：如果Idoc维护了某些地址信息，就依照Idoc更新维护部分地址，否则采用SAP ERP的主数据而定。（该方案，也会继续造成， 给用户的感觉，SAP ERP维护的地址信息，并不一定和IDOC产生的一致。） 实现方案分析 [实现方案分析环节，这个环节首先要让用户在问题原因解析环节，所提出的业务和开发的综合解决方案中，进行选择。因为有些问题是可以通过数据维护，操作方面来解决问题，有些问题的解决方案会相对完美，但是开发工作量较大。] 须用户回答：用户希望的业务解决方案 目前假设用户希望采用方案2： 完全忽略Idoc所带过来的地址信息。只依照客户编号，其他的信息采用SAP的主数据而定。 该方案的实现可以考虑以下两种方式： 在IDOC处理后的退出增项程序中，通过读取客户主数据的地址信息，重新修改相关的表； 在订单的保存的增强代码中，通过读取客户主数据的地址信息，重新修改相关的表； 先看IDOC处理后的退出增项程序: 通过 CMOD看增强程序： 从以上代码来看，目的就是为了实现：使用 IDOC的中所带过来的 Name Nam