You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The same result as running the query above without date_macro, which defaults to 'This Fiscal Year-to-date', both on the quickbooks-ruby side and the Quickbooks API side.
Expected:
A report that only includes months from the last fiscal quarter, with columns summarized by month.
Proposed solution:
Looking at url_for_query in quickbooks-ruby/lib/quickbooks/service/reports.rb (https://github.com/ruckus/quickbooks-ruby/blob/master/lib/quickbooks/service/reports.rb), it appears that date_macro simply gets dropped when options are provided.
Changing the returned string to "#{url_for_base}/reports/#{which_report}?date_macro=#{URI.encode_www_form_component(date_macro)}&#{options_string}" yields the expected response, respecting both date_macro and options.
I'm unsure about what your preference w/r/t pull requests is. If the above looks good and I haven't missed anything, I'd be happy to open one :)
The text was updated successfully, but these errors were encountered:
Steps to reproduce:
Quickbooks::Service::Reports.new(company_id: <some_realm_id>, access_token: <some_access_token>).query('ProfitAndLoss', 'Last Fiscal Quarter', summarize_column_by: 'Month')
Result:
The same result as running the query above without
date_macro
, which defaults to 'This Fiscal Year-to-date', both on the quickbooks-ruby side and the Quickbooks API side.Expected:
A report that only includes months from the last fiscal quarter, with columns summarized by month.
Proposed solution:
Looking at
url_for_query
inquickbooks-ruby/lib/quickbooks/service/reports.rb
(https://github.com/ruckus/quickbooks-ruby/blob/master/lib/quickbooks/service/reports.rb), it appears thatdate_macro
simply gets dropped whenoptions
are provided.Changing the returned string to
"#{url_for_base}/reports/#{which_report}?date_macro=#{URI.encode_www_form_component(date_macro)}&#{options_string}"
yields the expected response, respecting bothdate_macro
andoptions
.I'm unsure about what your preference w/r/t pull requests is. If the above looks good and I haven't missed anything, I'd be happy to open one :)
The text was updated successfully, but these errors were encountered: