中央請求とは

Baanの初期製品では、色々なモジュールで債権データを生成できました。しかし、そのままでは煩雑なため、「債権発生元を統合した」という意味で「中央請求」という名称の機能が造られ、今に至ります。

先の説明で、「ロジ取引は会計統合をもって経理伝票に反映」と伝えましたが、それは舌足らずです。債権債務はその後のタスクの存在、それに伴う緊急性により、早急に会計部門に伝える必要があります。そのため、債権債務は会計統合とは別の仕組みを持ちます。このうち債権部分の「中央請求」のお話をします。

販売出荷を行うと、裏側でその情報が記録されますが、ここで会計統合に記録されるのは倉庫要件のBS資産減少情報のみです。その他の情報は中央請求処理で生成します。具体的には「売上原価、売上高、債権」です。それらを会計統合および会計債権管理モジュールに連携します。

もちろん、債権・入金業務にはイレギュラーは付き物で、それを吸収する仕組みも用意しています。会計側に渡った債権データは履歴構造を持ち、債権100万のうち、80万一部入金や、債務の10万と相殺したり、多彩なケースをカバーします。

「中央請求」処理は会計統合とは独立しているので、単独軽量にバッチ処理できます。お客様の要件により、昼間に流す運用も見受けられます。また、顧客を分類して小分けに流す運用も可能です。

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

自己請求とは

購買請求とは業者様から請求書が届いて初めて債務と認識すべきです。しかし、その運用を実現しようとすると、「あの納品はまだ検品が済んでない」「不良品があったんだが」色々面倒なやりとりが伴います。そのやりとりの時間経過により、契約上の支払日にインパクトを与えかねません。全体請求金額の数%に満たないやりとりのために多大な金額の資金繰りの心配はしたくありません。

ならば、「検収済数量・金額は保証します、数%の祖語は後日調整しましょう」というやりとりも意味を持ちましょう。

先の説明で、「ロジ取引は会計統合をもって経理伝票に反映」と伝えましたが、それは舌足らずです。債権債務はその後のタスクの存在、それに伴う緊急性により、早急に会計部門に伝える必要があります。そのため、債権債務は会計統合とは別の仕組みを持ちます。このうち債務部分の「自己請求」のお話をします。

「自己請求」は「Self  Billing Invoice」の直訳であり、同じ考え方は他製品にもあります。自社の購買入庫検収済を債務認識し、支払機能に連携するものです。

もちろん、債務・支払業務にはイレギュラーは付き物で、それを吸収する仕組みも用意しています。会計側に渡った債務データは履歴構造を持ち、債務100万のうち、80万一部支払や、債権の10万と相殺したり、多彩なケースをカバーします。

「自己請求」処理は会計統合とは独立しているので、単独軽量にバッチ処理できます。お客様の要件により、昼間に流す運用も見受けられます。また、業者様を分類して小分けに流す運用も可能です。

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

会計統合処理とは

会計統合マスタが形になりましたら、ロジ取引を動かして、会計仕訳に変換します。ロジ取引データを会計統合データに渡すのですが、特に追加操作は必要ありません、ロジ取引の裏側で自動的に蓄積されます。

以下の流れになります。

ロジ取引発生(会計統合データ蓄積)

会計統合マッピング処理(仮仮経理伝票起票)

会計統合処理(仮経理伝票起票)

元帳転記(経理伝票承認)

まず「会計統合マッピング処理」ですが、ここでは統合取引マスタの変換ルールに従って勘定科目・各種補助科目・部門等を割り付けます。ここで変換エラーや意図しない仕訳を発見できれば、変換ルールを改訂し何回もリランできます。

次に「会計統合処理」ですが、ここでは「仮経理伝票」言い換えれば「経理部で日々手入力している未承認の経理伝票」と同様のモノを起票します。ここで変換エラーや意図しない仕訳を発見できれば、変換ルールを改訂し何回もリランできますが、赤黒の仮経理伝票が発生します。

最終的に「元帳転記」しますが、これは「会計統合」に限った機能ではなく、経理伝票共通の承認手続きです。

これらをふまえて「会計統合マッピング処理」の段階で変換エラーや意図しない仕訳を発見できれば手戻りも少なく理想的です。そのためには「会計統合処理」タイミングを遅らせる必要があります。あるお客様は1日の猶予を設けてエラー潰し・会計統合マスタ改訂をしていました。

この「会計統合処理」は比較的重い処理であり、他の夜間バッチ処理との処理スケジュールを考慮する場合があります。全件処理をする場合が多いですが、データ範囲を指定して細切れ処理もできます。

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

会計統合マスタとは

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

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

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

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

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

例:購買/入庫/借方

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

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

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

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

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

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

会計統合とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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