物料事务处理接口错误处理日志-例2

客户:达芙妮

现象:1 并发节点文件系统满,导致并发管理器挂起

             2用户删除了部分日志和输出文件,并重新启动管理器,所有管理器都正常启动,只有库存管理器actual=0, target=10

分析&解决 

一、灏明(Oracle) 10日去现场看了下,发现后台库存管理器进程状态为defunct,mtl_tranasctions_interface中有大量待处理数据(从出故障到现在的所有库存事物处理),并采取了一次处理少量数据来解决问题,下面是他的脚本

——————————————–

继续阅读“物料事务处理接口错误处理日志-例2”

接收事务处理接口错误处理日志1例

/*******************************************************************************
date : 2007-05-08
处理者: yunfang.shang
*******************************************************************************/

select * from rcv_transactions_interface
–查接收接口中来自销售订单退货的记录(error_message是错误信息提示)
SELECT rti.processing_request_id,
       rti.creation_date,
       rti.transaction_date,
       rti.group_id,
       oeh.order_number,
       rti.item_id,
       item_description,
       rti.unit_of_measure,
       rti.quantity,
       rti.source_document_code,
       rti.subinventory,
       oel.flow_status_code,
       pie.error_message
  FROM rcv_transactions_interface rti,
       oe_order_headers_all       oeh,
       oe_order_lines_all         oel,
       PO_INTERFACE_ERRORS        pie
 WHERE rti.oe_order_header_id = oeh.header_id
   AND rti.oe_order_line_id = oel.line_id
   AND rti.oe_order_header_id = oel.header_id
   AND rti.interface_transaction_id = pie.interface_line_id(+)
 ORDER BY oeh.order_number
—       
继续阅读“接收事务处理接口错误处理日志1例”

物料事务处理接口日志一例

物料事务处理接口日志一例

/*******************************************************************************
date : 2007-05-06
处理者: yunfang.shang
*******************************************************************************/
现象:库存事务处理接口中堆积了大量记录未被处理
现象:接口表中很多记录处理结果为Error;原因是组织层不允许负库存,而库存现有量不足,导致无法扣减库存成功
      大量出库记录由此被堵塞在接口表。
处理日志:
 select count(*) from MTL_TRANSACTIONS_INTERFACE
 select count(*) from Mtl_Material_Transactions_Temp
 
 –事务处理数量
 SELECT
   — *
   –transaction_quantity
   –distinct transaction_source_type_id
   FROM MTL_TRANSACTIONS_INTERFACE
  WHERE transaction_interface_id = 321706
    AND error_code IS NOT NULL
   
 SELECT *
   –transaction_quantity
   FROM Mtl_Material_Transactions_Temp where trx_source_line_id =22964
  
 –保留
 select * from mtl_demand_v a where a.demand_id =  22964
   
 –现有量
 SELECT sum(transaction_quantity)
   FROM mtl_onhand_quantities moq
  WHERE moq.INVENTORY_ITEM_ID = 3489
    AND moq.ORGANIZATION_ID =108
    AND moq.SUBINVENTORY_CODE =111215001
    –物料编码
    SELECT segment1
      FROM mtl_system_items_b
     WHERE organization_id = 108
       AND inventory_item_id = 3489
      
 — 查找错误记录的现有量
 SELECT a.transaction_interface_id,
       msi.segment1,
       a.organization_id,
       a.subinventory_code,
       a.transaction_quantity,
       XH_COMMON_UTL.get_onhand_qty(a.inventory_item_id,
                                    a.organization_id,
                                    a.subinventory_code) on_hand_qty
  FROM mtl_transactions_interface a,
       mtl_system_items_b msi
 WHERE a.inventory_item_id = msi.inventory_item_id
 and   a.organization_id = msi.organization_id
 and   a.error_explanation IS NOT NULL  

继续阅读“物料事务处理接口日志一例”

DATAFIX_OM行流批量Retry

