如果引用或轉貼,麻煩註明出處與本網誌連結,否則視為侵權。
顯示具有 ERP 標籤的文章。 顯示所有文章
顯示具有 ERP 標籤的文章。 顯示所有文章

2011年11月8日

SAP MRP時間計算之一 : 外部採購物料的MRP時間計算

 

原作時間 : 2000/4/7 作者: Fred F.M. Wang

image

說明:

1. 本時間計算方式適用於物料的採購類型為F(外部採購)的料號(請見物料主檔MRP 2 view)。

2. lead time offset(前置期偏移 by 工作日): BOM上層組件(成品or半成品)的order start date的偏移值。正值表示該元件在製造開始後才有需要,負值表示該元件在製造前就應備好。因此元件的MRP date(requirement date) = 上層組件的order start date + lead time offset。BOM元件項目的明細內維護

3. Goods receipt processing time(收貨作業處理時間): 在物料主檔的採購view中維護。

4. Planned delivery time(計劃交貨時間): 若該物料有多家廠商,請設平均值。在物料主檔的MRP 2 view中維護

5. Purchasing department processing time(採購處理時間): 採購文件所需的處理時間,依不同廠別在Customizing設定(txn:OPPQ)

6. Opening period: 為MRP controller將planned orders轉成PR or production orders的buffer time,例如,物管人員三天開一次PR則opening period應設為3(選排程臨界碼000)。在執行MRP前,將MRP控制參數”建立請購單”設為2(未確定期間的請購),執行後planning open date落在planning date及planning date前的planning orders會自動轉成PR,例如,4/6日run MRP則order start date在4/6未來三天的planning orders均會自動轉成PR。僅在Backward scheduling有用。在物料主檔的MRP 2 view中的排程臨界碼維護,排程臨界碼在Customizing設定

7. Backward scheduling: MRP類型屬於MRP或forecast-base planning(PD,VV)均採此方法計算。由物料的requirement date(MRP date)往前推算order release(start) date,order finish(delivery) date及plan opening date。(註: MRP類型請見物料主檔的MRP 1 View)

  • Order finish(delivery) date = MRP date - GR processing time
  • Order start(release) date = Order finish date – Planned delivery time – Processing time for purchasing
  • Plan opening date = Order start date – opening period

若計算出的order start date落在過去則系統自動會切換成Forward scheduling 計算。(也可依廠別在Customizing設定即使order start date落在過去也不自動切換成forward scheduling, txn:OPPQ)

8. Forward scheduling: MRP類型屬於再訂購點方式(VB,VM)均採此方法計算或Backward scheduling計算時,order start date落在過去則系統自動會改成Forward scheduling 計算。以planning date為order release(start) date往後推算及order finish date及MRP date。

  • Order finish(delivery) date = Order start date + Planned delivery time + Processing time for purchasing
  • MRP date = Order finish date + GR processing time

 

相關內容 :

2006年9月14日

轉貼SAP:ERP軟件在2010年前不會進行重大升級

【賽迪網訊】9月14日消息,SAP正在吸引用戶和開發人員釆用其新產品和NetWeaver SOA戰略的計劃。然而,在2010年之前,SAP的ERP軟件還不會進行重大的升級。

SAP產品和技術事業部總裁Shai Agassi星期二表示,今年6月份推出的“mySAP ERP 2005”軟件是SAP軟件的核心。這個核心的軟件在未來五年里不會更新。不過,SAP會對這個核心軟件進行一些修改,例如,通過每個季度或者每兩個季度 發布一次的增強數據包增加一些新功能和垂直市場的混合應用程序。

Agassi在拉斯維加斯舉行的SAP的TechEd會議的開幕式上對開發人員、合作伙伴和客戶許諾說,“mySAP ERP 2005”軟件從現在開始將使用很長時間。

“mySAP ERP 2005”被認為是全面實施SAP的“NetWeaver”戰略的第一個軟件。這個戰略是使用Web服務把SAP傳統的模塊和堆棧轉變為一個模塊或者開放 的架構。業務經理可以對這些模塊或者開放的架構進行客戶化處理。開發人員也可以擴展這些模塊和架構。

