商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方

当社が目指しているのは、規格書作成ソフトを一つ増やすことではありません。

商品マスタ、一括表示、製品規格書、取引先別様式、ラベル印刷が、同じ商品データを参照する状態です。

関連情報：ツールから選ぶと沼にはまる――小規模食品メーカーがAccessからブラウザDBへ進んだ理由

現在は同じ情報を複数回入力している

自社の規格書があっても、取引先から別のExcelやWebフォームを指定されることがあります。一括表示ラベルにも同じ原材料、内容量、期限、保存方法を記載します。

それぞれを別ファイルとして管理すると、変更時にどれが最新か分からなくなります。

一つのデータから複数の「表現」を作る

共通データには、商品そのものの事実と根拠を持たせます。

• 商品名、品番、JAN
• 原材料、配合、複合原材料
• 添加物、アレルゲン
• 内容量、期限、保存方法
• 製造所、販売者
• 栄養成分と算出根拠
• 包装資材、ラベルサイズ
• 規格書・原料資料の版と確認日

一括表示、規格書、取引先様式は、この共通データを別の並びや形式へ変換した「出力」として扱います。

他社テンプレートへ転記する難しさ

取引先ごとに、項目名、セル位置、選択肢、必須項目、記入単位が異なります。単純なCSV出力だけでは対応できないことがあります。

そこで、取引先書式ごとに次の対応表を持つ考え方があります。

自社の標準項目         取引先テンプレート
商品名          →     商品名称
内容量数値      →     規格・容量
内容量単位      →     単位
アレルゲン      →     特定原材料等
保存温度        →     保存条件
JAN             →     JANコード欄

ただし、他社のExcelやWebサービスの仕様が変更されれば、変換側も更新が必要です。また、相手先の利用規約やファイルの権利を確認し、無断でテンプレートそのものを公開しない配慮も必要です。

eBASEやインフォマートとの競合ではなく、役割分担

既存の規格書サービスには、取引先との商品情報共有や標準化という重要な役割があります。当社の社内DBは、それらを置き換えることだけを目的にしていません。

社内の商品情報を正本として整え、必要に応じて既存サービスへ入力・出力し、一括表示やラベル印刷にも再利用する。その間の転記負担を減らすことが目的です。

統合で重要なのは版と根拠

同じ商品名でも、原料規格、配合、ラベル、規格書が更新されます。単に最新値だけを上書きすると、過去ロットで何を使用したか確認できません。

商品、原料、配合、表示、規格書、ラベルテンプレートに版を持たせ、製造ロットと承認済み版を結び付ける必要があります。

関連情報：在庫管理で検証したBrotherブラウザ印刷を、一括表示ラベルへ転用できるか

これは一度に完成させるには重い開発です。そのため、まず商品情報と出力履歴をブラウザへ移し、次に原材料と表示を構造化し、その後に規格書統合を進めています。

この連載の記事

1. 第1回：ツールから選ぶと沼にはまる――小規模食品メーカーがAccessからブラウザDBへ進んだ理由
2. 第2回：食品表示と規格書をExcel・Accessで管理する限界――転記が増え続ける理由
3. 第3回：kintone・FileMaker・Exment・規格書サービスを検討して分かった――構想から逆算するツール選び
4. 第4回：なぜブラウザベースにこだわるのか――工場のPC・タブレット・OS依存を減らす設計
5. 第5回：Accessの商品マスタをPHP・MySQLへ移した――まだ「引っ越し段階」の食品表示DB
6. 第6回：在庫管理で検証したBrotherブラウザ印刷を、一括表示ラベルへ転用できるか
7. 第7回：何枚印刷したかを残す――ラベル履歴・ロット・商品情報を結ぶ設計
8. 第8回：一括表示を「私しか作れない」から「誰でも作れる」へ――食品表示DBの再設計
9. 第9回：商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方
10. 第10回：AIで長年の構想が動き出した――食品現場と技術を横断して組み立てる小規模DX