SAP OMS2的物料類型對應的工廠沒有打勾

SAP OMS2的物料類型對應的工廠沒有打勾
??
如果沒打勾
沒警告:: OMS2的物料類型對應的工廠沒有打勾
警告是會出現"科目類別需要被指派".....


請教一下，有人有人在SAP ERP 可以在第三地英屬維京群島的公司工廠設定下，可以設定會計科目指派類別進行收貨"入庫"，透過協力廠商模式可以 (PO : X + S) 但是要用一般工廠模式去收是會出現"科目類別需要被指派"......(IMG 有關科目精靈自動指派都對過.....不知道V.G FI/CO的部分要注意哪部分...)

終於被我測試出來了,後續再跟大家分享在vg第三地公司如何收貨入庫

已經找到, OMS2的物料類型對應的工廠沒有打勾

ERP 國際商管學院促進協會

國際商管學院促進協會
維基百科，自由的百科全書

國際商管學院促進協會
（英語：The Association to Advance Collegiate Schools of Business），
簡稱AACSB或AACSB International，
是一個於1916年在美國創建的、針對世界各管理學院的認證NGO；
核心任務是推動全球商管教育品質的認證，
當前已經成為國際上最為權威且知名的大學商管學院與MBA認證機構，
學術地位崇高。

AACSB的初始會員校有（依據英文首字字母排序）
哥倫比亞大學、
達特茅斯學院、
哈佛大學、
紐約大學、
西北大學、
俄亥俄州立大學、
杜蘭大學、
加州大學柏克萊分校、
芝加哥大學、
伊利諾大學厄巴納-香檳分校、
內布拉斯加大學系統、
賓州大學、
匹茲堡大學、
德州大學、
威斯康辛大學麥迪遜分校、
耶魯大學。

Automatic Account Determination

Automatic Account Determination
=================================
2010.04.13.成立
=================================
Compiere -> ADempiere -> SAPiere
=================================

This is perhaps the part that causes the most heartache for the FI Configurer.
For some reason, although it is an integration area, the FI team always ends up with responsibility for it. To do a good job you need a reasonable understanding of :

1. the business processes in the source modules
2. the FI account postings that they should be generating (what sort of account should be debited or credited etc)
3. the organisation structure and its relationships between the source modules
4. the reporting requirements that are expected from the General Ledger or Profit Centre Accounting
5. your chart of accounts

Sounds daunting doesn't it ? Here is a suggested approach ...

The IMG section under GL / business transactions / integration will take you through all the necessary account determination for the automatic postings that the system may need to post. You may not need all of these.You could maintain on an as needed basis. As the project teams test or prototype their expanding functionality, the SAP system will look for the accounts to which it should post. The error message and the SAP documentation and configuration does not always explain clearly which piece of account determination is used for which type of functionality, so it is sometimes difficult to be pro-active.

Being reactive has the benefit that hopefully each side (eg: MM and FI) can develop an understanding of what the business transaction is and therefore where it should be posting. Otherwise the MM person may not even be aware that he has generated a certain type of posting ! (You'd be amazed at some of the lack of ownership from a logistics consultant for the financial postings that they generate).

I will be explaining each account determination area simply and clearly with posting examples

* SD to FI Account Determination (aka revenue account determination). This and MM seem to confuse people the most.
* More later - This may take a while to complete........

In the meantime, some general warnings:

* Whenever you change the field status settings for an account, ensure that you have verified that any automatic postings will be able to meet the requirements. EG: do not make business area mandatory if your system may make a posting which cannot determine and post the business area.
* Consider specifying that accounts that are posted to automatically can only be posted to automatically. This will simplify reconciliation between the source module and the GL account should you need to do this.

SD-FI Account Determination and Postings

This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc). This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger.

The integration is controlled both in SD and in FI.

In SD there is a awesome area of configuration called the pricing procedures. The pricing procedure determines the final price quoted to the customer for a particular product. This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc. These prices or charges are called 'condition types'. This condition technique is used in a number of areas of SAP.

For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys). You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:

* ERF freight revenues
* ERL revenues
* ERS sales deductions
* EVV cash settlement
* MWS sales tax

Now we start getting to the integration by mapping the account keys to GL accounts. But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to. The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!

So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc (Yes it is that 'condition technique' kicking in again. Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )

We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys".

The chart of accounts part is standard in all account determinations, so let us look at the rest. This access sequence allows us to specify different GL accounts for different Sales Organisations.

