SPM Format

<< Click to Display Table of Contents >>

Navigation:  SPM > SPM > Formats >

SPM Format

Format Name: SPM

File Name: SPM.zip

Software: EQuIS SPM

Source: SPM install

Export(s):  SPM Export EDD

 

Description: The SPM format allows SPM plans to be imported/exported to different facilities.

 

Installation Instructions: This format requires a licensed SPM and the SPM Schema applied to the database.

For SPM usage, no additional steps are necessary.

For Enterprise and Professional usage of the export, this format should be published to the database. The export will be available for selection as a report once it has been published.

 

 

Overview: The SPM format is divided into three groups: SPM Contract, SPM Plan Task and Samples, and Scheduled Task Update. The format also contains SPM_Access and SPM_Task_Cost sections that can be used to populate the DT_SPM_ACCESS and DT_SPM_TASK_COST tables, respectively.

 

 

Limitations/Assumptions: The checks and mappings in any EDD format involve assumptions. The following are limitations and assumptions for the SPM format:

The format uses Get and Create methods to retrieve and populate certain fields in the database (i.e., Get/CreateSPMContractId, Get/CreateSPMContractMAGId, Get/CreateSPMContractMethId, Get/CreateSPMContractContainerId).

SPM Contract Group

Contracts created using the SPM format must be plan-specific. When creating contracts using the SPM interface, the option exists to make contracts shared amongst plans. However, because the plan_code field in the DT_SPM_Contract section of the format is part of the Primary Key, it is not currently an option to create shared contracts using the format.

The contract_start_date field is used to associate records in the SPM Contract  and SPM Plan Task and Samples groups of the format. Failure to populate this field in each section can cause the associations between parent/child tables to break and result in errors on Create.

Creating contract analytic methods and associating them to contract method analyte group (MAG) members is not currently possible in the same EDD.

For EDDs where new contract analytic methods are created, the spm_contract_method_id is not generated until the Create step.

Once contract analytic methods are in the database, the DT_SPM_Contract_Mag_Members.spm_contract_method_id field must be populated to then associate contract MAG members.

DT_SPM_Contract_Mag_Member.cas_rn is a lookup to RT_ANALYTE.CAS_RN. It is not constrained to the members of the MAG selected in method_analyte_group_code field. Adding analytes to the contract MAG that are not members of the parent MAG will result in the contract MAG becoming out of sync with the parent MAG, as can be seen in the ‘In Sync With Rt’ column in the SPM Contract MAG interface.

SPM Plan Task and Samples Group

The naming_schema_sample_name field, found in the SPM_Plan and Planned_Task_Commitment sections, is not required. However, if populating this field, adherence to the correct syntax for defining the sample name is required. A single record in DT_SPM_PLAN.NAMING_SCHEMA_SAMPLE_NAME that does not adhere to the required syntax can cause errors to be thrown throughout the SPM interface.

The default values for the naming_schema_sample and naming_schema_task fields in the SPM_Plan and Planned_Task_Commitment sections of the format will be auto-populated if left blank in EDD or when manually creating rows in EDP.

When creating a task using the Planned_Task_Commitment section, a value should always be entered into the duration_value field. Failure to do so will result in a "Conversion from type 'DBNull' to type 'String' is not valid" error when attempting to open the task in SPM.

Valid values for this field can be found in the RT_LOOKUP table where LOOKUP_TYPE = spm_duration.

If DT_SPM_COMMITMENT.ISOLATE_YN is not populated, in SPM it will be unchecked and treated as if it were ‘N’. This can lead to unexpected optimization when scheduling tasks. If using the Planned_Task_Commitment section of the format, it is recommended that isolate_yn be populated to avoid any unexpected behavior.

Planned_Task_Commitment Section (Defining Recurrence)

The Planned_Task_Commitment.Recurrence field can be used to define the frequency with which a task takes place. This field requires a specific notation to be properly parsed by SPM. See below for the specific notation and examples.

The individual sections within the notation are separated by a pipe delimiter ( | ), the number of which will vary depending on the specifications of the recurrence.

Daily

d|x, where x = every x days| x (same value as previous x)|True/False, where True = tasks occur only on weekdays

Example: d|5|5|False – Tasks will take place on a daily schedule, every 5 days, weekends included.

Weekly/Bi-Weekly/N-Weekly

w|Comma separated list of days on which tasks occur1|x, where x = every x number of weeks

1 Days of the week must be represented by their numerical equivalents, where Monday =1, Tuesday = 2, and so on until Sunday = 7.

Example: w|2,5|2 – Tasks will take place on a weekly, bi-weekly, or n-weekly schedule, every Tuesday and Friday, every 2 weeks.

Monthly/Quarterly/Semi-annually

m|Day of the week|nth1|Day of the week2|nth3|Month Count

1 The first ‘nth’ value has 6 valid values: First, Second, Third, Fourth, Fifth, and Last.

This section should be populated if a user intends to enter a specific day of the week in the first ‘Day of the week’ section, such as “on the Second Tuesday of every Month”.

This section should be left blank if a user intends to just use ‘Day’, such as “on the 2nd Day of every Month”.

2 If a day of the week is entered at all, it must be entered twice. There should be no difference between the second section of the notation and the fourth.

