AccountLogic 2.0：念頭に置いたが、終わりではない

この「製品」の作成の背景は、Habréの投稿にまでさかのぼることができます（バージョン1.0のリリースに特化した最後の記事はこちら ）。



バージョン2.0で、方法論的な可能性の上限の最終的なものではありませんが、いくつかの近似について話すことができる機能が追加されました。



これまで、「Accountant Logic」（新しい「Russified name」「Accounting Logic」）では、少なくとも仕様に従って許可する必要がありますが、かなり多くのことが許可されています。







コードが重大な結果を伴うアマチュア的であるという明らかな事実を否定しない無作法な広告。 さらに、プログラムで規定されている方法は専門的です。理論的基盤に基づいて作成され、その開発には10年かかりました。





バージョン1.0で使用可能な機能をリストするのは意味がないので、重要度が高い順に新しい機能の説明から始めます。



私。

サービス機能：アーカイブ、パスワード保護、ローカライズ（英語-機械翻訳、言語力の乏しい程度に調整）。







すべてが標準的なものであり、方法論上のわずかな関心事ではありません。



II。

データベース内のデータは、実際（メイン）と計画（追加、それらと比較するためにメインのものと並行して考慮される）の2つの部分に分けられます。 多様性に傾いていない典型的な機会。



レポートフォルダーは、実際のデータと計画されたデータを個別に提示するとともに、共同で提示します。











理論的には、多くの計画された（互いに並行した）情報フローを実装することは難しくありませんでしたが、なぜですか？



III。

ファイルバインディングは実行が簡単な機能ですが、珍しいソフトウェアアーキテクチャのため、面白くないわけではありません。 通常どおり、ファイルをワークスペースにドラッグアンドドロップすることで実行されます。







ファイルを次の要素のいずれかに関連付けることができます。

1. 事（写真に示されている）、
2. 行動
3. フォルダー。

用語は通常の会計とは異なるため、明確にする必要があります。 たとえば、[name] = "apple"、[grade] = "Antonovka"など、いくつかのプロパティがあるものがあります。 したがって、その受領はアクションに反映されます-アカウント、会計エントリの類似物。 そのため、ファイルをリンゴ全体（もの）、または受信に関するエントリ（アクション）、またはレポートフォルダーが形成されるプロパティ（名前、種類など）-実際には、別のセル。



便利なサービス、これ以上。



IV。

私は会計の革新、つまり物事の編集に直接向きます。



バージョン1.0を検討するとき、私は非難されました-眉毛ではなく、目で。 主張は次のとおりでした。「部屋にはいくつかのものがあります。 私がすべてのものをバルコニーに移動し、それによってこれらのものの特性を変更したと仮定します。 それは[location] = "room"でしたが、[location] = "balcony"になりました。 それで、私は個々のもののプロパティを個別に変更する必要がありますか？ すぐに本当に不可能ですか？」



今できます。 必要なものを選択し、プロパティを必要なものに変更します。







別の特定の機能は、物事の自動分離です（最初のバージョンでは、1つの特定のケース用に実装され、現在どこにでもあります）。



プログラムのイデオロギーは可能な限り現実に近いため、自然な順序で物事を扱うことができます。 100ルーブルがあり、そのうち10ルーブルを取引相手に譲渡する場合、当面は10ルーブルであるため、単に譲渡することはできません。 100ルーブルの一部を構成します。 会計原則に従って、最初に合計金額を90ルーブルで割る必要があります。 そして、10ルーブル。その後、オブジェクト全体を意図したとおりに転送することができます。 理解できる単一の送信の代わりに、2つの操作が発生します。一見過剰な分離と送信です。 これは、非の打ちどころのない理論的正当化にもかかわらず、不安にさせるものです。したがって、物事を自動的に部分に分割する機能が記述されています。



以前は利用できなかった「Things to Consumption」ラベルのアクションウィンドウで、アイテムのどの量的部分が変更されているかを示します。







「会計ロジック」自体が、指定された部分をオブジェクト全体から分離し、このアクションを主要なアクションの予備として記録します。



結果は、実際には共同で実行された2つのアクションの記録になります。 「過剰な」操作を心配する必要はありません。







