Those who are familiar with prior versions of NAV
might remember Job Scheduler from previous versions. Job Queue was
introduced in NAV 5.0 with similar functionality to Job Scheduler, but
with a changed setup and architecture. Job Scheduler required a
dedicated NAV client to be run in the background, which meant an extra
NAV session was always occupied. With Job Queue, we don't require a
dedicated client to be always running. Job Queue runs on NAS.
Setting up Job Queue
We need to make sure the NAS is running. The setup parameter should be JOBQUEUE in NAS.
Job Queue can be set up from both the Classic and the RoleTailored client.
In the RoleTailored client, we can find the Job Queue menu under Administration | Application Setup.
In the Job Queue Setup, we need to make sure that the Job Queue Active
option is unchecked before the setup and while changing any setup
parameters. The option has to be checked after the setups are complete.
To set up a new job, under the lists, click on Job Queue Entries to see the list of existing entries or to create or modify entries.
Click New to create a new entry.
As an example, let's set up a
routine to run "adjust costs" automatically everyday and we would like
this batch job to run at night when the users are logged off. So every
day we get updated costs of our items. Report 795, Adjust Cost - Item Entries is the one used to adjust item costs.
In the Object type to Run field, select Report. The options are Report or CodeUnit.
Both reports and Codeunits can be used to run procedures. In NAV,
reports are used not only for reporting data, but also to sometimes run
repetitive procedures or loop-type programs. Therefore, depending on the
need, sometimes NAV reports are preferred over Codeunits by
programmers.
In the Object ID to Run field, look up the field to choose 795, Adjust Cost - Item Entries. We can leave the Parameter String field blank for this example. This field is used to enter the text string that is used as a parameter by the job.
Let's fill the other fields as follows:
User ID: This field contains the User ID of the logged in user and is filled automatically by the system.
Maximum No. of Attempts to Run:
Use this field to specify how many times the system should attempt
running the job in the case of failure in the first attempt. Sometimes,
other resources available to run the job might not be available; hence,
holding up the job from starting.
No. of Attempts to Run:
This field contains the number of attempts that have been made to run
the task. The value is incremented by one every time an attempt is made
to run, till it reaches the value specified in Maximum No. of Attempts to Run field, after which an error is generated.
Last Modified Date/Time: This shows the time stamp of when the job was last modified.
Expiration Date/Time: This shows the time/date when the task should expire.
Earliest Start Date/Time: This shows the time/date when the job should be run first.
Priority: Use this field to set priority for the job. The higher the value, the higher is the priority of the task.
Status: Describes the current status such as Ready, In Process, or On Hold. The default value is On Hold. The status needs to be changed to Ready by the user. The status is changed to In Process when the job is running.
Recurring Job: This Boolean field is used to specify whether or not the job is a recurring one. The other days, fields under the Recurrence tab are used to determine whether the job should run on the specified days.
Starting Time: This field is used to specify the start time of the job per run.
Ending Time:
This field is used to specify the latest time the job can be run. This
is particularly helpful if there are multiple jobs to be run. Then the
system will stop attempting to run the job after the time specified in
this field, so that other jobs can be executed. This is also useful to
stop the process overrunning and causing performance degradation when
the users are in the system.
After all the parameters have been specified, change the status of the job to Ready by clicking Reset Status, as shown in the following screenshot:
Now check the Job Queue Active in the Job Queue Setup field as shown next:
Common batch jobs
Once we know how to set up Job Queue, let's take a look at some examples of periodic jobs, which many businesses need.
Recurring journals
Recurring journals
are transactions that we repeat periodically, such as monthly payments,
invoices, accruals, and other repeatable entries. In NAV, a recurring
journal is like a general journal with extra fields to manage
reoccurrence of transactions. A recurring setup can be used for fixed
amounts and/or account balances, actual or budget amounts, allocations
to different balancing accounts, departments, dimensions, and many more.
Let's now understand all the fields in a recurring journal.
The important fields to be filled in a recurring journal are Recurring Method, Recurring Frequency, Posting Date, Document No., Account Type, Account No., Description, and Amount.
The Recurring Method field determines how the amount on the journal line is treated in repeated transactions. For example, the Same Amount
option uses the same value in every transaction. Hence, the amount is
not deleted after the posting. These types of transactions are helpful
where the amount is known every time, for example, monthly rental
transactions. If the amount is unknown and needs to change every time,
we can use the variable in the recurring method.
Options
|
Description
|
---|
Fixed:
|
The amount on the journal is unchanged and thus will remain after posting.
|
Variable:
|
The amount on the journal is variable for the user to enter every time and, therefore, will be deleted after posting.
|
Balance:
|
The posted amount on the account on the line will be allocated among the
accounts specified for the line in the general journal allocation
table. The balance on the account will thus be set to zero.
Remember to fill in the Allocation % field in the allocation list table.
|
Reversing Fixed:
|
The amount on the journal line will remain after posting, and a balancing entry will be posted on the next day.
|
Reversing Variable:
|
The amount on the journal line will be deleted after posting, and a balancing entry will be posted on the next day.
|
Reversing Balance:
|
The posted amount on the account on the line will be allocated among the
accounts specified for the line in the general journal allocation
table. The balance on the account will thus be set to zero. A balancing
entry is posted on the next day.
|
Creating a Reminders batch job
The Reminders batch job
is used to create reminders for customers with outstanding balances.
The function uses the reminder terms code and fin charge terms code of
the customer card to determine the relevant terms for the reminder. The
document date triggers the use of the batch job and all ledger entries
within that date, which are used when creating reminders using this
function. Based on the combination of the two, the function determines
if there are any additional fees or interest to be posted.
The next step is to set up
the criteria for sending the first, second, and third notice to
customers. In NAV this is done using levels in reminders. Level 1 is the
first reminder we send regarding an overdue amount. Level 2 is the
second reminder, and so on. For each reminder level, we can define a
grace period and a due date. We also specify whether or not interest or
an additional fee should be included on the reminder.
The following screenshot shows the Reminder Terms window accessed from the customer page:
We can access the Reminder Terms window from Advance | Levels | Payments | Customer Page.
Adjust Exchange Rates batch job
The Adjust Exchange Rates
batch job can be used to adjust G/L, customer, vendor, and bank account
entries, if the exchange rate has changed as the entries were posted.
The batch job doesn't replace or edit existing entries but posts
additional offsetting entries to match the changes.
The system uses the Adjustment Exchange Rate
field in the currency table to make exchange rate adjustments (gain and
loss entries) to G/L, customer, vendor, and bank entries.
Let's take a look at the fields in the batch job:
Starting Date: Enter a date to specify the beginning of the period for which entries will be adjusted. This can be left blank.
Ending Date: Enter the last date for which entries will be adjusted. Usually, it's the same as the posting date in the Posting Date field.
Posting Description: The user can enter any description text. The default text is Exchange Rate Adjmt. of %1 %2 , in which %1 is replaced by the currency code and %2 is replaced by the currency amount that is adjusted (for example, Exchange Rate Adjmt. of CAD,$12,600).
Posting Date: Enter the date on which the G/L entries will be posted. This date is usually the same as the ending date in the Ending Date field.
Document No.: Enter a document number that will appear on the G/L entries created by the batch job.
Adjust Customer, Vendor and Bank Accounts: Place a check mark in this field if we want to adjust customer, vendor, and bank accounts for currency fluctuations.
Adjust G/L Accounts for Add.-Reporting Currency:
This is required only if we use additional reporting currency and if we
want to post-in an additional reporting currency. Also, if we want to
adjust G/L accounts for currency fluctuations between $ and the
additional reporting currency, we can make use of this feature.