USER GUIDE AMC BANKING DYNAMICS 365 FOR OPERATIONS. AMC Consult A/S July 3, 2018 Banking 7

Transcription

1 USER GUIDE AMC BANKING DYNAMICS 365 FOR OPERATIONS AMC Consult A/S July 3, 2018 Banking 7

2 CONTENTS Introduction...4 Facilities...5 Prerequisites...6 Workspace About...9 Setup Parameters Payments Posting Web service Banks Setting Bank holidays Prices Own bank accounts Company setup Customers and vendors Bank accounts Journals Advice Payment type priorities Search strings Cleanup Transaction texts Workflows Security roles Payments Prerequisites Payment journal Introduction 2

3 6.2.1 Creation Preparation Validation Approval and transfer Posting advice Additional functions Payment notifications Import Posting journal Auto match Manual settlement Cash discount Additional functions Posting Account statements Import Reconciliation Automatic reconciliation Manual reconciliation Ledger proposal Reports Reconciliation report Forecast report Appendix Charts Posting scenarios Demo return file Aggressive credit note accumulation Introduction 3

4 INTRODUCTION To benefit as much as possible from your AMC-Banking module, you should read this user guide, describing in detail, the various possibilities and functionalities offered by the module. The user guide covers the basic setup of the module; meaning the setup that only needs to be done once. Furthermore, it contains a detailed description of the module s functionalities for you to familiarize yourself with the daily use of the module. Best regards Development team AMC-Consult A/S Introduction 4

5 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: If your bank does not figure on the list of supported banks, please do not hesitate to contact either your reseller or us, to find out the possibilities for adding your bank to the list. Import and posting of payment notifications AMC Banking includes facilities for importing and handling payment notification files, which contains the physical credit and/or debit payments, which have been executed and posted on your bank account(s). Whether the payment notifications contain structured or unstructured payment information, the module includes advanced functionality for identifying and settling the individual payments, allowing the user to quickly handle and post the payment notifications. Import and reconciliation of bank account statement AMC Banking includes facilities for automatic account reconciliation based on electronic bank account statements from the bank. The reconciliation process matches the individual bank transaction against corresponding ledger transactions. Furthermore, the account reconciliation functionality can quickly identify and post bank transactions, which is unknown in Dynamics AX. Facilities 5

6 PREREQUISITES To be able to complete the setup and actions described in this manual, there are a few prerequisites The Banking module should be installed A valid Banking license should exist and the necessary license setup should have been completed Prerequisites 6

7 WORKSPACE Like many of the other modules in AX, the Banking module includes a designated workspace, which can easily be accessed from the central AX dashboard. Clicking the AMC Banking tile, forwards the user to the Banking workspace page, which offers easy access to important data and the core functionalities that revolves around Banking related processes. Workspace 7

8 The workspace is divided into four sections 1) Summary The summary section allows the user to initiate the daily tasks, increasing the productivity related to actions like initiating payments and importing bank return files 2) Journals and transactions Tab section offering an overview of the tasks currently in in process, allowing the user to quickly initiate actions, when required 3) Statistics Section offering small, graphical BI charts, offering a quick overview of the overall usage of Banking. Clicking the match level chart will open statistics in numbers, telling how efficient the auto match is being used and an estimate on saved time. 4) Links The Links section, contains links to the most common used pages in the Banking module. E.g. it offers quick access to the bank list, the customers own bank accounts as well as the payee setup pages. Workspace 8

9 4.1 ABOUT Clicking the About button in the top left corner, allows the user to see the exact version of the Banking module installed in the current Dynamics 365 environment Workspace 9

10 SETUP 5.1 PARAMETERS The module s basic parameters are set up from AMC Banking > Setup > Parameters 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 Grace period Centralized payment method Party accumulation Description Number of days to add to cash discount date, and thereby number of days to allow cash disc even though overdue The options are: - Intercompany: Cross-company transactions are handled using standard AX intercompany functionality, where transactions are posted both centrally and in original company, using configured intercompany accounts. - Partitioned: Cross-company transactions are handled centrally, but are posted in their respective companies. Note, that using this option will typically result in the creation of multiple posting journals, to keep transactions from different companies separate. Enable, if payment proposal should attempt to accumulate invoices associated to same party in global address book, when adding payments Use standard payment methods Auto send Note: This option is only available, when using the Intercompany centralized payment option, as it would directly conflict with the Partitioned way of doing centralized payments If enabled, the module will pair individual invoices with certain own bank accounts if both have identical payment methods. If enabled, payment advices are automatically ed to payees during transfer. If not enabled, users must send the payment advices manually from the journal. Note: The is (only) send when the payment has been transferred successfully. Note: s are send using standard AX functionality. That also means that the standard AX setup is used to configure the SMTP relay server Setup 10

