基本構造の観点から驚くこと
◆General Ledger (総勘定元帳)がない
Tallyでは、日本のようにGL(総勘定元帳)と勘定科目によって最終的な記帳がなされるのではなく、Voucher(帳票)にてなされた仕訳を勘定科目に近い用途のLedger(個別台帳)に記録します。
つまり、GLは個別Ledgerの集合として表現されるものと考えることができます。
またChart of Account(勘定科目一覧)はLedgerとそれをまとめるGroupのツリー構造として定義されます。
◆顧客マスタ、ベンダマスタがない
顧客およびベンダはそれぞれ勘定科目一覧におけるSundry Debtors(債務者)およびSundry Creditors(債権者)グループ配下のLedgerとして定義し、特に顧客マスタやベンダマスタなどは用意されていません。
日本の勘定科目一覧に例えるなら、中科目である売掛金や買掛金の下に、小科目として取引先の会社名が入ってくるようなイメージです。
これについて筆者は債権者や債務者を記録した伝統的な簿記を引き継いでいるのだなと理解しています。
◆勘定科目コードがない
インドにおいては一般的に勘定科目へのコード付けは行われていません。
とはいえ、本社としては連結関係を明確にする意味で勘定科目コードを付けたいと考えられることもあり、その場合はマスタ内の別のフィールドをコードに流用することをお勧めしています。
<イメージ:勘定科目構成>
よくある問題
Tallyを運用していくうえでの問題として起こりがちなのが、勘定科目構成がワケワカラン状態になってしまうことです。
上で述べた通り、顧客やベンダが台帳=勘定科目になっていることもあり、日常的に勘定科目を追加していきます。
さらには実務慣行として科目に個人名を入れてまで管理している状況も見受けられます。
インドの会計担当がTally内で業務が全て完結するよう、自分好みに使うのが当たり前の状況といえます。
したがい勘定科目の変更を制限することが不可能なため、記帳の過程で構成が変化していってしまい、日本から把握が困難になりがちです。
基本構造と運用上の取り決めによって落としどころを見つけるほかないのが実情ですが、だからこそ最初が肝心とも言えます。
ここまでは主に経理の観点からTallyの特徴を述べてきましたが、次は苦手な点を挙げてみます。
製造業での利用
結論から言えば、Tallyは工場での運用には弱いです。
もちろんTallyには標準で在庫管理機能が含まれているため、原材料から完成品への在庫変換という意味での生産実績は入力できますが、工程設計、所要量計算・生産計画などの計画機能がないといった意図的な線引きをしているため、製造業で本格的に使うには不向きです。
当面はシステム外でExcelを使ってこれらを処理するにしても、長期的な運用には再考が必要となります。
したがって、業務量の増大してくる3~5年くらいで、SAPやMSなどのグローバルERPに移行するご相談を受けることがあります。
ただし、上記は工場を持つ製造業のお話ですので、販売会社であればTallyで十分なケースがほとんどと思います。
レポートの体裁
管理者サイドから頂戴する問合せで多いのが、レポートが欲しい体裁で出てこない、ことです。
Tallyにも標準で売上レポートがあり、これをExcel形式で出力することもできるのですが、独自の体裁になっているので、単純にフィルタをかけて分析することができません。
おそらくTally内で全てを完結させ、外部へのファイルエクスポートはおまけという位置づけによるものでしょう。
フィルタ分析が可能なフォーマットでExcel出力するにはプログラミングを伴うTallyのカスタマイズが必要で、並べ替えや表示項目の追加など弊社でも対応しています。
このように不便なところはありつつ、どこまで出来るのか理解したうえで、最低限必要なカスタマイズをしながら使う、ということになりますが、これは他のERPでも同様ではないでしょうか。
次回はTallyをうまく使う工夫について述べてまいります。