So if we had a billing document line item where the customer had some special deductions for one of the products he purchased, we could map accounts by Sales Organisation. To make it even simpler a document is within one Sales Organisation so we have an overall mapping as follows:
SD Line Item Condition type SD Amount Account Key Sales Organisation GL Account
1 Sales deduction for being such a nice guy $10 ERS 1000 800010 - Sales deductions for 1000
Sales deduction for special promotion on particular product $15 ERS
Base Revenue $200 ERL 800000 - Revenue for Sales Org 1000
Total for item 1 $175
2 Base Revenue $100 ERL 1000 800000 - Revenue for Sales Org 1000
Total for item 2 $ 100
Document Total $ 275

So the invoice that the customer gets (and that you can view in SD) will look something like:
Item (Note this is the SD Invoice line item) Amount
Item 1: $175
Item 2: $100
Total owing , 30 days terms etc: $275

The GL document posting that the system will make to FI will look something like this though:
FI Line Item Debit / Credit Account Amount
1 Debit (PK=01) Customer (AR Account) $ 275
2 Credit (PK=50) Revenue (GL Account) -$ 300
3 Debit (PK=40) Sales Deduction (GL Account) $25

Balancing to 0 as all GL documents must....
$0

Note : There is no direct relation between an SD Line item and an FI Line Item - they are different things.
Other considerations:

* Remember that if you are using business areas, then depending on your configuration there, the system may create additional FI line items if it needs to post to different business areas. This may be even more of a reason why you do not need additional GL accounts. If your Sales Organisations already map to different business areas, you could use the GL accounts for all Sales Organisations.
* Different access sequences will allow a broader variety of GL accounts (for example: by customer account) group. I strongly suggest having a good understanding of the reporting requirements expected to be supported from the General Ledger vs the SIS (Sales Information System) or CO-PA (Profitability Analysis) or (CO-PCA) Profit Centre modules before you create too many GL accounts. At the risk of repeating myself, the SD to FI account determination should only be as detailed as your statutory reporting requirements. The reporting from other tools like Profitability Analysis are so much more flexible and powerful, you may never look at the General Ledger for internal profit reporting again except to do a reconciliation check.

ERP SAP SD 配銷 會計科目

ERP SAP SD 配銷 會計科目
ERP SAP SD 配銷 會計科目
============================================
業務銷售的 出貨 作業 與 會計科目
During goods issue in the sales cycle,
the system is usually configured to update
the relevant GL accounts automatically
and to create the relevant accounting documents.
This customization in IMG is also called
material account assignment and is achieved
through a number of steps as detailed below:
=============================================
1. Determine ‘valuation level’ (Company Code or plant).
2. Activate ‘valuation grouping code’ and link it with the ‘chart of accounts’ for each ‘valuation area.’
3. Link ‘valuation class’ with ‘material type’ (FERT, HAWA, HALB, etc.) with the ‘account category reference’ (combination of valuation classes).
4. Maintain ‘account modification codes’ for ‘movement types.’
5. Link ‘account modification codes’ with ‘process keys’ (transaction/event keys).
6. Maintain a GL account for a given combination of ‘chart of accounts’+ ‘valuation grouping code ‘+’ account modification code ‘+’ valuation classes.’

The process of Automatic Account Determination is as follows:

1. Depending on the ‘plant’ entered during goods issue (GI), the ‘Company Code’ is determined by the system which in turn determines the relevant ‘Chart of Accounts.’
2. The plant thus entered in goods issue determines the ‘valuation class’ and then the ‘valuation grouping code.’
3. The ‘valuation class’ is determined from the ‘material master.’
4. Since the ‘account modification code’ is assigned to a ‘process key’ which is already linked to a ‘movement type,’ the ‘transaction key’ (DIF, GBB, AUM, BSX, etc.) determines the ‘GL account’ as posting transactions are predefined for each ‘movement type’ in ‘inventory management.’

ERP專案調研報告

ERP專案調研報告

一、 引言
1. 編寫目的
通過瞭解 TSMC（以下簡稱 TSMC）現狀，分析企業業務流程及管理之重點，
為BPI企業流程、明確軟體功能需求以及評估軟體二次開發需求而撰寫本文。
本文的讀者為專案的組織實施者、專案二次開發系統分析及軟體發展人員等。

2. 文檔背景
調研時間：2009年03月2日、3日共兩個工作日
調研地點：TSMC總廠辦公室
參與人員：TSMC MIS、TSMC 專案小組各成員、TSMC 總廠各部門相關人員
調研範圍：TSMC 總廠銷售、採購、工程、生管、倉庫、等主要業務的現行流程
3. 參考資料
A. 藍道科技ERP 系統文檔書寫規範
B. 系統總體進度表
C. 各部門提供的相關表單及文檔
二、公司概況
TSMC 總廠、二廠、及制三，總廠、二廠以五金衝壓及五金模具設計製造為主
三、現行業務流程說明
1. 銷售部門
總廠業務部門負責總廠、二廠以及製造三部相關業務部門工作，擔當與客戶溝通的視窗。
客戶關係管理
1. 公司客戶目前主要為日資企業，如先鋒、日立等，另一類客戶為利盟指定的二級客戶。但隨著公司經營，客戶數將逐漸增加。
2. 目前客戶代號兩碼，有些以客戶英文名稱中的兩個英文字母表示，有些以漢字首兩個漢字的拼音字母表示，沒有統一規範，有規範統一編碼的需求。
3. 目前沒有客戶分級管理，但手工有做銷售分析，分別按產品做營業額、毛利分析，按客戶做營業額、毛利分析。按產品類別（如DVD、車載等）分析營業額及毛利。
4. 目前客戶如先鋒，其有不同的出貨地點，如香港、深圳等。出貨及開發票時都會開不同的公司抬頭，在分析報表時也需要將同一客戶不同區域匯總。（因此建議客戶編碼時，將不同區域的客戶建立成不同的客戶，在客戶編碼時，將同一客戶不同出貨區域客戶編碼，在編碼上讓其排列在相鄰區域。）
5. 目前暫不存在總公司和分公司的客戶模式，即與分公司交易，與總公司結款的模式。
6. 目前沒有做信用額度的管控，因為幾個大客戶都是很穩定的，但有部分壞帳，有管控壞帳風險的需求。
報價
1. 新產品客戶詢價時，客戶會聯繫業務要求報價。
2. 新品報價後，可能有一部分產品不會在公司生產，只是工程品，在系統內只記錄其總價。還沒有正式品號報價時，系統需要有專用於報價的料號，此料號應能設定其可以更改品名規格，在報價時更改品名規格，為沒有正式料號的產品作報價使用。（關於工程樣板的報價，一般沒有零件規格尺寸只有材質，但是需要顯示其數量，單價和縂價值。部分情況下還需要模具費的報價）
3. 沒有正式生產前，報價都沿用客戶料號，正式生產後，工程會會編立正式的料號。
4. 目前對外有統一的報價單格式，因涉及到模具開發成本及生產批量、採購批量原因，報價時會有分量計價的需求。（分量計價指：不同數量範圍，單價不同）
5. 報價時需能記錄材質、模具價格、部品價格等。
訂單核價
1. 銷售價格基本上以每次的合同價為准，若客戶需要降價，會重新報價。不同的客戶有不同的價格，需分量計價。
2. 價格的調整沒有固定的週期，要求每次的交易價格可以回寫價格資料檔。
3. 降價後，有客戶對未交完貨的訂單，要變更為新的單價交易。或出完貨後，還未結帳的客戶要求變更為新的單價結算。
Forecast
1. 客戶每月給一次後三至四個月的需求。有些客戶不會給Forecast，但會提前一個月下定單給業務，但需求變更都很大。
2. 業務部門會以銷售計畫統計表的形式統計回饋給生管，每月統計，在18號前提交生管單位。
訂單建立
1. 訂單的來源為國內、國外客戶及制三，客戶以傳真或郵件方式通知業務，即使電話口頭通知，事後也會補單。
2. 業務以銷售計畫統計表通知生管，若有變更時，會另外以郵件方式通知生管。目前計畫變更頻繁，且緊急插單情況頻繁。
3. 訂單類型：訂單通常分為三種：
1) 一種：一部分客戶不下Forecast，但會提前將訂單下出，後以交貨排程來安排生產，此類定單一般不安排生產主要用於備料；
2) 一種是客戶下Forecast後再正式訂單通知業務，Forecast可以作業備料的參考依據，因Forecast變更較大，在此基礎上會有調整，生產則以正式訂單安排生產。
3) 還有一種是樣品訂單，和正式訂單一樣，樣品訂單也納入生產計畫由車間進行生產，在接單時一般可確定樣品訂單是否收款。（樣板訂單和量產訂單的單價會有不一樣的情況）
4. 訂單評審沒有專門的會議和書面的評審資料，但業務會以電話或郵件告知生管，主要由生管和其它部門確認客戶的交期是否可以達到，評審確認後即可轉為公司的內部訂單。訂單的簽核則由業務主管，再到副總簽字。簽完字後轉生管一聯。
訂單變更
1. 目前訂單變更的頻度比較高，變更的內容主要是調整數量和變更交期。
2. 客戶訂單變更時，有些強制取消，有些取消時會與業務溝通，有些已經做好，也有可能取消，中間損失的吸收需業務與客戶協定方案。少部分客戶會有簽字蓋章的文書郵件通知業務。
3. 訂單內部變更需求時，由生管提出變更需求，業務接到通知後與客戶郵件溝通。
4. 訂單變更時，廠內不發行訂單變更通知單，只以郵件方式通知生管。
出貨管理