/*******************************************************************************
date : 2007-07-06
处理者: yunfang.shang
*******************************************************************************/

/*
现象: 现在有几张订单传到库存了之后传不到应收接口了
订单号:1000002895
*/

select * from oe_order_headers_all  where order_number = ‘1000002895’

— 查订单的 POS小票号
select oel.attribute2
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oeh. order_number = ‘1000002895’

–查发票接口
select  * from  RA_INTERFACE_LINES_ALL  where attribute2 in (select oel.attribute2
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oeh. order_number = ‘1000002895’)
–返回 0 条记录,说明已经全部被处理
–查发票行
select  * from  RA_CUSTOMER_TRX_LINES_ALL  where attribute2 in  (select oel.attribute2
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oeh. order_number = ‘1000002895’)
–返回 0条记录
–说明根本就没有生成到AR接口表中

–查订单行的开票状态字段
select oel.INVOICE_INTERFACE_STATUS_CODE,oel.*,oel.lock_control
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oeh. order_number = ‘1000002895’
— INVOICE_INTERFACE_STATUS_CODE是空的 NULL, 正常情况下开票完成的应该是 YES

–从界面查该订单,订单头 已登记 状态;订单行 实施 状态。 从菜单 工具/工作流状态 看到
— 开票接口出现例外。 看错误信息是表空间扩展问题。

–查数据库日志,表空间不足。 DBA扩展表空间后。
— 客户方 IT 人员 在出错的订单行界面按右键 选择 重试出错的活动。就 retry 过去了。

–但是这种记录很多,有700多条,如果手工retry的话,工作量很大。用户希望能用程序retry.

–首先找出这些记录
select count(1) from
(
select oeh.order_number,oel.INVOICE_INTERFACE_STATUS_CODE,oel.*,oel.lock_control
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oel.INVOICE_INTERFACE_STATUS_CODE is null and oel.attribute2 is not null and line_category_code =’ORDER’
and oel.flow_status_code =’FULFILLED’
)
–707 条

— 获取其中一条的 activity , item_key 就是line_id

SELECT was.item_type,
       was.item_key,
       wpa.process_name || ‘:’ || wpa.instance_label activity,
       was.activity_status,
       was.activity_result_code,
       was.assigned_user,
       was.notification_id,
       was.begin_date,
       pro.display_name process_name,
       act.display_name activity_name
  FROM wf_item_activity_statuses was,
       wf_process_activities     wpa,
       wf_activities_vl          pro,
       wf_activities_vl          act,
       wf_items                  wi
 WHERE was.process_activity = wpa.instance_id
   AND wpa.process_item_type = pro.item_type
   AND wpa.process_name = pro.NAME
   AND wpa.process_version = pro.version
   AND wpa.activity_item_type = act.item_type
   AND wpa.activity_name = act.NAME
   AND was.item_type = wi.item_type
   AND was.item_key = wi.item_key
   AND wi.begin_date >= act.begin_date
   AND wi.begin_date < nvl(act.end_date, wi.begin_date + 1) 
   AND was.item_type = ‘OEOL’
   AND was.item_key = ‘106458’
   AND was.end_date IS NULL
   AND was.activity_status =’ERROR’ ;

— 执行retry  比如单个记录的retry :

BEGIN

  — 初始化,根据实际环境修改,这样可以获得环境变量,主要是Org_id,一般不需要
  fnd_global.apps_initialize(user_id      => 1111,
                             resp_id      => 50260,
                             resp_appl_id => 660);
  — Call the procedure
  wf_engine.handleerror(itemtype => ‘OEOL’,
                        itemkey  => ‘106457’,
                        activity => ‘LINE_DEF_INVOICE_INTERFACE_SUB:INVOICE_INTERFACE’,
                        command  => wf_engine.eng_retry);
END;

–成功执行,再去界面看,行已经Close了。
/********************************************************************************
— 批量Retry 执行 这些出错的节点:
********************************************************************************/

