- BOM: ルーティングプロセス ルート
アプリケーション: 部品表
責任: 部品表
要約すれば
ルーティング (プロセス ルート) は、生産プロセスにおける処理順序、リソース、使用方法の標準化の問題を最終的に解決します。精度は 98% 以上である必要があり、徐々に 100% に到達するにはシーンと比較し続ける必要があります。
BOM と同様に、ルーティングも製造企業のビジネス主導のコアであり、WIP、OPM、COST、MPS/MRP などはルーティングに基づいて直接実行され、安定した明確なルーティングがなければ、ERP はありません。
工順は、製品/半製品の生産工程図であり、特定の材料を生産するためのプロセス、処理部門 (ワーク センター)、リード タイム、消費されるリソース、およびそれらの定格数量を定義します。
「自転車の組み立て」を例にとると、その予定工程経路表は次のとおりです。
そのうち、960001 は 3 つのプロセスを経ており、最初のプロセスである「組立センター」では、2 つのリソースが組み立てに使用されます。
ルーティングの保守と変更には、実際には少なくとも次の部門が関係します: 技術部門/R&D センター、企画部門、製造部門、および財務部門。
Oracle でのルーティングは、技術的な意味での標準的な構築ステップであるだけでなく、人件費および経費の収集というコスト機能も引き受けます。BOM を組み合わせることで、アセンブリのコスト (材料、人件費、および経費) を正確に計算することができます。コスト要因のため、ルーティングは少し複雑です。
さまざまな観点から、Routing にもさまざまな分類がありますが、BOM ほど複雑ではありません。
bom_operational_routings.routing_type によると、設計および製造の観点から
- エンジニアリング ルーティングはエンジニアリング モジュールで維持されます
エンジニアリング ルーティングは、基本的には反応工学設計におけるルーティング プロトタイプであり、EBS での実際のメンテナンスは、製造ルーティングと同じです。
- 製造 ルーティングは BOM モジュールで維持されるか、エンジニアリングによって「実装」されます ルーティング - 生産から変換されます
製造工順は、ワークショップの実際の生産、つまり製品の生産プロセスで現在使用されている工順を反映し、標準に従ってどのプロセスを通過する必要があるか、どの部門を通過する必要があるか、および部門のリソースがどのくらいか生産のために消費する必要があります。
bom_operational_routings.alternate_routing_designator に従って、プロセスのプライマリとセカンダリの観点から
- メインルーティング
最も一般的に使用されるプロセス ルートは、コスト畳み込み、開始 JOB、および MRP リード タイム計算などの各モジュールの使用においてデフォルトでメイン ルーティングです; コスト畳み込みおよび開始 JOB は、BOM を置き換えるために手動で選択できます。
- 代替ルーティング
メイン工順を作成した後、代替工順を作成できます。つまり、同じ製品を他の手順と方法 (異なるプロセス、異なる部門、異なるリソース、異なる数量) で生産できます。
設計ルーティングを行う場合、通常、一連の代替ルーティングを作成して、構成、プロセス、およびコストを比較できます。
ルーティングを置き換えることの重要性は、異なるレベルの熟練労働者または異なる技術レベルの機械を使用することの効率が同じではないことを示すことでもあります。たとえば、主要な工順は新しい設備で処理され、これには 0.1 機械時間が必要ですが、工順 AAA の交換は古い設備で処理され、0.3 時間が必要です。
任意内容：工程が決まっているかどうか
- 標準ルーティング
通常、プロセス、部門、リソース、割り当てがすべて固定されている標準ルーティングについて話します。
- ルーティング ネットワークは、Shop Floor Management モジュールで定義されます
Dynamic Routings（動的工程ルート）の意味：生産工程があらかじめ決まっているのではなく、前工程の結果から次工程を決定する、例えば10工程目の検査結果値が＜ 60%なら30工程、それ以外なら20工程へ。
したがって、最初の定義は複雑なルーティング ネットワークであり、分岐判断を伴うプログラム フロー チャートに似ています。
標準ルーティング学習プロセス
前提条件 「Oracle EBS フルモジュール設定の詳細な例」を参照して BOM を設定します
↓
Item を確認します 材料定義の BOM タブ ページのプロパティを確認します。「INV: Items」を参照してください
↓
Resource を定義します リソースとそのレートを定義します
↓
Overhead を定義します 製造コストを定義しますとリソース 製造経費との関係
↓
部門の定義 部門とそのリソースとの関係、および各部門の製造費の割合を定義します ↓
標準
工程の定義 標準プロセスの定義
↓
プライマリ ルーティングの定義 メイン ルーティングの定義
↓
代替の定義 代替の定義
↓
代替ルーティングの定義 代替ルーティングの定義
↓
操作の変更 無効なプロセス、新しいプロセスとリソースを追加
↓
リソースの使用場所 リソースの使用状況
リソース定義
N: BOM/工順/生産資源
Oracle におけるリソースの意味は比較的豊富で、主に労働力、機械、時間、通貨、数量、およびその他の項目が含まれます。リソースを定義するときは、一連のコスト パラメータ (アカウントとレート) を定義する必要があります。
レートとは、単価と単価を意味します。
次のリソースを作成します: マシン、ジュニア ワーカー、テスター、スペシャル ワーカー、レートをそれぞれ 10/10/11/20 に設定します。リソースと製造コストの関係もここで直接定義できます。
[レート] をクリックしてレートを定義します。最初の定義では、Frozen を直接定義できます。
リソース定義キー フィールド:
この章の演習で定義するデータは次のとおりです。
製造間接費の定義
N: CST/セットアップ/サブ要素/オーバーヘッド
水、電気、石炭、オンサイト管理費などの重要な間接費以外の間接費は、間接費 (製造費) として定義できます。間接費は純粋にコストの概念であり、工順の定義と使用には影響しません。Oracleは、リソースとの関連付けを通じて、完成品/半完成品の単価と製造原価を自動的に計算するという目的を実現しています。
次のリソースを作成します。Water、Coal を作成し、それらを HR01/MS01、HR01/HR02/HR03 に関連付けるように設定します。ここでは、各部門の製造間接費率を直接定義することもできます。
新たに Overhead を作成しても、ここで Frozen 型の関係を定義することはできませんが、以前の Resource 定義に戻すことはできます。
間接費定義のキー フィールド:
この章の演習で定義するデータは次のとおりです。
デパートメント
N: BOM/工順/部門
ここでの部門は、私たちが呼ぶ財務、マーケティング、および計画部門ではなく、ワーク センター、処理センター、およびコスト センターに相当する可能性があります。
次の部門を作成します: 組立センター、包装部門、試験部門、車輪部門。2 つのリレーションを定義します。
- 部門とリソース間の関係、つまり、部門が所有するリソースを定義する
- 部門レートを定義します。好きなだけ設定できます ^o^~^o^。ただし、冷凍は定義できません
部門は主要なフィールドを定義します:
この章の演習で定義するデータは次のとおりです。
標準手順
N: BOM/工順/標準工程
標準プロセスはプロセス テンプレートに相当し、通常、各マシニング センターで最も一般的に使用される生産プロセスを表します。
各部門はいくつかの標準手順を定義することができ、次に実際のプロセス ルートを定義するときに、これらの標準手順を直接参照し、状況に応じて変更することで、ルーティング メンテナンスの効率と精度を向上させることができます。
ここでは、「最終組立部門」の標準的な「組立工程」を定義します. 詳細なフィールドについては、次のセクションを参照してください.
メインルーティング
N: BOM/工順/工順
以前の設定はすべてルーティング用に準備されています。
ここでは先ほど紹介した「自転車の組み立て」の工程ルートを一つ一つ作成していきます. 工程内の部門に関連する資源のみ, つまり, 部門が所有する資源のみを選択できます. 10工程は標準工程を指します. :
一般的に使用されるフィールドは詳細であり、太字の部分は習得する必要があります。
この章の実践で定義されているルーティング データは次のとおりです。
代替番号
N: BOM/セットアップ/代替品
置換番号の定義は BOM と共有されるため、既存のものを使用するか、新しい AAA を定義できます。
代替ルーティング
N: BOM/工順/工順
唯一の違いは、置換番号が 1 つ多いことです。ここではこれ以上の詳細はありません。読者は自分で練習するよう求められます。
この章の実践で定義されているルーティング データは次のとおりです。
変更プロセス
N: BOM/工順/工順
部門、リソース、用途などの変更など、プロセスまたはその下のリソースの変更については、対応する行を直接変更できます。これは単純で直接的ですが、トレースを保持することはできません。推奨される方法は 2 つあります。1 つは変更のために明細を「コピー」して元の明細を無効にする方法、もう 1 つは ECO (Engineering Change Order) を介して行う方法です。
ここでは1の方法で、まず変更する工順を見つけ、変更する行に「有効期限」を記入して保存し、新たにレコードを追加し、同じシリアル番号で工程に入ります。新しいリソース情報を入力します。
これにより、ルーティングの新しいバージョン (バージョン) が実際に生成されます。たとえば、08-NOV-2006 13:05:59 以前は 1 つのバージョンであり、08-NOV-2006 13:06:59 以降は別のバージョンです。厳密にはつまり、この 2 つの時間の間のギャップ内に、別のバージョンがあります。
リソースが使用される場所
N: BOM/工順/生産資源の使用場所
リソース コードを入力して [検索] をクリックすると、どのアセンブリ パーツとどのプロセスでリソースが使用されているかをすばやく確認できます。
リビジョンとバージョン
マークされたバージョン番号はありませんが、以前の「変更操作」には区別するための有効な時間範囲があるため、ルーティングは異なる時点で異なるバージョンを持ちます。一方、ルーティングはリビジョン (リビジョン番号)、異なるリビジョンを作成できます。ルーティングはもちろん、そのバージョンも異なります。
したがって、一般に、異なるルーティング バージョンは、これら 2 つの方法で維持できます。
ルーティング SQL の書き方
Routing の SQL 記述方法は比較的単純ですが、有効な日付と型の制限にも注意する必要があります。以下は、現時点(Sysdate) でのルーティングの例であり、リビジョンがまだ欠落しています。
mst.segment1 assembly_item、 bor.alternate_routing_designator 代替、 bor.completion_subinventory、bos.operation_seq_num 、 dept.department_code、 bos.effectivity_date、 bos.disable_date、bres.resource_seq_num 、 res.resource_code、 bres.basis_type、 bres.usage_rate_or_amountを選択します。 mst、 bom.bom_operational_routings bor、 bom.bom_operation_sequences bos、 bom.bom_departments dept、 bom.bom_operation_resources bres、 bom.bom_resources res WHERE
mst.organization_id = bor.organization_id
AND mst.inventory_item_id = bor.assembly_item_id
AND bor.routing_sequence_id = bos.routing_sequence_id
AND bos.department_id = dept.department_id
AND bos.operation_sequence_id = bres.operation_sequence_id
AND bres.resource_id = res.resource_id
--Item AND mst.bom_enabled_flag = 'Y' AND mst.bom_item_type IN ( 1 , 2 , 3 , 4 ) -- 依存AND nvl(mst.eam_item_type, 0 ) = 0 -- ルーティング ヘッダー
AND bor.routing_type = 1 --1 Manufature, 2 ENG AND nvl(bor.cfm_routing_flag, 2 ) = 2 --Operations AND nvl(bos.disable_date, SYSDATE ) >= SYSDATE AND bos.implementation_date IS NOT NULL AND nvl(bos .eco_for_production, 2 ) = 2 --Filters AND mst.organization_id = 104 AND mst.segment1 LIKE '960%' ORDER BY 1 , 2 NULLS FIRST , 4
、8 ;
Resource とそのレート SQL の書き方
コストの種類に注意するだけで、比較的簡単です。
res.organization_id、
res.resource_code、
res. description ,
lov_cse.meaning cost_element,
CASE
WHEN res.cost_element_id IN ( 3 , 4 ) THEN
decode(res.functional_currency_flag,
1 ,
'Currency' ,
lov_brt.meaning)
ELSE
lov_cse.meaning
END resource_type,
lov_dbs.meaning default_basis_type,
crc.resource_rate
FROM bom.bom_resources res,
apps.fnd_lookup_values_vl lov_cse,
apps.fnd_lookup_values_vl lov_dbs、
apps.fnd_lookup_values_vl lov_brt、
bom.cst_resource_costs crc
WHERE res.cost_element_id = lov_cse.lookup_code
AND 'CST_COST_CODE_TYPE' = lov_cse.lookup_type
AND res.default_basis_type = lov_dbs.lookup_code
AND ' CST_resource_types.relookup_BASIS' = relookup_BASIS . = lov_brt.lookup_code AND 'BOM_RESOURCE_TYPE' = lov_brt.lookup_type AND res.resource_id = crc.resource_id AND res.organization_id = 104 AND res.cost_element_id = 3 -- 要素AND
crc.cost_type_id = 1 -- コスト タイプORDER BY 1 , 2 , 3 , 4 ;
製造間接費、関連リソース、評価 SQL の書き方
実際、Oracle は各コストのサブ要素の定義を bom_resources テーブルに格納するため、SQL を記述するときは、混乱しないように自己結合の使用に注意する必要があります。
オーバーヘッドに関連するリソース:
SELECT ow.organization_id、
ow.resource_code、overhead_code、
owh. description、
lov_cse.meaning cost_element、
lov_dbs.meaning default_basis_type、
res.resource_code resource_code
FROM bom.bom_resources owh、
apps.fnd_lookup_values_vl lov_cse、
apps.fnd_lookup_values_vl lov_dbs、
bom.cst_resource_overheads cro、
bom.bom_resources res
WHERE =.cost_element AND_cse =
.cost_element 'CST_COST_CODE_TYPE' = lov_cse.lookup_type
AND owh.default_basis_type = lov_dbs.lookup_code
AND 'CST_BASIS' = lov_dbs.lookup_type
AND owh.resource_id = cro.overhead_id
AND cro.resource_id = res.resource_id
AND owh.organization_id = 104 AND owh.cost_element_id = 5 -- 要素AND cro.cost_type_id = 1 --コストタイプORDER BY 1、2 ; _ _
オーバーヘッドの部門レート:
SELECT ow.organization_id、
ow.resource_code、overhead_code、
owh. description、
lov_cse.meaning cost_element、
lov_dbs.meaning default_basis_type、
dept.department_code、
cdo.rate_or_amount
FROM bom.bom_resources owh、
apps.fnd_lookup_values_vl lov_cse、apps.fnd_lookup_values_vl
lov_dbs
、bom.cst_department_overheads
clov 、 bomow.bom_cost_departh WHERE_departments = 要素.lookup_code AND
'CST_COST_CODE_TYPE' = lov_cse.lookup_type
ANDowh.default_basis_type = lov_dbs.lookup_code
AND 'CST_BASIS' = lov_dbs.lookup_type
AND owh.resource_id = cdo.overhead_id
AND cdo.department_id = dept.department_id
AND ow.organization_id = 104 AND owh.cost_element_id = 5 -- 要素AND cdo.cost_type_id = 3 -- コスト タイプORDER BY 1 , 2 , 6 ;
ルーティングの削除方法
N: BOM/削除グループ
削除グループによる一括削除により、トランザクション処理などの制約があるかどうかを一律にチェックし、ない場合のみ削除することができます。
製造リードタイムとその累積
N: BOM/工順/工順/ツール/計算リード タイム
N: BOM/工順/工順/ツール/ロールアップ リード タイム
製造リードタイムが累積されます。
- CST: 品目原価材料費
アプリケーション: 部品表
責任: コスト管理
要約すれば
材料費はアイテムのコストであるため、一部の企業ではそれを単一製品コスト、製品コスト、およびユニットコストと呼んでいます。
実際の業務と同様に、EBSシステムにおける資材の取引処理は品目ベースであり、さらにその原価計算は「資材原価」ベースです。
たとえば、商品Aを顧客に販売すると、売上高＝販売価格×販売数量、売上原価＝材料費×販売数量となるので、受注の粗利益＝売上高－売上原価を求めるのは簡単です。
このシステムでは、調達、在庫取引、WIP は、仕入価格差額/請求価格差額の PO 計算、在庫金額と取引費用の INV 計算、製造原価とその差額の WIP 計算など、材料費にも密接に関連しています。なども材料費に直接基づいています。
では、「材料費」はどのようにして生まれたのでしょうか。一つはもちろん手入力と直接定義ですが、実際の運用では対応する原価方式に合わせてシステムが自動計算するのが一般的です。これを行うには、Oracle のいくつかのコスト概念を理解する必要があります。
コスト構造: オラクルが提供するコスト・モデル
在庫組織: コスト モジュールは、他の製造モジュールと同様に、基本データとビジネス データを定義、記録、および保護するための「在庫組織」に基づいています; さらに、BOM の共通のように、コストは他の組織から共有することもできますただし、Share のみ 標準原価方式に限定され、Share 組織は WIP 機能を有効にすることはできません; Share 組織は「コスト サブ組織」と呼ばれ、これに対応して、Share 組織は「コスト マスター組織」と呼ばれます。 . ほとんどのエンタープライズ アプリケーションでは、共有機能は使用されないため、通常、組織の「コスト マスター組織」もそれ自体です。
原価法：システムは、永久原価法（各取引の原価をリアルタイムで計算）、期間原価法（期間単位で取引原価を計算）をサポートしています。前者は主な会計方法であり、特定の下位基準、移動加重平均、FIFO、LIFO、在庫組織は、通常は運用の特性または業界の規制によって決定される永久原価法のみを使用でき、使用する必要があります。後者は通常、次のように使用されます。補足ですが、PACの特定期間平均原価、期間LIFOについても、法令や会計基準で定められています。在庫組織が永久原価法と期間原価法を同時に使用する場合、「同じ原価トランザクションに対して、原価会計仕訳の複数のセットを生成できます。ただし、特定の会計仕訳セットのみを原価処理が規制に準拠するように、総勘定元帳を参照してください。これは、さまざまな転記手順を選択することによって実現されます。
通常、製造会社は標準原価法を使用し、流通/小売業者は平均原価法を使用します。
原価要素: さらに重要です。以下の説明を参照してください。
ベンチマークの種類: より重要です。以下の説明を参照してください。
原価要素 原価要素: Oracle で割った原価粒度
材料費は、システム内の 5 つの主要な要素のコスト (材料費、材料間接費、リソース、外注加工費、および間接費) に細分されます。実費分析における「資材・労務費」に相当します。
これらの 5 つの要素は、原価計算全体の重要な基礎であり、システム コストの計算と循環を理解するための鍵でもあります。在庫金額勘定、WIP 評価勘定、WIP 差額勘定、要素吸収勘定、在庫原価入力、WIP リソース入力、WIP 原価差、材料費畳み込みなどはすべて、技術的な観点から、これに基づいて処理されます。コスト関連のプログラム コードとは異なり、Oracle はこれら 5 つの主要な要素を処理するようにハードコーディングされています。
1.材料: 材料費。通常は、BOM の最下位レベルのコンポーネントの直接調達費です。
2.資材諸経費: 資材管理費。
3.リソース: 直接製造コストは、通常、直接消費される労働、設備、場所、およびその他の費用を指します。
4.外注加工費 : 外注加工費であり、品目に関連付けて調達を通じて受け取り、管理することができます。
5.製造間接費: アウトソーシングの過程でのリソース消費と間接費。
システムでは、上記の要素のいずれかを使用する場合、少なくとも 1 つの対応するサブ要素Sub Elementを定義する必要があります。これは、実際には柔軟で詳細なプラットフォームを提供し、ユーザーは自分の好みに応じて「自由に」設定できます。原価計算の特徴。
材料のサブ要素: 細分化されていない場合は、一般的な「原材料」のサブ要素を設定するだけで、ゴム、鉄骨構造、化学薬品、ポテトなどのように細分化することもできます。
資材間接費サブ要素: 購入手数料、配送料、税金などの資材管理料金の詳細を設定します。
リソースサブ要素: 旋盤 1、加硫機 1、一般労働者、技術者など、さまざまな実際のリソースを設定できます。
外注サブ要素: 外注処理の種類を設定します。これは、サプライヤによっても設定でき、案件にも関連付けることができます。
製造費のサブ要素: 水、石炭、電気などの製造費の詳細を設定します。
原価要素の観点から、材料費の構成は次のとおりです。
ベンチマークの種類 Basis: 自動コスト計算のベンチマーク パラメータ
EBS はどこでも自動計算機能を使用しており、原価計算も例外ではありません。自動化は、「いつ、どのように計算するか」の問題だけでなく、「いくら、いくら、どの口座から借りるか」の問題も明確にする必要があります。ベンチマーク タイプは、「数量の計算方法」を決定するために使用されます。
前のルーティングの章を振り返ると、製造コストとリソースには課金ベンチマークに関連する設定があり、次のように要約できます。
注: 「単一品目の消費量」は「材料費」の自動計算と畳み込みに使用され、「WIP あたりの消費量」は「仕掛品コスト」の自動計算に使用され、「PO あたりの消費量」は「購入コスト」に使用されます。 」の計算。
コスト畳み込みロールアップ: BOM、ルーティング、さまざまなレート、およびベンチマーク タイプに基づいて組み立てコストを計算します
コスト畳み込みはアセンブリに適用され、そのコスト = 下位層のコンポーネント コスト + 自身の処理コストです。下の図を下から上に見ていくと、自転車のコストが 170.00 である理由が直感的にわかります。
したがって、一般的に言えば、最も低いコンポーネントのコスト (材料) のみを手動で指定する必要があり、すべてのアセンブリのコストは、BOM、工順、さまざまなレート、およびベンチマーク タイプによって自動的に「複雑化」できます。
コストのレベルとソース
コスト畳み込みの観点から、さまざまなコストを次のように分類できます。
このレイヤー - 非畳み込み: 上記のハンドルとシートのコストなど、この材料のコストを直接定義します。
このレイヤー - 畳み込みに基づく: 前述のフレームと自転車の「このレイヤーの人件費」など、このマテリアルのルーティングから計算されたコスト。
下層 - 畳み込みに基づく: 上のフレームの「下層材料費」、自転車の「下層材料費」、「下層人件費」など、この材料の BOM ボリュームからのコスト。
ここの「下層」、一部のドキュメントは「上層」と呼ばれますが、これは翻訳の問題です! 対応する英語は実は「Previous」と呼ばれているので、英語に曖昧さはありません。
コスト タイプ コスト タイプ: 各バージョンのコスト データを保存します
コスト タイプは、各バージョンのコスト データを保存するためにシステムで使用されます: 現在のコスト、バックアップ コスト、すぐに使用できるコスト、シミュレートされたコストなど。したがって、材料のコストを取得する場合は、そのコスト タイプを指定する必要があります。
無限の数のコスト タイプを作成できるため、毎年履歴コストを保持するなど、意味のあるコスト バージョンを保存できます。
現在のコストで使用されるコスト タイプは「組み込み」、つまり Oracle によってハードコードされており、さまざまなコスト メソッドが異なります。標準コスト メソッドでは「凍結」が使用され、平均コスト メソッドでは「平均」が使用されます。 FIFO コスト方式では「FIFO」、LIFO コスト方式では「LIFO」を使用します。
初期に定義されていない限り、これらの「組み込み」コスト タイプの下で、材料費またはさまざまなレートを直接定義または畳み込むことはできません. コスト データは、他のコスト タイプ (通常は保留中) で準備する必要があります - 手動定義 +畳み込み、そして最後にコスト更新プログラムを通じて現在のコスト タイプに更新します。
コスト入力: 重要!
多くの原価関連のエントリがあり、異なる原価方法、特に差異の計算にはいくつかの違いがあります。ここでは、原価計算で最も一般的に使用されるエントリのみを説明します。完全な内容については、「A Simple Introduction to to」を参照してください。 Oracle EBS エントリ、ロジスティクス、およびドキュメント フロー」.
システムの原価エントリはすべて原価要素 (5 つの主要要素とその下位要素) に基づいています。
まず、メインのアカウント設定を見てください (自分でインターフェイスを確認してください)。
- INV 在庫には、5 つの主要な「在庫金額勘定」があります - 5 つの主要な要素に対応して、さまざまな「差異勘定」もあります。
- INV サブインベントリには、5 つの主要な「インベントリ バリュー アカウント」があります。
- WIP 作業指示書のタイプには、5 つの主要な「評価勘定」と 4 つの主要な「差異勘定」があります (2 つの品目が同じものを使用します)。
- 「材料」を除く 4 つの下位要素にはすべて「吸収勘定」があり、資源には「資源差勘定」があります。
- その他のカウンターパーティの件名はここには記載されていません。
標準原価を例として、さまざまなトランザクション処理の特定のエントリを見てみましょう。
アイテム コストの学習プロセス
前提条件 「Oracle EBS フルモジュール設定の詳細例」を参照して CST を設定
↓
組織パラメータの見直し 組織パラメータで選択されたコストタイプの見直し、省略
↓
楽しい除外の見直し 責任の機能的除外の見直し
↓
アイテムの定義 購入部品の定義の定義「INV: 品目」を参照
↓
BOM を定義 BOM 定義を定義、「BOM: 部品表」を参照
↓
リソースを定義 リソースとそのレートを定義、「BOM: 工順」を参照
↓
オーバーヘッドを定義 製造原価を定義、 「BOM: 工順」参照
↓
部門定義 部門定義、「BOM: 工順」参照
↓
工順定義 工順定義 「BOM: 工順」参照
↓
サブ要素の定義は、コストのサブ要素を定義します。ここでは、材料費と材料間接費のサブ要素を追加で定義します
↓
品目コストの定義は、材料費を手動で定義します。通常は、購入部品の保留コストです ↓
コスト
タイプの定義 コスト タイプを定義します
↓
ロールアップ アイテムコスト コスト コンボリューション、通常はコンボリューション アセンブリの保留コストです
↓
アイテム コストを表示して材料を表示します 保留コスト
↓
コストの更新を実行 標準コストを例に取り、保留コストを凍結に更新します
↓
アイテム コストを表示して現在のコストを表示します材料のコスト
↓
すべての取引を行う コストを表示するために取引処理を行う 入荷倉庫、請求書取引など、確認するエントリ
メニュー除外設定
N: システム/セキュリティ/責任/定義
以下に機能を示しますが、適用する責任については、実際のニーズに応じて設定してください。
原価副要素
N: CST/サブエレメント/マテリアル
Lot と Item に基づいて、2 つの材料サブ要素、Rubber と Steel をそれぞれ定義します。
N: CST/サブエレメント/オーバーヘッド
それぞれ 6 つの請求基準に基づいており、すべて HR01 に関連付けられている、購買などの 6 つの間接材料費副要素を定義します。
ここで間接材料費の割合を定義する必要はありません。品目原価で直接定義する必要があります。
テスト データの凍結コストは次のとおりです。
材料費
N: CST/アイテムコスト/アイテムコスト
購入した部品の冷凍コストを直接定義します. ここでは 91 から始まる材料を示します. 具体的には, コスト ボタンをクリックしてから, サブ要素に従ってコストを入力します. メイン インターフェイスでコストの計算方法を学習できます.
主なフィールドの説明:
| 属性名 |
説明 |
| ヘッダープロパティ |
|
| アイテム |
材料コーディング |
| コストタイプ |
コストタイプ |
| ロールアップに基づく |
コストはコンボリューションに基づいており、通常、アセンブリ部分はあり、下部の購入部分はありません |
| ロールアップに含める |
機器がコンボリューションされている場合、このコンポーネントはその中に含まれています。一般的にはい |
| ロットサイズ |
原価計算のロットサイズ |
| 単価 |
ユニットあたりの総コスト、読み取り専用 |
| 材料 |
材料の総コスト、読み取り専用 |
| 間接材料費 |
間接材料費要素の総原価、読み取り専用 |
| リソース |
リソースの総コスト、読み取り専用 |
| 外注加工 |
コミッションの合計コスト、読み取り専用 |
| オーバーヘッド |
オーバーヘッドの総コスト、読み取り専用 |
| User Def Item Costsプロパティ |
|
| 原価要素 |
原価要素 |
| サブ要素 |
原価副要素 |
| アクティビティ |
アクティビティ |
| 基礎 |
ベンチマークの種類 |
| レートまたは金額 |
単価 |
| 単価 |
これは、バッチ サイズ、ベンチマーク タイプ、および単価に基づいて計算され、ヘッダーの各コストのソースです。 |
| ロールアップ品目原価属性、ユーザー定義と同じ |
|
テスト データの凍結コストは次のとおりです。
| 材料 |
原価要素 |
子要素 |
リソースベース |
ベンチマークの種類 |
畳み込みソース |
レベル |
レート |
基準 |
料金 |
| 910001 |
材料 |
ゴム |
多く |
ユーザー定義 |
これ |
10 |
0.125 |
1.25 |
|
| 910001 |
材料 |
鋼 |
アイテム |
ユーザー定義 |
これ |
10 |
1 |
10 |
|
| 910001 |
うわー素材 |
関税 |
多く |
ユーザー定義 |
これ |
0.1 |
0.125 |
0.0125 |
|
| 910001 |
うわー素材 |
購入 |
アイテム |
ユーザー定義 |
これ |
0.1 |
1 |
0.1 |
|
| 910001 |
うわー素材 |
インポート1 |
解像度の単位 |
ユーザー定義 |
これ |
0.1 |
0 |
0 |
|
| 910001 |
うわー素材 |
インポート2 |
解像度値 |
ユーザー定義 |
これ |
0.1 |
0 |
0 |
|
| 910001 |
うわー素材 |
インポート3 |
合計値 |
ユーザー定義 |
これ |
0.1 |
11.25 |
1.125 |
|
| 910001 |
うわー素材 |
インポート4 |
アクティビティ |
ユーザー定義 |
これ |
0.1 |
0.5 |
0.05 |
|
| 910002 |
材料 |
ゴム |
多く |
ユーザー定義 |
これ |
10 |
0.125 |
1.25 |
|
| 910003 |
材料 |
鋼 |
アイテム |
ユーザー定義 |
これ |
10 |
1 |
10 |
|
| 910004 |
材料 |
鋼 |
アイテム |
ユーザー定義 |
これ |
5 |
1 |
5 |