1. 目前有一家客戶：旭麗，在出貨時不算銷貨，在客戶倉庫屬代管，客戶在自已倉庫領出使用後，以每月領出使用的量作為結算依據。

2. 樣品出貨，在現有系統內，一部分樣品從工程單位直接出貨，不入成品倉庫，系統內也不會有樣品定單。（現在的做法：因爲樣板要從工程出，所以業務就不能用正式的送貨單給客戶，只能手工做送貨單，然後用這份送貨單製作相應的發票，所以在月底對帳的時候系統中不能直接導出，而是需要手工將這一部分追加上去。 數量較大或者交貨次數較多時容易出現錯誤。 希望做法：因爲手板零件大部分是外發製作，厰内一般不會將其輸入系統。希望此部分可以在系統中用另外一種方式完成 注：客戶會提供料號或者品名）另一部分樣品入成品倉庫，需在系統內建立樣品定單，出貨時走正常出貨流程。

3. 出貨備品處理：現有一家客戶出貨時需要1％的備品，訂單和計畫內都不體現備品數量，只是在倉庫出貨時，倉管員多給1％。
4. 銷貨流程：
1) 業務部提前兩天開出貨通知單，出貨通知單上含嘜頭資訊，列印簽核，出貨通知單一式六聯，通知生管、業務出貨組、品質、成品倉、包裝等，倉庫接到出貨通知單後，安排出貨，並開立成品裝箱單。
2) 若出海外部分，業務需另開Invoice及Packing List。倉庫開立成品裝箱單後，轉交業務部出貨組，出貨組開立送貨單。並負責成品之出貨。國內客戶送貨單會簽回。

退貨管理
1. 退貨分為兩種情況：
1) 一種是產品出現品質問題需要退貨的，則由客戶先退貨，公司再進行補貨處理，有些產品客戶不需要重新補貨，只需沖銷應收款；
2) 另一種是實物不退回，如國外客戶，只是財務沖銷應收款或重新補貨處理。
2. 退貨時有些能核對到訂單和銷貨，有些無法核對。
若無法核對訂單及銷貨單的，沖銷應收款時則以最新交易單價扣款，補貨時備註退貨單號，能核對到訂單或銷貨單的，補貨時則需備註訂單號。
所有退回品必須經品檢後入庫。
3. 客退品經品管判定後，廠內處理時有三種情況，
1) 第一種：直接報廢，
2) 另一種先入庫，
3) 第三種則開立退回加工單返回生產線重工，再直接出給客戶。
建議以後走重工流程，生管開立重工制令。

2. 採購部
供應商管理
1. 目前公司共有供應商100家左右，目前供應廠商分為三大類：原料廠商、輔材廠商、模具廠商。
2. 供應商的編碼原則為3位元－XXX，第一位表示上面的三種大類，但有廠商會供應不同的產品時，不知道將其劃為哪一類，編碼比較混亂。
3. 供應商只根據供應材料的不同進行分類管理，沒有按地區或國家進行分類，原料會按材質、製造商（高爐廠）、供應商做統計分析。
4. 目前有每月進行供應商考核，月底按供應商交期、服務、及品管提供的品質狀況進行評核。
請購管理
目前公司不走請購流程（即不填請購單，生產用料不走請購流程）。

