NCP Payments (NAV)

Note

NCP Payments is available for Microsoft Dynamics 365 Business Central as an extension under the product name NCP Payments Export and NCP Payments Import. For more information, see [Docs] NCP Payments

Manual

☰ Contents

Appendix

• NAVAX Registration
  The current registration status of a NAVAX Dynamics NAV AddOn is displayed in the AddOn Setup page in the System group...
• Release Notes
• Upgrade to Business Central
  This topic is for developers and describes the steps required to transfer the data from the old C/AL version (NAV AddOn) to the new AL version (BC Extension)...

Docs  /  NCP Payments (NAV)  /  Appendix
NAVAX Registration

Trial Version

Request Registration

Note

For registration, calling the online help and performing some actions, access to https://www.nccube.com and https://www.navax.app must be allowed. In addition, TLS 1.2 is required. For more information, see How to get earlier versions of the Dynamics NAV development environment to work with TLS 1.2 Public IP from www.navax.app for setting firewall access: 94.136.22.236, Port: TCP/443 Checking the connection to https://www.navax.app using PS: Test-NetConnection navax.app -port 443 (PS must be performed with the M-Tier service user)

Activate/Update Registration

Terms & Conditions

https://www.navax.app/EULA.php?L=en

Data Security

https://www.navax.app/privacyStatement.php?L=en

Docs  /  NCP Payments (NAV)  /  Appendix
Release Notes

Note

NCP Payments is available for Microsoft Dynamics 365 Business Central as an extension under the product name NCP Payments Export and NCP Payments Import. For more information, see [Docs] NCP Payments

NCP Update

NCP 13.01

• Note

  This version is also available as a downgrade version for for older Dynamics NAV versions.

Modifications

Payments Import – Significant improvement of the automatic Customer Ledger Entries matching. In version NCP 13.00 the field Document No. Alloc. Accuracy was added to the Payments Import Setup. The option Fuzzy (Incl. values without special characters) has been revised and should now deliver a much better result.

Corrections

The settings for the file names of the payment files were ignored.

NCP 13.00

General

An update of the license file is necessary.

Update Codeunits are available. Important Payments Entry Comments for Bank Account Ledger Entries, Clearing Entries, Payment Entries and Remittance Entries have been removed and are no longer supported. If required, this functionality must be implemented via individual programming. During an update, the data in Table 1001702 "NCP Entry Comment Line" will be deleted.

A registration is necessary. The trial version expires in 30 days. For more information, see Appendix, NAVAX Registration.

Improvements

NC Payments now also supports the Web Client and the Tablet Client. NC Payments is now available for Microsoft Dynamics 365 Business Central – OnPremises. For a complete list of all available versions, see the document Version Matrix. Note that the features or functionality of the solution may vary depending on the installed version, the client you are using, and/or your license model.

Added function Delete Data to the Payments Export Setup. By creating a Payment File, an entry will be created in the Clearing Entries. The created Payment File will also be stored there. If necessary, this action can be used to remove the archived Payment Files from the Clearing Entries. Note After deleting, the files can no longer be exported. The period for deleting the data can be specified in the Delete Data Date Calculation field in the Payments Export Setup. Only data that is at least 6 months old can be deleted. If the field is empty, the minimum period is used.

Added function Delete Data to the Payments Import Setup. By importing a file, an entry will be created in the Payments Import. The imported file will also be stored there. If necessary, this action can be used to remove the archived Import Files from the Payments Import. Note The period for deleting the data can be specified in the Delete Data Date Calculation field in the Payments Import Setup. Only data that is at least 6 months old can be deleted. If the field is empty, the minimum period is used.

Added placeholder %10 Payment Type for the file names in the Payments Export Setup.

Added parameter [BankName2] to the Payments XML Schemas. With this parameter, the Name of the Bank Account can be specified in the CdtrAgt area of e.g. Non-SEPA Credit Transfer Schemas. To make sure that all new schema functions are available, you must update the XML Schemas.

Added new option Transaction Code in the Search in field of the Payment Import Fixed Account Allocations.

Added field Document No. Alloc. Accuracy to the Payments Import Setup. The two available options influence the automatic matching of the Customer Ledger Entries. The option Sharp (Identical value) is equivalent to the previous search. If the option Fuzzy (Incl. values without special characters) is selected, first (like Sharp) the exact value of the Document No. from the Customer Ledger Entry will be searched If nothing was found, the system searches for the Document No. without the following special characters: !"§$%&/=?+-.,;#~*|<>({[]}) Example: The Remittance Information of the Transaction contains the value 'INV2804' In NAV, the Document No. of the Customer Ledger Entry is 'INV-2804' For all open Customer Ledger Entries a possible transaction will be searched. Fuzzy means that it will be searched for 'INV-2804' first. Since there is no Transaction with this value, it will be searched for 'INV2804' afterwards. This value will be found in the Remittance Information of the Transaction. Note Since the Fuzzy option is not as strong as the Sharp option, the Document Rating in the allocation process will be reduced 10 points.

When importing a CAMT file, the posting date of the transaction will now be recognized even if it is specified in the format 'BookgDt DtTm'. So far, only 'BookgDt Dt' has been considered.

When importing a CAMT file, the value date of the transaction will now be recognized even if it is specified in the format 'ValDt DtTm'. So far, only 'ValDt Dt' has been considered.

Modifications

By creating a Payment File, an entry will be created in the Clearing Entries, as before. The final summary shows now all information about the created Clearing Entry. The Payment File can be provided for the Bank software via the Export Payment File function in the summary. Note The file can also be exported later via the Clearing Entries.

Significantly improved the performance of the Create Payment File function. The status window has also been revisited.

Significantly improved the performance of the Void Payment File function. The status window has also been revisited.

Payments Entry Comments for Bank Account Ledger Entries, Clearing Entries, Payment Entries and Remittance Entries (added by NC Payments in version 6.12) have been removed and are no longer supported.

Some windows have been redesigned/revised.

Corrections

The parameters for specifying the Recipient Address in the XML Schemas (added by NC Payments in version 8.10) were not filled in the payment file.

If the Create Bal. Account Line field in the Payments Export Setup was set, an error could occur during the amount check when posting the Journal Lines.

Voided Payment Entries will no longer be considered in the Payments Import.

When transferring the Payments Import to a Journal, the Currency Factor could cause an error.

NCP 11.01

Corrections

Due to an object ID conflict with the NC Cost Accounting AddOn, the pages with ID 1001750, 1001751 and 1001752 had to be moved. Before you can import the NCP 11.01 objects, you must delete the following objects: Page 1001750 NCP Country/Region Setup Page 1001751 NCP Bank Account Setup Page 1001752 NCP Bank Account Setup Card

NCP 11.00

Improvements

NC Payments is now available for Microsoft Dynamics NAV 2018.

Up from Microsoft Dynamics NAV 2018, Employee Payments are possible via NC Payments.

Added a new field External Account Holder to the Payments Import Transactions.

Added field Trans. Charges to the Payments Import Setup window. If the field is set to Yes, the charges will also be transferred to the Journal or the Reconciliation. Note: Only the Total Charges lines will be transferred. The Charges G/L Account No. for the direct transfer to a Journal or the indirect transfer to a Journal via the Reconciliation can be set in the Payments Bank Account Setup window. The new field Import Source Type in the journal lines and in the reconciliation lines indicates whether the line is a transaction, charge or reconciliation line. The fields Payment Import and Bank Acc. Reconciliation have been removed from the journals.

The Currency Factor from camt files will now also be considered in the Payments Import Transactions. If the transaction line is transferred in a Journal, foreign currency amounts will now be calculated with the correct currency factor.

Added parameter [BankCcy] to the Payments XML Schemas. With this parameter, the Currency Code of the Bank Account can be specified in the area of Non-SEPA Credit Transfer Schemas. To make sure that all new schema functions are available, you must update the XML Schemas.

It is now possible to create a One-Time Transfer via the External Bank Account Card action in the journals. The One-Time Transfer action has been removed from the journals.

Added action Suggest Data to the One-Time Transfer window. With this action, the data of the last One-Time Transfer (with same Account Type and Account No.) can be suggested.

Modifications

The main menu has been revised.

Some windows have been redesigned/revised.

The Payments Setup has been renamed to Payments Export Setup.

All NC Payments Extensions/Modifications to Currencies, Countries/Regions and Languages have been removed from the standard objects and are now available in separate objects. To set up the data click on the corresponding action in the Payments Export Setup or in the Payments Import Setup window. The fields LCY Code and ISO LCY Code have been removed from the Payments Export Setup and from the Payments Import Setup window. Instead, set up a record with blank Currency Code for the LCY ISO Code (usually EUR) in the new Payments Currency Setup window.

All NC Payment Fields have been removed from the Bank Account window/object and are now available in the new NCP Bank Account Setup window/object. To set up the data click on the Bank Account action in the Payments Export Setup or in the Payments Import Setup window.

The Payments Import Posting Lines and all related fields and actions have been renamed to Payments Import Transactions.

Payments Import fields and actions for transferring to a Journal or to a Reconciliation are now only displayed, if they were set up in the Payments Import Setup. If e.g. no transfer to a Reconciliation is set, no Reconciliation fields and actions will be displayed.

The Overall Charges field in the Payments Import Charges has been renamed to Total Charges.

The Pmt. Notification Texts and the SEPA Mandate Texts are now set up in the new Payment Language Setup window. To set up the data click on the Language action in the Payments Export Setup window. Default values for the settings can be suggested via the Initialize Data action. Note: In most cases, no Language Code is set for Vendors and Customers. For this reason, also set up a record with blank Language Code. It is also possible to link texts from another Language Code via the Linked Language Code field. That means that the text is not set up with the current Language Code, but with the linked Code. Here is an example of a possible setup:

Corrections

Added missing translations in the captions.

The Renumber Document Numbers function of the Journals also checked the Payment Status from Lines of other Journals.

If the Payment Suggestion was called with the Summarize per Vendor/Customer option, the Applies-to ID field settings in some entries was not cleared correctly in case that the suggestion was terminated with an error. The error also occurs in the standard. The error was corrected by a changed call logic.

NCP 10.01

Modifications

The registration is now bound to the Tenant.

The Support E-Mail functionality has been revised and is now available via What's New?.

NCP 10.00

Improvements

Added function Support E-Mail to the Payments Setup window. For problems/questions regarding the AddOn, please use this function. The e-mail contains helpful information for solving the problem.

The payment file settings in the Payments Setup window can now be set differently for each Bank Account. When creating the file, the system searches for the setting with the Bank Account. If no special setting is found, the setting without Bank Account will be used as before.

It is now possible to edit/create Payments XML Schemas.

The recipient data (Name, Address) for One-Time Transfers has so far been written directly from the Vendor/Customer to the payment file. Now it is possible to specify different recipient data in the One-Time Transfer window. If nothing is specified, the data is determined as before.

The bank account in Payments Import was so far only determined by the combination of IBAN and SWIFT Code. Now, if no bank account has been found, the system also searches for the IBAN without SWIFT Code.

