查看类型的定义。 您会看到与InfoObjects zcustpar和zcustparg相关的字段名称不仅是zcustpr和zcustparg。 它们的前缀是您错过的前缀。

您还可以在表/BIC/PZCUSTPAR和/BIC/ZCUSTPARG中看到正确的名称。

请使用代码 粘贴代码时，在编辑器中单击按钮。 它使读取起来非常容易-特别是如果您花时间对其进行格式化-例如，使用内置的漂亮打印机。
请注意，每行一个abap语句。

您 应该如下定义您的表IT_/BI0/PCUSTOMER：

 DATA it_/bi0/pcustomer类型散列表/bi0/pcustomer
      

然后使用TABLE KEY将READ更改为READ ...，这要快得多。

您的SORT不会使您的程序运行更快。

此外，您还应该在选择中包含OBJVERS EQ'A'子句，否则您也会选择不活动的值

从/BI0/PCUSTOMER中选择客户/BIC/ZCUSTPAR/BIC/ZCUSTPARG
        进入表IT_/BI0/PCUSTOMER
        适用于RESULT_PACKAGE中的所有条目
        客户= Result_package-customer
          AND objvers ='A'。
 在Result_package ASSIGNING 处循环。
   将表IT_/BI0/PCUSTOMER读入wa_/BI0/PCUSTOMER
         使用表键Customer = wa_/BI0/PCUSTOMER-customer。
   如果sy-subrc = 0。
     如果 -zcustpar =''。
         -zcustpar = wa_/BIO/PCUSTOMER-客户。
     万一。
     <结果字段> -zcustparg = <结果字段> -zcustpar。
   万一。
   
   如果 -customer + 7（3）='_IN'并且 -zcustpar =''。
     <结果字段> -zcustpar = <结果字段> -customer + 0（7）。
   万一。

   如果 -customer + 7（3）='_IN'并且 -zcustparg =''。
      <结果字段> -zcustparg = <结果字段> -zcustpar。
   万一。
 结束循环。
 
 

首先，检查result_field结构是否存在（查看结构_ty_s_TG_1）。

第二，检查例程的映射（如果这些字段位于 移出目标字段。

第三，我不明白为什么您需要例行程序。 您正在阅读客户主数据，以根据可靠的客户编号更新其自己的属性，那么为什么不创建公式规则来从源客户编号确定属性值呢？

发现得好！

嗨，马修，

当有大量记录要读入内部表并进一步处理时，我仅使用哈希表。

排序表将比标准表花费更多的时间，而对标准表进行排序不会花费太多时间。

无论如何，他编写了没有BINARY SEARCH的READ表语句，并且在READ语句之前使用了SORT语句，因此为了使读取速度更快并更新正确的客户，我进行了更改以添加 二进制搜索。

@ Vignesh，

您可以检查代码运行时间并选择最佳解决方案。

问候，

Satya。

如果要从哈希表中读取数据，则应始终使用它们（如果您确实没有唯一的密钥，则排序）。 您担心开销。 事实是，只有在要运行很多次的循环中构造HASHED表时，开销才成为问题。

在这里情况并非如此。 在我从事ABAP编程的22年中，我从未遇到过这种情况。

作为ABAP编程的一般原则，如果使用HASHED表作为首选项，然后根据需要使用SORTED并最终使用STANDARD，则不会遇到性能问题。 如果这样做，那么您随时可以调整代码。

您找他对表进行排序的借口很弱。 如果您建议使用SORTED表，那么我会更接受您编写的内容，但是您正在积极提倡一种旧的编程方式，我认为这很糟糕。 永远不需要SORT/BINARY搜索。 使用排序表并输入21世纪。

哦，您应该阅读有关答案的文字。 "在回答之前 您只能在提出海报者问题的解决方案时提交答案。"您应该使用注释。