==========================================================================
zsystem.jp 作業記録 2026年6月
==========================================================================

--------------------------------------------------------------------------
2026-06-01  個品別期間在庫 画面の Web 化（letip/uniqueperiodstock/）
--------------------------------------------------------------------------
目的・背景:
  Xojo製デスクトップアプリ「ZsystemDESKTOP」の業務システムリプレイスの一環。
  デスクトップ画面「個品別期間在庫」(UniqueIOWnd) を letip(メルシーダイキ)
  向けに Web 化した。指定期間における個品ごとの在庫/レンタル推移を一覧する画面。

移植元:
  ~/Library/CloudStorage/Dropbox/Document/Zsystem client/zsystemDESKTOP/
    400.個品管理/UniqueIOWnd.xojo_window の readLog（実行ボタンが呼ぶ最新版。
    readLog1/3/4 は旧版で未使用のため移植対象外）

作成ファイル（新規）:
  letip/uniqueperiodstock/index.php  … UI（開始日/終了日/資産区分＋実行＋CSV保存
                                        ＋ソート可能テーブル）
  letip/uniqueperiodstock/list.php   … JSON API（readLog ロジック移植）

使用テーブル:
  uniquecodetable（個品マスタ。ownerid/ownername もここ。PDTには ownerid 無し）
  ProductDistributeTable（PDCode で結合。Standard/ProductName/Kind）
  pack_archive（divisioncode 日次スナップショット, packno）… 基準在庫
  tasklog（timestamp/uniquecode/dstpackno/personid/asset/deleted）… 期間内移動
  person（personid → name で作業者名解決）

ロジック要点:
  1. 開始日以前の最新 divisioncode を基準スナップショットとする
  2. 個品マスタを ownerid で絞り込み（資産区分プルダウン）
  3. 基準時点の packno 取得。先頭"8"以外 = 在庫中(繰越)、"8"始まり/空 = レンタル中
  4. 期間内 tasklog を時系列に並べ、各移動を1行出力。先頭に繰越/レンタル中行、
     連続イベント間の 日数・時間 を算出
  出力列: No./資産区分/ATI個品番号/顧客個品番号/型式/商品名/品種/日時/P.No/
          日数/時間/備考

デスクトップ版からの調整点:
  - 性能: 個品ごと約1.1万回クエリ → tasklog 期間一括取得＋PHP側グルーピングに
    集約（ローカルはリモートMySQLへネットワーク接続のためタイムアウト回避）
  - 堅牢化: pack_archive.divisioncode が slash(500万)/dash(33万)/junk(320) 混在。
    単純文字列比較だと '2024-03-05' < '2024/03/05' で基準日を誤判定し得るため、
    DISTINCT(612件)を YYYY-MM-DD に正規化してから比較・選定
  - tasklog.deleted=0 で削除ログを除外（デスクトップ版は未フィルタ。ユーザー承認済）
  - 追加機能: 列ソート、ATI個品番号クリックで packviewer(履歴ビュア)を別タブ表示、
    CSV(UTF-8 BOM付)ダウンロード
  - PHP5.3互換で記述（?? / JSON_UNESCAPED_UNICODE 不使用）

備考:
  - 「日時」列はデスクトップ準拠で日付のみ表示（同日複数移動は日付同一）
  - 作業者は personid を name に解決して表示（デスクトップは生 personid）

デプロイ:
  zadmin@zsystem.jp:/Users/zadmin/Sites/letip/uniqueperiodstock/ へ scp。
  dir 755 / files 644。リモートPHP5.3 構文チェック・本番URL動作確認済。
  公開URL: https://zsystem.jp/letip/uniqueperiodstock/
==========================================================================

--------------------------------------------------------------------------
2026-06-03  個品別期間在庫 Web版 の機能拡張（備考の工程名化・作業者列分離 ほか）
--------------------------------------------------------------------------
目的・背景:
  6/1 初版をブラウザで運用確認しながら、デスクトップ版の見え方に寄せて
  備考・作業者・繰越表現を改善した。

index.php の変更:
  - 資産区分プルダウンの生成元を uniquecodetable.ownerid → AssetList
    （AssetCode/AssetName）に変更。デスクトップ版 ReadAssetsToMenu に準拠
  - デフォルト期間を「先月1日〜先月末」(date Y-m-01 / Y-m-t の -1month)に変更
  - 読み込み中スピナー（#status.loading::before）を追加
  - 「作業者」列を新設し、備考から作業者を分離（COLS に worker 追加）

list.php の変更:
  - mkrow に worker を追加し、備考(remark)と作業者(worker)を別列で返す
  - packno → 工程名 変換を追加（zgrouplist_expansion: groupcode → name）。
    P.No列はコードのまま、備考側に工程名を表示
  - 繰越/レンタル中（先頭）行の備考を精緻化:
      ・期間内に動きのある個品: 基準日より前の最終MOVログ(taskno='MOV')から
        「工程名（日付）」＋当該作業者を表示（prePeriodLog）
      ・期間内に動きの無い個品: pack テーブルに在れば現在packno＋工程名＋
        createdate、無ければ tasklog 最終ログの packno＋工程名＋日付
  - 全個品の最終 tasklog を JOIN（サブクエリ MAX(id)）で一括取得し、
    IN リスト肥大を回避（lastTasklog）
  - 基準日前の最終MOVは「期間内に動きのある個品のみ」を IN 句で遅延取得し
    負荷を抑制（prePeriodLog）
  - tasklog 期間の下限を ">" → ">=" に変更（基準日当日のログを含める）
  - 作業者表示を「name（personid）」形式に変更

デプロイ状況（2026-06-03 md5 比較）:
  - index.php: 本番反映済み（ローカル＝リモート md5 一致）
  - list.php : ローカルに未反映の変更あり（md5 不一致）。要再デプロイ。
    ※ index.php は worker 列を期待するため、list.php 未反映だと本番で
      作業者列が空になる。list.php の再デプロイが必要。
==========================================================================

==========================================================================
2026-06-04  ellio/arrival/ 画像パスのローカル/本番切替対応＋photoreceive.php同期