Modifications

For the use of some online services a registration is required. For more information, see Appendix, NAVAX Registration.

The design of the Bank Codes has been revisited/improved. In the Payments Setup window click on the Action Bank Codes and then, in the Bank Codes window, click Download…. Select the Create new Records & overwrite existing Records option to update the codes. Alternatively you can delete all Bank Codes before downloading them. The advantage of this is that the content of the table corresponds to the current status for Austria and Germany after the download. Manually created entries however are lost in this case.

The result of the Payment Suggestion has been improved/optimized, especially when different options (like Find Payment Discounts or Available Amount (LCY)) are combined.

The Suggest Application functionality in the Journals and the Match Automatically functionality in the Reconciliation have been improved/optimized. The analysis window now displays more detailed information about the selection procedure. In addition the window can now be closed with OK. This will take the suggestion into the Journal/Reconciliation. However, it is recommended to activate the analysis window for analysis purposes only. The reason for this is that at the time of the confirmation with OK it is no longer possible to guarantee whether all Entries are still available or open. This means that an error message or an indication that another user has changed the data could occur.

Some windows have been redesigned/improved.

Corrections

If the Application in the Journal was changed after the payment file has been created, an error could occur. The window could not be closed and a restart of the client was necessary.

If the field Modify allowed after "File Created" in the Payments Setup window was not activated, an error message could occur when posting a Journal in connection with One-Time Transfers.

It was not possible to send the Payment Notification by E-Mail in the classic NAV 2009 environment.

It was not possible to import camt files where Boolean fields are set to '0' and '1' instead of 'TRUE' and 'FALSE'.

No Bank Account was proposed when importing Custom Formats via the Payments Import window.

The fields Remittance Info. and Additional Info. were not filled when importing Custom Formats via the Payments Import window.

Due the fact that not all Banks strictly adhere to the MT940 specification, XML Identifiers (for example EREF or SVWZ) have been assigned with incorrect values when their length exceeded. From now on, the length for KREF, EREF and MREF will no longer be checked because these fields cannot be exceeded anyway due to the maximum number of their characters. For the remaining Identifiers an overrun of the length will only be considered, when the new field MT940 - Splitted XML Identifiers in the Payments Import Setup window is activated.

NCP 8.10

Improvements

New field Collective Transaction No. has been added to the Payment Journals and to the Cash Receipt Journals. The field is hidden by default. Depending on the setting of the Collective Transaction field in the Payment Setup (Register Payment File), there are 2 different modes of operation: Collective Transaction in the Payment Setup = No As previously, no Journal Lines will be summarized during file creation. By specifying a Collective Transaction No. it is now possible to define exceptions for individual Journal Lines. Lines with same Collective Transaction No. will be summarized. Lines without Collective Transaction No. will not be summarized. Collective Transaction in the Payment Setup = Yes As previously, all Journal Lines will be summarized during file creation. By specifying a Collective Transaction No. it is now possible to define exceptions for individual Journal Lines. Lines with same Collective Transaction No. will be summarized. Lines without Collective Transaction No. will also be summarized. In both cases, the following is valid: Independently from the setting of the Collective Transaction field in the Payment Setup and from the Collective Transaction No. field in the Journals, lines where a Payment Reference is specified or One-Time Transfer lines, will never be summarized. Furthermore only lines will be summarized, where following fields contain the same value: Payment Type Account Type Account No. External Bank Account Code Currency Code Direct Debit Type Direct Debit Sequence Mandate ID Date of Mandate As a result, one and the same Collective Transaction No. can be assigned several times. Example: There are two Journal Lines (payment and refund) for Customer A. For both lines Collective Transaction No. = '1' is specified. Furthermore there are three more lines for Customer B where also Collective Transaction No. = '1' is specified. Because of the Directives listed above (Account No.), two separate transactions will be created.

New fields Originator ID and Originator ID Issuer have been added to the Bank Accounts. In XML payment files previously only the Name of the Originator from the Payment Setup was used for identification. Some countries resp. some banks additionally require an ID for unique identification. This ID can now be set for the Bank Account and will then be written in the XML payment file.

New field Address Specification possible has been added to the XML Schemas. The field indicates whether the schema supports address data or not. If Address Specification is possible, the fields Originator Address and Recipient Address can be set. If Originator Address is selected, the address data from the Payment Setup will be written in the payment file. If Recipient Address is selected, the address data from the Vendor/Customer will be written in the payment file. To ensure that all new XML Schema functions are available, the XML Schemas must be updated.

A new option Create new Records & update existing Records (keep Settings) is available for the XML Schema Import/Download. If the option is selected, the settings (for example Int. IBAN Only, Batch Booking, Extended Character Set, etc.) for the individual schemes no longer get lost during the update process.

New field Trans. Amount has been added to the Payment Import Setup. The field is only considered in the transfer to a Journal. If the option Order Amount/Transaction Amount is selected, the Order Amount will be transferred to the Journal if available. Otherwise the Transaction Amount will be transferred. If the option Transaction Amount is selected, only the Transaction Amount will be considered resp. transferred.

The Payment Import Ledger Entry Search function has been enhanced. The function will now additionally search for a Payment Reference within the Remittance Info.

The G/L Account in the Payment Import Fixed Account Allocations will now be checked during selection.

It is now possible to define Custom Formats for the Payment Import. With the help of Custom Formats, it is possible to import CSV file format bank statements in the "Payment Import". It is possible to define as many formats as needed. For each format the file structure (delimiters, fields and field formats) can be set. Restrictions / Requirements: The file must begin with a line, which includes the field names (header). A line resp. a record must be no longer than 1024 characters. After creating a new format and setting up the delimiters used in the CSV file, the fields in the file and their assignment to Payments Import can be set up. With the Suggest Fields function it is possible to read resp. suggest the fields automatically from the CSV file resp. the line, which includes the field names (header). After that, each field of the file which should be imported into the Payment Import, must be assigned to a field number of the import.

Since Microsoft Dynamics NAV 2013 R2 it is possible to specify a Payment Reference in the Purchase Header. During the posting process, the Reference will now also be transferred to the Payment Reference field of NC Payments in the Vendor Ledger Entries. If the length of the text in the standard field (max. 50 characters) is longer than the max. length of the NC Payments field (max. 35 characters) the value will be clipped and a message appears.

Modifications

The field Creditor ID from the Payment Setup has been renamed to Creditor Identifier (CI).

Payment Import Fixed Account Allocations can no longer be Imported/Exported.

Modifications for an easier licensing of NC Payments.

Corrections

There was a performance issuer in the Vendor and in the Customer Payment Suggestion. After the actual suggestion, the Vendor resp. Customer Ledger Entries have been read once again.

Corrected an error in the Vendor and in the Customer Payment Suggestion for Credit Transfers in connection with the Option Available Amount (LYC).

NCP 8.00

Improvements

It is now possible to specify Filters for Ledger Entries in the Suggest Vendor Payments and Suggest Customer Payments functions. Filtering the Ledger Entries may additionally restrict the Suggestion. Internal Filters, set by the Suggestion, are still valid and cannot be revoked. However, a restriction is possible. If, for example, the Filter 'USD' is specified in the field Currency Code and Dom. Credit Transfer (PAYMUL) is selected in the field Payment Type of the Suggestion, no Entries will be suggested, because the Suggestion itself only considers 'EUR' Currencies. If, in the same case, Int. Credit Transfer (PAYMUL) is selected, only Entries with Currency Code 'USD' will be suggested.

If Create Bal. Account Line in the Payment Setup is activated, the Document Type field in the General Journal Line will be changed in certain situations during the Payment File creation (See NCP 7.10). Cancelling the Payment File now also resets the Document Type to its original value.

New field IBAN or Bank Account No. possible has been added to the XML Schemas. This field indicates whether the schema supports transactions without IBAN or not. If IBAN or Bank Account No. possible has a value, the new field IBAN or Bank Account No. can be activated. If IBAN or Bank Account No. is activated, the Bank Account No. will be exported to the Payment File if no IBAN is available. (Note: The IBAN of the own Bank Account must always be specified) To ensure that all new XML Schema functions are available, you must update the XML Schemas.

The Payment Statistics now shows Amounts per Payment Type, Bank Account No. and Currency Code. The Total Amounts in the register General have been revised.

Opening the Payment Setup for the first time now initializes following fields: ISO LCY Code will be initialized with 'EUR' if LCY Code is 'EUR' or 'EURO'. Originator: Name, Name 2 and Address data will be initialized with the data from the Company Information. Payment File: Remittance Info. will be initialized with '/[/%2][/%5%6][/Disc%7]'.

New field Pmt. Notification Text Exists has been added to the Payment Setup. The field indicates whether there is an entry in the Pmt. Notification Text table or not. With AssistEdit the Pmt. Notification Text can be opened.

The fields Payment File Text and E-Mail Subject will now be initialized with default values for new Pmt. Notification Text Records. If no Language Code is specified, the fields are initialized in German language. If a Language Code is specified, the fields are initialized in English.

Added following functions to the Payment Setup: Send Pmt. Notification Test Message With this function it is possible to test the settings for the Pmt. Notification E-Mail functionality. If the function is called, the E-Mail address, to which the message should be sent, must be specified in the field Test Message To. Create Permissions With this function the Payments Permission Sets can be created or updated. Initialize Currencies This function fills the ISO Code Payments field in the Currency table. For each of the available ISO Codes it will be checked, if a currency with the same code exists. If this is the case, it will be checked if the ISO Code Payments field contains a value. If no value is entered, the ISO Code will be written in the field. Initialize Countries/Regions This function fills the ISO Code Payments field and the SEPA field in the Country/Region table. For each of the available ISO Codes it will be checked, if a Country/Region with the same code exists. If this is the case, it will be checked if the ISO Code Payments field contains a value. If no value is entered, the ISO Code will be written in the field. After that, for all SEPA Countries the field SEPA will be set to Yes. Export Vendor/Customer Bank Accounts and Import Vendor/Customer Bank Accounts Until now, these two functions were available in the Payments Menu under Setup, Import/Export Bank Accounts.

New functionality for importing camt, MT940 and CREMUL has been added. The previous MT940 Import has been removed and is now part of this new functionality.

Modifications

If several payments in an XML Payment File were summarized to one transaction, each Remittance Information was automatically separated by a comma. This Logic has been removed.

The thousands separator of the Remittance Information amount fields (Parameter %6 and %7) are now removed automatically from the Remittance Information in the Payment File.

The sign of the summary amounts in the Payment Suggestion List has been changed.

The Lookup behavior for the fields Bank Branch No. and SWIFT-Code has been improved.

The field Bank Currency Code from the Bank Account has been renamed to Bank Currency Code (PAYMUL/DIRDEB).

The field Save Embedded Payment File from the Payment Setup has been renamed to Archive Payment File.

The field Embedded File Exists from the Clearing Entries has been renamed to Archived File Exists.

NCP 7.12

Improvements

