本 エッセー のなかで示した 「バッチ・バランス・リスト」 の記述は曖昧になっていて申し訳ない。というのは、「HDR」 の数量を導出項目 （D） として記述していますが、「バッチ・バランス・リスト」 では、ふつう、この数量を 「コントロール 数」 とみなして、実際の伝票上の数値を ユーザ が計算して [ 足して総計をもとめて ] 総計を入力します。そして、入力された総計値と コンピュータ のなかで計算された総計値を対比して、一致していれば OK として、一致していなければ、入力された総計値が間違っているか、あるいは、コンピュータ のなかの 「受注」 数値が入力されたときに入力 ミス （数値を間違って入力したこと） があったかの どちらかなので、一致しなかった原因を調べるために、「バッチ・バランス・リスト」 が使われます。

　「バッチ・バランス・リスト」 の扱いには、以下の 2つがあります。

　（1）ワーク・ファイル として扱う [ あくまで、「検算」 として扱う ]。
　　　（したがって、コンピュータ のなかに数値を ストア しない）

　（2）そういう 「事実」 があったことを記録する
　　　（したがって、コンピュータ のなかに数値を ストア する）

　いずれの やりかた を導入するかは、システム の性質に依存するので、プロジェクトで 「設計の基本指針」 として決めるべきでしょうね。ふつう、（1） で実施します。

　さて、（2） の前提に立って、「コントロール 数」 を入力値として考えれば、以下の データ は ストア されるでしょう。

　｛取引先 コード（R）、取引日、数量｝.

　そして、もし、入力された 「コントロール 数」 と コンピュータ のなかに ストア されている 以下の数量の総計が 「一致していない」 場合には、どちらかの数値が──あるいは、ふたつの数値とも──間違っていることになるので、「一致していない」 原因を調べることになります。

　｛受注番号、取引先 コード（R）、商品 コード（R）、取引日、数量｝.

　もし、「コントロール 数」 の総計のほうが正しくて、「受注」 伝票の数値が （1つ、あるいは複数・多数） 間違っていたのであれば──伝票を入力するときに数値を間違っていた、ということですが──「受注」 伝票の数値を訂正することになります。この場合、「訂正伝票」 を使って数値を修正するでしょうね。原帳票 （受注伝票と受注修正伝票） が監査証跡として遺っているので、「HDR」 を ストア する意味はないでしょう。「HDR」 は、あくまで 「検算」 用の ワーク・ファイル として扱っていいでしょうね。

　したがって、「バッチ・バランス・リスト」 は、ふつう、ワーク・ファイル として扱えばいいのですが、もし、内部統制上、ワークフロー において、「検算」 を実施したかどうか の証跡を遺さなければならないのであれば、「バッチ・バランス・リスト」 を ストア するかもしれない。

　さて、いずれにしても、「バッチ・バランス・リスト」 は、あくまで、「検算」 機能であって、「DTL」 に対する 「HDR」 ではないでしょうね。

　ただし、もし、「冊」 とか 「束」 という単位を導入していて、「受注」 を いくつか まとめて ひとつの 「冊」 （あるいは、「束」） にして、「冊」 （あるいは、「束」） が後続する event と関係をもつのであれば、「冊」 （あるいは、「束」） は──技術的には、「バッチ・バランス・リスト」 と同じです──、「HDR」 として作用します。このときには、「冊番号」 （あるいは、「束番号」） が導入されているでしょう。そして、「受注」 と 「冊 （あるいは、束）」 とのあいだには 「対応表」 が導入されるのですが、「HDR-DTL」 構成と同値でしょうね。

　┌─────────────────┐　　　　　┌─────────────────┐
　│　　　　　　　受注　　　　　　　Ｅ│　　　　　│　　　　　　　　冊　　　　　　　Ｅ│
　├────────┬────────┤　　　　　├────────┬────────┤
　│受注番号　　　　│受注日　　　　　│　　　　　│冊番号　　　　　│作成日　　　　　│
　│取引先コード(R) │数量　　　　　　│＞─○─┼┤　　　　　　　　│　　　　　　　　│
　│商品コード(R) 　│　　　　　　　　│　　│　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　│　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　│　　│　　  　　　　　│　　　　　　　　│
　└────────┴────────┘　　│　　└────────┴────────┘
　　　　　　　　　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　│
　　　　　　　　　　　　　┌────────┴────────┐
　　　　　　　　　　　　　│　　　　受注. 冊. 対応表　　　　　│
　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　　　　│受注番号(R)　 　│　　　　　　　　│
　　　　　　　　　　　　　│冊番号(R)　　 　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　└────────┴────────┘

　なお、「冊」 の 「event」 としての日付を 「作成日」 として ぼやかしてありますが、この日付の付値には、以下のような形態があるでしょう。

　（1） 受注に対する期間固定
　（2） 受注に対する数量固定

　などなど。
　「受注に対する期間固定」 というのは、或る一定期間ごとに受注を ロット 化する やりかたで──その期間のあいだに起こった受注 [受注日 ] を ひとつの 「冊」 として まとめます。たとえば、１週間ごとに 「受注」 を まとめるとか。「受注に対する数量固定」 というのは、「受注」 の数量を足して、或る まとまった量になったら、ひとつの 「冊」 を作る やりかた です。たとえば、以下を例にして、それぞれの ロット 化を説明します。

　　受注番号 001　商品 A　受注日 20091001　数量 30
　　受注番号 002　商品 B　受注日 20091002　数量 50
　　受注番号 003　商品 A　受注日 20091002　数量 40
　　受注番号 004　商品 A　受注日 20091005　数量 20

　「期間固定」 法として、たとえば、2009年 9月27日から 2009年10月 3日までの一週間に起こった受注を ひとつの 「冊」 にするのであれば、受注番号 001、002 および 003 が ひとつの 「冊」 になります。

　「数量固定」 法として、たとえば、ひとつの 「冊」 の数量を 100個 （あるいは、その近傍） とすれば、受注番号 001 と 002 を ひとつの 「冊」 にするかもしれない。したがって、「冊」 の作成日は、2009年10月 2日以後の値となるでしょう。

　さらに、「商品」 ごとに、「期間固定」 「数量固定」 を適用するかもしれない。
　こういう詳細な制約・束縛は、企業ごとにちがうので、現場・現物で確認してください。