勘定科目残高再集計とは

以前別の製品を導入した時に、「勘定科目残高再集計」というメニューがあり、他の若手メンバーは「トランザクションと残高がずれるなんて有り得ない」とその有用性に疑問を呈していました。

昔はマシンのリソースに限界があり、リカバリ手段として用意していたもので、BaanやLNにも同じ機能が用意されています。

通常の運用としては、経理仕訳伝票を起票し、責任者の承認を経て元帳に転記します。その時のデータの流れとしては、仮伝票データが元帳データに転記され、同時に勘定科目残高データに加算され、親勘定科目残高データに積み上がります。

昨今のハードウエア性能は格段に向上し、処理リソース不足に悩まされる場面は減りました。しかし「夜間ジョブスケジュールがずれ込み重い処理とかちあってしまった」「伝票承認データ件数が多すぎる」等により、伝票承認処理にリソース不足が生じる可能性はゼロではありません。

このとき、意図的に「勘定科目残高データ加算」処理を中断し、同時に「元帳データ転記」処理を守ります。

そして、リソースが充分かつ伝票入力時間外にリカバリ処理を流すというものです。このリカバリ処理は毎日流す必要はないと思いますが、保険的な意味合いで定期的に流す運用とします。

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

取引タイプとは

見慣れない単語ですが、このお話をします。貴社の運用において例えば、購買入庫伝票や売上計上伝票と決算修正伝票はごっちゃにしていないはずで、何かしらの区分が存在するはずです。例えば伝票の色であったり、何かしらのコードかもしれません。

取引タイプとは伝票の発生元を判別するための伝票区分と読替えることができます。

購買入庫時の債務伝票・棚卸資産増加伝票。

販売出荷時の売上原価伝票。売上高計上伝票・債権伝票。

製造完了時の製造原価においては、材料費部分、労務費部分、経費部分、原価差異、その他。

経理部においては、他部門から毎月届く経理仕訳取込、月例経費振込手入力、支払伝票、その他。

枚挙にいとまはありませんが、それらを「取引タイプ」という伝票区分で3ケタ英数コードにて分類することができます。先に説明した会計統合においても、細かく割付・判別できます。そして、この「取引タイプ」は業務業態そのものであり、日常運用において毎月のように増えるものではないため、細かすぎて破たんする心配も少ないです。

会計統合なり債権債務仕訳において、(求める水準の精度の)マスタ完成し本番運用したとしても、意図しない勘定科目残高が発生することがあります。膨大な元帳データを片っ端から当たる前に、この「取引タイプ」のルール付けがしっかりしていれば、比較的短時間に「このマスタがおかしい、マスタ修正しよう」「この取引が変だ、見直すべきか」といったトレース・分析・判断が可能です。

現在の業務運用において、「誤差の拾い出しが大変」「もっと細かくトレースできれば」云々といった不都合があれば、「伝票分類がどこまで細かければよいか」を認識、整理しておくだけで、ERP導入負荷は格段に軽くなります。

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

 

取引通貨とは

通貨マスタには3ケタ英数の通貨コードとともに、通貨レート発効決算日、通貨レートを保持できます。これは他社製品にも相当する機能があると思われます。

ですので、同じ通貨のUSDに対してもUS1、US2等、メインの通貨レート以外にも任意の通貨レートを保持できます。こうして、通貨レート予約にも対応できます。

また、債券、債務、振替伝票にも通貨情報を保持しております。その中身は「取引通貨、参照通貨、自国通貨」毎に「取引金額、(取引時)通貨レート」といったもので、参照通貨、自国通貨はあらかじめパラメタ設定します。

決算等で各取引の為替レート洗い替えを行うと、為替差額分の経理伝票を起票し、履歴・残高保持し、その後の入出金時には正しく消込を行います。IFRSではこの通貨別取引残高を要求されますが、十分対応できています。

自社の取引でどのような通貨が使用・運用されているか、為替レートはいつ、どのタイミングで更新しているかを認識、整理しておくだけで、ERP導入負荷は格段に軽くなります。

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