Unstructured Remittance Info. is now also displayed on the Bank Acc. Reconciliation and on the Bank Account Statement.

Corrections

No values were displayed in the Remittance Info. field on the Bank Acc. Reconciliation and on the Bank Account Statement.

NCP 7.11

Corrections

There was an error in the Renumber Document Numbers function which Microsoft added in the Version NAV 2013 R2. The error was corrected by Microsoft with Cumulative Update 6. Hotfix ID: 357325 Hotfix Title: The Apply-to field on the Apply Vendor Entries page is not updated when you use the Renumber Document Numbers function on the Payment Journal page In NCP Version 7.10 following enhancement has been added: Added function Renumber Document Numbers to the Payment Journal and to the Cash Receipt Journal. The function added in NCP Version 7.10 uses parts of the Microsoft function. Therefore, it is also affected by this error. The Microsoft Hotfix resolves only parts of the errors in this context. NAVAX has decided not to use parts from the Microsoft function for the NCP function anymore. NCP 7.11 fixes the function and other errors that may occur in this context, but only for the function provided by NCP. The Hotfix provided by Microsoft is not part of NCP 7.11. NCP 7.11 does not change or correct the Microsoft function.

The Filter in the Payment Entries was set incorrectly when calling them from the Vendor Card or from the Vendor List.

In certain situations an error occurred after sending an E-Mail from the Pmt. Notification E-Mail Suggestion. Affected Versions: NAV 2009 and higher.

If a Payment Notification was sent by E-Mail, the Pmt. Notification Printed field in the Payment Entries was set to Yes. Affected Versions: NAV 2009 and higher.

NCP 7.10

Improvements

Die Bankcodes wurden überarbeitet. Bei der Eingabe eines SWIFT-Codes wird der Code nun geprüft. Es sind nur SWIFT-Codes mit Länge 8 und 11 möglich. Weiters dürfen die ersten 6 Stellen nur Buchstaben, die restlichen Stellen nur Buchstaben und Zahlen enthalten. Die Bankcode-Tabelle wurde erweitert. Es wird in der Übersicht jetzt auch der ISO Ländercode der Bank angezeigt. Bei der Eingabe eines neuen SWIFT-Codes wird der ISO Ländercode aus dem SWIFT-Code ermittelt. Zusätzlich werden in der Einrichtung der Codes die Anzahl der zugeordneten Bankkonten und Debitor/Kreditor Bankkonten getrennt nach SWIFT-Code und BLZ angezeigt. Beim Import/Export und Download der Bankcodes gibt es (falls bereits Daten in der Tabelle vorhanden sind) jetzt folgende Optionen: Datensätze anlegen wenn nicht vorhanden legt nur neue Bankcodes an. Datensätze anlegen & vorhandene Datensätze überschreiben überschreibt bzw. aktualisiert die vorhandenen Codes (z.B. Feld Name). Werden die Bankcodes über die Funktion Download abgerufen (bzw. Import mit aktuellem Bankcode-File) werden Bankcodes welche nicht mehr im aktuellen Verzeichnis der Österreichischen bzw. Deutschen Nationalbanken enthalten sind als Veraltet gekennzeichnet. Das Feld Veraltet kann auch manuell gesetzt werden.

In der Zahlungsverkehr Einrichtung wurden im Register Version die Felder Datum der Bank Codes, Datum der Zahlungsverkehr Codes und Datum der XML Schemata hinzugefügt. Diese Felder zeigen das Datum des jeweiligen Datenbestandes an, welcher über Import/Download importiert wurde. Mit AssistEdit im Feld kann die Einrichtung der jeweiligen Daten geöffnet werden. Über What's New? hat man die Möglichkeit das jeweilige Datum mit den bereitgestellten Download-Daten zu vergleichen.

Die Zahlungsposten können jetzt auch direkt vom Debitor/Kreditor aus aufgerufen werden.

Über AssistEdit im MT940 Import, Feld Importierte Datei ist es nun möglich den Ordner von welchem die MT940 Datei importiert wurde zu öffnen.

Im Zahlungsvorschlag wurde in den Optionen ein neues Feld Letztes Skontodatum hinzugefügt. Ist das Feld Skonto finden im Zahlungsvorschlag gesetzt wird auf das Skontodatum der Posten jetzt mit diesem Feld gefiltert und nicht mehr mit dem Feld Letztes Fälligkeitsdatum. Ist das Feld leer wird wie bisher das Feld Letztes Fälligkeitsdatum für den Filter verwendet. In der Zahlungsverkehr Einrichtung wurde ein neues Feld Skontodatumsformel hinzugefügt. Ist das Feld gefüllt wird damit beim Aufruf des Zahlungsvorschlags das Feld Letztes Skontodatum auf Basis des Arbeitsdatums vorbelegt.

In der Zahlungsverkehr Einrichtung wurde ein neues Feld Fälligkeitsdatumsformel hinzugefügt. Ist das Feld gefüllt wird damit beim Aufruf des Zahlungsvorschlags das Feld Letztes Fälligkeitsdatum auf Basis des Arbeitsdatums vorbelegt.

In der Zahlungsverkehr Einrichtung wurde ein neues Feld Buchungsdatumsformel hinzugefügt. Ist das Feld gefüllt wird damit beim Aufruf des Zahlungsvorschlags das Feld Buchungsdatum auf Basis des Arbeitsdatums vorbelegt.

Im Zahlungsvorschlag wurde in den Optionen ein neues Feld Ohne Minderungen hinzugefügt. Ist dieses Feld gesetzt werden Posten welche den Betrag mindern würden, also z.B. Gutschriften nicht abgerufen.

Die Zahlungsvorschlagsliste wurde erweitert. Es wird jetzt auch die Belegnr. des Debitoren/Kreditorenpostens angedruckt.

In den Tabellen 21 Debitorenposten und 25 Kreditorenposten wurde ein neues Feld Zahlungsreferenz hinzugefügt. Dieses Feld wird im Zahlungsvorschlag berücksichtigt. Funktionsweise: Ist das Feld Zahlungsreferenz in den Kreditoren/Debitorenposten gefüllt wird beim Zahlungsvorschlag das Feld Zahlungsreferenz im Buchblatt mit diesem Wert vorbelegt. Das Feld Zahlungsreferenz in den Kreditoren/Debitorenposten kann in der Form Kreditorenposten bzw. Debitorenposten vom Benutzer mit F2 geändert werden. Das Feld ist standardmäßig in den Kreditoren/Debitorenposten leer, es wird also nicht vom Zahlungsverkehr vorbelegt. Über eine Individualprogrammierung ist es möglich eine spezielle Logik aufzubauen damit dieses Feld beim Buchen eines Belegs oder an anderen Stellen gefüllt wird. Der Zahlungsverkehr würde das Feld beim Abruf des Zahlungsvorschlags im Buchblatt berücksichtigen.

Die XML Schemata wurden überarbeitet. Folgende Änderungen wurden durchgeführt: Der ISO Ländercode kann jetzt geändert werden bzw. muss jetzt nicht mehr angegeben sein. Wenn ein ISO Ländercode bei einem XML Schema hinterlegt ist muss der ISO Ländercode des Bankkontos mit dem ISO Ländercode des Schemas bei der Erstellung der Zahlungsdatei übereinstimmen. Das Feld IBAN Only möglich zeigt an ob das Schema auch Transaktionen ohne die Angabe von SWIFT-Code unterstützt. (Anmerkung: der SWIFT-Code im eigenen Bankkonto muss immer angegeben werden) Ist IBAN Only möglich können die Felder IBAN Only Inland und IBAN Only Ausland gesetzt werden. Ist IBAN Only Inland gesetzt sind Inlandstransaktionen auch ohne SWIFT-Code erlaubt. Ist IBAN Only Ausland gesetzt sind Auslandstransaktionen auch ohne SWIFT-Code erlaubt. Wird voraussichtlich erst ab 2016 benötigt. Das Feld Sammelbuchung bestimmt wie die Transaktion Bankseitig gebucht wird. Standardmäßig ist dieses Feld leer und wird auch nicht in die Zahlungsdatei geschrieben. Bei der Angabe von Ja oder Nein wird der Indikator ob es sich um eine Sammelbuchung (Ja) oder eine Einzelbuchung handelt (Nein)in der Zahlungsdatei gesetzt. Nur wenn eine entsprechende Vereinbarung für Einzelbuchungen mit dem Kunden vorliegt, wird im Falle von Belegung mit Nein jede Transaktion einzeln auf dem Kontoauszug des Auftraggebers dargestellt. Andernfalls bzw. standardmäßig handelt es sich immer um eine Sammelbuchung (default/pre-agreed: Ja). Das Feld Spesenangabe möglich zeigt an ob das Schema die Angabe von Spesen erlaubt. Das Feld Eilzahlung möglich zeigt an ob das Schema Eilzahlung unterstützt. Datum der Spezifikation und Korrigiert am zeigen interne Informationen zum Schema. In Verwendung zeigt an ob das Schema Bankkonten zugeordnet ist. Nach einem Update von einer früheren Zahlungsverkehr Version müssen die Schemata über Download oder Import aktualisiert bzw. neu angelegt werden. Die Zuordnung der Bankkonten sollte danach ebenfalls überprüft werden da sich teilweise die Schema-Codes geändert haben.

Der Zahlungsverkehr wurde um die Möglichkeit erweitert Non-SEPA Überweisung zu erstellen. Um für ein Bankkonto eine Non-SEPA Überweisung zu erstellen muss dem Bankkonto das entsprechende Schema zugeordnet werden.

Neben Lastschriftart CORE und B2B wurde eine neue Lastschriftart COR1 hinzugefügt.

Die Sprachcode Tabelle wurde um das Feld Alternativer Sprachcode Zahlungsverkehr erweitert. Funktionsweise: Siehe nachfolgende Punkte.

Im Bericht Debitor SEPA Mandat Formular kann man nun über die Optionen im Bericht jetzt einstellen ob Name und Adresse des Debitors bzw. IBAN und SWIFT-Code des Debitor Bankkontos angedruckt werden soll. Zusätzlich wird jetzt neben der Mandat ID auch die Lastschriftart und Lastschriftsequenz angedruckt.

