製造業の仕入単価改定を管理するシステム導入｜発効日・発注残・請求差異の設計

仕入先から「来月納入分から単価を変えたい」という通知が届く。購買担当者が価格表を更新したつもりでも、発行済み発注書には旧単価が残り、入荷は新旧の両方にまたがり、請求書には新単価が載る。月末に経理が差異を見つけて初めて、購買、倉庫、生産管理がそれぞれ違う価格を参照していたことに気づく。この問題を解くための「製造業 仕入単価改定 管理システム 導入」は、価格マスタの上書きだけを電子化する話ではない。誰が、どの証拠に基づき、いつから、どの注文・受入・請求に価格を適用すると決めたかを一続きの記録にする設計である。

本記事では、タイの製造拠点を想定し、購買価格改定の通知から承認、仕入単価の発効日管理、発注残の単価変更、検収と請求照合までを具体的に整理する。購買管理全般の選び方や、標準原価をどう計算するかは別の論点だ。ここでは「同じ部品なのに、取引日と契約条件によって有効な価格が違う」という例外が、システム上で説明できるかに焦点を当てる。

結論：価格マスタより先に「適用境界」を決める

最初に決めるべきことは、値上げ幅や入力画面ではなく、改定価格を適用する境界だ。たとえば「10月1日以降の発注分」なのか「10月1日以降の納入分」なのかで、9月に発注し10月に受け入れる注文の扱いは変わる。「発注日」「仕入先確認日」「出荷日」「入荷日」「検収日」「請求日」は同じではない。契約書や合意書に基準日が書かれていないなら、購買と仕入先が発注残への適用を明示してから登録する。システムに任意の日付を入れても、商流の合意は生まれない。

実装するなら、①改定申請と証憑、②旧価格・新価格と通貨・単位、③発効条件、④対象となる未処理発注残、⑤承認と仕入先合意、⑥発注書の版、⑦受入・請求との照合、を同じ改定IDで結ぶ。これが最低限の骨格になる。Microsoft Business Central は仕入先別の購入価格表に有効日などを持ち、品目・数量・単位・通貨・日付を見て適用価格を判定する。SAPの購買条件にも有効期間という考え方がある。ただし、その標準機能が自社の「発行済みPOをどう扱うか」というルールまで自動で決めるわけではない。標準機能に乗る部分と、承認・発注変更・例外処理を分けて実機で確かめる必要がある。Microsoft Business Centralの購入価格／SAPの時点別条件

なぜ単価改定が工場で止まりやすいのか

「単価」の単位が部門で違う

仕入先の通知は「1個あたり」「1,000個あたり」「1kgあたり」のいずれかで届く。購買マスタは箱単位、在庫は個数、原価計算は重量、請求書は外貨ということもある。数値の大小だけを比べると、単位換算の誤りを値上げと誤認したり、逆に本当の値上げを見逃したりする。改定申請には、品目コード、仕入先コード、仕入先品番、購買単位、基本単位、換算率、通貨、税抜・税込の区分、運賃や金型費の扱いを含める。換算率を変更したときは、その履歴と承認も残す。

「価格を変える」という一文には、少なくとも四つの候補がある。見積価格、契約・価格表の価格、未発行POの提案価格、発行済みPOの合意価格だ。価格表を更新しただけで既発行POを書き換える仕様だと、過去の合意を後から説明できない。逆にPOを一切変更しない仕様だと、仕入先と改定合意した未納分が請求差異として積み上がる。どの価格をどの伝票へ渡すかを業務ルールとして定義する。

日付の名前だけでは適用条件が分からない

「発効日」欄が一つあっても、購買がそれをPO作成日と理解し、経理が納入日と理解していれば照合は失敗する。発効日の名称だけでなく、「何の出来事の日付を基準にするか」を明示する。日付はタイ現地時刻を基本とし、海外仕入先との契約で別の時区分を使うなら記録する。日付だけでよい取引と、時刻まで必要な取引も区別する。時刻を後付けで推定しない。

たとえば、10月1日付の価格改定通知が9月28日に届き、購買承認が10月3日、仕入先合意が10月5日だったとする。この場合、10月1日という日付をそのまま取引へ反映してよいとは限らない。承認前に発注した注文に遡及するのか、承認後の新規発注に限るのか、対象発注残を個別に合意するのか。三つの可能性を分けて承認者に提示する。遡及適用を認めるなら、どの伝票に何が変わるかの一覧を保存する。

