MRP跑完之后会产生计划单,然后发放成请购单,再由请购单发放成采购订单。
对于现有的采购订单,MRP会建议取消或延交。
但是MRP没找到标准的发放对采购订单需求日期进行更改,故客制修改采购订单的需求日期。
第一次没有休眠直接跑API,发现系统好慢,然后系统貌似有宕机的迹象。故诚惶诚恐。
后经测试发现,每当对一个采购订单所有的行更改完需求日期之后重新送审,会产生一个PO通信输出请求,
然后因为出现几百上千个请求,导致系统会宕机,后想了一个办法,每次跑之前检查系统是否还有PO通知输出请求在运行,
有就等待,直到运行完毕,没有就继续运行,虽然这么做会造成时间的延长,但是系统会安全,鱼与熊掌不可兼得。
另1:修改完需求日期会重新根据默认的审批层级结构送审,因为这部分不需要上级审批,所以设置系统的更改单容忍度(PO模块下更改单功能下),
在一定天数的需求日期更改可以自行重新审批,不走审批层级结构
另2:直接修改底表的需求日期,我也想过,但是经测试发现改完之后MRP不参考底表修改后的数据,所以此不可行。
未解决问题:如果需求日期更改不导致版本增加,不要求重新审批岂不美哉?
共享code如下:
CREATE OR REPLACE Package Body JWPOP002 Is
/*created by jam huang 20151201 根据MRP自动更新采购订单的需求日期*/
procedure auto_update_need_date(Errbuf Out Varchar2,
Errcode Out Varchar2) is
CURSOR C_HEADER IS
SELECT DISTINCT p.organization_id,p.po_number,p.userid
FROM jw_update_po_date_temp P;
cursor c_line(v_po_number varchar2) is
select t.rowid row_id,
t.organization_id,
t.po_number,
t.revision_num,
t.line_num,
t.postprocessing_lead_time,
t.new_need_date
from jw_update_po_date_temp t
where t.po_number = v_po_number;
excep exception;
v_num_1 number := 0 ;
v_num_2 number := 0 ;
i_1 number;
j number;
v_APPROVALS varchar2(1);
v_rev_num number;
v_resp_id number;
v_error_num number := 0;
v_conc_num number;
v_conc_num_1 number;
RESULT NUMBER ;
v_api_errors po_api_errors_rec_type;
begin
-------防呆--------------
select count(*) ---只能在周二和周五运行
into v_num_1
from dual
where to_char(sysdate, 'd') not in ('3', '6');
if v_num_1 > 0 then
raise excep;
end if;
select count(*)
into v_num_2 ----一天只能跑一次
from jw_run_update_po_date_flag j
where j.run_date = trunc(sysdate)
and j.flag = 'Y';
if v_num_2 > 0 then
raise excep;
end if;
insert into jw_update_po_date_temp_his ------备份
select p.*,sysdate from jw_update_po_date_temp p;
commit;
delete from jw_update_po_date_temp; ------清除
commit;
INSERT INTO jw_update_po_date_temp
(organization_id,