Manage Import mappings

Spooky as I just spent some time looking for them.

As I would imagine that the vast majority of people are only ever interested in looking at the mapping of bank imports, wouldn't it be an idea to have a link to this page on the bank import statement page? I'm sure there used to be one there?

Hi Paul,

Our development team have been made aware of this potential UX improvement.

Thanks again for your continued feedback.

Edit: If an import mapping has already been established for the bank account that you are attempting to import, there is an option to reset the mapping for that account, as seen below.

This will only be available for accounts that have a mapping configured. If not then when you attempt to import you will be prompted to map against the CSV file.

Not on my client it doesn't

Is there mapping established for the Lloyds account? As this option is only available when there is already mapping present.

They have been mapping to the same Lloyds account for over 4 years!

The same just happened on my bank upload, no message or warning.

Is this all connected with the defect CB has created in bank statement uploads, whereby it can no longer recognise mappings that have been in place for years, forcing the user to create a duplicate mapping?

A recent update to the formatting of the bank account naming has resulted in the uncoupling of bank accounts from their import mappings.

All accounts that have had mappings organized for them will need them reestablishing and will be prompted to do so on the next statement import.

How does this happen Theo?

Somebody decides to change the formatting of the name of bank accounts and, in doing so, uncouples perhaps thousands of bank accounts from their mappings.

You used to employ someone for QA to test changes, don't you do that any more? Also, at one time I was told that core coding would be protected from the peripheral stuff so that, as used to happen happen so often, a tiny change in one place could not effect core coding elsewhere.

Also are you saying that, as didn't happen with my and my client's imports earlier, anyone effected by this error will now get the message you show above? If so, again, how did it not happen before?

Any chance you could tell users that this is likely to happen the next time they upload a statement or do you expect me to circulate all my clients, and all the accountants I know that use CB so that they can warn their clients and explain to them what 'mapping" is?

As an example of how this effects users, in addition to loads of wasted time today to get my client's current account correctly updated, she was shocked to see accumulated corporation tax of £47K, rather than £9K yesterday. It turns out that in trying to recreate the mapping to her savings account, she managed to upload £200K of interest received, rather than £9.

Yeah sorry about this, Paul - this was a genuine unintentional mistake!

When mapping was originally designed the bank name was linked to the mapping, so if you changed the bank name it would mean you would have to re-map.

It's never really been highlighted as a problem before because it would be very rare that users would change the details of a bank name.

To help fix another problem, a space was added between the bank name and account number on all accounts - it seemed like an innocuous change, but actually, because of the above, it turned out to be much more serious.

Sorry about the problems it caused you!

This has at least helped us target a couple of changes -

1. Each bank account has it's own unique ID so we will be changing the mapping to link to the ID and not the bank name.

2. It seems mapping is not very clear to a lot of people so we are going to add some more info on the mapping screen to help make it easier to understand how to map a statement to fields in CB.

Thanks for that John but my issue about changes not being tested and QAd is still a valid one and likely to be compounded if it turns out that the new transfers bank rule has also been released without adequate checking.

Similarly, as I asked, is it up to me to tell all my clients and other accountants about their bank mappings no longer working, and what they need to do to recreate them, or will CB do the right thing and email all users (or perhaps you only target me and my clients?).

The technical problem over duplicated mappings still remains. As far as I am concerned the two mappings currently sitting in my and my client's books are identical and for the same bank account and, for most people, there's nothing onscreen that tells me which one to delete.

From what you say above, the old redundant mapping is the one without a space between the name & the (number) and so I can delete that one. Again, might it be an idea to tell everyone? If nothing else it would save Support a stream of queries.

It shouldn't be your job at all Paul. We have been discussing the addition of a notification messaging system on the menu bar in Clear Books, which will include our announcements from the community (product improvements/bug fixes/these type of issue). I can't give an exact date for this being added, but in the meantime, we will continue to add news on the community.

As for the mapping, if you have re-imported and re-mapped, the new mapping will be used everytime you import a new statement going forward. The original mapping becomes redundant, however, it will stay listed on the mapping menu so you can indeed delete the mapping which has no space between bank name and account number. If in doubt I would always recommend deleting them both, which will mean you will need to map the next time you import, but only that new mapping (after your import) will be listed.

I think we have weathered the bulk of the storm in support - it became clearer what the actual problem was and what had caused it in the last few days, by which point we had manually helped those customers who initially raised the issue. I'm sure we will continue to receive queries about this, so I have forwarded for management for review.

The two fixes I mentioned in the previous message should help prevent this particular issue from happening in future, and I hope make mapping a bit clearer.