既定の財務分析コード
この記事では、既定の財務分析コードについて開発者向けの説明を記載します。 ここでは、分析コードのがどのように生成されるか、その分析に使用される application programming interfaces (API)、および元帳分析コードの作成に使用する方法について説明します。 この記事には、ユーザーインターフェイス (UI)、SQLテーブルクエリ、およびそれらのクエリの出力例が含まれています。 また、API とその使用例についても説明します。
この記事では、デモ データの会社として USMF を使用します。
財務分析コードのコンセプトおよび業務プロセスに対する影響について詳細は 財務分析コード を参照してください。
既定の分析コードを入力する
250 以上のページによって、既定の財務分析コードを入力できます。 分析コードは、ファストタブに値および説明と共に一覧表示されています。 標準デモデータでは、30以上の分析コードを使用できます。 ただし、次の 財務分析コード ファストタブには、次の5つの分析コード、BusinessUnit、課、部門、ItemGroup、プロジェクト のみを表示しています。
分析コード リスト
分析コードは、最初に勘定構造の一覧に基づいてフィルター処理されており、これらは現在の会社またはページで指定されている会社の元帳に関連付けられています。 次に、それらの構造に関連付けられている分析コードの一覧と、それらの構造に関連付けられている有効となっている高度なルールの一覧が結合されたリストが表示されます。
元帳 ページ
元帳 ページ (一般会計 > 設定 > 元帳) にて、会社の勘定構造を管理できます。
分析コードの数が変動する勘定構造
勘定構造で使用する分析コードの数を決定するには 元帳 ページで グリッド上の 勘定構造の設定 を選択し、列の数を数えます。 以下の図は、3つの分析コードを使用しているの勘定構造と、5つの分析コードを使用する勘定構造を示しています。
3つの分析コードを使用する勘定構造
5つの分析コードを使用する勘定構造
上記の図に示した2つの勘定構造の間には、BusinessUnit、Department、CostCenter, ItemGroup、の4つの固有の分析コードがあります。 これら4つの分析コードは、既定の分析コードの一覧に表示されます。 さらに、高度なルールを介してアカウント構造に連係されている高度なルール構造からの分析コードが検証されます。 この例では、高度なルール構造から分析コードを検証した結果、5番目の分析コードがデフォルトの分析コードのリストに追加されています。
以下の図は、プロジェクト分析コードがデフォルト分析コードのリストに組み込むための高度なルールを示しています。
以下の図は、ルール構造を示しています。
この MainAccount 分析コードは、多くの場合は既定の分析コードの一覧には表示されないことに注意してください。 ただし、予算作成は例外となります。 この場合、既定の分析コードの一覧にはMainAccount分析コードが明示的に含まれています。
既定の分析コード一覧用API
既定のdimensionコントローラである DimensionDefaultingController は、会社に適切な分析コードを判断するために DimensionCache::getDimensionAttributeSetForLedger() APIを使用します。
取込と保存の管理
取込みフォームと分析コードデータのモデル
既定の分析コードを表示するすべてのページでは DimensionDefaultingController コントローラが使用されています。 このコントローラでは、分析コードが自動的に表示され、値を読み込んで保存するので、対話的な操作を行うことができます。 取込みパターンの詳細については、ホワイト ペーパー Implementing the Account and Financial Dimensions Framework for Microsoft Dynamics AX 2012 Applications を参照してください。
既定の分析コード値の保存
分析コードに関連付けられている値は、これらの分析コード値を参照する主テーブルとは別のテーブルに格納されます。 たとえば、LedgerJournalTableテーブルには、DimensionAttributeValueSetテーブル内のレコードへの外部キー参照を保持する dimensiondefault 列があります。 このレコードは、表示される一連の値を意味する親レコードです。
それぞれの値は、DimensionAttributeValueSetItem テーブルに独立した行として保存されますが、親レコードの外部キーは同じものとなります。
データは、これらのテーブルを介して直接照会できます。 また、以下の図に示すように DimensionAttributeValueSetItemView を使用してクエリを実行することもできます。
空の値
分析コードのフレームワークは、値が入力された分析コードについてのみ行を保存します。 空の行に対してはデータが保存されません。 したがって、データが保存された後、フレームワークは値を持たない分析コードについて、それがユーザーが削除したものなのか、そもそも値が入っていないものなのかを区別することができません。 空の値を保存するには、空白であることを意味する値を作成する必要があります。 例えば、empty、n/a、<cleared>、または *blank* などの名前を付けます。 ユーザーは、空白の値に対しては入力時にこの値を選択して、これは空白値入力の既定の動作とすることができます。
不変データ
ほとんどの分析コードと同様に、テーブルに挿入されたレコードは変更できません。 これらは最初に作成されますが、その後更新または削除されることがありません。 たとえば、ユーザーがプロジェクトIDを分析コードとして追加し、変更を保存したとします。
この場合でも、新しい行が追加された場合でも、SQLクエリは以前と同様の3つの行を返します。 新しい値が追加されると、分析コードフレームワークは新しい値セットレコードと、前の分析コードセットを変更するのではなく、新しい値セットにリンクされている4つの追加の値セットアイテムレコードを作成します。
パターンのコピー
このセクションでは、エンティティ間で既定の分析コードがどのようにコピーされるかについて説明します。
コピーとマージ
通常、既定の分析コードは、勘定科目分析コードを作成するために他の分析コードの組み合わせとコピーまたはマージされます。 分析コードフレームワークは、既定の動作の優先順位を設定しません。 各ページまたはプロセスは、ビジネスロジックの要件に基づいて、優先順位を決定します。
以下の例を、"仮想注文" ドキュメントに基づいて進めていきます。 このドキュメントは、品目としてのサービスを含む顧客販売注文であると考えることができます。 または、在庫品目を品目として含む仕入先の発注書であると考えることもできます。 以下の図に示すように、処理内のさまざまな時点で既定の分析コードを入力または上書きすることができます。
注文ドキュメントの場合は、ビジネスロジックに相当する既定の分析コードが複数用意されています。 この例で使用される発注書のように、ドキュメントヘッダーには既定の分析コードのセットが含まれている場合があります。 この例では、顧客または仕入先のオーダーには一連の既定の分析コードが存在します。 注文のビジネスロジックによっては、これらのさまざまな既定の分析コードの組み合わせによって優先順位が異なる場合があります。 既定の分析コードの中で優先順位が高いものは、他の既定の分析コードを置き換えることがあります。 また、既定の分析コードがマージされる場合もあります。
既定の分析コードをコピーする
以下の図は、ある販売店の主勘定に入力された既定の分析コードを示しています。
以下の図は、仕入先レコードの既定の分析コード参照に対するSQLクエリを示しています。
以下の図は、作成された既定の分析コードを示しています。
以下の図は、この仕入先に対して作成された新しい発注書を示しています。 既定の分析コードがドキュメントヘッダーにコピーされます。
以下の図は、SQLクエリとヘッダレコードへの既定の分析コード参照を示しています。
以下の図にあるように、仕入先を選択するとただちに、発注書ヘッダーに既に存在する分析コードが仕入先の分析コードによって置き換えられます。
したがって、既定の分析コードの外部キーをコピーする必要があります。 以下の図は、仕入先から購買発注へ既定の分析コードをコピーするために使用されるコードを示しています。
次の図は、ユーザーがプロジェクト分析コード値を入力した後のヘッダー分析コードを示しています。
以下のコードは、ヘッダー レコードの既定の分析コード参照に対する SQL クエリを示しています。
SELECT RecID, PURCHID, DEFAULTDIMENSION from PurchTable
WHERE PURCHID = '00000125' and DATAAREAID = 'usmf'
SELECT DA.NAME, DISPLAYVALUE, V.DIMENSIONATTRIBUTEVALUESET,
V.SETITEMRECID
FROM DIMENSIONATTRIBUTEVALUESETITEMVIEW V
JOIN DIMENSIONATTRIBUTE DA ON DA.RECID = V.DIMENSIONATTRIBUTE
WHERE V.DIMENSIONATTRIBUTEVALUESET = 52565466755
以下の図は、作成された既定の分析コードを示しています。
ユーザーが ライン ビューに切り替えて明細行を入力すると、以下の図に示すように、発注書ヘッダーから既定の分析コードがコピーされます。
以下の図は、外部キー参照を行にコピーするために使用されるコードを示しています。 この例では、明細行はまだ保存されていません。 そのため、既定の分析コードの外部キーは、メモリのテーブルバッファーのみに表示されます。
パターンのマージ
このセクションでは、エンティティ間で既定の分析コードがどのようにマージされるかを説明します。
既定の分析コードのマージ
次の図では、ユーザーが行の BusinessUnit 分析コードを手動で削除しました。 その結果、新しい既定の分析コード外部キーが作成され、発注書ヘッダーが更新されます。
この例ではヘッダーはまだ保存されていないため、更新された外部キーはメモリのテーブルバッファーにのみ表示されます。 ただし、以下の図に示すように、新しい既定の分析コードを照会して検索することができます。
次に、ユーザーが購買注文の明細行に入力する品目を考えてみます。 以下の図は、製品タブでの既定の財務分析コードを示しています。
以下のコードは、データベース内の既定の分析コードに対する SQL クエリを示しています。
SELECT ItemId, NAMEALIAS, DefaultDimension from InventTable where ItemId = '1000' AND DATAAREAID = 'USMF'
SELECT DA.NAME, DISPLAYVALUE, V.DIMENSIONATTRIBUTEVALUESET,
V.SETITEMRECID
FROM DIMENSIONATTRIBUTEVALUESETITEMVIEW V
JOIN DIMENSIONATTRIBUTE DA ON DA.RECID = V.DIMENSIONATTRIBUTE
WHERE V.DIMENSIONATTRIBUTEVALUESET = 68719490324
以下の図は、クエリの実行結果を示しています。
続いて、購買注文の明細行に品目を入力します。 以下の図は、購買注文の明細行で選択された品目と、その結果の既定の分析コードを示しています。 この場合、既定の分析コード値は発注書ロジックによってマージされています。
以下のコードおよび図は、SQL クエリと購買注文明細行の品目レコードからの既定の分析コードの結果を示しています。
SELECT PURCHID, LINENUMBER, ITEMID, DEFAULTDIMENSION from PURCHLINE where PURCHID = '00000100' AND DATAAREAID = 'USMF'
SELECT DA.NAME, DISPLAYVALUE, V.DIMENSIONATTRIBUTEVALUESET,
V.SETITEMRECID
FROM DIMENSIONATTRIBUTEVALUESETITEMVIEW V
JOIN DIMENSIONATTRIBUTE DA ON DA.RECID = V.DIMENSIONATTRIBUTE
WHERE V.DIMENSIONATTRIBUTEVALUESET = 68719490325
品目が購買注文の明細行に対して指定されている場合、発注書のロジックが3つの異なる参照元の既定の分析コードをマージます。 以下の情報を参照してください
注文ヘッダーの既定の分析コードが、注文明細行の既定の分析コードとマージされて、"結合結果1" の既定の分析コードが生成されます。
項目 注文明細行 注文ヘッダー マージの結果 1 説明 BusinessUnit この値は、両方のソースで空白です。 CostCenter この値は、両方のソースで空白です。 部 027 027 注文明細行の値は空白です。 結果として、この値は注文ヘッダーからコピーされます。 品目グループ この値は、両方のソースで空白です。 プロジェクト 000003 000003 000003 この値は、両方のソースで空白です。 外部キー **6190 *9574 *9574 マージされた後は、注文ヘッダーと同じレコードが使用されます。 品目の既定の分析コードが、注文明細行の "結合結果1" とマージされて、"結合結果2" の既定の分析コードが生成されます。 以下の表では、マージ処理の際の論理ステップを示しています。 ただし、これらの手順は、実行時に、dimensionフレームワークによって提供されるAPIを使用してマージされます。
項目 マージの結果 1 項目 マージの結果 2 説明 BusinessUnit この値は、両方のソースで空白です。 CostCenter 008 008 ヘッダー行の結合結果の値が空白です。 結果として、この値は品目からコピーされます。 部 027 023 027 ヘッダー行の結合結果の値がセットされます。 したがって、その品目はスキップされます。 品目グループ AudioRM AudioRM ヘッダー行の結合結果の値が空白です。 結果として、この値は品目からコピーされます。 プロジェクト 000003 000003 ヘッダー行の結合結果の値がセットされます。 外部キー *6190 **0324 **0325 マージ後の結果に対して新しいレコードIDが使用されます。
以下の図は、3つのソースからから既定の分析コードをマージするために使用されるコードを示しています。
勘定分析コードの作成
このセクションでは、新しい勘定分析コードを作成するために既定の分析コードをマージするか方法について説明します。
既定の分析コードは、仕訳帳と勘定配布で使用される勘定科目の組み合わせを作成するために後のステップで使用される値を提供します。 勘定科目の組み合わせは、構造と順序が適用される MainAccount および分析コード値の組み合わせにすぎません。 詳細については、第 5 部: 勘定分析コード を参照
既定の分析コードには、 MainAccount 以外の勘定科目の組み合わせに必要なすべての分析コードが用意されています。 既定の分析コードは既定の勘定と組み合わせることも、別の勘定分析コードを組み合わせて勘定分析コードを生成することもできます。
次の図は、購買注文明細行から勘定配布を実行する例を示しています。 注文明細行から 購買 > 財務配分金額 を選択し 勘定配布 ページを開きます。 このページでは、既定の勘定科目の組み合わせである 618900--027-008audiorm-が既に入力されています。
勘定配賦に入力された、プロジェクト、コストセンター、品目グループ、部署の値。 また、次の図に示すように、転記品目グループの既定の MainAccount の値は、購買注文の経費勘定の購買経費として品目に入力されています。 プロジェクトは、ここに該当する勘定構造の一部ではないため、表示されません。
以下の図は、クエリおよびその結果となる既定のアカウントのソースを示しています。
次の図は、品目グループの既定の勘定を含む購買注文明細行の既定の分析コードをマージするために必要なコードを示しています。
マージが完了すると、以下の図に示すクエリのように、新しい勘定科目の組み合わせが作成されます。 この動作は、既定の分析コードが相互にマージされる際の挙動と共通しています。
一般的なAPIのパターン
このセクションでは、最も一般的な既定のパターンに使用されるAPIについて説明します。
既定の分析コードAPI
Dimensiondefaultfacade と LedgerDimensionDefaultFacade クラスは、既定化を行うシナリオで必要なAPIを提供します。 LedgerDimensionFacade クラス" には、勘定分析コードで作業するためのメソッドが含まれています。 この方法は、パフォーマンスを優先し、高度に最適化されています。
既定の分析コード
serviceMergeDefaultDimensions()
ServiceMergeDefaultDimensions APIは、既定の分析コードに対して最も頻繁に使用されるAPIです。 2つから4つの既定の分析コードから新たな既定の分析コードを作成する必要がある場合は、これを呼び出す必要があります。 4つ以上の既定の分析コードをマージする必要がある場合は、このAPIを複数回呼び出すことができます。 この場合、前回の呼び出しの結果を、後続の呼び出しの初期パラメータとして使用する必要があります。 この方法では、値が有効かどうかにかかわらず、すべての値が確実にマージされます。
例 : DimensionDefaultFacade::ServiceMergeDefaultDimensions()
public static DimensionDefault serviceMergeDefaultDimensions(
DimensionDefault _value1,
DimensionDefault _value2,
DimensionDefault _value3 = 0,
DimensionDefault _value4 = 0)
serviceReplaceAttributeValue()
ServiceReplaceAttributeValue () APIは、1つの分析コード値をある既定のセットから別の既定セットへとコピーする必要がある場合に役立ちます。 指定された値は、ソースセットに既に存在する任意の値に置き換えられます。
例 : DimensionDefaultFacade::serviceReplaceAttributeValue()
public static DimensionDefault serviceReplaceAttributeValue(
DimensionDefault _target,
DimensionDefault _source,
RecId _dimensionAttributeId)
serviceMergeValidDefaultDimensions()
ServiceMergeValidDefaultDimensions () APIは、現在の元帳に対して有効な値のみをマージしていく場合に便利です。 ServiceMergeDefaultDimensions と同じように動作しますが、有効な値の検証がされます。
例 : DimensionDefaultFacade::ServiceMergeValidDefaultDimensions()
public static DimensionDefault serviceMergeValidDefaultDimensions(
DimensionDefault _defaultDimension1,
DimensionDefault _defaultDimension2,
DimensionDefault _defaultDimension3 = 0,
DimensionDefault _defaultDimension4 = 0)
勘定分析コード
serviceCreateLedgerDimension()
ServiceMergeDefaultDimensions APIは、勘定分析コードに対して最も頻繁に使用されるAPIです。 このメソッドは、既定の勘定または既存の勘定科目の組み合わせと0 から3つの既定の分析コードから、新しい勘定科目の組み合わせを作成する必要がある場合に呼び出す必要があります。 3つ以上の既定の分析コードをマージする必要がある場合は、このAPIを複数回呼び出すことができます。 この場合、さまざまなソースが、後続の呼び出しの初期パラメーターとして前回の呼び出し結果を受け取ります。 MainAccount 分析コードは、指定された勘定分析コードからのみ取得されます。
例 : LedgerDimensionFacade.serviceCreateLedgerDimension()
public static LedgerDimensionAccount serviceCreateLedgerDimension(
RecId _ledgerDimensionId,
DimensionDefault _dimensionDefault1 = 0,
DimensionDefault _dimensionDefault2 = 0,
DimensionDefault _dimensionDefault3 = 0)
{
serviceCreateLedgerDimensionForType()
ServiceCreateLedgerDimensionForType () APIは、serviceCreateLedgerDimension () API と共通した特徴があります。 ただし、勘定科目の組み合わせを作成する代わりに、予算勘定や予算計画勘定など、他の勘定分析コードタイプを作成することもできます。 LedgerDimensionType パラメーター は、作成された勘定科目のタイプを指定する際に使用します。
例 : LedgerDimensionFacade.serviceCreateLedgerDimensionForType()
public static LedgerDimensionBase serviceCreateLedgerDimensionForType(
LedgerDimensionType _ledgerDimensionType,
LedgerDimensionBase _ledgerDimensionId,
DimensionDefault _dimensionDefault1 = 0,
DimensionDefault _dimensionDefault2 = 0,
DimensionDefault _dimensionDefault3 = 0)
serviceCreateLedgerDimForDefaultDim()
ServiceCreateLedgerDimForDefaultDim () APIは serviceCreateLedgerDimension () および serviceCreateLedgerDimensionForType () APIと共通した特徴を持っています。しかし、既定の分析コードの値は、新しい勘定分析コードに直接コピーされ、元帳分析コードの値は後でマージされます。 対照的に、前述の2つのAPIについては、勘定分析コード値がコピーされ、既定の分析コード値が結合されています。
例 : LedgerDimensionFacade::サービスCreateLedgerDimForDefaultDim()
public static LedgerDimensionBase serviceCreateLedgerDimForDefaultDim(
DimensionDefault _defaultDimension,
LedgerDimensionBase _ledgerDimensionId)
serviceLedgerDimensionFromLedgerDims()
Serviceledgerdimensionfromledgerdims () API は前述のAPIと共通する特徴を持っていますがていますが、新しい勘定分析コードを作成するためには、ソースとして元帳分析コードのみを使用します。 主勘定には、勘定分析コードからの固定値のみが適用されます。
例LedgerDimensionFacade::ServiceLedgerDimensionFromLedgerDims()
public static LedgerDimensionAccount serviceLedgerDimensionFromLedgerDims(
LedgerDimensionBase _ledgerDimensionId1,
LedgerDimensionBase _ledgerDimensionId2 = 0,
LedgerDimensionBase _ledgerDimensionId3 = 0,
LedgerDimensionBase _ledgerDimensionId4 = 0,
LedgerDimensionBase _ledgerDimensionId5 = 0)
serviceMergeLedgerDimensions()
ServiceMergeLedgerDimensions () APIは、 serviceledgerdimensionfromledgerdims() APIと共通とした特徴を持っていますが、2つの会計分析コードだけを組み合わせるように最適化されています。
例 : LedgerDimensionFacade::ServiceMergeLedgerDimensions()
public static LedgerDimensionBase serviceMergeLedgerDimensions(
LedgerDimensionBase _ledgerDimension1,
LedgerDimensionBase _ledgerDimension2,
LedgerDimensionType _ledgerDimensionType = LedgerDimensionType::Account)
serviceCreateLedgerDimFromLedgerDim()
ServiceCreateLedgerDimFromLedgerDim () APIは、過去に転記されたドキュメントから新しい未転記のドキュメントに元帳分析コードをコピーする場合と、現在の勘定構造の設定を確実に使用すように設定したい場合に便利です。 これにより、転記時に新しい元帳分析コードを検証する際の検証エラーを防ぐことができます。
例 : LedgerDimensionFacade::サービスCreateLedgerDimFromLedgerDim()
public static LedgerDimensionAccount serviceCreateLedgerDimFromLedgerDim(LedgerDimensionAccount _ledgerDimension)