AMC Consult Banking 2012 v4 Banking Software User Guide
AMC Banking 2012 v4 is a software solution designed for Microsoft Dynamics AX 2012, providing functionalities for executing payments, importing and posting payment notifications, and importing and reconciling bank account statements.
Advertisement
Advertisement
U
SER GUIDE
FOR
AMC B
ANKING
M
ICROSOFT
D
YNAMICS
AX 2012
AMC Consult A/S
May 19, 2017
Banking 2012 v4
C
ONTENTS
|Introduction 2
|Introduction 3
|Introduction 4
1 I
NTRODUCTION
To benefit as much as possible from your AMC-Banking module, you should read this user guide, describing in details, 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.
You will also be able to read setups needed for localizations in Benelux and Germany.
Best regards
Development team
AMC-Consult A/S
|Introduction 5
2 F
ACILITIES
The Banking module covers three main areas of accounting.
Execution of payment
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.
|Facilities 6
3 P
REREQUISITES
To be able to complete the setup and actions described in this manual, there are several prerequisites
The Banking module should be installed
A valid Banking license should exist and the necessary license setup should have been completed
|Prerequisites 7
4 S
ETUP
4.1 P ARAMETERS
The module’s basic parameters are set up from AMC Banking > Setup > Parameters.
4.1.1 P AYMENTS
The payments tab contains setup specifically related to the process of executing payment
The fields on the payments tab have the following features:
Field
Payment accumulation
Description
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
Centralized payment method The options are:
|Setup 8
- 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 only in their respective companies. Though not required, using this option will result in the creation of more posting journals, to keep transactions from different companies separate.
Grace period Number of days to add to cash discount date, and thereby number of days to allow cash disc even though overdue
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
4.1.2 P OSTING
The posting tab contains setup specifically related to the process of posting payments
The fields on the posting tab have the following features:
|Setup 9
Field
Name of journal
Split payment notifications
Auto match
Medium match
Grace period
Description
The journal template to use for automatic created posting journals. E.g. journals created because of imported bank files or created when posting a payment journal
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
This mark specifies to automatically match payments that are created during import of bank files
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
Number of days to add to cash discount date, and thereby number of days to allow cash disc even though overdue
|Setup 10
4.1.3 W EB SERVICE
The web service tab contains setup specifically related to the process of communicating with the
AMC-Banking web service
The fields on the web service tab have the following features:
Field
Solution
URL
Description
The options are:
- Plus
- Enterprise
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)
|Setup 11
Username
Custom login
Password
Date verified
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.
If needed you can add a custom part to the AX serial number and use this for communicating with the web service
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
The date the license was last verified
Note: The license is automatically verified every 14 days
4.1.4 L OG
The log tab contains setup specifically related to logging of the web service communication.
The fields on the log tab have the following features:
Field
Log detail level
Enabled
File name
Description
The level of information to retrieve and present when the Banking module communicates with the web service and license server
The options are:
- All: Both regular info, warnings and errors
- Errors and warnings: Only warnings and errors
- Errors only: Only errors
- Debug: All messages including “unstructured” messages (e.g. unhandled exceptions)
Specifies whether logging of web service requests and response are enabled
The name of the web service log file residing on the server side
|Setup 12
|Setup 13
4.2 B ANKS
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.
To add banks, click the “Select banks” button in the menu. This will open a small form, in which banks can be added or removed. To populate the “Available” (banks) list, click the “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.
|Setup 14
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
License bank
Calendar
Description
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
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.
Manual account Specifies whether users are prompted for a manual own bank account, when adding payments to a payment journal. If not checked, own bank account is selected automatically
based on the individual open invoices. See also Appendix 8.1
Postable Specifies when payment transactions are considered ready for posting. The options are:
Transferred: Once transferred and payment file has been created
Validated: Once successfully validated by the bank, and validation file is imported
Executed: Once the bank has confirmed that payments have been executed, and the confirmation file is imported
|Setup 15
4.2.1 A DVANCED
Clicking the “Advanced” button will open a form where additional bank setup can be configured.
The fields on the fast tabs have the following features:
Field
Company
Company
Description
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
The name of the advanced bank setup. Name
File paths
File to bank
Path from bank
Archive
Bank agreement
Bank agreement 1
Bank agreement 2
Alternative sender
Alternative sender
Used to specify where to save created payment files
The path where bank files are stored prior to import
The path where bank files are archived once successfully imported
Used to identify a bank agreement (if any)
Used to identify a “sub-level” bank agreement (if any)
Used to override the default sender name, which is otherwise fetched from standard AX company setup
|Setup 16
4.2.2 B ANK 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
Calendar
Description
Ignore weekend
Maintain list of bank holidays
Description
Identification of the bank holiday calendar
Brief description of the bank holiday calendar
Used to specify whether to allow payment on weekends. If checked weekends are considered as regular weekdays and thereby payment days.
In this section, you can setup the bank holidays for this calendar
|Setup 17
4.2.3 P RICES
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.3 O
WN BANK ACCOUNTS
The setup related to your company’s own bank accounts is opened from AMC Banking > Common >
Own bank accounts.
|Setup 18
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 7)
and for balance chart, cost chart and post chart (see section 8.5)
Clicking either New > Bank Account or Maintain > Edit, will open a separate, detailed bank account setup form.
The fields on the fast tabs have the following features:
Description Field
Bank
Bank
Bank account
The internal bank to which the bank account belongs
The account number that is assigned by the bank
Note: Both local bank account numbers (BBAN) and IBAN numbers are allowed in this field
The currency of the bank account
The SWIFT code identifying the bank and possibly branch
Currency
SWIFT code
General
Company
More currencies
Priority
The company or legal entity in AX to which the bank account belongs
Specifies whether to allow other currencies than the bank account’s own currency
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.
|Setup 19
Offset account type
Offset account
Customer payment method
Vendor payment method
Bridging posting
Auto match class
Reconciliation
Start date
Reconcile principle
Bank balance
Ledger balance
Used to specify the type of the offset account in AX. The options are:
Bank
Ledger
Used to specify the offset account in AX which the bank account correlates to
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
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
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.
Field used to specify, which auto match class to use for auto matching imported transaction related to the bank account.
If left blank, the auto match functionality will use the default auto match class, which is distributed as part of the AMC-Banking module
The options are:
Main account: Reconciliation is done against all transactions on the offset account’s main account, regardless of financial dimensions
Financial dimension: Reconciliation is done only against the transactions with the exact same financial dimension as the one specified in the offset account field
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.
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
Used to specify the bank account’s balance on the start date. The balance is used in the reconciliation report
Used to specify the ledger account’s 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.
|Setup 20
4.3.1 C OMPANY 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
Company
Payments
Posting
Auto match
Description
Identification of the company in AX
Specifies whether payment journals in the related company can use the bank account
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
Specifies in which companies to look for open invoices when the auto match functionality is executed
|Setup 21
4.4 C USTOMERS 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.
The status 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 22
The fields in the form have the following features:
Field
General
Account type
Account number
Name
Disabled
Description
Specifies whether it is a customer or a vendor account
The account number of the vendor
The name of the vendor
Specifies whether the vendor has been disabled and should be excluded from the payment process
Discount
Grace period
Payment accumulation
Override
The number of days to allow overdue cash discount
Payment accumulation
Used if default payment accumulation of open invoices should be overridden on specific vendor level
Specifies how open invoices should be accumulated when creating payments. See section
|Setup 23
Advice
File advice
Disable auto advice
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
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 ID
Email address to use when sending payment advices to vendor
AX email template to use when sending payment advices to vendor
4.4.1 B ANK 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 24
The fields in the form have the following features:
Description Field
Identification
Bank
Name
Bank account
Routing number type
Routing number
Bank account number
SWIFT code
Currency
Bank account identification
Name of the bank account
Code identifying the type of the routing number
Routing number of the bank
The account number that is assigned by the bank
The SWIFT code identifying the bank and possibly branch
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.
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
Address
Bank address
Country ISO
Alternative address
The address of the bank related to the bank account
Specifies the country of the bank related to the bank account
Used to specify an alternative vendor address. If nothing is specified, vendors primary address is used
The address of correspondent bank, if a correspondent bank is used Correspondent bank address
Bank rules
Additional fields Fields in this section are used to define specific values of the payment if needed. Contact
AMC-Consult in any doubt.
|Setup 25
4.5 J OURNALS
The general behavior of the posting journal is set up from AMC Banking > Setup > Journals >
Journals.
Field
Voucher
New voucher
Voucher series
Posting
Delete lines after posting
Financial dimensions
Default financial dimensions
Description
Specifies how and when new vouchers are fetched. The options are:
In connection with balance
Manual
One voucher number only
The voucher series used
Specifies whether journals should be deleted when successfully posted
The journal can be configured with financial dimensions, which will automatically be added to created journals
|Setup 26
4.6 P AYMENT 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 A DVICE 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 C OMPRESSED
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 27
4.6.1.2 D YNAMIC
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 28
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.
|Setup 29
4.6.1.3 C LASS
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.
4.6.2 P REVIEW
Regardless of the payment advice type, it is possible to generate an advice preview by clicking the
“Preview” button in the top menu. 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
|Setup 30
4.7 P AYMENT TYPE PRIORITIES
When adding payments, users are presented with several payment proposals, representing different payment scenarios. Should the users find the default provided payment proposals inadequate, they can instead setup their own prioritized list of payment types from AMC Banking > Setup > Payment
type priorities.
On the left side, the priority form contains an overview of existing payment type priority lists. On the right side, the form contains a list of prioritized payment types related to the current selected priority list. To manually prioritize payment types across banks, edit the payment type list.
Once a priority list has been created, it will automatically be included in future payment proposals.
If the “User only” check box is checked, the payment proposal will only be included in payment proposals initiated by the “Created by” user.
|Setup 31
4.8 S EARCH 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.
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
|Setup 32
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:
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.8.1 C LEANUP
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 the “Cleanup” button in the top menu. The button opens a simple dialog, in which the user can specify “Older than” number of days.
Upon clicking the “OK” button, 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 33
4.9 T RANSACTION TEXTS
The transaction text setup which are reflected on the individual journal transactions’ “Description” field 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.
|Setup 34
4.10 W ORKFLOWS
To ensure that payments are only executed if the related customer/vendor bank accounts have been approved, the Banking module includes a workflow, which can be set up from AMC Banking > Setup
> Workflows
All standard AX objects required by the workflow are included in the AMC -Banking 2012 Foundation model.
Therefore, no additional installation is necessary. Execution and processing of workflows also requires
standard AX workflow configuration (see 8.9)
To enable the workflow, follow the steps below
1) Click the “New” button from the menu
2) Select the “Bank account number approval workflow” and click the “Create workflow” button
3) Use the opened workflow setup tool to create and configure the workflow as desired (see
|Setup 35
4.10.1 W ORKFLOW STATUS
If correctly configured and enabled, the workflow restricts users from using newly added or changed bank account numbers, without the required prior approval by an authorized user. Enabling the workflow will furthermore result in the non-editable field “Workflow status” being visible in the customer and vendor bank account setup forms.
The workflow status field has one of the four following values:
Active
The bank account has been properly approved (or did already exist prior to enabling the workflow) and is available for payment execution
Inactive
The bank account has just been created or the bank account number has been changed.
Pending
The bank account has number has been submitted for approval and is still pending the approval by an authorized user.
Rejected
The authorized approval user rejected the submitted bank account. The user can now change the bank account number and resubmit the record for approval.
|Setup 36
4.10.2 W ORKFLOW PROCESSING
4.10.2.1 S UBMIT
If the workflow for bank account number approval is enabled, new and changed bank accounts are given status “Inactive”. At the same time, the user will be presented with a yellow workflow ribbon allowing the user to submit the bank account for approval.
Once the “Submit” button is clicked, the user is presented with a small window allowing the user to add remarks to the approver.
When the user clicks the “Submit” button, the bank account record is added to the workflow processing.
|Setup 37
Once the bank account record is picked up by the workflow processing system, the bank account’s workflow status changes to “Pending” and the bank account record is locked, hence can no longer be edited nor deleted.
The user though, can “Cancel” the workflow, e.g. if the bank account number was typed incorrectly.
This is done from the yellow workflow ribbon’s “Action” button menu. Cancelling the workflow will result in the workflow status changing to “Rejected” allowing the user to edit the bank account record.
In addition to the “Cancel” button, the “Action” button menu also allows users to “View history”, which opens an overview displaying the full workflow history related to the bank account record
|Setup 38
4.10.2.2 A PPROVE
When a bank accounts changes to status “Pending”, the workflow processing system adds a standard
AX notification to the approval user(s).
Next step is for the approver to either approve or reject the pending bank accounts, which can be done individually on the bank account records from the Banking modules bank account forms.
|Setup 39
Furthermore, it is possible to open a list of pending bank accounts from AMC Banking > Inquiries >
Workflow > Pending bank accounts. The form provides a quick complete overview of current pending bank accounts.
From the yellow workflow ribbon’s “Action” button menu, the approver can “Approve” or “Reject” the bank account records, changing the bank account workflow status to “Active” or “Rejected” respectively.
Like the user, the approver can use the “Cancel” and “View history” options. Using the “Cancel” button will have a similar result to using “Reject” button. In both cases, the bank account status will change to “Rejected” and the users will be restricted from using the bank account during payment processing.
|Setup 40
4.10.3 U SER RIGHTS
All users, assigned the “AMC Banking manager” security role, can submit bank account approval requests, but only users assigned the “AMC Banking administrator” security role can approve pending bank accounts.
Security roles is assigned to users from System administration > Common > Users > Users > Edit >
User’s roles > Assign roles:
|Setup 41
5 P
AYMENTS
This section covers the creation, approval and execution of payments.
5.1 P REREQUISITES
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 P AYMENT 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 the “Lines” button.
|Payments 42
The payment journal form contains the following fields:
Section Meaning
Company
Bank
Journal
Description
Lines
Errors
Posted
The company indicates the id of the company, where the payments are processed from
The bank set up under Setup > Banks > Banks, which is used to execute the payment batch/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 of the journal
Shows the total number of payment lines in the journal
Shows the number of erroneous payment lines in the journal
Shows the number of posted payment lines in the journal
5.2.1 C REATION
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 sufficient to process customer payments.
To create payments, click either the “Customer payments” or the “Vendor payments” button from the “Add” section of the menu. Doing so, will open an “Add payments” dialog like the one below.
|Payments 43
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
Due date
Discount date
Forced payment date
Credit note accumulation
Meaning
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.
If you wish to use the cash discount in your search, a date can be indicated in this section as the date limiting the search. Cash discounts that can be used until and including this date are included in the search.
Notice: This section is only effective if the “Cash discount” box is marked.
Used to override the automatic payment date determination and instead use a forced payment date, disregarding holiday setup etc.
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 8.2
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 8.1.
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 44
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 has to 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 balance: 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 ledger: Checks whether the involved bank accounts have sufficient balance to process the payment, without resulting in a negative balance.
The balance is calculated using the bank account’s offset account balance, and if the balance is being exceeded, the check returns a warning,
|Payments 45
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 P REPARATION
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 46
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 according to the settled open invoices.
|Payments 47
5.2.3 V ALIDATION
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” and a descriptive log, explaining what needs to corrected, is added to the line at hand. The log is available in a form part to the right. Alternatively, the log can be opened by hovering over the small icons displayed in the left-most column of the payment grid lines.
Note: The log lines each has an icon showing the nature of the individual lines. Some lines also have a blue question mark, indicating that more information regarding the specific error is available. Clicking the questing mark redirects the user to the AMC-Banking support page, which contains detailed information on the error and how to solve it
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 48
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 A PPROVAL 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 hostto-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 P OSTING
Once the payments have been transferred, the next step is to post the payments. Where and when posting is available depends on the execution bank’s “Postable” setup, which has three values (see
|Payments 49
The options are:
1) Transferred
Posting is available immediately and is executed directly from inside the payment journal
2) Received
Posting is only available if the bank has confirmed the receipt of the individual payment transactions. Posting is done directly from inside the payment journal
3) Executed
Posting is only available if the bank has confirmed the execution of the individual payment transactions. During the import of the banks payment notification, which confirms the payment execution, a separate posting journal is created. Posting is done from inside the created posting journal.
If the posting is done from the payment journal, a posting journal is created and posted right away. If the posting functionality is unable to finish, e.g. because of posting errors, the posting journal is not deleted. This allows the user to continue working from inside the created posting journal
If posting is postponed until the bank has confirmed either the receipt or execution of payments, users will sometimes experience payments being rejected by the bank. In that case, users can end up with payment journals containing a mix of both successful and erroneous payment transactions.
It will not be possible to post such a payment journals because of the erroneous payments. At the same time, it will not be possible to delete the erroneous transactions in the journal, because of the transferred payments, which makes the payment journal non-editable.
The “Move” button from the menu is used to resolve such situations. The move functionality allows moving transactions from the current journal to a new journal.
In this case, the move functionality can be used to move the erroneous transactions to a new payment journal, where the user can then resolve the errors before resending the payments to the
|Payments 50
bank. This will leave only successful payments in the original payment journal, which will turn it into a postable state.
5.3 E
MAIL 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.
|Payments 51
Available placeholders are:
Placeholder
%Custname%
%Vendname%
Meaning
Customer’s name
Vendor’s name
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 the “Payment advice” button from the “Print” button menu.
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.
|Payments 52
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 A
DDITIONAL 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
The menu items have the following functions:
Menu item
Transactions
Cancel
Move
Update payment date
Function
A link to standard AX’s transactions form, which can be effectively used to get a detailed list of payees’ transactions.
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
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.
Easy way to update several transactions’ payment dates simultaneously
|Payments 53
6 P
AYMENT 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.
6.1 I
MPORT
Payment notifications are imported from AMC Banking > Common > Import bank return files (see
Imported payment notifications are matched against the own bank accounts, registered in the
to determine in which company to import the payment notification in, resulting in a posting journal being created in the respective company.
6.2 P OSTING 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 54
The posting journal overview have the following fields:
Section
In use
Company
Meaning
Specifies whether the journal is in use by either the system or a user
The company, in which the journal belongs
Name of journal
Description
Name of the journal configured in Setup > Journals > Journals
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
The total number of lines in the current payment suggestion. Lines
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”.
|Payment notifications 55
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.
6.2.1 A UTO MATCH
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
Rule (Turquoise)
High (Green)
Medium (Yellow)
Match criterion
A rule level match is achieved if the payment was identified from user defined search string configuration
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)
A medium level match is achieved if the payment was identified from either:
Customer account no (4th priority)
Our account number (5th priority)
|Payment notifications 56
Low (Red)
User (Blue)
Customer name (6th priority)
Customer bank account (7th priority)
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
If the user manually settles the transactions or changes status to “Ready”, the transaction is marked with match level “User”.
The auto match was not executed or was not able to match the payment. None (White)
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.
6.2.2 M ANUAL 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 57
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 58
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 Customer pays invoice A + B Customer receives invoice C
Customer mistakenly pays both invoice B + C
Payment exceeding expected amount
Invoice
A
Invoice
B
Invoice
A
Invoice
B
Invoice
A
Invoice
B
Invoice
C
Invoice
A
Invoice
B
Invoice
C
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
6.2.3 C ASH 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 59
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
6.2.4 A DDITIONAL 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 60
The menu items have the following functions:
Menu item
Search string
Move
Delete
Renumbering
Exchange rate
Update payment date
Function
Quickly initiate and add search string record based on the current selected record
Used to move lines to another posting journal
Easy way to delete many transactions, which can take very long, when done using the default delete functionality
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
Allows updating exchange rates per currency/date. Useful if the bank is not able to provide the exchange rates related to the payments
Easy way to update many transactions’ dates
6.2.5 P OSTING
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.
|Payment notifications 61
7 A
CCOUNT 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.
7.1 I
MPORT
Account statements are imported from AMC Banking > Common > Import bank return files (see 8.2)
Imported account statements are matched against own bank accounts, registered in the Banking
module (see 4.3). 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.
7.2 R ECONCILIATION
To start reconciling the bank account(s), open the list of own bank account from AMC Banking >
Common > Own bank accounts.
|Account statements 62
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 63
To reconcile across statements, simply click the “Reconcile” button, which will open the reconciliation form.
To reconcile one statement at a time, instead click the “Bank statements” button, 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 64
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.
7.2.1 A UTOMATIC 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.
|Account statements 65
Option
Allow “one-to-many” reconciliations
Allow “date-amount” reconciliations
Allow posting date difference
Behavior
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
Specifies whether the automatic reconciliation should be allowed to reconcile transaction solely on amount and date.
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
High (Green)
Medium (Yellow)
Low (Red)
Meaning
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 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 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 66
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.
7.2.2 M ANUAL 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.
7.2.3 L EDGER PROPOSAL
When reconciling transactions manually, situations where the bank and ledger amount does not match, is likely to occur.
|Account statements 67
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.
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.
|Account statements 68
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.
7.3 R ECONCILIATION 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.
|Account statements 69
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.
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:
|Account statements 70
8 A
PPENDIX
8.1 I NTELLIGENT PAYMENT PROPOSAL
|Appendix 71
8.2 A GGRESSIVE 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
01.01
08.01
10.01
10.01
12.01
15.01
31.01
31.01
Amount
-500,00
2.000,00
1.500,00
-1.200,00
400,00
-500,00
800,00
-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 72
The module will pair the credit notes with the earliest payment, which exceeds the credit note’s amount.
Open transactions
01.01.2015
-500
08.01.2015
2.000
10.01.2015
1.500
10.01.2015
-1.200
12.01.2015
400
15.01.2015
-500
31.01.2015
800
31.01.2015
-2.000
Removing payments outside date range (...but keeping credit notes)
01.01.2015
-500
Credit note outside date range
08.01.2015
2.000
Credit note accumulation:
10.01.2015
1.500
10.01.2015
-1.200
12.01.2015
400
01.01.2015
-500
08.01.2015
2.000
10.01.2015
1.500
10.01.2015
-1.200
12.01.2015
400
15.01.2015
-500
31.01.2015
800
Payment outside date range
31.01.2015
-2.000
Credit note outside date range
15.01.2015
-500
31.01.2015
-2.000
No payment large enough
Result:
08.01.2015
300
01.01.2015
-500
08.01.2015
2.000
10.01.2015
-1.200
10.01.2015
1.000
10.01.2015
1.500
15.01.2015
-500
12.01.2015
400
31.01.2015
-2.000
|Appendix 73
8.3 D ETERMINING PAYMENT DATE , AMOUNT AND CASH DISCOUNT
Payment add
Add transactions to journal
Use total date No
Yes
Payment date
=
Total date
Use cash disc Yes
Cash disc date + grace days
<
System date
No
Cash disc date + grace days
<
Forward date
No
Payment date
=
Due date
Yes Yes
No
Payment date
=
Cash disc date
No
Payment date
<
Forward date
Payment date
=
System date
No
Yes
Payment date
<
System date
Yes
Payment date
=
Forward date
Use cash disc Yes
Payment amount
=
Transaction amount
- cash disc amount
No
Payment amount
=
Transaction amount
Payment added
8.4 I
MPORT BANK RETURN FILES
If the bank can provide return files, they can be imported in the Banking module, by activating AMC
Banking > Common > Import bank return files.
When running on a Plus solution, the user is prompted with a very simple dialog, which only allows the user to filter, from which banks to import return files.
Filtering of banks is not required and is only used actively in very few cases. However, to filter the banks, click the “Banks” button. This will open a small form, in which the user can enable or disable the individual active banks. All banks are enabled by default.
|Appendix 74
Users running on an Enterprise solution will have a few more options, when activating the import of bank return files. Here it is also possible to specify, whether to upload local stored bank return files, a date range, a journal number range and a message type range.
The message type range can be used to filter, which types of bank return files to import. The different types available are:
|Appendix 75
- BANSTA: Payment validation responses
- CONTRL: Payment receipt confirmation
- CREMUL: Payment notification containing a list of executed credit transactions
- DEBMUL: Payment notification containing a list of executed credit transactions
- FINSTA: Account statement
Finally, when running an Enterprise solution, it is also possible to run the import repeatedly using standard AX batch functionality. Batch functionality and configuration is completed from the “Batch” tab.
|Appendix 76
8.4.1 I MPORT LOG
All imported return files are stored in an import log. To open the list of imported return files, use
AMC Banking > Inquiries > Import log.
The import form contains only basic data related to the individual return files. To see details regarding e.g. transactions, click the “Details” button in the menu.
It is also possible to reprocess return files by selecting the return file to reprocess and clicking the
“Reprocess” button. If a return file has no checkmark in the “Processed” column, it usually means that an error occurred during the original return file processing; hence, the return file has not been processed. In that case, the button’s label will change to “Process”.
If you are not sure, whether everything has been imported from the web service, the “Import” button is used to synchronize the list of return files. The import method compares the list of return files with the return files available on the web service and import the missing return files, if any exist.
8.5 C HARTS
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
|Appendix 77
8.5.1.1 B ALANCE
The balance chart provides an overview of the progression of the bank account’s balance over time.
8.5.1.2 C OSTS
The costs chart provides an overview of the costs related to e.g. exchange fees, regular fees, interests etc.
|Appendix 78
8.5.1.3 P OST
The post chart provides an overview of the daily movements on the bank account
8.5.2 D EBUGGING
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 79
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
|Appendix 80
8.5.3 E NTERPRISE P ORTAL
Charts can also be added to the role center if Enterprise Portal has been installed on the AX environment. The EP charts are included in their own model, and can be downloaded as an add-on from http://www.amcbanking.com
.
The charts are provided as web parts, which can be added to the role center using the following steps
1) Click “Personalize this page” link in the upper right corner
2) Click “Add a Web Part”, select “User control” and click the “Add” button
3) Click the small checkbox on the right side of newly added web part, click on the small black triangle next the check box and select “Edit My Web Part”.
|Appendix 81
4) Use the “Dynamics User Control WebPart” on the right side, to configure the web part. The
EP add-on includes three chart options: a. AmcBankBalanceChart b. AmcBankCostChart c. AmcBankPostChart
5) Once the configuration is done, click the “Apply” button. If the web part appears as expected, click the “Ok” button.
6) Click “Stop Editing” button to turn off edit mode again
Once the desired webparts have been added, it is possible to display data related to the individual own bank accounts, by selecting the bank account from the lookup
|Appendix 82
8.6 P OSTING SCENARIOS
The exchange rate when importing status files (DEBMUL) for the different posting scenarios can be:
Own account currency
DKK
DKK
EUR
EUR
Payment currency
DKK
USD
EUR
USD
Posting MSD
DKK
DKK
DKK
DKK
Posting CUR
DKK
USD
EUR
EUR
Exchange rate
From file
100, no
DKK/USD rate
DKK/EUR rate
DKK/EUR rate
8.7 D
EMO 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.
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 invoic es 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 83
8.8 B
ASIC WORKFLOW SETUP EXAMPLE
The following section describes a basic step-by-step example on how to setup the bank account approval workflow from the workflow setup tool
8.8.1.1 B ASIC SETTINGS
Click the “Basic settings” button in top menu and complete the following configuration:
|Appendix 84
|Appendix 85
Click the “Close” button and save the settings.
8.8.1.2 A PPROVE BANK ACCOUNT NUMBER OBJECT
Right click on the “Approve bank account” approval object. Choose “Properties” and complete the following configuration:
|Appendix 86
|Appendix 87
Click the “Close” button and save the settings.
8.8.1.3 A PPROVE BANK ACCOUNT NUMBER STEP OBJECT
Double-click the “Approve bank account number” approval object. You should now see the “Approve bank account number” step object:
Right-click the ”Approve bank account number” step object, choose “Properties” and complete the following configuration:
|Appendix 88
|Appendix 89
|Appendix 90
Click the “Close” button and finally click the “Save and close” button.
Please note, that each workflow can have several versions configured in the system, but only one of the versions can be active. In the “Workflows” list page, click the “Versions” button. The “Workflow versions” window should appear, displaying the configured versions.
The “Workflow versions” form allows users to see, whether the individual workflow versions are valid, whether they are active etc.
Furthermore, users can activate the individual versions, export/import workflow version setup and view, edit or delete versions.
|Appendix 91
8.9 S TANDARD AX WORKFLOW CONFIGURATION
To use the workflows included in the Banking module (as well as standard AX workflows) a Microsoft
Dynamics AX administrator must configure the workflow system.
8.9.1 E XECUTION ACCOUNT
First important thing to do is to configure a workflow execution account, which is used by all workflows to run and execute planned procedures. The workflow execution account runs business logic for the application and accesses Microsoft Dynamics AX data. The domain account that you select to serve as the workflow execution account must have the following characteristics:
It must be a dedicated account. A dedicated account is used only for a specific purpose.
It must have a password that does not expire.
It must have minimal access to network resources.
To specify the workflow execution account, follow the steps below:
|Appendix 92
1) Open System administration > Setup > System > System service accounts
2) In the “Workflow execution account” area of the form, specify a domain account to serve as the workflow execution account. The domain account can be specified in one of two ways: a. The network domain and related account username/alias b. A Microsoft Dynamics AX user.
The account that you specify is assigned to the Microsoft Dynamics AX system administrator role
If you are using Microsoft Dynamics AX 2012 R2 or later, repeat steps one through three for each partition in your Microsoft Dynamics AX installation.
8.9.2 N UMBER SEQUENCES
Next things to configure are the number sequences used by the workflow. Number sequences handle the identification numbers, which are automatically assigned to every workflow that is created and every instance of a workflow that is generated. If there is not any free number sequence in the system, then a new one should be created instead. https://technet.microsoft.com/EN-US/library/hh242127.aspx
To specify which number sequences are used to generate workflow IDs and workflow instance IDs, complete the following procedure:
|Appendix 93
1) Open System administration > Setup > System parameters
2) Select the “Number sequences” tab
3) Select the “Workflow ID” row and enter the number sequence to use to generate workflow
IDs in the “Number sequence code” field
4) Select the “Instance ID” row and enter the number sequence to use to generate workflow instance IDs in the “Number sequence code” field
8.9.3 B ATCH JOBS
Next thing to configure are workflow batch jobs. The workflow system uses batch jobs to process messages, determine due dates for work items, and process notifications for line items.
To create a batch group for the batch jobs, follow these steps:
1) Open System administration > Setup > Batch group
2) Create a new batch group
|Appendix 94
To specify the servers that the batch group runs on follow these steps:
1) Open System administration > Setup > Batch group
2) Select the batch group that you created in the previous procedure.
3) Click the “Batch servers” tab and add the AOS servers, which should serve as batch servers
Finally run the “Workflow infrastructure configuration wizard” tool to specify how often the workflow batch jobs should be processed. Follow these steps:
1) Open System administration > Setup > Workflow > Workflow infrastructure configuration
2) On the welcome page, click “Next”
|Appendix 95
3) Select a batch group and click “Next”
4) Select a batch group, specify how often the batch job should run and click “Next”
5) Select a batch group, specify how often line-item notifications should be processed and click “Next”
6) Click “Finish” to finish and close the wizard.
|Appendix 96
9 US L
OCALIZATIONS
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.
9.1 P OSITIVE 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 97
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
Positive pay format
Own account
Positive pay number
Lines
The company indicates the id of the company, where the payments are processed from
The bank set up under Setup > Banks > Banks, which are to receive the positive pay transactions
The positive pay related bank account, which is also the bank account, from which the cheques are executed.
Number identifying the journal, like the journal number, known from other journals
Shows the total number cheques in the journal
Voided
Cutoff date
Shows the number voided cheques
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
9.1.1 C REATION
To create Positive pay journals, click the “Positive Pay” button from the “Add” menu. Doing so, will open an “Add payments” dialog like the one below.
|US Localizations 98
The dialog contains only two fields and a range section, which can be used to limit the cheques being added to the journal.
Section
Own account
Cutoff date
Meaning
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
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.
9.1.2 T RANSFER
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.
|US Localizations 99
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
Advertisement
Key features
Execute payments to customers and vendors
Import and handle payment notification files
Import and reconcile bank account statements
Supports hundreds of banks worldwide
Handles both structured and unstructured payment information
Advanced automatic reconciliation functionality
User-friendly interface
Detailed documentation and support
Frequently asked questions
The main functionalities include executing payments, importing and posting payment notifications, and importing and reconciling bank account statements.
AMC Banking 2012 v4 supports hundreds of banks worldwide.
AMC Banking 2012 v4 can handle both structured and unstructured payment information.
