Share via

組織階層の計画

  • [アーティクル]

組織と組織階層を設定する前に、組織をシミュレーションする方法を確認してください。 組織モデルは、その実装と業務プロセスに重要な影響を与えます。

組織階層は、業務を構成する組織間の関係を表します。 したがって、組織をシミュレーションするときにもっとも重要な考慮事項は業務の構造です。 ただし、財務と会計、人事管理、業務、購買、および販売とマーケティングなどの機能領域のエグゼクティブおよび上級管理者からのフィードバックに基づいて、組織構造を定義することをお勧めします。

階層を計画するとき、組織階層と財務分析コードの間の関係を考慮することも重要です。 複数の組織階層を設定して、業務の異なるビューを表すことができます。 財務分析コードを使用して、これらのビューに基づいてレポートを作成できます。 パートナーを使用して、組織と法定の両方のレポートのニーズに対応する階層を作成します。

メモ

財務分析コードを使用して法人を作成せずに法人を表すことができますが、財務分析コードは法人の業務またはビジネス ニーズに対応するように設計されていません。 単位間会計機能は、各トランザクションによって作成された勘定項目のみ対処するように設計されています。

重要

組織をシミュレーションする方法を決定する際に、この記事の情報のみに基づく必要はありません。 このドキュメントはガイドです。 パートナーを追加のガイダンスとして使用して作業することができます。 パートナーは、さまざまな業界および全顧客層における経験を積んでいます。

業務を表す 1 つ以上の法人が必要です。 法人は、法的契約を締結することが可能であり、業績を報告する財務諸表の作成が要求されます。

法人は、トランザクション業務または連結に対して使用できます。 このことは、財務と運用での法人は、ビジネスの実際のエンティティを必ずしも表さないことを意味します。 たとえば、トランザクションに参加する会社は、関連法人を所有できます。 このシナリオでは、トランザクションのために法人が必要であり、関連法人の業績および残高を連結するために仮想の法人が必要です。

支社などの企業の内部組織を、追加の法人として、または主法人の作業単位として表すことができます。 作業単位は法的に定義された組織である必要はありません。 作業単位は、企業の経済資源と業務プロセスの管理に使用されます。 たとえば、部門、コスト センターは作業単位です。

いくつかの機能は、組織が法人か作業単位であるかに基づいて異なる働きをします。 決定を下す前に、次に示す機能を注意深く検討してください。

マスター データ

顧客、支払条件、税務当局、およびサイト固有の在庫注文などのマスター データは、法人ごとに設定する必要があります。 ユーザー、製品、およびほとんどの人事管理データなどのマスター データは、すべての法人間で共有されます。

組織を作業単位としてシミュレーションする場合

マスター データは、作業単位間で共有されます。

モジュールのパラメーター

売掛金勘定パラメーター、買掛金勘定パラメーター、現金および銀行管理パラメーターなどのモジュールのパラメータは、法人ごとに設定する必要があります。 法人のモジュールの設定は個別なので、各関連会社はローカルの法的要件とビジネス慣行に準拠することができます。 たとえば、専門サービスの法人と製造の法人は、同じ親会社に報告するけれども、モジュールのパラメーターは異なることがあります。

組織を作業単位としてシミュレーションする場合

モジュールのパラメーターは、作業単位間で共有されます。

データ セキュリティ

ほとんどのデータは法人 ID によって自動的に保護されます。 会社 ID は、法人に関連付けられるデータの固有 ID です。 会社は、1 つの法人のみに関連付けられ、法人は 1 つの会社のみに関連付けることができます。 ユーザーは、アクセスが許可されている会社のデータにのみアクセスできます。 会社 ID でデータを保護するためにカスタマイズする必要はありません。

組織を作業単位としてシミュレーションする場合

データは、カスタマイズしたデータ セキュリティ ポリシーを作成することによって、作業単位ごとに保護できます。 データ セキュリティ ポリシーを使用して、データへのアクセスを制限します。 たとえば、あるユーザーは特定の作業単位でのみ発注書を作成することが許されていると仮定します。 ユーザーが他の作業単位から発注書のデータへアクセスすることを防止するために、データ セキュリティ ポリシーを作成できます。 トランザクションの量とセキュリティ ポリシーの数が、パフォーマンスに影響を与える可能性があります。 セキュリティ ポリシーを作成する場合は、パフォーマンスを忘れないでください。

元帳

各法人には、勘定科目表、会計通貨、レポート通貨、および会計カレンダーを提供する元帳が必要です。 貸借対照表は、法人に対してのみ作成できます。 主勘定、分析コード、勘定構造、勘定科目表、および会計基準は、複数の法人で使用できます。

組織を作業単位としてシミュレーションする場合

