商云方的技术博客 (沪ICP备14046774号-1)

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

/*
现象： 顾问做了一张订单，在登记并完成“后台工作流程序” 后，订单及订单行关闭；
但是有一行 在AR中未找到对应的发票行（总共有6行，5行到了AR，有一行没有到AR）
*/

— 查订单行（由于订单行及发票行的attribute2 都用于存放 POS小票号，所以可以根据POS小票号来查
select  * from  oe_order_lines_all   where attribute2 = ‘ZCXSS111202800000035’
–返回6条记录
–查发票接口
select  * from  RA_INTERFACE_LINES_ALL  where attribute2 = ‘ZCXSS111202800000035’
–返回 0 条记录，说明已经全部被处理
–查发票行
select  * from  RA_CUSTOMER_TRX_LINES_ALL  where attribute2 = ‘ZCXSS111202800000035’
–返回 5 条记录
–说明肯定有一条根本就没有生成到AR接口表中

— AR 行 和订单行的差异，发现没有过来的一条记录，其发票接口状态字段异常 INVOICE_INTERFACE_STATUS_CODE =  NOT_ELIGIBLE
— 所以直接原因是 因为订单行不合法导致未能开票。 那么具体是什么原因呢？
— 打开 OM   行流 工作流定义 ，根据返回状态为NOT_ELIGIBLE 进行代码追踪 ；
— 从 行开票接口节点开始  OE_INVOICE_WF.INVOICE_INTERFACE->OE_Invoice_PUB.Interface_Line  – >OE_Invoice_PUB.Interface_Single_Line->OE_Invoice_PUB.Line_Invoiceable
— Line_Invoiceable 这个函数是最终的可能提供详细原因的函数。看代码后发现 导致行不可开票的原因有很多种，究竟是哪一种呢？
— 启用Debug ，准备做一次调试，看具体的debug原因就可以确定了明确的不可开票原因了。

— 在用户层设置  系统配置文件  “OM： 调试级别”      把值设置为5
— 在用户层设置  系统配置文件  OM：调试日志目录”      把值设置为   /usr/tmp
— demo  环境应用服务器：
— 删除 usr/tmp/  *.dbg  文件
— 再作一张订单，登记，运行工作流后台程序 ，直到订单关闭
— 在usr/tmp 目录下去看日志文件。
— 郁闷，这里的日志文件 只是跟踪到订单界面上的操作。根本就未能跟到  Line_Invoiceable 这个函数。所以从这个日志文件也看不出什么名堂。
— 那么是否信息被debug 到  fnd_log_message 表中去了呢？ 去找了一把也没有找到。
— 再去读  oe_debug_pub 程序，也就是记录日志的那个程序包。 发现它会判断：如果从系统配置文件中获取的当前 并发请求Id 不是 -1 ，
— 并且不是在 UI模式的话则会把日志的输出文件输出到 并发程序的log中去
— 想想，虽然我们是在界面上录入，登记订单。 但是真正启动   Line_Invoiceable 这个函数 的人应该是” 工作流后台流程” 这个并发程序。
— 是不是log信息被记录到这个” 工作流后台流程” 的log中了呢？
— 看刚才运行的 ” 工作流后台流程” 的log ，果来是这样。其中有句log 应该是 Line_Invoiceable 输出的

— 日志 ENTERING LINE_INVOICEABLE 应该是进入  Line_Invoiceable 函数的 标志性的日志语句
/*
ENTERING LINE_INVOICEABLE
。。。。。。
ITEM NOT INVOICEABLE ( 2 )
l_freight_count: 0
Handling non-invoiceable lines with no freight or automatic numbering*/

— 根据错误日志 “Handling non-invoiceable lines with no freight or automatic numbering”  到OE_Invoice_PUB 包中查找，，发现这个错误是由
— Interface_Line 函数抛出的，而且这句话是在调用line_invoiceabel 返回结果 false  并且
— 在  FND_PROFILE.VALUE(‘WSH_INVOICE_NUMBERING_METHOD’) = ‘A’ 的情况下设置的。

— ITEM NOT INVOICEABLE(2) 是 Line_Invoiceable 函数抛出的日志，在程序中有如下判断：

     IF (l_invoiceable_item_flag = ‘N’) OR
        (l_invoice_enabled_flag = ‘N’) OR
        (p_line_rec.item_type_code = ‘SERVICE’ AND l_serviceable_product_flag = ‘N’) THEN
           IF l_debug_level  > 0 THEN
               oe_debug_pub.add(  ‘ITEM NOT INVOICEABLE ( 2 ) ‘ , 1 ) ;
           END IF;
           RETURN FALSE;
     END IF;
    
—  而l_invoiceable_item_flag 和 l_invoice_enabled_flag 都是从物料信息表获取的：

        SELECT INVOICEABLE_ITEM_FLAG, INVOICE_ENABLED_FLAG
        INTO   l_invoiceable_item_flag, l_invoice_enabled_flag
        FROM   mtl_system_items
        WHERE  inventory_item_id = p_line_rec.inventory_item_id
        AND    organization_id = nvl(p_line_rec.ship_from_org_id, oe_sys_parameters.value(‘MASTER_ORGANIZATION_ID’, p_line_rec.org_id));
    
    
— 可见本次问题发生的真正原因就找到了： 就是物料属性设置不对，不可开票阿！！！。