The Excel Integration menu activity is available for a number of business components in Enterprise Financials. However, when importing very large amounts of data to the system, the new Bulk Data Load (36.24.8) is a more efficient utility. It is useful when setting up an implementation. Bulk Data Load lets you import multiple csv files into the system at once. It processes the contents of these files in batches, so that an error in one batch does not cause the entire import process to fail. You can use Bulk Data Load to import the following types of information:

There are a number of enhancements to daemon functionality:

Consistency checks are a series of validations that verify the integrity of the financial tables. You can run three categories of consistency check: technical, business and others.

Some checks in the business check section have already been covered in the technical check section. Redundant checks have been removed, making the checks consistent and improving performance. The performance has also been improved by the use of more efficient data retrieval methods, indexes, and other enhancements.

The original result file contained a lot of unnecessary processing messages, which made it difficult to find the real errors. To make the output clear, a new summary result file is now generated, outlining the check results for the business checks. The summary file is designed to give a general overview of the checks in a business-oriented way. You can easily find the result and the inconsistent amounts. For more detailed debugging, you can search the detailed result file to find the root cause.

The following checks have been added:

Report Cube Definition has been migrated to BLF technology. As a result, five new menu programs have been created:

Report Chart of Accounts Definition has been migrated to BLF technology. As a result, four new menu programs have been created:

Report Analysis Code Create now includes a Controlling Dimension field in the General tab. When generating reports, you can generate a report filtered on each value of the controlling dimension, which saves you having to generate each report individually.

The drop-down list for the Controlling Dimension field is populated based on the dimensions you select in the Dimension area of the General tab. For example, if you select fields for the GL, Sub-Account, and Daybook dimensions, these three options are available as controlling COA dimensions.

When running a report in Financial Report Run, you can specify an analysis code with a controlling dimension as a Filter Analysis code to control the bursting. You must also specify Yes in the new Report Burst selection field in Financial Report Run. The report run then generates a separate report for each value of the controlling dimension. For example, if the analysis code has a controlling dimension of Entity, the report run generates reports for each entity.

Report Master Create, Report Tree Maintenance, and Financial Report Run contain new fields that let you control whether to display detailed GL transactions on your reports.

Report Master Create contains a new Print GL Transactions field. The options are:

Report Master Create also contains a new Max Posting Lines field that lets you specify the maximum number of posting lines to include in a report. If the total number of lines in the report exceeds the maximum posting line value specified, an error message displays when you run the report.

Report Tree Maintenance includes a new Show Details field that lets you indicate the leaf nodes for which you want to print GL transactions in detail on a report.

Financial Report Run contains a new Print Details report selection criteria that lets you indicate whether you want to include detailed GL transactions in the report output. If you set this field to Yes, but have not configured the required setup in Report Master Create or in Report Tree Maintenance, the report displays an error message.

Report Cube Consistency Check (25.16.50.5) lets you check a cube’s balances in base currency against the balances for the source GL accounts.

In the browse, you can filter on the cube, entity, report year, and report period for which you want to check balances. The results in the browse compare the base currency opening balances, debit and credit values, and closing balances of the source entity and the cube. The browse also lists amounts in the cube’s presentation currency.

The Differences column shows all zeros when the balances in the source entities (Trial Balance) are equal to the balances in the report cube.

If there are unprocessed Cube daemon queue records, an error displays indicating that the cube is not up to date. In this case, you must wait until the Cube daemon has successfully processed the queue. You can verify the queue status in Cube Daemon Monitor.

A number of new variables are now available to use in the Title and Subtitle fields in Report Master Create:

In the Row Style field in Report Tree Maintenance you can now indicate that for transactions related to a particular leaf node, a report must display credit balances only or debit balances only. To show accounts with debit balances only, enter “dronly” in the Row Style field. To show accounts with credit balances only, enter “cronly” in the Row Style field. Typically, the option to display debit amounts only or credit amounts only is useful in Balance Sheet reports, where you can show, for example, bank accounts with a debit balance under assets and bank accounts with a credit balance under Liabilities.

The existing Financial Report Run field Show All Columns field has been relabeled to Show COA Columns.

When you set Show COA Columns to Yes and Detail Transaction to Yes, the report displays additional COA columns and uses an Excel layout to allow the additional COA columns to display.

If you set Show COA Columns to Yes, but the COA Type fields are blank and the Detail Transactions field is set to No, an error message displays indicating that the Show COA Columns option requires a COA Type or that Detail Transactions must be set to Yes.

A new Layout menu at the top of the Financial Report Run screen contains two choices:

You can now insert page breaks between different report detail levels. To insert a page break between different levels of detail, enter “page” in the Row Style field in Report Tree Maintenance at the level after which you want the page break. For example, if the highest level of information in the report tree is GL, and the next level is Entity, enter “page” in the Row Style field for the GL node. On the report, the entity details start on a new page after the GL details.

You can now run year-end closing on the official layer and also on management layers. You can close management layers before or after closing the official layer.

