rex0220 計算式プラグイン仕入れ先別テーブル集計に入力用請求日を追加

kintone

Last updated at 2025-12-11Posted at 2025-04-07

rex0220 計算式プラグイン仕入れ先別テーブル集計に、入力用請求日を追加してみます。
集計先テーブルに入力用項目を設定する例になります。

概要

申請社給品、購入金額、購入元が指定されたテーブル行を仕入テーブルに集計します。
仕入テーブルには、入力用請求日を追加します。
※仕入先別合計テーブルと仕入テーブルは横並びプラグインで並べています。

単純にテーブル集計を行うと請求日がクリアされるので、「仕入先 & "-" & 発注品 & "-" & 単価」をキーとして、請求日を集計後にも反映させます。

操作例

計算式プラグイン設定

仕入テーブルの計算式
- dic 変数に、集計前の請求日を格納
- psum 変数に、仕入テーブル用の集計データを作成
- 仕入テーブルにpsumの値をセット
- dic 変数から集計前の請求日を請求日にセット

OPTION: 循環参照を許可

// 購入.購入引当 NUMBER
LET(
  w, TR_SUM(申請個数,-在庫対応),
  IF(w>0, w, 0)
)

// 購入.購入金額 NUMBER
購入引当*申請単価

// 仕入先別合計 SUBTABLE
TLTABLE(購入,
    TPFILTER(AND(申請社給品,購入金額>0,購入元)),
    TPKEY(購入元),
    TPVAL(購入金額),
    TPOUT(仕入先T,発注金額T)
)

// 仕入先別合計.発注金額:発注金額T NUMBER


// 仕入 SUBTABLE
LET(dic, DIC(), // 辞書作成
  dummy, TARRAY(
    LET(key, 仕入先 & "-" & 発注品 & "-" & 単価, // キー作成
      DIC_ITEM(dic, key, 請求日) // 辞書登録
    )
  ),
  psum, TLTABLE(購入, // 購入集計
    TPFILTER(AND(申請社給品, 購入金額 > 0, 購入元)), // 条件指定
    TPKEY(購入元, 申請社給品, 申請単価), // 集計キー
    TPVAL(購入引当, 購入金額), // 集計値
    TPOUT(仕入先, 発注品, 単価, 発注個数, 発注金額) // 出力項目
  ),
  dummy, FSET(仕入, psum), // 仕入反映
  dummy, TARRAY(
    LET(rowno, ROWNO(仕入), // 行番号取得
        key, 仕入先 & "-" & 発注品 & "-" & 単価, // キー作成
        FSET(請求日, DIC_ITEM(dic, key), rowno) // 日付反映
    )
  ),
  "" // 終端
)

// 仕入.仕入先 DROP_DOWN
// 仕入.発注品 DROP_DOWN
// 仕入.発注個数 NUMBER
// 仕入.単価 NUMBER
// 仕入.発注金額 NUMBER

計算式アドバイザー・フェリスの解説

少し計算式がわかりにくいので、rex0220 計算式アドバイザー・フェリスに解説してもらいます。

// 仕入 SUBTABLE
LET(dic, DIC(), // 辞書作成
  dummy, TARRAY(
    LET(key, 仕入先 & "-" & 発注品 & "-" & 単価, // キー作成
      DIC_ITEM(dic, key, 請求日) // 辞書登録
    )
  ),
  psum, TLTABLE(購入, // 購入集計
    TPFILTER(AND(申請社給品, 購入金額 > 0, 購入元)), // 条件指定
    TPKEY(購入元, 申請社給品, 申請単価), // 集計キー
    TPVAL(購入引当, 購入金額), // 集計値
    TPOUT(仕入先, 発注品, 単価, 発注個数, 発注金額) // 出力項目
  ),
  dummy, FSET(仕入, psum), // 仕入反映
  dummy, TARRAY(
    LET(rowno, ROWNO(仕入), // 行番号取得
        key, 仕入先 & "-" & 発注品 & "-" & 単価, // キー作成
        FSET(請求日, DIC_ITEM(dic, key), rowno) // 日付反映
    )
  ),
  "" // 終端
)