11 Attachments File directory, in which to store attachment files when ing payment advices. The file directory should be accessible from the server, as it is the server, that creates the advice attachment files 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 Split payments Name of (customer) journal Name of vendor journal Auto match Medium match Grace period Description 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 The journal template to use for automatic created posting journals. If splitting of payment notifications is enabled, this template is only applied to customer posting journals The journal template to use for automatic created vendor posting journals This mark specifies to automatically match payments that are created during import of bank files This mark specifies if the auto match functionality should be allowed to settle medium matched open invoices, which as opposed to high matches are less evident Number of days to add to cash discount date, and thereby number of days to allow cash disc even though overdue WEB SERVICE The web service tab contains setup specifically related to the process of communicating with the AMC-Banking web service Setup 11

12 The fields on the web service tab have the following features: Field Solution URL Description The options are: - Plus - Enterprise The URL of the web service which handles the conversion of payments and bank files. Next to the field, is an SSL certificate status indicator, which is continuously updated to reflect the certificate status of the last web service connection. - Locked: Certificate is trusted and channel is secure - Unlocked: Certificate is valid, but is not regarded as trusted, as it is not authorized by a certificate authority (CA), typically because certificate is selfsigned - Exclamation mark: Certificate is invalid and channel is insecure. The Banking module will block communication with untrusted web services Login Password Date verified Log detail level 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 specified when registering your AMC-Banking license The password used when communicating with the license server and the web service specified in the URL field. Password is specified when registering your AMC-Banking license The date the license was last verified Note: The license is automatically verified every 14 days 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) Setup 12

13 5.2 BANKS The general bank setup is set up from AMC Banking > Setup > Banks > Banks When entering the bank setup page for the first time, the list of banks is empty. To add banks to the list, click Select banks To update the list of available banks, click Update banks. This will contact the bank data conversion service, and fetch an up-to-date list of banks made available by the service. To add banks, use the arrows to move banks from the Available (top) to the Selected (bottom) grid. Once the preferred banks have been added, click Close to return to the bank setup page. Setup 13

14 To the right, a preview pane displays the payment types available to the individual banks and possibly a brief description if further clarification on the payment type is needed. The fields on the fast tabs have the following features: Field Bank Bank Name License bank License bank Approval Login Execute country Payments Calendar Domestic payment currency Accumulate reference payments Own reference Description Identification of bank Editable bank name/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 Display field, indicating, whether bank requires approval when executing payments Display field, indicating, whether bank requires signing in, when importing bank return files Display field, indicating, the bank country code and thereby the country wherefrom payments are executed 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. Used to restrict domestic payments to a certain currency. If a currency code has been specified, invoices in other currencies will be regarded as international transfers, when executed using the bank. Used to specify, whether the bank allows accumulation of reference payments. If not checked, reference payments executed from this bank will not be accumulated, resulting in one reference payment per invoice. Specify what to use for own reference, which is usually also shown on bank account and related bank account statements SETTING Clicking Setting to open a page where additional bank setup can be configured. Setup 14

15 The fields on the fast tabs have the following features: Field Company Company Name Payments File to bank Import Disable 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 Used to disable and thereby skip the import of files, using these settings 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 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 be executed. Setup 15

16 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 5.2). The fields on the fast tabs have the following features: Field Calendar Description Allow payments on weekends 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 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. Setup 16

