月结流程.docx

月结流程.docx

《月结流程.docx》由会员分享，可在线阅读，更多相关《月结流程.docx（24页珍藏版）》请在冰豆网上搜索。

月结流程

月結SOP

月結之總體ScopeandFrame

•INV月結—交易過帳

Check所有transaction是否异常,pressallTXN均過帳

保證庫存的正確性和真實性:

並ExtractINV/WIPQTYfor重算成本

•財務月結—算出原料成本

重算成本

（通過加權平均算出每個item原料的成本-pendingcost）

找成本差异,更正有誤的成本

•Cost月結---形成財務報表

會計分錄,抛GL

形成生產成本价格，記錄歷史成本

Updateitemcost（Frozenstandardcost）

SubmitstandardcostadjustmentReport

目前對於財務月結和INV月結本質上沒有影響,除了驗收會對財務計算材料成本有影響以外.

INV月結:

INV月結就是為了保證本月的交易正常產生.即本月的交易只產生在本期（會計區間内）,非本月的交易絕不可以產生在本月.並因此而保證庫存的正確性,準確性.（這也是為什麽要check負庫存和帳查的原因）,以便抽出本期期末（下期期初）,為計算材料成本和CostUpdate做最正確的準備.任何錯誤的期末都一定會影響成本的正確性.

Step1.AllrecordsinHUBinterfacemustbecleared.

原則上是要CheckEDI856所有的Interface中的異常數據，這些是本月的交易但是卻不能正常產生交易異動檔。

所以必須讓這些數據正常insert到mtl_materail_transactions中。

關注的table有：

MIC_HUB_ISSUE_DETAILS，MIC_HUB_RECEIVING_DETAILS，MIC_HUB_TRANSACTION_DETAILS等EDI異常之table。

1.check發料的EDIinterface。

檢查語句Script：

SELECT*FROMMIC_HUB_ISSUE_DETAILS

WHEREEDI862_UPDATE_STATUSlike'ERR%'

ORSTATUS_CODE!

='OK-862'

產生問題的程式：

（CauseofIssue:

）

1.MiTACHUB（昆達）InboundMainProcess:

56M

2.MitacHubIssueInventoryProcess:

3.HWAHUB856Update862&AllocatedRecords:

4.PKG:

mkl_wip_auto_jj_for_02.auto_post_jj

處理辦法：

Errorstatuscode:

¶.ERR-PA-01

Priceagreement價格協議書未建立，AA單無法驗收

解決方式:

請PO人員解決

·.OK-BP、ERR-ISS（6）

JJ單利用EK調撥，不足量以AA採購，但EK與AA回的時間不同，過帳組未加以確認數量即過帳，造成第二筆單據無法過帳，形成HUBDATAError，進而造成INV負庫存。

解決方式:

過帳組會以加開JJ單與EK單將負庫存清空。

2.checktxn（如：

EK，DD，FF）的interface

檢查語句Script：

SELECT*FROMMIC_HUB_TRANSACTION_DETAILS

WHERESTATUS_CODE!

='OK-856T'

CauseofIssue:

MiTACHUB（昆達）InboundMainProcess:

56M]

EDIfromHUB:

處理辦法：

請查看程式

3.check驗收或者Approval的interface

檢查語句Script

select*fromMIC_HUB_RECEIVING_DETAILSH

whereLIKE'%ERR%'

CauseofIssue:

MiTACHUBReceivingProcess：

處理辦法：

UPDATEmic_hub_receiving_detailsh

SET='IMPORTED',

batch_id='124666'

然後：

通過BU_Code來判斷是GTK還是MKL,然後:

如果是transaction_type='S'要在對應的mitachubsupervisorgui運行mitachubstatuschangereport

如果是transaction_type='R'要在對應的mitachubsupervisorgui運行mitachubreceivingprocess

注意此程式是POModule中的程式需要byOU來運行.即挑選必要的responsibility

Step2.AllrecordsinMTLTXNinterfacesmustbeposted

OracleERP的過賬是通過MTL_TRANSACTIONS_INTERFACE和MTL_MATERIAL_TRANSACTIONS_TEMP及RCV_transactions_interface

與用戶或者客戶化作為接口來處理的。

Oracle自己的核心程式會自動由這兩個interface來判斷並處理產生正式的交易。

