Fixモジュール

Fix モジュールは、物理的資産のメンテナンス、修理、およびトラブルシューティングを処理します。これには、生産ラインを稼働させ続けるための内部製造設備のサービス、ならびに顧客から返品された製品の保証修理または有料サービスコールの管理が含まれます。

使用するタイミング

ショップフロアの機械が故障し、修理が必要な場合。
設備が予定された予防メンテナンスの時期になった場合。
顧客が保証期間内に欠陥のある製品を返品した場合。
顧客が以前に購入した製品の修理サービスに対して支払う場合。

Fixモジュールテーブル

Fixダッシュボードは、すべてのメンテナンスおよび修理活動の主要なディスパッチボードとして機能します。すべてのアクティブおよび履歴の「Fault Order」(FO)を一覧表示し、サービスマネージャーが緊急修理をトリアージし、進行中のメンテナンス作業の進捗を監視できるようにします。

主な要素

Priority: 修理の緊急性を示す数値ランキング(1が最高)。
Order Number: 「FO-」(Fault Order)で始まるチケットの一意の識別子。
Order Source: 修理が顧客の返品から発生した場合、元の販売注文(SO#)がここにリンクされます。
Order Type: 作業を分類します(例: 「Product Repair」、「Material Repair」、「Equipment Maintenance」)。
Item: 修理が必要な特定の製品、マテリアル、または機械。
Item Status: 「Under Warranty」、「Preventive」、「Fault」、「Paid」などの状況を示す動的バッジ。
Cost Value: 修理の推定または実際の財務コスト。
Customer: 修理に関連する顧客(該当する場合)。
Assigned To: 修理を任された特定の技術者またはエンジニア。
Status: 作業注文の現在の段階(例: 「Ready to Start」、「In Progress」、「FO Draft」、「Complete」)。

使い方

列ヘッダーを使用してテーブルをフィルターおよびソートします。例えば、「Order Type」列をフィルターして「Equipment Maintenance」チケットのみを表示するか、「Due Date」でソートして予定より遅れているタスクを見つけることができます。

拠点の選択と追加

組織が複数の物理的な場所で運営されている場合、正しい施設の修理チケットを表示していることを確認する必要があります。

ダッシュボードの左上にある Site ドロップダウンメニューを見つけます。
現在の施設を選択してテーブルをフィルターします。
新しい拠点を追加するには: ドロップダウンをクリックし、リストの下にある + Add a new site を選択します。
「Add a new site」モーダルが表示されます。
必須の Site Details を入力します: 「Site Name」、「Legal Name」、住所、「Currency」。
Site Functions の下で、この拠点が使用するモジュールのボックスをチェックします(「Fix」がチェックされていることを確認)。
Add をクリックして、新しい場所をデータベースに保存します。

Site dropdown

ランクの更新

すべての修理が同じように緊急ではありません。壊れたメイン組立ラインは即座の対応が必要ですが、きしむオフィスチェアは待つことができます。Rank機能により、マネージャーは技術者のワークロードを視覚的に優先順位付けできます。

急ぐまたは遅らせる必要のある「Fault Order」を特定します。
Priority 列の数値の隣のドロップダウン矢印をクリックします。
1〜10のリストから新しい数値を選択します。その範囲外の数値を割り当てるには、「Input Rank」をクリックして目的の数値を入力します。
テーブルは即座に再ソートされ、最高優先度のタスク(Rank 1)がリストの上部に移動します。

ステータスの更新

完全なドキュメントを開く必要なく、ダッシュボードから直接修理チケットをライフサイクル全体で進めることができます。これは、完了したチケットを迅速にクリアしたり、ジョブを保留にしたりするのに便利です。

更新したい注文行を見つけます。
その行の右端にある「三点」メニューアイコン(⋮)をクリックします。
注文の現在の状態に関連するステータスオプションを持つメニューが表示されます(例: 注文が「FO Draft」の場合、オプションは「Mark as Ready to Start」または「Cancel FO Draft」になります)。
新しいステータスを選択します。「Status」列のバッジが即座に更新されます。

注記:

毎日のトリアージ: サービスマネージャーは、テーブルを「Priority」と「Due Date」でソートして毎日を開始する必要があります。「Assigned To」列をチェックして、Rank 1の品目と期限超過の品目がアクティブに作業されていることを確認します。

注文ソースを活用する: Order Source列に「SO#」が表示されている場合、それは顧客がこの修理を待っていることを意味します。これらはしばしば、内部の美的修理よりも高い優先度が必要です。

会議用にエクスポートする: 右上の印刷アイコンの隣のダウンロードアイコンを使用して、テーブルをCSVまたはPDFにエクスポートします。これは、毎週のメンテナンスレビュー会議に非常に役立ちます。

Fix Orderの作成

Fix Order(FO)は、メンテナンスチームまたは技術者に修理、予防メンテナンス、またはトラブルシューティングタスクの実行を指示する公式のサービスチケットです。労働、部品コスト、および整備されている特定のシリアル番号を追跡するための中央レコードとして機能します。

Fix Orderは、内部の機械故障のためにゼロから手動で生成するか、ソースドキュメント(販売注文から発生する顧客保証請求など)から自動的に生成できます。

主な要素

Assigned To: 修理チケットに責任を持つ主任技術者。
Customer: 修理を要求するクライアント(内部設備メンテナンスの場合は空白のままか、自分の組織を選択します)。
Order Type: 作業を分類するドロップダウン(例: 「Product Repair」、「Material Repair」、「Equipment Maintenance」)。
Items Table: チケットの中核。特定の「Item」、その正確な「Serial Number」、「Item Status」(例: 「Under Warranty」、「Paid」)、推定「Cost Value」、および特定の部品を異なるスタッフに委任するための行レベルの「Assigned To」フィールドが必要です。
Financial Summary: 品目テーブルに入力された値に基づいて、「Subtotal」、「Tax」、および「Total」の修理コストを計算します。
アクションボタン: 進捗を一時停止する「Save Draft」、コピーをエクスポートする「Download」、およびチケットをライブでプッシュする「Create Order」。

ゼロからの作成

事前に存在するソースドキュメントなしで手動の修理チケットを構築します。

内部製造設備の一部がショップフロアで故障する。
施設の定期的、予防的メンテナンスのスケジューリング。
ウォークイン顧客が、システム内の以前の販売注文に関連付けられていない修理を要求する。

使い方

Fixダッシュボードから、右上の + Report a Fault(またはCreate)ボタンをクリックします。
「Create New Fix Order」フォームが開きます。
Assigned To フィールドを使用してメインの技術者を割り当てます。
(任意) 修理がクライアント用の場合、ドロップダウンから Customer を選択します。
Issue Date と予想される Due Date を設定します。
Order Type を選択します(例: 「Maintenance」または「Product Repair」)。
「Item」テーブルで、ドロップダウンをクリックして修理が必要な品目を検索および選択します。
トレーサビリティを確保するため、正確な Serial Number を入力します。
Item Status を設定します(例: 「Under Warranty」、「Paid」、「Preventive」)。
修理の推定または見積もりされた Cost Value を入力します。
Create Order をクリックします。確認モーダルが表示され、次のように尋ねます: 「You are about to proceed with this action. Make sure all items are correct. Press continue if you want to proceed.」
Continue をクリックして注文を確定します。

New form

ソースからの作成

親トランザクションから直接修理チケットを生成します。システムは、手動データ入力エラーを防ぐため、ソースから顧客データ、品目、シリアル番号を自動的に取得します。

既存の販売注文(SO)に基づいて顧客が保証返品を開始する。
QA検査官がCheck Order(CO)中に品目を不合格にし、リワーク用にフラグを立てる。

使い方

このワークフローは通常、システム通知を介してトリガーされます。別のモジュールから欠陥が報告されると、通知ポップアップ(例: 「Make: John Doe has requested a Fix Order」)を受信します。
通知またはリクエストをクリックすると、Fix Order Request モーダルが開きます。これは次のように述べます: 「You are about to create a new Fix Order based on the order below...」 と、ソースへのハイパーリンク(例: 「Sales Order: SO# 12345-67890」)を提供します。
リクエストモーダルで Continue をクリックします。
「Create New Fix Order」フォームが開きますが、上部に Order Source ブロックが表示され、ハイパーリンクされたソースドキュメントが表示されます。
Customer、Item、Serial Number フィールドは、親注文のデータに基づいて自動的に入力されます。
自動入力された詳細を確認し、技術者を割り当て、Cost Value を入力します。
Create Order をクリックし、確認モーダルをレビューし、Continue をクリックします。

Source request

注記:

ドラフト状態: 修理コストを確定する前にサプライヤーからの予備部品の見積もりを待っている場合、Save Draft ボタンを使用します。緑色の 「Draft Saved」 バナーは、作業がまだ技術者に送信されることなく安全に保存されていることを確認します。

ハイパーリンクされたソース: 3bワークフローでは、青の「Order Source」テキスト(例: 「SO-1234-5678-90」)はライブリンクです。クリックすると、元のトランザクションが新しいウィンドウで開き、元の購入日と保証の有効性を確認できます。

ベストプラクティス:

厳密なシリアル番号追跡: 顧客製品を修理するときは、「Serial Number」フィールドを決して空白のままにしないでください。顧客が保証修理のために製品を送信する場合、シリアル番号を追跡することで、販売した実際のユニットを送り返しているのか、別のユニットを送っているのかが証明されます。

正確な品目ステータス: 「Item Status」を常に正しくタグ付けしてください(例: 「Paid」と「Under Warranty」)。これにより、経理チームが「Cost Value」を顧客に請求すべきか、内部保証経費として償却すべきかがわかります。

品目ごとの委任: 注文に機械的メンテナンスと電気的トラブルシューティングが必要な場合、特定の品目行の個別の「Assigned To」フィールドを使用して、機械部品を1人の技術者に、電気部品を別の技術者に割り当てます。

Fix Orderの表示

Fix Orderが作成されると、技術者が修理を実行し、マネージャーがメンテナンスコストを追跡するためのアクティブなワークスペースになります。メインのFixダッシュボードから任意の注文行をクリックすると、詳細表示モードが開きます。このビューは、専用のタブに分かれています: General Information、Maintenance Instructions、Related Orders、Order History。

General Information

「General Information」タブは、修理チケットの主要なサマリーページです。技術者に必要なコンテキスト(作業が誰に割り当てられているか、何を修正する必要があるか、修理の推定財務コスト)を提供します。

主な要素

ヘッダー: Fix Order番号(FO#)、現在のステータスバッジ、および Actions ドロップダウンメニューを表示します。
物流: 「Assigned To」ユーザー、「Customer」(該当する場合)、「Issue Date」、「Due Date」を表示するフィールド。
Order Type: 作業を分類します(例: 「Maintenance」、「Product Repair」)。
Items Table: 特定の「Item」、「Serial Number」、「Item Status」(例: 「Under Warranty」、「Paid」)、「Cost Value」、行レベルの「Assigned To」所有者を一覧表示します。
Financial Summary: 右下にあり、修理の「Subtotal」、「Tax」、および最終「Total」コストを計算します。

使い方

Fix Orderを開きます。
ステータスバッジの隣の左上にある Actions ドロップダウンメニューをクリックします。
次の論理的なステップを選択します(例: 「Ready to Start」から「Mark In Progress」に変更)。
ステータスバッジは即座に更新され、作業が開始されたことを経営陣に通知します。

General Information

ソース付きの表示

Fix Orderが親トランザクション(顧客返品など)から生成された場合、General Informationタブは少し異なって見え、「Order Source」セクションがあります。

使用するタイミング

保証修理をレビューし、元の購入詳細または出荷ステータスを確認する必要がある場合。

主な要素

Order Source: FO番号の下に、ハイパーリンクされたID(例: 「SO-1234-5678-90」)と親注文の現在のステータス(例: 「Partially Shipped」)を含む専用ブロック。

使い方

青の Order Source ハイパーリンクをクリックします。システムは元のトランザクションを新しいウィンドウで開き、Sellモジュールを探し回ることなく、顧客の詳細、保証条件、または元の支払いステータスをシームレスに相互参照できるようにします。

Order Source block

Maintenance Instructions

空のときはグレーアウトまたは括弧表示ですが、修理されている品目がマスタープロファイルに添付された標準作業手順書(SOP)を持っている場合、「[Maintenance Instructions]」タブは生き生きします。

使用するタイミング

技術者が修理を正しく実行するためにステップバイステップのガイダンス、図、または安全手順を必要とする場合。

主な要素

資産の最初の作成中にItemsモジュールで構成された特定の指示、予想される所要時間、参照メディア(画像/データシート)を継承します。

Related Orders

多くの場合、修理はサプライヤーから交換部品を注文するか、新しい部品を社内で製造することなしには完了できません。「Related Orders」タブは、これらの二次ワークフローの追跡センターとして機能します。

使用するタイミング

修理が停滞しており、技術者が交換部品がまだ注文されているか、配送されているかを確認する必要がある場合。

主な要素

子注文の「ID#」(例: 部品購入用のPO、部品作成用のMO、修理済み品目を返送するためのSO)を表示する追跡テーブル。
「Customer」、「Due Date」、リアルタイムの「Status」(例: 「Cancelled」、「Complete」、「Waiting for Payment」)を表示します。

使い方

「Related Orders」タブをクリックするだけです。このリストの赤い「Overdue」バッジは、現在のFix Orderの完了を遅らせている外部の遅延を即座に強調表示します。

Order History

「Order History」タブは、Fix Orderのライフサイクル全体を詳述する不変の自動監査証跡です。

使用するタイミング

遅延した修理について事後分析を実施し、ボトルネックがどこで発生したかを確認する場合。
ステータス変更やコスト更新の説明責任を追跡する場合。

主な要素

Date: すべてのアクションについて分単位でタイムスタンプ。
Action Owner: 変更をトリガーした特定のユーザー。
Log: イベントの詳細な説明(例: 「John Doe moved the order to manufacturing: [ORDER NUMBER]」 または 「John Doe changed the order status from [STATUS NAME] to [STATUS NAME]」)。

注記:

コスト価値の可視性: General Informationタブで計算された「Total」は経理にとって重要です。修理コストが内部で吸収される(メンテナンスの場合)か、顧客に請求される(有料修理の場合)かを決定します。

ステータスメニューは動的: 「Actions」ドロップダウン内のオプションは、注文の現在の状態に基づいて変わります。「Marked In Progress」になっていない場合、注文を「Complete」とマークすることはできません。

ベストプラクティス:

ステータス規律: 技術者がツールを手に取った瞬間にすぐに「Actions」ドロップダウンを「Mark In Progress」に更新することを義務付けてください。注文が数日間「Ready to Start」のままである場合、「Order History」ログは割り当てられた技術者にとって不利な反映になります。

関連注文を監査する: マネージャーが調達チームに予備部品の場所を尋ねる前に、「Related Orders」タブを確認する必要があります。リンクされた発注書が「Failed Inspection」と表示されている場合、マネージャーはすでに答えを得ています。

ハイパーリンクを活用する: 修理タイムラインに関する顧客の紛争を扱うとき、常に「Order Source」リンクを使用して、元の販売注文または返品がいつ処理されたかを正確に確認してください。

Fixモジュール

使用するタイミング

ショップフロアの機械が故障し、修理が必要な場合。
設備が予定された予防メンテナンスの時期になった場合。
顧客が保証期間内に欠陥のある製品を返品した場合。
顧客が以前に購入した製品の修理サービスに対して支払う場合。

Fixモジュールテーブル

主な要素

Priority: 修理の緊急性を示す数値ランキング(1が最高)。
Order Number: 「FO-」(Fault Order)で始まるチケットの一意の識別子。
Order Source: 修理が顧客の返品から発生した場合、元の販売注文(SO#)がここにリンクされます。
Order Type: 作業を分類します(例: 「Product Repair」、「Material Repair」、「Equipment Maintenance」)。
Item: 修理が必要な特定の製品、マテリアル、または機械。
Item Status: 「Under Warranty」、「Preventive」、「Fault」、「Paid」などの状況を示す動的バッジ。
Cost Value: 修理の推定または実際の財務コスト。
Customer: 修理に関連する顧客(該当する場合)。
Assigned To: 修理を任された特定の技術者またはエンジニア。
Status: 作業注文の現在の段階(例: 「Ready to Start」、「In Progress」、「FO Draft」、「Complete」)。

使い方

拠点の選択と追加

組織が複数の物理的な場所で運営されている場合、正しい施設の修理チケットを表示していることを確認する必要があります。

ダッシュボードの左上にある Site ドロップダウンメニューを見つけます。
現在の施設を選択してテーブルをフィルターします。
新しい拠点を追加するには: ドロップダウンをクリックし、リストの下にある + Add a new site を選択します。
「Add a new site」モーダルが表示されます。
必須の Site Details を入力します: 「Site Name」、「Legal Name」、住所、「Currency」。
Site Functions の下で、この拠点が使用するモジュールのボックスをチェックします(「Fix」がチェックされていることを確認)。
Add をクリックして、新しい場所をデータベースに保存します。

Site dropdown

ランクの更新

急ぐまたは遅らせる必要のある「Fault Order」を特定します。
Priority 列の数値の隣のドロップダウン矢印をクリックします。
1〜10のリストから新しい数値を選択します。その範囲外の数値を割り当てるには、「Input Rank」をクリックして目的の数値を入力します。
テーブルは即座に再ソートされ、最高優先度のタスク(Rank 1)がリストの上部に移動します。

ステータスの更新

更新したい注文行を見つけます。
その行の右端にある「三点」メニューアイコン(⋮)をクリックします。
注文の現在の状態に関連するステータスオプションを持つメニューが表示されます(例: 注文が「FO Draft」の場合、オプションは「Mark as Ready to Start」または「Cancel FO Draft」になります)。
新しいステータスを選択します。「Status」列のバッジが即座に更新されます。

注記:

毎日のトリアージ: サービスマネージャーは、テーブルを「Priority」と「Due Date」でソートして毎日を開始する必要があります。「Assigned To」列をチェックして、Rank 1の品目と期限超過の品目がアクティブに作業されていることを確認します。

注文ソースを活用する: Order Source列に「SO#」が表示されている場合、それは顧客がこの修理を待っていることを意味します。これらはしばしば、内部の美的修理よりも高い優先度が必要です。

会議用にエクスポートする: 右上の印刷アイコンの隣のダウンロードアイコンを使用して、テーブルをCSVまたはPDFにエクスポートします。これは、毎週のメンテナンスレビュー会議に非常に役立ちます。

Fix Orderの作成

主な要素

Assigned To: 修理チケットに責任を持つ主任技術者。
Customer: 修理を要求するクライアント(内部設備メンテナンスの場合は空白のままか、自分の組織を選択します)。
Order Type: 作業を分類するドロップダウン(例: 「Product Repair」、「Material Repair」、「Equipment Maintenance」)。
Items Table: チケットの中核。特定の「Item」、その正確な「Serial Number」、「Item Status」(例: 「Under Warranty」、「Paid」)、推定「Cost Value」、および特定の部品を異なるスタッフに委任するための行レベルの「Assigned To」フィールドが必要です。
Financial Summary: 品目テーブルに入力された値に基づいて、「Subtotal」、「Tax」、および「Total」の修理コストを計算します。
アクションボタン: 進捗を一時停止する「Save Draft」、コピーをエクスポートする「Download」、およびチケットをライブでプッシュする「Create Order」。

ゼロからの作成

事前に存在するソースドキュメントなしで手動の修理チケットを構築します。

内部製造設備の一部がショップフロアで故障する。
施設の定期的、予防的メンテナンスのスケジューリング。
ウォークイン顧客が、システム内の以前の販売注文に関連付けられていない修理を要求する。

使い方

Fixダッシュボードから、右上の + Report a Fault(またはCreate)ボタンをクリックします。
「Create New Fix Order」フォームが開きます。
Assigned To フィールドを使用してメインの技術者を割り当てます。
(任意) 修理がクライアント用の場合、ドロップダウンから Customer を選択します。
Issue Date と予想される Due Date を設定します。
Order Type を選択します(例: 「Maintenance」または「Product Repair」)。
「Item」テーブルで、ドロップダウンをクリックして修理が必要な品目を検索および選択します。
トレーサビリティを確保するため、正確な Serial Number を入力します。
Item Status を設定します(例: 「Under Warranty」、「Paid」、「Preventive」)。
修理の推定または見積もりされた Cost Value を入力します。
Create Order をクリックします。確認モーダルが表示され、次のように尋ねます: 「You are about to proceed with this action. Make sure all items are correct. Press continue if you want to proceed.」
Continue をクリックして注文を確定します。

New form

ソースからの作成

既存の販売注文(SO)に基づいて顧客が保証返品を開始する。
QA検査官がCheck Order(CO)中に品目を不合格にし、リワーク用にフラグを立てる。

使い方

このワークフローは通常、システム通知を介してトリガーされます。別のモジュールから欠陥が報告されると、通知ポップアップ(例: 「Make: John Doe has requested a Fix Order」)を受信します。
通知またはリクエストをクリックすると、Fix Order Request モーダルが開きます。これは次のように述べます: 「You are about to create a new Fix Order based on the order below...」 と、ソースへのハイパーリンク(例: 「Sales Order: SO# 12345-67890」)を提供します。
リクエストモーダルで Continue をクリックします。
「Create New Fix Order」フォームが開きますが、上部に Order Source ブロックが表示され、ハイパーリンクされたソースドキュメントが表示されます。
Customer、Item、Serial Number フィールドは、親注文のデータに基づいて自動的に入力されます。
自動入力された詳細を確認し、技術者を割り当て、Cost Value を入力します。
Create Order をクリックし、確認モーダルをレビューし、Continue をクリックします。

Source request

注記:

ドラフト状態: 修理コストを確定する前にサプライヤーからの予備部品の見積もりを待っている場合、Save Draft ボタンを使用します。緑色の 「Draft Saved」 バナーは、作業がまだ技術者に送信されることなく安全に保存されていることを確認します。

ハイパーリンクされたソース: 3bワークフローでは、青の「Order Source」テキスト(例: 「SO-1234-5678-90」)はライブリンクです。クリックすると、元のトランザクションが新しいウィンドウで開き、元の購入日と保証の有効性を確認できます。

ベストプラクティス:

厳密なシリアル番号追跡: 顧客製品を修理するときは、「Serial Number」フィールドを決して空白のままにしないでください。顧客が保証修理のために製品を送信する場合、シリアル番号を追跡することで、販売した実際のユニットを送り返しているのか、別のユニットを送っているのかが証明されます。

正確な品目ステータス: 「Item Status」を常に正しくタグ付けしてください(例: 「Paid」と「Under Warranty」)。これにより、経理チームが「Cost Value」を顧客に請求すべきか、内部保証経費として償却すべきかがわかります。

品目ごとの委任: 注文に機械的メンテナンスと電気的トラブルシューティングが必要な場合、特定の品目行の個別の「Assigned To」フィールドを使用して、機械部品を1人の技術者に、電気部品を別の技術者に割り当てます。

Fix Orderの表示

General Information

主な要素

ヘッダー: Fix Order番号(FO#)、現在のステータスバッジ、および Actions ドロップダウンメニューを表示します。
物流: 「Assigned To」ユーザー、「Customer」(該当する場合)、「Issue Date」、「Due Date」を表示するフィールド。
Order Type: 作業を分類します(例: 「Maintenance」、「Product Repair」)。
Items Table: 特定の「Item」、「Serial Number」、「Item Status」(例: 「Under Warranty」、「Paid」)、「Cost Value」、行レベルの「Assigned To」所有者を一覧表示します。
Financial Summary: 右下にあり、修理の「Subtotal」、「Tax」、および最終「Total」コストを計算します。

使い方

Fix Orderを開きます。
ステータスバッジの隣の左上にある Actions ドロップダウンメニューをクリックします。
次の論理的なステップを選択します(例: 「Ready to Start」から「Mark In Progress」に変更)。
ステータスバッジは即座に更新され、作業が開始されたことを経営陣に通知します。

General Information

ソース付きの表示

Fix Orderが親トランザクション(顧客返品など)から生成された場合、General Informationタブは少し異なって見え、「Order Source」セクションがあります。

使用するタイミング

保証修理をレビューし、元の購入詳細または出荷ステータスを確認する必要がある場合。

主な要素

Order Source: FO番号の下に、ハイパーリンクされたID(例: 「SO-1234-5678-90」)と親注文の現在のステータス(例: 「Partially Shipped」)を含む専用ブロック。

使い方

Order Source block

Maintenance Instructions

使用するタイミング

技術者が修理を正しく実行するためにステップバイステップのガイダンス、図、または安全手順を必要とする場合。

主な要素

資産の最初の作成中にItemsモジュールで構成された特定の指示、予想される所要時間、参照メディア(画像/データシート)を継承します。

Related Orders

使用するタイミング

修理が停滞しており、技術者が交換部品がまだ注文されているか、配送されているかを確認する必要がある場合。

主な要素

子注文の「ID#」(例: 部品購入用のPO、部品作成用のMO、修理済み品目を返送するためのSO)を表示する追跡テーブル。
「Customer」、「Due Date」、リアルタイムの「Status」(例: 「Cancelled」、「Complete」、「Waiting for Payment」)を表示します。

使い方

Order History

「Order History」タブは、Fix Orderのライフサイクル全体を詳述する不変の自動監査証跡です。

使用するタイミング

遅延した修理について事後分析を実施し、ボトルネックがどこで発生したかを確認する場合。
ステータス変更やコスト更新の説明責任を追跡する場合。

主な要素

Date: すべてのアクションについて分単位でタイムスタンプ。
Action Owner: 変更をトリガーした特定のユーザー。
Log: イベントの詳細な説明(例: 「John Doe moved the order to manufacturing: [ORDER NUMBER]」 または 「John Doe changed the order status from [STATUS NAME] to [STATUS NAME]」)。

注記:

コスト価値の可視性: General Informationタブで計算された「Total」は経理にとって重要です。修理コストが内部で吸収される(メンテナンスの場合)か、顧客に請求される(有料修理の場合)かを決定します。

ステータスメニューは動的: 「Actions」ドロップダウン内のオプションは、注文の現在の状態に基づいて変わります。「Marked In Progress」になっていない場合、注文を「Complete」とマークすることはできません。

ベストプラクティス:

ステータス規律: 技術者がツールを手に取った瞬間にすぐに「Actions」ドロップダウンを「Mark In Progress」に更新することを義務付けてください。注文が数日間「Ready to Start」のままである場合、「Order History」ログは割り当てられた技術者にとって不利な反映になります。

関連注文を監査する: マネージャーが調達チームに予備部品の場所を尋ねる前に、「Related Orders」タブを確認する必要があります。リンクされた発注書が「Failed Inspection」と表示されている場合、マネージャーはすでに答えを得ています。

ハイパーリンクを活用する: 修理タイムラインに関する顧客の紛争を扱うとき、常に「Order Source」リンクを使用して、元の販売注文または返品がいつ処理されたかを正確に確認してください。