Registering Ad-hoc Production Jobs

Overview

The following types of jobs are managed by CCLAS:

  • Registered jobs, including production, internal and proposal jobs

  • Template jobs

  • Schedule jobs and draft jobs raised from schedule jobs.

  • Laboratory batch jobs which comprise samples from multiple registered jobs for a suite of tests.

The registration of production jobs and samples is the heart of the real transaction mechanisms in the laboratory. A production job is a request for analysis for one or more samples taken from the field, plant, production line or other place, and submitted to the laboratory by a client, and forms the basis for tracking the progress of analysis, reporting and invoicing for services provided.

The job has one or more groups of samples that are (typically) submitted from a single client and are to be tracked, analysed and reported (typically).

The client should provide some written instructions with the samples as to what preparation, analysis and reporting is expected. Unless there are standing orders, it can be very 'dangerous' to start processing samples without the correct instructions, as some procedures are destructive, and may not be able to be 'undone'. The samples often represent a significant financial commitment by the client (to collect, identify, transport, etc.) and they might not be able to be re-sampled or re-collected if the laboratory compromises their integrity due to mis-handling caused by incorrect or partial instructions. Handling of samples that have unknown or incomplete instructions might also be dangerous in the sense that particular precautions may need to be taken in their handling and storage, etc. Staff safety is always paramount, and the last thing wanted is for ill-informed operators to start handling a sample in an incorrect or dangerous manner.

Until the job is registered into the system, there are chances that details can be lost, samples mis-identified or mis-handled, etc, so it is generally important that the job is registered as soon as possible, and that the job number is clearly identified on all containers, samples, paperwork, etc, so that sample tracking has the best opportunity to minimise procedural errors.

After a job is registered and its samples defined, it is then analysed, released, validated, reported and invoiced.

Production jobs are scoped by laboratory.

Process

These steps outline the registration of a production job:

  • Receive the request from the client.

  • Create the production job in CCLAS 6.

  • Update the job with the header details, biofields, sample and test details.

  • View the job invoice/s and attach quote/s where agreed.

  • Print job paperwork.

  • Send the job paperwork to sample reception.

The CCREGN—Job application is used to create and maintain production jobs.

Note: Security options can be set up to permit the creation of specific job types within an organisation or laboratory.

Creating an Ad-hoc Production Job

Ad-hoc production jobs are created and maintained using the CCREGN—Job application.

Upon job creation, select the Job Type is as Production.

Jobs have two primary identifiers: Code and Job Name.

  • Each job Code and Job Name must be unique within the organisation for org-scope jobs, and unique within the laboratory for lab-scope jobs.

  • Either select a Job Name Syntax Code to generate the job name or enter the Job Name. The JOB_NAME_ONLY_FROM_SYNTAX application preference is used to force syntax use.

    Some laboratories let the LIMS identify and 'pick' the next job number, whereas other laboratories pre-identify a series of job numbers that can be assigned to groups of samples without the need of a live connection to the LIMS. These might be provided as labels or barcode labels, or they might just be contained in a central 'book'. This mainly works if the sample receipt is at a central location, but if this is a dispersed function, then letting the LIMS identify the job number is probably a better solution.

    Using syntaxes to generate job codes and names allows for automatic incrementing codification. The system can be set to force job name creation from syntax only to control job coding and naming.

  • The DEFAULT_PRODUCTION_JOB_NAME_SYNTAX application preference is used to set a default Job Name Syntax Code for a production job.

Where the CODEVALIDATION_JOBCODE application preference is defined and contains a list of visible ASCII characters, then a valid job code only contains characters from this list. If this preference is not defined, then a valid job code only contains characters from the ABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789 character set. The Scope for this preference is usually set at laboratory level.

Where the CODEVALIDATION_JOBNAME application preference is defined and contains a list of visible ASCII characters, then a valid job name only contains characters from this list. if this preference is not defined, then a valid job name only contains characters from the ABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789 character set. The Scope for this preference is usually set at laboratory level.

Refer to:

Use a Registration Mode of New Job by Client, in which case a Client Code must be entered with an optional Project Code and Contact Code.

  • If the selected client has a Primary Project Code defined, then that project is used as the default Project Code.

  • A job can only link to a client has is flagged as being able to submit samples.

  • Whether the Project Code is optional is driven by MANDATORY_PROJECT application preference.

  • A job can link only to a project that is flagged as being able to submit samples and where the job's Received Date falls in the project's Project Open Date and Project Close Date time frame.

    Note: The drop-down selection list excludes projects that cannot submit samples, but it does not exclude those outside of the job's Received Date as that date is not calculated until an attempt to create the job is made. Where a project is selected that cannot have samples submitted or the job's Received Date is outside the project date, then an error is returned upon submit.

  • Whether the Contact Code is optional is driven by the MANDATORY_CONTACT application preference.

  • If a project is selected and the project has a Primary Contact Code defined, then that contact is used as the default Contact Code. Otherwise, if a project is not selected and the client has a Primary Contact Code defined, then that contact is used as the default Contact Code.

Refer to Maintaining Clients.

Upon Creating Ad-hoc Production Jobs

Upon ad-hoc production job creation:

Register an ad-hoc production job

Job Locks

Cost Centre

The following processes are used so that the system can assign a default cost centre based on a production job's client.

Priority and Dates

The following processes are used to set a default value for a job's priority, set the working days of the week for the laboratory, and maintain holidays.

If the job has a project defined, and priority is defined on the project, then the job's priority is set from there. Otherwise, if priority is defined on the client, then the job's priority is set from there. Otherwise if a default priority is set up in the DEFAULT_PRIORITY application preference, then the job's priority is set from there.

A job's priority, the defined working days of the week, and holidays, are used to determine required dates for a production job.

The AUTO_RECEIVE_JOBS application preference configures whether a job's Received Date and Received By are set automatically, or left empty for manual update.

Workflow Status

Job Biofields

The following processes are used so that the system can assign job and sample biofields to production jobs.

Job Stakeholders and Report Templates

When a job is linked to a client, the client can bring in default report templates.

Job Invoices

Sample Tracking

What to do Next

Refer to Adding a Group of Samples to a Job