作業単位は独自の元帳情報を所有することはできません。 内部組織が固有の元帳を必要としない場合は、それらの内部組織を作業単位としてシミュレーションできます。 元帳の情報は、階層の親法人に対して設定されます。 損益計算書は、法人内の作業単位または親法人に対して作成できます。

会計カレンダー

各法人は独自の会計カレンダーを所有します。 内部組織が異なる会計年度と会計カレンダーを使用する場合、それらの組織を法人としてシミュレーションする必要があります。

組織を作業単位としてシミュレーションする場合

作業単位は会計カレンダーを共有する必要があります。 内部組織が同じ会計年度と会計カレンダーを使用できる場合、それらの組織を作業単位としてシミュレーションできます。

連結

財務諸表を作成するには、支社の財務結果を 1 つの連結会社にまとめる必要があります。

組織を作業単位としてシミュレーションする場合

データが既に作業単位間で共有されているので、連結は必要ではありません。

集中支払

すべての子法人の請求書に対して単一の親法人が請求先となって支払うことができるように、集中支払を設定する必要があります。

組織を作業単位としてシミュレーションする場合

すべての請求書が一つの法人に記録されるため、集中支払は必要ではありません。

会社間トランザクション

会社間販売注文書、発注書、支払、または入庫は相互に適用できます。 仕訳伝票を使用する必要はありません。 補助元帳のレベル (売掛金勘定、買掛金勘定) で会社間トランザクションを表示できます。 次の例は、会社間トランザクションの処理の方法を説明します。

例 1: 本社は、支社にサービスを提供し、支社にそのサービスのコストを請求する必要があります

支社を法人としてシミュレーションする場合、次のオプションがあります。

  • 本社は、その経費を相互請求するための仕訳入力を作成します。 このトランザクションを期限切れにすることはできません。
  • オプション 2: 本社は、支社にサービスの発注書を送付します。 販売注文が、会社間の補助元帳トランザクションで、法人内で支社に対して自動的に作成されます。
例 2: 本社は、支社に提供されるサービスを調達して支払します

支社を法人としてシミュレーションする場合、次のオプションがあります。

  • オプション 2: 請求書と支払は本社の法的な要求事項に従います。 本社は、その経費を相互請求するための仕訳入力を作成できます。 このトランザクションを期限切れにすることはできません。
  • オプション 2: 請求書と支払は本社の法的な要求事項に従います。 本社は、会社間補助元帳トランザクションを作成できます。

組織を作業単位としてシミュレーションする場合

作業単位間の法人間トランザクションは、仕訳伝票を通してのみサポートされます。 作業単位は、同じ法人の別の作業単位との間で、発注書、販売注文、または請求書を発行または受領することはできません。 補助元帳のレベル (売掛金勘定、買掛金勘定) で会社間トランザクションを表示できません。 次の例は、会社間トランザクションの処理の方法を説明します。

例 1: 本社は、支社にサービスを提供し、支社にそのサービスのコストを請求する必要があります

支社を作業単位としてシミュレーションする場合、本社は経費トランザクションを入力し、それを支社に対してプログラムします。

例 2: 本社は、支社に提供されるサービスを調達して支払します

支社を作業単位としてシミュレーションする場合、請求書と支払は本社の法的な要求事項に従います。 請求書を支社に対してプログラムできます。 損益計算書では、差引勘定する財務分析コードを使用して、支社の原価を報告します。

地方税の条件

法人は、法人が登録された国/地域の税務当局の税法に支配されます。 たとえば、デンマークに登録される法人はデンマークの税法や規制に支配されます。 法人は 1 つの国 / 地域にのみ所属できます。 法人の基本住所として選択した国/地域によって、その法人が使用できる国/地域固有の機能が制御されます。 たとえば、法人の基本住所がデンマークにある場合、デンマークの税法や規制に関連する機能が使用できるようになります。 したがって、組織が異なる国/地域に存在し、異なる地方税オプションを必要とする場合は、その組織を別の法人として設定する必要があります。

組織を作業単位としてシミュレーションする場合

作業単位は親法人の国のコンテキストを使用します。 同じ法人の作業単位は、異なる国/地域固有の条件を使用することはできません。 組織が同じ国/地域にあり、同じ税オプションを使用する場合、その組織を作業単位として設定できます。

国/地域の法定レポート

サポートされる国 / 地域については、ほとんどの法定レポートを作成できます。

メモ

一般会計の転記階層によって、子会社とは異なる会計基準を使用する親会社に対して調整エントリを作成できます。 たとえば、英国の一般会計慣行 (UK GAAP) を使用する法人の場合、転記階層に調整エントリを作成できます。 これらのエントリは、米国の一般会計原則 (GAAP) を使用する親法人に統合できます。 調整エントリは、英国の GAAP レポートには影響しません。

組織を作業単位としてシミュレーションする場合