計算式アドバイザーのフェリスの回答

こんにちは！rex0220 計算式アドバイザーのフェリスです。

ご提示いただいた計算式は、**「集計処理を行いながら、手入力したデータを維持する」**という、非常に高度で実用的なテクニックが使われていますね！

通常、計算式でテーブルを再生成（集計）すると、そのテーブルに手入力していたデータ（ここでは「請求日」）は消えてしまいます。しかし、この式では**「辞書（Dictionary）」機能**を使って一時的にデータを退避させ、集計後に復元することでその問題を解決しています。

詳しく解説しますね。

計算式の全体像

処理は大きく分けて以下の3つのステップで行われています。

【退避】 現在のテーブルにある「請求日」を、キー（仕入先+商品+単価）と共に辞書に保存する。
【集計】 別のテーブル（購入）からデータを集計し、仕入テーブルを書き換える。
【復元】 書き換わった仕入テーブルに対し、キーが一致する場合、辞書から「請求日」を戻す。

ステップごとの詳細解説

1. データの退避（Backup）

LET(dic, DIC(), // 空の辞書を作成
dummy, TARRAY(
  LET(key, 仕入先 & "-" & 発注品 & "-" & 単価, // ユニークなキーを作成
  DIC_ITEM(dic, key, 請求日) // 辞書にキーと「請求日」を登録
  )
),

DIC(): データを一時保存するための箱（辞書）を作ります。
TARRAY(...): テーブルの全行に対して処理を行います。
key: 「仕入先」「発注品」「単価」を連結して、行を特定するためのID（キー）を作ります。
DIC_ITEM: 作成した dic に、key を見出しにして、現在の 請求日 を保存します。これで、後でテーブルが書き換わっても日付を思い出せます。

2. データの集計と反映（Aggregation & Update）

psum, TLTABLE(購入, // 購入テーブルを集計
  TPFILTER(AND(申請社給品, 購入金額 > 0, 購入元)), // 条件：品名あり、金額>0、購入元あり
  TPKEY(購入元, 申請社給品, 申請単価), // 集計キー：購入元、品名、単価ごとのグループにする
  TPVAL(購入引当, 購入金額), // 集計値：個数と金額を合計する
  TPOUT(仕入先, 発注品, 単価, 発注個数, 発注金額) // 出力先：仕入テーブルの項目へマッピング
),
dummy, FSET(仕入, psum), // 仕入テーブルを集計結果(psum)で上書き

TLTABLE: 購入テーブルのデータを集計します。
FSET(仕入, psum): ここで 仕入 テーブルの中身が、集計結果 psum に完全に置き換わります。
- ⚠️ 重要: この瞬間、手入力していた「請求日」は一度消えて空っぽになります。

3. データの復元（Restore）

dummy, TARRAY(
  LET(rowno, ROWNO(仕入), // 新しいテーブルの行番号を取得
  key, 仕入先 & "-" & 発注品 & "-" & 単価, // 再びキーを作成
  FSET(請求日, DIC_ITEM(dic, key), rowno) // 辞書から日付を取り出してセット
  )
),
"" // 計算式の最後は値を返す必要があるため空文字などを置く
)

TARRAY: 新しくなった 仕入 テーブルの行を順番に処理します。
key: ステップ1と同じルールでキーを作ります。（仕入先、発注品、単価が変わっていなければ同じキーになります）
DIC_ITEM(dic, key): 辞書の中に、このキーに対応する「請求日」が保存されているか確認します。
FSET(請求日, ..., rowno): 保存されていた日付があれば、それを現在の行（rowno）の 請求日 項目に書き込みます。

まとめ

この計算式は、「集計ロジック（TLTABLE）」と「手入力データの維持（DIC/FSET）」を組み合わせた素晴らしい例です。