発注残が一枚のPOでも一つの状態ではない

一つの発注行100個のうち、40個は受入済み、20個は輸送中、40個は未出荷かもしれない。発注書に一つの単価だけが表示されても、商流上は同じ扱いにできない場合がある。受入済み分には元の単価を残し、未出荷分だけ新単価とするなら、発注行を分割するか変更注文を発行する必要がある。分割の方法は導入製品と会計連携の仕様で異なるため、業務シナリオとして試験する。

Oracle Procurement の変更注文の説明では、承認済み購買文書の変更提案は承認・受諾・検証が完了してから新しい文書版に反映される。これは「マスタを更新したら既発行POも自動で合意済みになる」と考えないための参考になる。自社の仕入先との契約条件は別途確認する。Oracle Procurementの変更注文

単価改定の業務フローを八つの状態に分ける

システム要件を画面名から起こすと、重要な遷移が漏れやすい。まず改定案件の状態を定義する。推奨する基本の流れは「通知受領→内容確認→影響試算→社内承認→仕入先合意→価格版の登録→対象PO変更→受入・請求照合」だ。案件を却下・差し戻し・保留する経路も必要になる。特に「承認済みだが仕入先合意待ち」「価格版は登録済みだがPO変更待ち」を一つの『完了』にまとめない。

同じ人物が通知受付、価格登録、承認をすべて行う構成は、後から原因を追いにくい。人員が少なく職務分離が難しい場合でも、少なくとも「入力者」と「承認者」は別にし、緊急変更には事後承認の期限と理由を付ける。通知書はPDF添付だけでなく、改定ID、仕入先、品目、価格、適用条件に索引を付け、後から検索できる状態にする。

仕入単価のデータモデル：上書きではなく版で残す

最低限、価格レコードには「仕入先×品目×発効条件×価格版」の識別子を持たせたい。部品の型番が同じでも仕入先が違えば価格は違う。同じ仕入先でも工場・通貨・単位・数量帯・輸送条件が違えば、単一の価格欄では収まらない。一方で、すべての属性をキーにすると運用が重くなる。どの条件が価格を変えるかを現行の発注・請求データから抽出し、必要な組み合わせだけを採用する。

推奨フィールドは、仕入先、品目、仕入先品番、適用工場、通貨、購買単位、基準単位への換算率、数量帯、旧価格、新価格、有効開始日、有効終了日、適用基準イベント、改定理由、交渉・承認資料の参照、申請者・承認者、版番号、登録日時、無効化理由である。追加で運賃、関税、税、リベートを価格に含むかを識別する。見かけ上の単価比較に含まれる費目が違えば、価格差異を誤って報告する。

同じ仕入先・品目・通貨・単位・数量帯で有効期間が重複したら、登録時に止めるか、優先順位を明示する。期間の端点も「開始日は含む／終了日は含まない」のように定義する。日付の境界を曖昧にしたまま月初の発注を処理すると、二つの価格が同時に候補になる。Microsoft Business Central の購入価格表は有効日を持ち、取引条件で適用を判断する。導入候補のデモでは、価格候補が二つあるときの選択順序を実際に表示してもらう。Microsoftの購入価格表

既存版を消す運用は避ける。訂正が必要なら新しい版を追加し、旧版の有効期間を閉じ、どのPOが旧版で確定したかを残す。ただし、使用するERPの標準仕様が必ずこの構造という意味ではない。重要なのは、ある日付・伝票について「当時何が承認済みだったか」を再現できることだ。CSV取り込みやAPI連携にも、同じバリデーションと監査ログをかける。画面からの入力だけを厳しくし、外部連携が価格を直接上書きできる状態では統制にならない。

発注残の単価変更を四つのケースで決める

発効日管理の設計は、発注残の扱いが決まって初めて実務に使える。次の四ケースをサンプルPOで試す。

ケースA：発効日前に発注し、全量が発効前に入荷済み。 原則として既存のPO・受入・請求の合意価格を保持する。仕入先が後から別条件を提示したなら、通常のマスタ改定に混ぜず、個別の訂正・追加請求として承認する。入荷履歴を新単価で無言更新しない。

ケースB：発効日前に発注し、全量が未入荷。 改定契約が「納入日基準」であれば変更対象になり得る。「発注日基準」なら旧価格のままかもしれない。契約文言と仕入先確認を基に決め、変更注文を発行する場合は旧版と新版を保存する。口頭で合意した後にPOだけ旧単価のまま残すと、後の請求差異に原因が移るだけだ。