この機能は、基本的なものだけでなく、複合的な均質物（化学的組み合わせに基づいて形成された-組成が互いに区別できないものの束）にのみ適用できることを予約します。 複合異質物（機械的結合に基づいて形成され、それにより互いに異なる部分で構成されることができます）-言い換えれば、メカニズム-最初に分解する必要があります。その後、コンポーネントを引き出した状態でアクションを実行する必要があります。



複合的な異質なものの部分への自動分割には、インターフェイスの顕著な複雑さが必要ですが、その必要性は現在見られていません。



V.

さらに、プログラムの時間精度が向上します。



法律では、最も近い日までの会計が必要です。 ただし、記録を保持する時間単位に基本的な違いはないため、ユーザーには選択の機会が与えられます。



「アカウンティングロジック」2.0では、会計指標（残高と売上高、それらから得られる収入と費用）を秒まで正確に計算できます。







私が理解している限りでは、秒単位の精度を実行することは難しくありません。したがって、注目に値するタスクです。 会計学のアプローチに従って、将来の事柄である義務の会計処理の革新を視覚的に示すことができるので、私にとって注目に値します。



前の投稿へのコメントで、読者は、義務の会計処理に関する会計学的手法の新規性を理解していないと不満を漏らしましたが、義務-そしてもっと広く見ると、物事とタイムラインの関係-は、私が無条件の成果と発見に帰するものです。 言葉で説明するのは困難でした。プログラムで披露するのに1日かかりました。1日後に初めて、未来からのものが現在に変わる様子を見ることができました。 1秒あたりのアカウンティングのおかげで、すぐに効果が現れます。



簡単な実験を行ってみましょう。



フォルダーが開いている場合は、フォルダーをオフにして、現在のもの（現時点で存在するもの）のみを表示します。







「設定」に進み、秒単位で正確なアカウンティングを設定します。



追加ウィンドウを開き、アイテムの名前を指定し、最も重要なこととして、操作を完了する時間を設定します。秒は現在の瞬間（登録の瞬間）よりも20秒多くなります。 100％未満の確率を示すことを忘れないでください。







物を追加します。 作業ウィンドウ（わかりやすくするために、アイコンモードを設定します）では、まだ表示されていません：数秒で届くためです。







20秒後に、タイマーを更新します。 すべてがエラーなしで完了した場合、追加されたアイテムが作業ウィンドウに表示されます。







フォルダを含めて、事物が到着する前に、つまり、指定された時間まで、事物が将来のものとして表示されます-義務（アクションを登録する時間がそれを完了するのにかかる時間よりも短い場合、そうでなければ義務は発生しません：物は適切な時間に到着します）それだけです。



会計士の見解によると、コミットメントは以前に登録された将来のものです。 確実にわかっている場合：1時間以内に、商品は受け取り時に登録する倉庫に到着します-これは将来のものであり、将来の時制で事前に記録できます。 しかし、あなたが今物の将来の領収書を登録する場合-これは義務です）。



さあ、行きましょう。 一般の人々からは要求されておらず、いつになるのかということのない理論の複雑さを理解することは価値がありますか？ さらに、より簡単な方法で秒の精度を実証することが可能です。



方法は次のとおりです。 設定を秒単位の精度に設定してから、物を追加します。 タイマーに操作の前にタイマーを設定します（分を減らします）-後で追加されたように、事は消えます。 元の時間を返します-事が表示されます。



VI。

義務の自然な会計への追加として、オプション「自動アクション」が追加されました（会計ソフトウェアでは、これは自動転記と呼ばれるようです）。



既知のプロパティを持つアイテムが定期的に到着、変更、または廃棄される場合、適切なアクションを自動的に実行できます。 プログラムが起動すると、最後の訪問の瞬間がチェックされます。必要に応じて、設定で指定された操作が実行されます。







実用的または理論的な観点から目立ったものはありません。



この記事を公開する準備ができたとき、計画されたレコードの自動アクションを提供するのではなく、アクションのプロパティに複数の変更を加えることに気付きました。 それは起こります。 次のバージョンが表示される場合、この省略は修正されます。



VII。

固定為替レート会計。



100ルーブルに相当するものを言ってみましょう。 3月1日（1ドルで50ルーブルの為替レート）に入り、3月30日（1ドルで75ルーブルの為替レート）にドロップしました。 その場合、アイテムの価格は2ドルで、廃棄コストは1.33ドルです。 それらの違いは為替レートと呼ばれます。