自從2003年以來,“NetWeaver”一直是SAP的夢想。SAP一直在其軟件中嵌入必要的Web服務編程接口,把SAP的軟件轉變為合作伙伴和客 戶能夠作為面向服務的架構的一個平台。ERP是“NetWeaver”戰略的重要組成部分。因此,用戶和合作伙伴放棄老版本的SAP R/3軟件甚至“mySAP ERP 2004”軟件對於SAP來說是非常重要的。

為了鼓勵用戶升級新的軟件,Agassi介紹了SAP現有的服務和為用戶提供幫助的新工具。他說,2007年是你們建立、發布和使用我們自從2003年以來給你們的全部信息的一年。這次會議是你們提高水平的一個機會。

Agassi在這次會議上還發布了對開發人員和企業經理使用“NetWeaver”和“mySAP ERP 2005”軟件提供支持的技術和計劃。

-------------------------------------------------------------------------------------

像這樣大型的系統, 太快的改版, 用戶根本無法跟隨, 改版所要花費的不只是金錢, 人力, 時間, 技術學習, 使用者變革管理等等, 而使用者要的只是完成商業行為, 如何說服企業老闆投入這麼大的成本, 必須要找出足夠的效益, 這些效益是可以將花的成本賺回來的! -- Fred

2005年9月26日

實作ERP系統時料號編碼策略問題探討

在導入物料管理系統時,往往會有料號編碼原則的問題,要將料號賦予意義的編碼原則還是用系統自動產生沒有意義的編碼? 下面是一個CPIM專家的回答 :

實作ERP系統時料號編碼策略問題 :
. What part numbering strategies have other companies employed during implementation of an ERP system?
. Why was this strategy chosen?
. What problems arose during implementation because of this decision?
. If you were to do this all over again, would you make the same decision?

顧問解答如下 :
This issue comes up in most ERP implementations. I have had this discussion with almost every company that I have been involved with. My recommendation would be the same as your SAP consultants. No matter how much or little intelligence you put in your part numbers you will run out of numbers some time. Or your business will change enough that your part numbers don't mean as much as they used to. SAP has a good solution to this problem. Let SAP auto-generate your part numbers and use Classification to classify the numbers into the groups that you want. You can then build reports or search queries to find the part number or groups of part numbers that you want. SAP also has "material groups" that you can assign to a group of part numbers. This would be like a commodity code.
By using classification you also help eliminate the possibility of having two part numbers for the same physical part because you could not find the part number and just created a new one.
During implementation the problem is that you have to retrain people to not rely on the part number and that they should rely on the description to identify the physical part. Descriptions have to be very specific using Noun, Adjective, Adjective, etc.
Another thing that I have seen is that in the storeroom or warehouse people try to put the inventory in part number order. This might be of some help when trying to find a part number but it is very inefficient for storage space. You should use a part locator to store material and not the part number sequence.
Would I do it again?? Without a doubt I would use system generated part numbers.
這個問題發生在大多數ERP導入過程。我幾乎跟每一個參與導入的公司有過這樣的討論。我的建議跟一般SAP顧問一樣。無論您把公司的料號編碼加入多少智慧(意義),執行一段時間,號碼就會用完。或者是因為業務的改變,造成料號編碼的原則已經不敷使用。
 SAP對這個問題具有很好地解決方法。讓SAP自動產生料號並使用Classification來進行分類分群。您可以建立報表或透過搜尋,找到需要的料號或料號群組。 SAP還有“material groups(物料群組)”,你將它指定給料號。就像一個商品代碼,藉由分類可以避免相同實體料件,建立了兩個不同的料號。

在導入過程中的問題是,你必須訓練同仁,不要再依賴於料號編碼,讓他們依靠的料號的描述,了解物料的實體特性。這個描述必須要非常具體的使用名詞,形容詞,形容詞等。

我曾看過在儲藏室或倉庫的人試圖把庫存以料號來排序。這可能有助於找到一個物料,但對這種方式對存儲空間是非常沒有效率的。而應該使用"料號定位碼"(part locator),來存放物料,而不是料號的順序。