Die SEPA Mandatstexte wurden erweitert. Es können nun unterschiedliche Textbausteine je nach Lastschriftart und Lastschriftsequenz angelegt werden. Im Bericht Debitor SEPA Mandat Formular wird nach folgender Logik der Textbaustein ermittelt: Lastschriftart Lastschriftsequenz Sprachcode Des Mandats Des Mandats Des Debitors Des Mandats Alle Des Debitors Alle Des Mandats Des Debitors Alle Alle Des Debitors Des Mandats Des Mandats Alternativer Sprachcode Des Mandats Alle Alternativer Sprachcode Alle Des Mandats Alternativer Sprachcode Alle Alle Alternativer Sprachcode Es wird also zuerst versucht einen Textbaustein mit dem Sprachcode des Debitors zu finden. Dabei wird zuerst nach einem Textbaustein für genau die Lastschriftart und Lastschriftsequenz des Mandats gesucht, falls kein Textbaustein vorhanden ist, wird nach der Lastschriftart des Mandats und der Lastschriftsequenz Alle gesucht usw. Wurde für den Sprachcode des Debitors kein Textbaustein gefunden wird mit dem Alternativer Sprachcode Zahlungsverkehr, welcher jedem Sprachcode zugeordnet werden kann, gesucht. Das wird nur dann gemacht wenn der Debitor einen Sprachcode angegeben hat. Hat der Debitor keinen Sprachcode hinterlegt, wird nach Textbausteinen ohne Sprachcode gesucht. Hat der Debitor einen Sprachcode hinterlegt, für diesen wurde aber kein Textbaustein gefunden und der Alternativer Sprachcode Zahlungsverkehr ist leer wird ebenfalls nach Textbausteinen ohne Sprachcode gesucht. Wird kein Textbaustein gefunden wird das Debitor SEPA Mandat Formular ohne einen Textbaustein gedruckt.

Die Externe Bankkontosuche in der Zahlungsverkehr Einrichtung wurde um die Option Letzte Transaktion/Hauptbankverbindung erweitert. Diese Option vereint die beiden bisherigen Optionen. Es wird also beim Zahlungsvorschlag, falls keine entsprechende Transaktion gefunden wird, danach weiter nach der Hauptbankverbindung gesucht. Falls nur ein Bankkonto existiert wird dieses verwendet. Je nachdem wie das eigene Bankkonto eingestellt ist und welche Zahlungsart gewählt wurde wird das gefundene externe Bankkonto vorgeschlagen oder nicht. Bedingungen für das Vorschlagen des externen Bankkontos: Bei Zahlungsart SEPA: Wenn der Ländercode des eigenen und des externen Bankkontos SEPA gesetzt haben. Der ISO Währungscode der Transaktion EUR ist. Bei Zahlungsart Non-SEPA: wenn Zahlungsart SEPA nicht möglich ist. Bei EDIFACT Inland (PAYMUL/DIRDEB): Wenn das eigene und das externe Bankkonto im ISO Ländercode als 'AT' definiert sind. Der ISO Währungscode der Transaktion EUR ist. Bei EDIFACT Ausland (PAYMUL): wenn Zahlungsart EDIFACT Inland nicht möglich ist. Das eigene Bankkonto im ISO Ländercode als 'AT' definiert ist. Das externe Bankkonto im ISO Ländercode einen Wert hat (kann auch 'AT' sein z.B. wenn ISO Währungscode der Transaktion nicht EUR ist bzw. Inland nicht möglich ist). Bei MT101 Inland: Wenn der ISO Ländercode des eigenen Bankkontos ident mit dem ISO Ländercode des externen Bankkontos ist. Bei MT101 Ausland: wenn Zahlungsart MT101 Inland nicht möglich ist.

Im Zahlungsvorschlag wird wie bisher bei SEPA Überweisung, SEPA Lastschrift, Inlandsüberweisung (PAYMUL) und Lastschrift (DIRDEB) nach Währungen mit ISO Währungscode 'EUR' gefiltert. Ist die Mandantenwährung in 'EUR' definiert werden auch Posten ohne Währungscode berücksichtigt. Bei Zahlungsart Überweisungsvorschlag, Auslandsüberweisung (PAYMUL), Non-SEPA Überweisung und MT101 Auslandsüberweisung gibt es im Zahlungsvorschlag nun die Möglichkeit das neuen Feld Fremdwährungsfilter zu setzen. Ist das Feld gesetzt wird nach Währungen mit ISO Währungscode ungleich 'EUR' gefiltert. Ist die Mandantenwährung nicht in 'EUR' definiert werden auch Posten ohne Währungscode berücksichtigt. Bei MT101 Inlandsüberweisung wird nicht nach Währungen gefiltert. Wenn nach einer Währung gefiltert wurde erscheint nach dem Abruf ein Hinweis, dass unter Umständen auch noch offene Posten in anderen Währungen vorhanden sind.

Im Zahlungsvorschlag wurde die Option Zahlungsart für Kreditoren um die Option Überweisungsvorschlag, für Debitoren um die Optionen Lastschriftvorschlag und Überweisungsvorschlag erweitert. Wird eine der beiden Optionen gewählt wird folgendes gemacht: Es wird nicht nach Währungscode gefiltert. Es wird versucht in Verbindung mit der Einstellung der Externen Bankkontosuche und dem eigenen Bankkonto das externe Bankkonto und die Zahlungsart zu ermitteln. Hier gilt folgendes: Bei Lastschriftvorschlag werden wie bisher Transaktionen des Debitors innerhalb des Währungscodes gesucht. Da die Zahlungsart aber zu diesem Zeitpunkt nicht feststeht wird nach SEPA Lastschrift und Lastschrift (DIRDEB) gesucht. Bei Überweisungsvorschlag werden wie bisher Transaktionen des Kreditors/Debitors innerhalb des Währungscodes gesucht. Da die Zahlungsart aber zu diesem Zeitpunkt nicht feststeht wird nach SEPA Überweisung, Inlandsüberweisung (PAYMUL), Auslandsüberweisung (PAYMUL), Non-SEPA Überweisung, MT101 Inlandsüberweisung und MT101 Auslandsüberweisung gesucht. Wird eine Transaktion gefunden wird die Zahlungsart und der externe Bankkontocode der Transaktion vorgeschlagen. Wurde keine Transaktion gefunden wird nach den Regeln der externen Bankkontosuche versucht das externe Bankkonto und die Zahlungsart zu ermitteln: Dabei wird bei Lastschriftvorschlag zuerst versucht eine SEPA Lastschrift zu erstellen sofern die Regeln der externen Bankkontosuche zutreffen und das eigene Bankkonto ein SEPA Lastschrift Schema hinterlegt hat. Erst danach wird versucht eine Lastschrift (DIRDEB) zu erstellen. Bei Überweisungsvorschlag wird zuerst versucht eine SEPA Überweisung zu erstellen sofern die Regeln der externen Bankkontosuche zutreffen und das eigene Bankkonto ein SEPA Überweisung Schema hinterlegt hat. Danach wird versucht eine Non-SEPA Überweisung zu erstellen wenn das eigene Bankkonto ein Non-SEPA Überweisung Schema hinterlegt hat. Erst danach wird versucht eine Inlandsüberweisung (PAYMUL) zu erstellen, gefolgt von der Auslandsüberweisung (PAYMUL). Bei MT101 Inlandsüberweisung und MT101 Auslandsüberweisung wird nicht versucht zu erstellen. Trotzdem können auch diese Zahlungsarten vorgeschlagen werden und zwar wenn schon eine Transaktion gefunden wurde. Ist also die Externe Bankkontosuche so eingestellt das letzte Transaktionen berücksichtigt werden und z.B. die letzte USD – Transaktion des Kreditors/Debitors mit MT101 Auslandsüberweisung durchgeführt wurde wird bei weiteren USD – Transaktionen so lange MT101 Auslandsüberweisung vorgeschlagen bis eine Transaktion in USD mit einer anderen Zahlungsart durchgeführt wurde. Die Externe Bankkontosuche, vor allem mit der Option Letzte Transaktion/Hauptbankverbindung in Verbindung mit Lastschrift/Überweisungsvorschlag sollte in den meisten Fällen die optimalen Ergebnisse liefern.

Im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt wurde ein neuer Menüpunkt Zahlungsstatistik hinzugefügt. Die Zahlungsstatistik zeigt alle Beträge des Buch.-Blatts summiert nach Zahlungsart an.

Im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt wurde ein neuer Menüpunkt Belegnummern neu nummerieren im Button Funktion hinzugefügt. Die Funktion erstellt dabei für alle im Buch.-Blatt vorhandenen Zeilen, bei denen weder Scheck gedruckt noch Zahlungsdatei erstellt gesetzt ist, die Belegnr. neu. Anmerkung NAV2013 R2: Ab NAV 2013 R2 ist die Funktion Belegnummern neu nummerieren standardmäßig in den Buch.-Blättern vorhanden. Diese Funktion wurde im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt durch die Funktion aus dem Zahlungsverkehr ersetzt. Die Funktion aus dem Zahlungsverkehr verwendet eine andere Logik für die Neuvergabe der Belegnummern und berücksichtigt dabei auch Buch.-Blattzeilen für welche bereits eine Zahlungsdatei erstellt wurde.

Im Zahlungsvorschlag wurde die Belegnummernvergabe geändert. Es werden jetzt bereits vorhandene Belegnummern in den Buch.-Blattzeilen berücksichtigt und nicht noch einmal vergeben. Weiters wird das Feld Start von Belegnr. auf die nächste freie Nummer der Nummernserie gesetzt. Der Abruf überspringt Belegnummern die bereits im Buch.-Blatt verwendet werden.

Bei Zahlungsdatei erstellen wurden die Optionen und die Dateierstellung selbst geändert. Die Optionen bzw. deren Verfügbarkeit bei Zahlungsdatei erstellen sind abhängig von der der gewählten Bankkontonr. und den dahinter zugeordneten Schemata, der Zahlungsart und der Lastschriftart. Es wurde ein neues Feld Durchführungsdatum Einmalige/Erste Lastschrift hinzugefügt. Es wurde ein neues Feld Spesen hinzugefügt. Es wurde ein neues Feld Eilzahlung hinzugefügt. Die Vorbelegung/Berechnung des Durchführungsdatums hat sich geändert. Das Durchführungsdatum wird jetzt folgendermaßen berechnet: Wird Eilzahlung aktiviert ist wird das Durchführungsdatum auf den heutigen Tag gesetzt. Ansonsten wird das Durchführungsdatum auf den nächsten Tag gesetzt, außer es handelt sich um eine SEPA Lastschrift in Verbindung mit Lastschriftart CORE - Basislastschrift, in diesem Fall wird das Durchführungsdatum auf Heute + 2 Tage gesetzt. Das Durchführungsdatum Einmalige/Erste Lastschrift ist nur bei SEPA Lastschrift in Verbindung mit Lastschriftart CORE - Basislastschrift verfügbar und wird folgendermaßen berechnet: Heute + 5 Tage. Die Option Spesen ist verfügbar unter folgenden Bedingungen: Bei Zahlungsart Auslandsüberweisung (PAYMUL) oder wenn das XML Schema des Bankkontos für die gewählte Zahlungsart Spesen unterstützt. Das Feld wird im Zahlungsposten gespeichert. Diese Option Eilzahlung ist verfügbar wenn das XML Schema des Bankkontos für die gewählte Zahlungsart Eilzahlungen unterstützt. Das Feld wird im Zahlungsposten gespeichert. Durch einige grundsätzliche strukturelle Änderungen bzw. Funktionserweiterungen werden jetzt bei der Dateierstellung folgende Transaktionen in einem Auftragsbestand (B-Level) zusammengefasst: Transaktionen mit selben Währungscode (bisher nur bei EDIFACT Dateien), selber Lastschriftart, Lastschriftsequenz und selben Durchführungsdatum. Die Lastschriftsequenz (früher Bankeinzugsart) wurde entfernt. Es werden jetzt alle Lastschriftsequenzen in eine Zahlungsdatei geschrieben. Pro Lastschriftsequenz wird ein Auftragsbestand geschrieben. Es wird automatisch von Lastschriftsequenz Erster auf Wiederkehrend gewechselt sobald eine weitere Transaktion in der Datei vorkommt. In diesem Fall wird auch das Durchführungsdatum der wiederkehrenden Transaktionen und falls vorhanden letzten Transaktion auf das Durchführungsdatum der ersten Transaktion gesetzt. Das neue Feld Urspr. Lastschriftsequenz in der Buch.-Blattzeile wird befüllt, wenn sich die Sequenz durch die Dateierstellung automatisch ändert. Wird die Transaktion annulliert wird die Lastschriftsequenz wieder zurückgesetzt.