必要なパラメータを設定します。そのために、事前に準備されたアクセスベースを接続する必要があります。 そうしないと、為替レートの差を計算できません。 ルーブル、ドル、ユーロ、または他のメーターで同時に記録を保持できる場合、それらを計算する方法-主な通貨はありません、それらはすべて主なものですか？ ただし、為替レートでベースを取得すると、設定でインストールされたメーターが自動的にメイン通貨になり、通貨は追加と見なされ、その時間ベースの比率がデータベースに示されます。







その結果、レポートフォルダーに追加の列が表示されます。







この方法は正式に会計規則に準拠していません、たとえ為替レートの差がどこかに接続されていなくても（ある意味、どの会計対象にも）、単純に計算され、任意の期間の任意の通貨で計算できますその方法は考えられません。



現代の会計ソフトウェア（これは残念なことに、私はよく知らない）についてはわかりませんが、為替レートの差を計算する公式に想像できる方法は、従来の会計規則にはほとんど当てはまりません。



会計がルーブルであるとしましょう。 会計規則に従って、ここには為替差はありません。 しかし、実体経済にはドルがあり、循環しています。したがって、実際にルーブルで行われた売買コストは常にドルに変換できるため、差を計算できます。 この場合、購入と販売のコストは一致せず、差額が発生します-為替レートなどです！



計算するために、1通貨、類似、会計、欠落、為替レート差の観点から考慮する場合、コースのディレクトリを接続し、オプション「為替レート差の読み取り」および「コースの反転」を設定する必要があります。



たとえば、100ルーブルに相当するものが到着し、その時点でのレートは50ルーブルでした。 ドルのために。 しばらくして、物は（同じ100ルーブルを費やします。、明らかに）、ドル為替レートはすでに55ルーブルでした。 したがって、これらの日付（つまり、処分の日付）間の為替レートの差は...でした。自分で考えてみてください。$ 2の価値があるものが到着し、同じものが約1.82ドルかかりました。 この場合、為替レートの差は、その期間のドル価値を下げる方向で18セントになります。 「アカウンティングロジック」は、この事実をキャプチャできます（もちろん、多くの設定のために非常に面倒なアルゴリズムを台無しにしない限り）。



Viii。

非常に実用的な機能は、ディレクトリの接続です。



ユーザーは、任意の数のテキストプロパティ（フィールド）に物とアクションを設定する権利を持っていますが、一連のフィールドでは、値を繰り返すことができます-たとえば、物の同一グループのプロパティを指定する場合。 参照ブックは、従来、関連する値を選択するために使用されています。



ためらった後、サードパーティのデータベースを接続するオプションを選択しました。 ユーザーは通常のアクセスツールを使用してディレクトリを管理し、適切なダイアログボックスを使用して完成したフォームでアカウンティングロジックにインポートされることを前提としています。







ディレクトリからのフィールドによって、レポート階層を構築することが許可されます。一般的には、ディレクトリ自体の変更を除き、すべてを行います。



これで、新機能のリストが完成しました。 面白くなく、実際に書かれたいくつかの機能は、私が恐怖で気づいた理由で捨てられました：歴史的発展のこの段階でそれらを使用することは不可能であり、それはあまりにも不便です。 したがって、「アカウンティングロジック」2.0は、方法論的な可能性の上限に反していると言えます。



まだ満たされていない主なものは、現時点では構築されていないように見えるネットワーク機能です...しかし、見てみましょう：祖母は2で言った。



ところで、ネットワーク機能について。 以前の投稿の1つへのコメントで、異なる国籍のユーザー間で物事を転送するときに、プロパティの互換性がどのように実装されるかを尋ねられました。 日本人は、プロパティを日本語、ロシア語で命名します-ロシア語では、日本人ユーザーからロシア語に物事を転送するとき、またはロシア語で物事を転送すると、プロパティが異なると認識され、失われます。 それから私は知らなかった、ある言語から別の言語への翻訳に応じてつぶやいた、今私は答えることができます。 アカウンティングロジックでは、プロパティは名で識別されます。将来、プロパティの名前は変更できますが、識別子（最初の名前）は保存されます。 したがって、言語の互換性を実現するには、プロパティを設定するときに、国際（英語）として受け入れられている言語で合意された名前を割り当てるだけで十分です。その後、プロパティは任意の各国語で名前を付けることができ、識別は影響を受けません。



