買いたいリクエスト型の調達の実務ガイド｜現場で起きやすい課題と誤解を分解する
買いたいリクエスト型の調達の実務ガイド｜現場で起きやすい課題と誤解を分解する
買いたいリクエストは、在庫一覧にない端末を探し、複数の売り手から供給提案を受けられる仕組みです。しかし、募集数量、上限、代替品、将来入荷、部分承認の意味が曖昧だと、調達を助ける機能が二重契約、過大調達、誤請求の入口になります。
特に注意したいのは、「買い手が納得しているから問題ない」という判断です。本人が超過調達を選べる業務でも、同時承認で想定以上に増える、予算権限者が確認していない、請求・保管能力を超える状態は防ぐ必要があります。本稿では、実務と実装で起きやすい14の誤解を、原因、影響、修正方法に分けます。
誤解1：商品が見つからなければ条件を広く書くほど提案が増える
「スマホなら何でも」「Bランク程度」「相場価格」のような募集は件数が増えても比較できません。売り手ごとに異なる機種、容量、品質、税送料を同じ提案一覧へ並べることになります。
必須条件、許容条件、代替条件を分けます。
- 必須：対応OS、管理機能、地域仕様、データ消去など
- 許容：色、軽微傷、分納など
- 代替：後継機、容量違い、別モデル
条件未確認を自動的に適合へせず、売り手に回答を求めます。自由文は用途説明に使い、比較項目は構造化します。
誤解2：希望価格を一つ表示すれば売り手に伝わる
希望価格が目標なのか、税抜上限なのか、送料込み総額なのかで意味が違います。数量別価格や将来入荷では単価も変わります。
価格は、単価、数量、小計、税、送料、手数料、通貨、有効期限に分けます。通常売買で0円・負値を受け付けません。上限超過提案を禁止するか、理由付きで比較可能にするかを決めます。
表示相場から希望価格を自動入力する場合も、単品出品と大口成約、状態、容量、時点をそろえます。販売相場を確認する結果は判断材料であり、調達上限を自動決定するものではありません。
誤解3：募集数量は常に超えてはいけない
600台を目標にし、条件が良ければ700台買う業務はあります。目標数量をハード上限として一律拒否すると、合理的な複数調達を妨げます。
ただし、無制限に承認してよいわけでもありません。target_quantity、maximum_quantity、approval_thresholdを分けます。上限なしでも、目標を超える時点で合計、差、予算・保管への影響を権限者へ示します。
超過承認を許す理由、承認者、日時、最大数量を残します。担当者の電話合意だけでシステム上限を外しません。
誤解4：複数承認の合計は画面で確認すれば安全である
二人の担当者が同じ画面で承認済み500台を見て、それぞれ200台のオファーを承認すれば、どちらも「目標600台まで残り100」と思っていても合計900台になります。
承認処理では、リクエスト行またはversionを排他し、現在の有効承認合計を再計算します。上限を超える場合は、一方を競合として止め、最新合計を再表示します。
上限超過を明示承認できる場合も、競合後に自動承認せず、新しい合計へ同意を取り直します。有効承認から取消・辞退を差し引いた数量も監視します。
誤解5：同じアカウントでなければ自己オファーではない
同一企業の買い手担当がリクエストを作り、別の売り手担当アカウントで提案すれば、user_idは違っても自己取引です。架空実績、相場操作、請求作成へつながります。
作成者・売り手をorganization_id、案件所有者、関連組織で確認します。作成API、オファーAPI、承認APIのすべてで防ぎます。画面ボタンを隠すだけでは直接リクエストを止められません。
関連会社間取引を業務上許す場合は、関係性、利益相反、承認者を明示し、一般市場の価格統計・実績へどう含めるかを決めます。
誤解6：オファーを受けた時点で売り手在庫を確保すべきである
未承認オファーで在庫を減らすと、複数リクエストへの提案やいたずらで販売可能数が失われます。オファー提出は供給意思であり、物理確保とは限りません。
一方、候補承認や契約後も確保しなければ、同じ在庫を通常商品、入札、別リクエストで重複販売できます。未確保、仮確保、契約確保、発送割当を分けます。
売り手は現在在庫と将来入荷を別に提示し、確認日時を持たせます。確保時には残在庫を同じ処理で更新し、競合すれば買い手へ最新数量を示します。
誤解7：将来入荷予定も現在在庫と同じ確度で比較できる
「翌月300台入荷予定」は、仕入契約済み、回収見込み、単なる営業予測で確度が違います。現在在庫と合算すると、調達不足が見えなくなります。
予定数量、確度区分、供給可能予定日、依存条件、最終確認日時を記録します。買い手の比較画面では、即納、確定予定、見込みを分けます。
将来入荷を契約へ含める場合、分納、遅延、代替、取消、支払時点を合意します。予定が外れたとき、通常の在庫不足として黙って期限を延ばしません。
入荷確度を担当者の主観だけで「高・中・低」にせず、仕入契約済み、出荷通知済み、回収計画、過去実績など根拠区分を持たせます。根拠の確認日が古くなったら買い手へ警告し、契約前に再確認します。
予定どおり入らなかった数量を、同じ売り手の別機種で自動充当しません。代替提案を新しいoffer_lineとして作り、仕様、価格、納期、買い手承認を取り直します。予定数量の変更履歴を消さず、調達不足の原因として残します。
誤解8：代替機種は同等品として元数量へ足してよい
後継機や容量違いでも、対応OS、通信、管理、ケース、アプリ、電池、保証が異なります。安い代替を元機種と同じ行に集計すると、要件を満たしたように見えます。
requested_itemとalternative_itemを分け、必須差、運用費、設定作業を比較します。買い手が代替を承認した場合も、「希望400台・代替200台」のように内訳を残します。
代替提案の価格だけを元機種相場へ混ぜません。型番や地域仕様が未確認なら、安くても必須不適合として保留します。
誤解9：公開後の質問には個別回答した方が早い
一社にだけ「Cランクも可」「納期を一週間延長」と回答すると、他社は厳しい旧条件で提案し、不公平になります。電話・メール回答も価格判断へ影響するなら案件情報です。
共通条件を補う回答はQ&A版へ反映し、参加可能な全売り手へ同じ期間で再確認機会を与えます。特定売り手だけの個別条件は比較画面へ明示します。
重大条件変更では既存オファーを自動継続せず、売り手に再確認または新版提出を求めます。旧条件を見た提案と新版を混ぜて順位付けしません。
誤解10：期限を延長すれば既存オファーも自動的に有効である
オファーには在庫・価格の有効期限があります。リクエスト期限を一週間延長しても、売り手の提案が同じ条件で残るとは限りません。
リクエストdeadlineとoffer_valid_untilを分けます。終了後の再開では、数量、希望価格、品質、既存承認、売り手資格を確認し、提案の再確認を求めます。
期限処理は、古い期限を読んだ後に担当者が延長する競合を考え、「現在もOPENかつ期限値が一致」の条件付き更新にします。再開・一括再開を無条件更新にしません。
誤解11：総合点が高いオファーを自動承認すれば公平である
重み付き点数は比較を助けますが、必須条件を満たさない安価な提案が、他項目で高得点になることがあります。欠損値を0や平均で埋めると意味も変わります。
安全、データ、必須仕様、上限価格など強制ゲートを先に通し、その後に価格、納期、保証を比較します。点数には重み、入力、版、対象外を表示します。
人が順位を変える場合、元順位、変更理由、承認者を残します。過去の人の採用結果をAIの正解へそのまま使わず、利益相反や慣習の偏りを確認します。
点数の改善だけを担当評価へ使うと、欠損値を都合よく入力したり、必須条件を許容条件へ変える動機が生まれます。採用後の納期遵守、受領一致、品質差、請求訂正を元の提案と評価版へ戻し、点数が実際の履行を予測したかを確認します。
新規売り手は実績母数がないため、一律に最低点へせず、少量契約、追加証拠、前払い条件など別のリスク低減策を使います。古い実績は期間と件数を示し、異議申立て・訂正の経路を設けます。
誤解12：候補承認後ならスタッフが条件を自由に修正できる
スタッフが状態確認後に数量や交渉価格を無条件更新できると、同時に契約・請求が確定した後で商談内容だけ変わる可能性があります。
契約前は商談版として差分を作り、現在versionを条件に更新します。別処理が先に進んでいれば競合として最新条件を再表示します。
契約・請求後は元条件を直接編集せず、変更提案、当事者再承認、請求訂正へ進めます。担当案件以外の変更・請求再生成をAPIで認可します。
IPAのアクセス制御や認可制御の欠落に関する解説も参考に、役割だけでなく対象案件・組織・担当を検証します。
誤解13：候補承認したオファー全体を請求へ渡してよい
売り手が複数品目を提案し、一部だけ商談・契約した場合、元オファー全体を請求へ渡すと過請求になります。通知にも非採用品目・金額が載る可能性があります。
offer_line、approved_line、contract_line、invoice_lineを分けます。請求・通知は確定contract_lineだけを参照します。
請求生成時に、契約状態、価格版、数量版、既存請求を同じ処理で確認します。再生成は担当・経理権限、理由、旧版を残します。送信成功と発行済み状態も分けます。
誤解14：データ消去や安全は受領後に確認すればよい
未消去端末や膨張端末を通常便・通常棚へ入れてから確認すると、個人データ閲覧や発煙リスクが広がります。リクエスト条件、売り手申告、発送前確認、受領隔離をつなぎます。
個人情報保護委員会の機器内データ消去に関する注意喚起を確認し、消去方式、対象ID、成否、失敗隔離を記録します。「初期化済み」の自由文だけで完了にしません。
膨張、発熱、焼損、浸水等は通常品と分け、輸送可否を運送事業者・関係基準に従って確認します。受領後の減額だけで安全隔離を解除しません。
ケーススタディ：目標600台へ三人が同時承認する
買い手は目標600台、上限800台で募集し、既に400台を候補承認しています。オファーA・B・Cは各200台です。三人の担当が同時に承認画面を開き、各自は「上限まで400台」と見ています。
単純更新の結果
三件すべてが成功すると承認合計1,000台で上限を200台超えます。画面側で残数を表示していても、APIが現在合計を固定しなければ防げません。
安全な処理
リクエストversionを条件にし、一件目Aの承認後にversionと合計を更新します。Bは最新合計600台に対して承認し800台になります。Cは競合で止まり、「現在800台、提案200台、承認後1,000台」と再表示します。
買い手が上限を1,000台へ変更するなら、予算・保管権限者が新版を承認し、Cのオファー有効性を再確認してから処理します。
検証する不変条件
- 有効承認数量がmaximum_quantityを超えない
- 超過許可がある場合は承認者・上限版がある
- 契約数量が売り手確保数量を超えない
- 取消戻入後の合計が一致する
- 請求数量が確定contract_lineと一致する
二つ以上の実APIリクエストを同時送信し、片方が競合で止まること、途中の商談・通知・請求が残らないことを確認します。
隔離環境で再現するテスト
単体関数だけでは、認可、同時実行、送信待ち、請求の境界を証明できません。テスト用DB、買い手組織、売り手A・B・C、スタッフ、経理を用意し、外部メール・LINEは模擬受信箱へ固定します。本番の取引・ユーザー・通知は使いません。
- 買い手組織が自分のリクエストへ提案する
- 担当外スタッフがIDを変更して詳細・請求を取得する
- 二件のオファー承認を同時送信する
- 期限延長と自動終了を同時実行する
- オファー撤回と候補承認を同時実行する
- 在庫確保と別商品商談を同時実行する
- 一部品目だけ契約し通知・請求を生成する
- 契約変更と請求生成を同時実行する
- 通知送信をタイムアウト・再試行する
- 受領・検収差から請求を訂正する
合格判定ではHTTP応答だけでなく、承認合計、在庫確保、商談件数、請求行、監査ログ、送信待ち件数を確認します。競合で失敗した処理から中間データや外部通知が残らず、再試行後も一件だけ確定することを確認します。
定期監視では、「有効承認が上限を超えない」「自己組織の提案がない」「契約数量が確保数量を超えない」「請求行が契約行と一致する」を検査します。不整合を見つけても履歴を自動修正せず、対象取引を保留して原因を調べます。
監視処理そのものが停止していないかも確認します。最終成功時刻、検査対象件数、失敗理由を運用画面へ出し、異常ゼロと未実行を区別します。修正後は同じ競合シナリオを再実行し、別の状態遷移へ副作用がないことを回帰確認します。
結果は担当者と監査者が共同で確認します。
監査・改善チェックリスト
- 必須・許容・代替条件を分けた
- 希望価格の単位・税送料・上限を示した
- 目標数量と最大数量を分けた
- 超過承認に権限者と明示確認がある
- 同時承認をversion・排他で制御する
- 自己オファーを組織単位で拒否する
- 未承認提案で在庫を減らさない
- 契約時に在庫を二重配分しない
- 現在在庫と将来入荷を分ける
- 代替品を元機種数量へ自動加算しない
- 共通Q&Aを全売り手へ同じ版で示す
- リクエスト期限と提案期限を分ける
- 必須不適合を総合点で隠さない
- 商談変更をversionと再承認で行う
- 請求・通知を確定品目だけから作る
- データ・安全未確認を通常工程へ流さない
まとめ：柔軟な調達ほど、上限と版を明確にする
買いたいリクエストは、複数社から柔軟に端末を集められます。だからこそ、目標数量と上限、現在在庫と将来入荷、希望品と代替品、候補承認と契約を分ける必要があります。
超過調達を業務上許しても、同時承認で意図せず上限を超える経路は止めます。自己オファーを組織単位で防ぎ、期限延長や重大変更ではオファー版を再確認します。総合点より必須の安全・データ・仕様ゲートを優先します。
商談・請求・通知は確定した品目と数量だけへ結び、契約後の無条件編集を避けます。柔軟性とは条件を曖昧にすることではなく、買い手が意図した例外を権限・版・証拠付きで選べることです。
