注文書の読み方には、取引先ごとのくせがある
取引先から FAX とメールで届く注文書を、人が読んで受注として登録し、在庫から引き当て、配車と引取の担当を決め、既存の倉庫・運送システムに入力していた。
注文書の様式は取引先ごとに違う。同じ会社でも店舗ごとに納品先のコードが違う。月間の定期注文書は1枚に1か月分が載っているが、出荷するのはその日の分だけ。品によって、重さで数えるものと箱で数えるものがある。こうした読み方のルールは、打ち合わせの場で実物の注文書を見ながら一つずつ確かめた。
受け取りと読み取りを分けた
注文書を受け取る段階では AI を呼ばず、原本を先に保存する。読み取りはその後に行う。添付ファイルごとに処理の状態を持たせ、メールが再送されても、処理が二重に走っても、受注を二重に作らないようにした。受注にならなかった添付は、人が画面で判断するまで未対応の一覧に残る。
確定するのは人
読み取った品名は、商品マスタと名寄せする。親会社の名前だけで納品先を決めると誤配送になるので、候補が複数あるときは担当者に選ばせる。在庫の引当は人が確認して確定し、配車について AI は提案だけを返す。確定したときにほかのシステムへ自動で送る機能は、運用の決まりができるまで有効にしていない。
作りながら分かったこと
AI に長い ID を渡すと、勝手に短くして返すことがあった。それ以来、受け取った値はそのまま持ち、AI にキーを書き換えさせない作りにしている。また、同じデータでも CSV と API では値の表し方が違った。CSV で動いていたからといって、API で同じように動くとは限らない。
AI の呼び出しごとに、使ったモデル・使用量・かかった時間・成否を記録している。費用と精度を見直すときの材料になる。