毫無疑問,我會用系統來自動產生料號。

Steve Blair CPIM
Quality Systems Consulting

感想 :
料號採系統自動編碼機制? 也就是無意義的料號編碼! 但是在實際的生產及倉儲人員卻無法透過無意義的編號進行溝通, 因此生產及倉儲人員透過另一種方式描述料號, 但是必須有良好的管理方式及嚴格的轉換機制, 否則容易造成錯誤. - Fred Wang

2005年3月28日

Drop Shipment流程的技術方案 - SAP平台範例

Drop Shipment流程的技術方案(外包商直接出貨自動扣帳處理)

Fred Wang (http://fredwang.blogspot.com) 2005/03/28

Drop Shipment略過自己的倉庫,直接由供應商送貨到客戶。如此可以節省倉儲管理成本及運輸成本等。

大致的流程如下:
1. 生管人員通知外包商出貨。
2. 外包商將出貨資料傳回。
3. 人工或自動將資料轉成ERP所需的格式, 然後上傳到ERP, 完成出貨扣帳動作。
4. 貨直接從外包商出貨到客戶。.

其中第3點, 以下我提供三個方向, 困難度及適用範圍均不同, 供大家參考 : (ERP以SAP為例)

方法一: 檔案傳輸
步驟 :
1. 給外包商一個FTP server address, 讓他們存放此類檔案
2. 用ABAP寫一支程式執行FTP get抓取FTP server中的檔案, 然後轉成internal table再trigger SAP batch input program, 完成出貨扣帳動作。
此法做法較簡單

方法二: 網頁輸入
步驟 :
1. 提供外包廠一個web site 進入點, 輸入id/password後填寫web form
2. 按[submit]後trigger Java program 透過介面程式(如JCO)啟動SAP batch input程式
這一般是針對小廠, 自動化系統不足的狀況才提供的輸入介面

方法三: b2b exchange
步驟 :
1.運用b2b軟體(SAP connector, 用webMethod的技術)進行資料傳遞(format: XML)
2.用SAP adapter 啟動SAP batch input程式
這種方法用在大廠, 雙方有密切的流程依存關係, 可用B2b軟體監控流程, 不過需要對方配合安裝B2B軟體(client side)

2005年3月18日

ERP模組介面設計說明

作者 : Fred Wang 原作日期1999.09.05 (http://fredwang.blogspot.com)

由於ERP模組間有許多關連性,ERP系統應有整合性的設計以發揮ERP系統的效益,一個ERP系統設計團隊應多留意此部份。在此謹介紹幾個主要的模組間的介面, 如採購系統, 庫存系統, 會計系統, 銷售系統及生產與控制系統。
各個模組間的介面說明如下頁:
觀念: 模組間應該用傳 message的方式啟動對方模組s 系統功能寫入或傳回所需資訊,不需知道對方模組在什麼table及什麼欄位。

說明:
1.  (採購系統-庫存系統)PO單據開立/刪除: 將自動變更庫存現況檔的在途量,且成為驗收入庫單的參考憑證。
à 設計上可考慮自動產生( or  合併檔案)
à 庫存系統應設計一個系統功能, 提供給採購系統起動庫存現況檔的在途量的自動變更。
à 若自動產生驗收入庫單則庫存系統亦應設計驗收入庫單的自動產生。
à 採購系統應提供系統功能以傳回PO data(input: PO no., output: 項次,料號,數量,單價等)

2.  (採購系統-會計系統)一般財產驗收確認: 若輸入發票號碼,確認後將自動產生進項發票記錄, 若驗收時無發票, 則需至進項發票維護功能輸入。(由會計單位確認發票後,才自動轉會計傳票)
à 會計系統應設計一個系統功能提供給採購系統起動進項發票的自動產生。

3.   (銷售系統-庫存系統)出庫通知單開立/刪除: 出庫通知單為銷貨出庫單的參考憑證。
à 設計上可考慮自動產生 or  合併檔案。
à 若銷貨出庫單自動產生則庫存系統亦應設計銷貨出庫單的自動產生。
à 銷售系統應提供系統功能以傳回出庫通知單data(input: 單號., output: 項次,料號,數量,單價等)

4.  (銷售系統-會計系統)銷售Invoice開立/取消: 自動產生會計傳票(應收帳款-銷貨收入 or 銷貨退回-應收帳款, 應收帳款,銷貨折讓-銷貨收入等)
à 會計系統應設計一個系統功能 提供給銷售系統啟動會計傳票的自動產生。

5.  (庫存系統-會計系統)入出庫異動確認: 自動產生會計傳票(銷貨成本-庫存)
à 會計系統應設計一個系統功能 提供給庫存系統啟動會計傳票的自動產生。

6.  (庫存系統-會計系統)原物料驗收入庫確認: 若輸入發票號碼,確認後將自動產生進項發票記錄。若驗收時無發票, 則需至進項發票維護功能輸入。(由會計單位確認發票後,才自動轉會計傳票)
à 會計系統應設計一個系統功能 提供給庫存系統 啟動進項發票的自動產生。

7.  (銷售系統-生產計畫與控制系統) : 可以由銷售預測來自動帶入生產計畫

8.  (生產計畫與控制系統-採購系統)Create PR via Planned order:
à 採購系統應設計一個系統功能提供生產計畫與控制系統啟動 PR的自動產生。

9.  (生產計畫與控制系統-庫存系統)Create生產領料單via Planned order:
à 庫存系統應設計一個系統功能提供生產計畫與控制系統 啟動 生產領料單的自動產生。

10.(所有的系統-庫存系統) 料號主檔查詢
       à 庫存系統應設計一個系統功能提供其它模組所需料號的基本資訊,如品名、單位、總分類、中分類等。(Fred)

11.(所有的系統-庫存系統) 現有庫存量查詢
à 庫存系統應設計一個系統功能提供其它模組所需庫存的資訊,如廠別、倉別、儲位、庫存量、在途量等。

如何加速建構一個整合性良好ERP系統

如何加速建構一個整合性良好ERP系統
Fred Wang (http://fredwang.blogspot.com)
1999.09.05

由於ERP系統模組繁多, 功能複雜, 傳統開發ERP系統的團隊只能因客戶需求, 以分工的方式逐一將模組一一建立起來, 但是往往造成系統整合性不佳, 開發速度緩慢, 無法共享程式, 標準不一致, 版本控制不良。
就上面的問題, 如何加速建構一個整合性良好ERP系統的構想,提出一些策略作法:

1. 首先應整理、訂定ERP標準或合理的商業流程

2. 系統Tables與功能, 應依照ERP標準或合理流程來設計: 可以有整合性的考慮、共用性較佳,且可避免為客戶所誤導。(完成一套後,不必再修改或修改程度最低,減少開發的人力時間成本)

3. 功能模組及子模組標準化及庫存化: 包含使用者介面(UI)元件, 系統功能及文件, 製作標準模組功能型錄,提供給users選擇。(若有不足再進行客製化程序, 減少客製化UI的成本及協調討論規格的時間)例如: 入庫申請作業有兩套做法, 兩組標準UI forms, 供users選擇。每個module的功能及Forms會在不同的專案後累積,應編製功能型錄,Forms型錄等以利再用。

4. Parameterized(參數化) : 將基本設定及可調整的參數及組態設定獨立成參數設定系統,不同公司或產業有自己的一套Profile。亦可將參數設定智慧化,以問卷方式快速完成設定。例如: 入庫申請作業,不同的客戶用相同的Form,但item欄位不同,可建立一個基本設定功能: 欄位選擇,除必要的欄位外可自由選定要顯示的欄位。

5. 共用功能元件化及庫存化管理: 累積智慧及經驗,加速Coding,減少maintenance time。製訂標準函式Naming rule及註冊程序以集中化管理。

6. 開發步驟標準化
建立”ERP系統開發程序”標準

7. 建立完整的開發樣版

8. 加強工具的開發:
例如:
建立或採用好的Query tools, Reporting tools
提供Download to Word or Excel formats
建立整合性的開發環境,如版本管理, Data dictionary workbench, UI development workbench等。