このプログラムには、小さな条件付き—条件付きで強調する—の例が付属しています。 これは、鉱石が採掘されている採石場から、鉱石から金属が製錬される加工工場、金属製品をプレスする工場、最終的なアウトレット、ショップまでの動きを追跡するために使用できます。 契約の文脈で物事を考慮し、財務結果を計算する方法が示されています。



会計ロジックで上記の（一般的に言えば、標準会計）機能を実装することの難しさは何ですか？ プログラムが普遍的であるという事実-会計コンストラクタ-したがって、契約と財務結果を担当する必須フィールドは提供されていません。 ユーザーは、必要なフィールド（会計学の言語、物事またはアクションのプロパティ）を入力して、アカウントを独立して整理する必要があります。



モノで実行されるアクションは、契約に関連する場合もあれば、契約に関連しない場合もあります。 最も一般的な販売契約は、例で考慮されます。



財務結果（利益または損失）を修正するために、売り手は物価を販売価格で再評価します。たとえば、物価は非常に高く（コスト）、物価は非常に高くなります（販売価格）。 これらの金額の差は、純損益を表します。 財務結果を他の売上高から分離するために、新しいプロパティを作成し（名前、明確、すべて同じです：記事のコスト、収益、コスト、またはその他の例では、意図的に異なる名前を使用します）、それを示して示します：財務結果。



物は販売価格で評価されるようになりました。買い手にそれを転送したり、買い手からの前払いを受け入れることができます。主なことは、カウンターパーティとの計算を反映する値を対応するプロパティに示すことを忘れないことです 計算：計算。



正しい設定を使用すると、決済のステータスと、契約のコンテキストでの財務結果を取得できます。







ここに示されているのは、契約番号5のステータスです。利益は88千ルーブル、ゼロの設定点での相互決済（売上高は20万ルーブル）に達しました。 また、ゼロではなかったとしても、上記の指標により、単純な比較を使用して、任意の方法で利益を計算することができます（現金法や発生法などのよく知られた会計上の問題を意味します）。



アカウンティングはユニバーサル機能を使用して実装されます：契約ごとに費用を分解した収入を考慮に入れることができ、逆もまた同様です。契約を収入/費用で分解し、追加のプロパティを入力します-プロパティのシーケンス（レポートフォルダーに反映される）は重要ではありません。 これは普遍性の好ましい側面であり、不快な側面はプログラムをカスタマイズする必要があることです。これは、その機能とアーキテクチャを完全に理解している場合にのみ可能です。



ただし、ユーザーはアカウンティングデータベースに新しいデータを入力するだけでなく、残されたアイテムのデータベースを消去する必要があります（昨日は夕食時にニシンを食べる、1か月前にナイトスタンドをゴミ箱に移動した、妻と妻が新しいブラウスを購入した、など）など）。



このプロジェクトの最終目標は、会計ロジックを支払いシステムに統合することです。これにより、製造業者と売り手は、ユーザーが購入した商品に関する情報を個人の会計データベースに直接送信します。 そうすれば、会計学的手法の利点は誰にでも明らかであることがわかります。



こちらから Accounting Logic 2.0をダウンロードしてください 。 システム要件は変更されていません。32ビットのMicrosoft Officeが必要です。 64ビットWindowsの場合、Microsoft Access Database Engine 2010（32ビット）をインストールする必要があります。 私が理解しているように、64ビットのWindowsとMicrosoft Officeで作業することは不可能です。この不幸をどうするかわかりません。



例はDataBase_Examplesフォルダーにあります;接続するには、バックアップコピーを（アーカイブコマンドから）復元する必要があります。 指定したフォルダーには、契約と為替レートの2つのAccessテストベースも含まれています。 それらの最初は参照の形式で接続でき、2番目は為替レートの差を計算するときに必要なベースとして接続できます。



私のプログラミングの経験は1年強で、その意味を理解しています。 （未熟な人のために、私は説明します：最初のバグのあるバージョンの多くのエラーを修正しましたが、これは新しいものを植えることができなかったという意味ではありません）。 同時に、方法論者としての私の経験は四半世紀です。言い換えれば、私はプログラムコードに実装された会計方法論ほど責任を負いません。



大多数の人を納得させることができるかどうかは問題ではありません。 誰が聞きたいですか。