INVOICE_GRID_SCHEME_HDR_FIELD

STRING, comprising a scheme attribute in the format:

attributeName

or

tableNameAlias.attributeName

When Maintaining Job Invoice Samples and Tests from Registration or Maintaining the Samples and Tests on a Job Invoice in an Invoice to maintain the invoice sample grid on a job invoice, then the content of scheme column headers is set based upon this preference. When a column that contains a scheme is displayed in the CCINV—Invoice application, then:

  • If empty (default on deploy), then the value of the default attribute is used as the column heading (see below).
  • If not empty, then the system attempts to find the value of the supplied attribute.

The table name aliases are JS for job scheme, SCH for scheme, and SC for scheme version.

The scheme attributes are defined by the related DTO property name (displayed when the cursor hovers over a screen field where the Show attribute tooltips setting is enabled).

Where scheme attributes are taken from SCH or SC, then they are taken from the org-scope (not the enabled-scope), or the lab-scope.

The column heading is set using the following rules:

  1. Where either:
    1. The preference is not defined
    2. The preference's value is inactive
    3. The preference's value is empty
    4. The preference's value does not contain a recognisable attribute name within JS, SCH or SC
    5. The preference's value contain a table name alias but does not contain a recognisable attribute name within that table

    then the scheme's Name is used as a default. For example:

    • <empty> --> S.name
    • xxx --> S.name
    • XXX.xxx --> S.name
    • JS.xxx --> S.name
    • JS.name --> S.name
    • SC.exportName --> S.name
  2. Where either:
    1. The preference's value does not contain a table name alias, but contains an attribute name within JS, SCH or SC
    2. The preference's value contains a table name alias that does not match JS, SCH or SC, but contains an attribute name within JS, SCH or SC

    then the first occurrence of the field within JS, SCH and SC, in that order, is used. For example:

    • name --> S.name
    • reportName --> JS.reportName
    • priceCode --> JS.priceCode when the price code is populated, otherwise S.code
    • exportName --> S.exportName
    • XXX.name --> S.name
    • XXX.reportName --> JS.reportName
    • XXX.exportName --> S.exportName
    • SV.name --> S.name
    • SV.reportName --> JS.reportName
    • SV.exportName --> S.exportName
  3. Where the preference's value contains a table name alias matching JS, SCH or SC, and contains an attribute name within that table, then it is used. For example:
    • JS.reportName --> JS.reportName
    • JS.priceCode --> JS.priceCode; S.code
    • SCH.name --> S.name
    • SCH.reportName --> S.reportName
    • SCH.priceCode --> S.priceCode
    • SCH.exportName --> .exportName
    • SC.name --> Error on screen display (Scheme version fields are not supported)
    • SC.reportName --> Error on screen display (Scheme version fields are not supported)

The supported scheme-based attributes are:

Job Scheme

Scheme

SchemeVersion

activatedUserId

allowReportNonValData

approvedDate

analysisTextId

autoRelease

approvedUser

compositeQcStatus

autoValidate

creationDate

compositeSpecStatus

containerTypeId

creationTime

creationDate

creationDate

creationUser

creationTime

creationTime

defaultRackSize

creationUser

creationUser

schemeName

fixedBasePrice

datagridHeaderName

 

fixedBlockPrice

description

 

isAutoValidate

exportName

 

isIncludedInJobQc

gridOrientation

 

isReportable

id

 

jobCode

importName

 

jobId

instrumentGroupCode

 

laboratoryCode

instrumentGroupId

 

lastActivatedDate

isActive

 

lastModDate

isCorrectionApplied

 

lastModTime

isIncludeInCosts

 

lastModUser

isInvoiceable

 

numberOfUnits

isReportable

 

organisationCode

laboratoryCode

 

priceCode

laboratoryId

 

priceCodeLabCode > priceCodeLabCode

lastModDate

 

registrationSequence > registrationSequence

lastModTime > lastModTime

 

reportDescription > reportDescription

lastModUser > lastModUser

 

reportFooterTextId > reportFooterTextId

latestPublishedVersionId > latestPublishedVersionId

 

reportHeaderTextId > reportHeaderTextId

organisationCode > organisationCode

 

reportName > reportName

pretreatmentCategoryId > pretreatmentCategoryId

 

reportSequence > reportSequence

priceCode > priceCode

 

reportTextId > reportTextId

priceType > priceType

 

requiredDate > reportDate

reportDescription > reportDescription

 

resultHeaderTextId > resultHeaderTextId

reportName > reportName

 

schemeCode > schemeCode

scheme2TextId > scheme2TextId

 

schemeId > schemeId

schemeCategoryId > schemeCategoryId

 

schemeLaboratoryCode > schemeLaboratoryCode

schemeScriptId > schemeScriptId

 

schemeName > schemeName

schemeTextId > schemeTextId

 

schemeVersionId > schemeVersionId

schemeType > schemeType

 

workflowStatus > workflowStatus

sectionCode > sectionCode

 

 

sectionId > sectionId

 

It is suggested that the maximum length should be 10 characters as a greater length than this causes the headings to consume the entire screen, preventing scrolling and making the grid unusable. Custom attributes are not supported for the sample grid.

Typically the preference is not set at role or user level.

Related Processes