17 When requesting a list of available banks and related payment types (see 5.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 page. 5.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

18 Like most list pages, the menu contains several buttons covering the general maintenance of the bank accounts. Furthermore, the menu contains buttons for account reconciliation (see section 8) and for balance chart, cost chart and post chart (see section 9.1) Clicking either New > Bank Account or Maintain > Edit, will open a separate, detailed bank account setup page. The fields on the fast tabs have the following features: Field Bank Bank Bank account Is IBAN Currency SWIFT code General Account type Offset account Company Restrict to 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 Display field, indicating, whether bank account number is an IBAN account The currency of the bank account The SWIFT code identifying the bank and possibly branch 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 The company or legal entity in AX to which the bank account belongs Restrict the bank account to the company where it resides (specified in the Company field), and thereby prevent the bank account from being used in other companies. This field is not to be confused with the general company setup s Payment field, which specified which companies invoices can be paid. Setup 18

19 Priority More currencies Bank groups Fee collection This option is typically used by holding companies with subsidiary companies, as it allows the holding company to create payments based on the subsidiary invoices, while restricting the bank account from being used by the subsidiary companies. 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. Specifies whether to allow other currencies than the bank account s own currency Used to group bank accounts together. The bank groups are used by the balance form parts, which calculates and displays the total balance of both individual bank accounts as well as bank account groups Specify whether fees are being collected on bank account and thereby whether to ignore transaction related (sub)fees or not. Customer payment method Vendor payment method Bridging posting Auto match class Reconciliation Start date Bank balance Ledger balance Note: Individual fee transactions will still be imported 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 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 page 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 COMPANY SETUP The company setup tab is used to set up, how the individual AX companies and/or legal entities can utilize the bank account. Setup 19

20 The default is that the company, in which the bank account resides, is allowed full access to the bank account, while all other companies are restricted from using the bank account at all. If a bank account is shared across AX companies or legal entities, companies can be added to the company list. Note: To permit users from seeing bank accounts, which are not relevant to them, bank accou nts are only visible in companies, that are included in the company setup. Furthermore, the company setup is only available in the bank account s own company. This ensures that bank account visibility and company setup, can only be changed by users with the required access to the company of the bank account. The fields in the grid have the following features: Field Company Payments Posting Auto match Description Identification of the company in AX Specifies whether payment journals in the related company can use the bank account The company in which to add the posting journals created because of importing bank files, e.g. customer- and vendor payments Note: Only one company can be the posting company Specifies in which companies to look for open invoices when the auto match functionality is executed 5.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 pages are almost identical in relation to both design and functionality. Having two setup pages, primarily serves to keep customers and vendors separate. The following section will therefore in certain cases only cover the vendor setup page, which is the most commonly used in relation to payments Unlike earlier versions of Banking, the current version utilizes standard AX s customer/vendor bank accounts, which helps reduce redundancy. Thus, all customers and vendors with related bank accounts are considered payable, usually without the need for additional setup. Therefore, the customer and vendor setup pages are only used, in cases where customers or vendors are to be excluded from the payment process or in those cases where additional information is required. Setup 20

21 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: - [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 - [Stop sign]: The vendor has been disabled, hence the vendor s open transactions are excluded from the payment process Clicking the Edit button will open a detailed vendor setup page Setup 21

22 The fields in the page have the following features: Field General Account type Account number Name Disabled Discount Grace period Payment accumulation Override Payment accumulation Advice Enable (File advice) Advice 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 for more information 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 Setup 22

23 Enable (Mail advice) ID Report design name File format Note: If nothing is specified, an automatic advice is created Used to activate advice for the payee address to use when sending payment advices to vendor AX template to use when sending payment advices to vendor The report design to use when sending payment advices to vendor. The module includes only one design, but this field can be used, if additional designs are created on the customer-side The SSRS file format to send the advice in BANK ACCOUNTS Customer and vendor bank accounts can be maintained either directly on the detailed customer/vendor setup page or by clicking the Payment > Bank accounts button in the list page menu. The fields in the page have the following features: Field Identification Bank account Name Bank account Bank account number Is IBAN Primary Bank account details Routing number type Routing number Description Bank account identification Name of the bank account The account number that is assigned by the bank Display field, indicating, whether bank account number is an IBAN account Display field, indicating, whether the bank account is the primary payee bank account Code identifying the type of the routing number Routing number of the bank Setup 23

24 SWIFT code Currency Payment Payment type 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. Thus, the specified payment type will be used on all future payments to the bank account Costs Correspondent bank account Address Bank address Alternative address Status Active from 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) Used to specify how to allocate payment related costs. The options are: - Shared: Charges are split between sender and receiver of the payment. Usually payer will be charged a fee for creating the payment order, whilst the receiver will be charged for costs related to intermediary banks and sometimes also a fee for receiving of the money. - Payer: All fees are charged to the sender of the payment - Payee: All fees are charged to the receiver of the payment Used to specify a bank account to use as correspondent bank account. This is a reference to another of the payee s bank accounts and correspondent bank account cannot be the same bank account, as the current selected bank account The address of the bank related to the bank account Used to specify an alternative vendor address. If nothing is specified, vendors primary address is used Date wherefrom the bank account is active Active to Note: This field is only available/shown on vendor bank accounts Date whereto the bank account is active and thereby is disabled Status Note: This field is only available/shown on vendor bank accounts Display field, quickly indication, whether bank account is active based on active from and active to fields Workflow status Note: This field is only available/shown on vendor bank accounts Bank account approval workflow status. If workflow has not been enabled, status is always Active Setup 24

25 5.5 JOURNALS The general behavior of the posting journal is set up from AMC Banking > Setup > Journals > Journals. Field Voucher New voucher Voucher series 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 The journal can be configured with financial dimensions, which will automatically be added to created journals Setup 25

26 5.6 ADVICE Electronic advices for payment files are set up from AMC Banking > Setup > Advice. When executing payments, it is important to create a satisfactory message to the recipient. AMC- Banking contains several options for creating electronic advices, and it is possible to design an unlimited number of templates for advices sent to the recipients. 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 COMPRESSED A compressed advice is a list of invoice numbers separated by commas, and it is typically used to conserve space in formats with very limited space for advice. The only configurable part is a header, which is used to prefix the invoice list. This setup will create an advice like this: Invoices: , , Setup 26

27 DYNAMIC Unlike the compressed advice, the dynamic advice is highly customizable and has several properties, which can be tweaked to suit your specific needs. The dynamic advice is typically used, where advice possibilities are rich, and only the most common invoice data, like invoice no., date, amount etc., is to be included The dynamic advice consists of three different text sections, each separated by new line: Header: A one-time occurring header being output at the start of the advice. The text can contain several lines of text, but should not exceed the maximum length of the payment file s advice. Most payment file formats allow 35 characters of text per line. 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 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 Setup 27

28 %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 CLASS The class option offers building advices using a fully customizable class, and is typically used in cases, where the invoice data covered by the placeholders, just do not cut it. E.g., the class could be used to fetch related data from the any AX module. The only configurable part is the Class name field, which is used to specify the name of the advice class to use. A class is only considered a valid advice class, if the class extends AmcBankAdviceClass, which forces the advice class to implement certain functionality. 5.7 PAYMENT TYPE PRIORITIES When adding payments, users are presented with payment proposals, representing different payment scenarios. Should the users find the default provided payment proposals inadequate, they Setup 28

29 can instead setup their own prioritized list of payment types from AMC Banking > Setup > Payment type priorities. On the left side, the priority page contains an overview of existing payment type priority lists. On the right side, the page 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 priority lists exist, they will be included as individual payment proposals when adding payment, provided they are not specified as User only or created by the current users. 5.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 action or account in AX. The search string setup is very useful and allows the user to adjust the default provided auto match functionality easily. The search string setup is opened from AMC Banking > Setup > Search strings. Setup 29

30 The setup form contains a list containing various combinations of search strings, transaction codes and their related action and/or account. It is also possible to open the search string setup from either the customer or the vendor form. In that case, the list only includes search strings related to the selected customer or vendor. The Search string field is used to match a user-defined text. This is e.g. useful in situations where a registered customer name in the AX does not correspond with the name provided by the customer itself or the bank, when a payment from the customer is received. In such cases, the user can easily add the provided customer name, which will allow the auto match functionality to determine the customer based on the provided search string. The Transaction code field is used to match transaction codes originating from the bank. Most banks tag the individual bank transaction with transactions codes (also known as business transaction codes), which helps determine the nature of the transactions. This is particularly useful, when receiving recurring, known, yet unexpected financial transactions like fees, interests etc. In such cases a transaction code can easily be tied to the related AX ledger account, allowing the auto match to quickly identify and prepare the transaction, which can then be posted with minimal user involvement. The search strings and transaction codes can be tied to three different actions: - Match: Used to tie a text string and/or transaction code to an account in AX. When met, the auto match functionality, will apply the set-up account to the transaction. - Delete: Used to delete transactions. When met, the auto match functionality will delete the transaction and inform the user, that a transaction was deleted. - Bridge post: Used to initiate bridge posting of the transaction. When met, the auto match functionality will apply the related bank account s bridge account to the transaction. This is particularly useful, when using Setup 30

31 account statements to post bulk payment, which have been specified in earlier files. E.g. Lockbox files (US) and FIK-indbetalinger (DK) CLEANUP Each search string record has two related date fields, specifying when the individual search string was created and last used. The two date fields are useful when cleaning up search strings, as it provides a quick overview of, which search string rules are being used regularly. To help keep the search string list neat and tidy, the search string setup includes cleanup functionality, which is activated by clicking Cleanup. 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. 5.9 TRANSACTION TEXTS The transaction text setup, which is reflected on the individual journal transactions Description field, is set up from AMC Banking > Setup > Transaction texts Setup 31

32 The transactions text setup page 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 WORKFLOWS To ensure that payments are only executed if the related customer/vendor bank accounts have been approved, the Banking module includes a workflow. For more info, please see the separate Activate bank account approval workflow document SECURITY ROLES To access the Banking module, users must be assigned with the proper security roles. For more info on Banking security role assignment, please see separate Set up security roles document Setup 32

33 PAYMENTS This section covers the creation, approval and execution of payments. 6.1 PREREQUISITES Customer and vendor transactions are created and posted from several locations, e.g. via the invoice register journal, the invoice journal or the ledger journal. To be picked up and processed by the Banking module, they are however all subject to a few common requirements: Must be approved Is not settled elsewhere Is in the selection range, defined in the payment add dialog 6.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 few options like creating new payments as well as viewing, editing and processing existing payment. To see the details of the individual payment journals, select a journal and click Lines. The payment journal page 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 Payments 33

34 6.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 a new payment journal and add payment lines, click either Add > Customer payments or Add > Vendor payments. This will open a dialog in which basic ranges can be used to filter and limit, which open transaction to include Section Pay to date Add cash discount 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 your company uses cash discounts, this field can be used to also include invoices, which is not necessarily due yet, but on which cash discount can be achieved within Pay to date. Invoices, that are cash discount eligible between the current date and the specified discount date are included in the search In addition to the fields, which have been placed directly in the dialog, the user can further limit the transactions, by adding user defines ranges, using the Filter button in the Records to include section. This is also where e.g. cross company ranges can be activated and changed Once the desired ranges have been specified, click OK to proceed to the payment proposal dialog. Payments 34

35 In the new two-part dialog, users are presented with different payment proposals. Each payment proposal includes the exact same invoices, but represents different ways of processing, the found, open vendor transaction and thereby also the final payments. In the top part, the user can see and choose between the individual generated proposals. The bottom part will show the individual payment transactions based on the selected payment proposal. The system will generate and present payment proposal using only a single execution bank, but will also create proposals that can include multiple execution banks, e.g. a payment proposal offering the cheapest way possible of executing the payments. During the generation of the individual payments proposals, the system will automatically attempt to determine bank accounts, payment types and other payment related information. The system uses various data to determine the payment information, such as country of payee bank account, invoice currency and available payment types. For an overview on how payment information is determined, see separate Determine payment instruction document. The individual payments proposals will usually differ based on the payment types available in the various executing banks, but can also be affected by user defined behavior parameters, which the user can specify in the bottom part of the dialog. Section Forced payment date Payment accumulation Meaning Used to override the automatic payment date determination and instead use a forced payment date, disregarding holiday setup etc. The options are: - Due date: Invoices and credit notes are accumulated per due date Payments 35

36 Credit note accumulation - 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 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: See section 0 When the payment behavior parameters are changed, the system must regenerate the proposals and therefore the Create button is disabled and instead the Refresh button is enabled. Clicking Refresh, will regenerate the payment proposals end re-enable the Create button. The top part of the payment proposal dialog contains two 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, To finish the payment proposal process and create the payments, select the desired payment proposal and click Create. 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 specifie d on the journal PREPARATION To open a detailed payment journal view, select the payment journal in the overview and click Lines. 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 from the Add menu. Payments 36

37 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, placed in the bottom of the page, allows the user to alter 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 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 page, in which the more advanced settlement actions, like changing cash disc, can be completed. Payments 37

38 When the settlement page is closed, the amount and advice is automatically updated, based on the settled invoices VALIDATION From leaving the AX environment to being executed by the intended execution bank, processing of payments can be done in several ways. Depending on, whether the payment journal requires approval or not (determined by the execution bank), the user has the option to either Validate or Transfer the journal using the respective buttons from the menu. In both cases, the first part of the payment process is to validate the payment information of the payment journal being processed. This validation ensures that payment information is adequate and will be accepted by the execution bank upon being received and processed in the external systems of the bank. Payment lines, which does not meet the bank requirements, will be marked as Erroneous. Furthermore, the system will add a small descriptive log, that explains the nature or the error and a hint to what needs to be corrected. This log can be seen by hovering the mouse cursor over the small error icon, that is visible in the payment grid s left-most column. Payments 38

39 Note: Most lines in the log will have a small blue question mark icon next to the text message. Clicking the questing mark redirects the user to the Banking knowledge base site, which sometimes offers additional error details. A quick log view is also available in the FactBox pane to the right If the payment journal contains many lines and validation errors are scattered throughout the journal, the display filter in the top-left corner can be used to filter transactions so only erroneous lines are visible. When the necessary corrections have been made, the user can click either the Validate or Transfer button once more to validate the now corrected journal. Once all payments are validated Payments 39

40 successfully, the journal will enter the next phase, which includes making the journal non-editable, which ensure that users cannot edit the now validated payment information. Once the journal has entered the non-editable state, it can only return to editable state by using clicking Cancel. This button is available to users that have been assigned the AMC Banking manager role 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 POSTING Once the payments have been transferred, the next step is to post the payments. To post the payment journal immediately, as opposed to waiting for a payment notification from the bank, click Create posting proposal. This will open a post dialog, where users can decide what to do with erroneous payment transactions, which posting journal type to create the proposal from and whether to attempt immediate posting of the created posting proposal Payments 40

41 Erroneous payment can either be deleted or moved to a new payment journal, wherefrom the required corrections can be applied and the payments can be reprocessed. If posting is instead postponed until the bank has confirmed the execution of the payments, then users will sometimes experience, that some payments have been rejected by the bank. In that case, users will usually not be able to delete the erroneous payments, because the journal enters a noneditable state once transferred. To remove the erroneous payment lines, use Functions > Move. The move functionality allows moving the erroneous transactions to a new payment journal, wherefrom the required corrections can be applied and the erroneous payments can be reprocessed 6.3 ADVICE If the electronic advice included in the payment file is inadequate, it is possible to print and send an additional advice. advice is activated from the customer or vendor page by specifying an address and an template. See 5.4 Using advice has the great advantage, that there is no limit to the number of invoices, which can be included in a single advice. Furthermore, the advice functionality uses standard AX functionality, making it possible to create language specific templates, which resemble the language of the receiving vendor. Standard functionality also offers the possibility to use placeholders in the body, which can offer a more personalized touch to the message. Payments 41

42 Available placeholders are: Placeholder %Custname% %Vendname% Meaning Customer s name Vendor s name Printing and sending of advices can be done manually from the payment journal overview or inside the individual payment journals. To print and send the advice, click Print > Payment advice. If payment advice is activated from inside the journal, a dialog is presented, allowing the user to decide the print destination. If payment advice is activated from the payment journal overview, outside the journal, the Banking module will automatically loop through all the payment transactions related to the selected payment journal, and send advices to customers and vendors, which has advice enabled. It is possible to skip the manual advice process, by enabling Auto send advice from the Payments tab of the parameter setup (see 5.1.1). If auto sending of advice is enabled, the advices are printed and sent once a payment journal has been successfully transferred. 6.4 ADDITIONAL FUNCTIONS The payment journal has a few additional functions, which can be helpful. Especially if posting is done directly from the payment journal, and therefore does not rely on bank return files. The functions are available from the Functions menu Payments 42

43 The menu items have the following functions: Menu item Transactions Cancel Move Update payment date Function A link to standard AX s transactions form, which can be effectively used to get a detailed list of payees transactions. Used to cancel the payment journal. This option is only available to trusted personnel, which has been assigned to the AMC Banking manager security role Used to move lines to another payment journal. This option is useful, if payments in the journal has been marked as erroneous, as this blocks further processing of valid/accepted payments. In such cases, the erroneous payments can be moved to a separate journal, allowing further processing of the accepted payment, while allowing reprocessing of erroneous payments in a separate payment batch. Easy way to update several transactions payment dates simultaneously Payments 43

44 PAYMENT NOTIFICATIONS Payment notifications reflect the credit and debit transactions, which have been physically posted on the bank accounts in the bank. This section covers the processing of payment notification, from the initial import to the final posting inside AX. The overall goal when importing and processing payment notification, is to match, settle and post physical bank transactions with payments and/or open transactions in the AX environment. In earlier versions, payment notifications where restricted to banks, which could provide designated payment notification files. The new version offers this facility to all customers, who can receive simple bank account statements. This means that payment notification processing is available to a vast increased number of customers, e.g. customers from countries with limited banking infrastructure. 7.1 IMPORT For more info on importing return files, please see separate Importing bank return files document Imported payment notifications are matched against the own bank accounts, registered in the Banking module (see 5.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. 7.2 POSTING JOURNAL The posting journal is used to match and settle bank transactions against either payments from the payment journal or open customer/vendor transactions, and is opened from AMC Banking > Journals > Posting journal. The posting journal overview have the following fields: Section In use Meaning Specifies whether the journal is in use by either the system or a user Payment notifications 44

45 Company Name of journal Description Journal type Lines Ready Created date and time The company, which the journal belongs to 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 Lines. The posting journal contains two main parts, the top grid containing the individual payment and the bottom grid containing the current payment s settlements. Each payment is stamped with a color code, which allows the user to quickly get an overview of which payments, that have already been processed and which payments that require further attention 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) 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 notifications 45

46 Medium (Yellow) Low (Red) User (Blue) None (White) 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) 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 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 either Settlement on the Settlement tab or Payment on the Payment tab. Clicking Settlement will open a settlement page, in which the user, can settle the bank transaction against open invoices in AX. The open invoices available depends on the individual bank transaction, and e.g. depends on the account type and currency of the bank transaction. Payment notifications 46

