akira/keinasystem
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

計画始動後の作付け変更について #3

New Issue
Closed
opened 2026-04-05 04:29:12 +00:00 by akira · 6 comments
akira commented 2026-04-05 04:29:12 +00:00
Owner
Copy Link

現在の状態（なぜOpenか）

調査開始

次にすること（Next Action）

影響範囲を調査する

ブロック要因

（なければ「なし」）

問題の概要

今、

  1. 圃場に対しての作付け計画を作った
  2. 圃場に対して、肥料の一部は既に計画通りに施肥済
  3. 計画は立てたがまだ、施肥していない肥料もある
  4. この状態で、急遽、作付け計画の変更が必要になりました。

ここで
作付け計画、施肥計画、散布実績などが、既にわりついているので
作付け計画に戻って一部だけ変えるというのが困難な状況になっている。
だが、現実には、そのような変更は必要

A) 既に、散布した肥料や農薬などは、そのまま紐づいていなければならない
B) 作付け計画を変えるので、品種は変わる
C) グループも変える

ちょっと操作した感じでは、少なくとも
１．足川北上を「にこまる」から「たちはるか特栽」に変えた
２．施肥計画画面の圃場追加候補に足川北上が出てこない
のような状況です。

たぶん、この問題だけ解決しても、他にも色々不具合が出てくると思います。

よって、
１）　最初に、これを実現する為に明らかになっていなければいけない事は何かを明示する
２） この実現によって、影響を受ける仕様を具体化する
の作業を行ってください

再現手順

期待する動作

実際の動作

関連

## 現在の状態（なぜOpenか） 調査開始 ## 次にすること（Next Action） 影響範囲を調査する ## ブロック要因 （なければ「なし」） --- ## 問題の概要 今、 1) 圃場に対しての作付け計画を作った 2) 圃場に対して、肥料の一部は既に計画通りに施肥済 3) 計画は立てたがまだ、施肥していない肥料もある 4) この状態で、急遽、作付け計画の変更が必要になりました。 ここで 作付け計画、施肥計画、散布実績などが、既にわりついているので 作付け計画に戻って一部だけ変えるというのが困難な状況になっている。 だが、現実には、そのような変更は必要 A) 既に、散布した肥料や農薬などは、そのまま紐づいていなければならない B) 作付け計画を変えるので、品種は変わる C) グループも変える ちょっと操作した感じでは、少なくとも １．足川北上を「にこまる」から「たちはるか特栽」に変えた ２．施肥計画画面の圃場追加候補に足川北上が出てこない のような状況です。 たぶん、この問題だけ解決しても、他にも色々不具合が出てくると思います。 よって、 １）　最初に、これを実現する為に明らかになっていなければいけない事は何かを明示する ２） この実現によって、影響を受ける仕様を具体化する の作業を行ってください ## 再現手順 ## 期待する動作 ## 実際の動作 ## 関連
akira commented 2026-04-05 04:51:24 +00:00
Author
Owner
Copy Link
<html>

確認内容の整理

項目 | 決定事項 -- | -- ① 変更履歴 | 必要（なぜ施肥設計が変わったか後からわかるように） ② 散布済みEntry | (B) 新品種計画に移動（影響大なら(A)も可） ③ 未散布Entry | 新品種計画に移動 + RESERVE付け替え ④ グループ | 圃場固有の恒久属性のため対応不要 ⑤ 田植え計画 | 施肥計画と同様の対処が必要

どれが良いですか？

実装の進め方（提案）

影響が広いため、段階的な実装を提案します：

  1. Step 1: PlanVarietyChange モデル追加（履歴記録のみ、表示なし）
  2. Step 2: 品種変更時のエントリ移動サービス（施肥計画のみ）+ 確認ダイアログ
  3. Step 3: 田植え計画のエントリ移動
  4. Step 4: allocation画面の変更履歴インジケータ表示

Step 2 が一番リスクが高い（RESERVE付け替えがある）ため、Step 1 で履歴だけ入れて動作確認後に Step 2 に進む方が安全です。

進め方についても確認させてください。