因爲oralce程式會自己判斷，如果數據不符合其規則或者異常，將會一直卡在interface中，不能正常產生交易。

處理interface產生正常交易的程式是：

MaterialtransactionManager.

Navigate:

INVSupperUserGUIsetuptransactionInterfaceManager裏面的Materialtransaction，如果其status為Active，則説明其是處在工作狀態。

（一般情況下，但oracleERPstartup，其都會在ConcurrentManager中InventoryManager中運行著）

處理：

MTL_MATERIAL_TRANSACTIONS_TEMP

方法1。

ToinvestigatewhytheTransactionsareFailing,runthefollowingSQLScript:

SQL>

selecttransaction_source_id,inventory_item_id,process_flag,

error_code,error_explanation,

transaction_source_type_id,organization_id

frommtl_material_transactions_temp

HowtoresubmittheTransactionsusethisscript:

SQL>

updatemtl_material_transactions_temp

setprocess_flag='Y',

lock_flag='N',

transaction_mode=3,

error_code=NULL,

error_explaination=NULL

whereprocess_flag='E'

方法2：

進入OracleERP系統察看並處理此种情況：

Navigate：

INVSupperUserGUItransactionPendingTransactions

處理MTL_TRANSACTIONS_INTERFACE

方法1：

SQL：

select,,

,,mti.*

frommtl_transactions_interfacemti

存放錯誤代碼，

Process_flag:

1:

ready2,notready,

Lock_flag:

1:

Locked,2ornull:

notlocked

處理完提示的錯誤后，updateprocess_flag=1,如果Lock_flag為1,請update為2或者null.

方法2:

同樣進入OracleERP系統察看並處理此种情況：

Navigate：

INVSupperUserGUItransactionTransactionOpenInterface.

處理：

RCV_transactions_interface

Checkerrmsg,thenrunthereceivetransactionreportbybatchid

Step3.Findnegativebalance負庫存

負庫存是系統不夠嚴謹的最明顯的表現,從根本上消滅負庫存是系統的目標,也是INVModuleMIS負責人的一個任務.因爲負庫存處理起來比較複雜,請及時處理,You’dBetterDealwithitByWeekevenbyDay

查看負庫存可以Run:

WHdataentryÕinvÕrunreportÕ負庫存報表

也可以直接運行SQLScript:

select*frommkl_negative_balance

並與帳務人員一起協同處理

Step4和Step5都是為了TXN的正常,本月的txn的transactiondate和PeriodID（會計區間ID）保持一直,都在本月,以免CostUpdate和切分錄的正確性。

但對於下面兩點的有效性保留自己的意見，待深入研究，在此不作評價。

Step4.CheckTXdate

SQL

select*fromMTL_MATERIAL_TRANSACTIONS

WHERETRANSACTION_ID>4421847

andTRANSACTION_DATE

00:

00','DD-MON-YYYYH24:

MI:

SS'）

andTRANSACTION_TYPE_ID!

=24

--TRANSACTION_ID為上月MAX_TX_ID

--TRANSACTION_DATE為這月第一天

--TRANSACTION_TYPE_ID!

=24此為Standardcostupdate

有問題bycase

通常為TX_DATE錯誤，所以Account_Periods也會有錯誤，所以要byORGupdate成正確的。

Step5.Checkacct_period_id

SQL

SELECT*FROMORG_ACCT_PERIODSORDERBYACCT_PERIOD_IDdesc

selectdistinct,

fromMTL_MATERIAL_TRANSACTIONSMMT,ORG_ACCT_PERIODSOAP

whereTRANSACTION_ID>

andTRANSACTION_TYPE_ID!

=24

AND=

--TRANSACTION_ID為上月MAX_TX_ID

Step6.RunReporttocost

此程式是INV月結的關鍵，計算每個料號的期末庫存（包括INV和WIP），是byOU跑的，沒個OU跑一次。

UC-抽INV/WIPQTY/AMOUNT準備重算成本（BYOU）（MBOU0001）

Step7.CheckOnhandQTY&TXQTYbalance（ALLORG）

此程式是check期初+本月txn是否等於期末庫存，並抽取期末庫存？

？

？

？

注意要保存report的内容，因爲report的内容都是由問題的（即期初+txn<>期末），請記錄並分析