法定レポートは、別のアプリケーションを使用して作成する必要があります。 本社の要件とは異なる各作業単位の要件をサポートするように、データを財務と運用アプリで確実に取得する必要があります。

通貨

組織でさまざまな機能通貨を使用する必要がある場合、組織を法人としてシミュレーションする必要があります。 機能通貨は法人ごとに設定します。 ただし、複数の通貨でトランザクションを入力できます。

組織を作業単位としてシミュレーションする場合

組織で単一の機能通貨を使用できる場合、組織を作業単位としてシミュレーションできます。 作業単位は機能通貨を共有する必要があります。 ただし、トランザクションの入力およびレポートの作成を、複数の通貨で行うことができます。

年度末締処理

法令や会計の慣行が組織が配置されている国/地域間で異なる場合、組織ごとに異なる期末の手順が必要な場合があります。 このことは、組織を法人としてシミュレーションすることが必要なことを意味します。 各法人が独自の期末の手順を使用します。

組織を作業単位としてシミュレーションする場合

法令や会計の慣行が組織が配置されている国/地域間で同一の場合、単一の一連の期末の手順を使用できます。 このことは、組織を作業単位としてシミュレーションできることを意味します。 すべての作業単位が同一の年度末締処理の手順を使用する必要があります。

番号順序

一部の参照の番号順序は法人ごとに設定できます。 一部の番号順序は共有できます。

組織を作業単位としてシミュレーションする場合

一部の参照の番号順序は作業単位ごとに設定できます。 一部の番号順序は共有できます。

製品

製品定義は共有され、トランザクションに含める前に、個々の法人にリリースする必要があります。 各法人は、トランザクションのドキュメントに含めることができる、リリースされた製品の独自のセットを所有します。 内部組織でさまざまな製品セットを使用する必要がある場合、組織を法人としてシミュレーションする必要があります。

メモ

製品定義は共有されますが、製品がリリースされた各法人で、各在庫サイトでその品目に対して異なる販売、購買、在庫パラメーターを指定できます。

組織を作業単位としてシミュレーションする場合

すべての作業単位は、同じ製品セットを共有します。 内部組織が同じ製品セットを共有できる場合、その組織を作業単位としてシミュレーションできます。

照会およびレポート

複数の法人でトランザクションを入力し、照会を実行するには、会社を手動で変更する必要があります。 データ セキュリティ区分のゆえに、連結照会およびレポートはリソースを消費する操作となり、時間がかかる可能性があります。

組織を作業単位としてシミュレーションする場合

複数の作業単位のデータにアクセスするために、法人を変更する必要はありません。 連結照会およびレポートと地域ごとの個別の照会はより速く簡単です。

組織と階層のモデリングのためのベスト プラクティス

組織階層を実装するとき、次のベスト プラクティスを考慮してください。

  • 法人と業務単位間の交差をモデル化する部門を作成します。 その結果、部門から法人へデータを法定レポートのために、また部門から業務単位へデータを社内レポートのためにロール アップすることができます。 部門が利益センターとなります。 部門を使用する場合、法人と事業単位を、勘定構造内の分析コードとして使用する必要はありません。 部門だけを分析コードとして使用できます。 ただし、コスト センターが原価集計部門として使用されるだけであり、部門が収益計上枠として使用される場合は、コスト センターと部門の両方を勘定構造の分析コードとして使用する必要があります。
  • 損益を報告するための複雑な要件が存在する場合は、作業単位の複数の階層をモデル化します。
  • 単一の法人では、同じ階層のために複数の階層をモデル化しないでください。
  • 目的ごとに階層を作成しないでください。 通常、複数の目的に 1 つの階層を使用できます。 たとえば、作業単位の 1 つの階層を、すべてのポリシー関連の目的に割り当てることができます。
  • 均衡階層を作成します。 階層では、ルート ノードから同じ距離にあるすべてのノードは、1 つのレベルとして定義されます。 均衡階層では、1 つのタイプの作業単位のみが各レベルで存在することが可能であり、ルート ノードから各レベルへの距離は一貫しています。 部門と法人または業務単位の間に中間レベルがある場合は、プレースホルダ組織は均衡階層を作成することが求められる場合があります。
  • 法人の構造が運営構造でもある場合は、別の作業単位の階層をモデル化しないでください。 法人と作業単位が混合した階層は両方の目的を果たす場合があります。
  • 主要な建て直しシナリオをモデル化する前に、階層の有効日数を使用して、影響分析および検証テストを実行します。
  • 運用環境で新しいバージョンを発行する前に、ドラフト モードを使用して階層を変更します。
  • 運用環境で階層から組織を追加または削除する権限を持つ人員の数を制限します。 番号が小さくなると、費用のかかる間違いが発生し、修正が必要となる可能性が少なくなります。