ケースC：一部受入済み・一部未納。 受入済み数量と未納数量を固定し、適用対象を行単位または分割行で表現する。たとえば100個のうち40個受入済み、60個未納なら、単価改定対象は条件によって60個以下である。輸送中や検収保留の数量がある場合はさらに分ける。システムが一つのPO行に異なる単価を持てないなら、発注行の分割、残数取消と再発注、変更注文のどれが監査と仕入先運用に合うか比較する。

ケースD：発効日以降の新規発注。 承認済み価格版を自動候補として表示する。ただし通貨、単位、数量帯、工場を含む条件が一致しない場合は自動適用せず、購買が根拠を確認する。暫定発注や緊急発注を認める場合は、例外コードと事後処理期限を付ける。

この四ケースを「PO日×入荷状態×契約基準」のテスト表として保存する。画面の説明を聞くだけでなく、サンプルPOを登録し、改定申請、承認、変更注文、入荷、請求まで一続きに操作する。Oracle は変更注文によって承認済み文書の新しい版を作る流れを説明している。製品選定では、その版が仕入先へ通知されるタイミング、発注残数量の扱い、会計への渡し方まで見る。Oracleの変更注文

承認履歴は「誰が押したか」だけでは足りない

仕入価格の承認履歴には、申請理由と代替策が必要だ。値上げの理由が原材料、為替、輸送費、仕様変更、数量変更のどれかによって、判断者も交渉余地も変わる。仕入先通知に書かれた理由をそのまま事実認定するのではなく、通知の主張として保存し、自社が確認した根拠を別欄に記録する。原価影響を試算する場合は、対象数量、対象期間、換算率、為替の前提を明記し、シナリオ値と実績値を混同しない。

承認経路は改定率だけで決めない。単価が小さくても大量発注品なら総額影響は大きい。反対に率が大きくても年数個の保守部品なら承認階層を増やす意味は薄い。少なくとも「価格差×見込数量」による期間影響、年間購買額、顧客への価格転嫁可否、生産停止の代替リスクを判断材料にする。金額の閾値は自社規程で定め、記事の例を標準値として採用しない。

承認後に価格や発効条件を修正したら、再承認の要否を判定する。承認済み案件の数値を直接修正して過去の承認画面が新しい数値を示す状態は避ける。変更前後の差分、変更者、変更日時、理由を残し、閾値を超える修正は再承認へ戻す。仕入先とのメール、署名済み合意書、改訂見積、PO変更の受領確認は改定IDで結び、担当者の個人メールボックスだけに置かない。

請求照合で価格差異を「原因別」に処理する

経理に届いた請求書の単価がPOと違うとき、すべてを「価格マスタが古い」として直してはいけない。原因には、①承認済み改定だがPO変更が未反映、②仕入先が未合意の新価格で請求、③単位・通貨・数量帯の不一致、④運賃・税・割引の扱い違い、⑤入力ミス、⑥受入日と発効条件の解釈違い、がある。差異コードを設け、購買、倉庫、経理の誰が次の処理を持つか決める。

Microsoft Dynamics 365 Finance の説明では、請求書、PO、入荷記録の照合で価格と数量を比較し、許容差を超えた不一致を識別できる。二点照合はPOと請求書、三点照合は入荷数量も含める。どの方式が適切かは品目や業務で変わる。実装時には許容差の割合だけでなく金額上限、通貨換算、部分請求、追加費用、端数処理をテストする。差異を許容範囲に収めるためにPO価格を後から変更する運用は、問題の記録を消してしまう。Microsoftの請求照合概要／照合設定の説明

請求を保留する場合、保留理由と解除責任者を見えるようにする。購買がPO変更を終えれば解消する差異と、仕入先の請求書再発行が必要な差異は異なる。差異を放置すると支払遅延の問題にもなるため、未処理件数、経過日数、金額、仕入先別の傾向を週次で見る。発生した差異から、価格改定フローのどこが抜けたかを振り返る。

タイ工場で押さえる運用上の境界

タイの工場では、現地仕入先のバーツ建て取引、日本・他国からの外貨建て取引、日本本社への報告が混在しやすい。だからといって、すべての価格を一つの通貨に換算してから登録する必要はない。契約通貨での原価格と会計・管理用の換算値を区別し、換算レートと評価日を記録する。請求照合はまず契約通貨と購買単位で比べ、為替差や会計換算差を仕入単価差と混ぜない。