採購單建立
公司目前鋼材的採購方式是，一部分按照客戶Forecast及訂單評估後備料，一部分按單採購，一部分為客戶通知高爐廠後，高爐廠生產完畢通知 TSMC，TSMC 視情況提前採購，其採購來源主要為生管給出的物料需求表：
1. 採購週期：國內一般4-5個工作日，國外進口料件，若廠商有備庫存，採購週期在2個月，沒有備庫存的，至少需提前三個月。
2. 原材的採購有些客戶會指定高爐廠及供應商，採購料件需能追蹤高爐廠及供應商。客戶指定高爐廠及供應商的原材，建議在料號上做區分。採購單上需能體現料件的製造商（高爐廠）及供應商。
3. 有材料認可的管理需求，未經過認可的材料或供應商不允許下採購單。
4. 採購單目前會在現有系統內建立訂購單，不含價格，簽核完後提交廠商。另外以Excel檔的形式，做一份原材料單價表。但月底時還需另外手工列印一份訂購單，和以前訂購單內容一樣，只是會帶上單價，將此資料給香港。
5. 每月25號左右下單給供應廠商，次月初時再補不足量。
6. 試樣有部分不下採購單，實物可能經過倉庫，但不入倉庫帳。
7. 包材由倉庫寫物品需求單簽核後提交採購。物料採購各單位填寫物品需求單簽核後提交採購。
8. 採購簽核時分急件與非急件，急件須簽至財管即可進行採購。
採購變更
1. 目前採購單變更沒有規則，生管提出變更需求，由採購與廠商協商。
2. 採購變更時，需另外列印採購變更單，簽核完後傳真供應廠商，但小宗交易變更時，則沒有列印採購變更單，只是在原訂單上文字說明，主管簽字後即可。
========
採購進貨
========
1.
除原材部分允許10%的超交外，其它不允許超交，
但有些因生產問題，也有超過10%也需要收貨，
此部分一般在發採購單與供應商溝通時就已知道，
會郵件聯絡各單位，
建議此情形若在下單階段就知道，須變更採購單。
>>>>>>>>>>>>>>>>>>>>>>
>>另外需要超交標準設定
>>另外專案超交標準設定
>>>>>>>>>>>>>>>>>>>>>>


2.一般允許分批交貨，而且包裝材料必須按實際生產進度需要另做交貨排程通知供應商交貨。
3. 採購進貨時，由廠商填寫 TSMC 格式的送貨單，將實物送至總廠收料中心，由收料中心、倉管收料員、品管負責收貨。其流程為：
1) 原料倉在實際材料上貼卷號條碼標籤（卷號指每卷材料或片材每包裝，為品質追溯的需求，須每卷材料都進行不同的編碼，並在保存、後繼生產、出貨等過程中進行正向和反向追溯而編此號），
2) 收料中心檢查送貨單與實物是否相符，原料倉開立原材料採購入為單。品管負責檢驗。在入庫時卷材須能記錄料號、卷號、重量、高爐廠、供應商、訂單號、進貨日期、母材、捆包號(即供應商卷號)等。
3) 片材須能記錄：料號、卷號、片數（需默認包裝片數，但允許用戶自行修改：如尾數）、重量、高爐廠、供應商、進貨日期、母材、捆包號等。
4) 後續為管控先進先出，則須按照入庫日期管控領用，按卷號做品質追溯。

4. 目前原材70%--80%料件為客戶指定高爐廠、及供應商，另一部分則不同供應商及高爐廠的同規格材料可以互相替代使用。
在料號編碼時，建議：客戶指定原材之高爐廠及供應商的，料號編碼須做區分；不同供應商及高爐廠同規格材料或以互相替代使用的，則料號編碼須編同一料號表示。
若同一高爐廠之不同供應商材料可以替代使用時，則料號編碼時只需將高爐廠作區分，不區分供應商。

採購退貨
(1). 品質有問題時，品管會驗退。
(2). 倉退時有兩種處理方式：一種是實物退回，必須有 退貨單沖銷對應的進貨單，此退貨一般需要補回；另一種是由供應商換貨，不扣貨款。
(3). 單據處理上由倉庫建立退貨單，對帳時由採購查詢單價。若需重新補貨時，則按原退貨單號補貨，不沖銷以前訂單的已送貨數量，也不另外開立新的PO。

3.倉庫管理
(1).目前總廠倉庫分為：原材倉庫、包材倉、成品倉、模具物料倉、外發虛擬倉、二廠對應原材、包材、成品倉。
(2).實際倉庫有劃分區域管理，為方便實物管理，快速存、取貨物之用。
(3).目前都是環保料件，以前有環保與非環保交替的情形出現。若以後再有此類狀況，建議在料號上作區分。

4. 批號管理：目前原料和成品都需作先進先出管理、保質期失效期管理以及後續追蹤處理。

5. 可回收包裝箱在管理時，由包裝產線開領料單至倉庫領料，接著入包裝後的成品至成品倉庫，再發貨給客戶，發貨給客戶後需要管控周轉箱的回收。倉庫人員想知道，公司現有多少可回收周轉箱，這些周轉箱都在哪些地方。因為目前沒有管控包裝產線入到成品倉的數量，所以無法知道周轉箱存放的地點。

