Exchange Rate Type P 在過去的版本中,我們都沒有維護過名稱為P(Standard translation for cost planning)的exchange rate type,但在現在的系統中,這種匯率類型是co中需要維護的一部分,如果不維護,co中的cost planning就不完整,這種情況下,會導致制令confirm時會跳出出錯的信息,這個時候仍然可以強制跳過,保存confirm的信息,但你如果檢查一下co中這個制令的成本數據,就會發現沒有實際的工時產生, 如果你全面的檢查一下,會發現其他的資料和結果都沒有問題. 解決的方法也很簡單,就是按照提示到維護匯率的地方維護一個新的類型為P的匯率(這個類型以前沒有用過): 這個時候再執行order的confirm就不會有問題了,工時會準確的跑出來,這個情況比較特殊,這未來新建的工廠中還會出現,維護CO與PP的同事一定注意,以免工時數據Run不出來,Routing都白做了,如果一直不維護,沒有一點工時出來的話,後面CO月結時的Assessment和PriceCalculate也沒法做了. Zhou, Robert 2007-03-21 3 -- 3 采購單價出錯對財務數據的影響與補救措施 2007-3-23 SAP中物料單價最重要的形成來源是對外采購的定單價格,因此,采購定單的價格對物料價格异動有很大的影響,有時這種影響是决定性的。在這種情况下,如果下單的user在輸入價格出現錯誤,其影響與造成的麻煩往往遠比想像的大,這與SAP系統各個模組之間高度的集成性有很大的關係。 從已有的經驗來看,錯誤一旦形成往往都不是在價格上很小的誤差,因爲輸錯的往往都不是價格,具有代表性的是計數單位1000變成了1,或者把采購數量或者其他莫名其妙的數字輸入了進來,其結果是要麽不錯,要錯就錯的很離譜。更爲糟糕的是錯誤不會停止脚步,系統在不停的運行,流程在往下走,那個最初的錯誤如同一個病毒在系統中擴散,當有人發現時,錯誤也許已經成數量級的增長。但這仍然不是最糟糕的情况，因爲灾難的源頭也許是個錯誤，但决定性的因素却是我們對待錯誤的態度以及采取的行動。那麽，還有什麽更糟糕的情况在等著我們：錯誤被發現了，但不是被所有與之相關的人，每個人都會從自己的專業角度看待這個問題，例如當初那個下錯單價的user，理論上他應該也是最先發現錯誤的人之一，至少是最先被通告的人之一，那下一步怎麽辦，檢查一下庫存，太好了，庫存大于那筆訂單的數量，然後將當初的入料還原了，重新下單買進來。只要抱有相應的職業謹慎性，我們就會懷疑這樣的做法可能會引起更嚴重的問題，有時候我不得不懷疑如此複雜的系統已經成爲客觀世界的一部分，我們沒有可能將錯誤完全的還原到錯誤發生前的狀態，至少從成本的角度看是這樣。 在過去發生過千倍單價錯誤的時候，我曾經在mail裏面舉例簡單說明上述的行動對財務數據的影響，由于舉例更直觀，這裏再引用一次。有一顆材料A原來是7元/EA,庫存1000EA,庫存金額7000RMB,現在有一張PO單價錯了,單價7000,采購數量爲1000,總額7000000,入料以後庫存2000EA(1000+1000),總額爲7007000 RMB (7000000+7000)RMB，單價變成3503.5RMB/EA,這個時候有100顆發上産綫,幷被一百個111階的半成品confirm吃賬,請注意,這個半成品本來只應該含有一顆價值7元的A料,可是它現在却含有一個單價3503.5的A材料,所以這批111階的半成品的單價比正常時提高了3496.5元(3503.5-7)，這個時候下單的人發現了錯誤，但幷沒有考慮到系統裏其他模組發生的事情，本來應該把這個産綫吃料的動作還原了再還原入料(這樣一切都回到原來的起點),可是因爲庫存還够，他却直接把入料還原了,這在他的角度看太正常不過了，但却導致了更嚴重的後果,爲什麽,因爲采購訂單是在與供應商結算,所以要按入料時的單價退回這顆料,這時庫存是多少呢,數量1900EA(2000-100) ,總額(7007000-3503.5*100)=6656650元,而要退運(還原)多少呢,1000EA,金額7000000元, 咦,真奇怪,總庫存數量雖然還够,但金額却不够了,SAP也被搞暈了,但SAP有它的原則,還原一定要按7000000還原,但庫存可以爲零,决不能爲負數,所以把庫存降爲零,但還差34350元(7000000-6656650),這可怎麽辦,(SAP在想,明明最多就值6656650元,居然能退7000000,這回賺了!) SAP把這筆"節約出的錢"去倒沖製造費用(正常情况下是製造費用－小額價差科目).實際上那筆錢在111階裏，它在間接費用和直接材料成本間擺錯了位置，但形成的過程却沒有邏輯上的合理性，當然更不符合財務上的原則，數據結構完全被破壞了。 上面的例子看似複雜却是最簡單的情况，現實中的情况可能還要複雜得多，可能錯誤單價的材料被confirm到n個制令中，後面又有其他的采購訂單也在入料，當然同時錯兩次的可能性 1 幾乎不存在，所有又有正確單價同時入進來，MAP在不停的變動，這本身已經是一場灾難，再還原錯了的話我們會發現有時候系統真的已經不是現實上不可逆，而是技術上也不可逆了。 當然，重點的問題還是對錯誤的補救上，因爲防範的方法不在今天討論之列，系統畢竟沒有智能，加再多的報表和功能也代替不了人。發現錯誤後最簡單有效的方法自然是沿原路返回，根據時間順序逆向的還原，一直還原到錯誤發生以前，于是那段時間的單據都變成了正負相抵的垃圾數據而不叫錯誤了。這樣做也許是痛苦的，甚至已經不具備管理流程上的可行性（例如生産的産品已經出貨了，庫存還原不出來了）和成本上的可行性（數據量很大，數據很複雜）。但畢竟還是可以還原的，更壞的情况是出現例子裏的情况，金額數據到了完全錯誤的位置，沒法通過前端的動作復原財務系統的數據。這個時候要補救就有采用計算分析和一些非常規的做法，根據現有的經驗結合實際情况補救的方法還是具有一定的可行性的。 這種材料單價的錯誤（沒有按正確的順序還原）最終都是會引起成品或半成品（通過制令）的成本與製造方面的費用對調位置，無非是制令上材料成本（5011領料-回沖，5014報廢-材料科目，對于CP26買入半成品幷按MAP計算151階的還會出現5012半成品-回沖）多挂，最後在費用損益類科目（製造費用-小額價差，價差-PO vs 標準）裏倒沖，解决的辦法直接針對制令成本和相關費用及損益進行調整，恢復到正常的可接受的水平。 首先是調整制令中的成本，找到相關的價格有錯誤的order，由于MAP在不斷的變動，每個order裏面這個料的confirm成本可能都不一樣，計算出每個order裏這個料的成本後，開始逐單還原，當然簡單的方法是手動262（就只還原那個料的item，而不是整個confirm，因爲101産出的成品或半成品可能已經沒有了），每次還原前，到MR21直接將這個料的單價改成與要還原的order裏confirm時的價格一樣。每次還原前，都調整價格，會拋出5231評價-材料這個科目（如果半成品是MAP要調整，就爲5232評價-半成品），暫時不理會這個科目的金額，只管還原order。這一步做完，所有發生錯誤後制令裏面的這個料的數量與金額都被還原了，相當于這個料沒有被耗用過，當然如果有其他動作比如201發生過也一幷還原，這個時候再把價格調整爲正常的價格，把還原掉的數據再confirm一遍，每個order的成本就都正常了。因爲錯誤的入料已經在前面被還原重入了（否則也就沒有這些麻煩事了），所以不需要管入料的情况了，這個時候實際上order的耗料金額都是對的了，异動這一塊的金額都沒有問題了。回到FICO，在那筆錯上加錯的還原入料上有一筆巨大的倒沖費用的 製造費用-小額價差（或價差-PO vs 標準）而在還原和重新confirm order前調整價格又拋出很多筆 5231評價-材料（或5232評價-半成品），如果計算準確，你會發現這兩個科目的淨發生額應該是正負相抵的，當然由于筆數很多可能不完全一樣，但相抵的差額應該是個很小的數字，然後讓財務手工切傳票用 5231評價-材料把小額價差切平。至此，這場嚴重的數據“事故＂所造成的惡劣影響基本被消解了，說到底那些金額又回到了正確的位置。 其實補救之方法無非就是找到受影響的數據，通過其他的可操作的方法調整回來，這當然是沒有辦法的辦法，不到萬不得已不需要使用的，重點還是防患于未然，加强宣導，杜絕錯誤的發生，發現錯誤後不要隨意修改，而是多部門協調，做出合理的解决方案後再動手。其實我們大部分的系統作業都應該這樣的。 Zhou, Robert 2