</html>
<html> <body> <!--StartFragment--><h2 style="color: rgb(41, 41, 41); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">確認内容の整理</h2> 項目 | 決定事項 -- | -- ① 変更履歴 | 必要（なぜ施肥設計が変わったか後からわかるように） ② 散布済みEntry | (B) 新品種計画に移動（影響大なら(A)も可） ③ 未散布Entry | 新品種計画に移動 + RESERVE付け替え ④ グループ | 圃場固有の恒久属性のため対応不要 ⑤ 田植え計画 | 施肥計画と同様の対処が必要 <p style="white-space: pre-wrap; margin-top: 0.1em; margin-bottom: 0.2em; color: rgb(41, 41, 41); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">どれが良いですか？</p><hr style="font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><h2 style="color: rgb(41, 41, 41); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">実装の進め方（提案）</h2><p style="white-space: pre-wrap; margin-top: 0.1em; margin-bottom: 0.2em; color: rgb(41, 41, 41); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">影響が広いため、段階的な実装を提案します：</p><ol style="padding-inline-start: 2em; color: rgb(41, 41, 41); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><li><strong>Step 1</strong>:<span> </span><code style="font-family: monospace; color: rgb(255, 255, 255); background-color: rgb(9, 52, 95); padding: 2px 4px; border-radius: 3px; word-break: break-word; font-size: 0.9em;">PlanVarietyChange</code><span> </span>モデル追加（履歴記録のみ、表示なし）</li><li><strong>Step 2</strong>: 品種変更時のエントリ移動サービス（施肥計画のみ）+ 確認ダイアログ</li><li><strong>Step 3</strong>: 田植え計画のエントリ移動</li><li><strong>Step 4</strong>: allocation画面の変更履歴インジケータ表示</li></ol><p style="white-space: pre-wrap; margin-top: 0.1em; margin-bottom: 0.2em; color: rgb(41, 41, 41); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Step 2 が一番リスクが高い（RESERVE付け替えがある）ため、Step 1 で履歴だけ入れて動作確認後に Step 2 に進む方が安全です。</p><p style="white-space: pre-wrap; margin-top: 0.1em; margin-bottom: 0.2em; color: rgb(41, 41, 41); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">進め方についても確認させてください。</p><!--EndFragment--> </body> </html>
akira commented 2026-04-05 04:53:30 +00:00
Author
Owner
Copy Link

CODEX

Issue #3 調査メモ: 計画始動後の作付け変更について

対象 issue

  • Gitea Issue #3
  • タイトル: 計画始動後の作付け変更について
  • 登録日: 2026-04-05

1. まず明らかになっている必要があること

この課題は「作付け計画を変更したい」ではなく、
「すでに計画・運搬・散布の一部が動き始めた後で、将来分だけを安全に組み替えたい」が本質。
そのため、以下を仕様として先に決めないと実装を始めると破綻しやすい。

1-1. どこまでを履歴として固定し、どこから先を変更対象にするか

  • すでに散布実績がある 圃場 × 肥料 は履歴として固定するのか
  • 固定する場合、固定対象は以下のどこまで含むのか
    • 散布実績
    • 実績に対応する施肥計画エントリ
    • 実績に対応する運搬明細
    • 在庫 USE / RESERVE
    • 作業記録
  • 「まだ散布していない残計画」だけを別レコードへ移すのか
  • 既存計画を上書きするのではなく、履歴保持のために分割するのか

1-2. 品種変更を何の単位で許可するか

  • 圃場単位での変更を許可するのか
  • 同じ年度中に圃場の品種変更履歴を残す必要があるのか
  • 変更後の圃場は新しい品種の施肥計画へ付け替えるのか
  • 変更前に散布済みの肥料は「旧品種の計画に残す」のか「圃場履歴として残す」のか

1-3. グループ変更の意味

ユーザー確認により、issue 本文の「グループ変更」は主に圃場管理の group_name を指す。

  • 圃場マスタの group_name は後から変更されうる
  • 運搬計画の配送グループも散布前なら変更されうる
  • ただし散布後は、運搬計画グループは基本的に変更しない前提

このため、少なくとも以下を分けて考える必要がある。

  • 圃場マスタ上の現在属性としてのグループ
  • 履歴として固定すべき運搬計画上のグループ