begin
    — 注意把当前Sql窗口中的 “输出” tab页中的缓冲区大小设置大一点,至少 100000
    — 初始化
    fnd_global.apps_initialize(user_id => 1111, resp_id => 50260,
                               resp_appl_id => 660);

    for c1 in (select oel.line_id
               from oe_order_lines_all oel
               where oel.INVOICE_INTERFACE_STATUS_CODE is null
               and oel.attribute2 is not null
               and line_category_code = ‘ORDER’
               and oel.flow_status_code = ‘FULFILLED’) loop
   
        for c2 in (SELECT was.item_type, was.item_key,
                          wpa.process_name || ‘:’ || wpa.instance_label activity,
                          was.activity_status, was.activity_result_code,
                          was.assigned_user, was.notification_id,
                          was.begin_date, pro.display_name process_name,
                          act.display_name activity_name
                   FROM wf_item_activity_statuses was,
                        wf_process_activities wpa, wf_activities_vl pro,
                        wf_activities_vl act, wf_items wi
                   WHERE was.process_activity = wpa.instance_id
                   AND wpa.process_item_type = pro.item_type
                   AND wpa.process_name = pro.NAME
                   AND wpa.process_version = pro.version
                   AND wpa.activity_item_type = act.item_type
                   AND wpa.activity_name = act.NAME
                   AND was.item_type = wi.item_type
                   AND was.item_key = wi.item_key
                   AND wi.begin_date >= act.begin_date
                   AND wi.begin_date < nvl(act.end_date, wi.begin_date + 1)
                   AND was.item_type = ‘OEOL’
                   AND was.item_key = c1.line_id
                   AND was.end_date IS NULL
                   AND was.activity_status = ‘ERROR’) loop
       
            — Call the procedure
                   
             wf_engine.handleerror(itemtype => ‘OEOL’, itemkey => c1.line_id,
                                  activity => c2.activity,
                                  command => wf_engine.eng_retry);
                                 
            dbms_output.put_line(‘c.line_id=’ || to_char(c1.line_id) || ‘     c2.activity=’ || c2.activity || ‘   be   processed’ );
            exit ;
        end loop;   
    end loop;
    –commit;
end;

/********************************************************************************
— 成功执行完毕后检查
********************************************************************************/

–再次检查
select oeh.order_number,oel.INVOICE_INTERFACE_STATUS_CODE,oel.*,oel.lock_control
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oel.INVOICE_INTERFACE_STATUS_CODE is null and oel.attribute2 is not null and line_category_code =’ORDER’
and oel.flow_status_code =’FULFILLED’

— 返回0条记录。 说明全部被处理了。

— 自动开票程序运行后 再运行
— 下面这句话可以证明 程序处理过的订单行均已开票成功
select b.order_number, b.line_id, a.*
       from RA_CUSTOMER_TRX_LINES_ALL a,
            (select oeh.order_number, oel.INVOICE_INTERFACE_STATUS_CODE,
                     oel.line_id, oel.lock_control
              from oe_order_lines_all oel, oe_order_headers_all oeh
              where oeh.header_id = oel.header_id
              and oel.last_update_date between
                    to_date(‘2007-7-6 23:24:00’, ‘YYYY-MM-DD HH24:MI:SS’) and
                    to_date(‘2007-7-6 23:27:00’, ‘YYYY-MM-DD HH24:MI:SS’)) b
       where a.interface_line_attribute6 = to_char(b.line_id)
      
— 被处理的订单行是706条。对应的发票行也是706条。全部开票成功。

DATAFIX_AR反过帐的问题