The Year-End Closing activities (25.21.4) let you run a process to automatically create closing postings and to close the GL calendar year to new transactions. This enhancement concerns Year-end Closing Execute (25.21.4.1). The purpose of this function is to carry out a registration function, where year-end periods are created (if required), year-end closing postings are created, and all GL periods of the GL calendar year are closed.

The year-end closing postings include:

Prior to this enhancement, this function only affected the official (or primary) layer. The official layer was closed but all other layers, management or transient, remained open. This enhancement implements the year-end closing functionality in management layers. Transient layers are not affected.

Enhancements to the processing of incoming bank files provide improved visibility and reporting. You can also enable the process to create unallocated banking entries and prepayments, for manual allocation later. The following sections describe the enhancements to Process Incoming Bank Files.

The Imported Bank File report (31.1.11) displays details on the status and allocation of imported bank files or batches of files. The level of detail included in the report enables it to be used for audit purposes and for troubleshooting.

The report displays different types of detail, depending on whether the record was a successfully processed customer payment, supplier payment, or banking entry, or if the record was unprocessed or processed with errors. The report contains up to five sections.

You can now import a bank file using Excel Integration. Incoming Bank File Excel Integration (31.1.12) lets you export a file template to Excel, complete the template with bank file data, and import the file back into the system. When the file imports successfully, you can save the file and then run Process Incoming Bank Files (31.1.6) to process it.

Using Payment Processing Configuration Maint (31.1.13), you can define how Process Incoming Bank Files (31.1.6) is to process bank files containing the action types:

When the instruction in the bank file is to create a customer payment, and a customer is not found by the system, the default behavior is to raise an error message. However, you can instead specify that the system create an unallocated banking entry.

When the instruction in the bank file is to create a customer payment and no matching invoice is found by the system, you can specify system behavior by choosing to create a prepayment, create an initial payment, or create an unallocated banking entry.

When the instruction in the bank file is to pay a customer payment, you can choose to raise an error message or create an unallocated banking entry.

For each bank account, you can configure separate settings.

As a result of the enhancements, depending on your configuration, Process Incoming Bank Files can create unallocated banking entries and prepayments.

The error messages displayed can also now be linked to the bank line where the error occurred.

Zero Postings Report (25.21.2.13) enables you to check posting lines with a zero amount. The search filters are Check Unposted Transactions, Entity, Daybook, GL Cal Year, GL Period, and Zero Amount By.

When you set Check Unposted Transactions to Yes and there are any unposted transactions, the report stops and displays a message. You can set up the report to display zero amount postings in trade currency, base currency, and statutory currency.

Before QAD 2015 EE, you could only view payment selections with the Initial status in Customer Payment Selection View (27.6.6.7). You can now view customer payment selections with all statuses: Initial, Allocated, For Collection, Paid.

With the QAD 2015 EE release, GL Report Writer (GLRW) is retired and replaced by Financial Report Writer (FRW). FRW is fully installed as part of the core Enterprise Financials. FRW contains all the capabilities of the GLRW and more.

FRW provides financial reports (balance sheets, income statements, cash flows, management reports ...) spanning multiple domains with chart translation to any desired chart and currency translation to any desired currency. The report hierarchies can contain selections of any of the accounting dimensions.

Report data is retrieved from the core QAD Enterprise Financial tables and is real time up to date.

You can build the report hierarchies and analysis codes from a single graphical UI.

You can also build the report structures in Excel and load these in the system with automatic creation of the underlying analysis codes and links to the charts.

The reports can have up to 60 columns of facts: amounts in any currency, opening balances, closing balances, period activity (month, quarter, YTD, period ranges...) comparing periods, side by side comparison of entities, cost centers, and comparing actual with budget.

You can include calculations with amounts in both rows and columns.

You can create easy to read reports with many formatting options leveraging the capabilities of QAD Reporting Framework, including many output formats: document viewer, printer, PDF, text file, or Excel.

You can print reports with or without transaction details. Alternatively, use the interactive screen to drill down from the report totals to the detail source transactions.

You can schedule reports to be printed in burst mode, repeating the same report for many entities or cost centers.

For customers who build a lot of reports with GLRW, conversion routines are provided to allow you to export GLRW report definitions in a format that can be directly imported into FRW. These routines enable existing reports to be migrated to FRW with limited effort.

The actual conversion steps consist of the initial setup of the FRW report chart and cube, followed by the export from GLRW and import into FRW of the report definitions (row group/report tree, column group, and report master).

In a new installation of QAD 2015 EE, the GL Report Writer is not included. Customers applying a 2015 or higher version of Enterprise Financials on a version of Enterprise Edition prior to 2015 can choose whether to run the old GLRW or take advantage of the new FRW.

Several enhancements allow the use of operational allocation codes when processing memo items in Evaluated Receipts Settlement (ERS) and Receiver Matching.

When you purchase a memo item in Purchase Order Maintenance, you can use operational allocation codes at line level to split the posting lines across several GL accounts, sub-accounts, cost centers, or projects. To use operational allocation codes, specify the allocation code in the Pur Acct field when you create the purchase order.

