Introduce invoice_type #8
Conversation
Akise17
force-pushed
the
feature/make_type_code_configurable
branch
from
7b88e50 to
27170b7
Compare
Akise17
force-pushed
the
feature/make_type_code_configurable
branch
from
27170b7 to
750ae96
Compare
Akise17
force-pushed
the
feature/make_type_code_configurable
branch
from
650a47f to
25f4433
Compare
Akise17
force-pushed
the
feature/make_type_code_configurable
branch
from
25f4433 to
c003d7a
Compare
lib/secretariat/invoice.rb
Outdated
| xml['ram'].TypeCode payment_code | ||
| xml['ram'].Information payment_text | ||
| if payment_iban | ||
| xml['ram'].Information payment_text if payment_text && payment_text != '' |
There was a problem hiding this comment.
| xml['ram'].Information payment_text if payment_text && payment_text != '' | |
| xml['ram'].Information payment_text if payment_text.present? |
There was a problem hiding this comment.
it's pretty easy to just copy over those methods from rails, please check my PR: https://github.com/fortytools/ruby-secretariat/pull/9/files
introduce blank? and present? method to make checking for blank values easier
| trade_settlement = by_version(version, 'ApplicableSupplyChainTradeSettlement', 'ApplicableHeaderTradeSettlement') | ||
| xml['ram'].send(trade_settlement) do | ||
| if payment_reference && payment_reference != '' | ||
| if payment_reference.present? |
There was a problem hiding this comment.
present? is a method from Rails and the gem does not depend on Rails, so shouldnt introduce that dependency here. In our context it probably works but we should keep this upstream compatable.
See also comment on object extensions below.
| @@ -0,0 +1,14 @@ | |||
| module Secretariat | |||
| module ObjectExtensions | |||
There was a problem hiding this comment.
Not sure if we should do this because the upstream maintainer of the gem seems to like to stick to != ''
There was a problem hiding this comment.
IMHO it's a better approach than !='', I create a RP for the gem to adapt this approach.
In worst case if the PR were rejected we can keep this approach for our fork and mind that when merging upstream changes to our fork
No description provided.