Die Vorgaben in neueren Rulebooks für XML SEPA/Non-SEPA Dateien wurden geändert. Bei Verwendung eines solchen Schemas wird die Transaktionsreferenz in die EndToEndId geschrieben. Damit ist eine Eindeutige ID für eine spätere Zuordnung vorhanden. Das bedeutet aber auch, dass, falls eine Zahlungsreferenz angegeben wurde, diese nicht mehr in die EndToEndId geschrieben werden kann. In dem Fall wird die Zahlungsreferenz als strukturierter Verwendungszweck in die Datei geschrieben. Ein unstrukturierter Verwendungszweck ist in diesem Fall nicht mehr vorhanden bzw. nicht erlaubt. Bei älteren Schemen verändert sich nichts bzw. gibt es folgende Vorgaben: Es wird weiterhin die Zahlungsreferenz (bzw. NOTPROVIDED falls keine Zahlungsreferenz angegeben ist) in die EndToEndId geschrieben. Eine Angabe einer Transaktionsreferenz ist hier nicht möglich. Auch ist bei Angabe einer Zahlungsreferenz kein Verwendungszweck erlaubt bzw wird kein Verwendungszweck in die Datei geschrieben.

Über AssistEdit im Clearingposten, Feld Erstellte Datei ist es nun möglich den Ordner in welchem die Zahlungsdatei erstellt wurde zu öffnen.

Es gibt jetzt eine neue Auswertung Clearingliste. Diese Liste Zeigt Informationen zur erstellten Zahlungsdatei an. Die Liste kann vom Buch.-Blatt, vom Clearingposten oder vom Zahlungsverkehr Menü aufgerufen werden.

Das Feld Status im Clearingposten wurde um die Option Gebucht erweitert. Der Status wird auf Gebucht gesetzt sobald das Buch.-Blatt gebucht wird.

Beim Annullieren eines bereits gebuchten Clearingpostens kommt nun eine weitere Rückfrage.

Der Avis kann jetzt auch per E-Mail verschickt werden. Der Avis E-Mail Vorschlag kann überall aufgerufen werden wo auch Avis drucken aufgerufen werden kann. Funktionsweise: Nachdem die Zahlungsdatei erstellt wurde kann man wie bisher den Avis drucken oder jetzt auch per E-Mail verschicken. Über den Menüpunkt Avis E-Mail Vorschlag wird zuerst ein Vorschlag erstellt. Dieser Vorschlag wird nicht gespeichert sondern bei jedem Aufruf von Avis E-Mail Vorschlag neu generiert. Die E-Mail Adresse an den der Avis geschickt werden soll, wird über das neue Feld Avis E-Mail (Register Kommunikation) beim Debitor bzw. Kreditor hinterlegt. Standardmäßig wird nur für diejenigen Debitoren/Kreditoren ein Vorschlag erstellt, die in diesem Feld eine E-Mail Adresse hinterlegt haben. Ist die Option Inklusive Konten ohne Avis E-Mail beim Vorschlag gesetzt werden auch Debitoren/Kreditoren ohne Avis E-Mail vorgeschlagen. Als Ergebnis des Vorschlags erhält man eine Übersicht mit allen Daten welche man anschließend kontrollieren, überarbeiten und abschließend senden kann. Der Betreff und der Textbaustein für die E-Mails wird in der Zahlungsverkehr Einrichtung unter dem Menüpunkt Avis Text hinterlegt. Der Text kann je nach Sprachcode hinterlegt werden. Der Vorschlag versucht den Sprachcode für den Avis Text folgendermaßen zu ermitteln: Über den Sprachcode des Debitors Alternativer Sprachcode Es wird also zuerst versucht einen Textbaustein mit dem Sprachcode des Debitors zu finden. Wurde für den Sprachcode des Debitors kein Textbaustein gefunden wird mit dem Alternativer Sprachcode Zahlungsverkehr, welcher jedem Sprachcode zugeordnet werden kann, gesucht. Das wird nur dann gemacht wenn der Debitor einen Sprachcode angegeben hat. Hat der Debitor keinen Sprachcode hinterlegt, wird nach Textbausteinen ohne Sprachcode gesucht. Hat der Debitor einen Sprachcode hinterlegt, für diesen wurde aber kein Textbaustein gefunden und der Alternativer Sprachcode Zahlungsverkehr ist leer wird ebenfalls nach Textbausteinen ohne Sprachcode gesucht. Wird kein Textbaustein gefunden wird der Sprachcode des Debitors im Feld Sprachcode Avis Text im Vorschlag angezeigt. Wird ein Textbaustein gefunden wird in das Feld Sprachcode Avis Text der Sprachcode des Textbausteins geschrieben. Der Sprachcode kann vor dem Senden noch verändert werden. Ein E-Mail kann nur dann gesendet werden, wenn ein Avis Text mit einem E-Mail Betreff existiert. Hat der Avis Text zusätzlich einen E-Mail Text hinterlegt wird dieser als Text in das Mail geschrieben. Nachdem alle Daten kontrolliert wurden kann man jedes einzelne Mail oder Alle senden. Avis Mails werden über SMTP gesendet. Dafür wurde die Zahlungsverkehr Einrichtung erweitert. Im Register Avis findet man alle notwendigen Einstellungen für den SMTP-Server. Hier kann man auch hinterlegen ob alle gesendeten Avis Mails als Kopie oder Blind-Kopie an eine weitere Adresse gesendet werden sollen (z.B. für interne Archivierungen, Benachrichtigungen usw.). Beim Senden der E-Mail wird der Avis Report als HTML Datei bzw. in neueren NAV Releases als PDF Datei im Anhang des E-Mails mitgeschickt. Im Zahlungsposten wird dabei das Feld Avis E-Mail gesendet auf Ja gesetzt und die Adresse, Zeit und Datum des E-Mails werden gespeichert. Wird ein Avis erneut gesendet werden diese Daten aktualisiert bzw. überschrieben.

Im Clearingposten wurden die Felder Anzahl Avis und Avis nicht gedruckt/gesendet hinzugefügt. Das Feld Anzahl Avis zeigt die Anzahl der Avis an, welche zu diesem Clearingposten existieren. Das Feld Avis nicht gedruckt/gesendet zeigt an, wie viele Avis noch gedruckt oder per E-Mail gesendet werden müssen.

Im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt wurden die Felder Durchführungsdatum, Avis gedruckt und Avis E-Mail gesendet hinzugefügt. Diese 3 Felder zeigen die jeweiligen Daten aus dem Zahlungsposten an.

In den Zahlungsposten wurde das Feld Anzahl Bankposten hinzugefügt. Dieses Feld entspricht dem Feld Anzahl Bankposten aus den Clearingposten, zeigt allerdings nur Bankposten zu einem Zahlungsposten an.

In der Zahlungsvorschlagsliste wird jetzt nach jeder Buch.-Blattzeile eine Linie angedruckt. Die Aufteilung des Zeilenbetrags bzw. der Ausgleich ist dadurch auch am Bericht ersichtlich.

Modifications

Die MT940 Buchungscodes und MT940 Geschäftsvorfallcodes wurden in eine gemeinsame neue Tabelle Zahlungsverkehr Codes zusammengelegt. Diese Tabelle wird ab jetzt für alle Codes verwendet. Für Zahlungsverkehr Codes stehen Import/Export und Downloadfunktionen zur Verfügung. Beim Import/Export und Download der Zahlungsverkehr Codes gibt es (falls bereits Daten in der Tabelle vorhanden sind) jetzt folgende Optionen: Datensätze anlegen wenn nicht vorhanden legt nur neue Zahlungsverkehr Codes an. Datensätze anlegen & vorhandene Datensätze überschreiben überschreibt bzw. aktualisiert die vorhandenen Codes (z.B. Feld Beschreibung).

Der Aufruf der Clearingposten über ein Bankkonto zeigt keine annullierten Posten mehr. Der Filter kann durch den Benutzer aufgehoben werden.

Der Aufruf der Zahlungsposten über ein Bankkonto bzw. Debitor/Kreditor Bankkonto zeigt keine annullierten Posten mehr. Der Filter kann durch den Benutzer aufgehoben werden.

Das Feld Buchungscode im MT940 Import wurde in SWIFT Transaktionscode umbenannt.

Das Feld Gegenkontoart im Zahlungsposten wurde in Kontoart umbenannt. Das Feld Gegenkontonr. im Zahlungsposten wurde in Kontonr. umbenannt.

Bankeinzugsmethode wurde in Lastschriftart umbenannt. Bankeinzugsart wurde in Lastschriftsequenz umbenannt.

Die Darstellung der Zahlungsdatei-Einstellungen in der Zahlungsverkehr Einrichtung wurde geändert. Die Einstellungen werden nun in einer übersichtlicheren tabellarischen Form angezeigt.

Das Feld Gegenkonto Sammelbuchungszeile erstellen in der Zahlungsverkehr Einrichtung wurde in Gegenkontozeile erstellen umbenannt. Eine Gegenbuchungszeile wird jetzt nur mehr erstellt, wenn mehr als eine Buch.-Blattzeile für eine Gegenbuchungszeile vorhanden ist. Weiters wurde das Verhalten bei der Zusammenfassung von Buch.-Blattzeilen mit unterschiedlichen Belegarten (Zahlung, Erstattung,…) verändert. Bisher wurden diese Zeilen zu einer Gegenbuchungszeile zusammengefasst und man konnte das Buch.-Blatt nicht mehr buchen. Das wurde korrigiert. Bei unterschiedlichen Belegarten wird die Gegenbuchungszeile jetzt nur mehr dann erstellt, wenn alle beteiligten Buch.-Blattzeilen eine Ausgleich mit Belegnr. gesetzt haben. Ist dies der Fall wird dabei bei allen betroffenen Buch.-Blattzeilen die Belegart auf Zahlung gesetzt.

Das Feld Zahlungsreferenz wurde von Numerisch auf Alphanumerisch geändert und auf 35 Stellen erweitert. Bei der Eingabe einer Zahlungsreferenz im Buch.-Blatt wird diese nicht mehr automatisch mit führenden Nullen auf 12 Stellen ergänzt.