During Operational Transaction Post, operational allocation codes in PO Receipt and other transactions are “exploded” to split the posting lines across the GL accounts, sub-accounts, cost centers, and projects in the relevant allocation codes. Therefore, in most cases, the system creates the required allocation postings for memo item purchases during Operational Transaction Post.

The Account field in the GL Account record now contains additional validation. The system displays an error if you attempt to create a GL account that has the same code as an existing operational allocation code.

Receiver Matching now supports the use of operational allocation codes.

If you set up an operational allocation code for several GL accounts and then specify the allocation code on a purchase order, Receiver Matching splits the posting lines across the GL accounts, sub-accounts, cost centers, and projects in the allocation code.

If you set the Use Exp Item Var Accts field to Yes in Supplier Invoice Control, you can view the operational allocation code in Receiver Matching, but the code is not actually used in the matching process. This situation occurs because the system has already charged the expense to the allocation code. The expense posting was created during PO Receipt, and was offset by the posting to the Expensed Item Receipts account and posted using Operational Transaction Post. In Receiver Matching, the main posting is to the Expensed Item Receipts account, and other accounts (other than tax accounts, the supplier control account, and the unmatched invoices account) are only used if there are usage or rate variances for the memo item purchase. If usage or rate variances occur, these are charged to the Expensed Item Usage Variance account or to the Expense Item Rate Variance account defined in Domain/Account Control.

If you set the Use Exp Item Var Accts field to No in Supplier Invoice Control, any usage or rate variances that arise from the matching of a memo item receipt are instead charged to the expense account defined on the purchase order line. If you specify an allocation code instead of a GL account, the allocation code is used in Receiver Matching.

For memo purchases only, you can change the GL account on the Receiver Matching line to an allocation code or you can change the allocation code on the matching line to a different one. In each of these cases, the Receiver Matching GL postings reverse the original postings made at PO Receipt and replace those with the new account or allocation code. As part of Receiver Matching, the allocation code is then exploded to its constituent accounts, sub-accounts, cost centers, and projects.

You can view operational allocation codes in Receiver Matching when matching memo items. The Op Alloc Code field in the Receiver Matching grid displays an operational allocation code if one was specified on the purchase order for the memo item. For memo items only, you can also enter a new allocation code, even if one was not used on the purchase order line.

If you set up an operational allocation code for several GL accounts and then specify the allocation code on a purchase order, you can use ERS to split the posting lines for the invoice and receiver matching across the GL accounts, sub-accounts, cost centers, and projects in the allocation code.

If you create and receive a purchase order for a memo item that uses an operational allocation code in one entity and then create the supplier invoice and receiver matching in another entity, the system creates cross-company postings. The GL accounts in the operational allocation code must be Standard accounts, and the system then uses the AP cross-company control account specified in the domain for the cross-company postings. During Operational Transaction Post, the posting lines, split according to the operational allocation code, are transferred to the other entity, where the original expense was recorded.

You must set the Use Expensed Item Var Accts field in Supplier Invoice Control to No to use any postings from allocation codes in Receiver Matching. To split the operational allocation code, the system takes a single posting line and splits the posting into two or most combinations of account, sub-account, cost center, and project, according to the allocation code. For each one of these postings, there must be an equal and opposite posting to the cross-company account in the invoice entity. Related cross-company control account postings in two entities must be equal and opposite.

You can now open and close the Periodic Costing sub-ledger in Entity GL Period Modify.

You can open the Periodic Costing sub-ledger if periodic costing is activated for the current domain. You cannot open the Periodic Costing sub-ledger if any future GL periods are still closed for period costing.

You can re-open the Periodic Costing sub-ledger for locked or open periods if the GL sub-ledger is open and if all other sub-ledgers are closed. You can re-open the Periodic Costing sub-ledger from within Financials or using an API.

In Entity GL Period Modify, you can manually close the Periodic Costing module for a particular GL period if there are no unposted periodic costing GL transactions and if there are no transient postings to Period Costing type daybooks for that period.

Mass Layer PC-Transfer Execute now runs at domain level so that you can use it to transfer periodic costing cross-company postings. In addition, the system displays a warning if any of the selected transactions are cross-company postings that still have corresponding postings in a transient layer. This provision helps to keep cross-company postings synchronized in both entities. Mass Layer PC-Transfer Execute only transfers one side of the cross-company posting. You must manually transfer the corresponding posting in the other entity to the management layer.

The system allows the user to create automatic GL accounts with all kinds of analysis limitations. Depending on the type of analysis limitation, some of the default analysis profiles are mandatory.

The system allows all kinds of analysis limitation in operational sides. If some analysis is mandatory but cannot be retrieved from operational transactions, the default setting in the GL account is retrieved when you post the operational transaction to the general ledger.

Sales and Use Tax API 5.0 is available in conjunction with the 2015 Enterprise Edition release. This new version provides enhancements to jurisdiction identification and provides additional GeoCodes.