/***********************************************************************************************************
概述:

问题: AR 会计分录传到总帐接口以后,用户在总帐中,没有导入这批日记帐之前,利用删除接口的程序把接口中的某一批数据给删除了。
       导致一批凭证丢失。
       
当时场景是这样的:
       1)客户的财务人员提交AR的过账程序,确实勾选了运行日记帐导入。
       但是由于某些原因导致:AR传总帐接口这一步是正常完成了。但是日记帐导入这一步没有正常完成。
       2)客户看到并发请求列表中有个红色的出错请求,就以为整个AR过账过程都错了,当然在总帐也没有查到相关日记帐。
       于是就再次运行AR过账程序,但是因为原来的数据已经被打上“已过账”标记,所以是过不去了。
       3)客户就以为是接口表中有错误数据所以导致不能再过账的(她的这个想法当然是错误的,但当时她确实就是这么以为的)
       于是她就删除接口的程序把接口中的某一批数据给删除了。
       4)这下可就完蛋了。接口中也没数据了,系统又不能再过账。到了这一步,客户就无能为力了。
       
***********************************************************************************************************/

怎么办? 

/***********************************************************************************************************
 1    根据用户 提交的  删除日记帐导入来源  的请求 来知道用户删除了哪一批数据
 ***********************************************************************************************************/

— 运行 总帐的 删除 接口程序 输入参数 request_id ,group_id 
— 如果不输入group_id  则,group_id 会被默认设置为-1 ,也就无法删除

— 并发请求 名称 = 删除日记帐导入来源   
— 并发请求ID = 550089
— 请求完成后查 接口表 

— 查德当时的运行参数:Receivables, 549291, 4427, 1

/*
GLLDEL module: 删除日记帐导入来源
+—————————————————————————+

当前的系统时间为 06-06-2007 13:58:17

+—————————————————————————+

>> glldel() 06-06-2007 13:58:17
SHRD0084: 从 GL_INTERFACE 中删除
SHRD0119: 从 GL_INTERFACE 中删除 147 记录。
SHRD0019: GLLDEL – 成功执行后退出处理。
*/

–查接口表
select * from gl.gl_interface where group_id = 4427
— 0 行 
–确实被删除
select * from gl.gl_interface
–1 POSTED -99 2005-4-30 Y 2005-4-30 10:28:31 -9999 A @#$% do not delete this record
–只有一条 OU屏蔽 而保留的记录
–发现数据确实被删除了。

–再查  AR_POSTING_CONTROL 表

  select * from AR_POSTING_CONTROL where   posting_control_id = 4427
–状态为Done  说明 AR传总帐接口是成功完成的

–查找被删除的记录

select * from  ar_adjustments_all  where   posting_control_id = 4427
— 0 行
select * from ar_misc_cash_distributions_all   where   posting_control_id = 4427
— 0 行
select * from  ar_receivable_applications_all  where   posting_control_id = 4427
— 61 行
— 备份到Excel 文件
select * from  ar_cash_receipt_history_all  where   posting_control_id = 4427
— 0 行
select * from RA_CUST_TRX_LINE_GL_DIST_ALL  where   posting_control_id = 4427
— 83行
— 备份到Excel文件
select * from  ar_transaction_history_all where   posting_control_id = 4427
–0行

–select * from  AR_PAYMENT_SCHEDULES_ALL where   posting_control_id = 4427
select * from  AR_CASH_BASIS_DISTS_ALL where   posting_control_id = 4427
— 0 行
–select * from AR_DISTRIBUTIONS_ALL where   posting_control_id = 4427
–select * from   AR_DISTRIBUTION_SETS_ALL where   posting_control_id = 4427

 –select * from AR_DISTRIBUTION_SET_LINES_ALL where   posting_control_id = 4427
 
–select * from  RA_INTERFACE_DISTRIBUTIONS_ALL  where   posting_control_id = 4427

/***********************************************************************************************************
2    使用  ARGCGP  来对这批数据进行 unpost 操作
 ***********************************************************************************************************/

— AR过帐标志重置程序 :ARGCGP
— Note:219307.1 对此程序的使用有明确的说明

