2

私は実際にアカウンティングRailsアプリケーションを開発しようとしていますが、ロジックに固執しています...

実際、私は「汚い」借方/貸方を自動化しようとしているユーザーの生活を簡素化したいと思っています。

私のフォームにこれらのフィールドがあるとしましょう：

  1. 日付（xxxx）
  2. 銀行口座（口座1）
  3. 経費カテゴリ（アカウント2）
  4. 金額（1000）

会計の世界では、これは次のようなジャーナルの1行に対応します。

  1. 日付：xxxx借方：account2貸方：account1金額：1000

しかし、このロジックを使用すると、計算とレポートはRailsでは悪夢になります...

それから私の考えはそれを次のように2つのリグに分割することです：

  1. 日付：xxxxアカウント：account2金額：1000
  2. 日付：xxxxアカウント：account1金額：-1000

それは意味がありますか？はいの場合、私が見つけた唯一の方法は、JavaScriptコードで更新されたフォームに非表示のフィールドを作成し、レコードを保存することです（私の好みには少し厄介に聞こえます:)）

「ゴーストフィールド」手法を使用せずに、データベースに2つのレコードを生成するために、コントローラーでそれを処理する方法はありますか？

VATロジックを追加することを想像すると、問題はさらに複雑になります...同じ例ですが、たとえば、操作に80のVATが含まれています...

  1. 日付：xxxx
  2. 銀行口座：口座1
  3. 経費カテゴリ：アカウント2
  4. 金額（付加価値税込み）：1000
  5. VATアカウント：アカウント3
  6. 付加価値税額：80

会計の世界日報では、次のようになります。

  1. 日付：xxxx借方：account2貸方：account1金額：1000
  2. 日付：xxxx借方：account3貸方：account1金額：80

データベース内：

1.日付：xxxxアカウント：account2金額：1000

2.日付：xxxxアカウント：account1金額：-1000

3。日付：xxxxアカウント：account3金額：80

4.日付：xxxxアカウント：account1金額：-80

つまり、「ゴーストフィールド」手法では、4本の隠線などを作成する必要があります...

これを行うためのより良い方法はありますか？

どうもありがとうございました。

ダン

4

5 に答える 5

3

コントローラーではなく、コールバックを使用してモデルに追加のレコードを作成する必要があります。

class Journal
  # ...

  after_create :update_individual_accounts

  def update_individual_accounts
    debited_account.create_accounting_entry_with self
    credited_account.create_accounting_entry_with self
  end
end

これで、新しいレコードを追加するたびに、対応する取引先にJournal2 つのレコードも作成AccountingEntryされます。

于 2012-02-03T13:48:51.080 に答える
0

こんにちはみんな、あなたの助けに感謝します。

私はついにあなたの様々な投稿からのインスピレーションを使ってこれを解決する方法を見つけました。

私が行ったことは、次のようなafter_createアクションを処理するためにモデルレベルでいくつかのコードを追加したことです。

after_create：journalize

次に、次のような別の定義で：journalizeアクションを定義しました。

def journalize Ligne.create（{作成するさまざまなデータを使用}）end

だから、あなたの助けにもう一度感謝します。ピースダン

于 2012-02-25T09:35:33.883 に答える
0

会計台帳のこの宝石に出くわしました: https://github.com/mbulat/plutus

readme から:

plutus プラグインは、あらゆる Ruby on Rails アプリケーションで使用できる完全な複式簿記システムを提供します。プラグインは、一般的な複式簿記の慣行に従います。浮動小数点の丸めエラーを防ぐために、すべての計算は BigDecimal を使用して行われます。プラグインには、データベースにも小数型が必要です。

このシステムは、アカウント、トランザクション、借方と貸方を管理するテーブルで構成されています。各トランザクションには、多数の借方と貸方が含まれる場合があります。ビジネス トランザクションを記録するトランザクション テーブルは、本質的には会計仕訳帳です。

アカウントはそのクレジットまたはデビット トランザクションに対して逆の has_many 関係を持っているため、元帳への転記は自動的に行われると見なすことができます。

于 2012-05-19T03:48:59.413 に答える
0

これは、DCI パターンにうまく適合する可能性があります。つまり、Accountant ロールが経費をジャーナルに追加する AddToJournal コンテキストを作成できるということです。このようにして、簡単にテストできるロジックを 1 か所に配置できます。

DCI は Rails の世界ではまったく新しい概念であるため、実装方法に関する規則はありませんが、この記事で取り上げられているアプローチがとても気に入っています: http://mikepackdev.com/blog_posts/24-the-right-way -to-code-dci-in-ruby

于 2012-02-03T13:56:08.453 に答える
0

account1(借方金額)からaccount1(貸方金額)への金額の振替を行っています。account_frmこれは、フィールドを収集する標準フォームを使用して行うことができますaccount_to& amount。コード内では、account_frm と account_to のアカウント オブジェクトを読み込み、送金した後、ジャーナル エントリを作成します。

= form_tag amount_transfer_url do
  = f.select :account_frm
  = f.select :accoutn_to
  = f.text_field :amount

class AccountsController < ..
 def transfer
  account1, account2 = Account.find_all_by_id(params[:account_frm], params[:accpunt_to])
  account1.transfer(params[:amount], account2)
 end
end

class Account < ..
 def transfer(accnt2, amt)
   # here self is account1
   # make journal entries after successfull transfer
 end
end
于 2012-02-03T14:00:03.480 に答える