Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transactions entry_date is not the actual transaction date #43

Open
cdhannes opened this issue Jan 7, 2020 · 3 comments
Open

transactions entry_date is not the actual transaction date #43

cdhannes opened this issue Jan 7, 2020 · 3 comments

Comments

@cdhannes
Copy link

cdhannes commented Jan 7, 2020

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
Copy link
Contributor

bumi commented Jan 7, 2020

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

@cdhannes
Copy link
Author

cdhannes commented Jan 7, 2020

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
Copy link
Contributor

bumi commented Jan 7, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants