Skip to main content

FAQs

  • Are there any steps I can take to speed up processing during the NML period and year end?

    Consider adopting one or more of the following strategies to speed up period and year end procedures:

    • Spread Your Workload: To spread the workload away from period end, postings from other ledgers should take place throughout a period.
    • Turn off automatic budget revision: Enter N for Budget Auto-Revision on the User Preferences tab of NML Parameter Record 1 if no automatic revision is required at Period End. The setting can be changed at will.
    • Free up the Accounts Masterfile at Year End: Integra end-users will be unable to access the accounts masterfile while the Year-end update is in progress. If you are using Journalled Budgets, then depending on the extent of the updates required, the process can take some considerable time. If this becomes a problem, you can reduce the time during which the masterfile will be unavailable. First, reset the Budget Auto-Revision indicator on the General Parameters (NML100_1) to No then exclude Budget Data Sets from the Year End Directives . The excluded budget datasets can then be updated as a separate exercise using the Multi-function Data Set Add/Copy program. This will not reduce the time taken overall - in fact it will increase it - but it will make the accounts masterfile available sooner.
    • Optimise the speed of the Summary Views Update: You can Optimise the speed with which the Summary Views Update is run on your system. See FAQ above on speeding up Summary View Updates.

    Prevent automatic year-end updates of the budget history: The budget history updates can cause delays and can be avoided in the following way:

    Before the year end is run in the nominal ledger, flag all budget datasets as not being a budget dataset to stop Integra looking for budget history records.
    ove the balances using the year end directives.

    Use the following SQL statements to re-flag the budget history records against the dataset which now holds the balance:

    Update nmlbjdet set dset=newdataset where dset=olddataset;

    or

    Update nmlbudhist set dset=newdataset where dset=olddataset;

    (where newdataset and olddataset represent the dataset numbers)

    The year-end actions that affect a budget data set are COPY, ADD, ZERO, ROLL-UP and OPENING BALANCE.

    Contact the iSOFT Business Solutions consultancy team:  If the above strategies fail to bring about an effective improvement, contact the iSOFT Business Solutions consultancy team. They may be able to develop SQL scripts tailored to your own particular circumstances which will speed up the period and year end processes and reduce system down-time.

  • Can a currency other than the Base 1 currency be used for SMS Stock Management Updates?

    Generally, RSS updates to the SMS Stock Management System calculate the appropriate values using Base 1 currency; the details for which are held in array fields - element (0) holds Base 1, element (1) holds Base 2 and so on. Provided your Systems Administrator has amended GL4.COM to assign a logical, SMS_CURR_CODE to a number that represents the base currency required, you can choose the currency in which RSS updates to SMS should be made. If the translation of the SMS_CURR_CODE logical fails or if the number retrieved does not represent a valid currency, then Base 1 currency (element 0) will be used.

  • The Summary Views Update takes a long time - what can I do to speed it up?

    To optimise the speed with which the Summary Views Update is run, the program reads the following files into memory so that subsequent data access is satisfied from memory rather than from disk:

    • NMLORGGRP
    • NMLORGVIEWS
    • NMLORGSUMMV
    • NMLACCMF Held entirely in memory
    • Held entirely in memory
    • Keys held in memory
    • Keys held in memory

    The maximum number of records which can be held in memory is unlimited, but to reduce memory usage, pre-programmed limits are set as follows:

    • NMLORGGRP
    • NMLORGVIEWS
    • NMLORGSUMMV
    • NMLACCMF 2,000 records
    • 7,000 records
    • 50,000 records
    • 30,000 records

    If you have less than the above number of records, then your systems administrator can reduce these limits thereby reducing the amount of dynamic memory used. If you have more than the above number of records then the limits must be increased to accommodate the additional information.

    How many records do I have?

    Oracle database users can determine the number of records in these tables using the sqldba utility. For each table NMLACCMF, NMLORGGRP, NMLORGVIEWS and NMLORGSUMMV, enter the command

    select count(*) from;

    In each case the result is the number of records on the file/table. Round this figure up to the nearest 1000. For ORGSUMMV, round up to the nearest 5000. How do I change the pre-programmed record limits? The /s7 directory contains a file called Config. Ask your systems administrator to add the following new lines to this file: MAX_ACCMF_RECORDS MAX_ORGGRP_RECORDS MAX_ORGVIEWS_RECORDS MAX_ORGSUMMV_RECORDS NOTE: To ensure that the program does not cause extensive paging activity on your machine, it is best run after hours.

  • How can I amend RSS purchase order lines which have been partially received?

    You will be able to amend partially received purchase orders lines - those with a status of B or D - if your Systems Administrator has set the Allow For Amendment of Partially Recieved Order Lines to Y, within the SEC320 - Integra Settings, this will assign a logical, RSS312_PARTAMEND. You will be prevented however from bringing the line quantity or value below what has already been received.

  • I’ve used SQL to reset transactions to Posted prior to running the final Period End Update in NML,

    Transactions are tagged with a counter in NML to indicate how many times they have gone through the year end process. NML examines the POSTED_YN column on the NMLTRX table to derive the value for this counter. In normal use, the POSTED_YN column cannot be set to Y so long as the transaction is in a year greater than that being closed.

    Transactions can be lost however if SQL has been used to manipulate the setting of the POSTED_YN column. This is sometimes done to speed up year end processing.

    If you have used SQL to reset transactions to Posted prior to running the final Period End Update, and you neglected to reset it before running the Year End, the solution below will rectify matters. Discover if the problem applies to you by entering the following SQL code…

    select count(*)
    where period like “YYYY%”
    and years_retained > 0;

    where YYYY is the year/cycle code for the year being closed. If zero is returned then no action is required, otherwise take the following corrective action…

    update nmltrx
    set years_retained = 0
    where period like “YYYY%”
    and years_retained > 0;

    If the number of rows returned from the update statement equals that in the select statement then…

    commit;

    NOTE: The solution applies to ORACLE users only and assumes that the the RETAIN_TRANSACTIONS indicator is set to 2 - the most common setting.