ダブルブラジャー*プログラマーの目を通して

私たちのほとんどは会計士に出くわしました。 多くの人にとって、彼らの用語は中国人の手紙であるように思われます。 ただし、このツールがどれほど便利で強力なのかを理解しているはずです。



この記事は学術的なものではありませんが、私の単純な見方を反映したものであり、すでに学術的な記事を習得している人にとっては面白くないでしょう。 「ダブルレコーディング」のようなシンプルで強力なツールを理解することに興味がある人は、猫の下でお願いします。



何らかのプロパティを所有し、外の世界と関係があるアクティビティをリードする何らかの構造を想像してみましょう。 どんな構造であるかは関係ありません。 会社、世帯、ウェブサイト、または単純な市民のいずれかです。 それがオンラインのスタートアップになるとしましょう。 象取引プラットフォームを作成するとします。 このプロジェクトを「Slonomarket」と呼びます。



法人、IP / FOP、その他の法的措置は登録しません。 ほんの数人の友人がそのようなスタートアップを立ち上げ、ガレージで活動を行うことに同意したと想像してください。

バランス

私たちの象市場の財政の全体像を理解するために、私たちは持っているもの、借りているもの、借りているものなどを書くタブレットを立てました。 このプレートを「 残高 」と呼び、プレート内の線は「 残高勘定 」です。



明らかに、 すべてのヨーグルトが同じように役立つわけではありません。 「キャッシュデスク」のお金を反映するアカウントには、サプライヤへの支払い額と大きな違いがあります。 したがって、プレートを2つに分割します。 1 つには 、いわゆる「 アクティブアカウント 」があり、保有しているものや管理できるものなどを反映します 。後半には、「 パッシブアカウント 」を入力し、債権者、サプライヤーなどに負債を反映します。 n。



実際、資産と負債（Rzhevskyは沈黙します！）はまったくの財産と負債ではありませんが、最初に、混乱しないようにそのような定義を提案します。 記憶するために、このような関連付けを使用できます-資産を積極的に管理できます。 ランダムな知人にお金を与えるか、使い果たします。 クライアントの借金（クライアントに対する私たちの借金は資産であり、サプライヤーに対する借金は負債です）を許すため、機械を破壊するか、車にスクラップを渡します。 それはすべて私たち次第です。 また、負債がある場合、受動的な操作のみが可能です。 私たちはサプライヤーに借金をランダムにホームレスにすることはできません。 ホームレスとサプライヤーの両方の同意が必要です。



象市場のバランスの例：



資産：

• YandexMoney：1000rub
• 紙：500摩擦
• フェディと現金：1000rub
• 象の在庫：600ルーブル（うち販売済みだが出荷されていないもの-500ルーブル）
• 象市場サイト：400rub
• 1年間のホスティング：1000rub
• 象の顧客債務：1000rub
• カバーされていない損失（象の盗難による）：500rub

負債：

• 資本金（創業者の貢献）：2000rub
• 利益剰余金（象の販売による）：1000rub
• WebMoneyクレジット：1000rub
• 象は販売されましたが、クライアントに配達されていません：500ルーブル
• サプライヤーVasyaへの債務：500ルーブル
• プログラマーへの義務Feday：500rub
• 未払配当金：500ルーブル

一部のアカウントは驚くべきものです。たとえば、負債の利益と資産の損失の理由は明らかではありません。 これは正常です、もう少し低く説明します。



パッシブアカウントの量がアクティブアカウントの合計に等しいという事実に注目したいと思います。 このバランス特性は基本です。 ここから名前-バランスが生まれます。 会計士が残高が収束しないと言った場合、通常、彼は資産と負債が等しくないことを正確に意味します。これはエラーの最初の兆候です。

パッシブまたはアクティブになるアカウントの別の外観：

資産は私たちが持っているもの、お金を使ったもの、負債はこのお金の出所です。



この観点からは、実際に既に存在しているので、資産に利益を反映することはできません-キャッシュデスクでのお金の形、クライアントの借金の形、またはその他の形のいずれかです。 クライアントが支払いを済ませ、倉庫で象の購入にこのお金をすぐに使ったとしても、利益は新しい象の形になりますが、すでに資産に反映されています。 しかし、それはどこから来たのですか？ 負債-利益にその起源を記録します。



同様に損失。 たとえば、象が盗まれたなど、損失を被った場合、これらの象の起源はすでに負債に反映されています。 これらがすでに販売されているが出荷されていない象である場合、支払われているが出荷されていない象に表示されます。 創業者のお金からそれらを購入した場合、認可された資本で、販売または遅延してそれらを与えられた場合、サプライヤーへの債務の形で。 しかし、このお金（象）はどこに行きましたか？ これは盗難による損失です。