1-4. 不整合をどこまで許容するか

  • 旧品種の施肥実績が残ったまま、新品種の作付け計画へ変更してよいか
  • 「今年のその圃場は最終的に何を作ったか」と「途中で何を前提に散布したか」がズレてもよいか
  • PDF や一覧画面で、旧計画分と新計画分を同時に見せる必要があるか

1-5. ユーザー操作として必要な単位

  • 圃場 1 筆だけ切り替えたいのか
  • 複数圃場をまとめて切り替えたいのか
  • 施肥済み分を残しつつ、未散布分を新計画へ一括移動したいのか
  • 変更理由や変更日などの監査情報が必要か

2. 現行実装で起きていること

2-1. 候補圃場は「現在の作付け計画」から再計算される

施肥計画の圃場候補は、現在の plans.Plan(year, variety) を見て作られている。

そのため、作付け計画で圃場の品種を変更すると、
変更前の品種に紐づく施肥計画画面では、その圃場が追加候補に出なくなる。
issue にある「足川北上が圃場追加候補に出てこない」はこの挙動と一致する。

2-2. 施肥計画の実績集計は year + field + fertilizer 単位

散布実績から actual_bags を再集計するとき、対象は plan__year + field_id + fertilizer_id で更新される。

つまり現行実装では、
「どの施肥計画に対する実績か」ではなく、
「同年度のその圃場・その肥料の実績か」で紐づいている。

このため、同じ年度に圃場を別計画へ移したり、計画を分割したりすると、
実績が複数計画へ二重反映または意図しない再配分になる余地がある。

2-3. 施肥計画更新はエントリ全削除・全再作成

施肥計画更新時は、既存エントリを全削除して新しいエントリを作り直す。

この方式だと、「散布済みの行だけ残して、未散布分だけ移す」という操作単位を持てない。
履歴保持と将来計画の分離を実現するには、今の更新方式は不足している。

2-4. 運搬計画は年度内の全施肥エントリを前提に集計する

運搬計画詳細の未割当圃場・利用可能肥料・全明細は、plan__year=obj.year の全施肥エントリから作られている。

そのため、作付け変更に伴って施肥計画を分割・移管したい場合、
年度全体集計ベースの画面は旧計画と新計画を自然に区別できない。

2-5. 散布実績自体はスナップショットを保持している

散布実績明細は以下を保存している。

これは履歴保持の観点では良いが、
「どの施肥計画のどの行から発生した散布か」という計画レベルの参照は保持していない。

3. 影響を受ける仕様

3-1. 作付け計画

  • 現在は field + year が 1 件で、その年度の最新状態のみを表す
  • 途中変更の履歴を持たない
  • 変更前後を区別したいなら、履歴テーブルか有効期間の考え方が必要

3-2. 施肥計画

  • 候補圃場抽出ロジック
  • 編集画面での圃場追加可否
  • 既散布行と未散布行の扱い
  • actual_bags の再集計単位
  • 在庫引当の再作成ロジック

3-3. 圃場グループ

  • 圃場マスタの group_name は現在値しか持っていない
  • 後日変更されると、過去時点でどのグループだったかは追えない
  • ただし現時点では、散布実績や施肥実績が group_name に直接依存している箇所は薄い
  • よって圃場グループ変更は、主に表示・集計・将来計画側の問題として扱える

3-4. 運搬計画

  • グループ割当の維持方法
  • 年度全体施肥エントリを前提にした未割当圃場計算
  • すでに運搬済みの明細を履歴として残しつつ、未運搬分だけ別グループへ再編できるか

3-5. 散布実績

  • 既存実績の参照元計画が曖昧
  • 変更後の計画へ実績が再集計されるかどうか
  • 候補一覧生成時に、旧計画分と新計画分をどう見せ分けるか

3-6. 在庫管理

  • 施肥計画更新時、RESERVE が全置換される
  • 実績 USE は散布実績ベースで残る
  • 途中変更時に「旧計画の引当を解除し、新計画へ再引当」が必要
  • ただし散布済み分の USE は動かしてはいけない

3-7. 作業記録

  • 作業記録は運搬回 / 散布実績への 1:1 参照で成立しており、履歴としては比較的安定
  • 一方でタイトル等は計画名変更の影響を受けうる

4. この issue に対する現時点の結論

この問題は単なる「候補圃場の表示漏れ」ではない。

