Comments (9)
puh, autsch... thanks for reporting this! that's a bad.
need to wrap my head around it. (also ping @Uepsilon )
from cmxl.
and thanks a lot for reporting and the great issue and analysis.
from cmxl.
hey @hapm, do you found this when dealing with real world data? if so, could you provide an example please?
clarifying start: the provided date is formated as follows:
- 6digits date (aka valuta) (mandatory)
- 4digits entry date (opt)
during research i found some banks providing examples having the date (valuta) before the entry_date whilest others have it the other way around. this seems inconsistent. since I'd assume the valuta is the date the transaction should be considered completed while the entry date is the date the transaction was placed. so the only logical way for me is, that the valuta can be equal OR later than the entry date, not the other way around.
201902010101
is possible while 201902010202
is not.
also, if we think that it's indeed possible to plan transactions for the upcoming year, we might not even know what the entry date's year was at all when provided with 4 digits only. so we can only guess that it was the same year OR the year before if the valuta is somewhere near january. but that is a guess too.
your first example is not touched by any of the code as it happens in february. for the second line, i'd suggest not to check if the entry_date's month is bigger but to be precisely december. but then again, date is completely optional and not provided by a lot of banks at all.
from cmxl.
Thanks for pointing out the bad example, I messed that up by copying the wrong line. I edited the example above, so it matches the real data I got from the bank with confidential information removed. My guess of why the (german) bank is booking it like this, is to make sure that the monthly interest is booked after the month is closed (therefor entry_date = first day of next month), but the interest it self belongs to the month (therefor date = last day of month the interest ist calculated for).
I tried to find a limitation in the specs, that permits or disallows that kind of statement to no avail. The only thing I could find was this:
The SWIFT System validates subfield 2, Entry Date (Date in reduced ISO form), using current System Year (Error code(s): T50).
To be honest I didn't search very much for what is meant with System Year
in this context, but the only reasonable conclusion I could come up with, was that the entry_date
should always be between the dates of field 60a
and 62a
. Sadly I couldn't find a rule like that in the specs either.
To workaround this issue, I will directly access Statement.data['entry_date']
for now, and get the year based on this rule.
from cmxl.
We experienced the same issue at the start of February, in our case there was a line like:
:61:1901300201D1,00NCOMNONREF//XXXXXXXXX
during research i found some banks providing examples having the date (valuta) before the entry_date whilest others have it the other way around. this seems inconsistent. since I'd assume the valuta is the date the transaction should be considered completed while the entry date is the date the transaction was placed. so the only logical way for me is, that the valuta can be equal OR later than the entry date, not the other way around.
This seems totally logical to me, but apparently not to the bank 🙃
The fix suggested by @hapm makes sense to me, I'd phrase it as: the algorithm for choosing the entry dates year should minimize the difference between the two dates.
from cmxl.
61:1901300201D1,00NCOMNONREF//XXXXXXXXX
this line would not be affected by any change after all, as it would be
valuta: 2019-01-30
entry_date: 2019-02-01
in any case, right?
from cmxl.
Without any change the entry_date would be parsed as '2018-02-01', because
date.month == 1 && date.month < to_date(self.data['entry_date'], self.date.year).month
evaluates to true
. With the given pull request this would be fixed. As there is no limit of the date field in the specs, I assume the given transaction could still be in a statement of 2020, and should therefor be booked in 2020 but valued in 2019. This doesn't have a real use case but I can't find anything against that in the specs.
from cmxl.
Without any change the entry_date would be parsed as '2018-02-01',
oops, true..
yeah, since the specs are unprecise about this, i'd rather ignore entry_date at all. if you need them for historical reasons (to check if you have processed that transaction already) it should make no difference as long as the resuling date after parsing is always the same.
but it's not really suitable for deciding when the booking was done
from cmxl.
fixed by #32
from cmxl.
Related Issues (20)
- release new version on rubygems? HOT 1
- support for Mt942 fields HOT 1
- Support for RC and RD in :61: funds_code HOT 3
- Chargeback transfers fail to be parsed HOT 4
- processing problem HOT 8
- Lines with non-digit tags should be parsed too. HOT 6
- Tag 86 at the end does not get parsed HOT 2
- Line break within transaction, colon right after newline HOT 7
- Negative Debit HOT 7
- Statement Field generation_date NoMethodError: undefined method `date' for nil:NilClass HOT 3
- Question/Discussion: Use of sha value for transactions HOT 10
- Field 61: Statement Line cannot parse transactions of type 'S' HOT 2
- transactions entry_date is not the actual transaction date HOT 3
- Unencrypted secret in codebase HOT 1
- chore: Enable Semaphore CI runs for tests HOT 2
- Deprecated Warning: Using the last argument as keyword parameters is deprecated HOT 2
- Statement and sequence numbers aren't correctly parsed when without filling 0 digits HOT 2
- rchardet19 upgrade
- rchardet19 dependency breaks under ruby 3.3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cmxl.