NuAppにおける「明細」は、データ構造、業務フロー、自動計算が密接に絡み合うシステム設計の最重要トピックの一つです。
明細は便利である反面、設定箇所が「データ設定」「プロセス設定」の中でも多岐にわたるため、バラバラに設定を見ているだけでは全体像が掴みにくいという特性があります。
この記事では、開発者が実際の案件で「明細」を迷わず正しく設計・構築できるよう、以下の流れに沿って設計思想から実装のステップまでを体系的に解説します。
- 第1章:概念理解(明細とは何か、一般的なツールと異なるNuApp独自の強み)
- 第2章:モデル(データ・プロセスの器)の構築(データ設定での器の作り方と考慮点)
- 第3章:アプリ(実際の機能)での権限制御(プロセス設定におけるタスク・列単位の制御)
- 第4章:バックエンド自動処理(データ操作を使った高度な計算やレコード展開)
明細とは?
明細とは何か、その具体例
NuAppにおける「明細」とは、1つの「モデル」の中に、複数行の従属データを内包して管理するためのデータ構造です。
- 具体例:
- 見積書・請求書モデル: 「見積ヘッダ(顧客名、有効期限、合計金額など)」という親データに対して、複数行並ぶ「見積明細(商品名、数量、単価、金額など)」の行データ。
- 経費精算モデル: 「申請ヘッダ(申請者、申請日、合計金額など)」に対して、1回の出張に伴う複数の「利用実績明細(利用日、交通機関、区間、金額など)」の行データ。
従来のRDB(リレーショナルデータベース)でいう「1対多のテーブル結合」を、モデルの内部に最初から組み込まれているかのように、直感的に、かつ強力に制御できます。
明細機能を使うメリット
モデル内に明細を組み込むことで、システム開発において以下の大きなメリットが生まれます。
- 直感的なUI/UXの実現: ユーザーは1つの画面(アプリ)を開くだけで、全体の情報と、それに紐づく複数の行データを同時に閲覧・編集できます。画面を何度も行き来するストレスがありません。
- プロセスの連動が一蓮托生: 「親データが承認されたら、明細も同時に編集ロックをかける」といった、実業務に即したライフサイクル管理(プロセス制御)が容易になります。
- データ整合性の担保: バラバラのモデルで管理するよりもデータの結びつきが強固なため、集計漏れや「親のいない迷子データ」の発生をシステム構造的に防ぐことができます。
一般的なノーコードツールと比較したNuAppの強み・特徴
多くの一般的なノーコードツールにも「サブテーブル(明細)」に類する機能は存在しますが、NuAppの明細は「業務アプリとしての実戦力」が圧倒的に違います。
- 強み①:シームレスな操作性(画面遷移ゼロ) 多くのノーコードツールでは、明細の追加・編集を行う際に別のページへ遷移したり、ポップアップウィンドウを開いたりするオーバーヘッドが発生します。NuAppでは、親モデルの画面上で明細行を直接操作できるため、ユーザーは画面遷移のストレスなく、Excelのような軽快さで連続入力が可能です。この「業務を止めないUI」は、現場の入力負荷を劇的に下げます。
- 強み②:タスク・権限と連動した「列(カラム)単位の制御」 「明細全体を見せる/隠す」だけでなく、「このタスク(プロセス)の時は、明細内の『仕入単価』の列だけを非表示にする、あるいは編集不可にする」といった、業務フローに同期した緻密な権限制御が標準機能で実装できます。
- 強み③:「データ操作」による高度な自動処理とバラシ 明細内の行ごとの自動計算はもちろん、明細全体の縦計(サマリー)を親データの項目に自動反映する設定がノーコードで完結します。さらに、プロセスが進んだ段階(例:受注時)で、明細の各行データを別のモデルの独立したレコード(例:発注データ)へと一括自動展開(バラシ)するような、高度なバックエンド処理(データ操作)の仕組みが最初から備わっています。
【データ設定】明細の器(モデル)を作る
NuAppにおける明細の構築は、データの依存関係や自動処理の動きを正しく理解し、モデルの属性をどう定義するかが鍵となります。
大前提:明細のアーキテクチャ思想
一般的なノーコードツールにあるような「単に画面上に表を作る機能」とは異なり、NuAppの明細は「別モデルとして定義したものを、親モデル側から『明細型』として参照する」という構造になっています。
- 独立したデータとプロセス: 明細側として指定するモデルも、それ単体で「独立したデータ」と「プロセス」を持っています。そのため、「明細のデータだけを別の業務で集計する」「明細単体で独自のステータスやワークフローを持たせる」といった、RDB(リレーショナルデータベース)と同様の高度なモデリングが可能です。
ベーシックな基本設定
明細型の属性を設定する際、ユーザーの入力負荷を減らし、データの品質を保つための必須の基本機能が備わっています。
- 重複行の排除: 同じ商品や項目が、明細内に2行以上重複して登録されるのをシステム的に防ぎます。
- 自動並び替え(ソート): 入力された順ではなく、「日付順」「項目コード順」など、あらかじめ指定したルールで明細行を自動的に並び替えて整頓します。
画面上での「自動的なデータ反映」3つのパターン
明細の入力時、画面遷移なしでユーザーに心地よい自動化を提供するために、以下の3つの連動設定(補完・コピー・集計)を組み合わせて設計します。
① 明細型の「明細への自動補完」設定(親 → 明細への反映)
親モデルに入力された値を、全ての明細行へ自動的にコピー・同期させる機能です。
- ユースケース: 見積書(親)に「拠点:東京本社」や「担当営業:山田」と入力した際、その見積書に含まれる全ての明細行の裏側データにも、自動的に「東京本社」「山田」という値をセットしたい場合に使用します。明細ごとに同じ値を何度も選ばせる無駄を排除できます。
② 明細そのもののコピー(参照モデル → 明細への一括展開)
同じ明細のセットを持つ別の「マスタ・参照型モデル」から、明細データをごっそりコピーして展開する機能です(自動補完設定を利用)。
- ユースケース:「見積テンプレート」からの展開 あらかじめ「標準プラン」というテンプレート用モデルを作っておき、そこに明細(商品A、商品B、商品C)をセットしておきます。ユーザーがアプリ上で「標準プラン」を選択すると、その瞬間に明細のセットが画面上に一括で自動展開されます。ユーザーが1行ずつ明細を追加する手間を徹底的に省くことができます。
③ 合計値の算出(明細 → 親への縦計反映)
明細内に入力された数値データを足し合わせ、親モデル側にリアルタイムに反映させる機能です。
- 設定方法: 親モデル側に「計算型」の属性を用意し、明細の合計を出す設定(SUM関数のようなイメージ)を行います。
- ユースケース: 明細行の「金額」の総合計を、親モデルの「見積合計金額」に自動反映させる、経費精算の明細の合計を「総申請金額」に自動反映させる、といった業務アプリの必須要件をノーコードで実現します。
【プロセス設定】タスクごとの「操作・権限」を制御する
データ設定で定義した明細を、実際の業務フロー(タスク)の中でどのように制御するかを設計します。NuAppの明細権限は「2層(明細全体への操作 ✕ 各項目への権限)」に分かれており、親モデルの各タスクごとに設定を行います。
1層目:明細そのものを操作する権限(アクションの制御)
まずは、そのタスクにおいてユーザーが「明細の行(レコード)そのもの」に対して、どんな操作をしてよいかを定義します。以下の4つのアクションから、業務要件に合わせて複数選択で許可を与えます。
- 追加: 新しい明細行をその場で追加できる。
- 削除: 既存の明細行を削除できる。
- 更新: 明細行のデータを書き換えることができる。
- インポート: 保存済みデータを選択して、取り込むことができる。
💡 実務での定石例: 「営業担当の作成タスク」では、上から3つを許可し、「上長承認タスク」ではすべてチェックを外す(=明細の行追加や削除を完全にロックする)といったメリハリのある設計を行います。
2層目:項目毎の権限(カラム単位の制御)
「明細の行は追加できるが、特定の列(カラム)だけは見せたくない、あるいは編集させたくない」という、さらに細かい制御を行います。
- 設定の仕組み: NuAppでは、親モデルのタスク画面の中に、「明細側モデルで通常通り設定したタスク」を紐付ける(割り当てる)という独特の方式をとります。
- ユースケース: 明細側モデルに「通常入力タスク(金額・数量ともに編集可)」と「購買用タスク(仕入単価のみ編集可、他は読み取り専用)」を作っておきます。親モデルの「営業入力タスク」の画面には、明細側モデルの「通常入力タスク」を適用させることで、列単位の権限を連動させます。
【超重要】設計における最大の難所:親と子の「プロセス同期」
SEが実装する上で、最も知識と工夫が必要になる、最大の罠でありポイントがここです。
親モデル側のタスクでどれだけ「明細の更新」や「明細側タスク(編集可能状態)」を指定していても、明細(子モデル)自身のプロセスが「編集不可能なタスク(例:確定・完了タスク)」に遷移してしまっていると、画面上ではロックがかかってしまい編集できません。
- 失敗パターン(アンチパターン): 親のステータスは「差し戻し(編集したい)」なのに、子のステータスは前回の処理で「確定」のまま残っている。結果、親画面を開いても明細がグレーアウトして直せない。
- 正しい設計思想(ベストプラクティス): 明細データのライフサイクル(プロセス)が、親データの進捗と必ず一致するように設計してください。 具体的には、親モデル側で「タスクが差し戻された時」のアクション(データ操作等)として、紐づく子モデル(明細)のステータスも同時に「編集可能なタスク(作成中など)」へ引き戻す(同期させる)プロセスを必ずセットで実装します。
【データ操作・モデル連携】自動処理と高度なプロセス連動
データ設定、プロセス設定(画面上の権限)を終えたら、最後はバックエンドでの「自動処理(データ操作)」と「モデル間の連携(メッセージ送受信)」の設計です。NuAppでは、明細ループや非同期のプロセス連動といった、高度なシステムロジックをノーコードで実装できます。
明細に対するデータ操作(ループ処理と一括更新)
明細データに対して裏側で自動処理を走らせる際、NuAppは柔軟なスキャン(走査)と更新ロジックを持っています。
- ピンポイント指定と一括更新: 明細の「最初の行だけ」「最後の行だけ」といった特定のレコードを狙った操作はもちろん、「すべての行に対して一括でデータを更新・書き換える」というループ処理が可能です。
- 前行の結果を引き継ぐ累積計算(シーケンシャル処理): 明細を一括更新する際、「前の行の計算結果(状態)を、次の行の更新処理に引き継いで使う」という高度なロジックが組めます。
- ユースケース: 在庫の「移動明細」において、1行目(初期在庫10 + 入庫5 = 残15)の計算結果である「残15」を、2行目(残15 - 出庫3 = 残12)の計算に引き継ぐような、「在庫のスライド残高計算」や「累積値の算出」がノーコードで実現できます。
明細からのデータ反映(バックエンド集計)
画面上のリアルタイム計算(第2章の計算型)とは別に、バックエンドのバッチ的なタイミングでも明細を集計できます。
- SUM関数によるバックエンド演算: 「ステータスが〇〇に変わった瞬間」などのトリガーで、データ操作内の演算機能(SUM関数など)を使い、明細データを集計して親モデルや別モデルへ値を書き込むことができます。
モデル連携(明細の自動生成と動的追加)
通常は「親を作ってから、その中に明細(子)を追加する」という流れですが、NuAppではその逆、あるいは「データが存在しなければ親を自動生成して潜り込む」という賢い連携が可能です。
- 「親を自動生成 ➔ 自分を明細として追加」ロジック: 先に子データ(明細となるデータ)だけが単体で発生する業務(例:外部システムから流れてくる毎日の売上明細データなど)において、
- バックエンドで「その子データの条件に合う親データ(例:該当月の売上伝票ヘッダ)」が存在するか検索する。
- なければ、親データをバックエンドで自動的に新規生成する。
- 生成された(あるいは既に存在していた)親データの中に、自分自身(子データ)を明細行として自動的に追加・格納する。
- メリット: ユーザーが手動で伝票(親)を作ってから明細を入力するという手間を完全に自動化し、データの取り込み・整理をバックエンドで完結させられます。
親と子のプロセス連動(メッセージ送受信による非同期制御)
第3章で触れた「親子のプロセス同期」をさらに高度化させ、時間差(非同期)での制御を可能にするのが「メッセージ送受信」機能です。
- 明細側の「一時停止」と親側からの「再起動」: 明細(子)側は、自身のプロセスを進めていく中で、途中の特定のタスクで一回ストップ(待機状態)させておきます。
- 親のタイミングで後続処理を発火: その後、親モデル側のプロセスが特定のステータス(例:全体の最終承認など)に達したタイミングで、子モデルに対して「メッセージ」を送信します。これを受信した子モデルは、ストップしていたタスクから後続の処理(例:別システムへの連携、確定処理など)を一斉に再開します。
- メリット: 「10行ある明細がそれぞれバラバラに進捗しつつも、最終的な完了のタイミングだけは親データの意思決定に強制的に合わせる」といった、複雑な分散ワークフローが美しくコントロールできます。