本質は以下の 2 点。

  1. 現行システムは「現在の作付け計画」と「履歴として固定すべき施肥・運搬・散布」を分離していない
  2. 施肥・運搬・散布の一部が 年度 + 圃場 + 肥料 集計でつながっており、計画の再編単位を持っていない

したがって、候補圃場 API だけ直しても不十分で、
少なくとも「履歴固定」と「未実施分の再計画」の仕様分離が必要。

5. 実装前に必要な仕様決定

最低限、次の 4 点を決める必要がある。

  1. 変更後も残すべき履歴の最小単位は何か
  2. 未散布分をどの単位で旧計画から切り離すか
  3. 品種変更後、既散布分を旧品種の施肥計画に残すのか、新品種側に見せ替えるのか
  4. 圃場マスタの group_name 変更を履歴管理対象にするか、現在値扱いに留めるか
  5. 散布前の運搬計画変更をどこまで許容するか

6. 推奨する実装方針の方向性

現時点では、次の方向が最も安全に見える。

方針A: 履歴固定 + 未実施分の再計画

  • 散布実績がある 圃場 × 肥料 は旧施肥計画側に固定する
  • 未散布分だけ新施肥計画へ移す
  • 運搬済み明細も履歴として残し、未運搬分のみ再編対象にする
  • 作付け計画の最新状態とは別に、施肥計画側で「履歴としての対象圃場集合」を保持する
  • 圃場マスタの group_name は変更可能な現在属性として扱い、必要なら帳票側でスナップショット化を検討する

方針B: 候補圃場と実績参照を分離する

  • 候補圃場表示は「現在の作付け計画」
  • 既存計画の保持対象は「その計画に保存済みの圃場」
  • 実績集計は plan_id またはそれに準ずる固定キーに寄せる

方針A/B を組み合わせないと、issue の A/B/C を同時には満たしにくい。

6-1. ユーザー確認を踏まえた補足結論

ユーザー確認により、優先順位は次のように見える。

  1. 散布後の履歴固定が最優先
  2. 散布前の運搬計画は変更可能
  3. 圃場マスタのグループは現在値として後から変わりうる

したがって、構造上もっとも重要なのは
作付け変更後も散布済みデータが崩れないこと
であり、group_name 自体は二次的な論点。
ただし帳票や一覧で「当時のグループ」を見たい要求が出るなら、別途スナップショットが必要になる。

7. 次の調査・設計タスク案

  1. 「既散布・未散布」「既運搬・未運搬」で分けた業務フローを図にする
  2. 施肥計画エントリに履歴固定用の状態を持たせるか検討する
  3. 散布実績の参照先を year + field + fertilizer から計画単位へ寄せる案を比較する
  4. 圃場マスタ group_name を履歴化する必要があるかを判断する
  5. UI 上で必要な操作を列挙する
  6. その後に issue を「暫定対処」と「構造対応」に分割する
