背景
澤井製作所向け仕様書(docs/qr-barcode-spec-analysis.html、Git 管理外)の 7 章に、第 3 の仕向地「デンソー」のコード体系を現場写真 9 枚(かんばん 7 枚・現品票ラベル 7 枚、2 品番 3 箱 + 4 箱)のデコード結果から追加した。現行アプリは 澤井製作所(66 桁 QR・4-2-4@管理コード)と モルテン(61 桁 QR・4-2-3/4-2-4@管理コード)だけを受理するため、デンソーのかんばん・ラベルは読取段階で弾かれる。
デンソーの事実(7 組すべてで検証済み):
かんばん QR は 221 文字、QR 型番 7・誤り訂正 M・英数字モード。JAMA 自己記述形式 : JAMA + 版 1 桁 + ヘッダ長 4 桁(この欄から項目定義末尾まで)+ 前置き 10 文字 + 項目番号3桁+桁数2桁 × 21 + 固定長データ部 97 文字。
項目: 100=帳票区分 20、104=部品番号 10 桁 (ハイフンなし)、111=包装、112=収容数 、121/127=次区、124=指示、152=かんばん連番(箱ごとに固有) 、402=管理番号、519=納入日 YYYYMMDD、520=便、521=指示数(= 収容数 × 箱数)、523=アイテムNo、401=受入 ほか。
現品票ラベルの Code 128 は 860150-7722@1DZ50O: 品番 6-4(10 桁)@ 6 桁管理コード 。ハイフンを除いた品番は QR 項目 104 と一致する。
公式の JAMA・JAPIA 標準帳票ガイドライン V10.20 の QR は DI 方式([)>RS06GS…)で、この項目番号方式は公開表に無い。項目名はかんばんの印字から突き合わせた。
決定事項(仕様書 7.5、2026-09-07)
重複判定キー: QR 全文 (かんばん連番が箱ごとに違うため)。澤井製作所と同じ方式。
箱の数え方: 品番ごとの N 箱目 (澤井製作所と同じ)。予定箱数(指示数÷収容数)は表示せず、履歴詳細と PDF の項目として残すだけ。完了判定はしない。
QR の受理条件: JAMA 自己記述形式を汎用解析 (221 文字固定にしない)。ヘッダ長と項目定義を解析し、項目 104・112・152 があれば受理。
仕向地の混在は不可(既存のセッションロックをそのまま適用)。
呼称は デンソー / Denso 、永続化 id は denso。
テストが参照する既存文言は変更しない。澤井製作所・モルテンの挙動は変えない。
共通設計
Destination に denso を追加。detect は denso を最初に判定 (JAMA 先頭 + 解析成功)→ sawai → molten → trim 後 sawai。理由: KanbanQRRecord.parse は寛容で JAMA501195… をカード番号として通してしまう。
DensoKanbanRecord / DensoKanbanQrRecord: ヘッダ長・項目定義リスト・データ部の桁合計を検証し、項目 104(部品番号)・112(収容数)・152(かんばん連番)を必須とする。全項目の生値も保持する。
Code 128 の形式検証は仕向地ごと: sawai 4-2-4、molten 4-2-3/4-2-4、denso 6-4 。未確定時は 3 つのいずれか。
品番表示は仕向地依存(format(partNumber:destination:)): denso の 10 桁は 6-4。
箱識別子は sawai と同じ「正規化 QR 全文」。Room・履歴 JSON の変更は不要(destination は文字列)。
やること(PR 順、子 Issue)
iOS/Android: 共通フィクスチャと照合コアに仕向地「デンソー」を追加する(JAMA 自己記述 QR・6-4 品番) #107 共通フィクスチャ + 照合コア(iOS/Android、shared/** は両 CI を起動するため同 PR)
iOS: スキャナ画面と履歴ストアをデンソーに対応させる(6-4 表示・デモ・フローテスト) #108 iOS 仕向地ロック・読取ゲート・結果表示・デモ
iOS: 履歴詳細と PDF にデンソーのかんばん項目を記載する #109 iOS 履歴詳細・PDF・JSON
Android: ScanReducer と画面をデンソーに対応させる(可変長 QR の長さ案内・6-4 表示・計測テスト) #110 Android Reducer・画面・計測テスト
Android: 履歴詳細と PDF にデンソーのかんばん項目を記載する #111 Android 履歴詳細・PDF
iOS/Android: 仕向地デンソー対応の docs を更新し、実物のかんばん・ラベルで通し確認する #112 docs 更新と実物での通し確認
受け入れ条件
背景
澤井製作所向け仕様書(
docs/qr-barcode-spec-analysis.html、Git 管理外)の 7 章に、第 3 の仕向地「デンソー」のコード体系を現場写真 9 枚(かんばん 7 枚・現品票ラベル 7 枚、2 品番 3 箱 + 4 箱)のデコード結果から追加した。現行アプリは 澤井製作所(66 桁 QR・4-2-4@管理コード)と モルテン(61 桁 QR・4-2-3/4-2-4@管理コード)だけを受理するため、デンソーのかんばん・ラベルは読取段階で弾かれる。デンソーの事実(7 組すべてで検証済み):
JAMA+ 版 1 桁 + ヘッダ長 4 桁(この欄から項目定義末尾まで)+ 前置き 10 文字 +項目番号3桁+桁数2桁× 21 + 固定長データ部 97 文字。20、104=部品番号 10 桁(ハイフンなし)、111=包装、112=収容数、121/127=次区、124=指示、152=かんばん連番(箱ごとに固有)、402=管理番号、519=納入日YYYYMMDD、520=便、521=指示数(= 収容数 × 箱数)、523=アイテムNo、401=受入 ほか。860150-7722@1DZ50O: 品番6-4(10 桁)@ 6 桁管理コード。ハイフンを除いた品番は QR 項目 104 と一致する。[)>RS06GS…)で、この項目番号方式は公開表に無い。項目名はかんばんの印字から突き合わせた。決定事項(仕様書 7.5、2026-09-07)
denso。共通設計
Destinationにdensoを追加。detectは denso を最初に判定(JAMA先頭 + 解析成功)→ sawai → molten → trim 後 sawai。理由:KanbanQRRecord.parseは寛容でJAMA501195…をカード番号として通してしまう。DensoKanbanRecord/DensoKanbanQrRecord: ヘッダ長・項目定義リスト・データ部の桁合計を検証し、項目 104(部品番号)・112(収容数)・152(かんばん連番)を必須とする。全項目の生値も保持する。4-2-4、molten4-2-3/4-2-4、denso6-4。未確定時は 3 つのいずれか。format(partNumber:destination:)): denso の 10 桁は6-4。destinationは文字列)。やること(PR 順、子 Issue)
shared/**は両 CI を起動するため同 PR)受け入れ条件
6-4のラベルが両 OS・カメラ/BCST-47 で一致するshared/test-fixtures/matching-cases.jsonに denso ケースが入り、Swift / Kotlin 双方が同じ結果を返すdocs/PRODUCT_SPEC.md・CLAUDE.md・各 OS の docs が仕向地 3 つの仕様を記述し、仕様書 7 章に対応状況と実機確認結果が入る