入徑:

wipsuperuser->mis模擬報表程式->ExtractMICownon-handforITI/IHTI

recordthelog/reportmessage

入徑:

wipsuperuser->mis模擬報表程式->ExtractVendorownon-handforITI/IHTI

recordthelog/reportmessage

如果不平bycase

Step8.抽外倉AW區的庫存及金額

Step9.SelectMAXTXID

SQL

selectmax（TRANSACTION_ID）fromMTL_MATERIAL_TRANSACTIONS

MailtoCOST

Step10.OpenacctperiodbyORGinnextmonthfirstday.

逐Org打開會計區間，如果發現會計區間内沒有下月的區間，請聯係GL或者財務建立GL會計區間或者打開GL會計區間，只有GL區間打開，INV的區間才可用。

建立GL會計區間在INVModule也同樣存在，

Navigate：

INVSupperUserGUISetupFinancialsAccountingCalendaraccounting中建立GL會計區間

Navigate:

INVSupperUserGUISetupFinancialsAccounts中打開會計區間

Finance月結

MISCost月結

Cost月結前的準備工作：

関掉可能在oracle中產生交易（向MTL_MATERIAL_TRANSACTION插入數據）的EDI或者自動schedule程式。

目前的做法為：

1．在MIS月結前，切斷所有用戶，替換oracleERPlogin入口Portal

方法:

login到ERP服務器，（or）find的位置，把此文件更名替換掉。

這樣在用戶loginERP的時候就會彈出頁面找不到的ERRmessage。

2．停掉EDI程式

MiTACHUB（昆達）InboundMainProcess（3個）

此IOOracle的EDI的程式，它會把IO中的過賬動作會抛給oracle而產生txn。

影響MIS月結

MKLAUTOSIMULATIONANDPOSTAFTEREK

此程式為IO中合併備料EK過賬會抛oracleERP后，自動讓相應的JJ單過賬，產生JJ單過賬。

AutoGenerateDDSlipNumber

AutoDDproject中倉庫在IO收到SFCS中的物料后，自動在ERP產生DD單的程式。

3．停掉Autoschedule程式

AutoSFCSMoveTX

此程式為自動MOVEWIPTXN，產生Movetransaction

MKLRepairthedifferenceofissueandtransaction

此程式會通過MTLmaterialtransaction更改工單的issue和usequantity,此程式會與CE-30CCRollback的程式衝突，造成CE-30修改的量被此城市repair。

注意：

在IO中過賬完半個小時（大多數EDI的程式運行周期均小於半個小時）后，才可以停掉EDI的程式。

並且上面的程式在停掉以前應該再運行一次，以盡量保證所以本期交易在oracleERP中產生。

另：

AutoGG的Process過長超過半小時，往往會在月結開始后會產生GG單（請注意—目前未解）

1．DeleteandUpdateResoucrerate（New）

目前因爲MKL和GTK的resourceRate為O，所以人工不需要在charge到WIP中去，所以生産日報表中keyIN並產生WIP_cost_txn_interface紀錄對於GTK來説已經不再需要，為提高切分錄的時間直接Delete。

對於MPK因爲目前產綫的keyin的生産日報表之時間人工=keyin的工時*laborrate，而目前LaborRate與相應的resourcerate相同。

故系統中不再設置Laborrate，而直接用resourcerate。

此程式就會charge和update相應的resource。

2.檢查各org成本料號是否一致

Navigate：

CSTCostEndingProcess->uc-跨Oraganization成本Check（Pending&Frozen）

Parameter：

Pendingcost

如果不一樣就察看他們那個合理,在itemcostitemcost中察看item的cost,也可以在其他Org看,判斷那個更合理,如果不一致，就通過copycostfunction來統一PendingCost。

並且如果Pendingcost不一致，説明財務月結的最後一步沒有做好或者PendingCost在財務月結完后又被重新計算過。

3.CHGWOStatustochangethestatusfrom'failtoclose'to'completenochargedallowed'

Navigate：

CostEndingProcess->CE-25CHGWOStatusforOSP

Parameter：

無

此程式目地在DeOracle的Bug:

FailtocloseWO會和closeWO一樣,在costroll-up時Resource,Overhead不會算到，所以先暫時將WO的Status向前移回CompleteNoChargedAllowed（15=>5）,CostRoll-up完後在改回（step32）.（此處時引用黃韋道和陳欽專編的《ENDCOSTPROGRESS訓練教材》）

