会計学と会計。 コンピューターアカウンティングのルールとコンプライアンス違反の結果

私は長い間-ほぼ20年間会計の方法論に携わってきました。 それは、そのばかげた目障りな会計手法の誤りを克服する試みから始まり、セクションの1つとしてコンピューター会計の理論を含む、会計学と呼ばれる学問分野の創設で終わりました。



会計学のトレーニングコースの一環として、コンピューターアカウンティングのいくつかのルールを提案できるようにしてください。 Habréには、簿記を自動化する多くの専門家がいます。-会計方法論の「奇跡」が彼らにとって興味深いと思われることを願っています。 人々は、どれだけ時代遅れの方法論を自動化しているかを認識すべきですか？



規則A. 同種のエンティティはオブジェクトとして登録されます。



自然現象または抽象的な概念など、あらゆるものを考慮に入れることができますが、単一の情報システム内の同種の会計オブジェクトの形で、異種のエンティティを一緒に考慮することは完全に不可能です。



なんで？ はい、会計は実世界のモデルであるため、物事、現象、抽象的な概念は、比較することは誰にも起こらない異なる意味レベルの概念です。 牛は乳量と直接関係していますが、乳量と乳量を比較することは可能ですか？ 牛と乳の生産量は1つの情報システムに反映される可能性がありますが、さまざまな方法で反映されます。これには、とりわけ会計方法論があります。



現在の会計方法論は、この規則にどの程度準拠していますか？ 見てみましょう。



会計の最初のタスクは、ビジネス活動で使用されるものを記録することです。 ただし、物と一緒に、それらと同等の権利を持つオブジェクトとして、物として数えられない会計アカウントに多くのオブジェクトが反映されます。 たとえば、無形資産。 会計における無形資産とは、ソフトウェアおよびデータベース、芸術作品の著作権、発明に対する法的権利、および商標も意味します。 私はこれらのすべてのエンティティを考慮することに絶対に反対しません（無形資産のリストの枠組み内でも非常に多様です、私は注意します）が、物、情報、法律を一列に考慮することはできません！ そして、会計は考慮に入れます。



無形資産だけが物と同種として登録されていると思うなら、あなたは間違っています。 そのようなオブジェクトの雲。 モダン（ハハ！）アカウンティングのベースとなっている二重エントリは、いわゆる純資産の登録を前提としています。これは計算値、つまり抽象的な算術概念です。



資本は、経済におけるいくつかの有用なものの全体ではありません（最初に、「資本」という用語の経済的意味）、完全に異なるものです。 XとYの2つのマテリアルオブジェクトがあるとします。同時に、XはY = Zであることがわかっています。この状況では、Zはいつでもできるため、情報システムにオブジェクトとして登録する必要のない計算値です。計算されます。 Zは実際には存在せず、抽象化です！ しかし、想像してみると、複式簿記は、株式に起因するオブジェクトのグループ全体を登録します。この登録がなければ、単に存在しなくなります。 言い換えれば、存在しないオブジェクトの登録は、複式簿記の方法です。



マテリアルオブジェクトとパーで登録されている他のエンティティがあります。 牛と乳量を同等のオブジェクトとして会計処理することは、会計処理の一般的な現象です;これは確かにわかります。



ルールB オブジェクトを識別する必要があります。実際のオブジェクトは、類似した現実のオブジェクトと区別可能でなければならず、情報システムのプロトタイプには一意の識別子が必要です。



これは、簿記が実際のオブジェクトと情報オブジェクトの両方を特定しようとしないことを意味するのではなく、求めるだけで、常にうまくいくとは限りません。 その理由は方法論の分野にあります。



会計士によく知られている例を示しますが、おそらく自動化の範囲外です。



国内会計では、いわゆる退職の評価の方法が使用されます：FIFOと平均コスト、以前はLIFO法（現在は実際にキャンセルされました）がありましたが、外国会計ではHIFOとLOFOの方法が使用されているようです。 これはどのようなゴミであり、最も重要なのは、オブジェクトが受信時に評価される場合、原則として実際のコストまたは標準コストで必要なのはなぜですか？ なぜ退職査定が必要なのですか？