CODEX # Issue #3 調査メモ: 計画始動後の作付け変更について ## 対象 issue - Gitea Issue `#3` - タイトル: `計画始動後の作付け変更について` - 登録日: 2026-04-05 ## 1. まず明らかになっている必要があること この課題は「作付け計画を変更したい」ではなく、 「すでに計画・運搬・散布の一部が動き始めた後で、将来分だけを安全に組み替えたい」が本質。 そのため、以下を仕様として先に決めないと実装を始めると破綻しやすい。 ### 1-1. どこまでを履歴として固定し、どこから先を変更対象にするか - すでに散布実績がある `圃場 × 肥料` は履歴として固定するのか - 固定する場合、固定対象は以下のどこまで含むのか - 散布実績 - 実績に対応する施肥計画エントリ - 実績に対応する運搬明細 - 在庫 USE / RESERVE - 作業記録 - 「まだ散布していない残計画」だけを別レコードへ移すのか - 既存計画を上書きするのではなく、履歴保持のために分割するのか ### 1-2. 品種変更を何の単位で許可するか - 圃場単位での変更を許可するのか - 同じ年度中に圃場の品種変更履歴を残す必要があるのか - 変更後の圃場は新しい品種の施肥計画へ付け替えるのか - 変更前に散布済みの肥料は「旧品種の計画に残す」のか「圃場履歴として残す」のか ### 1-3. グループ変更の意味 ユーザー確認により、issue 本文の「グループ変更」は主に圃場管理の `group_name` を指す。 - 圃場マスタの `group_name` は後から変更されうる - 運搬計画の配送グループも散布前なら変更されうる - ただし散布後は、運搬計画グループは基本的に変更しない前提 このため、少なくとも以下を分けて考える必要がある。 - 圃場マスタ上の現在属性としてのグループ - 履歴として固定すべき運搬計画上のグループ ### 1-4. 不整合をどこまで許容するか - 旧品種の施肥実績が残ったまま、新品種の作付け計画へ変更してよいか - 「今年のその圃場は最終的に何を作ったか」と「途中で何を前提に散布したか」がズレてもよいか - PDF や一覧画面で、旧計画分と新計画分を同時に見せる必要があるか ### 1-5. ユーザー操作として必要な単位 - 圃場 1 筆だけ切り替えたいのか - 複数圃場をまとめて切り替えたいのか - 施肥済み分を残しつつ、未散布分を新計画へ一括移動したいのか - 変更理由や変更日などの監査情報が必要か ## 2. 現行実装で起きていること ### 2-1. 候補圃場は「現在の作付け計画」から再計算される 施肥計画の圃場候補は、現在の `plans.Plan(year, variety)` を見て作られている。 - [backend/apps/fertilizer/views.py](/home/akira/develop/keinasystem/backend/apps/fertilizer/views.py#L126) - [frontend/src/app/fertilizer/_components/FertilizerEditPage.tsx](/home/akira/develop/keinasystem/frontend/src/app/fertilizer/_components/FertilizerEditPage.tsx#L180) そのため、作付け計画で圃場の品種を変更すると、 変更前の品種に紐づく施肥計画画面では、その圃場が追加候補に出なくなる。 issue にある「足川北上が圃場追加候補に出てこない」はこの挙動と一致する。 ### 2-2. 施肥計画の実績集計は `year + field + fertilizer` 単位 散布実績から `actual_bags` を再集計するとき、対象は `plan__year + field_id + fertilizer_id` で更新される。 - [backend/apps/fertilizer/services.py](/home/akira/develop/keinasystem/backend/apps/fertilizer/services.py#L11) つまり現行実装では、 「どの施肥計画に対する実績か」ではなく、 「同年度のその圃場・その肥料の実績か」で紐づいている。 このため、同じ年度に圃場を別計画へ移したり、計画を分割したりすると、 実績が複数計画へ二重反映または意図しない再配分になる余地がある。 ### 2-3. 施肥計画更新はエントリ全削除・全再作成 施肥計画更新時は、既存エントリを全削除して新しいエントリを作り直す。 - [backend/apps/fertilizer/serializers.py](/home/akira/develop/keinasystem/backend/apps/fertilizer/serializers.py#L152) この方式だと、「散布済みの行だけ残して、未散布分だけ移す」という操作単位を持てない。 履歴保持と将来計画の分離を実現するには、今の更新方式は不足している。 ### 2-4. 運搬計画は年度内の全施肥エントリを前提に集計する 運搬計画詳細の未割当圃場・利用可能肥料・全明細は、`plan__year=obj.year` の全施肥エントリから作られている。 - [backend/apps/fertilizer/serializers.py](/home/akira/develop/keinasystem/backend/apps/fertilizer/serializers.py#L291) そのため、作付け変更に伴って施肥計画を分割・移管したい場合、 年度全体集計ベースの画面は旧計画と新計画を自然に区別できない。 ### 2-5. 散布実績自体はスナップショットを保持している 散布実績明細は以下を保存している。 - 実散布袋数 - 計画袋数スナップショット - 運搬済み袋数スナップショット - [backend/apps/fertilizer/models.py](/home/akira/develop/keinasystem/backend/apps/fertilizer/models.py#L211) - [backend/apps/fertilizer/serializers.py](/home/akira/develop/keinasystem/backend/apps/fertilizer/serializers.py#L437) これは履歴保持の観点では良いが、 「どの施肥計画のどの行から発生した散布か」という計画レベルの参照は保持していない。 ## 3. 影響を受ける仕様 ### 3-1. 作付け計画 - 現在は `field + year` が 1 件で、その年度の最新状態のみを表す - 途中変更の履歴を持たない - 変更前後を区別したいなら、履歴テーブルか有効期間の考え方が必要 ### 3-2. 施肥計画 - 候補圃場抽出ロジック - 編集画面での圃場追加可否 - 既散布行と未散布行の扱い - `actual_bags` の再集計単位 - 在庫引当の再作成ロジック ### 3-3. 圃場グループ - 圃場マスタの `group_name` は現在値しか持っていない - 後日変更されると、過去時点でどのグループだったかは追えない - ただし現時点では、散布実績や施肥実績が `group_name` に直接依存している箇所は薄い - よって圃場グループ変更は、主に表示・集計・将来計画側の問題として扱える ### 3-4. 運搬計画 - グループ割当の維持方法 - 年度全体施肥エントリを前提にした未割当圃場計算 - すでに運搬済みの明細を履歴として残しつつ、未運搬分だけ別グループへ再編できるか ### 3-5. 散布実績 - 既存実績の参照元計画が曖昧 - 変更後の計画へ実績が再集計されるかどうか - 候補一覧生成時に、旧計画分と新計画分をどう見せ分けるか ### 3-6. 在庫管理 - 施肥計画更新時、RESERVE が全置換される - 実績 USE は散布実績ベースで残る - 途中変更時に「旧計画の引当を解除し、新計画へ再引当」が必要 - ただし散布済み分の USE は動かしてはいけない ### 3-7. 作業記録 - 作業記録は運搬回 / 散布実績への 1:1 参照で成立しており、履歴としては比較的安定 - 一方でタイトル等は計画名変更の影響を受けうる ## 4. この issue に対する現時点の結論 この問題は単なる「候補圃場の表示漏れ」ではない。 本質は以下の 2 点。 1. 現行システムは「現在の作付け計画」と「履歴として固定すべき施肥・運搬・散布」を分離していない 2. 施肥・運搬・散布の一部が `年度 + 圃場 + 肥料` 集計でつながっており、計画の再編単位を持っていない したがって、候補圃場 API だけ直しても不十分で、 少なくとも「履歴固定」と「未実施分の再計画」の仕様分離が必要。 ## 5. 実装前に必要な仕様決定 最低限、次の 4 点を決める必要がある。 1. 変更後も残すべき履歴の最小単位は何か 2. 未散布分をどの単位で旧計画から切り離すか 3. 品種変更後、既散布分を旧品種の施肥計画に残すのか、新品種側に見せ替えるのか 4. 圃場マスタの `group_name` 変更を履歴管理対象にするか、現在値扱いに留めるか 5. 散布前の運搬計画変更をどこまで許容するか ## 6. 推奨する実装方針の方向性 現時点では、次の方向が最も安全に見える。 ### 方針A: 履歴固定 + 未実施分の再計画 - 散布実績がある `圃場 × 肥料` は旧施肥計画側に固定する - 未散布分だけ新施肥計画へ移す - 運搬済み明細も履歴として残し、未運搬分のみ再編対象にする - 作付け計画の最新状態とは別に、施肥計画側で「履歴としての対象圃場集合」を保持する - 圃場マスタの `group_name` は変更可能な現在属性として扱い、必要なら帳票側でスナップショット化を検討する ### 方針B: 候補圃場と実績参照を分離する - 候補圃場表示は「現在の作付け計画」 - 既存計画の保持対象は「その計画に保存済みの圃場」 - 実績集計は `plan_id` またはそれに準ずる固定キーに寄せる 方針A/B を組み合わせないと、issue の A/B/C を同時には満たしにくい。 ## 6-1. ユーザー確認を踏まえた補足結論 ユーザー確認により、優先順位は次のように見える。 1. 散布後の履歴固定が最優先 2. 散布前の運搬計画は変更可能 3. 圃場マスタのグループは現在値として後から変わりうる したがって、構造上もっとも重要なのは `作付け変更後も散布済みデータが崩れないこと` であり、`group_name` 自体は二次的な論点。 ただし帳票や一覧で「当時のグループ」を見たい要求が出るなら、別途スナップショットが必要になる。 ## 7. 次の調査・設計タスク案 1. 「既散布・未散布」「既運搬・未運搬」で分けた業務フローを図にする 2. 施肥計画エントリに履歴固定用の状態を持たせるか検討する 3. 散布実績の参照先を `year + field + fertilizer` から計画単位へ寄せる案を比較する 4. 圃場マスタ `group_name` を履歴化する必要があるかを判断する 5. UI 上で必要な操作を列挙する 6. その後に issue を「暫定対処」と「構造対応」に分割する
akira commented 2026-04-05 05:06:32 +00:00
Author
Owner
Copy Link

