客户：达芙妮
现象：1 并发节点文件系统满，导致并发管理器挂起
2用户删除了部分日志和输出文件，并重新启动管理器，所有管理器都正常启动，只有库存管理器actual=0, target=10
分析&解决
一、灏明（Oracle) 10日去现场看了下，发现后台库存管理器进程状态为defunct，mtl_tranasctions_interface中有大量待处理数据（从出故障到现在的所有库存事物处理），并采取了一次处理少量数据来解决问题，下面是他的脚本
——————————————–
分类：DataFix
接收事务处理接口错误处理日志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，对于临时解决问题而言，比较简单。因为毕竟在很少的情况下用户需要进行反过帐操作。
DataFix_接收清算帐户
采购组织接收选项清算帐户公司段设置错误，已经产生相关凭证，并且已经传总帐，要求做DataFix
===================
Issue 1 DataFix_RCV_Clearing_Account_Change_For_CAN
===================
现象
现象1：加拿大公司的总帐日记帐界面：接收清算帐户，日记帐不平，无法过帐。如下图:
现象2：加拿大库存组织上CC1上的，清算帐户的公司段设置错误,应该设置成801，实际设置成了801,如下图：
事实1： ORG_ID=801是美国公司，ORG_ID=802是加拿大公司，加拿大只有一个库存组织：CC1
事实2： 加拿大采购模块的相关凭证已经Transfer到总帐日记帐（已经完成日记帐导入，但尚未过帐）
事实3：加拿大和美国使用不同的帐套。
事实4：子模块到总帐是汇总传的，目前在总帐看到两笔出错的不能过帐的日记帐存在此问题。Journal_head_id 分别是：25418 ，25337 事实5：此前曾发生过CC1库存组织接收选项上的接收帐户设置错误的情况。也是错误的设置成801
事实6：接收帐户与清算帐户的科目是一样的。
事实7：接收选项上的Clearing Account在11.5.10开始出现，在11.5.9版本上没有。
事实8：加拿大启用了多币种，美元为本位币，加元帐套为报告帐套，帐套ID分别为1002(USD) 和 1003(CAD)
分析:
受影响的业务：
1) 当采购组织与接收组织不一致时，会使用到此帐户。
2) 使用Drop-Ship，其接收帐户使用的也是Clearing Account. 而加拿大使用的全部是Drop-Ship.
解决方法：
1) 在后台更改CC1采购接收组织的Clearing Account 的公司段为：802 ;
2) 更改子模块（采购模块和库存模块）的所有错误的凭证
3) 更改总帐中（接口和日记帐）所有错误的凭证
4) 如果存在相关汇总帐户，再更新相关汇总帐户。
分析SQL:
1 获取801.1244010000.000000.000.00000000 的CCID Select code_combination_id From gl_code_combinations Where segment1 = '801' And segment2 = '1244010000' And segment3 = '000000' And segment4 = '000' And segment5 = '00000000' #返回：1051 2获取802.1244010000.000000.000.00000000 的CCID Select code_combination_id From gl_code_combinations Where segment1 = '802' And segment2 = '1244010000' And segment3 = '000000' And segment4 = '000' And segment5 = '00000000' #返回：2316 获取 科目= '1244010000' 的所有帐户 Select code_combination_id From gl_code_combinations And segment2 = '1244010000' #返回： 2316 1051 说明该科目相关的帐户只有两个明细帐户，无汇总帐户。 3 获取加拿大帐套的ID Select set_of_books_id From gl_sets_of_books Where Name = 'GiTi Canada Set of Books' #返回1002 4 获取帐户错误的日记帐头 Select Distinct gl.je_header_id From gl_je_lines gl, gl_je_headers gh Where gl.je_header_id = gh.je_header_id And gh.set_of_books_id = 1002 And gl.code_combination_id = 1051; #返回两笔： 25418 25337 5 获取加拿大OU的org_id Select organization_id from hr_operating_units where Name =’某客户(Canada),LTD. #返回127 6 获取CC1的组织ID Select organization_id From mtl_parameters Where organization_code = 'CC1' #返回：126 6 获取库存模块错误的会计分录的所有事务来源类型 SELECT DISTINCT mta.transaction_source_type_id FROM inv.mtl_transaction_accounts mta WHERE mta.organization_id = 126 AND mta.reference_account = 1051 #返回：1 |
相关检查：
--rcv_accounting_events Select Count(1) From po.rcv_accounting_events a Where a.org_id = 127 And a.debit_account_id = 1051; 返回：18 --rcv_receiving_sub_ledger Select Count(1) From rcv_receiving_sub_ledger a Where a.set_of_books_id = 1002 And a.code_combination_id = 1051; 返回：18 Select Count(1) From rcv_receiving_sub_ledger a Where a.set_of_books_id = 1003 And a.code_combination_id = 1051; 返回：0 -- mtl_transaction_accounts Select Count(1) From inv.mtl_transaction_accounts mta Where mta.organization_id = 126 And mta.reference_account = 1051 And mta.transaction_source_type_id = 1; 返回：18 -- gl_interface Select Count(1) From gl.gl_interface gi Where gi.code_combination_id = 1051 And gi.set_of_books_id = 1002; 返回：0 Select Count(1) From gl.gl_interface gi Where gi.code_combination_id = 1051 And gi.set_of_books_id = 1003; 返回：18 --gl_je_lines Select Distinct gl.je_header_id From gl_je_lines gl, gl_je_headers gh Where gl.je_header_id = gh.je_header_id And gh.set_of_books_id = 1002 And gl.code_combination_id = 1051; 返回： 25337 25418 Select Distinct gl.je_header_id From gl_je_lines gl, gl_je_headers gh Where gl.je_header_id = gh.je_header_id And gh.set_of_books_id = 1003 And gl.code_combination_id = 1051; 返回： 无记录 |
执行更新脚本：
BEGIN -- update rcv_parameters Update po.rcv_parameters p Set p.CLEARING_ACCOUNT_ID = 2316 Where p.organization_id = 126; --update rcv_accounting_events Update po.rcv_accounting_events a Set a.debit_account_id = 2316 Where a.org_id = 127 And a.debit_account_id = 1051; --update rcv_receiving_sub_ledger Update rcv_receiving_sub_ledger a Set a.code_combination_id = 2316 Where a.set_of_books_id = 1002 And a.code_combination_id = 1051; -- Update Inv trnasactions account Update inv.mtl_transaction_accounts mta Set mta.reference_account = 2316 Where mta.organization_id = 126 And mta.reference_account = 1051 And mta.transaction_source_type_id = 1; -- update gl_interface Update gl.gl_interface gi Set gi.code_combination_id = 2316 Where gi.code_combination_id = 1051 And gi.set_of_books_id = 1002; Update gl.gl_interface gi Set gi.code_combination_id = 2316 Where gi.code_combination_id = 1051 And gi.set_of_books_id = 1003; --update gl_je_lines for head 25418 and 25337 Update gl.gl_je_lines a Set a.code_combination_id = 2316 Where a.je_header_id = 25418 And a.code_combination_id = 1051; Update gl.gl_je_lines a Set a.code_combination_id = 2316 Where a.je_header_id = 25337 And a.code_combination_id = 1051; End; |