47 Clicking Payment will also open a settlement-like page. Unlike the settlement pages, which allow settling of open invoices directly, the payment page instead allow users to settle the bank transaction against payment(s), that have been executed from the Banking module s payment journal. In this scenario, the payment works as an indirect link between the posting record and the open invoices settled against the payment. Posting journals, and thereby posting records, are usually created because of imported bank return files, such as account statements or payment notification. Thus, a posting record is usually tied to a specific bank account. The payments available for settlement are therefore limited to the payments, which have been executed on the bank account of the posting record. Furthermore, the payments are limited, based on the posting record s currency and status, where only payments with status Transferred, Received or Validated are included. Once a payment s status reaches Executed, the payment is posted, considered as processed and will therefore no longer be available for settlement in the payment settlement page. Payment notifications 47

48 Usually a posted payment is also an Executed payment, but if bridge posting is activated, a posted payment can have status Transferred. The payment settlement pages, solely considers the status of the payment, when filtering available payment. In this scenario, the users are therefore allowed to select the posted payment, thereby completing the bridge account to bank account posting. In both the regular settlement page as well as the payment settlement page, invoices that have already been settled elsewhere, will be marked with a tiny red lock. Thus, the user will not be allowed to conduct a settlement of the invoice. If the user wants to see where a locked invoice has been settled, it is possible to click the tiny lock icon. Doing so will result in an infolog; describing in which company the where the settlement has been done. Once the user has marked the invoices or payments to settle and made sure that the total settlement amount matches the payment amount (within max difference), clicking OK will carry out the settlements. As a new feature, the module allows automatic handling of payments exceeding the open invoices available. This situation e.g. occurs if a customer mistakenly pays invoices twice, thereby exceeding the expected payment amount (see example below). Customer receives invoice A + B Customer pays invoice A + B Customer receives invoice C Customer mistakenly pays both invoice B + C Payment exceeding expected amount Invoice A Invoice B Invoice A Invoice B Invoice A Invoice B Invoice C Invoice A Invoice B Invoice C Invoice A Invoice B Invoice C When attempting to carry out a settlement, where the payment amount exceeds the settlement amount, the user will be asked to confirm the amount difference, which will result in the original payment being split into three different transactions. 1) A ledger/bank transaction reflecting the original posted bank transactions 2) A settled customer transaction reflecting the part of the payment, which could be settled against open invoices 3) A not-settled customer transaction reflecting the remainder of the payment, which could not be settled 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. Payment notifications 48

