transactions entry_date is not the actual transaction date

[cdhannes]

I actually don't know if our source file is valid, but we have a file (real file, coming from a bank) that has opening_date and closing_date set at 2019/12/30, but one transaction with an individual date of 2019/12/31.

The whole case shouldn't be possible, but in this case the cmxl's parsed "entry_date" is "1230" and the "date" field is "191231" - which is the correct date. Not only is the entry_date field wrong (I guess it's taking it's value from the global opening/closing dates) but it also misses the year.

For now, is it safe to use "date" instead of "entry_date"?

[bumi]

can you provide some example code that shows what you're trying to do and example statement?

[cdhannes]

Hi @bumi

This is our code:

    statements = Cmxl.parse(open(file.expiring_url).read) # , encoding: 'UTF-8'
    statement = statements.first

    if save
      statement.transactions.each do |transaction|
        new_transaction = BankTransaction.new(
          ...
          entry_date: transaction.entry_date,
          ...
        )
        increment!(:transactions_processed_count) if new_transaction.save
      end

and this is the file:

:20:STARTUMSE
:25:xxxx0000/00000xxxxx
:28C:000xx/001
:60F:C191230EUR000000xxxxxx,xx
:61:1912301230CR000000000xxx,xxNMSCNONREF//xxxxxxxx
:86:166?00xxxxxxxxxx
:61:1912311230DR000000000xxx,xxNMSCNONREF
:86:805?00xxxxxxxxxx
1,90S?3061030000?310000052930
:62F:C191230EUR000000xxxxxx,xx

This is the parsed data for the second transaction:

 @match=
  #<MatchData
   "1912311230DR000000000xxx,xxNMSCNONREF"
   date:"191231"
   entry_date:"1230"

[bumi]

the transaction is from 30.12.2019 but the actual value booking happened on 31.12.2019
Valuta (date) vs. Buchungsdatum (entry_date)

so that should be fine, isn't it?

[janz93]

@cdhannes we are doing some early spring cleaning 🌷 🧹

is this issue still relevant?

[dahennessy]

Issue can be closed, thank you!