ここでは、会計手法のいくつかのエラーが互いに重なり合っていますが、最終的にはすべてが実際のオブジェクトを特定できないことによって決定されます。 実際には、状況は次のとおりです。



倉庫に到着した部品は、店主が同じ部品に折り畳みます。 詳細は実際には同じですが、異なる価格で購入された点のみが異なり、会計で会計処理されます（いわゆる：実際のコストで考慮する）。 店主にとって、詳細は同じですが、会計士の詳細は異なるため、詳細は異なります。 ここで、パーツは生産またはバイヤーに転送され、会計担当者は、倉庫でパーツが識別されていないため、どの特定のパーツが残っているのかという問題に直面しています。ストアキーパーは文書に従って必要なパーツをリリースしましたが、費用はどれくらいですか？ 答えは財務結果に直接影響します：会計に従って計算された損益。



この特定の問題を解決するために、処分に関するFIFOおよび他の評価方法があります。 法律は、会計士にそれをそのまま規定しています：地獄に、本当の詳細で、あなたはあたかもドロップアウトと見なされるべきオブジェクトの指示があるか、またはドロップアウトされたオブジェクトを評価する方法からドロップアウトするという事実から進みます。



ここでは、会計方法論は現実を反映しておらず、その反映が意図されているように思われますが、反対に、現実と情報システムの間の矛盾を規制します。 規制が強制されていると言えますが、現実世界のオブジェクトの識別の欠如について不平を言うことができます。 もちろん、自動化技術者にとってこのような識別問題を解決するのは難しいですが、解決策は完璧なプログラムコードを書くだけでなく、一般的な取引高を整理することにもあることを理解する必要があります。



ルールB オブジェクトは識別子によって示され、機能によって特徴付けられます。



それは簡単だろうか？ オブジェクトは識別子によって示されますが、それ自体は何も意味しませんが、あるオブジェクトと別のオブジェクトを区別することしかできません。 オブジェクトの全体の多様性を説明するために、オブジェクトの実際の特性である兆候があります。



一意のオブジェクトを定義する1つ以上の機能によってIDが決定される場合、バリアントが可能ですが、会計のケースは同じではありません。考慮されるビジネスエンティティは同一の機能を持つ場合があるため、識別子が必要です。 アカウンティング方法論はそれらにいかなる方法でも提供しませんが、量のカテゴリーを使用します：ユニークなオブジェクトはユニークな特性によって決定されますが、多くのコピーの数、または物理的なメートル（質量、体積など）で推定される変数母集団の形で存在することがわかります。 ） オブジェクトは「それ自体」のオブジェクトとしてではなく、常に増加または減少する単位の形で存在します（ただし、これは考慮されるすべてのものではなく、大多数-経済における労働のオブジェクトと呼ばれるものに適用されます）。



これは誰かにとって不幸なようには見えませんが、そのようであってはならず、考慮されている各オブジェクトに識別子が割り当てられていた場合には起こりません。 これが問題にならない場合は、少なくとも奇妙です。



ただし、ルールBに違反すると、たとえば主要な会計文書である勘定科目表など、より深刻な結果につながります。 勘定体系は、オブジェクトを特徴付ける機能のリストであり、リストは階層的ですが、階層を適用する特別な理由はありません。



オブジェクトを特徴づけることができ、原則として多くの特徴によって特徴付けられるという事実は、特徴がそれらの間で等しく等しく、個々のオブジェクトに適用されるという事実を意味します。 大まかに言えば、オブジェクトが色によって特徴付けられる場合、各オブジェクトは1つまたは別の色（またはその不在-無色）によって特徴付けられますが、色は使用される他の特性、たとえば味と同じです。 ただし、勘定コード表は特性の階層に基づいています。 これは理論的には可能ですが、特性が階層の異なるブランチで繰り返されない場合にのみ合理的です。これはアカウンティングに起因するものではありません。 その結果、ある種の方法論的エラーが発生します。単一のツリーに存在する特徴については選択が容易であり、セット内の階層の枝に散在する他の特徴については、階層システムが適応されているため選択が困難になります階層を上下に移動し、ある枝から別の枝に飛んでいるリスのようにジャンプしないようにします。 いずれにせよ、私はそう思う。