これらの損失を管理する能力の観点から、そして私たちが「持っている」という事実からも矛盾はありません-泥棒を許すことができます。 泥棒を逃した警備員に「借金をかける」ことができ、彼の給料から計算することができます。 これらの損失を保険金と交換することができます（保険がある場合）。 さて、または損失を利益から「カバー」して、利益と損失を1量減らします。



なぜ株式/資本が負債に反映されるのですか？



起源によって、私たちは創設者からお金を受け取りました。つまり、このお金をどういうわけか彼に「負っている」ということです。 また、機能ごとに-たとえば、配当に、または承認された資本を増やすために、利益を分配することができます。 配当とは、創業者が会社からそれらを（資産、お金、製品などの形で）取得することを意味します。利益から認可資本を増やすと、創業者がスタートアップの資産を増やすために利益の一部を寄付したかのようになります。



「過剰な」利益はないが、損失があり、これらの損失をカバーしたい場合、資本を削減する以外に選択肢はありません。 これはおおよそ「会社にはお金がないので、借金の一部を許します」に相当します。 すなわち 私たちのSlonomarketが利益を得た場合、それは創業者により多くのお金があり、彼がお金を失った場合、それはより少なくなります。



なぜそのような困難なのですか？ バランスが必要だからです。 残高の両側は等しくなければなりません。そのため、一部の残高項目（アカウント）を取り出して捨てることはできません。



所属するチートシート：



プロパティ、次に処分できるもの-アクティブなアカウント

私たちへの義務、借りているもの-アクティブなアカウント

義務、必要なもの-パッシブアカウント

利益-パッシブアカウント

損失-アクティブなアカウント

収入-パッシブアカウント

費用-アクティブアカウント

資本、すなわち 創業者の投資、承認された資本など -パッシブアカウント

投稿

ここでは、バランスの2番目の基本的な特性にスムーズにアプローチしました。変更は少なくとも2つのアカウントに関連しています。 この声明は、主要な貸借対照表の特性の直接的な結果です。貸借対照表の両側（資産と負債）は合計で等しくなければなりません。 したがって、一方を縮小または増加させる場合、反対側も同様に変更する必要があります。 または、同じタイプ（アクティブまたはパッシブ）の別のアカウントを変更する必要がありますが、符号は異なります（つまり、資産を増やして負債を変更しなかった場合、他の資産を減らす必要があります...同様に負債も同様です）



これが私たちにとって十分であることを確認するために、資産は私たちが持っているものであり、負債はそれがどこから来たかを覚えておいてください。 したがって、同様の条件で、ある種の資産がある場合、それはどこかから来るはずであり、それに応じて同様の記録が負債に現れるか、別の資産が減少します。



在庫のある製品があるとしましょう。 しかし、彼はそのようには見えません。 それを購入してから、一部の資産が減少した（手元の現金、口座のお金など）か、ローンが与えられた（繰り延べ、売却など）してから同じ金額に対して新たな責任を負います。 彼らは私たちからお金を盗みましたか？ お金が減り、損失が増えました。 融資をしましたか？ 資産を減らすか、他の負債を増やすことなく、信用を与えることはできません。 結局、私たちは何かを与えました。 これは、お金、または他の場所（たとえば、創業者から）で借りたもの、または彼らが何らかの商品を与えた負債のため（倉庫内の在庫が減少した）、または販売のために取った商品を返しました（商品の量を減らし、仕入先に負債を減らしました）このアイテム）。 2つのアカウントは常に変更されます。



そこで、2つ目の基本概念である「 配線」に進みます。



転記は、2つのアカウントを同じ金額だけ変更する「アトミック」トランザクションです。 紙の会計では、大きな本を使用して、さまざまなアカウントと操作を記録します。 最初のアカウントと2番目のアカウントで、各トランザクションを2回記録する必要があります。 これは二重エントリと呼ばれ、現在の会計の基礎となる会計方法に名前を付けました。



1つのアカウントのみが影響を受ける操作は誤りです（はい、私はオフバランスのアカウントについて知っていますが、これは会計士がプログラマーではないという事実の結果である規制会計の初歩であり、この記事ではアクティブパッシブアカウントと同様に考慮しません）。 単一のエントリを作成する場合、それを行う必要がないか、どこかでソウルメイトを失ったか、間違ったバランスで録音を行う必要があります（たとえば、人々がビジネスマネーと個人のマネーを混合し始めたときなど）ビジネスに他のファウンダーがいなく、会計について十分に理解していない）。



理論的には、1つのトランザクションには、たとえば3つのアカウントが存在する可能性がありますが、これにより、正確性などを検証するのが難しくなります。したがって、アトミック操作は2つのアカウントに影響します。



そのため、勘定科目で構成される残高があります。 アカウントには、アクティブとパッシブの2種類があります。 貸借対照表の変更は、転記によって行われます。 転記は、貸借対照表を使用したアトミック操作であり、2つのアカウントに影響し、同じ金額で変更します。

