USER GUIDE AMC BANKING FOR MICROSOFT DYNAMICS AX 2012
AMC Consult A/S September 12, 2016 Banking 2012 v4
CONTENTS 1
Introduction...................................................................................................................................5
2
Facilities .........................................................................................................................................6
3
Prerequisites..................................................................................................................................7
4
Setup .............................................................................................................................................8 4.1 Parameters ............................................................................................................................8 4.1.1
Payments ................................................................................................................8
4.1.2
Posting ....................................................................................................................9
4.1.3
Web service ......................................................................................................... 11
4.1.4
Log ....................................................................................................................... 12
4.2 Banks .................................................................................................................................. 13 4.2.1
Advanced ............................................................................................................. 15
4.2.2
Bank holidays ....................................................................................................... 16
4.2.3
Prices ................................................................................................................... 17
4.3 Own bank accounts ............................................................................................................ 17 4.3.1
Company setup .................................................................................................... 20
4.4 Customers and vendors...................................................................................................... 21 4.4.1
Bank accounts...................................................................................................... 23
4.5 Journals .............................................................................................................................. 25 4.6 Payment advice .................................................................................................................. 26 4.6.1
Advice types ........................................................................................................ 26
4.6.2
Preview ................................................................................................................ 29
4.7 Payment type priorities ...................................................................................................... 30 4.8 Search strings ..................................................................................................................... 31 4.8.1
Cleanup ................................................................................................................ 32
4.9 Transaction texts ................................................................................................................ 33 4.10 Workflows .......................................................................................................................... 34 4.10.1
Workflow status .................................................................................................. 35
4.10.2
Workflow processing ........................................................................................... 36
4.10.3
User rights ........................................................................................................... 40 |Introduction
2
5
Payments .................................................................................................................................... 41 5.1 Prerequisites....................................................................................................................... 41 5.2 Payment journal ................................................................................................................. 41 5.2.1
Creation ............................................................................................................... 42
5.2.2
Preparation .......................................................................................................... 45
5.2.3
Validation ............................................................................................................ 47
5.2.4
Approval and transfer.......................................................................................... 48
5.2.5
Posting ................................................................................................................. 48
5.3 Email advice........................................................................................................................ 50 6
Payment notifications ................................................................................................................ 52 6.1 Import ................................................................................................................................. 52 6.2 Posting journal ................................................................................................................... 52
7
6.2.1
Auto match .......................................................................................................... 54
6.2.2
Manual settlement .............................................................................................. 55
6.2.3
Cash discount ...................................................................................................... 57
6.2.4
Other functions ................................................................................................... 58
6.2.5
Posting ................................................................................................................. 59
Account statements ................................................................................................................... 60 7.1 Import ................................................................................................................................. 60 7.2 Reconciliation ..................................................................................................................... 60 7.2.1
Automatic reconciliation ..................................................................................... 63
7.2.2
Manual reconciliation .......................................................................................... 65
7.2.3
Ledger proposal ................................................................................................... 65
7.3 Reconciliation report .......................................................................................................... 67 8
Appendix .................................................................................................................................... 69 8.1 Intelligent payment proposal ............................................................................................. 69 8.2 Aggressive credit note accumulation ................................................................................. 70 8.3 Determining payment date, amount and cash discount ................................................... 72 8.4 Import bank return files ..................................................................................................... 72 8.4.1
Import log ............................................................................................................ 75 |Introduction
3
8.5 Charts ................................................................................................................................. 75 8.5.2
Debugging ............................................................................................................ 77
8.5.3
Enterprise Portal.................................................................................................. 79
8.6 Posting scenarios ................................................................................................................ 81 8.7 Demo return file ................................................................................................................. 81 8.8 Basic workflow setup example ........................................................................................... 82 8.9 Standard AX workflow configuration ................................................................................. 90 8.9.1
Execution account ............................................................................................... 90
8.9.2
Number sequences .............................................................................................. 91
8.9.3
Batch jobs ............................................................................................................ 92
|Introduction
4
1 INTRODUCTION In order 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 in order 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 FACILITIES 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 is able to quickly identify and post bank transactions, which is unknown in Dynamics AX.
|Facilities
6
3 PREREQUISITES In order to be able to complete the setup and actions described in this manual, there are a number of 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 SETUP 4.1 PARAMETERS The module’s basic parameters are set up from AMC Banking > Setup > Parameters.
4.1.1 PAYMENTS The payments tab contains setup specifically related to the process of executing payment
The fields on the payments tab have the following features: Field Payment accumulation
Grace period Use standard payment methods
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 Number of days to add to cash discount date, and thereby number of days to allow cash disc even though overdue If enabled, the module will pair individual invoices with certain own bank accounts if both have identical payment methods.
|Setup
8
Auto send
If enabled, payment advices are automatically emailed to payees during transfer. If not enabled, users have to 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 POSTING The posting tab contains setup specifically related to the process of posting payments
The fields on the posting tab have the following features: Field Name of journal Split payment notifications
Auto match Medium match
Description The journal template to use for automatic created posting journals. E.g. journals created as a result 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
|Setup
9
Grace period
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 WEB 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
Username Custom login Password Date verified
Description The options are: Plus Enterprise The URL of the web service which handles the conversion of payments and bank files 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) 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
|Setup
11
4.1.4 LOG 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
4.2 BANKS The general bank setup is set up from AMC Banking > Setup > Banks > Banks When entering the setup form for the first time, the bank list is empty, meaning that no banks have been made available. 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
13
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
Manual account
Postable
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. 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 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
14
4.2.1 ADVANCED 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
Name File paths File to bank Path from bank Archive Bank agreement Bank agreement 1 Bank agreement 2 Alternative sender Alternative sender
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. 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
15
4.2.2 BANK HOLIDAYS Bank holidays are set up from AMC Banking > Setup >Banks > Bank holidays Depending on the country of the bank and sometimes even the payment format, a given bank has certain dates where payments cannot be executed (cleared). The bank holiday setup is used to set up these none-payment dates, and is used to ensure that payments are created on dates where they can actually 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
16
4.2.3 PRICES The price setup can be opened either by clicking the Prices button, which will open only prices related to the selected bank, or from AMC Banking > Setup > Banks > Prices The price setup is used to configure the costs related to executing payments of a certain payment type.
When requesting a list of available banks and related payment types (see 4.2), the web service will also return an estimated price for executing each payment type. If the prices are inaccurate, e.g. if your company have negotiated favorable prices, both the price and the related currency can be easily corrected in this form.
4.3 OWN BANK ACCOUNTS The setup related to your company’s own bank accounts is opened from AMC Banking > Common > Own bank accounts.
|Setup
17
Like most list pages, the menu contains a number of 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: Field Bank Bank Bank account Currency SWIFT code General Company
Description 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 The company or legal entity in AX to which the bank account belongs
|Setup
18
More currencies Priority
Offset account type
Offset account Customer payment method
Vendor payment method
Bridging posting
Auto match class
Reconciliation Reconcile principle
Start date
Bank balance Ledger balance
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. 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
19
4.3.1 COMPANY SETUP The company setup tab is used to set up, how the individual AX companies and/or legal entities are allowed to 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. 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 are allowed to use the bank account The company in which to add the posting journals created as a result 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
20
4.4 CUSTOMERS AND VENDORS Setting up payee bank information is done from either AMC Banking > Common > Customers or AMC Banking > Common > Vendors, which opens list pages providing a quick payee overview. Note: The customer and vendor setup forms are almost identical in relation to both design and functionality. Having two setup forms, primarily serves to keep customers and vendors separate. The following section will therefore in certain cases only cover the vendor setup form, which is the most commonly used in relation to payments
Unlike earlier versions of Banking, the current version utilizes standard AX’s customer/vendor bank accounts, which helps reduce redundancy. As a result, 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 actually required.
The status field in the grid have the following features: Field Status
Description 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
|Setup
21
Clicking the Edit button will open a detailed vendor setup form
The fields in the form have the following features: Field General Account type Account number Name Disabled Discount Grace period Payment accumulation Override Payment accumulation
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 The number of days to allow overdue cash discount 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 4.1.1 for more information
|Setup
22
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 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 BANK ACCOUNTS Customer and vendor bank accounts can be maintained either directly on the detailed customer/vendor setup form or by clicking the Payment > Bank accounts button in the list page menu.
|Setup
23
The fields in the form have the following features: Field Identification Bank Name Bank account Routing number type Routing number Bank account number SWIFT code Currency
Payment type Payment type
Description 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. Used to tie up the bank account to a specific payment type. As a result, the specified payment type will be used on all future payments to the bank account Note: If a payment type is not specified, the payment creation functionality will attempt to find the most appropriate payment type based on the individual open invoices (see section 0)
Address Bank address Country ISO Alternative address Correspondent bank address Bank rules Additional fields
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 Fields in this section are used to define specific values of the payment if needed. Contact AMC-Consult in any doubt.
|Setup
24
4.5 JOURNALS 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 ca be configured with a number of financial dimensions, which will automatically be added to created journals
|Setup
25
4.6 PAYMENT ADVICE Electronic advices for payment files are set up from AMC Banking > Setup > Payment advices. When executing payments, it is important to create a satisfactory message to the recipient. AMCBanking contains several options for creating electronic advices, and it is possible to design an unlimited number of templates for advices sent to the recipients.
4.6.1 ADVICE TYPES It is possible to create three types of advices: -
Compressed: Comma separated invoice numbers Dynamic: Custom configurable advice with a limited number of fixed placeholders Class: Fully customizable advice class
It is not a requirement to set up advices. If no advice setup is found, an advice suitable for the payment file will automatically be created by the web service based on the individual open invoices
4.6.1.1 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
26
4.6.1.2 DYNAMIC Unlike the compressed advice, the dynamic advice is highly customizable and has a number of 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
27
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 a number of 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
28
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 PREVIEW 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
29
4.7 PAYMENT TYPE PRIORITIES When adding payments, users are presented with a number of 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
30
4.8 SEARCH STRINGS As a feature, it is possible to add rules that tie certain text and/or codes on bank payments to a given 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 simple list containing various combinations of search strings, transaction codes and their related account type and account number. It is also possible to open the search string setup from either the customer or the ve ndor 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 to a given account. 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 bank provided transaction codes to a given account. Most banks “tag” the bank account transaction with transactions codes (also known as business transaction codes), which helps determine the nature of the individual 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, |Setup
31
allowing the auto match to quickly identify and prepare the transaction, which can then be posted with minimal user involvement.
4.8.1 CLEANUP Each search string record has two related date fields, specifying when the individual search string was created and last used. The two date fields are useful when cleaning up search strings, as it provides a quick overview of, which search string rules are being used regularly. To help keep the search string list neat and tidy, the search string setup includes cleanup functionality, which is activated by clicking 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
32
4.9 TRANSACTION 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
33
4.10 WORKFLOWS To ensure that payments are only executed if the related customer/vendor bank accounts have been approved, the Banking module includes a workflow, 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 8.8) |Setup
34
4.10.1 WORKFLOW 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
35
4.10.2 WORKFLOW 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
36
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, is allowed to “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
37
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
38
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
39
4.10.3 USER RIGHTS All users, assigned the “AMC Banking user” security role, can submit bank account approval requests, but only users assigned the “AmcBankController” 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
40
5 PAYMENTS This section covers the creation, approval and execution of payments.
5.1 PREREQUISITES Customer and vendor transactions are created and posted from several locations, e.g. via the invoice register journal, the invoice journal or the ledger journal. In order to be picked up and processed by the Banking module, they are however all subject to a number of common requirements: Has to be approved Is not settled elsewhere Is in the selection range, defined in the payment add dialog
5.2 PAYMENT JOURNAL The payment journal is used to create and process payments based on open customer and/or vendor transactions and can be opened from AMC Banking > Journals > Payment journal.
From the payment journal menu, the user is offered a number of 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
41
The payment journal form contains the following fields: Section Company Bank Journal
Meaning 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.
Description Lines Errors Posted
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 CREATION Thought the module allows the processing of payments to customers, the most common scenario is that payments are created and processed from open vendor transaction. Processing of customer and vendor payments are two identical processes, so despite the following section primarily focusing on vendor payment scenarios, the section should also be 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
42
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 a number of 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
43
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
44
To finish the payment proposal process and create the payments, select the desired payment proposal and click the “Create” button. This will result in one or more payment journals (one journal per execution bank) being created. Payments can also be added from inside the individual payment journals, which has similar menu buttons for initiating payment adding. When adding payments from inside a journal, the user will only be presented with a single payment proposal, which represents the existing execution bank specified on the journal.
5.2.2 PREPARATION To open a detailed payment journal view, select the payment journal in the overview and click the “Lines” button. The initial status of payments in a newly created journal is “Editable”, which indicates that the payments can edited or deleted. E.g., it is possible to change bank account information, add/remove settlements to payments lines and delete lines, which should not be included in the payment batch. Furthermore, it is possible to add manual payments, simply by clicking the “New” button (CTRL+N) and filling in the required payment information.
Note: Payment amount can only be altered directly on manual payment, i.e. payment without settlements. If a payment has settlements, the total payment amount can be changed by editing the settle amount on the individual settlement lines in the settlement grid
The settlement grid allows the user to alter the settlements quickly, without leaving the payment journal. E.g., it is possible to quickly add or remove settlements with 1-2 mouse clicks. Furthermore, it is possible to edit the settlements directly from the settlement grid, allowing the user to specify |Payments
45
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
46
5.2.3 VALIDATION From leaving the AX environment to being executed by the intended execution bank, processing of payments can be done in several ways. Depending on, whether the payment journal requires approval or not (determined by the execution bank), the user has the option to either “Validate” or “Transfer” the journal using the respective buttons from the menu. In both cases, the first part of the payment process is to validate the payment information of the payment journal being processed. This validation ensures that payment information is adequate and will be accepted by the execution bank upon being received and processed in the external systems of the bank. Payment lines, which does not meet the bank requirements, will be marked as “Erroneous” 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 n ature 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 inf ormation 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 locking the journal to ensure the user cannot edit the validated payment information.
|Payments
47
Note: A non-editable payment journal can be cancelled by clicking the “Cancel” button from the menu. Cancelling the journal, will return it to editable state. If the journal has already been transferred, the “Cancel” button is only available to users, who have been assigned to the AmcBankController security role.
5.2.4 APPROVAL AND TRANSFER If the payment journal does not require approval, a bank file is returned and saved locally. In addition, the payment transactions change to status “Transferred”. The user is now responsible for the physical file transfer to the bank, e.g. by uploading the created payment file in the bank’s online web system. If the payment journal does indeed require approval, the payment transactions instead change to status “Approvable”, which allows the approval users to access the “Approval” button menu. Here they have the possibility to either “Approve” or “Reject“ the complete payment journal. Clicking the “Approve” button will open a small journal approve dialog in which the approver can specify username and password.
Rejecting the journal will return the journal into editable mode Once the required approvals have been applied, the journal is transferred automatically. If a 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 POSTING 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 4.2) The options are: |Payments
48
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 bank. This will leave only successful payments in the original payment journal, which will turn it into a postable state. |Payments
49
5.3 EMAIL ADVICE If the electronic advice included in the payment file is inadequate, it is possible to print and send an additional email advice. Email advice is activated from the customer or vendor form by specifying, an email address and an email template.
Using email advice has the great advantage, that there is no limit to the number of invoices, which can be included in a single advice. The advice functionality uses standard AX email functionality, making it possible to create language specific email templates, which resemble the language of the receiving vendor. 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.
|Payments
50
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. 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.
|Payments
51
6 PAYMENT NOTIFICATIONS Payment notifications reflect the credit and debit transactions, which have been physically posted on the bank accounts in the bank. This section covers the processing of payment notification, from the initial import to the final posting inside AX. The overall goal when importing and processing payment notification, is to match, settle and post physical bank transactions with payments and/or open transactions in the AX environment. In earlier versions, payment notifications where restricted to banks, which were able to provide designated payment notification files. The new version offers this facility to all customers, who are able to 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 IMPORT Payment notifications are imported from AMC Banking > Common > Import bank return files (see 8.2) Imported payment notifications are matched against the 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 the payment notification in, resulting in a posting journal being created in the respective company.
6.2 POSTING JOURNAL The posting journal is used to match and settle bank transactions against either payment journal payments or open customer/vendor transaction, and is opened from AMC Banking > Journals > Posting journal.
|Payment notifications
52
The posting journal overview have the following fields: Section In use Company Name of journal Description Journal type Lines Ready Created date and time
Meaning Specifies whether the journal is in use by either the system or a user The company, in which the journal belongs Name of the journal configured in Setup > Journals > Journals A brief description of the journal and its content 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. The number of processed lines, which are ready for posting The journal’s creation date and time
To open a journal, select a journal and click the button “Lines”.
|Payment notifications
53
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 AUTO 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
54
Low (Red)
User (Blue) None (White)
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.
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 MANUAL SETTLEMENT If the auto match is not able to identify a bank transaction’s related customer/vendor and invoice(s), it is possible to carry out a manual settlement. It is also possible to post a payment without settling it, e.g. if it is a prepayment. In that case, the user can change the payment’s status field value to “Ready”.
To initialize manual settlements, click one of the two buttons in the settlement grid’s tool bar.
Clicking the “Settlement” button will open an external settlement form, which allows the user to settle the bank transaction against open invoices in AX.
|Payment notifications
55
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. As a result, 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
56
Once the user has marked the invoices or payments to settle and made sure that the total settlement amount matches the payment amount (within max difference), clicking OK will carry out the settlements. As a new feature, the module allows automatic handling of payments exceeding the open invoices available. This situation e.g. occurs if a customer mistakenly pays invoices twice, thereby exceeding the expected payment amount (see example below). Customer receives invoice A + B
Invoice A
Invoice B
Customer pays invoice A + B
Invoice A
Invoice B
Customer receives invoice C
Invoice A
Invoice B
Invoice C
Customer mistakenly pays both invoice B + C
Invoice A
Invoice B
Invoice C
Payment exceeding expected amount
Invoice A
Invoice B
Invoice C
When attempting to carry out a settlement, where the payment amount exceeds the settlement amount, the user will be asked to confirm the amount difference, which will result in the original payment being split into three different transactions. 1) A ledger/bank transaction reflecting the original posted bank transactions 2) A settled customer transaction reflecting the part of the payment, which could be settled against open invoices 3) A not-settled customer transaction reflecting the remainder of the payment, which could not be settled
6.2.3 CASH DISCOUNT If a customer has been granted cash discount, the auto match routine and settlement functionality expect the customer to utilize the cash disc, by deducting the cash disc from the invoice amount. This is of course only true, if the payment date does not exceed the cash disc date. If the customer does not utilize the cash disc, or if the customer utilizes the cash disc, but the cash disc date has been exceeded, the auto match will consider this an amount difference. As a result, an obtained match will be degraded to a low level match. |Payment notifications
57
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 a number of 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 OTHER FUNCTIONS The posting journal has a number of functions, which can be used to ease the process, getting from import to posting. The functions are available from the “Functions” menu
|Payment notifications
58
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 a large number of 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 a large number of transactions’ dates
6.2.5 POSTING To post a posting journal, all transactions are required to have status “Ready”. This status is automatically set when settling the transactions (automatically or manually), but can also be set by the user, if the transaction is not to be settled. The post method utilizes standard AX’s own posting functionality, meaning that the posting functionality also includes a validation. This ensures that all transactions meet the posting requirements configured throughout AX.
|Payment notifications
59
7 ACCOUNT STATEMENTS Account statements reflect the movements on the bank account, but how the account statement is processed and utilized, often depends on the individual customer and the country in which the customer resides. In some countries, the account statement is the basis for the posting the credit and debit movements in the ERP system, while account statements are used for account reconciliation in others. This chapter will primarily focus on the process of account reconciliation, but it is also possible to use account statements as a posting foundation. In that case, the account statement will also enter the system as payment notifications (see 6). The overall goal of the bank account reconciliation is to ensure that the posted ledger transactions in AX reflect the physical movements on the bank account, thereby also ensuring that balances in AX corresponds with the balances on the bank accounts.
7.1 IMPORT 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 RECONCILIATION To start reconciling the bank account(s), open the list of own bank account from AMC Banking > Common > Own bank accounts.
|Account statements
60
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
61
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
62
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 AUTOMATIC RECONCILIATION To start an automatic account reconciliation run, click the “Auto reconcile” button. This will open a small dialog allowing the user to enter a few criteria, which decides the behavior of the automatic reconciliation.
|Account statements
63
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 are allowed to 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
64
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 MANUAL RECONCILIATION The user can reconcile bank transactions, which could not be reconciled automatically, manually. This is done by marking the bank and ledger transactions to reconcile and clicking the “Reconcile” button from the menu. Like the automatic reconciliation, the reconciled bank transactions and ledger transactions will automatically disappear from the “Unreconciled” view. To see the reconciled transactions, switch to the “Reconciled” view. It is tempting to mark several bank and ledger transactions simultaneously to finish the reconciliation in the fewest steps possible. However, we do not recommend this approach, as it quickly leads to a loss of overview and confusing reconciliations. Furthermore, unreconciling a reconciled transaction would result in the need to unreconcile all other related transactions as well.
7.2.3 LEDGER PROPOSAL When reconciling transactions manually, situations where the bank and ledger amount does not match, is likely to occur. |Account statements
65
The ledger proposal is used to handle such situation. It is possible to add amount difference to the ledger proposal, but actually, 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
66
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 RECONCILIATION REPORT To document the account reconciliation, it is possible to print out a reconciliation report by clicking the “Reconcile report” button from the own bank account list page form.
This will result in a small dialog, in which the user is able to specify a date interval and a so-called “Viewpoint” allowing, seeing the either reconciliation from “Current” or “Historical” view.
|Account statements
67
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
68
8 APPENDIX 8.1 INTELLIGENT PAYMENT PROPOSAL
|Appendix
69
8.2 AGGRESSIVE CREDIT NOTE ACCUMULATION Aggressive credit note accumulation offers the possibility to deduct future credit notes from similar payments despite the credit notes being due later than the payments. This section describes step-by-step, how a list of open invoices is handled and accumulated using the aggressive credit note accumulation method. Open invoices Due date 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
70
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
15.01.2015 -500
31.01.2015 800
31.01.2015 -2.000
Payment outside date range
Credit note outside date range
Removing payments outside date range (...but keeping credit notes) 01.01.2015 -500
08.01.2015 2.000
10.01.2015 1.500
10.01.2015 -1.200
12.01.2015 400
Credit note outside date range
Credit note accumulation: 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 -2.000 No payment large enough
Result: 08.01.2015 300
10.01.2015 1.000
01.01.2015 -500
10.01.2015 1.500
08.01.2015 2.000
15.01.2015 -500
12.01.2015 400
31.01.2015 -2.000
10.01.2015 -1.200
|Appendix
71
8.3 DETERMINING PAYMENT DATE, AMOUNT AND CASH DISCOUNT Add transactions to journal
Payment add
Use total date
No
Use cash disc
Yes
No
Payment date = Total date
Payment date = Due date
Yes
Cash disc date + grace days < System date
Yes
No
Payment date < Forward date
Payment date = System date
Yes
No
Cash disc date + grace days < Forward date
No
Yes Payment date = Cash disc date
Payment date < System date
No
Yes
Payment date = Forward date
Use cash disc
Yes
Payment amount = Transaction amount - cash disc amount
Payment amount = Transaction amount
Payment added
No
8.4 IMPORT BANK RETURN FILES If the bank is able to 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
72
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
73
-
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
74
8.4.1 IMPORT 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 CHARTS From the overview of own bank accounts, it is possible to get a graphical view of data related to the individual bank accounts. Currently the module includes three charts, which can all be opened from the menu
|Appendix
75
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
76
8.5.1.3 P OST The post chart provides an overview of the daily movements on the bank account
8.5.2 DEBUGGING If the chart form 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
77
The chart forms all utilize ActiveX controls, which displays the individual charts. If the chart forms appear 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 ActiveX controls. 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 from to the list of Trusted sites
|Appendix
78
8.5.3 ENTERPRISE PORTAL 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
79
4) Use the “Dynamics User Control WebPart” on the right side, to configure the webpart. 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 in order 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
80
8.6 POSTING 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
Posting CUR
DKK DKK DKK DKK
DKK USD EUR EUR
Exchange rate From file 100, no DKK/USD rate DKK/EUR rate DKK/EUR rate
8.7 DEMO RETURN FILE As a new feature, it is possible to create a demo account statement, based on the open invoices in the AX environment. The feature is initialized from Setup > System > Demo return file. 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. As a result, 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 a number of demo transactions, allowing users to test various reconciliation and auto match scenarios. To keep the demo simple, both bank accounts as well as open invoices are restricted to the company’s currency only.
When finished looping through the open invoices, the demo file is created and an infolog is returned, informing which of the various demo scenarios that were successfully created
|Appendix
81
8.8 BASIC 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
82
|Appendix
83
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
84
|Appendix
85
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
86
|Appendix
87
|Appendix
88
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
89
8.9 STANDARD AX WORKFLOW CONFIGURATION In order to use the workflows included in the Banking module (as well as standard AX workflows) a Microsoft Dynamics AX administrator has to configure the workflow system.
8.9.1 EXECUTION 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. In order to specify the workflow execution account, follow the steps below:
|Appendix
90
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 NUMBER 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, according to the following website: 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
91
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 BATCH 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. In order 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
92
In order 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
93
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
94
![arxiv: v4 [hep-ex] 12 Jul 2012](https://kipdf.com/img/300x300/arxiv-v4-hep-ex-12-jul-2012_5b346e9f097c477d678b4863.jpg)
![v4 [math.gt] 12 Jan 2007](https://kipdf.com/img/300x300/v4-mathgt-12-jan-2007_5ac600bb1723ddc51da189f6.jpg)
![arxiv: v4 [hep-ex] 12 Sep 2015](https://kipdf.com/img/300x300/arxiv-v4-hep-ex-12-sep-2015_5b163cdf7f8b9a963b8b45be.jpg)
![arxiv: v4 [cs.lg] 12 Jan 2017](https://kipdf.com/img/300x300/arxiv-v4-cslg-12-jan-2017_5ab5465d1723dd339c810faa.jpg)