英語の見積とタイ語の請求書で品名表記が異なることもある。比較の軸は翻訳された品名ではなく、社内品目コード、仕入先品番、PO番号、行番号とする。仕入先品番が変わる場合は改定申請に紐付け、旧番号との対応を残す。価格通知のメールを日本語へ要約するときも、発効条件に関わる原文と翻訳を並べて保持する。多言語表示ができることより、原文・合意文書・システム入力の三つが一致していることが重要だ。

会計、税務、輸入に関わる扱いは取引条件ごとに異なる。関税や税率の一般論から発注単価を決めず、自社の契約、インコタームズ、請求書、会計方針を確認する。システムに必要なのは、価格本体と諸掛の区分、通貨、発効条件、承認・変更の根拠を正しく残せることだ。法令の適用判断は担当専門家に確認する。

導入要件をRFPに落とすときの十二の質問

ベンダーへの質問は「価格改定機能はありますか」では浅い。デモ環境で次の十二項目を一つのシナリオとして実演してもらう。標準機能、設定、追加開発、運用回避のどれで実現するかをそれぞれ回答してもらえば、提案間で費用と責任範囲を比較しやすくなる。

1. 仕入先・品目・通貨・単位・数量帯ごとに旧新価格を版管理できるか。
2. 有効期間が重なる価格を登録したとき、警告・拒否・優先順位はどう動くか。
3. 発効条件をPO日、納入日などから選び、伝票へ記録できるか。
4. 価格通知、見積、合意メールを改定IDに紐付けて検索できるか。
5. 改定前後の金額影響を未納発注残から試算できるか。
6. 一部受入済みのPO行の未納分だけを変更できるか。
7. 変更注文の承認、仕入先通知、受領確認をどの版で管理するか。
8. 承認後の再修正で再承認と監査ログがどう動くか。
9. 入荷と請求の単価差を契約通貨・購買単位で照合できるか。
10. 差異を原因コードで分け、担当者と期限を割り当てられるか。
11. CSV・API・外部ERP連携からの更新にも同じ検証を適用できるか。
12. 過去時点の承認価格、PO版、受入、請求の関係を再現できるか。

この十二項目のうち特に見落としやすいのは6と7だ。多くのデモは新規POの作成を見せるが、実際の問題は既発行POの未納分に現れる。サンプルデータには、異なる通貨・単位、部分受入、輸送中、請求済み、承認待ちを含める。ベンダーの「できます」という回答は、実際にその状態を作って画面と出力帳票を確認して初めて採点する。

小さく始めるための実装順序

初期導入で全仕入先・全品目を一度に移行する必要はない。まず、過去に改定が多かった品目、購買額が大きい品目、発注残が長期に残る品目から試す。三つの選定軸で候補を並べ、仕入先数とPO件数が扱える範囲を選ぶ。初期対象を狭くしても、価格版と発注残の関係は本番同様に設計する。後から履歴を再構築するほうが難しいからだ。

第一段階では、価格改定申請、承認、証憑、版管理を整える。第二段階で発注残影響の抽出と変更注文を接続する。第三段階で入荷・請求差異の原因分類を接続する。各段階の完了条件は機能を入れたかではなく、テストケースを追跡できるかで決める。たとえば、通知書から改定IDを引き、承認版、対象PO、入荷、請求差異へ遡れることを確認する。

移行前のスプレッドシートに同じ品目・仕入先で複数の価格がある場合、最新行だけを正と決めない。通貨や単位が違うか、数量帯が違うか、古いPOの合意価格が残っているかを確認する。未決のレコードは「暫定」「確認中」として新規POへの自動適用から外す。データの整理と承認権限の整理を飛ばしてシステムだけ入れると、古い曖昧さが高速に複製される。

運用開始後の指標は、値上げを何件登録したかより、例外が減ったかを見る。具体的には、改定通知から承認までの日数、承認済み改定でPO未変更の件数、請求単価差異の件数と金額、差異解消までの日数、証憑のない変更の件数を追う。ただしゼロ件を無理に目標にすると差異の隠蔽を促す。最初は原因別の可視化と解消時間の短縮を目標にする。

ケースで確認する導入テストと合格条件