運営

各トランザクションには1つ以上のトランザクションがあります。 本質的に、操作は、単一の意味、単一のイベント（およびイベント自体を説明する情報ですが、バランスのために必要ではありません）によって接続された一連のトランザクションです。

操作は、実世界のイベントを反映する一種のエンティティです。 商品の移動、注文、配当の支払いなど すなわち 実際の操作。

1つの操作の投稿は同じDBMSトランザクション内にある必要があり、1つの投稿が失敗した場合、操作全体が失敗しました。 操作には原子性があります。



象のバッチを取得したとしましょう。 100ルーブルのシベリア象、400ルーブルのアフリカ象、500ルーブルのアメリカ象。 その結果、いくつかの投稿があります。



1）サプライヤーへの債務の100ルーブル（負債）の増加、倉庫内のシベリア象の100ルーブル（資産）の増加

2）400ルーブルの負債の増加、在庫のアフリカゾウの同量の増加

3）500ルーブルの負債の増加と在庫のアメリカゾウの同様の増加

4）500ルーブルの前払いに対するサプライヤーの負債の減少、およびサプライヤーへの同額の負債の減少（理想的には、このようなことは別個のサービス文書として行われます。請負業者との関係のアカウントはアクティブ-パッシブであることがわかっていますが、ここにあります）



これらのトランザクションはすべて1つの操作に関連付けられており、1つのイベント、つまりサプライヤからの商品の受領、同時発生などに関連付けられています。

文書

通常、どの会計でも、各イベントは1つまたは複数のドキュメントの形式で表示されます。 文書が貸借対照表の変更を反映している場合、それらは1つ以上の操作の形で反映されます。 1つのドキュメントに関連するトランザクションをさまざまな操作に分割することには明確なルールがなく、特定の会計目標に依存します。

借方と貸方

どんな投稿があるのか​​見てみましょう。



1）アクティブアカウントの増加、パッシブアカウントの増加（A + P +）

2）アクティブなアカウントの減少、パッシブ（AP）の減少

3）2つのアクティブなアカウントの増減（A + A-）

4）2つのパッシブアカウント（P + P-）の増減



4種類の投稿が判明しました。 残りはバランスを維持する要件を満たしていません。 これを単純化できますか？



アカウントの順序にはまだ意味がないので、別の順序で記述します。



A + P +

P-A-

A + A-

P-P +



サイレントワイヤリングの共通点は何ですか？



1）アクティブなアカウントがそもそもある場合は増加し、パッシブな場合は減少する

2）2番目の場所がアクティブアカウントの場合は減少し、2番目の場所がパッシブアカウントの場合は増加

T.O. 1つのタイプのトランザクションを取得します。これは2つのアカウントを示し、デビットアカウント、クレジットアカウント、およびトランザクションの量と呼びましょう。

それに応じて、投稿アクションルールを記録します。

1）アクティブなアカウントの借方が増加すると、パッシブの場合は減少します

2）ローンがアクティブなアカウントの場合は減少し、パッシブなアカウントの場合は増加します



ここで、残高を維持するための会計フォームが終了します。

もう少し正規化する

まだ単純化してみましょう。



アクティブなアカウントの値を正の数として記録し、パッシブなアカウントの値を負の数として記録しましょう。 貸借対照表の単純化された構造は次のようになります。



ID

お名前

タイプ（パッシブ/アセット）、

価値

そして、投稿テーブルの構造、それぞれ：

ID

借方（借方勘定のID）、

クレジット（クレジットアカウントID、

金額



残高の整合性を確認するのがさらに簡単になります-すべての口座の合計がゼロになるはずです。



投稿のルールも簡単です。



1）取引の金額を借方勘定に追加します

2）アカウントがパッシブである場合、正になったかどうかを確認し、正であれば、操作を中止してトランザクションをロールバックします

3）クレジット口座から金額を差し引きます。

4）アカウントがアクティブである場合、マイナスになっているかどうかを確認し、マイナスになっている場合は、操作を中止してトランザクションをロールバックします。



それだけです すでに会計のすべての基本的な特性があります。



もちろん、実際のデータベースでは、サブジェクトエリアに関連するさまざまなフィールドを追加します。たとえば、投稿には日付/時刻と、投稿を生成したドキュメントへのリンクが必要です。 アカウントには、これによる何かに関する情報と、他の関連オブジェクト（請負業者、商品など）への接続が必要ですが、それは別の話です。



おそらくここで終わります。興味深い場合は、残高から情報を最大限に抽出する方法を説明します。操作の例をいくつか分析します。



ADF：操作とドキュメントの概念を分離しました。 記事の議論の中で、操作とドキュメントは同一であるとここに書かれていました。