【背景・目的】
  ローカル開発時、ellio/arrival/ には invoiceimage/ の実画像が無いため
  入荷伝票（現品票）画像が表示できなかった。localhost アクセス時のみ本番
  (https://zsystem.jp/ellio/invoiceimage/) から画像を引くよう切替を導入。
  本番アクセス時は従来どおり相対パス ../invoiceimage/ を使い挙動不変とする。

【作業前のローカル/サーバー md5 比較で判明した差分（3ファイル）】
  - regist.php / regist.js : ローカルが新（今回の対応）。→ デプロイ対象
  - photoreceive.php       : サーバーの方が新しい改善版だった。
      ローカルは古いデバッグ版（相対パス・echoデバッグ残存・
      explode('[.]',…) バグ・エラー処理未導入）。
      → サーバー版をローカルへ取り込み（逆方向同期）。
        ローカル旧版は photoreceive.local-old-20260317.php.bak として退避。

【regist.php / regist.js の変更内容】
  - regist.php: HTTP_HOST に localhost/127.0.0.1 を含むかで $_isLocal 判定し、
      define('IMAGE_BASE_URL', 本番URL or '../invoiceimage/') を定義。
      <img src> 出力（GetPage / GetRegistTarget）を IMAGE_BASE_URL 経由に変更。
      Form() のテンプレ置換に [IMAGEBASEURL] → IMAGE_BASE_URL を追加。
      ※ opendir('../invoiceimage/') 等のサーバー側ディレクトリ読取りは
        ブラウザURLでないため従来どおり相対のまま（変更不要）。
  - regist.js : 先頭に var imageBaseURL='[IMAGEBASEURL]'; を追加。
      サムネ背景・拡大window.open・ナビ画像の3箇所を imageBaseURL 経由に。
      regist.js は Form() 内で file_get_contents → str_replace で
      プレースホルダ置換されるため、JS内 [IMAGEBASEURL] も確実に置換される。

【デプロイ前検証】
  - PHP構文チェック(php8.4) エラーなし／PHP5.3互換(strpos/define/三項のみ)OK
  - 本番は HTTP_HOST=zsystem.jp → IMAGE_BASE_URL='../invoiceimage/' となり
    出力は従来とバイト単位で同一（現場挙動に変化なし）。

【デプロイ・本番検証（2026-06-04）】
  - 現行 regist.php/js をサーバー上に *.bak-20260604 でバックアップ後デプロイ。
  - chmod 644／md5 ローカル一致（regist.php=68b0a1a9… js=444a3405…）。
  - curl 'regist.php?mode=openForm' で本番レンダリング検証:
      var imageBaseURL = '../invoiceimage/'; に正しく置換、
      未置換[IMAGEBASEURL]なし、PHPエラー混入なし。→ 正常稼働確認。

【残務】
  - サーバー: regist.php.bak-20260604 / regist.js.bak-20260604（問題なければ削除可）
  - ローカル: photoreceive.local-old-20260317.php.bak（不要なら削除可）
==========================================================================

==========================================================================
2026-06-04  ellio/arrival/ 入力フォーム フリーズ対策＋PackNo赤丸表示

【背景・目的】
  regist.php の入力フォームで、候補画像リストから登録フォームへ切替える際、
  画面が白いまま（入力欄が出ない状態で）一定時間フリーズする問題があった。
  ※フリーズは本番（現場端末）で発生。以前の画像width/height指定では未解決。

【原因の切り分け（計測込み）】
  - サーバー側は潔白: invoiceimage全走査(42,255件)=0.07秒、
    getActualList/getInvoiceInfo/getPage 応答も各0.03〜0.13秒と高速。
  - 真因はクライアント側: naviarea に「縮小版でなく原寸1.5MBの入荷伝票（現品票）画像」を
    ページ数ぶん挿入し、viewpainにも原寸画像。これらをブラウザが
    メインスレッドで同期デコード→フォームのペイントがブロックされ白画面化。
    width/height はレイアウト予約でデコードコストを下げないため効かなかった。
  ※invoiceimageは約4.2万枚・77GB、1枚約1.5MB。

【対策（regist.js / regist.php）】
  - viewpain大画像(GetPage, regist.php) と naviareaサムネ(regist.js) の<img>に
    decoding='async' を付与→デコードを非同期化し、フォームを先に描画。
    naviareaサムネには loading='lazy' も追加（画面外の同時読込抑制）。
  - 未使用の axios / Vue のCDN同期ロード2行を regist.js から撤去
    （regist画面では未使用。死んだ onSubmit/vm1 も削除）。

【併せて実装: PackNo赤丸表示（packdot）】
  - フォーム編集中、「画面遷移でpackテーブルに書き込まれる状態」なら
    PackNo入力欄の近くに小さな赤丸を表示。判定は WriteInfo() の実条件を
    厳密再現: packno非空 かつ NOT(変更なし かつ packテーブルに該当なし)。
    変更なし時のみ checkPackInvoiceno でpack存在を確認。
  - 更新タイミング: フォーム表示時(checksendfrom内) ＋ PackNo編集時(packcheck)。
  - 誤検知修正: 未登録(UNREGISTED)/対象外(NOTARGET)では packno が type=hidden
    のため、隠しフィールド時は赤丸を出さないガードを追加。

【ローカル開発の注意（今回判明）】
  - imageBaseURL(本番フルURL化)は画像の「表示URL」だけを本番に向ける。
    ページ数・ファイル存在の判定は getInvoiceInfo等が opendir で
    「ローカルの」invoiceimageを走査して行うため、ローカルに当該画像が
    無い入荷番号(例:6月分)は 0ページ表示になる。ローカル確認は
    ローカルに画像が存在する番号(2-3月分)で行うこと。

【デプロイ・本番検証（2026-06-04）】
  - 現行を *.bak-20260604b でバックアップ後、regist.php/regist.js をデプロイ。
    chmod 644／md5一致(regist.php=0a097e07… js=39f57104…)。
  - 本番出力で検証: viewpain画像に decoding='async'、axios/Vueの<script src>除去、
    hiddenガード反映、imageBaseURL='../invoiceimage/'、未置換[IMAGEBASEURL]無し、
    PHPエラー無しを確認。
  - 現場端末での体感確認は依頼中。改善不十分なら原因③(サムネonload高さ再計算
    ＋CSS transition:height 撤去)や根本対策(サーバー側サムネ生成)へ。

【残務（バックアップ）】
  - サーバー: regist.php.bak-20260604 / .js.bak-20260604（1回目デプロイ時）、
    regist.php.bak-20260604b / .js.bak-20260604b（2回目）。問題なければ削除可。
  - ローカル: photoreceive.local-old-20260317.php.bak。不要なら削除可。
==========================================================================

==========================================================================
2026-06-05  ellio/arrival/ 不具合修正（メーカー切替不能）＋letip 2件

【背景・目的】
  6/4 デプロイの regist.js で不具合報告。「右側の入力フォームが出ない／
  メーカー(納入元)を選び直しても切り替わらない」。6/4 の変更には IMAGE_BASE_URL
  対応だけでなく、axios/Vue 読込廃止・PackNo赤丸(packdot)機能追加という
  regist.js 大改修が含まれていた。

【原因（確定）】
  新規追加の snapshotFormValues() が document.inputform 内の全SELECT要素に
  対し onchange を「代入」で上書きしていた。納入元セレクト sendfrom は
  inputform 内にあり、元の onchange='checksendfrom()' が潰され、メーカーを
  変更してもフォームが再読込されなくなっていた（入力フォーム内の他セレクトは
  onKeyPress のみで無傷。onchange を持つのは sendfrom だけ）。

【修正内容（ellio/arrival/regist.js）】
  - snapshotFormValues(): .oninput/.onchange の代入を addEventListener へ変更。
    pdBound フラグで重複登録防止。既存の onchange='checksendfrom()' を温存し
    メーカー切替が復活。
  - checksendfrom 内 document.inputform.packno.focus() に存在チェック追加
    （packno欄なしの UNREGISTED/NOTARGET フォームでの JS エラー予防）。
  - 本番 arrival/ と開発版 arrivald/ の両方に適用（arrivald は openClip() 追加
    のみが本番との差分で、不具合は同一だった）。

【デプロイ（2026-06-05）】
  - arrival/regist.js を scp 転送、chmod 644、md5一致(ab037454…)を確認。
    regist.php は変更なしのため転送せず。
  - 6/4作成のロールバック用バックアップ(regist.*.bak-20260604)はユーザー判断で
    当面保持（新版安定確認後に削除提案）。

【letip/salesstock/stocklist/ Z在庫ロジック調査（中断）】
  - JAN 4967991412020 = productcode N090007 の Z在庫について調査。
  - Z在庫(zqty)は他列と別系統で、当月表示時は「live pack の現在qtyを
    productcode一致・JAN非空・対象店舗の販売品棚(GL.name=band)で合計」。
    過去月は pack_archive 翌月 divisioncode の期末在庫。
  - 実データ: 51612=5(雑色)+101787=1(川崎)=6。store=ALLならコードでも6を算出。
    雑色単独なら5。期末在庫(subtotal)はALL当月で5（期首5＋99999数量修正4件が
    ネット0）。「画面で5・本来6」の店舗/列の切り分け途中でユーザー指示により中断。
  - コード変更・デプロイなし（参照クエリのみ）。

【letip/packviewer/ チャートに数量表示】
  - 目的: 画面下部タイムラインチャートの各工程セルに、遷移してきた数量を
    「x N」形式で表示。
  - find.php buildTimeline(): 各フェーズ先頭サブログ(sublogs[0])の content から
    parseContent で '数量' を取得し、色付きセル内 PackNo の右隣に
    「x 数量」を太字表示（例: 51612 x 5）。数量なしログでは非表示。
  - PHP8.4 構文チェック済み。find.php のみ修正、デプロイ未実施（ローカル確認待ち）。
  - 別件: index.php がローカル(6/1)先行（CSS等）。今回対象外、デプロイ要否は別途。
==========================================================================

==========================================================================
2026-06-07  letip/packviewer/ チャートに「枝分かれ（部分移動）」表示を追加

【背景・目的】
  工程遷移(MOV)で元packの数量が0にならない場合、元pack(母体)は消えず残る。
  これは実態としては「母体から一部が分岐して出て行った」だけ。従来チャートは
  パック番号(先pack)が変わるたびに別セルを作るため、部分移動でも先packへ
  遷移したように見え、母体↔先packでセルが行き来していた。母体を主線として
  一本で表し、部分移動の先packは「分岐の事実のみ」を上方向の枝で表現したい。
  （枝先のその後は追わない）

【判定ロジック（find.php buildTimeline / moveRemainQty）】
  - MOVログの「MOVE:元pack 名称(残)ー＞先pack 名称(新)」末尾括弧の (残) を読む
    （グループ名の全角括弧（）は対象外、半角 (数字) のみ一致。取得不可時は
    元数量-数量 でフォールバック）。
  - 元pack==現在の母体(curPN) かつ 残>0 → 先packを現セルの「枝」に記録し
    主線セルを作らない(continue)。残=0(母体消滅)は従来どおり前向き遷移。

【表示（find.php / index.php CSS）】
  - セル上部に「枝帯」を新設。枝ボックス＝先pack番号＋数量(x N)＋グループ名、
    下に短い脚、枝のある帯のみ母体の横線(主線)を表示。
  - 枝はスクロールさせず、セル幅を枝本数分だけ拡張して親セル間隔を開ける方式。
    branchUnitW=76px(ボックス72+gap4)、cellW=max(128, 枝本数*76+8) を
    チャートフレームにインライン指定。タイムライン総幅は実セル幅の積算に変更。
  - タイムライン領域 155→216px、セル/コネクタ 144→208px、枝帯64px。

【検証】
  - ローカルPHPからリモートDB接続で find.php 実行（要 $_SERVER[REQUEST_URI]=
    /letip/... 設定。CLIだとzcommonのDB判定が落ちるため）。
  - 母体 101302 で: 主線195セル/枝692/枝帯70。枝なしセル128px、枝ありは
    768px等(最大1680px=枝22本)。枝帯にスクロール指定なし。JSON妥当。

【状態・申し送り】
  - find.php / index.php ともローカルのみ・未デプロイ（ローカル確認待ち）。
  - index.php は元々ローカル(6/1)先行＋今回CSS追加で、サーバーと差分大。
  - 先行実装「x 数量(母体セル)」(2026-06-05分)もこのfind.phpに含む。
  - 調整余地: 枝多数セルが横長(最大1680px)、グループ名折返し、枝ゼロ履歴でも
    上部64px帯が出る点（畳む対応は要望あれば追加）。
==========================================================================

--------------------------------------------------------------------------
2026-06-07  発注登録の商品取り違え訂正＋根本原因(空JAN誤マッチ)修正
            (letip/salesstock/buyingmng/)
--------------------------------------------------------------------------
目的・背景:
  メルシーダイキでウェルファン発注実績(2026/06/04, お客様発注番号WYT1434)を
  一括取込した際、「やさしい献立Ⅳ かまなくてよい16種16個セット」が
  「ベストポジションバー基本セット」として誤登録された、との訂正依頼。
  原データ(ウェルファン発注実績_20260604.xlsx)では当該商品のJAN欄が「なし」。

事象の特定:
  発注コード LZ001703 (= buyingCodeSupplier WYT1434, ウェルファン, 雑色店)。
  - 発注明細 buyingstocktable(id 5103): やさしい献立Ⅳ/S300064 … 既に正(再登録で修正済)
  - 入荷予定 pack(packno 101100): ベストポジションバー基本セット/J100027 … 誤りのまま残存
  発注明細だけ直され、入荷予定(pack)が初回の誤登録のまま取り残された状態だった。
  ※packno 101100 は2019年に別商品で使われた再利用番号。invoiceno='WYT1434' で限定特定。

データ訂正(本番DB letip, 実施済み):
  (1) pack packno 101100 (1件)
      productcode J100027→S300064 / productname ベストポジションバー基本セット→
      やさしい献立Ⅳ… / standard NBP-100-80→JANT7 / JAN 空→JANT7
  (2) tasklog id 1037781〜1037787 (7件, invoiceno='WYT1434'で限定)
      productcode J100027→S300064 (7件) /
      comment 商品名(id1037782)・productコード文字列(id1037784) を訂正
  ※packlog/personlog 等その他ログはユーザー指示により対象外。
  ※buyingstocktable は元から正のため変更なし。

根本原因(確定):
  商品マスター productDistributeTable に JANcode が空のレコードが2295件存在し、
  その先頭が J100027(ベストポジションバー)。JAN空のまま `WHERE JANcode='$jan'`
  を実行すると `WHERE JANcode=''` となり、常にこの誤行にヒットする。
  一括取込(registBulkOrder)は客先JAN「なし」をクライアントで空文字化(buyingmng.js:
  if(jan=='なし')jan='')して登録するが、registBulkOrder には空JANガードが無かった
  (単票 registOrderDetail には既にガードあり)。これが今回の取り違えの根本原因。

コード修正(buyingmng/index.php, ローカルのみ。未デプロイ):
  全て「空JANは商品/カタログ照合をスキップ」する多層防御ガード。PHP5.3互換。
  1. getKind(293)              空JANは即 '' を返す
  2. getBuyingItems(458)       空JANは kind 照会をスキップ
  3. getProductInfo(863)       空JANは即 'not found' を返す
  4. registOrderDetail(620)    新規登録時、空JANはカタログ照合せずフォーム名を保持
                               (catalogtable空JAN行8414件の先頭=ウェルファンWeb割値引き
                                への誤上書きを防止。テストで新規発見した同種リスク)
  5. registBulkOrder(1155)     空JANはマスター照合せず新規登録ルートへ(根本対策)

テスト:
  本番DB読み取りのみ(書き込みなし)で自動回帰テスト 16/16 PASS。
  修正後 getKind/getProductInfo は実コードverbatimで検証。非空JAN経路は無改変
  (SQL文字列は旧版と同一)、php -l 構文OK、'0'/null の境界も確認。

CustomersCode(品番)照合について(検討の上 見送り):
  無JAN品の重複PD抑止のため品番でマスター照合する案を検討したが、catalogtableは
  手動更新・複数仕入先混在でウェルファン品番はほぼ未登録(802024等0件)。最終的に
  JANが得られないと意味がなく、無JAN品には実効性なしと判断し実装見送り。

残課題:
  - 上記コード修正のデプロイ(scp)は未実施。ユーザー指示後に実施予定。
  - 副作用として、同一無JAN品の一括取込を繰り返すと新規PDが重複し得る(JAN無し
    商品の宿命)。実害が出たら品名統合等のデータ運用側で個別対応。
==========================================================================

--------------------------------------------------------------------------
2026-06-09  letip/schedule/ スケジュール画面のモバイル対応（レスポンシブ化）
--------------------------------------------------------------------------

【背景・目的】
  配送ルート可視化画面（左ペイン=担当者別スケジュール一覧380px固定 / 右ペイン=
  Google Map にマーカー・順路矢印線・担当エリアポリゴンを描画）を、スマホでも
  閲覧できるようにする。現状は #maincontainer が flex-direction:row 横並び固定の
  ため、スマホ幅(375px等)だと左ペイン380pxで画面が埋まり地図が見えなかった。

【方針（ユーザー承認済み）】
  - レスポンシブ（同一ファイル）方式。PC版は維持し、URL・デプロイ先も1つのまま。
  - モバイルは上下分割（上=地図 / 下=リスト）。ブレークポイント max-width:600px、
    上下比率 50:50。

【変更内容（ローカルのみ。未デプロイ）】
  1. schedule.html … 既存PC版CSSは無改変。末尾に @media (max-width:600px) を追加。
       - #menubar .title 非表示、span の margin-left リセット、日付＋担当者を1行に
         （メニューバー高さ40pxを維持 → 既存 calc(100vh-40px) がそのまま有効）
       - #maincontainer を flex-direction:column に。#mappane を order:1 height:50%、
         #schedulepane を order:2 width:100% height:50%（380px固定・右境界線を解除し
         上に border-top）
  2. schedule.js … initMap() 末尾に画面回転時の地図リサイズ対応を1行追加。
       window.addEventListener('resize', () => gMap && trigger(gMap,'resize'))

【ローカル確認環境・検証】
  - php -S localhost:8765 -t (zsystem.jpルート)、CWD=schedule（index.php が
    file_get_contents('schedule.html') を相対パス参照するため）で起動。
  - 認証は zcommon.php:412 の「Referer host=localhost かつ Cookie personid あり」
    でパス不要ログインが通る仕様を利用。person テーブルから group に150/300を含む
    personid=9000 を取得し、Cookie をセットする一時中継 _devlogin.php（JS遷移で
    Refererをlocalhost化）経由でアクセス。
  - headless Chrome でスクショ撮影し目視検証:
      モバイル390px … タイトル非表示+1行メニュー / 上下分割（上:地図 下:リスト）OK
      PC1280px     … タイトル表示 / 左380px+右地図の横並び2ペイン維持OK
  - 地図の「エラーが発生しました」は Google Maps APIキーの referer 制限で localhost
    が未許可なため。本番 zsystem.jp では表示される。レイアウト検証には影響なし。
  - 確認後、一時ファイル _devlogin.php は削除（rsync誤送信防止）、php -S 停止済み。
    schedule/ は index.php / schedule.html / schedule.js の3ファイルのみ。

【残務】
  - 続きは別マシンで実施予定（Dropbox同期で schedule.html/js の変更は反映済み）。
  - デプロイ(scp/rsync)は未実施。ユーザー指示後に実施。
  - 必要なら上下比率(50:50)・ブレークポイント(600px)の微調整、その他モバイルUIの
    追加対応を検討。
==========================================================================

==========================================================================
2026-06-10  letip/schedule/ 居宅介護支援事業所 住所の一括ジオコーディング

【目的・背景】
  スケジュール地図(letip/schedule/)は表示のたびに Google Maps JS の Geocoder
  で住所→緯度経度変換し geocode_cache に保存している。居宅介護支援事業所
  (party_title_types=5)の住所を事前に一括変換してキャッシュへ投入し、地図表示
  時のライブ変換を減らす。Google無料枠(Geocoding=Essentials SKU 月10,000回)に
  収まるか検討のうえ実施。

【件数・無料枠判定】
  - customertable type='居宅' = 1,137件 / 住所あり 1,081件
  - ユニーク住所(CONCAT(address,address2,address3)) ≒ 956件
  - 956 << 10,000(月) → 無料枠内(約1割)。課金なし。
  - customertable.latitude/longitude は全件0=未投入のため流用不可、変換が必要。

【方針】A案: customertable(居宅)のマスタ住所基準でキャッシュを網羅投入。
  ※地図側は tz4_schedules.party_address で引くため、表記揺れの事業所は
    地図ヒットしない可能性あり(投入後に必要なら点検)。

【変更ファイル】(scp個別デプロイ済 /Users/zadmin/Sites/letip/schedule/)
  - index.php : 新モード getOfficeAddresses 追加(居宅のユニーク住所をJSON返却)。
                権限は既存3モードと同じ CheckPermission('150') 群に追加。
  - schedule.js: bulkGeocodeOffices()/bulkGeocodeStep() 追加(コンソール実行用)。
                未キャッシュ分のみ変換 / 200ms間隔 / OVER_QUERY_LIMIT指数バック
                オフ / 50件毎に進捗ログ。既存の地図描画関数は無改変・末尾追記のみ。
                schedule.html は変更なし(恒久ボタンは付けずコンソール実行方式)。

【実行・結果】
  - Mapsキーはリファラ制限付き → サーバー側curl不可。本番画面で実行。
  - ブラウザ(本番 zsystem.jp/letip/schedule/)コンソールで bulkGeocodeOffices()。
  - 成功 929 / 失敗 0、既キャッシュ27 → 居宅956中954件キャッシュ済(99.8%)。
  - geocode_cache 総数 1,267。未マッチ2件は住所表記の微差/日次同期変動の可能性
    (実用影響軽微、必要時に潰す)。

【メモ】
  - 再実行すれば既キャッシュ分はスキップし続きから変換可能。
  - コンソールの loading=async未指定/Marker非推奨 警告は本件と無関係の既存表示。
==========================================================================

==========================================================================
2026-06-11  letip/schedule/ ログイン担当者の自動選択（person.properties連携）

【目的・背景】
  スケジュール地図(letip/schedule/)を開いた際、ログインユーザーがスケジュール
  担当者と同一なら、その担当者がドロップダウンで選択済みの状態で開くようにする。
  従来は常に先頭「全体」が選択されていた。

【担当者の紐付け調査結果】
  - スケジュール担当者は tz4_schedules.worker_id で識別。
    worker_id → tz4_tz4users.worker_id → party_id → tz4_parties.name(氏名)。
  - TZ4側で worker_id↔party_id 未連携が多数(tz4_tz4users 41行中 worker_id有18/
    party_id連携9)。直近90日の稼働 worker_id 13件のうち氏名解決可は7件のみ、
    残6件(5948=487件,5940,5938,5937,5939,5945)はTZ4側に氏名が無く自動突合不可。
  - 氏名が取れる8名は person と氏名(全半角スペース除去)で全件クリーン一致・
    多重該当0・person側同名衝突0。→ 氏名突合は氏名がある限り完全に信頼可。

【対応: person.properties に永続化】
  - person に properties(varchar255) を新設(ユーザー作成)。カンマ区切りの
    key=value 列を格納する汎用フィールド。
  - 氏名突合できた8名へ tz4workerid=<worker_id> を書き込み:
    9017=1601(小河) 9018=1602(齋藤) 9019=1603(長濵) 9026=5927(梨羽)
    9028=5930(保坂) 9056=5946(西村) 9060=5947(川畑) 9061=5949(田中)

【実装: index.php】
  - loginWorkerId() 追加: ログイン中personid(cookie優先/なければセッション)で
    person.properties を引き、カンマ区切りkey=valueをパースして tz4workerid を返す。
  - disp(): $myWorker=loginWorkerId() を取得し、担当者ドロップダウン(3 optgroup)で
    worker_id==$myWorker の option に selected を付与。未該当/未ログインは従来通り
    「全体」にフォールバック(後方互換)。

【テスト】
  - ローカルPHP→リモートletip直結で実コード実行: マッピング3名/未マッピング/
    未ログイン/パーサ(カンマ区切り複数キー・空白・欠落)全てOK。
  - 本番デプロイ後 実HTTP検証: 9028→5930 selected, 9061→5949 selected,
    0001(未マッピング)→selected無し=全体, アプリ正常描画。全OK。

【デプロイ】index.php を本番反映済(md5一致/chmod644)。schedule.js/html は変更なし。

【残運用】無名worker6件は該当personのpropertiesに手動で tz4workerid= を追記すれば
  同様に自動選択対象になる。
==========================================================================

==========================================================================
2026-06-13  backup/ packテーブルCSVバックアップ + Basic認証（システムダウン復旧用）

【目的・背景】
  システムダウン時の復旧用バックアップ。毎日0時過ぎに、その時点（前日終了
  状態）の pack テーブルを letip/ellio それぞれ CSV 出力し、zsystem.jp/backup/
  に置く。CSVには工程名フィールドを追加。/backup/ は Basic認証(koukoku/kouko9)。

【仕様・実装】
  - backup/packbackup_csv.php（cron用 CLIスクリプト, CLI専用ガードあり）。
    letip(letip/koukoku-lutip)・ellio(ellio/koukoku-ellio) 両DBに接続し、
    SELECT pack.*, zgrouplist_expansion.name AS 工程名
      FROM pack LEFT JOIN zgrouplist_expansion
      ON pack.packno = zgrouplist_expansion.groupcode
    を CSV 出力。groupcode一意で行増殖なし(検証済)。
  - 出力先は dirname(__FILE__) = /Users/zadmin/Sites/backup/ 自身。CSVは静的
    ファイルとして Apache が直接配信 → PHP/MySQL停止中でも取り出せる。
  - UTF-8 BOM付き(Excel対策)。一時ファイル→rename(配信中の半端読み取り防止、
    ダンプ失敗時は前回成功分が残存)。
  - backup/index.html: 静的リンクページ(letip.csv / ellio.csv)。
  - PHP5.3互換で記述(?? / アロー関数 / 型宣言 / fputcsv第5引数 不可)。

【工程名】
  ユーザー指示により zgrouplist_expansion を packno でリレーションし name
  フィールドが工程名に該当(extraction.php の immovable系と同じ結合)。

【ローカル検証】
  ローカルPHP→リモートDB直結で実行。fgetcsvで厳密照合:
  letip 9275レコード(=pack=join, 行増殖なし、工程名9266件付与/未登録packno9件空)、
  ellio 468レコード(工程名全件)。列数55(pack54+工程名)。
  ※wc -lでは9307行に見えるがcomment等のフィールド内改行を別行と数えるためで、
    CSVとしては正しい。

【Basic認証 — 当初の.htaccessは不可と判明】
  - /Users/zadmin/Sites は AllowOverride None のため .htaccess が無視される
    (実際に設置→認証なしで200=丸見えを実証)。
  - ★調査でApache二段構成が判明:
    ・/usr/local/apache2 (Apache 2.4.51) = HTTPS(443)・静的配信の実体。
      auth_basic/authz_user/authn_file/authz_core 全ロード済み。
      .phpは proxy:fcgi://127.0.0.1:9000 で PHP-FPM 5.6.40 に委譲。
    ・/etc/apache2 (macOS Apache 2.2.24) = :80 のHTTPSリダイレクト用。
  - 効く設定は /usr/local/apache2/conf/httpd.conf。443 vhost(:118〜、
    DocumentRoot /Users/zadmin/Sites, AllowOverride None)に <Directory> 追記:
        <Directory "/Users/zadmin/Sites/backup">
            AuthType Basic / AuthName "backup"
            AuthUserFile "/Users/zadmin/Sites/backup/.htpasswd"
            Require valid-user
        </Directory>
  - .htpasswd は koukoku:kouko9 (apr1)。ドット先頭ファイルは既定で403配信ブロック。

【デプロイ・実行】
  - backup/ を rsync (php/html) + scp(.htpasswd)。dir755/file644。
  - 初回手動実行で letip.csv 9275 / ellio.csv 468 生成(644、_www読取可)。
  - cron追加(zadmin):
      5 0 * * * /usr/bin/php /Users/zadmin/Sites/backup/packbackup_csv.php
        >> /Users/zadmin/packbackup_csv.log 2>&1
  - Apache設定変更(sudo, パスワードはSSHと同じ): バックアップ
    (httpd.conf.bak_20260614)→/tmp候補で httpd -t 構文検証→本番cp→
    apachectl -k graceful。
  - 検証(キャッシュバスター付き): ellio.csv/letip.csv/index すべて
    認証なし→401 / koukoku:kouko9→200。工程名列も確認。全OK。
    ※graceful直後の一瞬だけ旧ワーカーが旧設定(認証なし200)で応答する点に注意。
  - 無効化された .htaccess は削除(.htpasswd は AuthUserFile 参照のため残置)。

【メモ】
  - 既存 letip/packbackup.php(0:00, pack_archive へDB内退避)とは別物。今回のは
    工程名つき静的CSVのオフライン取り出し用。
==========================================================================

==========================================================================
2026-06-16〜17  letip/routeplan/ 新規作成（モニタリング期限ルート計画）
==========================================================================

【目的・背景】
  - 営業マンが「今後の営業予定」で動く経路の“ついで”に回れる、モニタリング期限
    が近い/超過の利用者宅を、事前計画段階で見つけやすくするツール。
  - schedule/（既存：当日スケジュールを地図にプロット）を複製して routeplan/ を
    作成し、モニタリング期限プロット層を追加する方針。
  - 当初は「現地で空き時間に近隣のモニタリング先を探す」案だったが、モニタリング
    先=利用者宅はアポ必須で現地思いつき訪問は非現実的 → 事前計画ツールに方針転換。
  - 担当者会議で兼任できないか調査 → サービス担当者会議に定期開催義務はなく
    (新規/更新認定/区分変更/変更時のイベント駆動)、ケアマネ主催・場所も事業所/
    電話/オンラインが多く「会議出席≠利用者宅モニタリング充足」。除外条件に使わない。

【作成・変更ファイル（すべてローカル。routeplan/ はサーバー未デプロイ）】
  - letip/routeplan/index.php / routeplan.html / routeplan.js
      schedule/ を複製しファイル名・参照を routeplan に変更。タイトル等の表示文言
      「スケジュール」→「ルート計画」。
  - letip/routeplan/routeplan_メモ.md … 構想・調査・確定クエリ・コスト等の作業メモ。
  - letip/tz4_monitoring_sync.php（新規・デプロイ済）… TZ4→letip.tz4_monitoring_due
      を日次で全件洗い替えするバッチ。

【DB / cron（letip 本番に反映済）】
  - letip.tz4_monitoring_due テーブル新規作成＋初回投入（2,933行）。
      user_party_id(PK)/user_name/user_address/user_phone/charger_party_id/
      charger_name/last_monitoring/monitoring_due/synced_at。idx_due, idx_charger。
  - cron(zadmin)追加: 30 3 * * * cd letip && php tz4_monitoring_sync.php
      （毎日3:30 JST、既存3:00 tz4sync と非重複）。

【モニタリング抽出ロジック（確定）】
  - 期限 = 実施履歴あり MAX(fy_monitoring_options.execution_date)+6M /
           なし care_rentals.tz4date2_begin+6M（scheduled_date 不使用）。
  - 母集団絞り: tz4status='A' かつ「現役レンタル中」
      (user_party_id が z_munit_sales_histories.product_set_state=0 を保有)。
      → 終了日(tz4date2_end)未整備のゾンビ契約を実質除外。
  - 利用者(user_party_id)単位に集約。件数(全社): 30日以内=101 / 期限切れ=1,841。
    住所あり: 30日以内 98 / 期限切れ 1,200。geocode は初回のみ・$5/1000で些少。
  - 留保: 納品/回収/担当者会議の訪問日を最終訪問日に未織込のため超過件数は過大寄り。
    30日以内スコープは信頼でき、まずそこで運用開始可能。

【画面機能（routeplan）】
  - 上部バー右に「モニタリング ☐30日以内 ☐期限切れ」チェックボックス（件数つき）。
  - チェックで地図に独立レイヤーのマーカー（丸型 scale4・外周黒・文字なし・
    30日以内=#d32f2f / 期限切れ=#8b0000・zIndex1で他マーカーより下）。
  - 画面右端にモニタリング一覧ペイン（期限順）。行クリックで該当マーカーへフォーカス、
    マーカークリックで行ハイライト。
  - 担当者ドロップダウン選択でモニタリングも絞り込み（worker_id→charger party_id 変換）。
    件数キャプションも選択担当に追従（getMonitoringCounts）。
  - 退職者(charger)を除外（tz4_people/tz4_parties の「(退職)」表記を正規化し
    charger_name と突合）。期限切れ 1,200→1,157。
  - 一括事前geocode関数 bulkGeocodeMonitoring()（コンソールで一度実行、対象ユニーク
    住所1,194件）。saveGeoCache は住所を生値保存に修正（htmlspecialchasによる
    キャッシュキー不一致を防止）。

【性能対応】
  - 退職者除外を NOT IN(サブクエリ) で直書きしたら 11.8秒に激重化 → 退職者名を先に
    取得して定数IN化し 0.08秒へ。
  - worker絞り込みの IN(サブクエリ) も DEPENDENT SUBQUERY(0.22秒) → party_id を
    先取りして定数IN化（実装済、検証は中断）。
  - 主クエリは idx_due でORDER BYのfilesortなし・geocode_cache はPK eq_ref で良好。
  - 重さの主因はサーバークエリでなくブラウザ側（大量geocode＋約1,157マーカー描画）。
    → 一括事前geocodeで解消見込み。なお残ればマーカークラスタリングを検討。

【未了・TODO】
  - routeplan/ 一式のサーバーデプロイ（未実施）。
  - worker絞り込み定数IN化の動作検証（中断）。
  - bulkGeocodeMonitoring() の初回実行でキャッシュ温め。
  - 期限ロジック精緻化（訪問記録を最終訪問日に織込）、超過件数の精度向上。
  - 大量マーカー時のクラスタリング要否判断。

==========================================================================
2026-06-17〜06-23  ローカルAI(Ollama)画像OCR基盤の構築＋ellio/ocrtest/ デプロイ
==========================================================================
目的・背景:
  生成AIにプログラムから処理をさせるテスト環境が欲しいとの要望。第一弾として
  「画像から文字列を読み取る(OCR)」を、Mac mini(Apple M4/24GB)上のローカルLLMで
  実現。入口は zsystem.jp のブラウザ画面とし、画像＋AIへの指示(プロンプト)を送って
  結果テキストを受け取る。外部API課金なし・オフラインで試行錯誤できる土台を作る。

【Mac mini 側 構築】
  - Ollama を Homebrew(formula版)で導入、brew services で常駐(API 127.0.0.1:11434)。
  - モデル: llama3.2-vision は「unknown model architecture: 'mllama'」で読込不可。
    → 日本語OCRに強い qwen2.5vl:7b を採用(既定)。他に qwen2.5:7b/llama3.2:3b 導入。
  - OCRラッパー /Users/menou/ollama-ocr/ocr.php (PHP, php -S 127.0.0.1:11500)。
    /health と /ocr。X-API-Key 認証(apikey.txt, 600)。{image(base64),prompt?,model?}。
  - php -S は max_execution_time=30 で curl_exec 中に Fatal→サーバーごと落ちる問題。
    ocr.php に set_time_limit(0) を入れ CURLOPT_TIMEOUT=300 で上限管理。

【接続: SSHリバーストンネル】
  - 既存のSSH基盤を流用し家のポート開放ゼロで実現。autossh で Mac→zsystem.jp、
    -R 127.0.0.1:11500:127.0.0.1:11500。zs サーバー内 localhost:11500 がMacに届く。
  - ブラウザは zsystem.jp としか通信せず、Mac mini/Ollama は外部非公開。

【自動起動: launchd(ユーザーLaunchAgent)】
  - ~/Library/LaunchAgents/com.menou.ollama-ocr.{wrapper,tunnel}.plist
    (RunAtLoad+KeepAlive)。kill→別PIDで自動復活を検証済み。

【zsystem.jp 側 入口画面】
  - 当初 zsystem.jp/ocrtest/ に作成 → 要望により ellio/ocrtest/ へ移動。
  - index.php: 画像アップロード＋「AIへの指示」テキスト欄＋プリセット(カンバン＋
    現品ラベル/伝票→JSON/名刺)。指示空欄なら全文OCR。
  - リモートは PHP5.3 のため 5.3互換で記述(?? / [] / アロー関数 / 型宣言 不使用)、
    curl_close 不使用(PHP8で deprecated)、set_time_limit(360)。
  - zcommon.php/DB 非依存の単独ファイル。

【デプロイ(2026-06-23)】
  - ローカル ellio/ocrtest/index.php → リモート /Users/zadmin/Sites/ellio/ocrtest/。
    新規ディレクトリ作成＋scp転送＋chmod(dir755/file644)。新規のため差分なし。
  - 公開URL: https://zsystem.jp/ellio/ocrtest/
  - ※公開URLでの本番経路フル動作確認(GET/POST)は実行直前で中断、未検証。

【トラブル/留意】
  - mediaanalysisd(macOS標準)がCPU100%占有し推論が遅延(macOS27プレリリースの既知
    張り付き)。本件とは無関係。必要時 sudo killall mediaanalysisd(launchdが再起動)。
  - コード本体(~/ollama-ocr/)は Dropbox 外=バックアップ対象外。

【記録の所在】
  - 設定詳細(運用コマンド/トラブルシュート/TODO): Dropbox/www/macmini/ollama-ocr.md
  - auto-memory: project_macmini_ollama_ocr.md

【未了・TODO】
  - 公開URLでの本番フル動作確認(ブラウザ→zs→トンネル→Mac→Ollama)。
  - 実帳票(カンバン/現品ラベル等)での精度検証・用途別プロンプト/JSON出力の作り込み。
  - 必要なら完全ヘッダレス運用(自動ログイン)、コード本体のDropbox保管。
==========================================================================


==========================================================================
2026-06-23  ellio/film/ 検索結果テーブル・クリアボタン追加（デプロイ済み）
==========================================================================

【目的・背景】
  フィルム在庫管理（ellio/film/）の検索（出庫支援）画面で、検索した商品コードの
  在庫一覧を可視化したい。従来は棚マップ上の強調表示のみで、入荷日・棚番号・数量を
  リスト形式で確認できなかった。あわせて入庫フォームの操作性向上（クリア）と
  検索フォームの入力ミス防止（分類変更時の幅クリア）を実施。

【変更1: 検索結果テーブル（入荷日昇順）】
  - 検索ボタン下に結果テーブルを表示。列＝入荷日／棚番号／数量。
  - index.php SearchStock(): SELECT に qty,arrivaldate,createdate を追加。
    ORDER BY COALESCE(NULLIF(arrivaldate,''),createdate) ASC, locate。
    ※読み取り専用クエリのみ。書き込み経路・dbprocは不変。
  - 入荷日カラムの判断: createdate（=登録時刻、常に当日）ではなく arrivaldate を採用。
    RegistFilm() が入庫フォームの入荷日入力を SETPROPAT arrivaldate で明示書込しており、
    既存在庫の導入登録では過去日付に書換可。実際の入荷日を保持するのは arrivaldate。
    arrivaldate 空の旧レコードは createdate にフォールバック。
  - form.html: #out_result 下に <table id="out_table">（初期非表示）。
  - index.js: renderSearchTable()追加。formatLocate()=locate→「レーン-列-段」整形、
    formatDate()=日付部分のみYYYY-MM-DD正規化。doSearch成功時/空ヒット時に再描画。
  - film.css: .restable（枠線・ヘッダ背景・数量右寄せ・偶数行ストライプ）。

【変更2: 入庫タブ クリアボタン】
  - form.html: 登録ボタン行に左寄せ「クリア」ボタン追加（onclick=resetInForm()）。
    既存 resetInForm() 再利用＝全入力フィールド・packnoバッジ・棚強調をクリアし
    ロケ欄にフォーカス。
  - film.css: .clearbtn（margin-right:auto で登録を右端へ押し出す。グレー系配色）。
    .btnrow は flex-end のまま維持＝検索タブの単独ボタンには影響なし。

【変更3: 検索タブ 分類変更で幅クリア】
  - index.js onClassChangeOut(): out_width.value='' を追加。分類を選び直すと幅が空に
    なり、新しい厚さ・長さ自動セット後に幅へフォーカス。

【デプロイ（2026-06-23）】
  - 対象4ファイル: ellio/film/{index.php,form.html,index.js,film.css}
    → /Users/zadmin/Sites/ellio/film/。同一ディレクトリ・別名のため1コマンドscp。
    chmod 644 後、ローカル⇔サーバー md5 全一致を確認。
  - 公開URL: https://zsystem.jp/ellio/film/

【未デプロイのまま残る件（今回対象外）】
  - dbproc.php一本化（SPEC §8）。regist.php本番フローの実機テスト未実施のため保留。
    今回の変更は read経路のみで write経路に無関係。


==========================================================================
2026-06-24  ellio/film/ 在庫テーブルUI改善・ラック図表記/バッジ調整（デプロイ済み）
==========================================================================

【目的・背景】
  フィルム在庫管理（ellio/film/）の検索・在庫一覧の視認性と操作性を向上。
  在庫テーブルを業務の見方（分類起点）に合わせ、ラック図と連動させる。

【在庫/検索テーブル】
  - sticky ヘッダの水平ボーダー流れ対策: border-collapse 下では sticky th の
    上下 border が追従せず流れるため、border-top/bottom を消し box-shadow(inset)
    で水平線を描画＝固定ヘッダーに追従（film.css .restable th）。
  - 列順を変更: 分類→サイズ→商品コード→棚番号→入荷日→Packno→数量。
    form.html ヘッダ、index.js renderSearchTable のセル生成順、
    index.php GetRackData の ORDER BY を同順に統一（初期=全在庫表）。
    ※検索(出庫支援)結果は従来どおり入荷日昇順(FIFO)のまま。
  - 行タップ連動: 行 onclick→selectTableRow() で該当の棚(セル hlsearch)＋
    商品(バッジ hl)をラック図に強調、選択行を .selrow 表示。
  - サイズ欄: x 区切りを淡色(#aaa, span.szx)。厚さ(中央 pos2)は非表示にし
    「長さ x 幅」で表示（mkSizeTd で3要素なら中央除外）。

【自動ラック図】
  - レーン番号表記を「1/2」→「レーン1/レーン2」に変更（buildRack）。
  - 商品バッジ強調色を #1c89c4→#e80(オレンジ)に変更＝視認性向上(.pbadge.hl)。
  - 商品バッジ幅をセル幅基準に固定: box-sizing:border-box＋
    flex:0 0 calc((100%-2px)/3) で既定(=9相当)3列、太い(volume>0=6相当)は
    5割増の calc((100%-2px)/2)で2列。両脇予約=セル padding:1px。
    ※将来 volume に実値(9/6)が入ったら JS の thin/thick 判定を
      「9→3列/6→2列」に振り分ける改修が必要（現状 volume 空＝全て3列）。

【ユーザー/linter 併合分（同時デプロイ）】
  - 検索タブにクリアボタン(resetOutForm)。初期状態=全在庫一覧表示
    (loadRackData(true))。テーブルを .tablewrap スクロール領域に格納。
  - GetRackData/SearchStock に ProductDistributeTable LEFT JOIN で Size 取得。

【デプロイ（2026-06-24）】
  - 対象4ファイル: ellio/film/{index.php,form.html,index.js,film.css}
    → /Users/zadmin/Sites/ellio/film/。同一ディレクトリ・別名のため1コマンドscp。
    chmod 644 後、ローカル⇔サーバー md5 全一致を確認。
  - 公開URL: https://zsystem.jp/ellio/film/


==========================================================================
2026-06-24  ellio/film/ ステータスバー(LOG)の改善（デプロイ済み）
==========================================================================

【目的・背景】
  画面下部のグレーのステータスバー(#LOG)は入庫登録の結果・検索の入力不備など
  の状態表示用。視認性と配置を改善する。

【変更（film.css / index.js）】
  - 配置: 画面下部の全幅固定 → 右ペイン(#inputpane)下部に限定
    (left:46%; right:0)。操作している右ペイン直下にメッセージが出る。
  - 色: 暗い #000a+白文字 → 上部バー(.panehead)と同色(#0000000a/#0008)に統一。
  - 自動消去: log() 改修。メッセージ表示後4秒で自動クリア。新規log()毎に
    タイマーをリセット。
  - 色分け: log(msg,type)。type='ok'→緑(#2e7d32)/'err'→赤(#c62828)/
    省略→既定色。登録完了=緑、各種エラー・未入力・該当なし=赤、登録中…=既定。

【デプロイ（2026-06-24）】
  - 対象2ファイル: ellio/film/{index.js,film.css}
    → /Users/zadmin/Sites/ellio/film/。chmod 644 後 md5 全一致を確認。
    ※index.php/form.html は変更なし(サーバーと一致のため転送対象外)。


==========================================================================
2026-06-24  ellio/film/ 在庫リスト行タップで入庫フォーム引き継ぎ＋PackNo表記（デプロイ済み）
==========================================================================

【目的・背景】
  在庫一覧/検索結果の行を選んだだけで入庫作業に移れるよう、検索実行時と同様に
  入庫フォームを入力済み状態にする。表記ゆれ(Packno)も統一。

【変更（index.js / form.html）】
  - 在庫リスト行タップ(selectTableRow)を改修。従来のラック図強調(棚セル・
    商品バッジ)に加え、行データを入庫フォームへ引き継ぎ＝検索実行時の
    copySearchToIn と同様に入力済みにする。
    引き継ぎ: in_class=productname / Size「長さx厚さx幅」を分解し
    in_length,in_thickness,in_width / in_productcode=productcode。
    ※タブ切替は自動では行わない(検索時と同じ挙動)。
  - 表示テキスト「Packno」→「PackNo」に変更（入庫フォームのラベル、
    在庫テーブルのヘッダ）。関数名 onPacknoScan は内部コードのため不変。

【デプロイ（2026-06-24）】
  - 対象2ファイル: ellio/film/{index.js,form.html}
    → /Users/zadmin/Sites/ellio/film/。chmod 644 後 md5 全一致を確認。
    ※index.php/film.css は変更なし(サーバーと一致のため転送対象外)。


==========================================================================
2026-06-30  ellio/film 工程番号帯の変更（F帯→数値帯）＋expansion再展開＋既存144本リナンバー（ellio DB直接変更）
==========================================================================

【目的・背景】
  フィルム工程の番号帯を、独立したF接頭帯（種類別 1/6PL・1/9PL・1/11PL ＋
  端数予約 ＋ F90000系出庫）から、既存の数値帯の空き番号に差し込む新方針へ移行。
  サイズ/形状での区別を廃止し「フィルム入荷予定→フィルム仮置き→フィルム保管」に一本化。
  併せて塗料用の数値帯（将来の塗料管理プログラム用）と、フィルム/塗料共通の
  在庫落とし専用（出庫）番号も整備。基準はユーザー提供 Excel「厚木zgrouplist.xlsx」
  （黄=フィルム/水=塗料/橙=在庫落とし専用）。

【zgrouplist マスタ変更（ユーザー事前実施分＋本作業）】
  - ユーザーがF帯（F00000〜F99992 計10帯）を master から削除済み。
  - 新数値帯は master に既存: 003000 フィルム入荷予定 / 004000 塗料入荷予定 /
    037000 フィルム仮置き / 038000 塗料仮置き / 040000-044999 フィルム保管(flag1=フィルム,
    flag5=良品在庫) / 060000-064999 塗料保管 / 070990・070991・070992。
  - 本作業で 070000「出庫」の endno を 070999→070899 に修正
    （070990/070991/070992 単独帯との groupcode 重複を解消。これが無いと再展開不可）。

【zgrouplist_expansion 再展開】
  - ellio/zgrouplistexpansion.php と同一ロジック（seqno再採番→全削除→帯ごとに
    groupno..endno をゼロ埋め展開、500件バルクINSERT、1トランザクション）を
    ellio DB 直結で実行。
  - 結果: 46帯 / 72,603スロット。F帯は master/expansion とも0（完全撤去）。
    groupcode 一意制約クリア。孤児帯なし。

【既存フィルム pack 144本のリナンバー（pack のみ）】
  - 旧 F10001〜F30320（144本: 1/6PL 55・1/9PL 55・1/11PL 34）を、packno昇順で
    044000〜044143 へ連番リナンバー（pack.packno のみ UPDATE。CASE一括・TX保護）。
  - 採番方針: 全部044台に連番（下桁保持は F1/F2/F3 でサイズ跨ぎ連番が重複=54件
    衝突のため単一044帯では不可、と確認のうえユーザー判断で連番採用）。
  - 040台(040000-040999)は現場テスト用に空けて確保。044台がコピー(現行在庫)。
  - リナンバー後、144本は groupcode=044xxx により 040000 フィルム保管
    (flag5=良品在庫) に自動所属。locate は全本保持→ラック図表示は継続。
  - 旧ログ(packlogindex 1296件 / tasklog srcpackno 1152・dstpackno 144件 /
    commandlog テキスト)は開発データのため旧 F packno のまま据え置き（pack のみ整合）。
    ※packlog/personlog には該当0件＝144本は一括シードの開発/テストデータと判断。

【検証】
  - 再展開: 新帯スロット数一致（040000=5000等）、F帯0、重複0、master46帯=expansion46帯。
  - リナンバー: EF pack 144本=044000〜044143、残存F pack 0、144本とも
    040000フィルム保管(良品在庫)に紐付、locate全保持、040台占有0。
  - 1回目の再展開は070000重複でエラー→自動ROLLBACKで無傷を確認後、endno修正して再実行。

【ファイル変更・デプロイ】
  - なし（DBのみの変更。ローカルPHPファイルの修正・サーバ転送なし）。
  - 控え: scratchpad に pack144_backup.json（旧状態）/ renumber_map.json（新旧対応表）。

【残課題（次フェーズ）】
  - film/index.php RegistFilm の工程割当: 現状 MOV;src=dst=packno;FILM-IN（自packno・
    工程未割当）。新モデルでは入庫時に packno を 040000帯から採番し
    フィルム保管に所属させる設計へ要追従（採番方式・現場テスト用040台運用の確定）。
  - GetRackData/SearchStock の在庫対象を工程(良品在庫)基準に絞り込むか要検討
    （現状 pack.locate 直読み）。
  - Excel整合の残り（037000/038000 名称→「（入庫収納）」、070991/070992 名称→
    「Nライン出庫（在庫落とし専用）」、070999 追加、070990 要否、050000「鋼材」→
    「鋼材保管」）は今回未適用＝別途判断。
  - F帯144本のラック図見え方の検証完了後、旧F関連の整理（必要なら旧ログ処理）。


==========================================================================
2026-06-30  ellio/raw 在庫状況ビュー: フィルム在庫セルの表示項目変更＋素材バナーをフィルムに修正（デプロイ）
==========================================================================

【目的・背景】
  ellio/raw（在庫状況ビュー PackList）で、フィルム在庫(productcode が EF で始まる
  保護フィルム)が鋼材用レイアウトに乗っており、セル内容がメーカー(空)/productcode
  と意味が薄く、素材種別バナーも「鋼材」と誤判定されていた。フィルム現場で識別
  しやすい表示へ変更する。

【変更（ellio/raw/index.php・PackList のみ）】
  - SELECT に pack.length/width/lotno/productname を別名(pklength/pkwidth/pklotno/pkpn)
    で明示追加（SELECT * の列名衝突回避）。
  - 各行で $isfilm=(strpos(productcode,'EF')===0) を判定。
  - フィルム在庫セルの表示を4行・各センタリングに変更（鋼材セルは現状維持）:
      1行目 packno（従来どおり・#fff 半透明）
      2行目 品種(productname) ＋ 長さ×幅（pack.length x pack.width）
      3行目 ロット番号（color #fff8）
      4行目 入荷月日（pack.arrivaldate を m/d、0000-00-00は空）
    ※.cell は 96x56px・line-height14px で4行が収まる。text-align:center で中央寄せ。
  - 素材種別バナー: フィルム行は $MT を 'フィルム' に上書き（standard が
    アルミ/SUS/-75 に当たらず既定の「鋼材」になる誤判定を是正）。鋼材等は不変。

【検証】
  - php -l OK。サーバ現行との diff が意図した3〜4箇所のみ（ドリフト無し）を確認。
  - セルHTML生成・バナー判定をローカルPHPでシミュレートし期待どおりを確認。

【デプロイ（2026-06-30）】
  - 対象1ファイル: ellio/raw/index.php → /Users/zadmin/Sites/ellio/raw/index.php。
    chmod 644 後 md5 一致を確認。他ファイル(raw.css/raw.js/raw.html)は変更なし。

【残課題】
  - pack詳細トレイ(TrayTitle)の鋼材ラベル(鋼材規格+目付/コイルNO/クロメート)の
    フィルム対応は未着手（別途判断）。