改善案/issue_3_計画始動後の作付け変更_調査.md#L442 (line 442)
旧 plan の当該エントリに対応する RESERVE を削除 という書き方は、現行実装とずれています。RESERVE はエントリ単位ではなく fertilization_plan 単位で全置換管理です。backend/apps/materials/stock_service.py (line 10) の通り、実装上は「旧 plan 全体の RESERVE を再生成」「新 plan 全体の RESERVE を再生成」と書かないと誤実装されやすいです。

改善案/issue_3_計画始動後の作付け変更_調査.md#L437 (line 437)
未散布判定を actual_bags is NULL にしているのは危険です。actual_bags は散布実績再集計の結果で、将来のロジック変更や部分散布時に 0 や端数が入る可能性がありますし、「未散布」と「部分散布」を同一扱いできません。backend/apps/fertilizer/models.py (line 72) を踏まえると、少なくとも「actual_bags is null または 0」「一部散布済みは移動不可 or 分割対象」と明文化した方が安全です。

改善案/issue_3_計画始動後の作付け変更_調査.md#L367 (line 367) と 改善案/issue_3_計画始動後の作付け変更_調査.md#L449 (line 449)
田植え計画を「施肥と同様」とまとめていますが、田植え計画には actual_bags に相当する実績概念がまだありません。backend/apps/plans/serializers.py (line 177) 現状では「全 Entry 移動」なのか「将来の実績連携を見越して未実施分のみ移動」なのかを切り分けて書く必要があります。今の書き方だと、施肥と同じ判定軸があるように読めます。

