Expense and revenue account same IBAN

[RobertMaaskant]

I am running Firefly III version 4.7.1.4

Description of my issue:

Through an import an expense account and a revenue account were created for a single IBAN. This seems correct, but now when attempting to rename them (would like the default import name to something more sensible) it does not allow this with an error message: 'It looks like this IBAN is already in use.'

Steps to reproduce

1. Create revenue account
2. Attempt to create expense account with same IBAN: this is not allowed

The problem exists on the demo site.

Other important details (log files, system info):

Debug information generated at 2018-03-11 11:59:12 Europe/Amsterdam for Firefly III version 4.7.1.4.

Variable	Content
FF version	4.7.1.4
FF API version	0.1
App environment	local
App debug mode	false
App cache driver	file
App logging	notice, daily
PHP version	7.2.1
Display errors	Off
Session start	2018-03-01 00:00:00
Session end	2018-03-31 23:59:59
Session first	2017-01-01 00:00:00
Error reporting	ALL errors
Host	Windows NT HAPTOP 10.0 build 16299 (Windows 10) i586
Interface	apache2handler
UserID	1
DB drivers	mysql, sqlite
Current driver	mysql
Using Sandstorm?	no
Is Sandstorm (.env)	false
Is Docker (.env)	false
Trusted proxies (.env)
User agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Loaded extensions	Core, bcmath, calendar, ctype, date, filter, hash, iconv, json, SPL, pcre, readline, Reflection, session, standard, mysqlnd, tokenizer, zip, zlib, libxml, dom, PDO, bz2, SimpleXML, xml, wddx, xmlreader, xmlwriter, apache2handler, openssl, curl, fileinfo, gd, gettext, intl, mbstring, exif, mysqli, pdo_mysql, pdo_sqlite, Phar, ftp
Installed packages	bacon/bacon-qr-code@1.0.3, davejamesmiller/laravel-breadcrumbs@4.2.0, defuse/php-encryption@v2.1.0, doctrine/annotations@v1.6.0, doctrine/cache@v1.7.1, doctrine/collections@v1.5.0, doctrine/common@v2.8.1, doctrine/dbal@v2.6.3, doctrine/inflector@v1.3.0, doctrine/lexer@v1.0.1, egulias/email-validator@2.1.3, erusev/parsedown@1.7.0, fideloper/proxy@3.3.4, firebase/php-jwt@v5.0.0, guzzlehttp/guzzle@6.3.0, guzzlehttp/promises@v1.3.1, guzzlehttp/psr7@1.4.2, laravel/framework@v5.5.36, laravel/passport@v4.0.3, laravelcollective/html@v5.5.3, lcobucci/jwt@3.2.2, league/commonmark@0.17.0, league/csv@9.1.2, league/event@2.1.2, league/flysystem@1.0.43, league/fractal@0.17.0, league/oauth2-server@6.1.1, monolog/monolog@1.23.0, mtdowling/cron-expression@v1.2.1, nesbot/carbon@1.23.0, paragonie/constant_time_encoding@v2.2.1, paragonie/random_compat@v2.0.11, phpseclib/phpseclib@2.0.10, pragmarx/google2fa@v2.0.7, pragmarx/google2fa-laravel@v0.1.4, psr/container@1.0.0, psr/http-message@1.0.1, psr/log@1.0.2, psr/simple-cache@1.0.0, ramsey/uuid@3.7.3, rcrowe/twigbridge@v0.9.6, rmccue/requests@v1.7.0, swiftmailer/swiftmailer@v6.0.2, symfony/console@v3.4.5, symfony/css-selector@v4.0.5, symfony/debug@v3.4.5, symfony/event-dispatcher@v4.0.5, symfony/finder@v3.4.5, symfony/http-foundation@v3.4.5, symfony/http-kernel@v3.4.5, symfony/polyfill-mbstring@v1.7.0, symfony/polyfill-php56@v1.7.0, symfony/polyfill-php70@v1.7.0, symfony/polyfill-util@v1.7.0, symfony/process@v3.4.5, symfony/psr-http-message-bridge@v1.0.2, symfony/routing@v3.4.5, symfony/translation@v4.0.5, symfony/var-dumper@v3.4.5, tijsverkoyen/css-to-inline-styles@2.2.1, twig/twig@v1.35.2, vlucas/phpdotenv@v2.4.0, watson/validating@3.1.2, zendframework/zend-diactoros@1.7.1,

[JC5]

I'll pick it up for the next release. Currently IBAN's are forced to be unique because it helps when importing data (ironically) but it's not always realistic. For example, a friend that sends you money and you receive money from (ie. via Tikkie) would have an expense account and a revenue account, both with the same IBAN.

As for the renaming, checkout the rules feature. You might be able to automate some of this stuff.

[simhnna]

To circumvent this in silverstrike I just have the notion of foreign accounts and don't distinguish between expense and revenue. It might not be very easy to switch that, and you might not even want to as some things won't work as before (viewing expense/revenue accounts) and it is sort of a major shift in the modelling. Just wanted to know that it works and I didn't encounter any issues without the distinction yet.

[JC5]

In a digital ledger it doesn't matter much indeed. You could safely skip double booking as well, it's not as if my app is going to commit fraud. But I like it, and it's a big step to turn away from.

As for the account numbers and IBAN's. I'm going to remove the unique requirement from them for the next release, and just leave some basic checks.

[JC5]

New basic checks in the new release:

• For asset accounts, IBANs must be unique over all types of accounts.
• For expense and revenue accounts, they may have a counterpart (revenue <> expense) with the same IBAN. Other combinations are not allows.

As for the import routine: there is an item on my list to improve various parts of the import routine. Relevant to this issue is the fact that the creation of new objects (such as accounts and transactions) is not always centralized. When this is implemented, your original issue is way less likely to happen.

[JC5]

See #1222 for the improvements I mentioned.