ING sanitizeDescription update

[MrMoronIV]

The description of the ING transactions hold more information which is discarded by this parser. For example Direct Debet (automatische incasso) transactions have their desscription next to the PREF identifier. Below is a function that adds this information to the description. Feel free to implement/rewrite this or do nothing with it ;)

    /**
     * Overloaded: ING encapsulates the description with /REMI/ for SEPA.
     *
     * {@inheritdoc}
     */
    protected function sanitizeDescription($string)
    {
        $description = parent::sanitizeDescription($string);
        if (strpos($description, '/PREF/') !== false
                && preg_match('#/PREF/(.*?)/#s', $description, $results) && !empty($results[1])
        ) {
            $description_start = $results[1];
        }
        if (strpos($description, '/EREF/') !== false
                && preg_match('#/EREF/(.*?)/#s', $description, $results) && !empty($results[1])
        ) {
            $description_start = $results[1];
        }
        if (strpos($description, '/REMI/USTD//') !== false
                && preg_match('#/REMI/USTD//(.*?)/$#s', $description, $results) && !empty($results[1])
        ) {
            $description_end = $results[1];
        }
        if (strpos($description, '/REMI/STRD/CUR/') !== false
                && preg_match('#/REMI/STRD/CUR/(.*?)/#s', $description, $results) && !empty($results[1])
        ) {
            $description_end = $results[1];
        }

        return $description_start.' '.$description_end;
    }

[fruitl00p]

@MrMoronIV Do you have a certain test to prove that it works like this? I currently created a branch with this change and have added a trim()-call to the return statement as not to return ' ' as that would possibly be silly :)

I personally don't have any (modern) ING statements nor spec to validate this with (other than the already present ING spec)

[MrMoronIV]

I've just encountered this while importing a recent ING bank export with various types of statements . There was information missing that I needed, hence this code I came up with. So this is by no means a complete implementation driven by specs but merely a working piece of code from "the fields".

In other news, the camt export type is probably an easier one to work with for people since the bank actually provides the desired information in fixed fields instead of in this mt940 mess (who even came up with this standard :/).

[fruitl00p]

CAMT is another one of the various standards some of the banks employ... But then again, remember the famous XKCD It will always be sometype of mess :)

Could you verify my patch still works with your sample? This atleast trim-s the output to prevent " "-descriptions and doesn't seem to break any (current) tests...

[MrMoronIV]

I moved away from the mt940 format for now in favor of the camt type. However, I've been over your code and it looks good, I don't think you've changed any of my provided regular expressions which are the key in making this work.

Here's the line that made me create my patch (I've changed the actual information):
Note the padded number, this is how the bank actually delivers it.

:61:1902050205C42312,95NDDTPREF//432423423122
/TRCD/01010/
:86:/PREF/Direct Debet Descr//CSID/NL74ZZZ133333080000//REMI/USTD//TOT
AAL        345 POSTEN/

This should return:

Direct Debet Descr TOTAAL        345 POSTEN

as its description

[fruitl00p]

I'll add that as a test to make sure it will keep working in the future ;)

This also brought to light a seemingly error in the regex where the delimiter is included but shouldn't have been. I've updated the branch to match