メリット: 購入テーブルデータが更新されて再集計が走っても、一度入力した請求日は消えずに残ります。
ポイント: キーとなる項目（仕入先、発注品、単価）が変わると、別のデータとみなされて請求日は引き継がれません。

もし、この式をカスタマイズしたい場合や、別の項目も維持したい場合は、DIC_ITEM で保存する値や FSET で復元する部分を追加すれば対応できますよ。

何か他に気になる点はありますか？

他アプリへの応用での注意点

別アプリで同様のことを行う場合に、気を付ける点は？

計算式アドバイザー・フェリスの回答

別のアプリでこの「集計＋手入力データ維持」のロジックを実装する場合、特に気を付けるべきポイントは**「データの消失リスク」と「キー（紐付け）の正確さ」**の2点です。

この計算式は、一度テーブルを丸ごと書き換える（上書きする）処理を含むため、設定を間違えると入力したはずのデータが消えてしまう可能性があります。

具体的に注意すべき5つのポイントをまとめました。

1. 「キー（Key）」の作り方が最重要

このロジックの命綱は、データを退避・復元するための「キー」です。
[cite_start]例では 仕入先 & "-" & 発注品 & "-" & 単価 をキーにしています [cite: 32]。

注意点: 集計元（購入アプリなど）でデータが修正され、キーの構成要素（例：商品名や単価）が変わると、「別の行」とみなされてしまいます。
結果: 元のキーで保存されていた「請求日」などの手入力データは引き継がれず、消えてしまいます。
対策: キーには、変動しにくい一意のID（コードなど）を含めるのがベストです。

2. `FSET` によるテーブルの完全上書きリスク

[cite_start]計算式の中の FSET(仕入, psum) は、仕入テーブルを psum（集計結果）で完全に置き換えます [cite: 7, 32]。

注意点: もし TLTABLE の集計条件（TPFILTER）が間違っていて、集計結果が 0件（空っぽ）になった場合、仕入テーブルも空っぽになり、入力していたデータも全て消えます。
対策: TPFILTER の条件式は慎重に設定し、意図せず 0件にならないように注意してください。

3. 保存したい項目を確実に `DIC` に入れる

[cite_start]例では「請求日」だけを保存していますが、他にも手入力項目（例：備考、ステータス）がある場合は、それらも忘れずに辞書（DIC）に入れる必要があります [cite: 1]。

対策: 保存したい項目が複数ある場合は、辞書の値を配列やオブジェクトにするか、項目ごとに別のキーで辞書登録する工夫が必要です。
- 例: DIC_ITEM(dic, key, ARRAY(請求日, 備考))

4. フィールドコードの完全一致

別のアプリに移植する際、最も多いミスがフィールドコードの間違いです。

[cite_start]注意点: 計算式内のフィールドコードは、新しいアプリの設定と完全に一致している必要があります。特に TLTABLE の TPOUT（出力先）の並び順とデータ型が、受け取り側のテーブル項目と合致していないとエラーになります [cite: 15]。

5. 処理が重くなる可能性（パフォーマンス）

この処理は「辞書作成（全行ループ）」→「集計（全データ参照）」→「書き込み」→「復元（全行ループ）」という重い処理を一度に行います。

注意点: テーブルの行数が数百行になると、ブラウザが固まったり、処理に時間がかかったりする可能性があります。
対策: 不要な行は集計しないようにフィルタリングするか、行数が増えすぎない運用を心がけてください。

私（フェリス）からのアドバイス

新しいアプリでこの式を作成する際は、いきなり本番データで試さず、以下の手順でテストすることをお勧めします。

テスト用のレコードで、手入力データ（請求日など）を入れる。
集計元のデータを変更して、再計算を実行する。
「行が増減しても、手入力データが正しい行に残っているか？」 を確認する。

もし、新しいアプリ用に書き換えた計算式に不安があれば、作成した式を見せてくださいね。フィールドコードが正しいかなど、私がチェックします！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

rex0220 計算式プラグイン 仕入れ先別テーブル集計に入力用請求日を追加

概要

操作例