49 If the customer does not utilize the cash disc, or if the customer utilizes the cash disc, but the cash disc date has been exceeded, the auto match will consider this an amount difference. Thus, an obtained match will be degraded to a low-level match. Should the user decide to accept the customer s payment despite of the amount differences caused by incorrect utilized cash disc, the settlement page allows modifying the expected cash disc easily by using the designated cash disc fields in the bottom of the settlement page. Depending on how the cash disc has been incorrectly utilized, there are different 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 ADDITIONAL FUNCTIONS The posting journal has several functions, which can be used to ease the process, getting from import to post. The functions are available from the Functions menu Payment notifications 49

50 The menu items have the following functions: Menu item Move Delete Renumbering Exchange rate Update payment date Function Used to move lines to another posting journal Easy way to delete many transactions, which can take very long, when done using the default delete functionality Used to regenerate the voucher numbers in the journal. This is e.g. useful to ensure using the lowest possible voucher numbers when using a continuous voucher series Allows updating exchange rates per currency/date. Useful if the bank is not able to provide the exchange rates related to the payments Easy way to update many transactions dates 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 50

51 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 7). The overall goal of the bank account reconciliation is to ensure that the posted ledger transactions in AX reflect the physical movements on the bank account, thereby also ensuring that balances in AX corresponds with the balances on the bank accounts. 8.1 IMPORT For more info on importing return files, please see separate Importing bank return files document Imported account statements are matched against own bank accounts, registered in the Banking module (see 5.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. 8.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 51

52 The own bank account grid contains two fields furthest to the right, Last date and Reconciled. The two fields provide a quick overview of the bank accounts, which 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 To reconcile across statements, simply click Reconcile, which will open the reconciliation page. To reconcile one statement at a time, instead click Bank statements, which will open a list of statements related to the selected bank account. The account statement overview contains a Reconcile button, which will open the same reconciliation page as can be opened from the bank account overview. In this case, though, the reconciliation page will only include bank transactions related to the current selected account statement. Account statements 52

53 The reconciliation page 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 page will open using the Unreconciled view. Two further view options exist, which can be activated from the View menu. - Unreconciled: Bank and ledger transactions, which have not yet been reconciled. - Reconciled: Bank and ledger transactions, which have been reconciled. - All: Both reconciled and unreconciled bank and ledger transactions AUTOMATIC RECONCILIATION To start an automatic account reconciliation run, click Auto reconcile. This will open a small dialog allowing the user to enter a few criteria, which decides the behavior of the automatic reconciliation. Account statements 53

54 Option Allow one-to-many reconciliations Behavior Specifies whether the automatic reconciliation should be allowed to settle a single bank transaction against multiple ledger transactions Allow date-amount reconciliations Allow posting date difference Note: Ledger transactions are required to have the same voucher or document number Specifies whether the automatic reconciliation should be allowed to reconcile transaction solely on amount and date. Specifies the number of days that bank and ledger dates can differ Once the behavior of the automatic reconciliation has been decided, click OK to initiate the reconciliation functionality. The automatic reconciliation will loop through the bank transaction displayed in the page, 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 54

55 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 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 Reconcile. 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 one reconciled transaction would result in the need to unreconcile all other related transactions as well LEDGER PROPOSAL When reconciling transactions manually, situations where the bank and ledger amount does not match, is likely to occur. Account statements 55

56 The ledger proposal is used to handle such situation. It is possible to add amount difference to the ledger proposal, but it is also possible to add bank transactions, if they have not been registered on the ledger side at all. To add either the bank transaction or the amount difference to the ledger proposal, use the respective buttons from the proposal part of the menu. Once a transaction has been added to the ledger proposal, the Proposal button will be enabled. Clicking the Proposal button will open the reconcile ledger proposal page. Account statements 56

57 When the user is satisfied with the ledger proposal, the proposal can be transferred to a ledger journal by clicking Transfer to ledger. The transfer dialog allows the user to select a ledger Journal name and has a Post option, which allows the user to automatically post the created ledger journal The ledger part of the reconciliation page is showing data directly from standard ledger tables. Thus, transactions posted from the ledger proposal are available immediately in the reconciliation page. 8.3 REPORTS The Banking module contains two reports to support the bank account reconciliation process, which are available from the Print menu. Account statements 57

58 8.3.1 RECONCILIATION REPORT To document the account reconciliation process, it is possible to print out a reconciliation report by clicking the Print > Reconcile report in the own bank account list page. This will result in a small dialog, in which the user can specify a date interval and a so-called Viewpoint allowing, seeing the either reconciliation from Current or Historical view. The box From date is automatically specified using the latest of the two dates: account reconciliation start date set on selected bank account or the start date of current fiscal year. Account reconciliation start date is indicated under AMC Banking > Common > Own bank accounts > Maintain > Edit > Reconciliation > Start date. 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 58

59 8.3.2 FORECAST REPORT It is possible to print a forecast report, which simulates the near future cash flow. The forecast is calculated dynamically, based on the latest account statement date from the bank as well as both realized and unrealized customer and vendor payment To print the forecast report, click Print > Forecast report in the own bank account list page. Account statements 59

60 APPENDIX 9.1 CHARTS From the overview of own bank accounts, it is possible to get a graphical view of data related to the individual bank accounts. Currently the module includes three charts, which can all be opened from the menu. - Balance: Provide an overview of the progression of the bank account s balance over time - Costs: Provides an overview of costs related to e.g. exchange fees, regular fees, interests etc. - Post: Provides an overview of the daily movements on the bank account 9.2 POSTING SCENARIOS The exchange rate when importing status files (DEBMUL) for the different posting scenarios can be: Own account currency Payment currency Posting MSD Posting CUR Exchange rate From file DKK DKK DKK DKK 100, no DKK USD DKK USD DKK/USD rate EUR EUR DKK EUR DKK/EUR rate EUR USD DKK EUR DKK/EUR rate 9.3 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 Appendix 60

61 complete excessive setup. Thus, it is possible to create a realistic demo file based on the customer s own data. Activating the menu item, opens a small dialog, where the user is asked to choose the bank account to base the demo data on. Once OK is clicked, the demo functionality will loop through the AX environment s open invoices, and attempt to create demo transactions, allowing users to test various reconciliation and auto match scenarios. To keep the demo simple, both bank accounts as well as open invoices are restricted to the company s currency only. When finished looping through the open invoices, the demo file is created, an infolog is returned, and the user can download the demo file. Appendix 61