前回に引き続きGeneral Ledger Entry(会計元帳明細)のDimension Code(分析コード)の修正について説明します。前回は1明細のG/L EntryのDimension Codeを修正しました。今回は複数レコードについて修正する方法を説明します。
前回のおさらい
前回、分析コード値を修正した後に”Dimension Correction”ページを開くと下図のように不要なレコードが表示されていました。Entry No.3は実際に分析コード値を修正したレコードですが、それ以外に多数の”Draft”レコードが作成されています。これはいつ作られたのでしょうか？
前回と同じような手順を実行してみます。General Ledger Entriesの画面から”Correct Dimensions”ボタンをクリックします。
すると”Draft Dimension Correction”のカードページが開きます。”Created at”の日付時刻を見ると今日の今の時間帯です。つまり、このレコードはまさに今作られた事が分かります。左上の矢印で前の画面に戻ります。
General Ledger Entries画面で再び”Correct Dimensions” をクリックします。
すると再び”Draft Dimension Correction”のカードページが開きます。”Created at”を確認すると、また新たにレコードが作成されたことが分かります。
”Dimension Correction”のリストページに戻って画面をフレッシュすると新たに2つのレコードが作成されています。つまり、General Ledger Entriesの画面からDimensionを修正しようとすると、作業を中断するたびに不要なレコードが意図せず作成されてしまいます。前回の記事の最後にも書きましたが、”Deimension Correction”の使い方としてGeneral Ledger Entriesの画面から分析項目値を修正するのはベストな方法ではないと考えます。
推測になりますが、設計意図としては”Draft Dimension Correction”を新規で1レコード作成し、それに対して特定の条件を満たすGeneral Ledger Entriesのレコード群を割り当てて、分析項目の値を修正するのが正しい使い方だと思います。
そう考えると、分析項目の値を変更するのにわざわざJob Queueでバッチ処理をする理由が理解できます。前回の様に1件のG/L Entryを修正するだけであればJob Queueのバッチ処理も不要ですし、そもそも”Draft Dimension Correct”のカード画面も不要です。大量のデータを修正するからカードやJob Queueを用意している、と考える方が自然です。
業務的には、以下のようなシナリオを想像してみましょう。
”SalespersonのJO(Jim Olive)は3月1日からはCustomerGroupがSmallに分類される顧客の担当を外れたにも関わらず、3月の転記日付でJOの売上が計上されていることに気づきました。3月以降はJOから引き継いだ別の担当者LT(Lina Townsend)が売上を計上すべきでしたが手違いによりJOで計上されてしまっていました。これを修正します。”
以下、分析項目を修正する対象のGeneral Ledger Entriesを抽出し”Draft Dimension Correction”に割り当てて分析項目値を変更する方法を説明します。
a. 準備
Cronusカンパニーの既定の設定ではGeneral Ledger Entriesに”Area”や”Salesperson”の分析項目が表示されていません。これはGeneral Ledger Setupにショートカット分析項目の設定が不足しているからです。下図のようにShortcut Dimension3～8が設定されていません。
以下のようにShortcutDimension3に”Area”, ShortcutDimension4に”Salesperson”を設定します。
すると、General Ledger Entries(会計元帳明細)にShortcutDimension3,4が表示されました。ちなみに、設定直後は”ShortcutDimensionX”と表示されますが、少し時間が経過すると”Area”, ”Salesperson”のように分析項目名が表示されるようになります。
b. 分析項目値が誤っているG/L明細の発見
ここからは業務のシナリオに沿って進めます。
経理担当者がGeneral Ledger Entry(会計元帳明細)をチェックしていました。G/L Registerの画面から一つの元帳登録番号(今回の例では378)を選択して”Process”タブの中の”General Ledger”をクリックします。
このG/L Register No.(会計元帳登録番号)に紐づくG/L Entries(会計元帳明細)が表示されました。転記日付が2021年3月以降にも関わらずCustomerGroupがSmallでSalesPersonがJOの売上明細が存在します。
JOは3月から担当を外れたはずです。営業部門に確認すると間違って入力されてデータであり、SalespersonはLT(Lina Townsend)が正しいとのことでした。
c. 分析項目値訂正カード伝票の作成
誤った分析項目値を訂正します。”Dimension Correction”リストページから”+新規”ボタンをクリックします。
新規の”Draft Dimension Correction”カードページが開きました。”Description”に今回の修正内容を記述します。現時点では中段の”Dimension Correction Changes”にも下段の”Selected Ledger Entries”に何も表示されていません。これから対象のG/L Entriesを抽出して指定し、変更後の分析項目値を指定します。
下段の”Selected Ledger Entries”のセクションには6つのボタンが存在します。これらのボタンを使用して対象のG/L Entriesを絞り込んでいきます。これらのボタンの使い方を順に説明します。
d. マニュアル選択
”Selected Manually”ボタンを使うとG/L Entriesの一覧から任意の明細を選択できます。ボタンをクリックしてみましょう。
General Ledger Entriesの一覧画面が表示されました。ここで対象の明細を選択して”OK”ボタンを押すと対象の明細を指定できます。全てのG/L Entriesが表示されているため探すのが大変ですが、この画面ではFilter機能が使用できます。今回のケースではG/L EntriesのEntryNo.が判明しているので、EntryNo.をフィルタします。
Entry No.=1631を指定します。
対象のG/L Entryが絞り込まれました。ここで”OK”をクリックします。
”Draft Dimension Correction”カードページに戻りました。下段の”Selected Ledger Entries”に指定したG/L Entry No.が表示されています。
このように、”Select Manually”ボタンは対象のG/L Entryを指定する最もシンプルな方法です。
e. 関連明細の追加
次は”Add Related Entries”ボタンです。どのような”関連明細”が指定されるかTooltipを読むだけでは分かりませんので、実際にクリックしてみましょう。
G/L Entryが1明細追加されました。この明細は何でしょう？
これは同じ会計元帳登録番号に紐づいている売上の明細です。
追加された明細に関連する明細がないかを確認します。明細を全選択して再び”Add Related Entries”ボタンをクリックします。
明細は増えませんでした。これ以上関連明細は無い、という事でしょう。”関連明細”の定義については現時点ではDocsに明記されていないため定義は不明です。今後、Microsoftから情報提供されるのを待ちたいと思います。
f. 明細の削除
”Selected Ledger Entriesの”明細を削除する場合、例えば提案された関連明細を対象明細に含めたくない場合は、削除対象の明細を選択した状態で”Remove Entries”をクリックします。
すると明細が削除されました。
ここで再び”Add Related Entries”をクリックしてみると何が起きるでしょうか？
先ほどの関連明細が追加されると思ったのですが、、何も追加されません。もう一度ボタンを押しても何も起きません。
初めてこれを見た時はバグか？と思ったのですが、バグではありません。それには”Manage Selection Criteria”を理解する必要があります。
g. 選択基準の管理
”Manage Selection Criteria”をクリックしてみましょう。
以下の画面が表示されます。この画面ではこれまでに実施したG/L Entriesを選択した操作手順が上から下に記述されています。最初にマニュアルで番号指定し、関連明細を検索、再度関連明細を検索、関連明細を削除、関連明細を検索、再度関連明細を検索、という順序です。現在の状態で”Add Related Entries”を何度押しても、一番下の行に”Related Entries”の明細が追加されるだけです。4行目の”Excluded”の手順が残っている限り関連明細は表示されません。このアーキテクチャーは非常に重要なので覚えておく必要があります。
4行目以降の明細を選択して”Delete”ボタンをクリックします。
1明細しか削除されませんでした。。これはバグだと思います。
1件ずつ削除し、”Excluded”以降の明細をすべて削除しました。”Close”ボタンで前の画面に戻ります。
これで関連明細が復活しました。
説明が長くなってしまったので、続きは次回の記事にします。今回使用したボタンは少量のG/L Entriesの修正には有用ですが、実際の業務ではもう少し大量のデータに対して条件を付けて抽出する必要があります。次回は転記日と分析項目”Salesperson”を使って絞り込む方法を説明します。