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

Knab transactions #90

Open
StonehengeCreations opened this issue Dec 13, 2022 · 3 comments
Open

Knab transactions #90

StonehengeCreations opened this issue Dec 13, 2022 · 3 comments

Comments

@StonehengeCreations
Copy link

StonehengeCreations commented Dec 13, 2022

I am testing this package out by importing my Knab Mt940 statements.
All incoming funds (customers paying their invoice) are being marked as Credit ('C'), while my own payments, such as my phone bill, are being marked as Debit ('D').
Should this not be the other way around?

@StonehengeCreations
Copy link
Author

Looking at the code in Engine.php parseTransactionDebitCredit() it looks like transaction type is searching for D or C. Knab does not use that, so I figured that the transaction code would probably be leading. By manually comparing the transaction code with the transaction information I noticed that this is indeed the case.

Because I own a small business I realise that the list of codes below is incomplete, but for now I have added this method to the Knab class and it seems to work properly.

protected function parseTransactionDebitCredit() {
   $code = (int) parent::parseTransactionCode();

  static $map = array(
    100 => 'C', // Type::SEPA_TRANSFER => Paid
    110 => 'D', // Type::SEPA_TRANSFER => Received			
    131 => 'C', // Type::SEPA_DIRECTDEBIT (First of) 
    132 => 'C', // Type::SEPA_DIRECTDEBIT (Continued)
    200 => 'C',	// IDEAL PAYMENT	
    300 => 'C', // Type::PAYMENT_TERMINAL
    401 => 'C', // Type::BANK_COSTS
  );

  if( array_key_exists( $code, $map ) ) {
    return $this->sanitizeDebitCredit( $map[$code] );
  }
 
  throw new \RuntimeException( "Transaction code $code is unknown for this bank." );
}

@fruitl00p
Copy link
Owner

Thats strange indeed. Have you tested this with the available samples as part of the package? This seems to have been working for other users?

Has KNAB changed their spec?

@StonehengeCreations
Copy link
Author

I do not know if Knab have changed their specs, because they seem to have no documentation for their mt940 files, other than how to generate them. I could not find any documentation about their transaction codes either.

I have not used the test packages - I am testing with my own real data exported from my Knab Dashboard.

Aside from the Debit/Credit, I ran into some other inconsistencies while testing:

  1. If the Account Name is followed by 'CSID', the accountName will result in this: "SIMPEL NL BV/CSID/NL15 ZZZ 603163060001/MARF/S694513380201712281420", because it matches the first check in parseTransactionAccountName and therefore never gets to line 120. I have altered the first check to #/NAME/(.*?)/(EREF|REMI|ADDR|CISD)/#ms.

  2. If the BIC happens to end with XXX the accountName will be blank: :86:/TRTP/SEPA OVERBOEKING/IBAN/NL21KNAB[xxxxxxxx]/BIC/KNABNL2HXXX/NAME/[my name]

  3. This also then applies to the transactionDescription, because the $name in parseTransactionDescription will be empty. So then the description is then: /TRTP/SEPA OVERBOEKING/IBAN/NL21KNAB[xxxxxxxx]/BIC/KNABNL2HXXX/NAME/[my name]

  4. Knab Savings Accounts as well Bank Costs are only 8 digits and are marked as BBAN instead of IBAN, because they are for internal use only. The sanitizeAccount adds a 'P', thinking that it is GIRO.

After running into these issues, I compared the other engines and I noticed the the Knab class is almost identical to the ASN class. It even has the same, unused/uncalled, method parseTransactionType... Could that possibly explain my experience?

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