架空のO171は、営業が商品・数量・希望日を確認して受付を終えました。しかし現場の作業と納品はまだです。受注表の完了が受付の終点だけを示すなら、全体が終わったように読めない名前にします。

教材では受付済み、作業中、納品済みという状態を使います。納品済みの根拠は会社が認めた納品記録の確認です。保存ボタンを押した事実や、通知を送った事実を納品へ置き換えません。

会社で発送と納品を区別する必要があれば、別状態を追加します。状態の数を先に増やすより、誰が何の未完了を知りたいかを経営者と担当者が確かめます。

この章の根拠：出典1出典2

O171を受付済みへ変えるのは、営業が必要項目と未確認の扱いを確かめた後です。作業中は現場が引き受けて開始した記録、納品済みは所定の納品確認に対応させます。

同じ担当が更新する場合でも、業務の根拠を分けます。営業が現場の返答を受けて入力するなら、現場の確認日時や記録を添えます。画面を編集できることが、業務の状態を判断する権限とは限りません。

自動連携の成功も別の確認です。取込先で保存されたことと現場が引き受けたことを混ぜず、状態を変えるイベントの意味を開発担当へ示します。

この章の根拠：出典1出典3

教材の通常注文は受付済みから作業中、納品済みへ進みます。受付後に納品済みへ直接変える操作ができても、途中の業務確認が省けるとは限りません。正規の条件を定義します。

別の受注経路で作業済みの記録が入る場合など、途中を飛ばす必要があれば、その根拠と担当を別に決めます。通常と例外を同じ無条件の変更にしません。

一部だけ納品した注文は全体の納品済みとは限りません。明細や数量の単位で状態を持つ必要があるかを確認し、部分完了の残りが見えるようにします。

この章の根拠：出典2出典3

数量の確認待ちは保留です。顧客の取消が所定の手順で確認された場合は取消という状態を残します。どちらも納品済みと同じ完了へまとめると、実績や残作業の意味が変わります。

保留には不足情報、確認先、担当、次の確認を添えます。再開する場合はどの状態へ戻るかを確認します。取消には根拠、残る作業や費用の判断先を記します。

作業中の取消は、現場の停止可否や進んだ処理の確認が必要です。受付担当が状態名だけを変更して現場も止まったと扱わず、引継ぎを確認します。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典1出典2

O171が未納品なのに納品済みへ変わったら、変更担当が元の根拠を確認します。正しい状態へ戻す場合は、旧状態、新状態、理由、担当、日時を記録します。無言の上書きで誤変更を消しません。

納品済みを見て請求や報告が進む運用なら、利用先へ影響したかを確認します。状態を戻すことと、請求や予定を訂正することは別の作業です。正規の担当へ渡します。

開発担当は、通常・保留・取消・誤変更の確認例で入力と連携を点検します。画面で状態が変わることだけでなく、許されない変更の扱いと履歴が残ることを確かめます。

この章の根拠：出典2出典3

O171の受付済みは営業の確認が終わった状態で、納品済みではありません。経営者は、必要な終点と根拠を担当者と定義します。

通常の順と例外、保留と取消の理由を分けます。連携で保存されたことを業務の完了にせず、現場の引受や納品確認へ対応させます。

状態対応表の記入メモへ、変更担当と許されない移り方、誤変更の確認先を残してください。利用先への影響まで追い、受注の何が終わったかを説明できる表にします。

この章の根拠：出典1出典2出典3