substancelab/rconomic

Ruby wrapper for the e-conomic API - thankfully, integrating with e-conomic doesn't have to suck

rconomic's Issues

cashbooks.all.last not loading properties correctly

Failing test case:

economic = Economic::Session.new(<account>, <login>, <password>)
economic.connect

cb1 = economic.cash_books.all.last
cb2 = economic.cash_books.find({:number => cb1.number})

assert cb1.handle[:number] == cb2.handle[:number]    # FAILS, cb1.handle[:number] is nil

I'm not sure how to run the gem's tests againsts a live economic account, but if you could guide me (just call me on skype) i would be happy to supply test + solution as a pull request.

Persist multiple CashBookEntries

I'm trying to create severalt Economic::CashBookEntry and append them to Economic::CashBook entries

I can't find a way to persist them all at the same time.

cash_book = economic.cash_books.find(number: 1)
entry = Economic::CashBookEntry.new
entry.text = 'Random'
entry.amount = 100
entry.date = Time.now
cash_book.entries << entry

Latest version

Is there any reason the latest version is from march 2014?
It seems to be very inconsistent with the readme

Add X-EconomicAppIdentifier header to Savon client init

Since 16.11.2015 e-conomic require a X-EconomicAppIdentifier header to be set.
Currently the rconomic gem does not support this header which needs to be fixed.

Handle is (potentially) not up to date after creating a DebtorContact

When you create a DebtorContact through the E-Conomic API, it is not possible to either set or predict the the next ID for a contact. This means that a contact is created by setting the ID to 0 as described in lib/economic/debtor_contact.rb, where E-Conomic will assign an ID to the response.

The problem is that the ID of the handle of the DebtorContact is not updated after the DebtorContact has been created. This means that when you try to create an invoice and sets the attention to a DebtorContact that you have just created, the request will fail, because E-Conomic can't find the newly created contact (if the handle ID is 0). This happens if the handle method is called, when the DebtorContact is being build, which will result in the Handle being memoized with an outdated ID.

Dependabot can't resolve your Ruby dependency files

Dependabot can't resolve your Ruby dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Bundler::GemNotFound with message: Could not find nokogiri-1.11.0-arm64-darwin in any of the sources

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

X-EconomicAppIdentifier header

According to http://techtalk.e-conomic.com/e-conomic-soap-api-now-requires-you-to-specify-a-custom-x-economicappidentifier-header/ e-conomic is now requiring a custom header for API users.

From what I can see, we would have to modify Econonmic::Endpoint#client to set this header.

Has anyone run into trouble with this or is there another way to add the header or do a workaround that I'm missing?

License missing from gemspec

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

  spec.license = 'MIT'
  # or
  spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

Support for CashBook_RegisterPdfVoucher

Our application needs to be able to associate PDFs with the vouchers we create via the cash book, so I will be putting together a pull request to support the CashBook_RegisterPdfVoucher operation.

Any suggestions/preferences as to the API rconomic should expose before I get started?

Time to XML gets wrong format with newest Gyoku

Heads up - if you update/install rconomic and get the dependency gyoko at a version larger than 0.4.4, things will break.

Savon 0.9.5 (which rconomic is tied to) allows its gyoko dependency to update from 0.4.4 to 0.4.6.

gyoko no longer converts rconomic's Time objects to the format that rconomic assumes and that e-conomic expects. You need DateTimes. E.g. my_time.to_datetime is enough to fix it.

Also, they removed lower_camelcase which makes rconomic's version of savon_spec unhappy.

I think the best course of action for now is to tie down the gyoku version, since Savon didn't. (And gyoko shouldn't have made backwards-incompatible changes in patch versions.)

At some later point, all of Savon can be updated and the gyoko version can be untied. Newer versions of Savon tie down the gyoku version tighter.

Support for accruals (periodisation) for cash book entries

I want to add support for accruals/periodisation on cash book entries.

From what I can see, there are two options for supporting this, and I'd love to get some feedback on what would be the preferred way to add it.

One option would be to add support for accruals to CashBookEntryProxy#create_cash_book_entry_for_handles so that it's supported at creation time. It looks like we'd need to support an optional handle for the capitalisation account.

Another option would be to add direct support for updating the cash book entries using CashBookEntry_SetAccrualInformation, as has been done with CashBookEntryProxy#set_due_date.

Any preferences as to which way to go? Or is there another option I haven't considered above?

"You need to include an X-EconomicAppIdentifier header when not connecting with the Token Based model."

This is a placeholder for me.

I've been running fef7498 which includes #42 in production on a monthly batch job for quite some time with no problems.

This month it failed during connect with the error that is the title of this message.

Adding extended logging shows that it's when rconomic tries to establish a session, and it indeed does not look like the header is set/sent on the connect operation.

Perhaps before, connect was allowed without the header, and the api only checked the header for each "real" operation?

Or could it be that they only just now started enforcing the new requirement even though AFAIK the documented deadline is long passed and #42 never worked?

Not sure, but need to investigate our app more and possibly contact e-conomic support. Or possibly, just switch to token authentication - not sure if any other users of this library use the old way...

creating creditors

Does not work as documented. The helper function produces an error.

creditor.number = economic.creditors.next_available_number

There appears to be no function corresponding to this for creditors, not even in the SOAP API. I've written to e-conomics for a clarification.

The best work-around I can think of is currently to "get all" and find the last, highest creditor number. Or wait (gasp!) until e-conomics implements said get_next_available_number.

Otherwise, creating a creditor works, as long as you provide an unused number.

Strangely, 'creditor.save' no longer works if you go into the GUI, and delete the creditor you just created via 'creditor.save'.

Savon version locked to 0.9.5

Would it be possible to relax the Savon dependency to allow for newer versions of Savon as well?

Exception thrown when trying to find single debtor by ID

There is an exception thrown when trying to find single debtor by ID using the "economic.debtors.find(17)" method.

Savon::SOAPFault at /somefile
(soap:Client) Economic.Api.Exceptions.IntegrityException(E06000): The following entities does not exist: 17 (id=80153aee-36bd-415d-9e00-82530bb81d7a)

I think this started to appear in the past week or two. Before it was just returning nil and then I create a new debtor, if there is no debtor with that specific ID.