6. 盤點管理：現在兩種盤點：月盤及年終盤點，月盤為倉庫自行盤點，
1） 月底盤點時，產線也需要清線，帳務部分做虛擬退倉，實物不做退庫。
2）年終盤點則會列印盤點卡及盤點清冊。原材料不允許出現盤差，其它有盤差時，目前沒有盤差調整申請流程。
7. 報廢流程：目前生產線自行填寫報廢單，經品管判定及相關人員簽核後，報廢至倉庫。至倉庫後倉庫需另外再重新填寫報廢單，重新走報廢流程。
8. 資材課下設委外發中心，所有托外加工部分都由外發中心管理。
9. 系統需求：目前倉庫沒有進行ABC管理、沒有做迴圈盤點管理、呆滯分析，但有做ABC管理、迴圈盤點管理、呆滯分析的需求。
4. 工程
產品工程資料：
1. 目前成品、半品、原材都以客戶料號為主。經前階段討論，未來將對材料進行重新編碼，原材編碼建議參見採購說明。成品以客戶料號編碼，半品以客戶料號加工藝識別碼識別。
2. 產品BOM並不複雜，為管控生產進度，將以BOM斷階及工藝管理結合進行管控。如下圖結構示意圖：



3. 新品報價時，業務發圖面給設計和工程，由設計課報模具、材料、設備加工費用，貼紙、鉚軸、捆包須工程課出相關圖面給採購詢價。報價階段都沒有正式的料號。
4. 下了樣品定單的都會由生管開立物品需求單，手板則由業務部開立需求單工程審核後交由採購處理。

新BOM建立流程
1. 對於新產品，業務發出圖面，設計課根據設計開立原材料需求表給工程，工程課在系統內建立料號及BOM相關資料。
2. BOM表內不會標明產品加工工藝，但在QC控制圖內會標明產品相關工藝。
3. BOM表內材料有一部分為治具，在BOM表內只作標示，其領料碼應設置為不發料，另有一些可能為客戶供給的材料，應定義為客供料。後期計算成本時，客供料雖然發料，但不計入直接材料成本。
4. BOM經簽核後發行。
ECN變更流程
1. 客戶設變後，有發行工程變更。目前有出現變更後，因現場或在庫沒有及時清理，出貨匯入舊版一起出貨。
2. 工程課反映設變後延誤通知工程，有些三次元了才通知工程，變更通知單發行比較滯後，造成流程上混亂。建議重新協定變更流程。
3. 若需變更供應商，則須採購開立原材料試樣申請單，工程再試樣。
5. 生管部門
計畫制定
1. TSMC 目前的生產模式屬於接單式生產，生產計畫基本來源於客戶正式訂單，部分材料根據銷售預測作為參考，參與人為經驗調整後進行備料。
2. 生管制定生產計畫排程以月為單位，每月23號左右排出生產計畫及備料計畫，次月初有變更時，則會以郵件方式發急件通知變更計畫。有些大訂單分批次下生產計畫（開立制令時需要能有工單拆解功能，分批次進行工單生產追蹤）
計畫發放流程
目前沒有明確開立制令，以月度生產排程為准，後繼則須開立正式製造命令單，以便追蹤生產、核算生產成本。生產計畫無法直接利用客戶Forecast及訂單作為計畫來源，變異性很大，也不完全是有訂單才生產。
計畫變更作業
計畫變更較為頻繁，變更需求主要來自客戶訂單變更，其次來自生管的變更，變更一般以郵件方式溝通，不另行發變更檔。
6. 生產部
按照生管發放的月生產計畫及急件通知安排生產。總廠生產部包含：衝壓課、加工課、包裝課。

生產領退料
1. 生產線有專人負責領料，一般架模具時領料。
2. 生管排生產計畫及急件通知都會給倉庫和生產，生產線按照排產計畫自行開立領料單至倉庫領料，倉庫按照排產備料。但無法核算工單用料，無法管控超領。在領料時，需按工藝分工作組各自領料。
3. 原材領料須按先進先出規則管控領料，領料單上須顯示與入庫單相似的資訊，即：料號、卷號、材質、母材、供應商卷號、重量等相關資訊。
4. 有些卷材無法分割按工單領料，只能整卷整卷髮料。可以使用用產線倉庫自動扣料功能，或退料模式，若採用退料模式，則須及時退庫，否則做計畫時無法知道領用未使用完，還有餘料。
5. 目前發料時，不會考慮用料的合理損耗。
6. 超耗領料：生產部自行開立原料領料單，簽核後至倉庫領料，超領時生管另外開立慮擬的制令，為超領開單使用。建議以後以制分析管控領料及超領。
7. 挪料：一些共用料件會挪料，挪料時未辦相關手續，不走單據。
8. 一部分原材領幫至產線拆裝後，長期露置在空氣中，會對產品品質有影響，也有保質期管理需求。
生產線報廢
生產線填寫報廢單，經簽核後入到倉庫，倉庫再填寫相同的報廢單，重新簽核一次才算正式報廢。在產線報廢時，量小由各生產課自行報廢，量大時，統一交由包裝部統一填寫報廢單報廢。
生產報工
1. 衝壓生產線每班填寫個人生產日報表，需登記機台編號、日期、班次、機種、料號、原材供應商、供應商卷材編碼、重量、加工數、調模報廢、料頭料尾報廢、衝壓報廢、完成良品數、時間、時數、模具裝況、及衝床時間使用狀況。
根據輸入的生產日報表產生衝壓產能統計表，作為早會開會的依據。必當日早上8：30天早會前看到昨天的生產資料。
2. 加工生產線每班填寫：個人攻牙日報及個人鉚軸生產日報，現有系統內只錄入統計攻牙工序日報表。
3. 現在生產入庫未按制令入庫，未來若需要產生成本資料，須按工單收集工時。

委外加工
1. 委外加工廠商的管理由倉庫委外中心執行，目前沒有設立供應商倉庫管理外點庫存，外發產品也沒有入到實際倉庫後發出，而是在產線暫存區域直接外發給委外廠商。
2. 委外也沒有委外加工制令，只有相應的發料及回收單。這種方式不利於委外核銷及委外用料分析。
3. 加工費用由委外中心與委外加工廠商對帳。

四、總結

以上只是對現行各個部門業務流程初步的瞭解，隨著專案的展開和深入，將會有更細緻更具體的瞭解，同時也將發現系統操作面和功能面與 TSMC 當前運作習慣的差異，因此建議在項目的實施階段，本著使用系統現有功能至最大程度為首要原則，必要時才進行適當的二次開發，保證項目能按照計畫進行並順利上線。

ERP 看到 Yeh 教授

ERP 看到 Yeh 教授!!

如何把ERP的導入和使用成本壓到最低？
丹尼爾一邊開車一邊想著。
>>
>>為什麼 ERP 導入要顧問
>>因為要幫你設定企業管理流程
>>因為要幫你設定對應會計科目
>>因為它無法記錄系統
>>取得會計科目的路徑
>>供使用者參考修正用
>>
>>教你管理
>>教你會計
>>教你系統
>>幫你客制化
>>你收顧問費每小時2500元
>>我收技術轉移每小時800元
>>??



ERP導入顧問費在台灣至少每小時2500元，
而中小企業彈性大，商務流程各不相同，
ERP常要客製，所以產品費、顧問費、
客製費加起來起碼要數百萬元，
中小企業負擔不起。
上線後的使用成本更高，
每年18%至22%的維護費、伺服器的費用、
以及要聘請一位或數位IT人員維持日常ERP運作，
這也是中小企業負擔不起的。

丹尼爾的學術背景使他想到，
能不能將SOA-ERP融入學校課程有系統的訓練
「學生顧問」並以「社會企業」的方式對中小企業提供服務呢？

ERP顧問需要多年的培養，怎麼可能用學生當顧問？
而且，為什麼用NEO結合學校課程而不是其他ERP系統？

ERP 以前用SAP

>>這是明明需要有一個作業稱作 << 修正發票 >>
>>SAP 也不對為何要<迴轉物料>
>>現在你的系統也不對 <消退,原發票作廢,重打一張應收帳款單,
>> 自行輸入原銷貨單號,做一張出貨單,手動輸入應收帳款資料,並且載明原始出貨單,重新出發票>
>>明明就是需要一個<< 修正發票 >>作業
>>

ERP 資通加油 不錯的軟體公司 有 ADempiere 水準

ERP 資通加油 不錯的軟體公司 有 ADempiere 水準

如果你愛台灣
400萬的台灣商用軟體
與
不用錢的 OpenSource 歐美共構
你會用哪一種!!
愛台灣請用愛心
購買台灣產品


令人愛不釋手的 ERP 底層架構

文 - 楊振源

首先還是分享一段冷笑話。
話說某日一位顧問到客戶端導入系統， MIS 問他：『 我用過4套 ERP 系統，每一套都有XX功能，為什麼你的系統沒有這個功能？ 』，該顧問回答：『 因為這是第5套。』

現在與各位分享傳說夢幻中，令 IT 人員愛不釋手的第 6 套 ArgoERP 系統的底層架構：

WEB 架構
透過 Browser ( IE / Firefox / Google … ) 就可以 RUN ArgoERP，沒有地點的限制，也沒有安裝 Client 端程式的負擔。

多語系架構
同一套程式執行碼，提供正體中文、簡體中文、英文… 等多語系架構，不會增加 IT 維護系統的額外負擔。系統 Prompt 可按需求自由設定調整，例如 “ 料號 ” 可自由調整為 “ 商品編號 ”。