標識の階層システムは、フラットシステムの特殊なケースです。これは、良い意味で、会計に適用する必要があります。 勘定科目表の方が自然な方法を教えてください：勘定科目残高（つまり、階層の最上位レベル）またはいわゆる分析機能に従って残高を計算します（複数の勘定科目を特徴づける場合）（たとえば、 、これらのことは何で、どのアカウントで考慮されますか？ 会計ソフトウェアも複雑なサンプルを扱うように訓練されていますが、ここではソフトウェアについてではなく、会計方法について説明しています。 兆候が等しければ、どの兆候が報告指標を生成するかについて絶対に無関心です。



ルールG。 サインは互いに矛盾してはならない。



自動化技術者はこれらの詳細に入らないように努めていますが、階層よりも、勘定体系はセマンティクスが不十分です。



（一般に受け入れられてはいませんが）情報システムはそれ自体では存在できませんが、独自の制限を超えるものを含める必要があることはよく知られています。 会計情報システムでは、他の多くの場合と同様に、システムで使用されるシソーラスがこれを超えています。 オブジェクトを特徴づけ、情報システムのコンテンツを構成する兆候は、システムのユーザーが自分の心と経験に基づいてあると認識する特定の意味を持つ単なる用語です。 システム自体では、セマンティクスは定義されていません：部分的に定義できます（たとえば、企業はその識別子名だけでなく、登録コード、銀行の詳細などによっても特徴付けられます）が、完全には定義できません。 つまり、会計情報システムは、内部構造の観点から理想的に設計されており、わずかなエラーや矛盾はありませんが、外部セマンティクスのエラーが含まれているため、まったく機能しません。 さて、会計対象を特徴付ける標識、つまりこれらすべての会計分類が手作業で作成された場合、定義上、何も良い結果は得られないことは理解できます。



私は能力があると断言します。会計分類は正確に構成されています。 たとえば、勘定科目表によると、「資材」口座にはサブアカウント「原材料」が含まれています。 言い換えれば、「原材料」は「材料」のサブセットを構成するものであり、その逆ではありません。これは本当に驚くのでしょうか？ そして、口頭での会計の定式化にはこのようなエラーは少なくなく、数十、数百でもあります。勘定科目表に示されている約70の勘定科目ごとに、そのような言語学的な間違いがいくつかあり、会計システムが無意味になります。 自動化された会計ではなく「会計」会計に「入る」ことを試みた場合、あなたはすぐにこれを確信したと思います。



外部セマンティクスのレベルで欠陥のあるシステムを自動化するか、自動化しないで、正常に機能するものを作成してもまだ機能しません。



ルールD. 登録されたソースサンプル間の関係は、対応するアカウンティングオブジェクト間の関係として表示されます。



元のサンプルとは、情報システムのオブジェクト（会計オブジェクト）のプロトタイプとして機能する周囲の現実のオブジェクトを意味します。



この規則は、最初は理解できないように聞こえますが、例を挙げた後は馬鹿げています。 たとえば、情報システムに2つの赤いリンゴが登録されている場合-または1つの赤いリンゴが登録されていて、2つ目のリンゴが緑である場合は重要ではない-この属性によって登録済みのリンゴ間の関係を判断する場合、他に登録する必要はありません。 値自体の比較は、一致（同じ色のリンゴ）または不一致（異なる色のリンゴ）のいずれかを示します。



誇張された例-この規則に従わないことは、実際にはより困難です。



セール（お金のための商品）を受け取ります。 指定されたオブジェクト-商品とお金-は交換比率によって接続されます。交換比率は、受け入れられた会計方法論に従って、会計レコードで固定する必要があります。 この場合、お金は、それが商品のために受け取られたという事実によって特徴付けられ、商品はお金と引き換えに脱落したという事実によって特徴付けられます。 オブジェクトを使用して他の操作を行う必要はありません...そう思われます。 そしていや！ 実際には、お金と商品の間に、Realizationと呼ばれる奇妙なオブジェクトが挟まれています。その結果、1つの会計レコードではなく2つの会計レコードが取得されます。 および販売借方、商品貸方。 この人工的な現象は、オペレーションのフレームワーク内で相互接続されたオブジェクトの異なるコストによって説明される場合があります。おそらく、受け取った利益の額は、Realizationアカウントがサービスを提供する財務結果に起因します。 これはナンセンスです。発明されたオブジェクトなしで利益を財務結果に帰することは可能です-実装は必要ありません。



