はじめに整える部分
- 仕入先への発注台帳
- 分納・未着の確認
- 受入確認
想定例：10個の発注で、届いた8個と未着2個を追う
発注を確定
承認した数量と注文をそろえます。
- 品目
- 部品X
- 発注数
- 10個
- 仕入先
- 仕入先A
P-40を発注2回の分納この例の要点
到着を明細へ追加します。
- 1回目
- 6個
- 2回目
- 2個
- 到着累計
- 8個
未着2個受入を確認
到着後の確認待ちを分けます。
- 受入確認済み
- 6個
- 到着・未確認
- 2個
- まだ未着
- 2個
確認待ち2個
- これまで
発注後の残りを、注文書から調べる
これから届いた数と未入荷の数が分かる
あとから広げる部分
- 請求との連携
- 仕入先への送信
発注送信・支払実行は条件を分けて決めます。
- 発注明細
- 数量を扱う単位
- 確認
- 承認する流れ
- 返品
- 受入後の変更の扱い
- 請求
- 明細と突き合わせる範囲
開発費用の目安を確認できます。
質問に答えて、必要な範囲を整理できます。
発注台帳を整える
- 向いている状況
- 発注が少なく、担当者が未着と受入を照合できる
- 確認すること
- 分納後も残りを残し、到着と検品を分ける
既製の購買製品を使う
- 向いている状況
- 承認・分納・受入が既製の購買製品に合う
- 確認すること
- 返品、仕入先との受け渡し、請求照合を確認する
自社の購買手順に合わせて作る
- 向いている状況
- 案件や工程ごとに異なる購買確認を整えたい
- 確認すること
- 発注・未着・受入から始め、送信や支払は条件を分ける
届いたら発注完了になりますか
全数量の到着と受入確認を分けます。分納なら未着が残り、到着していても確認待ちの数量を残します。
承認後に数量を変えられますか
変更前後と理由を記録し、再承認が必要な条件を決めます。承認された内容と仕入先へ確定した注文を区別して照合します。
仕入先へ注文書を自動送信しますか
まず申請・発注・受入の記録を対象にします。送信が必要なら、宛先と注文内容の確認、送信後の結果確認を含めて範囲を決めます。
- 相談時
こんな不安に
要望をうまく説明できない
本番トライアルなら
つくる人に、
直接相談 
お客様とエンジニア つくるエンジニアが直接お話を聞き、ふだん使っているExcelや紙の書類を一緒に見ます。何をつくるかは、当社がまとめてご提案します。
- 開発中
こんな不安に
使う前に、
細かいところまで 決められない 本番トライアルなら
見ながら決める
何のために、どこまでつくるかを最初に決めます。細かなところは、動く画面を見ながら一緒に決めます。
- 完成時
こんな不安に
業務に合うかは、
使ってみないと 分からない 本番トライアルなら
業務で試して
判断 
業務で確認 完成品をふだんの仕事で使いながら、続けるかを決められます。
- 納品後
こんな不安に
使ってから
直したくなったら、 また費用がかかりそう
頭金は1割
完成・検収までは、初回分以外のお支払いはありません。
残りの開発費は基本12回
残りの開発費は、完成・検収の翌月から基本12回でお支払いいただきます。
終了のご連絡
終了したい月の前月末までにご連絡ください。ご希望の月末で終了します。
終了とデータの受け取りを確認する
代表取締役・エンジニア
影山 湧亮
筑波大学卒。警視庁で約10年間勤務し、本部で経済安全保障対策や情報の収集・分析に従事。
前職ではフルスタックエンジニアとしてWebアプリケーション開発に従事。その後、要件定義からAWSでのインフラ構築までを一人で担い、商用サービスを企画・開発・リリース。
現在は、生成AIの活用・社内のAI利用ルールづくり・業務改善の相談から、Webアプリや業務システムの開発まで担当。
エンジニアの紹介と会社情報を見る開発のご相談からご提案・お見積りまで、完全無料で承ります。