本文へ移動
Wagby11
マニュアルのグループを選ぶ

WAGBY11 MANUAL / 05

親・子・孫の関係を定義する

受注伝票・受注明細・納品予定を3階層で管理し、各詳細画面からたどる方法を説明します。

最終更新日:

親子関係の小目次へ

1. このページで伝える機能

受注伝票に受注明細を持たせ、さらに各明細に複数の納品予定を持たせられます。同じ品物を分割して納品する場合など、明細ごとに日付と数量を管理できます。

親・子・孫はどのようにつながる?

親子関係の基本では、受注伝票を親、受注明細を子として説明しました。さらに一つの明細に複数の納品予定を持たせると、納品予定が孫になります。孫にとっての直接の親は受注明細です。

親:受注伝票受注ID:1001件名:事務用品の注文

一つの伝票に複数の明細

子:受注明細受注ID:1001 + 明細番号:1品名:デスクライト / 数量:10

この明細に属する納品予定

孫:納品予定(10個を2回に分けて納品)

受注ID 1001・明細番号1の納品予定
受注ID明細番号納品番号数量
1001114
1001126
子:受注明細受注ID:1001 + 明細番号:2品名:ブックスタンド / 数量:6

この明細に属する納品予定

孫:納品予定(6個を2回に分けて納品)

受注ID 1001・明細番号2の納品予定
受注ID明細番号納品番号数量
1001212
1001224

孫の主キー = 親ID(受注ID)+ 子の枝番(明細番号)+ 孫の枝番(納品番号)

子を特定する「受注ID+明細番号」を孫へ引き継ぎ、さらに孫自身の枝番を加えて、納品予定を識別します。

孫は、子のキー全体と孫自身の枝番で識別する

子の受注明細は「受注ID+明細番号」の複合主キーを持ちます。孫の納品予定には、その子を特定する二つの値を両方とも引き継ぎ、孫自身の枝番である「納品番号」を加えます。

図の「受注ID 1001・明細番号1・納品番号1」と「受注ID 1001・明細番号2・納品番号1」は、別の納品予定です。納品番号は受注明細ごとに自動で採番するため、別の明細では同じ番号を使えます。同じ明細の中に同じ納品番号を重複して保存することはできません。

受注IDと納品番号だけでは、どの明細の納品予定かが決まりません。親から子へ、子から孫へと、直前の階層を特定するキー全体を引き継ぐのがポイントです。この例のAppSchemaでは、孫に引き継ぐ受注IDと明細番号をorderKey・lineKeyとして保持し、納品番号のdeliveryNoと合わせた三つの項目を主キーにします。

2. Wagby11で実現できること

受注伝票の関連データから受注明細の詳細を開くと、その明細に属する納品予定を確認できます。納品番号は、枝番を読み取る表示用項目で確認しています。

受注明細の詳細に、その明細の納品予定を表示します。
受注明細の詳細に、その明細の納品予定を表示します。

納品予定を追加するときは、受注伝票のキーと明細番号の両方が引き継がれます。利用者が保存用のキー項目を個別に入力する必要はありません。

受注明細を引き継いで納品日と納品数量を入力する画面。
受注明細を引き継いで納品日と納品数量を入力する画面。

親・子・孫を一画面で同時保存する機能ではありません。受注伝票と受注明細の同時更新を使う場合も、納品予定は受注明細の詳細から別に登録・更新します。

3. AIへの指示例

最小限の指示例

受注明細ごとに、複数の納品予定日と納品数量を管理できるようにしてください。

納品予定の識別方法や、既存の受注明細の主キーをどう参照するかをAIが類推して補います。既存の枝番付き明細を保つことと、各階層の画面をたどって操作することを伝えます。

より詳細な指示例

SalesOrder→order_line→DeliveryPlanの3階層にしてください。order_lineの既存の複合主キーorderId・lineNoは変更しません。DeliveryPlanは両キーを保存するlong型のorderKey・lineKeyと、自動採番のdeliveryNoを主キーとし、order_lineへの論理参照lineRefを全キーのmappingsで定義します。納品日と納品数量を用意し、納品番号は保存しない読み取り専用の表示項目でも確認できるようにします。受注明細の詳細から納品予定一覧と新規登録へ進めるようにしてください。3階層を一画面で同時保存せず、納品予定は個別に登録・更新します。
既存のモデル・主キー・データ・権限を保持し、guide・referenceで必要な仕様を確認してください。新規モデルにはG_ADMINの必要な登録・参照・更新・削除権限と予約属性versionを用意します。メニューと一般利用者向け操作マニュアルを更新し、設計情報の検証・コード生成・起動を行って保存後の内容を確認してください。

4. 編集されるAppSchemaの例

以下は関連する定義の抜粋です。構文を覚えなくても、実現したい動作をAIへ伝えられます。

# DeliveryPlan.yaml の属性の抜粋
entity:
  attributes:
    - { name: 受注ID保存列, name_en: orderKey, type: long,
        pk: true, not_null: true, hidden: true }
    - { name: 明細番号保存列, name_en: lineKey, type: long,
        pk: true, not_null: true, hidden: true }
    - { name: 納品番号, name_en: deliveryNo, type: branchid, pk: true }
    - name: 受注明細
      name_en: lineRef
      type: reference
      not_null: true
      fk:
        entity: order_line
        mappings:
          - { local: orderKey, target: orderId }
          - { local: lineKey, target: lineNo }
    - { name: 納品日, name_en: deliveryDate, type: date }
    - { name: 納品数量, name_en: quantity, type: integer }

参照先の複合主キー全項目を、同じ順序で対応付けます。lineRefは論理参照なので主キーにはせず、保存用のorderKey・lineKeyと枝番を主キーにします。保存用キーの入力補完や納品番号の採番は標準処理が行います。複合親キーの関係はui.form.childrenの同時保存には指定できません。

5. 参考資料

guide:エンティティ間の関係
designer/docs/appschema/html/guide/03-model/03-relations.html
reference:entity
designer/docs/appschema/html/reference/06-entity.html
guide:詳細画面
designer/docs/appschema/html/guide/07-screens/06-detail.html