わかります、はい：ここでは、1個の牛を考慮し、15リットルの牛乳を考慮します（これは、牛と牛乳が実際に存在するものであるため、論理的です）。週105リットル？



それに何と言えますか？！ 会計の方法論はあまりにも無視されているため、エラーが互いに強制し、互いに重なり合っているため、最終的にどのルールに違反しているかを判断することが難しくなります。 確かに、会計の年齢は少なくとも500年、そしておそらく2倍です！



ルールE. 登録済みソースサンプルと未登録サンプルとの関係は、登録済みサンプルのサインとして表示されます。



前の規則で規定されているように、両方のオブジェクトが登録されている場合、問題はありません。 ただし、周囲の現実のすべてが会計に登録されているわけではありません。 情報システムが、登録済みオブジェクトと未登録オブジェクトの関係を表示する必要がある場合はどうなりますか？



キログラム標準があり、3キログラムの重さがある別のものがあると仮定します。これは、モノと標準を比較的重くすることによって明らかにされます。 情報システムに計量操作を登録すると、2つのオブジェクト（モノと標準）の間に適切な関係が発生します。 しかし、標準がシステムに登録されていない場合、物の重量を記号としてのみ設定することができます。 「3 kg」は物事の兆候であり、他には何もありません。 この場合、比較加重を登録する必要はありませんが、この場合、標準が情報システムに登録されていないという事実のため、これはまだ不可能です。



今すぐ練習してください。



会計では、2番目のコストでオブジェクトを考慮する必要があります。 オブジェクトは100ルーブルと推定されていますが、それは必要です-まあ、それは必死に必要です、あなたは知っていますか？！ -110ルーブルでさえ考慮に入れてください。 何が簡単に見えましたか？ システムに追加機能を導入し、短期間全体を...しかし、会計方法論ではこれを許可していません-何らかの理由で、それは重要ではありません。これについては触れません。 非標準的な方法で状況から脱出する必要があります。つまり、別のオブジェクトを登録します。これは、実際には存在するものではなく、いわゆるコストの差を表すものです。 上記の例では、オブジェクト、いわゆる規制は、10ルーブルで評価されます。 その結果、2つのオブジェクトが登録されます。1つは100ルーブル、もう1つは10ルーブルに相当します。 これにより、問題の条件に応じて、110ルーブルで最初のオブジェクトを評価できるようになりますか？ 小学校：100と10ルーブルの量。 所望の110ルーブルを与えます。 -つまり、2番目のコスト（新しい基準でのオブジェクトの特性）でオブジェクトを評価するために、新しいオブジェクトが登録されます。したがって、情報システムの2つのオブジェクトは、1つの実物に対応し始めます。メインオブジェクトと、メインオブジェクトのコスト差という形での追加オブジェクトです。同時に、結果として生じる規制の枠組みは決して物の一部ではありませんが、その属性は独立したオブジェクトとして登録されています。オブジェクトとして登録されたサイン！



会計上の奇跡に制限はないと言います。



私が策定した会計学は、これらの規則に限定されず、はるかに広くなっています（一部の資料はHabréで公開されています-たとえば、こちら）この投稿では、会計規則と会計慣行を比較することのみを目的としており、現在の会計方法論がコンピューター会計の観点からどれほど馬鹿げているかを示しました。残念ながら、多くのIT専門家はこれを理解しておらず、会計手法をプログラミングの手法に置き換えようとしています。ただし、プログラムコードの記述は会計の自動化を意味するものではなく、自動化はより深い概念であり、コンピューターテクノロジーの使用だけでなく、これに適した登録の方法論的な方法も含まれます。