Classifying transactions.

[SamMousa]

There are several transaction types that can be identified for all accounts regardless of bank.
It would be good to add that type to make handling of the transaction easier.
(Currently I would have to parse the bank specific transaction code, which I do not want to know about).

Currently I have identified the following types:

    const SEPA_TRANSFER = 10;
    const SEPA_DIRECTDEBIT = 20;
    const BANK_COSTS = 30;
    const BANK_INTEREST = 31;
    const ATM_WITHDRAWAL = 40;
    const PAYMENT_TERMINAL = 50;
    const UNKNOWN = 99;

These are already in my fork (https://github.com/SamMousa/php-mt940/tree/feature-interfaces-2), however I have made some design decisions that you might not agree with / need to be discussed.

1. I have included a ValueObjects library.
2. I have added more to the interfaces.

If you are interested in adopting these changes, it might be wise to create a new develop branch.

I will be actively developing this library regardless, the downside is I will probably not have time to upgrade all parsers or properly update all tests.

Let me know how / if you think we could best work together!

[fruitl00p]

I like the idea of giving the transactions a defined set of types... However we must have to allow some sort of local processing... I don't believe that the package itself would hold all truths and thus must allow for the local developer actually working with a file to override / ignore / alter the given transaction type as 'guessed' by the package... ?

[SamMousa]

We could always add setters as well as getters for the transaction type.

[fruitl00p]

Been AFK for a while and just starting to get back to this... I still like the idea of types for the transactions, but from the current docs the different banks have many different transaction types already... (20+ differences with over 30+ shared, thus 50-ish types?) seems like overkill...

Any thoughts on how to reconcile this into a coherent solution?

(+1 on the interfaces though...!)

[SamMousa]

We could categorize them, most transaction types are likely to fall into
one specific category regardless of bank. Especially the standardized
things like sepa transfers.

On Aug 17, 2016 11:26, "Robin Speekenbrink" notifications@github.com
wrote:

Been AFK for a while and just starting to get back to this... I still like
the idea of types for the transactions, but from the current docs the
different banks have many different transaction types already... (20+
differences with over 30+ shared, thus 50-ish types?) seems like
overkill...

Any thoughts on how to reconcile this into a coherent solution?

(+1 on the interfaces though...!)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhYzTUvjMKmGQ3iWR8pfDqqhJ8ytSKMks5qguG_gaJpZM4G83tc
.

[fruitl00p]

After reconsideration, if you could separate the introduction of the interface definitions as a seperate PR from the IBAN and Type additions, this would make the change easier to handle.

Again, i like the additions of the interfaces and the introduction of the IBAN and Type stuff, but that seems a separate issue . (also since the IBAN stuff would make it a requirement where this might not necessarily be so outside of the EU / internationally... right?)

[SamMousa]

@fruitl00p Sorry, I'm no longer working on this or projects using this. Feel free to cherry-pick changes you like or close this issue if you're not up for that :)