–1 确保受影响的纪录的AR会计期是打开的

–2 确保受影响的记录未过到总帐
      –查总帐日记帐是否存在来自AR的Posting_control_id =8000的纪录
      select  jb.name,jh.*,jl.*
      from gl_je_lines jl, gl_je_headers jh, gl_je_batches jb
      where jl.je_header_id = jh.je_header_id
      and jh.je_batch_id = jb.je_batch_id
      and jb.name like ‘%4427%’
      
      select  jb.name
      from gl_je_lines jl, gl_je_headers jh, gl_je_batches jb
      where jl.je_header_id = jh.je_header_id
      and jh.je_batch_id = jb.je_batch_id
      and jb.name like ‘%4427%’      
      group by jb.name

— 发现没有来自 应收的 含 4427的批

     
      
–3 确保当前没有正在运行日记帐导入

–4 再次检查Posting_Control_id  的正确性,否则可能导致重复过帐。

— 按照  Note:219307.1  定义了并发程序 : ARGCGP_SD
–名称:SD AR Unposting

–提交了请求;
–参数 1, 4427, Y, N, N 4427
–请求运行出错

–检查发现 ar_receivable_applications_all 已经被重置。
–RA_CUST_TRX_LINE_GL_DIST_ALL 没有改变。

/*日志如下

=======================================
Parameters passed in:
     Set of Books Id:          1
     Posting Control Id:       4427
     Reset GL Posted Date:     Y
     Delete from GL_INTERFACE: N
     Debug Mode On:            Y
========================================

  当前的系统时间为 07-06-2007 16:23:37
*****************************************************
***** argurs *****
BEGIN TO RESET THE GL_POSTED_DATE
-> POSTING_CONTROL_ID = 4427

Resetting ar_adjustments…
Committed the reset – 0 lines

Resetting ar_misc_cash_distributions…
Committed the reset – 0 lines

Resetting ar_receivable_applications…
Committed the reset – 61 lines

Resetting ar_cash_receipt_history…
Committed the reset – 0 lines

Committed the reset – 0 lines

Resetting ra_cust_trx_line_gl_dist…

Oracle error in function ‘argurs’
 AR-ARGLTP: -20001 ORA-20001: 您无法删除已过帐记录。
ORA-06512: 在”APPS.RA_CU
AR-ARGCGP: Error from argurs
========================================
|   Cannot delete records from gl_interface.
|   Please delete records from gl_interface with group id of 4427
|   DO NOT submit any posting program until these records are deleted.
=======================================*/

— 到界面查看 ,发现 被重置的收款已经变成“未核销状态”

— 从备份的Excel文件中获取 第一条记录的  receivable_application_id ,检查这条记录
select * from ar_receivable_applications_all  where  receivable_application_id = 178374
— 把重置后的记录与重置前的记录相比较:发现 :重置的动作在于:
–就某一条AR中的会计分录而言:系统的这个重置程序  只是把POSTING_CONTROL_ID 改成 -3 并把GL_POSTED_DATE 设置为空

/***********************************************************************************************************
3    把重置成功的部分 再一次传总帐
 ***********************************************************************************************************/

— 用户再次运行 AR ->传总帐的程序
— 传输程序成功完成
— 日记帐导入失败
–日志的关键部分
— request_id =  551614

/*Error in: gllccl
Function return status: 0
Function Err Message: failure to get cross currency account
Function warning number: -1
*****************************************************
sqlcaid:   sqlabc: 0  sqlcode:  1403  sqlerrml: 27
sqlerrmc:
ORA-01403: 未找到数据

sqlerrp:   sqlerrd: 0 2 0 0 0 538976288
sqlwarn:           sqltext:  */

— 问 赵丰干
–答:总账/设置/账户/暂记  定义类别为“交叉币种”的账户   ; 这里没有设置暂记帐户
— 也就是说 要添加一条 来源=应收。类别=交叉币种 的帐户
— 相关讨论如下:

–=========================================
/*商云方 说:
老赵,汇兑损益 在AR 作不同币种的收款核销发票的时候 产不产生?也就是说在AR中是否要产生汇兑损益的会计分录?
赵丰干 说:
产生
赵丰干 说:
只要在AR中作跨币种收款核销,这个科目是必须的,无论是否有汇差产生
商云方 说:
哦,那么为什么在总帐导入日记帐的时候才报错呢? 在AR做核销的时候怎么不报错?
赵丰干 说:
因为GL中的凭证都是单币种的,因此跨币种核销业务会产生两张凭证,这个科目就是用来作中转的
赵丰干 说:
如果不设置的话,总账凭证就无法生成*/

恰好,老马也在县,就顺便跟老马也讨论了一下:
–=======================
/*商云方 说:
他们财务经理说不想做交叉币种核销,要求撤销核销。撤销港币发票。重新作人民币发票,然后再核销。
ma 说:
撤销核销不代表原来的交叉核销不存在了,只是系统产生出两笔正负相抵的交叉核销而已
商云方 说:
那怎么办呢?
ma 说:
那就追设一下,让凭证导入吗
商云方 说:
也就是说正负相抵消得交叉核销还是会传到总帐接口表吗?
ma 说:
会的
ma 说:
正负相抵不等于没有
商云方 说:
那要这么说,就只能在总帐中去设置那个暂挂帐户楼。
ma 说:
如果是一并导入的话,有可能可以导入的。
商云方 说:
准不准阿?
商云方 说:
老马,我们现在已经取消了人民币收款对港币发票的核销。
ma 说:
如正凭证:借:应收款未核销(RMB) 贷:应收款(HKD);这个凭证RMB和HKD的借贷都不平;再产生负凭证后:借:应收款(HKD) 贷:应收款未核销(RMB),那么导入的凭证会是:
商云方 说:
那么下一步,如何把那个港币发票作废掉?
商云方 说:
怎么操作?
ma 说:
借:应收款(HKD) 贷:应收款(HKD)
ma 说:
借:应收款未核销(RMB) 贷:应收款未核销(RMB)
ma 说:
你可以再传总帐,然后一起导
ma 说:
要求核销和取消核销的日期一定要一样
商云方 说:
那肯定不一样,
商云方 说:
核销是前几天进行的。取消核销时今天进行的。
ma 说:
或设上暂挂账户和选项,导入再取消此选项也可以
ma 说:
你在现场吗
商云方 说:
对,在

把问题给用户方反映了.

—  用户方 财务部经过讨论后 认为 目前还没想好要进行交叉币种核销的业务。
—  用户方决定 把 不同币种核销取消,然后对 外币发票 作贷项操作,然后再重做人民币发票,再核销。再传总帐

/***********************************************************************************************************
4    把刚才重置未成功的部分 再一次重置
 ***********************************************************************************************************/
 
—  由于刚才  ARGCGP_SD 只是重置了   ar_receivable_applications_all 表中的记录 ,而且经过再一次的调用AR->GL 的传输程序后
—  ar_receivable_applications_all 表中被重置的记录的  posting_control_id已经变成了另一个值.

— 现在需要想再次运行  ARGCGP_SD  来重置   RA_CUST_TRX_LINE_GL_DIST_ALL 中的记录
— 运行 SD AR Unposting 
–参数 1, 4427, Y, N, N 4427
–log 
/*===============================================================
***************************************************************
BEGIN TO RESET THE GL_POSTED_DATE
-> POSTING_CONTROL_ID = 4427

Resetting ar_adjustments…
Committed the reset – 0 lines

Resetting ar_misc_cash_distributions…
Committed the reset – 0 lines

Resetting ar_receivable_applications…
Committed the reset – 0 lines

Resetting ar_cash_receipt_history…
Committed the reset – 0 lines

Committed the reset – 0 lines

Resetting ra_cust_trx_line_gl_dist…

Oracle error in function ‘argurs’
 AR-ARGLTP: -20001 ORA-20001: 您无法删除已过帐记录。
ORA-06512: 在”APPS.RA_CU
AR-ARGCGP: Error from argurs
===============================================================
|   Cannot delete records from gl_interface.
|   Please delete records from gl_interface with group id of 4427
|   DO NOT submit any posting program until these records are deleted.
===============================================================
*/

— 系统标准程序重置未成功 ,手工重置

begin 

fnd_global.APPS_INITIALIZE(user_id =>1059 ,resp_id =>50330 ,resp_appl_id => 222);

update RA_CUST_TRX_LINE_GL_DIST_ALL
set GL_POSTED_DATE = NULL, POSTING_CONTROL_ID = -3
where posting_control_id = 4427;

end ;

— 上述过程执行失败,现象和并发程序执行失败是一样的
— 出错的时候会跳出 错误堆栈 ,根据错误堆栈,看源代码 知道有个Bug与此有关
— Metlink Note:272844.1 对此有说明

–措施:
— 暂时失效 触发器:ra_cust_trx_line_gl_dist_bri
— 重置请求运行完后再 启用

— 再次运行– 运行 SD AR Unposting 
–参数 1, 4427, Y, N, N 4427
— 成功完成
–log 
/*===============================================================
Parameters passed in:
     Set of Books Id:          1
     Posting Control Id:       4427
     Reset GL Posted Date:     Y
     Delete from GL_INTERFACE: N
     Debug Mode On:            Y
===============================================================

  当前的系统时间为 07-06-2007 18:50:05
***************************************************************
***** argurs *****
BEGIN TO RESET THE GL_POSTED_DATE
-> POSTING_CONTROL_ID = 4427

Resetting ar_adjustments…
Committed the reset – 0 lines

Resetting ar_misc_cash_distributions…
Committed the reset – 0 lines

Resetting ar_receivable_applications…
Committed the reset – 0 lines

Resetting ar_cash_receipt_history…
Committed the reset – 0 lines

Committed the reset – 0 lines

Resetting ra_cust_trx_line_gl_dist…
Committed the reset – 83 lines

Resetting ar_transaction_history…
Committed the reset – 0 lines
SUCCESSFUL.
****************************************************************/

— 到界面查发票的会计方法,已经变成 “未过帐” 状态。

/***********************************************************************************************************
5   用户操作
 ***********************************************************************************************************/

— 用户取消了收款与发票的核销

— 用户对此发票 作贷项操作

— 用户再做人民币发票

— 人民币收款 核销 人民币发票

— 在总帐设置暂挂帐户
–总账/设置/账户/暂记  定义类别为“交叉币种”的账户
— 来源=应收款管理系统
— 类别 = 交叉币种 
— 帐户 = 0003.00000.7201030101.00000000.000000.000000.000.000000.00

— 再次运行 AR->GL 的过帐程序
— 用户报告 一切OK  (暂记帐户是有内容的)

/***********************************************************************************************************
6   总结
 ***********************************************************************************************************/

解决方法:   利用系统提供的隐藏并发程序  ARGCGP 对这一批数据进行AR反过帐. 然后再重新过帐. 因为交叉币种核销问题,添加了暂记帐户。
注意点: ARGCGP 反过帐时, 由于ra_cust_trx_line_gl_dist_all 上有个数据库触发器会阻止ARGCGP 对表的修改,所以会导致失败.
       解决方法有两种
                       1是 临时实效此触发器. 待 ARGCGP运行完以后再恢复生效.
                      2 Oracle 说这是一个Bug, 可以打个patch 解决。打patch以后ARGCGP 就不会出现运行失败的情况了。
       我选择的是方法1,对于临时解决问题而言,比较简单。因为毕竟在很少的情况下用户需要进行反过帐操作。