原価構成要素とは

製造原価明細の大項目として「物・労・経」と略されますが、それらを任意に細分化し、コードを付与したものを「原価構成要素」と呼びます。

製造モジュールの中で重要なマスタであることは言うまでもなく、別途解説した会計統合においても、製造原価を勘定科目変換する上で重要なキーになります。別の製造系ERP製品でも同じ考え方があります。ここでは会計側要件でそのお話をします。

まず「物」にあたる原材料および消耗品、貯蔵品、外注購買品、その他といったものですが、通常は会計側要件より製造側要件の方が細かく管理する場合が多いため、会計統合の要件としては比較的安心できる部分です。

次に「労」にあたる労務費部分ですが、会計側で発生した直接人件費・関連コストを全て表現しようとすると、恐ろしく煩雑になり、管理しきれなくなるため、適度な粗さが必要です。

最後に「経」にあたる「直接経費」「間接経費」です。

「直接経費」は機械減価償却費、工場光熱費、工場地代家賃、その他ですが、製造部門側でも重要な関心事であり、詳細な区分が要求されます。時間単価を算出・改訂する上でも貴重な参考データになります。会計統合の要件としては必要な粒度が確保しやすい部分です。

「間接経費」は間接部門人件費、間接部門経費等、製造部門が管理しきれないあらゆる要素が関連するため、その粒度は会計要件とならざるを得ません。製造現場においては機械時間単価として稼働時間で製造原価に付加させたり、倉庫付加費用といった方法で在庫評価額に付加させることもできます。

もちろん、これら時間単価、倉庫付加費用等をいくらにすべきかを算出するのは多大な労力を伴いますが、望む精度を確保できれば、そこから得られる恩恵も多大なものです。

これらの原価構成要素をキーに発生した標準単価、実際原価は「原材料⇒中間品⇒製品」へと積み上がり、製造原価明細上で詳細な分析が可能になります。

そして、この原価構成要素の粒度も正解はなく、その他原価関連マスタ検討作業も決して軽くはありません。(望む精度の)マスタ完成後にも原価管理に悩み、終わりはありませんが、その悩みは「格段に高次元の原価管理」であることは間違いありません。

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

 

幻の会計機能 原価管理とは

過去にあるパートナー様から「チケット余ったから、なんか教育してよ」と少々無茶な依頼がありました。そのパートナー様は私がBaanに携わる遥か昔からのヘビーユーザーであり「普通の機能では絶対満足しない」とばかりにニッチな機能で臨みました。結果は半ば呆れながらも知識欲求を少しは満たしたようです。

標記機能はその一つです。

「原価管理」といえば一般的には企業運営の中核であり、心臓部です。それに該当する部分は製造モジュール内であり、会計統合経由で認識できる各種原価差異であります。

では、会計モジュール内の「原価管理」機能は何かと言いますと、各種原価時間レートの算出機能です。

標準原価計算や実際原価算出には、「1時間あたりの機械稼働コスト・労務費・間接経費」が必要になります。それら時間レートを算出する為に

「分母:累積機械稼働時間、累積労働時間、作業場面積、その他」

「分子:勘定科目(補助科目)別残高、その他」

をマスタ設定し、実データを基に算出、各種新レートに本番反映できるものです。

これに対し、パートナー様やお客様の反応は。

「レート算出はExcelでよいのでは」

「設定が面倒くさい」

「設定ミスで誤ったレートが不意に上書きされたら困る」

という否定的な反応に凹むものの、好意的なものもあり

「ヒューマンエラーの介入がExcelより格段に少ない」

「設定ミスをしても再現性があり、原因分析の労力が少ない」

この機能を作成した人々の労力が少しは報われ、一縷の望みが見えたような気がします。でも、私の知る限りでは導入運用実績がないのが悲しいところです。

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

原価差異とは

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

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導入負荷は格段に軽くなります。例えば「その他品目」「その場に応じた属人的な分類」「未分類の品目」「裏品目(?)」といったものです。

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

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