導入テストは、操作が終わったかだけで判定しない。どの証拠が画面と帳票に残ったかまで合格条件に入れる。最初のテストは、発効日をまたぐ注文を一件用意する。9月に100個を発注し、9月中に40個を受け入れ、10月に60個を受け入れる。改定通知は9月下旬、適用条件は「10月納入分」と明記されたものを使う。購買は通知を登録し、対象POを抽出し、未納分60個を見てから承認申請する。承認後、発注変更が仕入先に渡り、受領確認が残る。経理画面では40個の旧価格と60個の新価格に対応する請求が照合できる。これが一つの流れとして再現できれば、単なる価格表機能を超えて業務に使える。

次のテストでは、同じ9月発注100個でも適用条件を「10月以降の新規発注分」に変える。この場合、10月納入分60個は旧価格のままになる可能性がある。入力した発効日が同じでも結果が違うことを、システムがどう表現するかを見る。担当者が毎回手作業で価格を打ち直すだけなら、発効条件の管理機能は実質的にない。逆に、契約条件を無視して自動で新価格へ変えるなら、合意していない変更を生む。望ましいのは、自動候補の根拠と例外判断を両方残せる仕組みだ。

第三のテストは「一度承認した価格の訂正」だ。旧価格120、新価格130で承認した後、仕入先が計算ミスを認めて128に訂正したとする。130の承認記録を消さず、訂正通知を添付し、影響するPOと未処理請求を再抽出できるかを確認する。承認済み改定を無言で修正できてしまうなら、履歴から当時の判断を再現できない。再承認の要否は社内閾値によって異なるが、変更前後の値と理由は必ず残す。

第四のテストは、請求書に価格差があるが価格改定とは関係がない状態だ。たとえばPOは箱単位、請求書は個単位で、換算率の入力が誤っている。差異を「価格改定」として片付けず、単位の問題として購買マスタまたは請求入力を修正できるかを見る。差異原因コードを分ける理由はここにある。分類を間違えると、価格交渉が必要ない案件に時間を使い、本当の改定漏れが埋もれる。

第五のテストは、承認前の緊急発注だ。生産停止を避けるために発注を先行させる場合でも、誰が例外を許可し、暫定単価をどう設定し、いつまでに正式承認を完了させるかが必要になる。暫定POを出したまま正式価格が確定しなければ、入荷と請求で差異が繰り返される。例外は「後で誰かが直す」という自由記述ではなく、責任者、期限、解除条件を持つ未完了タスクとして表示する。

評価表には、各ケースについて「操作の可否」「必要な追加開発」「仕入先へ出る文書」「監査で再現できる証跡」「会計連携後の金額」を記録する。標準機能で画面上は動いても、帳票やAPIに新版が出なければ運用で破綻する。購買だけのデモで合格とせず、倉庫の受入担当と経理の照合担当も同じサンプル伝票を見て採点する。これが導入後に部門間で価格が食い違うリスクを減らす最も具体的な確認方法になる。

標準原価・調達管理全般とのつながり

仕入単価改定は標準原価の改定と同義ではない。購買契約価格を更新しても、会計上の標準原価や評価方法をいつ更新するかは別の意思決定になる。差額を原価へどう反映するかは、原価計算の方式と会計方針に従って決める。標準原価の目的、更新頻度、実際原価との差異の考え方は製造業の標準原価管理で整理している。本記事で扱うのは、その手前で購買と仕入先が合意した価格が、どの注文・受入・請求に適用されるかだ。

また、調達管理システム全体の機能と費用の判断は購買管理システムの選び方を参照したい。長納期部品では価格改定の途中に先行発注や設計変更が入るため、長納期部品の先行調達設計の論点も併せて見ると、発注残をどの時点で確定するかが明確になる。これらは範囲の異なる記事であり、仕入単価改定の個別条件は本記事の手順で定義する。

価格改定後に運用が崩れる三つの境界例

第一は、発注残の一部を別工場へ振り替える場合だ。元のPOではバンコク工場向けの100個を旧価格で契約していたが、50個を別工場へ直送すると、適用する価格表や運賃条件が変わることがある。数量だけを振り替えて単価を引き継ぐと、受入先では合意書を見つけられない。振替前後の工場、価格条件、受入場所、仕入先確認を一組に残し、元POと移動先POの関係を追えるかを確かめる。振替が価格改定に当たらない場合も、なぜ旧価格を維持したかの根拠が必要だ。

