banking 2012 user guide · 2019-05-10 · ax environment, and gives you access to hundreds of banks...
TRANSCRIPT
AMC Consult A/S May 9, 2019 Banking 2012 v6
USER GUIDE
AMC BANKING FOR MICROSOFT DYNAMICS AX 2012
|Introduction 2
CONTENTS
1 Introduction...................................................................................................................................5
2 Facilities .........................................................................................................................................6
3 Prerequisites..................................................................................................................................7
4 Setup .............................................................................................................................................8
4.1 Parameters ............................................................................................................................8
4.1.1 Payments ................................................................................................................8
4.1.2 Posting ....................................................................................................................9
4.1.3 Web service ............................................................................................................9
4.1.4 Direct debit .......................................................................................................... 10
4.2 Banks .................................................................................................................................. 11
4.2.1 Settings ................................................................................................................ 14
4.2.2 Bank holidays ....................................................................................................... 15
4.2.3 Prices ................................................................................................................... 16
4.2.4 Payment type priorities ....................................................................................... 16
4.3 Own bank accounts ............................................................................................................ 18
4.3.1 Company setup .................................................................................................... 21
4.4 Customers and vendors...................................................................................................... 22
4.4.1 Bank accounts ...................................................................................................... 24
4.5 Journals .............................................................................................................................. 27
4.6 Payment advice .................................................................................................................. 28
4.6.1 Advice types ........................................................................................................ 28
4.6.2 Preview ................................................................................................................ 31
4.7 Search strings ..................................................................................................................... 31
4.7.1 Cleanup ................................................................................................................ 33
4.8 Transaction texts ................................................................................................................ 34
4.9 Auto match ......................................................................................................................... 34
4.10 Workflows .......................................................................................................................... 36
4.11 Security roles ...................................................................................................................... 36
5 Payments .................................................................................................................................... 37
|Introduction 3
5.1 Prerequisites....................................................................................................................... 37
5.2 Payment journal ................................................................................................................. 37
5.2.1 Creation ............................................................................................................... 38
5.2.2 Preparation .......................................................................................................... 41
5.2.3 Validation ............................................................................................................ 43
5.2.4 Approval and transfer.......................................................................................... 44
5.2.5 Posting ................................................................................................................. 44
5.3 Email advice ........................................................................................................................ 46
5.4 Additional functions ........................................................................................................... 47
6 Direct debit withdrawals ............................................................................................................ 49
6.1 Prerequisites....................................................................................................................... 49
6.2 Direct debit journal ............................................................................................................ 49
6.2.1 Creation ............................................................................................................... 50
6.2.2 Preparation .......................................................................................................... 51
6.2.3 Validation ............................................................................................................ 51
6.2.4 Transfer ............................................................................................................... 51
6.2.5 Posting ................................................................................................................. 51
6.3 Email advice ........................................................................................................................ 52
6.4 Mandates ........................................................................................................................... 52
6.4.1 Physical mandates ............................................................................................... 52
6.4.2 Electronic subscriptions ....................................................................................... 53
7 Payment notifications ................................................................................................................ 56
7.1 Import ................................................................................................................................. 56
7.2 Posting journal ................................................................................................................... 56
7.2.1 Auto match .......................................................................................................... 57
7.2.2 Manual settlement .............................................................................................. 58
7.2.3 Cash discount ...................................................................................................... 60
7.2.4 Additional functions ............................................................................................ 61
7.2.5 Posting ................................................................................................................. 62
8 Account statements ................................................................................................................... 63
|Introduction 4
8.1 Import ................................................................................................................................. 63
8.2 Reconciliation ..................................................................................................................... 64
8.2.1 Automatic reconciliation ..................................................................................... 66
8.2.2 Manual reconciliation .......................................................................................... 68
8.2.3 Ledger proposal ................................................................................................... 69
8.3 Reports ............................................................................................................................... 71
8.3.1 Reconciliation report ........................................................................................... 71
8.3.2 Forecast report .................................................................................................... 72
9 Appendix .................................................................................................................................... 73
9.1 Aggressive credit note accumulation ................................................................................. 73
9.2 Charts ................................................................................................................................. 75
9.2.1 Troubleshooting .................................................................................................. 75
9.3 Posting scenarios ................................................................................................................ 76
9.4 Demo return file ................................................................................................................. 76
10 US Localizations .......................................................................................................................... 79
10.1 Positive pay journal ............................................................................................................ 79
10.1.1 Creation ............................................................................................................... 80
10.1.2 Transfer ............................................................................................................... 81
|Introduction 5
1 INTRODUCTION To benefit as much as possible from your AMC-Banking module, you should read this user guide,
describing in detail, the various possibilities and functionalities offered by the module.
The user guide covers the basic setup of the module; meaning the setup that only needs to be done
once. Furthermore, it contains a detailed description of the module’s functionalities for you to
familiarize yourself with the daily use of the module.
Best regards
Development team
AMC-Consult A/S
|Facilities 6
2 FACILITIES The Banking module covers four main areas of accounting.
Execution of payments
AMC Banking includes facilities for executing payment to all customers and vendors in the Dynamics
AX environment, and gives you access to hundreds of banks throughout the world.
For a complete list of banks, please visit:
http://amcbanking.com/support/amc-banking/microsoft-dynamics-ax/banks/
If your bank does not figure on the list of supported banks, please do not hesitate to contact either
your reseller or us, to find out the possibilities for adding your bank to the list.
Import and posting of payment notifications
AMC Banking includes facilities for importing and handling payment notification files, which contains
the physical credit and/or debit payments, which have been executed and posted on your bank
account(s).
Whether the payment notifications contain structured or unstructured payment information, the
module includes advanced functionality for identifying and settling the individual payments, allowing
the user to quickly handle and post the payment notifications.
Import and reconciliation of bank account statement
AMC Banking includes facilities for automatic account reconciliation based on electronic bank
account statements from the bank.
The reconciliation process matches the individual bank transaction against corresponding ledger
transactions. Furthermore, the account reconciliation functionality can quickly identify and post
bank transactions, which is unknown in Dynamics AX.
Direct debit withdrawals
AMC Banking includes facilities for automatic withdrawal of funds from customer bank accounts
based on the customer invoices registered in the system
The direct debit functionality handles every step of the withdrawal process, from acquiring physical
or electronic withdrawal mandates, from sending the actual withdrawal instructions to finally
settling and posting the customer invoices.
|Prerequisites 7
3 PREREQUISITES To be able to complete the setup and actions described in this manual, there are several
prerequisites
✓ The latest version of the Banking module should be installed
✓ A valid Banking license should exist, and the necessary license setup should have been
completed
|Setup 8
4 SETUP
4.1 PARAMETERS
Go to AMC Banking > Setup > Parameters.
4.1.1 PAYMENTS
The payments tab contains setup specifically related to the process of executing payment
The fields on the payments tab have the following features:
Field Description
Grace period Number of days to add to cash discount date, and thereby number of days to allow cash disc
even though overdue
Centralized payment method The options are:
- Intercompany: Cross-company transactions are handled using standard AX
intercompany functionality, where transactions are posted both centrally and in
original company, using configured intercompany accounts.
- Partitioned: Cross-company transactions are handled centrally but are posted in
their respective companies. Note, that using this option will typically result in the
creation of multiple posting journals, to keep transactions from different
companies separate.
Party accumulation Enable, if payment proposal should attempt to accumulate invoices associated to same
party in global address book, when adding payments
Note: This option is only available, when using the Intercompany centralized payment
option, as it would directly conflict with the Partitioned way of doing centralized payments
Use standard payment methods If enabled, the module will pair individual invoices with certain own bank accounts if both
have identical payment methods.
Auto send If enabled, payment advices are automatically emailed to payees during transfer. If not
enabled, users must send the payment advices manually from the journal.
Note: The email is (only) send when the payment has been transferred successfully.
Note: Emails are send using standard AX email functionality. That also means that the
standard AX email setup is used to configure the SMTP relay server
|Setup 9
4.1.2 POSTING
The posting tab contains setup specifically related to the process of posting payments
The fields on the posting tab have the following features:
Field Description
Split payment notifications Specifies whether to split payment notification, so debit and credit transactions end up in
separate posting journals. This is useful in organizations where debit and credit transactions
are handled by different designated accountants
Name of (customer) journal The journal template to use for automatic created posting journals. If splitting of payment
notifications is enabled, this template is only applied to customer posting journals
Name of vendor journal The journal template to use for automatic created vendor posting journals
Auto match This mark specifies to automatically match payments that are created during import of bank
files
Use old match interface As of Banking 2012.6.0.0 a new auto match interface was introduced, deprecating old auto
match customizations and extensions. To prevent old customization from stop working, the
old interface is still there, and can be reactivated by checking this checkmark.
Settle medium match This mark specifies if the auto match functionality should be allowed to settle medium
matched open invoices, which as opposed to high matches are less evident
Grace period Number of days to add to cash discount date, and thereby number of days to allow cash disc
even though overdue
4.1.3 WEB SERVICE
The web service tab contains setup specifically related to the process of communicating with the
AMC-Banking web service
|Setup 10
The fields on the web service tab have the following features:
Field Description
Solution The options are:
- Plus
- Enterprise
URL The URL of the web service which handles the conversion of payments and bank files. The
field’s background color will continuously be updated, reflecting the SSL certificate status of
the last web service connection.
- Green: Certificate is trusted, and channel is secure
- Pink: Certificate is valid, but is not regarded as trusted, as it is not authorized by a
certificate authority (CA), typically because certificate is self-signed
- Red: Certificate is untrusted, and channel is insecure. The Banking module will
block communication with untrusted web services
Note: The field is only editable on Enterprise solutions, where a designated web service is
hosted either locally or by a third party (Microsoft Azure or similar)
Username The username/login used when communicating with the license server and the web service
specified in the URL field. Username is defined as the AX serial number.
Custom login If needed you can add a custom part to the AX serial number and use this for
communicating with the web service
Password The password used when communicating with the license server and the web service
specified in the URL field. Password is defined when creating your AMC-Banking license
4.1.4 DIRECT DEBIT
The payments tab contains setup specifically related to the process of automatic withdrawal of funds
from customer bank accounts via direct debit.
|Setup 11
Field Description
Solution The options are:
- Plus
- Enterprise
URL The URL of the web service which handles the conversion of payments and bank files. The
field’s background color will continuously be updated, reflecting the SSL certificate status of
the last web service connection.
- Green: Certificate is trusted, and channel is secure
- Pink: Certificate is valid, but is not regarded as trusted, as it is not authorized by a
certificate authority (CA), typically because certificate is self-signed
- Red: Certificate is untrusted, and channel is insecure. The Banking module will
block communication with untrusted web services
Note: The field is only editable on Enterprise solutions, where a designated web service is
hosted either locally or by a third party (Microsoft Azure or similar)
Tax registration number Due to a general lack of consensus, on which field to use, when registering customers’ tax
registration number, you can set up, which field from the customer table that is used by the
AX legal entity/company.
The options are:
- Tax exempt number
- ID number
- Organization number
Auto send If enabled, payment advices are automatically emailed to payees during transfer. If not
enabled, users must send the payment advices manually from the journal.
Note: The email is (only) send when the payment has been transferred successfully.
Note: Emails are send using standard AX email functionality. That also means that the
standard AX email setup is used to configure the SMTP relay server
4.2 BANKS
The general bank setup is set up from AMC Banking > Setup > Banks > Banks
When entering the setup form for the first time, the bank list is empty, meaning that no banks have
been made available.
|Setup 12
To add banks, click Select banks. This will open a small form, in which banks can be added or
removed. To populate the Available (banks) list, click Update banks.
The module will now contact the web service specified in the parameter setup and request a list of
available banks and payment types. Once the bank update has finished, the individual banks can be
selected by using the arrow buttons.
Close the bank selection form and refresh the bank list to see the newly added banks.
To the right, a preview pane displays the payment types available to the individual banks and possibly
a brief description if further clarification on the payment type is needed.
The fields on the fast tabs have the following features:
Field Description
Bank
|Setup 13
Bank Identification of bank
Name Editable bank name/description
License bank Reference to a license bank, which is the web service’s own bank identifier. The license bank
is used by the module to instruct which bank format the web service should output when
creating payment files
Note: Usually this is a fixed value, which rarely needs changing
Requirements
Approval Indicates whether bank requires approval when executing payments
Login Indicates whether bank requires signing in, when importing bank return files
Direct debit Indicate whether the bank is a direct debit bank, hence cannot be used for regular payments
Payments
Calendar Reference to a holiday calendar, which contains the dates, where payments cannot be
executed by the banks
Note: If left blank, weekdays are considered payment dates and weekends are considered as
holidays.
Domestic payment currency Used to restrict domestic payments to a certain currency. If a currency code has been
specified, invoices in other currencies will be regarded as international transfers, when
executed using the bank.
Accumulate reference payments Used to specify, whether the bank allows accumulation of reference payments. If not
checked, reference payments executed from this bank will not be accumulated, resulting in
one reference payment per invoice.
Own reference Specify what to use for own reference, which is usually also shown on bank account and
related bank account statements
Direct debit (only applicable on direct debit banks)
Mandate required Used to specify whether bank requires physical mandates
Subscription required Used to specify whether bank requires electronic mandates
Credit card bank Used to specify whether withdrawals are done via a credit card solution
|Setup 14
4.2.1 SETTINGS
Clicking Settings will open a form where additional bank setup can be configured.
The fields on the fast tabs have the following features:
Field Description
Company
Company Used to specify the scope of the advanced bank setup. The company field is used, if a
company specific bank setup is needed.
If left blank, the setup is considered a general setup, which will be used in all companies,
which do not have company specific setups
Name The name of the advanced bank setup.
Payments
File to bank Used to specify where to save created payment files
Alternative sender Used to override the default sender name, which is otherwise fetched from standard AX
company setup
Advice Default advice, allowing to set up a joint advice layout on bank level, instead of having to set
up advice on each payee
Import
Disable Used to disable and thereby skip the import of files, using these settings
Path from bank The path where bank files are stored prior to import
Archive The path where bank files are archived once successfully imported
Bank agreement
Bank agreement 1 Used to identify a bank agreement (if any)
Bank agreement 2 Used to identify a “sub-level” bank agreement (if any)
Direct debit (only applicable on direct debit banks)
File to bank (subscription) Used to specify where to save created payment files
Alternative tax registration
number
Used to override the default tax registration number, which is otherwise fetched from
standard AX company setup
Subsystem Used to set up which bank sub system to use for direct debit functionality
|Setup 15
4.2.2 BANK HOLIDAYS
Bank holidays are set up from AMC Banking > Setup > Banks > Bank holidays
Depending on the country of the bank and sometimes even the payment format, a given bank has
certain dates where payments cannot be executed (cleared). The bank holiday setup is used to set
up non-payment dates and is used to ensure that payments are created on dates where they can be
executed.
Besides the obvious benefit of getting one’s payments executed, this also helps getting the most
accurate result, in relation to dates, exchange rates etc., when posting payments.
You can set up several bank holidays calendars, which can be specified on the various installed banks
that do not adhere to the same calendar (see 4.2).
The fields on the fast tabs have the following features:
Field Description
Calendar Identification of the bank holiday calendar
Description Brief description of the bank holiday calendar
Ignore weekend Used to specify whether to allow payment on weekends. If checked weekends are
considered as regular weekdays and thereby payment days.
Maintain list of bank holidays In this section, you can setup the bank holidays for this calendar
|Setup 16
4.2.3 PRICES
The price setup can be opened either by clicking the Prices button, which will open only prices related
to the selected bank, or from AMC Banking > Setup > Banks > Prices
The price setup is used to configure the costs related to executing payments of a certain payment
type.
When requesting a list of available banks and related payment types (see 4.2), the web service will
also return an estimated price for executing each payment type. If the prices are inaccurate, e.g. if
your company have negotiated favorable prices, both the price and the related currency can be easily
corrected in this form.
4.2.4 PAYMENT TYPE PRIORITIES
When adding payments, payment types are prioritized and validated in a default order based on best
practice. In some cases, though, this default sort order does not correspond with real life or some
companies’ way of doing business.
To ensure that payment types are determined in a smooth and seamless way, companies that wish
to deviate from the default sort order, can create their own bank specific, prioritized payment type
list from AMC Banking > Setup > Banks > Payment types
|Setup 17
To initialize the payment type list, click the Reset button. This will fill the list with a selection of
payment types ordered using best practices. The payment type list will never include unavailable
payment types, but please note, that it might not include all the bank’s available payment types. This
is due to the fact, that some payment types are not suited to be included in the daily payment
routines.
Payment types can be repriorited using the Top, Up, Down and Bottom buttons and disabled using
the Disable checkmark. The Clear button is used to remove the user defined payment priority list
altogether and revert to the systems default settings.
|Setup 18
4.3 OWN BANK ACCOUNTS
The setup related to your company’s own bank accounts is opened from AMC Banking > Common >
Own bank accounts.
Like most list pages, the menu contains several buttons covering the general maintenance of the
bank accounts. Furthermore, the menu contains buttons for account reconciliation (see section 8)
and for balance chart, cost chart and post chart (see section 9.2)
Clicking either New > Bank Account or Maintain > Edit, will open a separate, detailed bank account
setup form.
|Setup 19
The fields on the fast tabs have the following features:
Field Description
Bank
Bank The internal bank to which the bank account belongs
Bank account The account number that is assigned by the bank
Note: Both local bank account numbers (BBAN) and IBAN numbers are allowed in this field
Currency The currency of the bank account
Parent bank account Used to tie virtual bank accounts to their physical counterparts
SWIFT code The SWIFT code identifying the bank and possibly branch
General Company The company or legal entity in AX to which the bank account belongs
Restrict to company Restrict the bank account to the company where it resides (specified in the Company field),
and thereby prevent the bank account from being used in other companies. This field is not
|Setup 20
to be confused with the general company setup’s Payment field, which specified which
companies’ invoices can be paid.
This option is typically used by holding companies with subsidiary companies, as it allows
the holding company to create payments based on the subsidiary invoices, while restricting
the bank account from being used by the subsidiary companies.
Priority The priority of the bank account used to specify how bank accounts are prioritized against
each other. The lower the number, the better priority. However, the priority is only used, if
no other match is found based on currency, method of payment etc.
More currencies Specifies whether to allow other currencies than the bank account’s own currency.
Please note, if more currencies are disabled, then the system will prioritize the posted
amount over the originally transferred amount, when importing bank return files
Bank groups Used to group bank accounts together. The bank groups are used by the balance form parts,
which calculates and displays the total balance of both individual bank accounts as well as
bank account groups
Offset account type Used to specify the type of the offset account in AX.
The options are:
- Bank
- Ledger Offset account Used to specify the offset account in AX which the bank account correlates to
Customer payment method Used to link the bank account to a certain standard AX customer payment method.
When adding payments, the module will attempt to pair open customer invoices with bank
accounts with similar payment methods.
Note: This field is only visible and used if standard payment methods are enabled in
parameter setup
Vendor payment method Used to link the bank account to a certain standard AX vendor payment method.
When adding payments, the module will attempt to pair open vendor invoices with bank
accounts with similar payment methods.
Note: This field is only visible and used if standard payment methods are enabled in
parameter setup
Bridging posting If a selected method of payment is setup to use bridge posting, you have activated the
bridging functionality, and this field is automatically marked. This means that posting of a
payment journal will use the bridging account as offset account instead of the bank account.
Fee collection Specify whether fees are being collected on bank account and thereby whether to ignore
transaction related (sub)fees or not.
Note: Individual fee transactions will still be imported
Match class Field used to specify, which auto match class to use during auto matching of imported
transaction. The auto match class is responsible for testing the validity of the matches found
by the rules
If left blank, the auto match functionality will use the default auto match class, which is
distributed as part of the AMC-Banking module
Match rule setup Used to specify which set of auto match rules to use for identifying potential matching
payments and/or invoices in the system
If left blank, the auto match functionality will use a default set of auto match rules in a strict
order from
Reconciliation Start date The date on which to start reconciling
This date is typically used when the reconciliation functionality is started later than the AX
implementation, where existing ledger transaction is either reconciled already or old
electronic account statements is not available.
|Setup 21
The start date indicates the date on which transactions are included in the reconciliation
process. Therefore, ledger transactions posted prior to the start date, will not be included in
the reconciliation functionality, e.g. in the reconciliation form and report
Bank balance Used to specify the bank account’s balance on the start date. The balance is used in the
reconciliation report
Opening balance Used to specify the system account’s opening balance on the start date. This field is only
visible when offset account type = bank. The field is typically used in cases where ledger
opening transactions does not have the necessary data, linking them to the bank account
specified as offset account. In those cases, the report is not able to retrieve the opening
balance automatically.
4.3.1 COMPANY SETUP
The company setup tab is used to set up, how the individual AX companies and/or legal entities can
utilize the bank account.
The default is that the company, in which the bank account resides, is allowed full access to the bank
account, while all other companies are restricted from using the bank account at all. If a bank account
is shared across AX companies or legal entities, companies can be added to the company list.
Note: To permit users from seeing bank accounts, which are not relevant to them, bank accounts are only
visible in companies, that are included in the company setup. Furthermore, the company setup is only
available in the bank account’s own company. This ensures that bank account visibility and company setup,
can only be changed by users with the required access to the company of the bank account.
The fields in the grid have the following features:
Field Description
Company Identification of the company in AX
Payments Specifies whether payment journals in the related company can use the bank account
Posting The company in which to add the posting journals created because of importing bank files,
e.g. customer- and vendor payments
Note: Only one company can be the posting company
Auto match Specifies in which companies to look for open invoices when the auto match functionality is
executed
|Setup 22
4.4 CUSTOMERS AND VENDORS
Setting up payee bank information is done from either AMC Banking > Common > Customers or
AMC Banking > Common > Vendors, which opens list pages providing a quick payee overview.
Note: The customer and vendor setup forms are almost identical in relation to both design and
functionality. Having two setup forms, primarily serves to keep customers and vendors separate. The
following section will therefore in certain cases only cover the vendor setup form, which is the most
commonly used in relation to payments
Unlike earlier versions of Banking, the current version utilizes standard AX’s customer/vendor bank
accounts, which helps reduce redundancy. Thus, all customers and vendors with related bank
accounts are considered payable, usually without the need for additional setup. Therefore, the
customer and vendor setup forms are only used, in cases where customers or vendors are to be
excluded from the payment process or in those cases where additional information is required.
|Setup 23
The left-most status icon field in the grid have the following features:
Field Description
Status An image displaying the payment status of the vendor.
The options are:
- [Green check mark]: The vendor is enabled and has related bank account setup,
hence is considered payable. The vendor’s open transactions are included in
payment process
- [None]: The vendor is enabled but has no bank related setup. The vendor’s open
transactions are included in payment process
- [Red cross]: The vendor has been disabled, hence the vendor’s open transactions
are excluded from the payment process
Clicking the Edit button will open a detailed vendor setup form
|Setup 24
The fields in the form have the following features:
Field Description
General
Account type Specifies whether it is a customer or a vendor account Account number The account number of the vendor
Name The name of the vendor
Disabled Specifies whether the vendor has been disabled and should be excluded from the payment
process
Discount
Grace period The number of days to allow overdue cash discount
Payment accumulation
Override Used if default payment accumulation of open invoices should be overridden on specific
vendor level
Payment accumulation Specifies how open invoices should be accumulated when creating payments. See section
4.1.1 for more information
Advice
Disable auto advice Used to prevent automatic building of payment advice based on the invoices included in the
separate payments. Disabling the auto advice enables the advice field, which allows the user
to choose an alternative advice
Advice Reference to the advice template, which is used to create the electronic advice included in
the payment file
Note: If nothing is specified, an automatic advice is created
Email advice
E-mail Email address to use when sending payment advices to vendor
E-mail ID AX email template to use when sending payment advices to vendor
Report design name Advice report design to use for payment advices
File format File type of the advice report file being attached in the advice email
4.4.1 BANK ACCOUNTS
Customer and vendor bank accounts can be maintained either directly on the detailed
customer/vendor setup form or by clicking the Payment > Bank accounts button in the list page
menu.
|Setup 25
The fields in the form have the following features:
Field Description
Identification
Bank Bank account identification
Name Name of the bank account
Bank account
Routing number type Code identifying the type of the routing number
Routing number Routing number of the bank
Bank account number The account number that is assigned by the bank
SWIFT code The SWIFT code identifying the bank and possibly branch
Currency Currency code of the bank account
Note: Specifying a currency code will result in the bank account being restricted to
transactions of that currency only.
Correspondent bank account Used to specify a bank account to use as correspondent bank account. This is a reference to
another of the payee’s bank accounts and correspondent bank account cannot be the same
bank account, as the current selected bank account
Payment type
Payment type Used to tie up the bank account to a specific payment type. Thus, the specified payment
type will be used on all future payments to the bank account
Note: If a payment type is not specified, the payment creation functionality will attempt to
find the most appropriate payment type based on the individual open invoices (see section
0)
|Setup 26
Address
Bank address The address of the bank related to the bank account
Alternative address Used to specify an alternative vendor address. If nothing is specified, vendors primary
address is used
Bank rules
Customer ID Receiver’s identification of payer. This
Costs Used to specify how to allocate payment related costs.
The options are:
- Shared: Charges are split between sender and receiver of the payment. Usually
payer will be charged a fee for creating the payment order, whilst the receiver
will be charged for costs related to intermediary banks and sometimes also a fee
for receiving of the money.
- Payer: All fees are charged to the sender of the payment
- Payee: All fees are charged to the receiver of the payment
|Setup 27
4.5 JOURNALS
The general behavior of the posting journal is set up from AMC Banking > Setup > Journals >
Journals.
Field Description
Voucher
New voucher Specifies how and when new vouchers are fetched. The options are:
- In connection with balance
- Manual
- One voucher number only Voucher series The voucher series used
Financial dimensions
Default financial dimensions The journal can be configured with financial dimensions, which will automatically be added
to created journals
|Setup 28
4.6 PAYMENT ADVICE
Electronic advices for payment files are set up from AMC Banking > Setup > Payment advices.
When executing payments, it is important to create a satisfactory message to the recipient. AMC-
Banking contains several options for creating electronic advices, and it is possible to design an
unlimited number of templates for advices sent to the recipients.
4.6.1 ADVICE TYPES
It is possible to create three types of advices:
- Compressed: Comma separated invoice numbers
- Dynamic: Custom configurable advice with a limited number of fixed placeholders
- Class: Fully customizable advice class
It is not a requirement to set up advices. If no advice setup is found, an advice suitable for the payment
file will automatically be created by the web service based on the individual open invoices
4.6.1.1 COMPRESSED
A compressed advice is a list of invoice numbers separated by commas, and it is typically used to
conserve space in formats with very limited space for advice. The only configurable part is a header,
which is used to prefix the invoice list.
This setup will create an advice like this:
“Invoices: 123456789, 321654987, 4654231….”
|Setup 29
4.6.1.2 DYNAMIC
Unlike the compressed advice, the dynamic advice is highly customizable and has several properties,
which can be tweaked to suit your specific needs. The dynamic advice is typically used, where advice
possibilities are rich, and only the most common invoice data, like invoice no., date, amount etc., is
to be included
The dynamic advice consists of three different text sections, each separated by new line:
Header: A one-time occurring header being output at the start of the advice. The text can contain
several lines of text but should not exceed the maximum length of the payment file’s advice.
Most payment file formats allow 35 characters of text per line.
|Setup 30
1) Body: The body is being output once per open invoice settled on the individual payment. The body can be outputted in a single line or in one line per invoice by enabling the Linefeed field
The body allows several placeholders, which represent various data related to the individual open invoice:
➢ %1: Invoice no, left justified
➢ %2: Invoice amount, right justified
➢ %3: Invoice currency, left justified
➢ %4: Invoice date, left justified
➢ %5: Utilized cash discount amount, right justified
➢ %6: Customer/vendor account number, left justified
➢ %7: Transaction text, left justified
Each placeholder is “paired” with a related length property, which helps keep diverse invoice data aligned. It is important to fill the length, if a placeholder is used. Otherwise, you
will not see a value in the advice
2) Footer: A one-time occurring footer being output at the end of the advice. Like the header, the footer can contain several lines of text, but should not exceed the maximum length of the payment file’s advice.
4.6.1.3 CLASS
The class option offers building advices using a fully customizable class, and is typically used in cases,
where the invoice data covered by the placeholders, just do not cut it. E.g., the class could be used
to fetch related data from the any AX module.
The only configurable part is the Class name field, which is used to specify the name of the advice
class to use.
A class is only considered a valid advice class, if the class extends AmcBankAdviceClass, whic h forces the
advice class to implement certain functionality.
|Setup 31
4.6.2 PREVIEW
Regardless of the payment advice type, it is possible to generate an advice preview by clicking
Preview. This allows the user to test the advice setup continuously during set up.
The preview is generated from the selected advice setup using a random payment transaction. Therefore,
the preview functionality will return an error if no payment transactions exist
4.7 SEARCH STRINGS
As a feature, it is possible to add rules that tie certain text and/or codes on bank payments to a given
action or account in AX. The search string setup is very useful and allows the user to adjust the default
provided auto match functionality easily.
The search string setup is opened from AMC Banking > Setup > Search strings.
|Setup 32
The setup form contains a list containing various combinations of search strings, transaction codes
and their related action and/or account.
It is also possible to open the search string setup from either the customer or the vendor form. In that case,
the list only includes search strings related to the selected customer or vendor.
The Search string field is used to match a user-defined text. This is e.g. useful in situations where a
registered customer name in the AX does not correspond with the name provided by the customer
itself or the bank, when a payment from the customer is received. In such cases, the user can easily
add the provided customer name, which will allow the auto match functionality to determine the
customer based on the provided search string.
The Transaction code field is used to match transaction codes originating from the bank. Most banks
“tag” the individual bank transaction with transactions codes (also known as business transaction
codes), which helps determine the nature of the transactions. This is particularly useful, when
receiving recurring, known, yet unexpected financial transactions like fees, interests etc. In such
cases a transaction code can easily be tied to the related AX ledger account, allowing the auto match
to quickly identify and prepare the transaction, which can then be posted with minimal user
involvement.
The search strings and transaction codes can be tied to three different actions:
- Match:
Used to tie a text string and/or transaction code to an account in AX. When met, the auto
match functionality, will apply the set-up account to the transaction.
- Delete:
|Setup 33
Used to delete transactions. When met, the auto match functionality will delete the
transaction and inform the user, that a transaction was deleted.
- Bridge post:
Used to initiate bridge posting of the transaction. When met, the auto match functionality
will apply the related bank account’s bridge account to the transaction. This is particularly
useful, when using account statements to post bulk payment, which have been specified in
earlier files. E.g. Lockbox files (US) and FIK-indbetalinger (DK)
4.7.1 CLEANUP
Each search string record has two related date fields, specifying when the individual search string
was created and last used. The two date fields are useful when cleaning up search strings, as it
provides a quick overview of, which search string rules are being used regularly.
To help keep the search string list neat and tidy, the search string setup includes cleanup
functionality, which is activated by clicking Cleanup in the top menu. The button opens a simple
dialog, in which the user can specify Older than number of days.
Upon clicking OK, the cleanup functionality will delete all search string records, which have not been
used the specified number of days. The cleanup functionality is batch executable, allowing the
cleanup job to run continuously in the background.
|Setup 34
4.8 TRANSACTION TEXTS
The transaction text setup, which is reflected on the individual journal transactions’ Description
fields, is set up from AMC Banking > Setup > Transaction texts
The transactions text setup form is used to set up account type specific transaction text. E.g., it is
possible to use different transaction text on vendor and ledger transactions.
Furthermore, it is possible to create language specific transactions texts. E.g., it is possible to
configure both a Danish and English vendor transaction text. This will result in the description on
transactions related to a Danish vendor being built from the Danish transaction text setup and the
description on English vendor transaction being built from the English transaction text setup.
If the language field is left blank, the transaction text is used on transactions that does not relate to
a configured language. Using the previous example, a French vendor’s transaction would neither
fetch the description from the Danish or English setup, but instead fetch the description from the
default vendor configuration without language specified.
4.9 AUTO MATCH
A new auto match interface has been introduced, which makes it much easier to customize the auto
match on the fly, without the need to develop code-wise changes.
To set up a custom auto match routine, open AMC Banking > Setup > Auto match
|Setup 35
The auto match setup page is used to create user-defined match routines, that consists of a set of
match rules, which can be enabled/disabled and prioritized as required and desired. A custom, user-
defined auto match routine can be very helpful to better fit the auto match to the bank information
provided on imported bank transactions. E.g. if a bank account only has transactions with payment
references, performance and time-consumption can most likely be optimized by disabling pointless
match rules like the customer name rule.
To create a new auto match routine, click the New button from the top menu. The new match routine
will initially reflect the default match setup, but can easily be customized from the grid menu, by
disabling (deleting) or by changing the priority of the individual match rules. It is also possible to add
new match rules, e.g. if custom developed match rules are available.
|Setup 36
In addition to the match rules in the grid, it is also possible to enable advanced sequential matching,
by changing the Advanced match value to Yes. When the advanced match is enabled, the match
routine will attempt to match a subset of the customer invoices sorted by due date.
Advanced matching should be used with caution, as it will increase the total time-consumption of
the auto match. Therefore, the advanced matching is best used in situations, where it is common for
customers to pay only a subset of the outstanding invoices, without providing the necessary
structured information, e.g. invoice numbers, that allows the system to determine, exactly which
invoices are being paid.
4.10 WORKFLOWS
To ensure that payments are only executed if the related customer/vendor bank accounts have been
approved, the Banking module includes a workflow. For more info, please see the separate Activate
bank account approval workflow document.
4.11 SECURITY ROLES
To access the Banking module, users must be assigned with the proper security roles. For more info
on Banking security role assignment, please see separate Set up security roles document
|Payments 37
5 PAYMENTS This section covers the creation, approval and execution of payments.
5.1 PREREQUISITES
Customer and vendor transactions are created and posted from several locations, e.g. via the invoice
register journal, the invoice journal or the ledger journal. To be picked up and processed by the
Banking module, they are however all subject to a few common requirements:
✓ Must be approved
✓ Is not settled elsewhere
✓ Is in the selection range, defined in the payment add dialog
5.2 PAYMENT JOURNAL
The payment journal is used to create, and process payments based on open customer and/or
vendor transactions and can be opened from AMC Banking > Journals > Payment journal.
From the payment journal menu, the user is offered options like creating new payments as well as
viewing, editing and processing existing payment. To see the details of the individual payment
journals, select a journal and click Lines.
|Payments 38
The payment journal form contains the following fields:
Section Meaning
Company The company indicates the id of the company, where the payments are processed from
Bank The bank set up under Setup > Banks > Banks, which is used to execute the payment batch/journal
Journal The id of the journal, which also works as a payment batch’s unique indicator.
Unlike most other journals, the journal id of the payment journal is not based on number sequences or
voucher series. The journal id is instead constructed from the payment company combined with a shared
counter, which ensures that payment journals across companies can be processed without violating bank
uniqueness constraints.
Description Description of the journal
Lines Shows the total number of payment lines in the journal
Transferred Shows the number of lines, which have been transferred to the bank
Received Shows the number of lines, which have been confirmed as received by the bank
Validated Shows the number of lines, which have been successfully validated by the bank
Executed Shows the number of lines, which have been executed by the bank
Errors Shows the number of erroneous payment lines in the journal
Updated The date and time of the last journal update
5.2.1 CREATION
Thought the module allows the processing of payments to customers, the most common scenario is
that payments are created and processed from open vendor transaction. Processing of customer and
vendor payments are two identical processes, so despite the following section primarily focusing on
vendor payment scenarios, the section should also be enough to process customer payments.
To create payments, click either Add > Customer payments or Add > Vendor payments button.
Doing so, will open the Add payments dialog.
|Payments 39
The dialog contains of two sections, where the left side is used to present payment proposals based
on the configurations specified by the user on the dialog’s right side.
The user is presented with fields, which allows the user to quickly limit the included transactions as
well as affecting the payment creation behavior.
Section Meaning
Pay to date If the search is only to be based on regular due conditions, a date may be entered in this section and
used as limitation in the search. Invoices due until and including this date are included in the search.
Add cash discount If your company uses cash discounts, this field can be used to also include invoices, which is not
necessarily due yet, but on which cash discount can be achieved within Pay to date. Invoices, that are
cash discount eligible between the current date and the specified discount date are included in the
search
Forced payment date Used to override the automatic payment date determination and instead use a forced payment date,
disregarding holiday setup etc.
Payment accumulation The options are:
- Due date: Invoices and credit notes are accumulated per due date
- Period (First): Invoices and credit notes are accumulated in total, and payment date is the
due date of the first invoice in the selection
- Period (Last): Invoices and credit notes are accumulated in total, and payment date is the
due date of the last invoice in the selection
None: Invoices and credit notes are paid separately
Credit note accumulation Method used to accumulate credit notes during creation of vendor payments. The options are:
- Passive: The Banking module respects credit notes’ due date, which will only be
accumulated with payments with same due date.
- Aggressive: Future credit notes are included even though outside the specified date range
and due date is overridden. See section 9.1
In addition to the fields, which have been placed directly on the dialog, the user can further limit the
transactions, by adding user defines ranges, using the Select button.
To activate cross company payments, use the Select button to change the company included. This is done from the designated tab Company range
Once the desired ranges have been specified, the Refresh button, placed right next to the payment
proposal grid, is used to generate the payment proposals.
During the payments proposals generation, the module will automatically attempt to determine
bank accounts, payment types and other information related to the individual payments. This is
determined by several criteria, e.g. the available and active banks configured in the bank setup. For
an overview on how payment information is determined, see separate Determine payment
instruction document
Each payment proposal includes the exact same invoices, but represents different ways of
processing, the found, open vendor transaction and thereby the final payments. The individual
payments will usually differ based on the executing bank(s), e.g. by having different payment types,
different accumulation principles etc.
|Payments 40
It is possible to process payments using only a single execution bank, but it is also possible to process
payments using multiple execution banks, e.g. to process payments the cheapest way possible.
Next to the payment proposal grid, it is possible to get a quick overview of the payment types
included in the individual proposals. Furthermore, the Payment transactions tab can be used to see
the individual transactions, included in the payment proposal, in details. E.g. it is possible to see the
bank accounts involved and the estimated price for executing the individual payments.
It is possible to change the included transactions, as well as the payment behavior, dynamically, by
modifying the dialog fields or the user specified ranges. Doing so will result in the Create button
being disabled and the Refresh being re-enabled. This ensures that the user must click the Refresh
button, thereby regenerating the payment proposals based on the latest defined ranges, behavior
etc.
Above the Refresh button is two additional buttons, which is used to run checks, which can be
executed repeatedly on the individual payment proposals:
✓ Check payees: Used to check the balance of the payee, customer or vendor, and investigate
whether the total sum of payments for the payee exceeds what the payee is owed, e.g. due
to future credit notes. If the payee balance is exceeded, the check returns a warning,
If this check is used frequently, consider whether to use aggressive credit note accumulation
✓ Check balances: Checks whether the involved bank accounts have enough money to process
the payments, without resulting in a negative balance.
The balance is calculated using the bank accounts balance, and if the balance is being
exceeded, the check returns a warning,
|Payments 41
To finish the payment proposal process and create the payments, select the desired payment
proposal and click the Create button. This will result in one or more payment journals (one journal
per execution bank) being created.
Payments can also be added from inside the individual payment journals, which has similar menu buttons
for initiating payment adding. When adding payments from inside a journal, the user will only be presented
with a single payment proposal, which represents the existing execution bank specified on the journal.
5.2.2 PREPARATION
To open a detailed payment journal view, select the payment journal in the overview and click the
Lines button.
The initial status of payments in a newly created journal is Editable, which indicates that the
payments can edited or deleted. E.g., it is possible to change bank account information, add/remove
settlements to payments lines and delete lines, which should not be included in the payment batch.
Furthermore, it is possible to add manual payments, simply by clicking the New button [CTRL+N] and
filling in the required payment information.
Note: Payment amount can only be altered directly on manual payment, i.e. payment without settlements.
If a payment has settlements, the total payment amount can be changed by editing the settle amount on
the individual settlement lines in the settlement grid
The settlement grid allows the user to alter the settlements quickly, without leaving the payment
journal. E.g., it is possible to quickly add or remove settlements with 1-2 mouse clicks. Furthermore,
it is possible to edit the settlements directly from the settlement grid, allowing the user to specify
|Payments 42
missing payment ids or change the amount to settle (thereby changing payment amount); all without
leaving the journal.
The advanced button opens a designated settlement form, in which the more advanced settlement
actions, like changing cash disc, can be completed.
When the settlement form is closed, the amount and advice is automatically updated based on the
settled open invoices.
|Payments 43
5.2.3 VALIDATION
From leaving the AX environment to being executed by the intended execution bank, processing of
payments can be done in several ways.
Depending on, whether the payment journal requires approval or not (determined by the execution
bank), the user has the option to either Validate or Transfer the journal using the respective buttons
from the menu.
In both cases, the first part of the payment process is to validate the payment information of the
payment journal being processed. This validation ensures that payment information is adequate and
will be accepted by the execution bank upon being received and processed in the external systems
of the bank.
Payment lines, which does not meet the bank requirements, will be marked as Erroneous.
Furthermore, the system will add a small descriptive log, that explains the nature or the error and a
hint to what needs to be corrected. This log can be seen by hovering the mouse cursor over the small
error icon, that is visible in the payment grid’s left-most column. A quick log view is also available in
the FactBox pane to the right
Note: Most lines in the log will have a small blue question mark icon next to the text message. Clicking the
questing mark redirects the user to the Banking knowledge base site, which sometimes offers additional
error details.
When the necessary corrections have been made, the user can click the Validate or Transfer button
once more to validate the now corrected journal. Once all payments are validated successfully, the
journal will enter the next phase, which includes making the journal non-editable, which ensure that
users cannot edit the now validated payment information.
|Payments 44
Once the journal has entered the non-editable state, it can only return to editable state by using
clicking the Cancel button from the menu. This button is available to users that have been assigned
the AMC Banking manager role.
5.2.4 APPROVAL AND TRANSFER
If the payment journal does not require approval, a bank file is returned and saved locally. In addition,
the payment transactions change to status Transferred. The user is now responsible for the physical
file transfer to the bank, e.g. by uploading the created payment file in the bank’s online web system.
If the payment journal does indeed require approval, the payment transactions instead change to
status Approvable, which allows the approval users to access the Approval button menu. Here they
have the possibility to either Approve or Reject the complete payment journal.
Clicking the Approve button will open a small journal approve dialog in which the approver can
specify username and password.
Rejecting the journal will return the journal into editable mode
Once the required approvals have been applied, the journal is transferred automatically. If a host-
to-host solution has been established with the bank, the bank file will be transferred directly to the
bank without further user involvement required. Alternatively, the approved bank file is returned
and saved locally, leaving the physical file transfer responsibility to the users. In both cases, the
payment transactions change to status Transferred.
5.2.5 POSTING
Once the payments have been transferred, the next step is to post the payments. To post the
payment journal immediately, as opposed to waiting for a payment notification from the bank, use
the Create posting proposal button. This will open a post dialog, where users can decide what to do
with erroneous payment transactions, which posting journal type to create the proposal from and
whether to attempt immediate posting of the created posting proposal
|Payments 45
Erroneous payment can either be deleted or moved to a new payment journal, wherefrom the
required corrections can be applied, and the payments can be reprocessed.
If posting is instead postponed until the bank has confirmed the execution of the payments, then
users will sometimes experience, that some payments have been rejected by the bank. In that case,
users will usually not be able to delete the erroneous payments, because the journal enters a non-
editable state once transferred.
To remove the erroneous payment lines, use Functions > Move. The move functionality allows
moving the erroneous transactions to a new payment journal, wherefrom the required corrections
can be applied, and the erroneous payments can be reprocessed
|Payments 46
5.3 EMAIL ADVICE
If the electronic advice included in the payment file is inadequate, it is possible to print and send an
additional email advice. Email advice is activated from the customer or vendor form by specifying,
an email address and an email template.
Using email advice has the great advantage, that there is no limit to the number of invoices, which
can be included in a single advice. The advice functionality uses standard AX email functionality,
making it possible to create language specific email templates, which resemble the language of the
receiving vendor. Standard email functionality also offers the possibility to use placeholders in the
email body, which can offer a more personal touch to the email message.
Available placeholders are:
Placeholder Meaning
%Custname% Customer’s name
%Vendname% Vendor’s name
|Payments 47
Furthermore, it is possible to choose the advice file type and choose an alternative report design, if
the default design is not adequate. This allows customers to quickly create own email advice designs.
Printing and sending of email advices can be done manually from the payment journal overview or
inside the individual payment journals. To print and send the email advice, click Print > Payment
advice
If payment advice is activated from inside the journal, a dialog is presented, allowing the user to
decide the print destination.
If payment advice is activated from the payment journal overview, outside the journal, the Banking
module will automatically loop through all the payment transactions related to the selected payment
journal, and send email advices to customers and vendors, which has email advice enabled.
It is possible to skip the manual email advice process, by enabling Auto send advice from the
Payments tab of the parameter setup (see 4.1.1). If auto sending of email advice is enabled, the
email advices are printed and sent once a payment journal has been successfully transferred.
5.4 ADDITIONAL FUNCTIONS
The payment journal has a few additional functions, which can be helpful. Especially if posting is
done directly from the payment journal, and therefore does not rely on bank return files. The
functions are available from the Functions menu
|Payments 48
The menu items have the following functions:
Menu item Function
Transactions A link to standard AX’s transactions form, which can be effectively used to get a detailed list of payees’
transactions.
Cancel Used to cancel the payment journal. This option is only available to trusted personnel, which has been
assigned to the AMC Banking manager security role
Move Used to move lines to another payment journal. This option is useful, if payments in the journal has
been marked as erroneous, as this blocks further processing of valid/accepted payments. In such
cases, the erroneous payments can be moved to a separate journal, allowing further processing of the
accepted payment, while allowing reprocessing of erroneous payments in a separate payment batch.
Update payment date Easy way to update several transactions’ payment dates simultaneously
|Direct debit withdrawals 49
6 DIRECT DEBIT WITHDRAWALS This section covers the creation and execution of direct debit withdrawals. In addition, it covers the
creation of the required withdrawal mandates, whether electronic or physical.
6.1 PREREQUISITES
Customer transactions are created and posted from several locations, e.g. via the invoice register
journal, the invoice journal or the ledger journal. To be picked up and processed by the Banking
module, they are however all subject to a few common requirements:
✓ Must be approved
✓ Is not settled elsewhere
✓ Is in the selection range, defined in the payment add dialog
6.2 DIRECT DEBIT JOURNAL
The direct debit journal is used to create, and process withdrawals based on open customer
transactions and can be opened from AMC Banking > Journals > Direct debit journal.
From the journal menu, the user is offered a few options like creating new journals as well as viewing,
editing and processing existing direct debit journals
The payment journal page contains the following fields:
Section Meaning
Company The company indicates the id of the company, where the journal is processed from
Bank The bank set up under Setup > Banks > Banks, which is used to execute the batch/journal
Journal The id of the journal, which also works as a batch’s unique indicator.
|Direct debit withdrawals 50
Unlike most other journals, the journal id of the journal is not based on number sequences or voucher series.
The journal id is instead constructed from the execution company combined with a shared counter, which
ensures that journals across companies can be processed without violating bank uniqueness constraints.
Description Description of the journal
Lines Shows the total number of payment lines in the journal
Transferred Shows the number of lines, which have been transferred to the bank
Received Shows the number of lines, which have been confirmed as received by the bank
Validated Shows the number of lines, which have been successfully validated by the bank
Executed Shows the number of lines, which have been executed by the bank
Errors Shows the number of erroneous payment lines in the journal
Updated The date and time of the last journal update
6.2.1 CREATION
To create a new direct debit journal, click the New button, and fill in the required fields. Once
created, select the journal and click Lines.
Click the Add button from the menu to add withdrawal lines to the journal. This opens a dialog, which
can be used to filter the open transactions to add to the journal.
Section Meaning
Due date A due date range added as convenient filter Add cash discount If your company uses cash discounts, this field can be used to also include invoices, which is not
necessarily due yet, but on which cash discount can be achieved within Pay to date. Invoices, that are
cash discount eligible between the current date and the specified discount date are included in the
search
|Direct debit withdrawals 51
Forced payment date Used to override the automatic payment date determination and instead use a forced payment date,
disregarding holiday setup etc.
Click the OK button to add the customer transactions that fall within the specified filter ranges
6.2.2 PREPARATION
Preparation of a direct debit journal works like preparation of regular payment journal. For more
info see 5.2.2
6.2.3 VALIDATION
Validation of a direct debit journal works like validation of regular payment journal. For more info
see 5.2.3
6.2.4 TRANSFER
Transfer of a direct debit journal works like transferring of regular payment journal. For more info
see 5.2.4
6.2.5 POSTING
Posting of a direct debit journal works like posting of regular payment journal. For more info see
5.2.5
|Direct debit withdrawals 52
6.3 EMAIL ADVICE
Sending email advices to customers in a direct debit journal works like the equivalent functionality
of a regular payment journal. For more info see 5.35.2.5
6.4 MANDATES
A mandate is an acceptance from the customer, giving access to withdraw funds directly from the
customer’s bank account. There are two type of mandates
• Physical mandates
• Electronic subscriptions
6.4.1 PHYSICAL MANDATES
The mandate implicitly includes general rules as to the customer’s rights to cancel withdrawals as
well as obligations of the withdrawer to advice prior to the actual withdrawal etc.
To enable the use of mandates, open AMC Banking > Setup > Banks > Banks, select the withdrawal
bank and ensure that the Mandate required check box is checked
The Banking module utilized the standard direct debit mandate functionality, which is found in the
customer setup.
Please note, that mandate functionality was not added until AX 2012 R3, hence this functionality is not
available in prior versions
|Direct debit withdrawals 53
For more info, see: https://docs.microsoft.com/en-us/dynamicsax-2012/appuser-itpro/add-direct-
debit-mandate-information-to-a-customer-account
6.4.2 ELECTRONIC SUBSCRIPTIONS
In this chapter we will discuss the subscription process. Like mandates, the subscription process is all
about getting access to withdraw funds from the customers’ bank accounts, but unlike mandates,
which are physical files/documents, subscriptions are instead electronic interchanges of mandate
information.
To enable the use of subscription, open AMC Banking > Setup > Banks > Banks, select the withdrawal
bank and ensure that the Subscription required check box is checked
Subscriptions are maintained from AMC Banking > Periodic > Subscription
The form, from which subscriptions are handled, contains three grids.
1. The left most grid contains subscription which are ready to be processed
2. The middle grid contains pending subscriptions, which requires some kind of action to be
processed
3. The right most grid contains a list of active subscriptions, which allows withdrawals from the
related customers
6.4.2.1 PROCESSABLE SUBSCRIPTIONS
First step of adding an active mandate, is to add customer to the Processable subscriptions grid. This
is done by clicking the Select button from the grid’s top menu, which open a small pop-up window
from which inactive customer can be selected.
|Direct debit withdrawals 54
Once the customers have been selected, click the Close button to return to the subscription form.
To process the processable subscriptions in the list, click the Transfer button. This will activate a
validation of the customer and subscription data. If the validation is successful, an electronic
subscription file will be created, and the processed subscriptions will change state from processable
to pending, hence move from the list of Processable subscriptions to the list of Pending
subscriptions
6.4.2.2 PENDING SUBSCRIPTIONS
As the name indicates, the list of pending subscriptions contains subscriptions, which have not yet
been fully processed. There are basically two types of pending subscription.
The first type covers the subscriptions, which have been transferred and now awaits a bank response
confirming the completion of the subscription.
The second type covers unknown (active) subscriptions, which need to be linked to customers in the
system. Unknown subscriptions are typically created because of a bank response, containing
subscriptions, which cannot be identified by the data in the response. In that case a warning
messages will inform that an unknown subscription has been added to the list of pending
subscriptions
Pending subscription awaiting bank response can be recognized by the small clock icon on the left
side of the pending list. In most cases, these subscriptions will be updated and processed
automatically, once the bank file is imported. It is also possible to manually cancel or process the
pending subscriptions by using either the Delete or the Process subscriptions buttons respectively.
Unknown subscriptions can be recognized by the error icon, which indicates, that the subscription
cannot be finished until customer information has been specified. Once the required customer
information has been specified the error icon will change into a green check icon, indicating that the
subscription can now be finished. This is done by clicking the Process subscriptions button
|Direct debit withdrawals 55
6.4.2.3 ACTIVE SUBSCRIPTIONS
Once processed the pending subscription is moved to the list of Active subscriptions, marking that
the electronic mandate requirements for a withdrawal is met.
To remove an active mandate, simply click the Delete button in the grid’s top menu and confirm the
removal in the deletion prompt dialog.
The most common scenario is for the customer itself to terminate the subscription that allows withdrawals.
In that case, provided the bank can deliver the information, the customer is unsubscribed automatically
because of a bank response file
|Payment notifications 56
7 PAYMENT NOTIFICATIONS Payment notifications reflect the credit and debit transactions, which have been physically posted
on the bank accounts in the bank. This section covers the processing of payment notification, from
the initial import to the final posting inside AX.
The overall goal when importing and processing payment notification, is to match, settle and post
physical bank transactions with payments and/or open transactions in the AX environment.
In earlier versions, payment notifications where restricted to banks, which could provide designated
payment notification files. The new version offers this facility to all customers, who can receive
simple bank account statements. This means that payment notification processing is available to a
vast increased number of customers, e.g. customers from countries with limited banking
infrastructure.
7.1 IMPORT
For more info on importing return files, please see separate Importing bank return files document
Imported payment notifications are matched against the own bank accounts, registered in the
Banking module (see 0). If a matching bank account is identified, the related company setup is used
to determine in which company to import the payment notification in, resulting in a posting journal
being created in the respective company.
7.2 POSTING JOURNAL
The posting journal is used to match and settle bank transactions against either payment journal
payments or open customer/vendor transaction and is opened from AMC Banking > Journals >
Posting journal.
|Payment notifications 57
The posting journal overview have the following fields:
Section Meaning
In use Specifies whether the journal is in use by either the system or a user
Company The company, in which the journal belongs
Name of journal Name of the journal configured in Setup > Journals > Journals
Description A brief description of the journal and its content
Journal type The type of journal. Typically, either customer payment or vendor disbursement, depending on the imported
transactions
Lines The total number of lines in the current payment suggestion.
Ready The number of processed lines, which are ready for posting
Created date and time The journal’s creation date and time
To open a journal, select a journal and click the button Lines.
The posting journal contains two main parts, the top grid containing the individual payment and the
bottom grid containing the current payment’s settlements.
Each payment is stamped with a color code, which allows the user to quickly get an overview of
which payments, that have already been processed and which payments that require further
attention.
7.2.1 AUTO MATCH
|Payment notifications 58
During the import of payments, unless disabled, the Banking module performs an automatic match
of the payments. The auto match can also be executed manually on either journal or transaction
level from the Auto match menu.
Regardless of whether the auto match was executed automatically or manually, the individual lines
will be marked with a match level, which specifies with which certainty the match was found.
Level Match criterion
Rule (Turquoise) A rule level match is achieved if the payment was identified from user defined search string
configuration
High (Green) A high-level match is achieved if the payment was identified from either:
✓ Payment ID (1st priority)
✓ Payment reference (2nd priority)
✓ Invoice number (3rd priority)
Medium (Yellow) A medium level match is achieved if the payment was identified from either:
✓ Customer account no (4th priority)
✓ Our account number (5th priority)
✓ Customer name (6th priority)
✓ Customer bank account (7th priority)
Low (Red) A low-level match is achieved if the payment was matched against a customer or vendor, but was not
able to identify, which open invoices/transactions to settle.
In general, a low match always originates from either a rule, high or medium match, but has been
degraded, because the settlement could not be completed, e.g. because of amount differences
User (Blue) If the user manually settles the transactions or changes status to Ready, the transaction is marked
with match level User.
None (White) The auto match was not executed or was not able to match the payment.
The Banking module allows creating and utilizing own developed customer specific auto match classes. I.e.
it is possible to tamper with the individual match levels; hence, they can differ from the description above.
7.2.2 MANUAL SETTLEMENT
If the auto match is not able to identify a bank transaction’s related customer/vendor and invoice(s),
it is possible to carry out a manual settlement.
It is also possible to post a payment without settling it, e.g. if it is a prepayment. In that case, the user
can change the payment’s status field value to Ready.
To initialize manual settlements, click one of the two buttons in the settlement grid’s tool bar.
Clicking the Settlement button will open an external settlement form, which allows the user to settle
the bank transaction against open invoices in AX.
|Payment notifications 59
Clicking the Payment button will open an external settlement form, which allows the user to settle
the bank transaction against payments, which have been executed from the payment journal (see
5.2). The original payment thereby works as an indirect link to one or more open invoices in AX.
In both the regular settlement form as well as the payment settlement form, invoices that have
already been settled elsewhere, will be marked with a tiny red lock. Thus, the user will not be allowed
to conduct a settlement of the invoice.
If the user wants to see where a locked invoice has been settled, it is possible to click the tiny lock
icon. Doing so will result in an infolog; describing in which company the where the settlement has
been done.
|Payment notifications 60
Once the user has marked the invoices or payments to settle and made sure that the total settlement
amount matches the payment amount (within max difference), clicking OK will carry out the
settlements.
As a new feature, the module allows automatic handling of payments exceeding the open invoices
available. This situation e.g. occurs if a customer mistakenly pays invoices twice, thereby exceeding
the expected payment amount (see example below).
Customer receives invoice A + B
Invoice A
Invoice B
Customer pays invoice A + B
Invoice A
Invoice B
Customer receives invoice C
Invoice A
Invoice B
Invoice C
Customer mistakenly pays both invoice B + C
Invoice A
Invoice B
Invoice C
Payment exceeding expected amount
Invoice A
Invoice B
Invoice C
When attempting to carry out a settlement, where the payment amount exceeds the settlement
amount, the user will be asked to confirm the amount difference, which will result in the original
payment being split into three different transactions.
1) A ledger/bank transaction reflecting the original posted bank transactions
2) A settled customer transaction reflecting the part of the payment, which could be settled
against open invoices
3) A not-settled customer transaction reflecting the remainder of the payment, which could
not be settled
7.2.3 CASH DISCOUNT
If a customer has been granted cash discount, the auto match routine and settlement functionality
expect the customer to utilize the cash disc, by deducting the cash disc from the invoice amount.
This is of course only true, if the payment date does not exceed the cash disc date.
If the customer does not utilize the cash disc, or if the customer utilizes the cash disc, but the cash
disc date has been exceeded, the auto match will consider this an amount difference. Thus, an
obtained match will be degraded to a low-level match.
|Payment notifications 61
Should the user decide to accept the customer’s payment despite of the amount differences caused
by incorrect utilized cash disc, the settlement form allows modifying the expected cash disc easily by
using the designated cash disc fields as shown below.
Depending on how the cash disc has been incorrectly utilized, there several approaches, which can
be used to quickly accept the payment differences they cause.
✓ Customer does not utilize granted cash disc
Change Use case discount value from Normal to Never
✓ Customer utilized cash disc despite cash disc date being exceeded
Change Use case discount value from Normal to Always
✓ Customer utilizes cash disc but utilizes incorrect cash disc amount
Change Cash discount amount to utilized cash disc amount
✓ Customer utilizes cash disc despite not being granted cash disc
Change Cash discount amount to utilized cash disc amount
7.2.4 ADDITIONAL FUNCTIONS
The posting journal has several functions, which can be used to ease the process, getting from import
to posting. The functions are available from the Functions menu
|Payment notifications 62
The menu items have the following functions:
Menu item Function
Search string Quickly initiate and add search string record based on the current selected record
Move Used to move lines to another posting journal
Delete Easy way to delete many transactions, which can take very long, when done using the default delete
functionality
Renumbering Used to regenerate the voucher numbers in the journal. This is e.g. useful to ensure using the lowest
possible voucher numbers when using a continuous voucher series
Exchange rate Allows updating exchange rates per currency/date. Useful if the bank is not able to provide the
exchange rates related to the payments
Update payment date Easy way to update many transactions’ dates
7.2.5 POSTING
To post a posting journal, all transactions are required to have status Ready. This status is
automatically set when settling the transactions (automatically or manually), but can also be set by
the user, if the transaction is not to be settled.
The post method utilizes standard AX’s own posting functionality, meaning that the posting
functionality also includes a validation. This ensures that all transactions meet the posting
requirements configured throughout AX.
|Account statements 63
8 ACCOUNT STATEMENTS Account statements reflect the movements on the bank account, but how the account statement is
processed and utilized, often depends on the individual customer and the country in which the
customer resides. In some countries, the account statement is the basis for the posting the credit
and debit movements in the ERP system, while account statements are used for account
reconciliation in others.
This chapter will primarily focus on the process of account reconciliation, but it is also possible to use
account statements as a posting foundation. In that case, the account statement will also enter the
system as payment notifications (see 6).
The overall goal of the bank account reconciliation is to ensure that the posted ledger transactions
in AX reflect the physical movements on the bank account, thereby also ensuring that balances in AX
corresponds with the balances on the bank accounts.
8.1 IMPORT
For more info on importing return files, please see separate Importing bank return files document
Imported account statements are matched against own bank accounts, registered in the Banking
module (see 0). If a matching bank account is identified, the related company setup is used to
determine in which company to import and create the account statement and the related
transactions.
|Account statements 64
8.2 RECONCILIATION
To start reconciling the bank account(s), open the list of own bank account from AMC Banking >
Common > Own bank accounts.
The own bank account grid contains two fields furthest to the right, Last date and Reconciled. The
two fields provide a quick overview on which bank accounts that requires reconciliation. The Last
date field holds the date of the latest registered movement on the bank accounts. The Reconciled
field contains a small icon, which indicates whether the bank account has been fully reconciled. If
reconciliation is required, a small red cross will be displayed, but once the account is reconciled, a
green check mark will appear instead.
The bank account overview provides two reconciliation options:
1) Reconciliation across bank account statement (recommended)
2) Reconciliation per bank account statement
|Account statements 65
To reconcile across statements, simply click Reconcile, which will open the reconciliation form.
To reconcile one statement at a time, instead click Bank statements, which will open a list of
statements related to the selected bank account.
The account statement overview contains a Reconcile button, which will open the same
reconciliation form as can be opened from the bank account overview. In this case, though, the
reconciliation form will only include bank transactions related to the current selected account
statement.
|Account statements 66
The reconciliation form is built using a bank and a ledger section. The bank section contains a list of
imported bank transactions and the ledger section contains a list of ledger transaction registered on
the bank account’s offset account.
Initially the form will open using Unreconciled view, which will display the bank and ledger
transactions, which have not yet been reconciled. Two further view options exist; Reconciled
showing only reconciled transactions and All showing both reconciled and unreconciled transactions.
8.2.1 AUTOMATIC RECONCILIATION
To start an automatic account reconciliation run, click the Auto reconcile button. This will open a
small dialog allowing the user to enter a few criteria, which decides the behavior of the automatic
reconciliation.
Option Behavior
|Account statements 67
Allow “one-to-many” reconciliations Specifies whether the automatic reconciliation should be allowed to settle a single
bank transaction against multiple ledger transactions
Note: Ledger transactions are required to have the same voucher or document
number
Allow “date-amount” reconciliations Specifies whether the automatic reconciliation should be allowed to reconcile
transaction solely on amount and date.
Allow posting date difference Specifies the number of days that bank and ledger dates can differ
Once the behavior of the automatic reconciliation has been decided, click the OK button to initiate
the reconciliation functionality. The automatic reconciliation will loop through the bank transaction
displayed in the form and will attempt to match each bank transaction against AX ledger
transactions. When the reconciliation finishes, the results are displayed in an infolog.
The automatic reconciliation functionality will categorize the reconciliations into three levels,
depending on the certainty of the match
Value Meaning
High (Green) High reconciliation status is attained if a ledger transaction with for instance a unique payment
reference figuring in both the transaction of the bank and in Dynamics AX is found.
Medium (Yellow) Medium reconciliation status is attained if the posting text of the bank completely or partly contains
sequences recognizable in a ledger transaction in Dynamics AX. Also, the original basis of the ledger
entry is examined on the transaction so that a vendor payment having created an offset transaction on
the ledger account, for instance, is found if just the name or number of the company is found in the
posting text of the bank.
Low (Red) Low reconciliation status is attained if only the date and the amount on the bank transaction are the
occasions of the reconciliation against the ledger transaction.
The reconciled bank transactions and ledger transactions will automatically disappear from the
Unreconciled view. To see the reconciled transactions, switch to the Reconciled view.
|Account statements 68
Switching to Reconciled view will result in a new color code Level column on the left side of the grid.
The added column shows the match level of the individual transactions.
In addition, when selecting a reconciled transaction, all transactions related to the current
reconciliation, whether bank or ledger, will be marked in green. This allows the user to get a quick
overview of the current reconciliation. Furthermore, it is possible to show Only current
reconciliation, by checking or unchecking the check boxes above the two grids.
It is also possible to batch execute the automatic reconciliation across account statements and bank
accounts. This functionality is activated from AMC Banking > Periodic > Reconciliation > Bank
account reconciliation.
8.2.2 MANUAL RECONCILIATION
The user can reconcile bank transactions, which could not be reconciled automatically, manually.
This is done by marking the bank and ledger transactions to reconcile and clicking the Reconcile
button from the menu. Like the automatic reconciliation, the reconciled bank transactions and ledger
transactions will automatically disappear from the Unreconciled view. To see the reconciled
transactions, switch to the Reconciled view.
It is tempting to mark several bank and ledger transactions simultaneously to finish the reconciliation
in the fewest steps possible. However, we do not recommend this approach, as it quickly leads to a
loss of overview and confusing reconciliations. Furthermore, unreconciling a reconciled transaction
would result in the need to unreconcile all other related transactions as well.
|Account statements 69
8.2.3 LEDGER PROPOSAL
When reconciling transactions manually, situations where the bank and ledger amount does not
match, is likely to occur.
The ledger proposal is used to handle such situation. It is possible to add amount difference to the
ledger proposal, but it is also possible to add bank transactions, if they have not been registered on
the ledger side at all.
To add either the bank transaction or the amount difference to the ledger proposal, use the
respective buttons from the proposal part of the menu.
Once a transaction has been added to the ledger proposal, the Proposal button will be enabled,
allowing the user to enter the ledger proposal.
|Account statements 70
When the user is satisfied with the ledger proposal, the proposal can be transferred to an existing or
new journal from where the posting can be completed by clicking the Transfer to ledger button. The
transfer dialog also contains a Post option, which allows the user to automatically post the created
ledger journal
As the ledger part of the reconciliation form is showing data directly from standard ledger tables, transactions posted using the ledger proposal, i.e. on the bank account’s offset account, is available immediately by refreshing the form.
|Account statements 71
8.3 REPORTS
The Banking module contains two reports to support the bank account reconciliation process, which
are available from the Print menu.
8.3.1 RECONCILIATION REPORT
To document the account reconciliation, it is possible to print out a reconciliation report by clicking
the Reconcile report button from the own bank account list page form.
This will result in a small dialog, in which the user can specify a date interval and a so-called
Viewpoint allowing, seeing the either reconciliation from Current or Historical view.
The box From date is automatically specified using the latest of the two dates: account reconciliation
start date set on selected bank account or the start date of current fiscal year. Account reconciliation
start date is indicated under AMC Banking > Common > Own bank accounts > Maintain > Edit >
Reconciliation > Start date.
|Account statements 72
The box To date must be filled in with the date for which you wish to show the reconciliation. Be
advised that the start and end date must be from the same fiscal year and that opening entries are
created since problems with the ledger balance would arise in the report otherwise. The
reconciliation report is constructed as follows:
8.3.2 FORECAST REPORT
It is possible to print a forecast report, which simulates the near future cash flow. The forecast is
calculated dynamically, based on the latest account statement date from the bank as well as both
realized and unrealized customer and vendor payment
To print the forecast report, click Print > Forecast report in the own bank account list page.
|Appendix 73
9 APPENDIX
9.1 AGGRESSIVE CREDIT NOTE ACCUMULATION
Aggressive credit note accumulation offers the possibility to deduct future credit notes from similar
payments despite the credit notes being due later than the payments.
This section describes step-by-step, how a list of open invoices is handled and accumulated using the
aggressive credit note accumulation method.
Open invoices
Due date Amount
01.01 -500,00
08.01 2.000,00
10.01 1.500,00
10.01 -1.200,00
12.01 400,00
15.01 -500,00
31.01 800,00
31.01 -2.000,00
Current date = 05.01 | Date range 05.01 – 20.01
Credit notes lie outside date range; both prior and afterwards. By enabling the [Aggressive] credit note mode,
the module will attempt to pair credit notes (even though outside due range) with similar payments, while
ignoring due date differences.
|Appendix 74
The module will pair the credit notes with the earliest payment, which exceeds the credit note’s amount.
01.01.2015-500
08.01.20152.000
10.01.20151.500
10.01.2015-1.200
12.01.2015400
15.01.2015-500
31.01.2015800
31.01.2015-2.000
01.01.2015-500
08.01.20152.000
10.01.20151.500
10.01.2015-1.200
12.01.2015400
15.01.2015-500
31.01.2015800
31.01.2015-2.000
Payment outside date range
Open transactions
Removing payments outside date range (...but keeping credit notes)
01.01.2015-500
08.01.20152.000
10.01.20151.500
10.01.2015-1.200
12.01.2015400
15.01.2015-500
31.01.2015-2.000
No payment large enough
Credit note accumulation:
08.01.2015300
10.01.20151.000
12.01.2015400
31.01.2015-2.000
Result:
01.01.2015-500
10.01.2015-1.200
15.01.2015-500
08.01.20152.000
10.01.20151.500
Credit note outside date range
Credit note outside date range
|Appendix 75
9.2 CHARTS
From the overview of own bank accounts, it is possible to get a graphical view of data related to the individual bank accounts. Currently the module includes three charts, which can all be opened from the menu
- Balance: Provide an overview of the progression of the bank account’s balance over time
- Costs: Provides an overview of costs related to e.g. exchange fees, regular fees, interests etc.
- Post: Provides an overview of the daily movements on the bank account
9.2.1 TROUBLESHOOTING
If the chart is opened with wrong parameters (e.g. if bank account number has not been registered on the web service, specified in parameter setup), the following errors appear.
|Appendix 76
The chart all utilize some external scripts, which generate the individual charts visible in Internet
Explorer. If the chart tab appears blank when opened, it could be caused by restrictions in Internet
Explorer. In that case, Internet Explorer security settings need to be configured to allow running the
external scripts.
One way to accomplish this is to follow the steps below:
✓ Open Internet Explorer
✓ Select Internet Options from the menu and go to the Security tab
✓ Add the web service URL from the parameter form to the list of Trusted sites
9.3 POSTING SCENARIOS
The exchange rate when importing status files (DEBMUL) for the different posting scenarios can be:
Own account
currency
Payment
currency
Posting MSD Posting CUR Exchange rate
From file
DKK DKK DKK DKK 100, no
DKK USD DKK USD DKK/USD rate
EUR EUR DKK EUR DKK/EUR rate
EUR USD DKK EUR DKK/EUR rate
9.4 DEMO RETURN FILE
As a new feature, it is possible to create a demo account statement, based on the open invoices in
the AX environment. The feature is initialized from Setup > System > Demo return file.
|Appendix 77
The demo feature makes it possible to quickly set up a demo on the fly, without the need for an
active, working bank agreement, without deciding on certain file formats and without the need to
complete excessive setup. Thus, it is possible to create a realistic demo file based on the customer’s
own data.
Activating the menu item, opens a small dialog, where the user is asked to choose the bank account
to base the demo data on, and a file path where the demo file should be saved.
Once the OK button is clicked, the demo functionality will loop through the AX environment’s open
invoices, and attempt to create demo transactions, allowing users to test various reconciliation and
auto match scenarios.
To keep the demo simple, both bank accounts as well as open invoices are restricted to the company’s
currency only.
When finished looping through the open invoices, the demo file is created and an infolog is returned,
informing which of the various demo scenarios that were successfully created
|Appendix 78
|US Localizations 79
10 US LOCALIZATIONS If the US localizations model has been installed, the Banking users will have access to US specific
content and functionality, which is not part of the Banking foundation model.
10.1 POSITIVE PAY JOURNAL
The primary US specific feature is the Positive pay journal, which is added to the Journals section in
the Banking workspace.
The Positive pay journal is used to verify physical cheques, to prevent cheque fraud, and is opened
from AMC Banking > Journals > Positive pay journal.
|US Localizations 80
From the journal menu, the user is offered a few options like creating new Positive pay files, as well
as viewing, editing and processing existing Positive pay transactions. To see the details of the
individual journals, select a journal and click the Lines button.
The journal form contains the following fields:
Section Meaning
Positive The company indicates the id of the company, where the payments are processed from
Positive pay format The bank set up under Setup > Banks > Banks, which are to receive the positive pay transactions
Own account The positive pay related bank account, which is also the bank account, from which the cheques are executed.
Positive pay number Number identifying the journal, like the journal number, known from other journals
Lines Shows the total number cheques in the journal
Voided Shows the number voided cheques
Cutoff date Positive pay cutoff date
Confirmation number The confirmation number, which is provided by the bank upon receiving the positive pay file
File status Status of the positive pay journal/file
10.1.1 CREATION
To create Positive pay journals, click the Add > Positive Pay. Doing so, will open the Add payments
dialog
|US Localizations 81
The dialog contains only two fields and a range section, which can be used to limit the cheques being
added to the journal.
Section Meaning
Own account The bank account on which to create positive pay transactions. The bank account’s offset account is
used to find cheques that are going to be executed from the bank account
Cutoff date A simple transaction date, which is used to determine which cheques to add to the journal
Once the desired ranges have been specified, click the OK button to generate the Positive pay journal
and transactions.
10.1.2 TRANSFER
Use the transfer button to validate the data of the individual Positive pay transactions. If all
transactions are validated successfully, the Positive pay file is created, allowing users to forward the
physical file to the bank.