Es können jetzt beliebig viele SEPA Mandate zu einem Debitor Bankkonto zugeordnet werden. SEPA Mandate werden jetzt nicht mehr direkt am Debitor Bankkonto hinterlegt sondern in einer dahinterliegenden Tabelle. Über den Menüpunkt SEPA Mandate in der Debitor Bankkontokarte können die Mandate hinterlegt werden. Funktionsweise: Eine Mandat ID kann pro Debitor Bankkonto nur einmal vergeben werden. Es ist aber möglich dieselbe Mandat ID auch in anderen Debitor Bankkonten zu verwenden. In diesem Fall erscheint ein Hinweistext das die Mandat ID bei mindestens einem weiteren Debitor Bankkonto verwendet wird. Die Lastschriftsequenz bestimmt, ob es sich um ein Einmaliges oder ein Wiederkehrendes Mandat handelt. Das Feld Anzahl Zahlungsposten zeigt die Anzahl der Zahlungsposten (unabhängig von der Lastschriftsequenz) für das Mandat an. Das Feld Letzte Lastschrift erstellt zeigt an ob ein Zahlungsposten mit Lastschriftsequenz Letzter vorhanden ist. Das Feld Erste Lastschrift erstellt kann manuell gesetzt werden falls es zwar noch keine Zahlungsposten für das Mandat gibt, das Mandat aber schon in anderen Systemen bzw. vor einer Datenübernahme verwendet wurde. Der Zahlungsvorschlag versucht Mandate aufgrund folgender Regeln zu ermitteln: Es werden nur Mandate berücksichtigt: Bei denen das Feld Mandat erteilt am ausgefüllt und vor oder gleich dem Tagesdatum ist/liegt. Bei denen das Feld Mandat gültig bis leer, nach oder gleich dem Tagesdatum ist/liegt. Sobald ein Mandat gefunden wurde wird ermittelt ob es dazu schon Zahlungsposten gibt. Bei einmaligen Mandaten wird geprüft ob das Feld Erste Lastschrift erstellt gesetzt ist oder ob bereits Zahlungsposten vorhanden sind. Ist das der Fall wird nach dem nächsten Mandat gesucht. Ansonsten wird das Mandat vorgeschlagen. Bei Wiederkehrenden Mandaten wird geprüft ob ein Zahlungsposten mit Lastschriftsequenz Letzter vorhanden ist. Ist das der Fall wird nach dem nächsten Mandat gesucht. Ansonsten wird das Mandat vorgeschlagen. Die Lastschriftsequenz wird dabei auf Erster gesetzt wenn noch kein Zahlungsposten vorhanden ist und das Feld Erste Lastschrift erstellt nicht gesetzt ist. Ansonsten wird die Lastschriftsequenz auf Wiederkehrend gesetzt. Eine Änderung der Daten im Buch.-Blatt bzw. eine manuelle Vergabe von Mandaten im Buch.-Blatt, welche nicht beim Debitor Bankkonto hinterlegt wurden ist wie bisher weiterhin möglich. Das Feld Mandat ID kann auch über ein Lookup im Buch.-Blatt ausgewählt werden.

Bisher wurde zu jedem Zahlungsposten die Belegnr. und das Buchungsdatum der Buch.-Blattzeile gespeichert. Je nach Einstellungen im Zahlungsverkehr kann es sein, das für mehrere Buch.-Blattzeilen nur ein Zahlungsposten existiert. Sollte es in diesem Fall unterschiedliche Daten in den beiden Feldern der Buch.-Blattzeilen geben, wurden die Felder im Zahlungsposten nicht befüllt. Beim Buchen der Buch.-Blattzeilen kann es weiters vorkommen, dass je nach Einstellung der Nummernserie bzw. Buchungsnr.-Serie die Belegnr. bei der Buchung neu vergeben wird. Ein Navigate war in diesem Fall nicht mehr möglich bzw. brachte falsche Ergebnisse. Aus diesem Grund wurde eine neue Tabelle Zahlungsbuchungsposten angelegt welche zu jedem Zahlungsposten die während der Buchung entstehenden Belegnummern und Buchungsdatumswerte zu diesem Zahlungsposten speichert. Das neue Feld Anzahl Zahlungsbuchungsposten im Zahlungsposten zeigt die Anzahl der dahinterliegenden Belegnummern bzw. Buchungsdatumswerte an. Die neunen Felder Gebucht mit Belegnr. und Gebucht mit Buchungsdatum im Zahlungsposten zeigen jeweils die Werte des ersten Zahlungsbuchungspostens an. Navigate verwendet nur mehr diese tatsächlich gebuchten Werte. Wird Navigate direkt im Zahlungsposten aufgerufen und es existieren mehrere Zahlungsbuchungsposten zum Zahlungsposten wird Navigate mit dem ersten gefundenen Datensatz aufgerufen. Die Felder Belegnr. und Buchungsdatum im Zahlungsposten wurden entfernt.

XML bzw. SEPA und Non-SEPA Zahlungsdateien unterstützen jetzt mehrere Auftragsbestände (B-Level) innerhalb einer Datei.

Die Generierung der Auftragsreferenz (Bestandskontrollnr.) und Transaktionsreferenz (Auftraggeberreferenz) wird nun bei der Erstellung der Zahlungsverkehrsdatei unabhängig von der Zahlungsart immer nach demselben Schema generiert. Basis für die Referenzfelder ist wie bisher auch die Dateireferenz.

Die erlaubten Zeichenausnahmen für Österreichische Bankkonten wurden geändert. Grundsätzlich sind folgende Zeichen erlaubt: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 /-?:().,'+ Leerzeichen Bisher war es so, dass bei Österreichischen Bankkonten zusätzlich folgende Zeichen erlaubt waren: &; Zusätzlich wurden folgende Zeichen automatisch konvertiert: < wurde zu '&lt;' > wurde zu '&gt;' & wurde zu '&amp;' " wurde zu '&quot;' ' wurde zu '&apos;' Diese automatische Konvertierung wurde geändert. Im XML Schema kann nun das Feld Erweiterter Zeichensatz gesetzt werden. Ist das Feld gesetzt wird in diesem Schema die oben genannte Konvertierung durchgeführt. Ist das Feld Erweiterter Zeichensatz nicht gesetzt wird das Zeichen & automatisch zu + konvertiert, alle anderen Zeichen werden durch ein Leerzeichen ersetzt.

Bisher wurden beim Erstellen der Zahlungsdatei alle 8 Stelligen SWIFT-Codes mit XXX ergänzt. Ab jetzt werden SWIFT-Codes des eigenen Bankkontos nicht mehr mit XXX ergänzt. SWIFT-Codes des Externen Bankkontos werden nur mehr mit XXX ergänzt wenn das neue Feld Externen SWIFT-Code mit XXX ergänzen in der Zahlungsverkehr Einrichtung gesetzt ist.

Bei SEPA bzw. XML Transaktionen mit Avis wurde in der Zahlungsdatei der Hinweistext See Notification gefolgt von der Avisnr. geschrieben. Bei EDIFACT und MT101 Zahlungen ist der Text abhängig vom ISO Ländercode des Externen Bankkontos. Bei AT, DE und CH wird hier Siehe Avis gefolgt von der Avisnr. geschrieben. Diese Logik ist jetzt auch bei SEPA bzw. XML Zahlungen aktiv. Weiters kann der Text jetzt auch im Menü Zahlungsverkehr unter Einrichtung im Avis Text im Feld Zahlungsdateitext hinterlegt werden. Wird kein Avis Text gefunden, oder ist das Feld leer wird der Text über die vorher beschriebene Logik ermittelt. Der Zahlungsdateitext kann je nach Sprachcode hinterlegt werden. Es wird versucht den Sprachcode für den Avis Text folgendermaßen zu ermitteln: Über den Sprachcode des Debitors Alternativer Sprachcode Es wird also zuerst versucht einen Textbaustein mit dem Sprachcode des Debitors zu finden. Wurde für den Sprachcode des Debitors kein Textbaustein gefunden wird mit dem Alternativer Sprachcode Zahlungsverkehr, welcher jedem Sprachcode zugeordnet werden kann, gesucht. Das wird nur dann gemacht wenn der Debitor einen Sprachcode angegeben hat. Hat der Debitor keinen Sprachcode hinterlegt, wird nach Textbausteinen ohne Sprachcode gesucht. Hat der Debitor einen Sprachcode hinterlegt, für diesen wurde aber kein Textbaustein gefunden und der Alternativer Sprachcode Zahlungsverkehr ist leer wird ebenfalls nach Textbausteinen ohne Sprachcode gesucht.

Das Feld Durchführungsdatum wurde aus den Clearingposten entfernt da das Datum nicht mehr auf dieser Ebene eindeutig ist.

Das Feld Empfängerreferenz im Zahlungsposten wurde auf 35 Stellen gekürzt und wird nur mehr bei Zahlungsart Inlandsüberweisung (PAYMUL), Lastschrift (DIRDEB) und Auslandsüberweisung (PAYMUL) befüllt.

Das Feld Avis Anzahl gedruckt im Zahlungsposten wurde in Avis gedruckt umbenannt. Das Feld wurde in ein Ja/Nein Feld geändert und zeigt jetzt an ob ein Avis gedruckt wurde oder nicht.

Es wurden allgemein die Meldungen, Fehlermeldungen und Captions verbessert.

Corrections

Im Zahlungsvorschlag wurden bei Skonto finden in Verbindung mit Skontotoleranz berücksichtigen nicht alle zukünftigen Posten abgerufen. Wenn das Buchungsdatum des Zahlungsvorschlags zwischen dem Skontodatum und dem Skontotoleranzdatum des Postens lag und das Letzte Fälligkeitsdatum des Zahlungsvorschlags vor dem Skontotoleranzdatum lag wurde der Posten nicht abgerufen. Dies wurde korrigiert.

Die Ermittlung des Verwendungszwecks in der Zahlungsvorschlagsliste, im Avis und in den Verwendungszweckposten konnte in gewissen Konstellationen verwirrende Ergebnisse liefern. Das Problem trat in Verbindung mit Ausgleich mit Belegnr. auf wenn mehrere Buch.-Blattzeilen dieselbe Ausgleich mit Belegnr. verwendeten. In diesem Fall konnten die Verwendungszwecke nicht richtig berechnet werden. Dies hatte weder Auswirkung auf die Buchung noch auf die Beträge in der Zahlungsdatei. Allerdings war der Aufbau des Verwendungszwecks in diesem Fall etwas irreführend. Beispiel: Es existieren 2 offene Kreditorenposten, einmal mit 200 Euro, einmal mit 1000 Euro. Beide Posten haben dieselbe Belegnr.: XYZ. Nach dem Abruf des Zahlungsvorschlags erhält man 2 Buch.-Blattzeilen welche beide im Feld Ausgleich mit Belegnr. XYZ gesetzt haben. Beim Berechnen des Verwendungszwecks findet die erste Buch.-Blattzeile mit 200 Euro den ersten offenen Posten. Hier wird der Verwendungszweck richtig berechnet. Die 2. Buch.-Blattzeile mit 1000 Euro findet ebenfalls den ersten offenen Posten mit 200 Euro und geht beim Verwendungszweck davon aus das 200 Euro für den Posten verwendet werden und der Restbetrag von 800 Euro zusätzlich als Zahlung an den Kreditor gehen. Dies wurde korrigiert. Die Berechnung des Verwendungszwecks berücksichtigt jetzt eventuell vorhandene Buch.-Blattzeilen für die ebenfalls dieselbe Ausgleich mit Belegnr. gesetzt ist.

