会計統合マスタとは

ロジ側の取引を会計仕訳に変換する処理を会計統合と呼んでいます。その変換ルールをここでお話しします。

まず、ロジ側処理を「購買、販売、製造、倉庫、その他」機能で分類します。

次にそれらの機能を「購買/入庫、販売/出荷、等」と取引内容で分類します。

次に「借方/貸方」と分類します。

この3段階で分類した変換単位毎に変換ルールを登録します。

例:購買/入庫/借方

変換ルールは優先順位を持ち、「品目グループが〇〇かつ倉庫が〇〇なら勘定科目は〇〇」といったロジックを順番に登録していきます。

この変換ルールは細かい条件を優先し、徐々に粗い条件にしていきます。

そして、最後に「条件合致せず」という勘定科目を割り当てて認識するか、会計統合機能のエラー表示にて認識するかはご相談です。

この変換ルールは世代管理しており、過去の統合仕訳に意図しないものを発見した時に原因トレースができます。また、この変換ルールは膨大であり「一発で完成」することはなく、何回かのシミュレーション・改訂を繰り返し、本番稼働後もメンテナンスが必要ですので、「編集中・稼働中・履歴」といった状態を保持します。

会計仕訳変換全て機械的に判断できるように事前に整理するだけで、ERP導入負荷は格段に軽くなります。

(推敲していませんので、徐々に更新します)

原価差異とは

ここでは棚卸在庫品の在庫評価に標準原価の固定振替単価を採用した場合のお話をします。

BaanERP及びInforLNでは以下の原価差異を抽出できます。

購買単価差異

製造材料単価差異

製造材料数量差異

製造労務費単価差異

製造労務費時間差異

製造機械単価差異

製造機械時間差異

製造計算オフィス差異

棚卸数量差異(詳細原因へ振替要)

在庫調整数量差異(詳細原因へ振替要)

お客様に抵抗のある言葉として「責任会計」というものがあります。そのままでは「悪者捜し」のイメージがあるようですが、決してそのようなことはなく、良い部分もこれで見えて来ますし、売上総利益の向上の為には細かい分析が必要です。

上記では大体の発生原因がお分かりになると思いますが、「計算オフィス差異」だけが謎です。

主な原因として、実際の生産指示数量が標準生産指示数量を下回ると、アイドリング時間・材料部分のコストが標準単価に乗り切らずマイナス原価差異として計算オフィス差異が発生します。(他にも原因はあります)

これらの原価差異勘定・仕訳は会計統合を経て会計側が認識できます。それらは会計統合マスタ上で細かい分類設定が可能ですが、将来的なメンテナンス運用を考慮した粗さが必要です。

また、多少手間にはなりますが、会計機能側ではなく製造機能側にて詳細な原価差異を確認することができます。

(推敲していませんので、徐々に更新します)

マルチサイトとは

これはBaanERP及びInforLN用語ですが、「複数の事業拠点」と捉えてよいです。「春日部工場、越谷販売所、草加倉庫、西新井本社(会計)」といったもので、事業拠点を会社コード毎に管理する考え方は、他社パッケージ製品にも見受けられます。以下BaanERP及びInforLNにてお話しします。

「100、110、200・・」といった会社番号にて管理し、大まかに「ロジ会社」と「会計会社」に二分できます。細分必須要件は

「1ロジ会社、1生産計画」

「1会計会社、1財務諸表」といったものです。

大抵の導入では「Nロジ会社、1会計会社」のケースが多く、複数のロジ拠点の取引を会計統合によって1会計会社に集約するイメージです。

1製造会社では1件(明細は複数あります)の製造計画しか回せません、では複数の工場の場合はどうするかといいますと、製造会社間で受発注(購買・販売)を行い、受注側の工場にて生産計画を回しなおします。

購買拠点や販売拠点、倉庫はどのように会社コード管理するかと言いますと、「自由です」。但し、会社コードをまたがった物品移動は販売購買データが発生し、煩雑になりますので、導入ケースによって判断します。

例えば、越谷販売所が販売受注をし、草加倉庫から製品出荷した場合に「社内仕切価格で売買」するかどうかで事情が変わります。売買する場合は「三者間販売」と呼び、会社コードを分ける方が取引が明確になります。

ERP導入前にこの「社内取引」に該当する部分の「曖昧な運用を解消または認識」しておくだけでもERP導入負荷は格段に軽くなります。

(推敲していませんので、徐々に更新します)

品目グループとは

これはBaanERP及びInforLN用語ですが、「棚卸資産の勘定科目上の分類およびそれを細分化したもの」と捉えてよいです。「製品、商品、中間品、原材料、貯蔵品、その他」といったもので、他社ERP製品にも名称は違えど似た考え方があります。

会計統合では製造、購買、販売、倉庫といったロジ側の各種取引を経理仕訳に変換しますが、その変換キーのうち、一番重要なものになります。

月末に勘定残高試算表と在庫有高を比較チェックする場合に、その作業を容易にするためには、「勘定科目⇔品目グループ」の関係はできる限りシンプルにするべきです。

ERP導入作業では、この品目グループを経理側要件・ロジ側要件で入念な擦り合わせを行い、時間を要する部分であります。ERP導入前にこの「品目グループ」に該当する部分の「曖昧な運用を解消または認識」しておくだけでもERP導入負荷は格段に軽くなります。例えば「その他品目」「その場に応じた属人的な分類」「未分類の品目」「裏品目(?)」といったものです。

また、「品目グループ」は本番稼働後も必要に応じてマスタ追加し、併せて「会計統合」関連及び影響範囲マスタもメンテナンスしていきますので、「細かすぎて管理不可能」「多すぎて云々」な事態は避けるべきです。

(推敲していませんので、徐々に更新します)

会計統合とは

「会計統合」何か凄い響きですが、要するに「自動仕訳」の事で、「financial integration」の直訳です。

「購買して原材料が入庫した」

「倉庫間を部品が移動した」

「製品を製造完了した」云々

といったロジ側のアクションを会計仕訳に変換する仕組みです。

この変換キーは何か、貴社の業務で見回してみましょう。

「製品、部品、原材料、消耗品といったモノの属性」

「通常販売、販売返品、サンプル出荷といった取引形態」

「マシンAなら、マシンBならといった製造機械の分類」云々

これらを総合的に判断し、貴社では会計仕訳に変換しています。

この変換作業に例外はありませんか?

この変換作業に属人的な判断はありませんか?

会計仕訳変換全て機械的に判断できるように事前に整理するだけで、ERP導入負荷は格段に軽くなります。

(推敲していませんので、徐々に更新します)