Idoc处理业务伙伴姓名地址问题Word文档格式.docx
《Idoc处理业务伙伴姓名地址问题Word文档格式.docx》由会员分享，可在线阅读，更多相关《Idoc处理业务伙伴姓名地址问题Word文档格式.docx（15页珍藏版）》请在冰点文库上搜索。
用户最初提到：
以上信息是非常不完整的，没有提到任何的具体问题。
我们需要用户进一步详细到：
提供问题简述和问题的详细描述。
问题简述：
通过Stering的中间件把网站的信息通过IDOC方式传递给SAP生成销售订单时，销售订单的业务合作伙伴上的NAME和Street的信息有错误。
（不知后面的邮政编码和区域是否也有错误？
）
问题详细描述：
1.通过T-codeWE19导入Idoc3300291
2.IDOC的数据状态
3通过调用Inboundfunctionmodule处理：
IDOC_INPUT_ORDERS
4.得到的结果销售订单：
（T-code：
VA03，输入销售订单，然后转到的Partner界面）
5.客户本身希望的样子。
其实上图的说明有问题的。
只是Name不对么？
Street和Postcode等呢？
2.需求分析和问题根源分析
[需求分析和问题根源分析环节，这个环节主要有顾问负责，无需用户参与，本环节的最佳实践包括;
1.利用用户所提供的数据，重现用户的错误。
如果问题无法重现，表示偶尔性的操作问题。
2.利用另外的数据来重新错误，如果另外的数据操作没有问题，表示是数据问题。
一般无需修改ＳＡＰ的程序代码。
3.利用程序的Debug功能，一步步的调试，以便于了解程序的内部处理过程和特殊的内部处理过程]
重现问题：
利用Idoc:
3300291,使用WE19重新产生销售订单，出现Idoc处理错误。
无法产生销售订单。
更换另外一个IDOC:
3294554
在处理3294554之前的销售订单：
查看今天的销售订单数据：
WE19处理：
IDOC:
SE11查询订单：
进过对比分析分析，知道订单100107152是这次产生的。
查看订单：
修改Idoc的数据：
再次产生销售订单：
弹出了这个一个错误：
这表示Idoc的处理是利用SAP的标准的BDC接口在做的。
从以上错误界面可以看出：
SAP本身从客户主数据得到地址信息，我们观察对比其他几行的数据就可以看到。
校正以上问题：
把邮政代码修改为6位数，重新开始。
得到的销售订单：
从以上分析，了解问题的所在：
问题原因解释：
整个程序本身看起来运行合理，主要是因为IDOC的结构中，没有维护或者维护的客户的地址信息不对。
Idoc的处理是按照IDOC的信息来修改销售订单的。
要解决这个问题：
有两个方案：
1.从第三方的软件得到的Idoc的消息，正确维护这些地址信息即可。
（此方案无需编程修改。
2.完全忽略Idoc所带过来的地址信息。
只依照客户编号，其他的信息采用SAP的主数据而定。
3.中间状态：
如果Idoc维护了某些地址信息，就依照Idoc更新维护部分地址，否则采用SAPERP的主数据而定。
（该方案，也会继续造成，给用户的感觉，SAPERP维护的地址信息，并不一定和IDOC产生的一致。
3.实现方案分析
[实现方案分析环节，这个环节首先要让用户在问题原因解析环节，所提出的业务和开发的综合解决方案中，进行选择。
因为有些问题是可以通过数据维护，操作方面来解决问题，有些问题的解决方案会相对完美，但是开发工作量较大。
须用户回答：
用户希望的业务解决方案
目前假设用户希望采用方案2：
完全忽略Idoc所带过来的地址信息。
该方案的实现可以考虑以下两种方式：
1.在IDOC处理后的退出增项程序中，通过读取客户主数据的地址信息，重新修改相关的表；
2.在订单的保存的增强代码中，通过读取客户主数据的地址信息，重新修改相关的表；
先看IDOC处理后的退出增项程序:
通过CMOD看增强程序：
从以上代码来看，目的就是为了实现：
使用IDOC的中所带过来的
Name
Name_2
Name_3
Name_4
Street
Str_supp11
House_no
来更新adrc地址表。
现有需求和过去的需求相互冲突，如何处理？
这表示，如果Idoc为某个客户维护了地址信息，这些地址信息将更新到SAPERP的客户主数据中去，以后SAPERP对该客户主数据的地址信息将一直采用Idoc更新后的新地址。
该段代码是原来的代码由开发人员专门写的。
这意味着这代表以前的某个需求驱动的。
现在的需求和以前的代码的需求是有冲突的。
如果用户不希望由IDOC中的地址信息来更新用户的主数据的地址信息，只需要把上述代码注释掉即可：
如果用户不希望由Idoc的新地址，还是使用SAP主数据地址信息的话，最简单的方法是，有Stering那边传递过来的IDOC不要传递过来任何地址信息即可。
就会自动的使用SAPERP的客户主数据地址。
这是最简单的处理方法。
这个方式最优的。
上图中，不要维护Name1到City的任何信息。
自然就会使用SAPERP的客户主数据信息。
也就是说，Stering那边不要传输地址信息给Idoc即可。
如果要传输的话，要保证正确。
4.代码和开发实现
[代码实现环节，这个环节用户顾问记录自己的变更，最佳实践包括：
1.如果对老代码进行修改，最好可以在这里依照文件附件的形式，把原有的代码做一个备份。
并说明修改后的代码的样子。
2.修改好的代码，所产生的请求号，也记录在此。
1.如果用户希望通过Stering传输客户地址信息，并更新SAPERP的客户主数据。
保持现状。
无需任何修改。
给用户讲述系统的业务逻辑。
（本文档的前面几个章节本身可以作为用户自行阅读逻辑的内容）
2.如果用户不希望通过Stering传输客户地址信息，并更新SAPERP的客户主数据。
把：
增强
的如下代码注释掉即可：
（注释掉49行到80行）
3.如果用户希望在订单中采用SAPERP的主数据地址，还不是IDOC中的地址，只需要IDOC中的针对那些地址字段，不要传输数据过来即可。
无需编程修改。
5.单元测试
[单元测试环节，这个环节说明，当代码实现了，我们自行挑选1-2笔测试数据进行完整的测试，并展示结果。
这个环节对于顾问的好处是：
提交给用户之前，我们的代码是经过充分的测试的。
这可以确保提交给用户时，不会有简单和低级，并可能引起客户抱怨的问题出现]
本问题，要基于用户的希望来决定单元测试和代码实现。
6.用户测试
[用户测试环节，这个环节说明，用户已经经过用户测试，把用户测试的反馈邮件抓图再次即可。
本问题，要基于用户的希望来决定什么样的代码修改。
7.知识转移和重要提示
[知识转移环节，这个环节说明，如果复杂的场景或者配置，可以给用户编写培训文档，或者解决方案中有什么特殊注意事项和告知，也再此说明。
比如有些程序的性能优化，是通过在一些大的表上建立格外的Index而提升性能，那么请再次说明，该方案可能对业务数据录入处理的保存会有负面的影响]
无。
升级会员 