entries, credit amounts, debit amounts failing without associated id

78 views
Skip to first unread message

Brian Rossetti

unread,
Mar 19, 2015, 2:43:12 AM3/19/15
to plutu...@googlegroups.com
I ran into an issue today that i was hoping you might be able to take a look at, I am trying to create entries, but the entry error responds with @messages={:credit_amounts=>["is invalid"], :debit_amounts=>["is invalid"]}> and the debit/credit amounts respond with an error of  @messages={:entry=>["can't be blank"]}>. I am following the below order of operations:

ro = Organization.first
r= o.relationships[3]
rr= o.relationships[5]
acct = o.accounts[3]
accct = o.accounts[5]

debit_amount = rr.debit_amounts.new(amount: 1000, account: acct)
credit_amount = r.credit_amounts.new(amount: 1000, account: accct)

entry = o.entries.build(description: "testentry")
entry.debit_amounts << debit_amount
entry.credit_amounts << credit_amount
entry.save

if I am breaking the plutus setup by adding Relationships and Organizations, i was thinking maybe i can override these validations in the engine with a callback to allow one or the other to be created first, but i feel like that might be dangerous and cause issues with legitimate double entry practices? just a thought

can you provide any insight into why i might be getting this error, i dont see a way to create the entry without attaching the credit and debit amounts and the debit and credit amounts wont save until they have an entry associated with them, its a vicious circle :)

thanks for any assistance you can provide.

Brian
Message has been deleted
Message has been deleted
Message has been deleted

Brian Rossetti

unread,
Mar 19, 2015, 9:12:34 AM3/19/15
to plutu...@googlegroups.com
here is kind of what I am going for on my decorator:

Plutus::Amount.class_eval do
    belongs_to :relationship
    around_create :check_for_entry_id!

     _validators[:entry]
          .find { |v| v.is_a? ActiveRecord::Validations::PresenceValidator }
          .attributes
          .delete(:entry)

      def check_for_entry_id!
          self.destroy unless self.entry_id
      end
end

when I am in the console, the  AmountObject._validators[:entry].find { |v| v.is_a? ActiveRecord::Validations::PresenceValidator }.attributes.delete(:entry).delete(:entry) works on the instance of the Amount object, but I cant get it to work on the model level to cancel out the validation. any thoughts?

i know this is not what plutus was intended for and you dont deal with this very often, so I appreciate it that your taking the time to look at it, no worries if your unfamiliar with implementations like this. Also, I am not very comfortable with Concerns yet which is why I am using the eval. thanks again!

Brian

mbulat

unread,
Mar 19, 2015, 11:32:34 AM3/19/15
to plutu...@googlegroups.com
Well just taking a stab at it, can you get an entry to save using the basic build syntax described in the readme? If so, perhaps you can then assign the relationship after the entry has saved. So something like:

entry = Plutus::Entry.build(
                :description => "testentry",
                :debits => [
                  {:account => acct.name, :amount => 1000.00}],
                :credits => [
                  {:account => accct.name, :amount => 1000.00}])
entry.save

entry.debit_amounts[0].relationship = rr
entry.debit_amounts[0].save

entry.credit_amounts[0].relationship = r
entry.credit_amounts[0].save

My only guess is that there are some circular validations going on. If that doesn't work, then my only suggestion would be to try forking plutus on github. You could then add in all the relationships directly, and try to get them working via the test suite without dealing with any potential complications from engine overloading code. It might be easier to figure out what's causing the issue that way. And once it's working that way, you could either just bundle the fork from github into your app, or try porting the changes via the engine overload methoda.

Brian Rossetti

unread,
Mar 19, 2015, 1:51:45 PM3/19/15
to plutu...@googlegroups.com
thanks for the response, yeah, you are right, the associations are breaking the entry method, i am going to try to override it via the engine or subclass Entry. thanks again for your quick response, ill post back here if i find a solution to my situation.
Reply all
Reply to author
Forward
0 new messages