NCP 7.02

Improvements

Added a new Option Consider Payment Discount Tolerance to the Payment Suggestion. If the option is selected, and the field Block Payment Tolerance in the Vendor/Customer Card is not activated, the Pmt. Disc. Tolerance Date from the Entries will be considered in the Discount Calculation. If additional the option Find Payment Discounts is selected, the search for potential (future) payments will not only filter the Pmt. Discount Date but also the Pmt. Disc. Tolerance Date. This improvement is not available for NAV 3.60.

When creating the Payment Suggestion detailed information about the current progress will be displayed in a window now.

In Payments, it is now possible to export Vendor and Customer Bank Accounts in a CSV file and import from there back later. You can find this functionality in Payments Menu > Setup > Bank Accounts Export/Import. With the function Export Bank Accounts, the bank account information can be exported in the format: InternalType;InternalNo;InternalCode;Bank Branch No.;Bank Account No.;SWIFT Code;IBAN and then be forwarded for review. The fields InternalType, InternalNo and InternalCode should not be changed otherwise the information cannot be mapped correctly on import. When exporting, all blanks from the fields Bank Branch No., Bank Account No., SWIFT Code and IBAN will be removed in the file. With the function Import Bank Accounts, the revised bank account data will be imported. With the Existing Values option field of the Import it can be specified what should happen with already existing values. The field Existing Values offers the following options: Keep and update empty Fields If selected, only fields will be updated which currently don't have a value in the database. Replace if new Value not empty If selected, a field will be updated if the file contains a value, regardless of the current value of the field in the database. Replace all If selected, all fields in the database are overwritten with the values in the file. Valid for all options: If the content of the field in the database will not differ from the content of the file the field will not be changed. Furthermore, the Import has an additional option Create Bank Codes. If this option is selected the Import will create Bank Codes if they do not exist. Additional notes: Not all data must be exported. When importing only those bank account information are updated in the database that are in the file. All bank accounts in the file that no longer exist in the database, will be skipped.

MT940 files from BAWAG P.S.K. may contain additional information in the subfields of the block 86. Information from BAWAG P.S.K.: Due to various customer requirements, these specifications are used as an additional service of BAWAG P.S.K. for better allocation of various payments: /AIK/ This is the Image key (AIK) of scanned documents. AIK is a bank mark of the first recording reference or image reference. /AES/ This is an output collector with images. AES is a bank mark of an inventory reference or compressor reference. In Payments, this information is now stored in the new fields AIK Reference and AES Reference of the Posting Lines.

Modifications

In the NAV 2013 standard Payment Suggestion checks on the Vendor-Level has been added. Based on the current value of the field Balance (MW) the Vendor will be skipped or not. These checks, which were taken over by NCP 7.00, have now been removed or disabled because at this time not all the necessary information is available. E.g. the field On Hold from the entries was not considered. Also entries which already been suggested in a journal were not considered.

Corrections

MT940 files which contained the maximum number of lines in the unstructured Remittance Information (Block 86) could not be read. The "MT940 Import" stopped with an error message: The selected File is not a MT940 File.

The field lengths and relations of the fields User ID and External Document No. were not correct in the payment objects of the NAV 2013 version.

NCP 7.01

Improvements

Following fields have been added to the Cash Receipt Journal: Direct Debit Method SEPA Mandate ID SEPA Date of Mandate SEPA Direct Debit Type These fields are filled when data is entered into the field External Bank Account Code or via the report Suggest Customer Payments and can be changed in the journal if necessary. The field Direct Debit Method offers the following options: Core (CORE) Business to Business (B2B) Non Pre-authorised Direct Debit Pre-authorised Direct Debit The default setting is based on the chosen Payment Type (Direct Debit (DIRDEB) or SEPA Direct Debit (SDD)) and the Direct Debit Method (DIRDEB) and SEPA Direct Debit Method (SDD) field settings stored on the Customer Bank Account Card. If Payment Type = SEPA Direct Debit (SDD) the additional fields SEPA Mandate ID and SEPA Date of Mandate are filled with the settings from the Customer Bank Account Card. The field SEPA Direct Debit Type offers the following options: One-Off Recurrent First Final The default value is determined by the Payment Entries already posted. If a Payment Entry for the Customer and External Bank Account Code exists, which contains the same content in the fields SEPA Mandate ID and SEPA Date of Mandate, the option Recurrent is proposed. If no Entry is found, the value First is proposed. Note: Recurrent is proposed at the earliest after the first/next SEPA Direct Debit posting because the required information is not included in the previous Payment Entries.

Following fields have been added to the Payment Entries: Direct Debit Method SEPA Mandate ID SEPA Date of Mandate SEPA Direct Debit Type

Modifications

One-Time Credit Transfer has been renamed to One-Time Transfer and is now also available for Direct Debits.

Corrections

In certain constellations and in conjunction with the Role Tailored Client no Customer Ledger Entries were displayed on the Payment Suggestion List.

NCP 7.00

Improvements

It is now possible to create Dom. Credit Transfer (MT101) and Int. Credit Transfer (MT101) with NC Payments.

Dom. Credit Transfer (PAYMUL), Int. Credit Transfer (PAYMUL), Dom. Credit Transfer (MT101) and Int. Credit Transfer (MT101) are now available in the Cash Receipt Journal.

Dom. Credit Transfer (MT101) and Int. Credit Transfer (MT101) are now available in the Payment Journal.

Added the field SWIFT Code MT101 Agency to the Bank Account Card.

A new placeholder %11 was added to the Remittance Info. fields in the Payment Setup. It can be used to fill the Remittance Info. with the field Document Date.

The Payment Suggestion List now also prints the Name of the Vendor/Customer/Bank Account/GL Account.

Added a new field Payment Text to the Payment Journal and the Cash Receipt Journal. A new placeholder %12 was added to the Remittance Info. fields in the Payment Setup. It can be used to fill the Remittance Info. with the field Payment Text from the Journals. The Payment Text field is hidden by default. The field is not filled by NC Payments. Es kann also manuell vom Benutzer befüllt werden oder für eine Kundenanpassung frei verwendet werden. It can therefore be filled manually by the user or be used freely for customization.

It is now possible to import MT940 files which contains Disposed Transactions. Disposed Transaction Blocks will be skipped.

The register Company in the Payment Setup was renamed to Originator. Also added a new field Country/Region Code.

Added a new field External Bank Account Code to table 21 Cust. Ledger Entry and 25 Vendor Ledger Entry. This field is considered in the Payment Suggestion. How it works: If the field External Bank Account Code in the Vendor/Customer Ledger Entries is filled the Payment Suggestion fills the field External Bank Account Code in the Journal with that value. The user can use F2 to change the field External Bank Account Code in the Vendor/Customer Ledger Entries form. The field in the Vendor/Customer Ledger Entries is empty by default, it is not preassigned by NC Payments but it is possible to build a special logic via custom programming so that this field will be filled when posting a document or elsewhere. NC Payments consider the field in the Journal when calling the Payment Suggestion.

It is now allowed to create an Int. Credit Transfer (PAYMUL) within Austria even if both banks (Sender/Receiver) have 'AT' as their ISO Country Code.

SWIFT Codes of length 8 (missing branch or department identification) are now extended to 11 characters by adding XXX when the payment file is generated.

Added a new field External Bank Account Search to the Payments Setup. This field is considered in the Payment Suggestion. How it works: The field has 2 options: Main Bank Account and Last Transaction. If the option Main Bank Account is selected the Payment Suggestion tries to determine the External Bank Account Code as previously via the Main Bank Account Flag from the Vendor/Customer Bank Account. If there is no Main Bank Account for the Vendor/Customer, the field is filled if the Vendor/Customer has only one bank account. If the option Last Transaction is selected the Payment Suggestion tries to determine a value based on the last transaction of the bank account with the same Payment Type, Vendor/Customer No. and Currency Code. In both cases: If the field External Bank Account Code in the Vendor/Customer Ledger Entry contains a value this value is proposed.

Following new fields have been added to the Payments Setup: SEPA Collective Transaction (SCT) SEPA Collective Transaction (SDD) Dom. Collective Transaction (PAYMUL) Dom. Collective Transaction (DIRDEB) Int. Collective Transaction (PAYMUL) Dom. Collective Transaction (MT101) Int. Collective Transaction (MT101) These fields can be used to determine whether transactions should be combined and transmitted as a collective transaction to the bank when creating the payment file. The following transactions are not affected: One-Time Transfers Transfers with a Payment Reference. Otherwise, NC Payments try to combine journal lines with same Vendor/Customer/Bank Account No., External Bank Account Code and Currency Code to one transaction. For Credit Transfers it is now also possible to include Credit Memos which are entered in the journal via Applies-to Doc. No.. The requirement is that the collective transaction has a positive amount. The same applies vice versa for Direct Debits. The single transactions are shown in the Remittance Info. and on the Payment Notification report. This functionality especially makes sense if Summarize per Vendor or Summarize per Customer in the Payment Suggestion is not used. Payment Entries resulting from grouped journal lines are marked as Collective Transaction. Furthermore, the Description field of the Entries is filled with Collective Transaction. The fields Document No. and Posting Date of an Entry will only be filled if there are no differences within the collective transaction. If the journal lines but have different content, the corresponding field is left blank.

Added a new field Notification No. Printed to the table Payment Entry. This field indicates how often the Payment Notification report for the entry was printed. The application automatically updates this field.

It is now possible to define Remittance Info. Headers for Dom. Credit Transfer (PAYMUL) and Direct Debit (DIRDEB) in the Payments Setup. If the corresponding header field contains text it will be printed in the first row of the Remittance Info. Example: Remittance Info. Header: 'Info/Amount (Discount)' Remittance Info.: '%1 %2/%6[ (%7)]' Result: Info/Amount (Discount) Payment 00112300/12.500 (500) Payment A312-5/1000 Payment B312-5/990 (10) Payment 01004565B/2300

Clearing Entries are now accessible directly from the main menu entry History.

The functionality Void Payment File can now be called directly from the Clearing Entries.

Added new field Save Embedded Clearing File to Payment Setup. When this field is activated a copy of the payment file will be saved to the database for every Clearing Entry.

The following new placeholders were added for File Names in the Payment Setup: %7 File Reference, %8 Clearing Entry No., %9 User ID

