13年前、私はYAOF（レポートフォームの言語）を発明し、会計の教科書に章として含めました。
いいえ、いいえ、尊敬されているハブラチアンを「コード」サンプルと混同するつもりはありません。なぜなら、私が生まれた直後、YOFは無事に亡くなったからです。 この言語は亡くなりましたが、彼が解決しようとしていた問題は、ほとんどの人がその言語に関与しておらず、現在関与していないという事実により、未解決のままでした。 この問題の解決策は、会計士だけでなくプログラマーにとっても特定の関心事になるかもしれません。
今、私は問題が何であるか説明しようとします。
会計レポートを見ていない人は何人いますか？会計士が財務指標を記入する無数の消化できないフォーム？！ 最初から、フォームは特定の構造を持つデータベースに基づいて構築されているため、その構築にはいくつかの典型的なアルゴリズムが必要です-各ケースに関してプライベートではなく、典型的です。 それは、各指標が別々に計算される会計レポートのテキスト表形式の説明を、レポートがソースデータベースで実行された標準手順の結果である正式な数学的説明に置き換えることでした。
完全に無力であるため、ここで発明した「コード」を持ち込むリスクはありませんが、その遠い瞬間に私を動かしたロジックをまだ拒否していません。 おそらく私の推論は、IT専門家の一部に賢明な思考を促します。 要するに、検討のための情報。
レポートフォーム用の言語を作成することにしたので、私が最初にしたことは、レポートを非構造化レポートと構造化レポートに分割することでした。
- 非構造化レポートでは、指標はそれぞれ個別に計算され、表に配置されるか、任意の方法でシートに配置され、テキストの名前と説明が添付されます。
- 構造化レポート -それどころか、明確な構造を持つレポート：変換のいくつかを通じてソースデータベースから取得したテーブルの形式。
非構造化レポートは、明らかに「コンピューターではない」性質があるため、形式化を放棄しなければなりませんでした。
「構造化されたレポートのみ、変換されたテーブルのみ」私はすぐに自分で確立しましたが、変換は最初のサンプルの不足に直面しました。
初期構造がわかっていれば、何かを何かに簡単に変換できますか？ 資格情報と可能な限り多くの構造を登録する多くの方法がある場合はどうすればよいですか？ 変換の典型的な方法に興味があったことを思い出してください。その結果、有益な説明を含むフォームの形式ではなく、プログラマーだけでなく会計士にも理解できるプログラムコードの形式でレポートフォームを取得することが可能になります。 解決策は1つしかありませんでした。ある構造をモデルとして採用し、そこから始めることです。 この場合、サンプルとして受け入れられた標準構造のアカウンティングデータベースを直接使用してレポートを生成できますが、非標準構造のデータベースは最初は標準構造のデータベースに縮小する必要がありました。
標準構造を持つベースを正規化テーブルと呼びました。 興味のあるデータベースはどれもアカウンティングであったため、すべてのアカウンティングデータベースを正規化されたテーブルに取り込むことができました。いくつかのオブジェクトが登録されており、プロパティとメーターのリストで表される特定のデータ構造が必要でした。
与えられた最も単純な正規化されたテーブルでは、各行は1つのオブジェクトを表し、Sはオブジェクトのプロパティであり、iはメーターです。
アカウンティングデータベースの構造がどれほど洗練されていても、最終（最も単純な）バージョンでは、オブジェクトを登録し、そのプロパティとメーターを記述します。
厳密に言えば、ゲージは会計データベースの必須要素ではありません。会計の基本的なメーター- 数量 -は、サンプリング後にオブジェクトレコードの数としてテーブルを変換することで取得できます。
i1とi2がオブジェクトの数ではなく何か他のものを示し、プロパティS1に従ってオブジェクトの数を操作する必要があるとします。 不要なプロパティを破棄して、変換用のテーブルを取得します。
次に、フィールドS1の各値でオブジェクトの数（i3）をカウントすることにより、変換を実行します。
ソーステーブルにない新しいメーターが表示されます。
同様に、 平均値を取得できます。
しかし、ソーステーブルに必要なすべてのメーターが配置されていると仮定します。質問は、会計レポートを生成するときにどのタイプの変換が必要かということです。 私は長い間この質問を自問し、私に知られているさまざまな会計報告書と声明（残念ながら構造化されたもののみ）を標準的な変換に還元しようとしました。
いくつかの必要な変換-まず第一に、テーブル列の再配置 、 転置 、 選択、およびソート -自明であるためすぐに省きました。私は本当に会計方法に興味がありました。 長い反射の結果、2つしか見つかりませんでした。
1つ目はよく知られています： 階層でプロパティを設定します 。
初期データを取得します（プロパティS1およびS2とメーターi1のみを使用します-つまり、サンプリング後）。
次の階層を定義します。
変換の結果、次のようになります。
会計では、そのような場合、書くのが慣例です：含む...
2番目の方法は、プロパティを見出しに配置することです （この方法は、経理でもコンピューターサイエンスでも名前が付けられていなかったので、自分で発明しなければなりませんでした）。
以下についてです。
最初の正規化されたテーブルを使用します。
次に、オブジェクトのプロパティの1つ（S3など）をヘッダーのメーター領域に配置すると、次の結果が得られます。
データは同じですが、テーブルの外観は完全に異なります。 レポートユーザーにそんなに多くの情報を提供したいのなら、レポートデータの対象者を選択してください。
明らかに、階層に応じてヘッダーに入れることができます-そのような階層を設定します、例えば：
この場合、次のテーブルビューが表示されます（最初のブランチのフラグメントが表示されます）。
私が理解している限り、テーブルを転置し、その階層を設定することで同じことが得られます。つまり、テーブルをヘッダーに入れることは、特定のシーケンスで実行される変換の最終結果です。
正規化されたテーブルの残りの可能な変換（たとえば、 結果の行 ）は、よりデザイナーです。
考慮された例では、最も単純な初期データが使用されました：実際には、データベースは日付と収入費用 （歪んだ会計バージョン、借方と貸方）によって複雑になり、1つのオブジェクトの収入と支出は同時に記録されません。 したがって、オブジェクトは2回登録されます。到着時に1回、消費時に2回です。 受け取られたが、廃止されたオブジェクトではなく計算されたメーターは、 バランス （一般的にはバランス）を形成します。 ただし、このメーターはテーブル変換機能に根本的に新しいものを追加しません。
構造化レポートは、これらの基本的な変換に縮小できます。
報告フォームの言語の必要性が生じたとき、そのような言語は、私のようなプログラミングの絶対的なアマチュアではなく、完全に資格のある同志によって、非常に迅速に記述できるように思えます。 これが実現されると、会計報告の形式はプログラムコードの形式になります。これは、情報化の観点から歓迎されます。 まったく異なる質問は、これが会計分野の意思決定者にどれだけ必要かということです。 会計基準のコンピューター化の方向でいくつかの非常に控えめなジェスチャーが行われていますが、それらは十分で十分とは言えません。
PSすでに記事を終えた後、私は会計士またはプログラマーのどちらが同じ問題を解決した（少なくとも解決できた）かを把握しようとしました。
会計士のうち、2人が頭に浮かぶ、会計の人々は有名です。
最初はニコライ・ウスティノビッチ・ポポフ （1843-？）です。 彼は長年住んでおり、報告フォームの形式化の問題を解決したのではなく、個々の会計システムの数学的正当化の問題を解決しました。 当時、プログラミングはきついが、ニコライ・ウスティノビッチが現代人だったら、彼の数学的能力が応用できることは間違いない。
ネタバレの下で、N.U。の本から数ページ ポポフの「会計の数学的方法」（1906）。これにより、ハブラチ人はこの人がどのカテゴリーを考えたかを理解できました。
見る 
解決した（そして正常に解決した！）2番目の会計士会計報告の形式化の問題は、現代の教授であるOleg Ivanovich Kolvakh （1946年生まれ）です。 彼の概念によれば、会計レポート（初期データも）は行列代数の枠組みで形式化されているため、システムの名前はmatrix accountingです。
ネタバレの下で、O.I。の作品から2ページ Kolvaha「会計とバランスシートの形成のマトリックスモデル。」
見る 
マトリックス会計O.I. コルヴァフは私の会計教科書よりも早く作成されたので、当時私はそれに慣れていませんでした。そうでなければ、核兵器の発明を控えたでしょう。 残念ながら、数学に関する私の知識すべてについて、マトリックスアカウンティングは実際の使用において数学的厳密さを受け取っていません。
会計業務では、主に1C：Enterpriseで会計ソフトウェアに関連する言語が使用されます。 これらの言語が慣れていないため、これらの言語がフォームをレポートするための汎用言語としてどのように使用するのに適しているかはわかりません。 プロのプログラマーがそのような言語を作成しようとする試みは、雇用主の順序ではなく、彼ら自身のイニシアチブによって、私には知られていない。