Hi Mr_Mayor I have seen this problem too.  I investigated it further and found that the system appears (I don't know for sure, Sage Support will have to confirm) that regardless of what you attempt to submit in the Statement Currency field, the system is forcing the Functional Currency (in my case CAD instead of USD from the Excel sheet).  In the below example in Sage 300 2025 PU2, its option to overwrite the field with another currency is greyed out, forcing the existing functional currency value.  RVSPY confirms just before the error that its trying to insert the value in the Excel document - in this case USD.  I suspect this will need to go to Sage support and be submitted as a case for rectification.  If you're submitting a case already I'll leave it with you, if not, let me know and I'll submit a case with my findings.  All the best.

Hi All,

This was reported to Development.  It was determined to be a minor defect as there is nothing preventing the user from creating the Bank Code via the UI. 

Import\Export process is really for volumes of transactions/records.. Most companies don't have hundreds and hundreds of individual Bank Codes requiring the necessity to use Import/Export  and thus it was determined to be a minor defect. 

Regards,

DCrampton

the first part is understandable

the second part doesn't resonate well. even AP's payment codes or AR's Interest Profile can have 1 file but the import export still exists and works well

i have a client with 42 banks hence asking. 

is that the Sage position  that it wasn't necessary? 

you can import record. it just seems unnecessary to use the import function to add one record.. as for your client with 42 Bank Codes .. did they import all 42 Bank Codes at once or did they add them as they went along?

all banks are needed, it's a segmented company, and users have different banks for each segment

punching in all 42 seemed terrible. 

this option has always been working before

thanks to Cashbook, once you have all banks in, they are a functionality to auto load all banks. pretty cool

I still don't quite understand.. the 42 Banks are already added into Sage, correct?  the issue with this particular error is with importing a new bank code with currency option.. so they are importing 42 Bank Codes at a time?  

in my situation. Central Bank introduced a new currency as functional currency. 

you have to create a new database. Export and import setups 

everything else I can export and import expect this bank function. Now I have to do those 42 banks manually. Creating them 1 by 1 

Thank you for the update DCrampton .  I understand clients often don't have many Bank Accounts, maybe half a dozen per database, but in Mr_Mayor case where he needs to import 42 into a new database, I can see its a pain when you want to avoid input errors.  I also understand it might seem strange to use imports when there are only a few records but the practical situation is different.  We have clients that are Group Company HQ's where they have 50+ databases and counting, adding several a year.  Each new database is based on an existing, and Sage doesn't provide a clone tool to base a new database off an existing (I really need to convince clients to invest in TailRox tools that offer this), and to save on errors and consulting time, we need to open every single setup screen and configure it/add entries. Also when setting up completely unique databases its better to share import sheets with the clients, having them enter/modify the GL accounts, bank accounts, etc they want into the Excel files, leaving us to just import them.

Typing several entires or configuration items into each setup screen for each module equates to at least 50 round of data entry.  So what we do is setup a list of import files for AP Account Sets, AP Dist Codes, AP Terms, AP Payment Codes, AP Selection Codes rinse and repeat for every module, importing as much as possible.  Any screen we have to stop and type stuff in manually when there is pressure to reduce consulting fees and avoid mistakes is annoying.  That's all, I understand its not a big issue, but am just trying to provide some feedback on Mr_Mayor 's concerns.  Its the volume and time pressures we encounter where anything we can import is a big help...and we call make human errors typing stuff in which is always a pain hehe.

Thank you for the update DCrampton .  I understand clients often don't have many Bank Accounts, maybe half a dozen per database, but in Mr_Mayor case where he needs to import 42 into a new database, I can see its a pain when you want to avoid input errors.  I also understand it might seem strange to use imports when there are only a few records but the practical situation is different.  We have clients that are Group Company HQ's where they have 50+ databases and counting, adding several a year.  Each new database is based on an existing, and Sage doesn't provide a clone tool to base a new database off an existing (I really need to convince clients to invest in TailRox tools that offer this), and to save on errors and consulting time, we need to open every single setup screen and configure it/add entries. Also when setting up completely unique databases its better to share import sheets with the clients, having them enter/modify the GL accounts, bank accounts, etc they want into the Excel files, leaving us to just import them.

Typing several entires or configuration items into each setup screen for each module equates to at least 50 round of data entry.  So what we do is setup a list of import files for AP Account Sets, AP Dist Codes, AP Terms, AP Payment Codes, AP Selection Codes rinse and repeat for every module, importing as much as possible.  Any screen we have to stop and type stuff in manually when there is pressure to reduce consulting fees and avoid mistakes is annoying.  That's all, I understand its not a big issue, but am just trying to provide some feedback on Mr_Mayor 's concerns.  Its the volume and time pressures we encounter where anything we can import is a big help...and we call make human errors typing stuff in which is always a pain hehe.