但目前在多次月結經驗中，發現FailtoCloseWO在CostManager中進行切分錄的時候，不能正常Charge到WIPAccount中，所以建議在CostManager切完分錄后，再改囘的動作。

4.CE-30CCRollback

Navigate：

CostEndingProcess->CE-30RollbackCC-Z-

參數：

無參數

這個程序主要是DeleteOracleERP的Bug，在資產重新評估之前,本月份（AccountPeriod）的CC單尚未切分錄,理論上不應計算在資產重新評估中（應在下月份月結才算入本月份的CCTransaction）,然而Oracle將其算入.

如果不做這步，則對於存在Z-w和CC的工單其在WIPStandardCostAdjustmentReport中的AdjustmentQuantity將會不正確。

正確的邏輯；期初：

=期末-（JJ-CC）+（DD-Z-W）=期末-JJ-Z-W+CC+DD，

Oracle錯誤的邏輯：

期初：

=期末-JJ+DD

因爲期末沒有錯，要用oracle錯誤的邏輯算出對得Adjustmentqty，則必須在JJ單中+CCqty，在DD中-Z-Wqty。

5.CostUpdate

Navigate：

Cost->Itemcost->stdcostupdate->UpdateCosts

每個org都作,并且不可以錯:

就是要選OU,在changeorg的BYorg來作

注意不可以掉了任意一個

是從pendingcost更新到Frozencost

（財務再通過加權平均后得到的本月實際成本放在pendingcost中,再通過本月的實際成本和上月的實際成本（既Frozencost）作比較,算出差异）

RUN報表前的參數設置:

上面是設置帳本的界面!

下面是參數的主界面

通常出錯的原因：

1．Request直接報ERR，Requestlog中提示無下月的會計期間。

出錯原因：

本Org下月會計區間沒有打開，CostUpdateTXN不能正常產生在下月期間内。

2．CostUpdate运行过长时间（>小时），并且在requestLog中出现：

App-00988 OracleError1654ele-acct错误信息。

这中错误原因不明，但是此ERR一定要checkDB的ERR。

方法：

login到DB（telnet到），查看DB的AlertLog：

界面和目录如下：

6.CheckCostUpdate的結果allorgs

Navigate：

CostEndingProcess->uc-跨Oraganization成本Check

参数：

FrozenCostType，每個公司（OU）均需運行一次。

檢查FrozenCost是否一樣

7.調整有誤的料號

Navigate：

Cost->CostMassEdits->CopyCostInformation->CopyItemCostsAcrossOraganizationWEI

參數怎么設置

1﹒現從DGL的frozen導入到DTS（responsibility是DTS）的MSH0211　type

2﹒然后在調用copyitemcost（forimportdata）

把DTS　的MSH　costtype導入到DTS的Frozen　costtype

9．CE-40CCRecovery

Navigate：

WIPSuperUser/CostSupperUser->CostEndingProcess->CE-40RecoveryRollbackCC->Z

参数：

无参数

此程式和CE-30RollbackCC-Z-對應，修復CE-30RollbackCC-Z-做過的Debug的修改。

10.CE-45暫移下個月之Tranx（theres/ohtxinthenextperiod）

Navigate：

CostSupperUser->CostEndingProcess->CE-45TempremovingthenextperiodRes&OH

Parameter：

下個月的第一天（下期的第一天）

此程式是把下期發生的人工（產鮮助理keyin的生産日報表）和可能的外包工單的OSP費用（Wip_cost_txn_interface）暫存到零時文檔，再在CE-55RecoverytheremovenextperiodResc&OH恢復。

如果目前MISCOST月結發生在本期的期末晚上和下期期末淩晨的話，此步驟和CE-55可以不作。

11．切分錄前的准備程式-成品

Navigate：

CostEndingProcess->TX-切分錄前的准備程式

Parameter：

本期期間（Mar-05）

此程式的作用：

取本期的最小最大TXNid。

InsertMax_txid,Min_txid到MIC_MTL_MINMAX_TXID

大於上期最大TXNID的TXN的CostFlag均必須為N。

判斷本期所有的交易均正常，上期月結切分錄沒有本