多時區架構
Centralize DB 於總部統一管理，以簡化 IT 維護人力。可設定時區管理，由歐洲、美國、日本…等地連線回總部共用 DB 系統，但又各自保有該地區正確的時間。例如台灣 1 月 1 日，美國可是 12 月 31 日。

多公司架構
同一套 DB 之下的多公司架構，程式與資料庫只需要維護一套。設立一家新公司只要 30 秒鐘。跨公司基本資料彈性發佈，集團公司多角貿易資料拋轉、集團合併報表拋轉。

可依資料歸屬授權的架構
同樣有銷售訂單的執行權限，但是 A 就是看不到 B 的資料。比如 A 員管理倉庫 WH1、WH2， B 員管理倉庫 WH3、WH4，則可限定只可以看到自己所管理的倉庫資料。

可依程式欄位授權的架構
程式區塊 / 頁籤 / 欄位 / 按鈕 …等等元件，可以依照每位員工或群組授予各種權限。如此則可以免除一些不必要的程式客製。尤其對於成本 / 單價 …等等業主關心的資料安全問題。

與異質系統接口的架構
從基本資料如料件 / BOM / 客戶 / 廠商 …到開帳資料如應收 / 應付 / 傳票…再到交易資料如訂單 / 出貨單…等等，提供一系列異質系統資料介接的入口與API，有效整合或同步異質系統的資料。如 PLM 的料號或 BOM 透過介面 API 自動匯入 ArgoERP 系統，客戶的電子訂單透過介面 API 自動匯入 ArgoERP 的訂單系統。

預警功能的 ERP 架構
可以自行 SQL 設定警訊的條件 / 傳送資訊 / 收件人或群組…等等，於事件達到警示條件時，即自動發出 e-Mail 或簡訊通知相關人員。例如交期延誤一天通知課長，延誤兩天通知經理，延誤三天通知總經理…等設定。

可匯出 EXCEL 套範本的架構
凡是 ArgoERP Form 上面查詢得到的資料都可以匯出 EXCEL ，甚至匯到事先已建立好的套印範本，如 Invoice / Packing List 範本，或事先已建立的樞紐分析表範本。以增加資料彈性運用的空間。

俗話說，人對了，事情就對了。同樣的，選擇一套底層架構對的系統，你的 ERP 已經成功了一大半。根據中華企業資源規劃學會 ( CERPS ) 論文研究指出，讓使用者喜歡的 ERP 系統是確保導入成功的關鍵因素之一。

>>回電子報首頁

平均滿意度：5.00 / 總人數：3

您對這篇文章的滿意度：非常好

ERP 畫面複製 到底哪些不該複製 欄位複製設定篇

// fill data
if (copyCurrent)
{
boolean hasDocTypeTargetField = (getField("C_DocTypeTarget_ID") != null);
Object[] origData = getDataAtRow(currentRow);
for (int i = 0; i < size; i++)
{
GridField field = (GridField)m_fields.get(i);
String columnName = field.getColumnName();
if (field.isVirtualColumn())
;
else if (field.isKey()
|| columnName.equals("AD_Client_ID")
//
|| columnName.startsWith("Created") || columnName.startsWith("Updated")
|| columnName.equals("EntityType") || columnName.equals("DocumentNo")
|| columnName.equals("Processed") || columnName.equals("IsSelfService")
|| columnName.equals("DocAction") || columnName.equals("DocStatus")
|| columnName.equals("Posted") || columnName.equals("IsReconciled")
|| columnName.equals("IsApproved") // BF [ 1943682 ]
|| columnName.equals("IsGenerated") // BF [ 1943682 ]
|| columnName.startsWith("Ref_")
// Order/Invoice
|| columnName.equals("GrandTotal") || columnName.equals("TotalLines")
|| columnName.equals("C_CashLine_ID") || columnName.equals("C_Payment_ID")
|| columnName.equals("IsPaid") || columnName.equals("IsAllocated")
// Bug [ 1807947 ]
|| ( columnName.equals("C_DocType_ID") && hasDocTypeTargetField )
|| ( columnName.equals("Line") )
)
{
rowData[i] = field.getDefault();
field.setValue(rowData[i], m_inserting);
}
else
rowData[i] = origData[i];
}
}

ERP 如何大量客製化 ??

大量客製化的條件是什麼？
ERP如何大量客製化？

>>大量客製化的第1個條件，產品必須模組化。
>>也就是說，產品必須由數個模組構成，
>>而模組與模組之間必須有標準化的介面。

大量客製化本身是大問題 ??
應該是顧問可設定導向 !!