改善案/issue_3_計画始動後の作付け変更_調査.md#L461 (line 461)
actual_bags 集計ロジックは「影響なし」と言い切らない方がいいです。今回の方針なら大きな改修は不要ですが、前提は「同一年・同圃場・同肥料の行が複数計画にまたがって共存しないこと」です。これは仕様上の制約なので、「影響なし」ではなく「現方針では再利用可能。ただし重複行を作らないことが前提」と書くのが正確です。

改善案/issue_3_計画始動後の作付け変更_調査.md#L442 (line 442) 旧 plan の当該エントリに対応する RESERVE を削除 という書き方は、現行実装とずれています。RESERVE はエントリ単位ではなく fertilization_plan 単位で全置換管理です。backend/apps/materials/stock_service.py (line 10) の通り、実装上は「旧 plan 全体の RESERVE を再生成」「新 plan 全体の RESERVE を再生成」と書かないと誤実装されやすいです。 改善案/issue_3_計画始動後の作付け変更_調査.md#L437 (line 437) 未散布判定を actual_bags is NULL にしているのは危険です。actual_bags は散布実績再集計の結果で、将来のロジック変更や部分散布時に 0 や端数が入る可能性がありますし、「未散布」と「部分散布」を同一扱いできません。backend/apps/fertilizer/models.py (line 72) を踏まえると、少なくとも「actual_bags is null または 0」「一部散布済みは移動不可 or 分割対象」と明文化した方が安全です。 改善案/issue_3_計画始動後の作付け変更_調査.md#L367 (line 367) と 改善案/issue_3_計画始動後の作付け変更_調査.md#L449 (line 449) 田植え計画を「施肥と同様」とまとめていますが、田植え計画には actual_bags に相当する実績概念がまだありません。backend/apps/plans/serializers.py (line 177) 現状では「全 Entry 移動」なのか「将来の実績連携を見越して未実施分のみ移動」なのかを切り分けて書く必要があります。今の書き方だと、施肥と同じ判定軸があるように読めます。 改善案/issue_3_計画始動後の作付け変更_調査.md#L461 (line 461) actual_bags 集計ロジックは「影響なし」と言い切らない方がいいです。今回の方針なら大きな改修は不要ですが、前提は「同一年・同圃場・同肥料の行が複数計画にまたがって共存しないこと」です。これは仕様上の制約なので、「影響なし」ではなく「現方針では再利用可能。ただし重複行を作らないことが前提」と書くのが正確です。
akira commented 2026-04-05 05:09:15 +00:00
Author
Owner
Copy Link