3 The second ‘nth’ value has 31 valid values (1-31). This field should always be populated. If a value is entered in the first ‘nth’ section of the notation, such as ‘Second’, then enter a ‘1’ in this section.

 

Note: In the case where some sections of the notation will be left blank, the pipe delimiters should still be entered but nothing should come between them.

 

Example: m|friday|second|friday|1|2 – Tasks will occur on a monthly, quarterly, or semi-annual schedule, on the second Friday of every 2 months.

Example: m||||4|5 – Tasks will occur on a monthly, quarterly, or semi-annual basis, on the 4th day of every 5 months.
In this case, the Day of the week and first ‘nth’ sections were not necessary, so 4 pipe delimiters were entered with nothing in between to signify that the value of these 3 sections is null.

Annually

y|Day of the week|nth1|Day of the week2|nth3|Month4|x, where x = every x number of years

1 The first ‘nth’ value has 5 valid values: First, Second, Third, Fourth, and Last.

This section should be populated if a user intends to enter a specific day of the week in the first ‘Day of the week’ section, such as “on the Second Tuesday of every October”.

This section should be left blank if a user intends to just use ‘Day’, such as “on the 2nd Day of every October”.

2 If a day of the week is entered at all, it must be entered twice. There should be no difference between the second section of the notation and the fourth.

3 The second ‘nth’ value has 31 valid values (1-31). This field should always be populated. If a value is entered in the first ‘nth’ section of the notation, such as ‘Second’, then enter a ‘1’ in this section.

4 Months must be represented by their numerical equivalents, where January = 1, February = 2, and so on until December = 12.

 

Note: In the case where some sections of the notation will be left blank, the pipe delimiters should still be entered but nothing should come between them.

 

Example: y|monday|third|monday|1|10|2 – The task will occur on an annual basis, every third Monday of October every 2 years.

Example: y||||2|4|3 – Tasks will occur on an annual basis, on the 2nd of April every 3 years.
In this case, the Day of the week and first ‘nth’ sections were not necessary, so 4 pipe delimiters were entered with nothing in between to signify that the value of these 3 sections is null.

 

Additional information including descriptions of each field, data types, method mappings and definitions can be found in the EDD Description for the SPM format. The EDD Description file can be created in EDP.

 

 

EQuIS Table Mappings:

 

AT_SPM_COMMITMENT_REPORT

AT_SPM_CONTRACT_MTH_CONTAINER

DT_SPM_ACCESS

DT_SPM_COMMITMENT

DT_SPM_CONTRACT

DT_SPM_CONTRACT_CONTAINER

DT_SPM_CONTRACT_METHOD

DT_SPM_CONTRACT_MAG

DT_SPM_CONTRACT_MAG_MEMBERS

DT_SPM_PLAN

DT_SPM_PLANNED_ACTIVITY

DT_SPM_PLANNED_CONTAINER

DT_SPM_PLANNED_RESULT

DT_SPM_PLANNED_TASK

DT_SPM_PLANNED_SAMPLE

DT_SPM_SCHEDULED_ACTIVITY

DT_SPM_SCHEDULED_SAMPLE

DT_SPM_SCHEDULED_TASK

DT_SPM_TASK_COST

DT_TASK

RT_COMPANY

RT_GROUP

RT_MATRIX

 

 

Exports: The data returned will be automatically filtered by the facility to which the user is connected, as well as by the parameters selected prior to running the report.

 

Export

Format Section

Source Table(s)

SPM Export EDD

SPM_Plan

DT_SPM_PLAN

Planned_Task_Commitment

DT_SPM_COMMITMENT

DT_SPM_PLANNED_TASK

Commitment_Reports

AT_SPM_COMMITMENT_REPORT

DT_SPM_COMMITMENT

DT_SPM_PLANNED_TASK

Planned_Sample_Result

DT_SPM_CONTRACT

DT_SPM_CONTRACT_MAG

DT_SPM_PLANNED_RESULT

DT_SPM_PLANNED_SAMPLE

DT_SPM_PLANNED_TASK

Planned_Sample_Container

DT_SPM_CONTRACT

DT_SPM_CONTRACT_MAG

DT_SPM_CONTRACT_METHOD

DT_SPM_PLANNED_CONTAINER

DT_SPM_PLANNED_RESULT

DT_SPM_PLANNED_SAMPLE

DT_SPM_PLANNED_TASK

Planned_Activity

DT_SPM_PLANNED_ACTIVITY

DT_SPM_PLANNED_TASK

DT_SPM_Contract

DT_SPM_CONTRACT

DT_SPM_Contract_Method_Cont

AT_SPM_CONTRACT_MTH_CONTAINER

DT_SPM_CONTRACT

DT_SPM_CONTRACT_METHOD

DT_SPM_CONTRACT_CONTAINER

DT_SPM_Contract_Mag

DT_SPM_CONTRACT

DT_SPM_CONTRACT_MAG

DT_SPM_Contract_Mag_Members

DT_SPM_CONTRACT

DT_SPM_CONTRACT_MAG_MEMBERS

DT_SPM_CONTRACT_METHOD

SPM_Access

DT_SPM_ACCESS

SPM_Task_Cost

DT_SPM_TASK_COST