FAQs & Knowledge Base

Welcome to our Knowledge Base. Search or browse through the topics below to find answers to your questions.

Categories: SEPA-Transfer | Show all categories

Yes, in the Enterpise Edition of SEPA-Transfer there is this option.

When sending bookings to the bank, there is a checkbox "Doi not consolidate" in the SEPA Transfer dialogue. If this is ticked, a flag called "batch booking" is written into the SEPA file, which instructs the bank to show all bookings of the collector individually on the account statement.

However, some banks ignore this flag, including many Volksbanks as well as GLS Bank, which has its data centre operated by Fiducia.

The only workaround is to send all bookings individually. Please note that this may incur higher booking costs than for a collector and that you need a TAN for each booking.

SEPA-Trafser supports you in this if you set the option "Maximum number of bookings for SEPA export" at the very bottom of the "Advanced" page of the settings dialogue to "1". This option is also only available in the Enterprise Edition.

Owners of the Small Business Edition can purchase an upgrade to the Enterprise Edition at a reduced price in our customer area.

During your maintenance period, you will find them at Downloads/Updates -> Older versions in your customer account. There are the installation files and keys of the two last major versions.

None of our applications depend on Java Spring or any other Java library and are thus not affected by this vulnerability.

All of our products are being developed in Delphi or C#. Although we use Spring4D(elphi) with some of the components, they are safe to use, because the reported vulnerability applies to Java Spring framework only.

This applies to all versions and editions of our applications (TreeSize, SpaceObServer, SpaceObServer WebAccess, HeavyLoad, SmartPOP2Exchange, Exchange Server Toolbox, SpamAssassin in a Box, SpamAssassin for Windows, SmartCallMonitor, SEPA-Transfer, ServerSentinel, and ShellBrowser). It is recommended to always use the latest available versions though to benefit from the latest patches, improvements, and features.

All of our products are being developed in Delphi or C#. Although we use Log4Net with some of the components, they are safe to use, because the reported vulnerability applies to Log4J only.

None of our applications depend on Log4J or any other Java library and are thus not affected by this vulnerability.

This applies to all versions and editions of our applications (TreeSize, SpaceObServer, SpaceObServer WebAccess, HeavyLoad, SmartPOP2Exchange, Exchange Server Toolbox, SpamAssassin in a Box, SpamAssassin for Windows, SmartCallMonitor, SEPA-Transfer, ServerSentinel, and ShellBrowser). It is recommended to always use the latest available versions though to benefit from the latest patches, improvements, and features.

According to the SEPA standard, the execution date 01.01.1999 for credit transfers means "earliest possible date" (formally "non-terminated credit transfer") and is always used by SEPA-Transfer if the execution date is the respective today's date.

If you specify a future date, SEPA-Transfer exports a "scheduled transfer". This contains the date as specified.

In the Enterprise Edition of SEPA-Transfer, there is an option to influence this behavior in the settings under "Advanced". In the "Bank specific settings" section, check the "Execution date of non-terminated SEPA transfers is the current day instead of 01.01.1999" to always use the date you set in SEPA transfers.

All entries (Page 1 / 3)