改善案/issue_3_計画始動後の作付け変更_調査.md#L428 (line 428)
田植え計画 | 施肥と同様に対応 という決定表現が、下の詳細仕様と少しズレています。詳細では #L463 (line 463) 以降で「現時点では全件移動」と明記されているので、表も「現時点では全件移動、将来実績連携後に再設計」くらいに合わせた方が誤読されません。

改善案/issue_3_計画始動後の作付け変更_調査.md#L444 (line 444)
actual_bags = 0 は現行 services.py では null に丸められる は少し断定が強いです。現行の再集計ロジックでは未該当なら NULL になりやすい、という理解は良いのですが、将来だけでなくデータ補正や手動更新でも 0 が入り得ます。仕様書上は「未散布判定は NULL または 0 を未散布扱いとするかどうか」を明示した方が安全です。

改善案/issue_3_計画始動後の作付け変更_調査.md#L428 (line 428) 田植え計画 | 施肥と同様に対応 という決定表現が、下の詳細仕様と少しズレています。詳細では #L463 (line 463) 以降で「現時点では全件移動」と明記されているので、表も「現時点では全件移動、将来実績連携後に再設計」くらいに合わせた方が誤読されません。 改善案/issue_3_計画始動後の作付け変更_調査.md#L444 (line 444) actual_bags = 0 は現行 services.py では null に丸められる は少し断定が強いです。現行の再集計ロジックでは未該当なら NULL になりやすい、という理解は良いのですが、将来だけでなくデータ補正や手動更新でも 0 が入り得ます。仕様書上は「未散布判定は NULL または 0 を未散布扱いとするかどうか」を明示した方が安全です。
akira commented 2026-04-05 05:14:27 +00:00
Author
Owner
Copy Link

調査結果をもとに、実装タスクを issue 分解しました。

  • 親チケット: #4 作付け変更時の計画連動対応を実装する
  • 実装チケット: #5 PlanVarietyChange モデル追加と品種変更トリガー基盤を実装する
  • 実装チケット: #6 施肥計画の未散布Entry移動とRESERVE再生成を実装する
  • 実装チケット: #7 田植え計画のEntry移動対応を実装する
  • 実装チケット: #8 allocation画面に品種変更確認と履歴表示を追加する

仕様メモ:

  • 改善案/issue_3_計画始動後の作付け変更_調査.md
調査結果をもとに、実装タスクを issue 分解しました。 - 親チケット: #4 作付け変更時の計画連動対応を実装する - 実装チケット: #5 PlanVarietyChange モデル追加と品種変更トリガー基盤を実装する - 実装チケット: #6 施肥計画の未散布Entry移動とRESERVE再生成を実装する - 実装チケット: #7 田植え計画のEntry移動対応を実装する - 実装チケット: #8 allocation画面に品種変更確認と履歴表示を追加する 仕様メモ: - `改善案/issue_3_計画始動後の作付け変更_調査.md`
ai commented 2026-04-07 00:59:23 +00:00
Collaborator
Copy Link

2026-04-07 時点で、依頼されていた調査整理を 改善案/issue_3_計画始動後の作付け変更_調査.md にまとめたためクローズします。

この調査で以下を整理済みです。

  • 実現のために先に明らかにすべき論点
  • 影響を受ける仕様の具体化
  • 現行実装でどこに結合があるか
  • 今後の実装方針の分解案

後続実装は親子 Issue #4-#8 へ切り出されています。

2026-04-07 時点で、依頼されていた調査整理を `改善案/issue_3_計画始動後の作付け変更_調査.md` にまとめたためクローズします。 この調査で以下を整理済みです。 - 実現のために先に明らかにすべき論点 - 影響を受ける仕様の具体化 - 現行実装でどこに結合があるか - 今後の実装方針の分解案 後続実装は親子 Issue #4-#8 へ切り出されています。
ai closed this issue 2026-04-07 00:59:23 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
機能
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ai claude akira
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: akira/keinasystem#3
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?