第二は、複数回の改定が短期間に重なる場合だ。最初の改定が10月1日、次の改定が11月1日で、仕入先が10月分をまだ請求していないとする。最新価格だけを残すと、10月納入分の請求を11月価格と誤照合する。価格版は取引時点で参照でき、入荷日と合意条件から当時の有効版を再現できなければならない。11月の改定を登録するときは、10月版の終了日を明示し、期間の重複と空白を検査する。承認が遅れて日付を遡らせる場合には、すでに確定した伝票への影響一覧を承認者へ提示する。

第三は、仕入先が価格改定と同時に品番や包装単位を変える場合だ。旧品番の在庫が残り、新品番の発注も始まる過渡期には、価格差が仕様差か単位差かを切り分ける必要がある。品目統合を急ぐと、旧ロットを新単価で評価する誤りが起こり得る。新旧品番の対応、換算率、切替日、代替承認、在庫消化方針を改定案件に関連付け、購買と生産管理の双方で確認する。価格改定案件を閉じる条件にも、未納POだけでなく旧品番の未処理請求が残っていないかを含める。

これらの境界例では、システムが自動で正解を選ぶ必要はない。関係する注文と在庫を漏れなく示し、判断の根拠と担当者を記録できることが合格条件である。例外の決定を自由記述だけにすると、次に同じケースが出たとき再利用できない。判断した基準イベント、対象数量、承認者、仕入先合意、処理後の伝票版を構造化して残す。後から「その時点でなぜその価格だったか」を一つの改定IDから説明できるかを最終確認にする。

よくある質問

価格マスタを更新すれば発行済みPOも自動で変わりますか

製品仕様と設定次第だが、自動変更を前提に業務を設計しない。発行済みPOは仕入先との合意文書であり、変更対象と承認・通知を明示する必要がある。マスタ変更後、未納のどの行に影響があるかを一覧化し、契約基準に沿って変更注文を発行するか決める。

発効日は発注日と納入日のどちらを使うべきですか

普遍的な正解はない。契約・見積・合意メールの条件に従う。基準イベントが曖昧なら、発注残を含む適用範囲を仕入先と確認する。社内システムでは「発効日」と「基準イベント」を別の項目として持たせると、後から解釈を確認しやすい。

請求書だけが新単価のときはどうしますか

まずPO版、受入日、価格改定ID、合意書を照合する。承認済み変更がPOへ未反映なら購買の変更処理、未合意の請求なら仕入先への訂正依頼、単位や通貨の誤りなら換算・入力の修正に分ける。経理が差異を消すためだけにPOを上書きしない。

中小工場でも専用システムが必要ですか

改定頻度、発注残の量、仕入先数、監査要求による。まず同じ改定IDで通知・承認・PO・請求を追える運用を整え、既存ERPで実現できるか確認する。専用システムを選ぶのは、既存機能では発注残の分割や証憑追跡が継続的に手作業となる場合だ。

まとめ：一つの改定IDで「なぜその価格か」を再現する

仕入単価改定管理の成否は、価格を何秒で書き換えられるかでは測れない。発効条件、部分受入済みの発注残、仕入先との合意、承認版、入荷、請求差異を一つの改定IDで辿れるかが要点である。導入前には、少なくとも四つの発注残ケースを自社の伝票で試し、変更注文と請求照合まで実演してもらう。そこまで確認すれば、単価改定が「担当者のメールと記憶」に依存する状態から抜け出せる。

TOMAS TECHでは、タイ工場の購買・生産管理・会計の境界を整理し、既存システムへの追加、ERP連携、新規開発の範囲を一緒に検討している。現在の改定通知、発注残、請求差異の例を持ち寄っていただければ、適用境界と必要な記録から要件を整理できる。お問い合わせはこちら。

参考情報

• Microsoft Learn: Record special purchase prices and discounts — 品目・数量・単位・通貨・日付に応じた購入価格。
• Microsoft Learn: Purchase Price Lists — 購入価格表と有効日。
• SAP Help Portal: Time-Dependent Conditions — 購買条件の有効期間。
• SAP Help Portal: Conditions in Info Records — 購買情報レコードの条件変更。
• Oracle Fusion Cloud Procurement: Change Orders — 承認済み購買文書の変更版。
• Microsoft Learn: Accounts payable invoice matching overview — PO・入荷・請求の照合と価格差異。
• Microsoft Learn: Set up Accounts payable invoice matching validation — 許容差と二点・三点照合の設定。