The fields Bank Branch No. and SWIFT Code can now be selected from a new table Bank Code using LookUp. This function is the same as that of the Post Code/City fields in the Standard Application. This means that the Bank Code table does not necessarily have to contain the Bank Branch No. or the SWIFT Code. Import/Export and Download functions are available for Bank Codes. Bank Codes for Austria and Germany are currently available for downloading.

Instead of the Button Create now Import/Export and Download functions are available for MT940 Posting Codes and MT940 Transaction Codes.

Following new fields have been added to the Payments Setup: SEPA Always Create Notification (SCT) SEPA Always Create Notification (SDD) Dom. Always Create Notification (PAYMUL) Dom. Always Create Notification (DIRDEB) Int. Always Create Notification (PAYMUL) Dom. Always Create Notification (MT101) Int. Always Create Notification (MT101) These fields can be used to control whether an Payment Notification should always be created when the payment file is created, regardless of whether or not the Remittance Info. can be transmitted fully or not.

Modifications

The version list of the objects has been changed from NCZV to NCP.

The extensions in the field Bank Payment Type from the journal line have been removed and are now in the new field Payment Type.

When entering the Sender Identification or Receiver Identification on the Bank Account Card now all entered spaces will be removed.

Removed the field Payment Reference from table 21 Cust. Ledger Entry. Added a new field Payment Reference Field No. to the Payments Setup where you can now specify the field from the table Cust. Ledger Entry which contains the reference. If necessary, a field and the reference allocation should be implemented via custom programming as there is no universal approach at which time the reference is determined and how this reference is then provided to the Customer for payment. The functions for Suggest Application in the Bank Acc. Reconciliation (After reading a MT940 file) now considers the new field Payment Reference Field No. from the Payments Setup.

Removed the fields SEPA Split Amount and SEPA Split Amount Limit from the Bank Account Card.

Changed the verification checks for Bank Branch No., Bank Account No., SWIFT Code, IBAN and Routing.

The field Bank Posting Schema from the Payments Setup has been changed. The field had 2 options Lines and Accounts. Lines had no effect. Accounts created a Bal. Account Line in the Journal for lines with same Account, Posting Date, Document No. and Currency Code when the Payment File was created. The field was replaced by the new field Create Bal. Account Collective Posting Line.

The generation of the Order Reference and Sender Reference during the creation of the payment file has been changed. The File Reference is the basis for the reference fields, as was previously the case.

Renamed the field Payment Bank Account Code in NC Payments to External Bank Account Code.

The allowed characters for SEPA files have been changed. The following characters are allowed: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 /-?:().,'+ Blank/Space The following additional characters are allowed for Austrian bank accounts: &; Umlauts are converted automatically as before. 'Ä' becomes 'Ae', 'Ö' becomes 'Oe' etc. The following additional characters are converted automatically for Austrian bank accounts: < becomes '&lt;' > becomes '&gt;' & becomes '&amp;' " becomes '&quot;' ' becomes '&apos;' For all other bank accounts following characters will be automatically converted: & becomes + Characters remaining after the conversion which are not allowed in the file will be replaced by Blank/Space.

The behavior of the Vendor/Customer Payment Suggestion has been modified. How the Payment Suggestion works: If no Payment Type is selected the suggestion for Vendors will only propose Vendors to whom an amount is payable. On the Customer side only Customers from whom an amount is receivable will be proposed. The following applies to both sides: If Payment Type Dom. Credit Transfer (PAYMUL), Int. Credit Transfer (PAYMUL), SEPA Credit Transfer (SCT), Dom. Credit Transfer (MT101) or Int. Credit Transfer (MT101) is selected then the suggestion will only propose Vendors/Customers to whom an amount is payable. If Direct Debit (DIRDEB) or SEPA Direct Debit (SDD) is selected then the suggestion will only propose Vendors/Customers from whom an amount is receivable. Additionally, a filter for amounts in EURO is applied if Dom. Credit Transfer (PAYMUL), Direct Debit (DIRDEB), SEPA Credit Transfer (SCT) or SEPA Direct Debit (SDD) is selected.

The verification of changes to Applications (Applies-to ID, Applies-to Doc. Type/No.) after a payment file has been created have been improved.

Replaced the field Payment Created in the journal line with the new field Payment Status.

The field SEPA Remittance Info. Length was removed from the Payment Setup. The length is now determined automatically by the SEPA Schema.

Corrections

It is now only possible to set one bank account as Main Bank Account for each Vendor/Customer.

NCP 6.19

Improvements

Swiss SEPA Schemas are now available.

Added new field Save Embedded MT940 File to Payment Setup. When this field is activated a copy of the MT940 file will be saved to the database for every MT940 Import. Added new field Embedded File Exists to the MT940 Import Form. This field is not visible by default. By clicking on the field, the file can be deleted or exported.

Modifications

Changed the Design of the MT940 Import Form.

Corrections

It is now possible to import MT940 Files which contains Header/Block Information.

NCP 6.18

Modifications

In case of foreign transfers the part Name of the Bank and Location of the Branch (both 70 characters) in the Segment Group 12 FII C088 has been filled with the information of the Account Holder. This has been changed. Name of the Bank will now be filled with Name and Name 2 from the Account Holder‘s Bank Account Card. "Location of the Branch" will be filled with the Address, Address 2, Post Code, City and Country/Region from the Account Holder‘s Bank Account Card.

Until now the Account Holder fields have been filled with the Name and City of the Account Holder. The field Name 2 has been added.

NCP 6.16

Corrections

An empty FTX Block (Segment Group 16) was written in the Payment File if no Remittance Information exists for the transaction.

The total order sum (Segment Group 5) could deviate from the sum of the individual transactions in certain constellations for Int. Credit Transfer (PAYMUL). This concerned the bank software display only and did not affect the amounts to be transferred.

The Sender Reference was not unique in certain constellations.

NCP 6.15

Modifications

So far, if no Payment Reference was specified, the Sender Reference was written to the <EndToEndId> in SEPA Files. Due to a change that is no longer possible. The <EndToEndId> can now only contain the Payment Reference or the value NOTPROVIDED.

NCP 6.14

Improvements

The MT940 Import can now also import unstructured Remittance Information.

Additional Codes have been added to the Create function in the MT940 Transaction Codes form. The program now proposes AT and DE Codes.

NCP 6.13

Corrections

In the NCP 6.12 release for NAV 3.60 and NAV3.70 it was not possible to select the Bank Payment Type in the Report Suggest Vendor Payments (ID 393). Version NCP 6.13 is only available for NAV 3.60 and NAV 3.70.

NCP 6.12

Improvements

The Field Modify allowed after File Created from the Payment Setup now also affect the Application in the Journal. If the field is not activated the Application in the Journal cannot be changed if the Journal Line has the Status Payment created.

It is now possible to add Comments to every Bank Account Ledger Entry, Clearing Entry, Payment Entry and Remittance Entry.

The verification of Applies-to ID in the Payment Suggestion has been improved.

Routing (used in EDIFACT files) now finds more countries.

EDIFACT files can now be created even if only the IBAN is specified. This means Bank Branch No. and Bank Account No. are no longer mandatory fields.

A new placeholder %6 was added for File Names in the Payment Setup. It can be used to add the Bank Account No. to the file name.

A new placeholder %10 was added to the Remittance Info. fields in the Payment Setup. It can be used to fill the Remittance Info. with the field Description from the Journal Line.

The maximum number of characters for a Remittance Info. placeholder can now be limited in the Payment Setup. This can be done by specifying a numerical value within angle brackets directly after the placeholder.

The MT940 Import can now also import MT940 files which contains IBAN and SWIFT Code. For this the MT940 Bank Account Mapping has been changed. The Account Information (Bank Account Identification) will no longer be split up. This allows to read an assign files with less rigid Bank Account Mapping formats.

The file generation for SEPA has been changed. The structure of the XML file is no longer a fixed part of the code but must be setup. In Payments there is a new Menu Item SEPA Schemas where the different SEPA formats can be defined. Import/Export and Download functions are available for SEPA Schemas. After downloading (or import) of the required Schemas they must be assigned to the bank accounts. The system currently supports Credit Transfer (SCT) and Direct Debit (SDD) Schemas. At the time of this release Schemas for Austria and Germany are available as download. Depending on which Schema was allocated to the Bank Account, the XML files are different in their structure (e.g. DE or AT format). The Bank Account's ISO Country Code must match the ISO Country Code of the Schema when creating the payment file.

Modifications

If no Remittance Info. exists for a SEPA transaction n/a will be written to the file.

NCP 6.11

Improvements

The Payment Suggestion has been added to the Payment Journal and Cash Receipt Journal Menu in the Role Tailored Client.

The Payment Suggestion now checks the Applies-to ID for Vendor and Customer Ledger Entries and releases them when they are no longer used in the system.

Modifications

Wrong Caption was displayed in the Role Tailored Client for Payment Entries.

The function Create Payment File now ignores spaces in the Bank Account fields Sender Identification and Receiver Identification.

Changed the Create Payment File file handling for the Role Tailored Client.

Corrections

The Remittance Entries (payment details) were not calculated correctly in certain situations. This had an effect on the results of the Payment Suggestion List, Payment Notification and Remittance Information in the payment file.

Docs  /  NCP Payments (NAV)  /  Appendix
Upgrade to Business Central

Prerequisites for the Upgrade

• Minimum NCP 13.00 Older versions of NCP must first be updated in NAV.

Files for the upgrade

Preparation 1: Rename old tables in the NAV database

Preparation 2: Rename old fields in the standard tables of the NAV database

APPLICATION UPGRADE

[Microsoft Docs] Business Central - Upgrading Customized C/AL Application to Microsoft Base Application Version 19

Task 3: Move code customizations to extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-3-move-code-customizations-to-extensions

Task 4: Create empty System, Base, and customization extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-4-create-empty-system-base-and-customization-extensions

Task 5: Create table migration extension

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-5-create-table-migration-extension

migration.json
{
    "apprules": [
        {
            "id": "63ca2fa4-4f03-4f2b-a480-172fef340d3f"
        },
        {
            "id": "437dbf0e-84ff-417a-965d-ed2bb9650972"
        },
        {
            "id": "2c40ba68-7b3b-4783-ba82-b1094db31332"
        }
    ]
}

Task 10: Publish DestinationAppsForMigrations extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-10-publish-destinationappsformigrations-extensions

Task 12: Install DestinationAppsForMigration and move tables

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-12-install-destinationappsformigration-and-move-tables

Task 13: Publish final extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-13-publish-final-extensions

Task 14: Synchronize final extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-14-synchronize-final-extensions

Task 17: Upgrade and install final extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-17-upgrade-and-install-final-extensions

After the upgrade

1. NAVAX Consulting GmbH_NCP Payments Base by NAVAX_14.0.0.0.app
2. NAVAX Consulting GmbH_NCPE Payments Export by NAVAX_14.0.0.0.app
3. NAVAX Consulting GmbH_NCPI Payments Import by NAVAX_14.0.0.0.app