Work items are a core entity for any case-related data. Where ShareDo differs, however, is that many different entities are managed as cases in their own right. Work items that can be imported via the data loader include:
| ENTITY | Description |
|---|---|
| Instructions | Typically used to manage the onboarding of matters in either a B2B or B2C context |
| Task | Manages distinct activities within sharedo |
| Matter | Provides containers in which cases can be managed |
| Offers | Manages the financial offer process; typically used for dispute matters |
| Payments | Manages the request of payments from third parties. |
| Invoices | Manages the recording of invoices for matters. |
| Statements of Work | Manages the import of statements of work |
| Proceedings | Manages the import of litigation details |
To load a particular work item, you need to populate some core loader tables that are common across all ShareDo entities; these include:
| ENTITY | Description |
|---|---|
| Sharedo | Populates the core sharedo information |
| Task | Populates additional task information. There should always be one record in Task for each sharedo record. |
| Phase History | In order to fully record the progress of a task this table should be populated |
| Participant Roles | Specifies the roles that are participant plays |
Once the core tables are populated, you then are required to populate specific tables for each sharedo type.
This section describes both the core sharedo import tables together with the extension tables for each of the specific types.
Sharedo
Every sharedo to be loaded into the system requires an entry in the sharedo table.
| Attribute | Description |
| SharedoTypeSystemName |
Sharedo ships with a number of default types which can then be extended through configuration. All sharedo types can be seen through the Modeller UI where the system name can be seen
|
| PhaseSystemName |
In this column you specify the current phase of the sharedo. The valid phases for a sharedo can be found via the work type modeller – phase model screen
Upon import the sharedo will be created at this current phase. In you require a full history of its phase changes then you should also populate the Phase History table. |
| Category / Category Id |
Sharedo allows you to optionally specify the sub categorisation of a sharedo. Since not all sharedo types require a category you will need to determine if the sharedo type requires a category and if so what values it contains. You can see if the sharedo type is configured for a category by inspecting the category optionset field on ther work types basic settings Validation rule - must be valid for the category option as configured within config.sharedoTypes
The The |
| Title | The title of the sharedo that is shown to the user in lists and forms. |
| Description | The description or details of the sharedo that is shown to the user in the various details. |
| DerivePermissionsFromSoW | If this is set then permissions will be automatically set for the Reader and Contributor roles based on the SoW. |
Comments
Comments can be loaded against the majority of sharedo types subject to system configuration. To load a comment the import.comments table should be populated as follows.
| Attribute | Description |
|---|---|
| UserReference | ODS reference to the user who created this comment |
| Created | Date the comment was created |
| Comment | The textual comment itself |
| isPrivate | Whether this comment should be private and not exposed to external parties |
| sharedoReference | The sharedo the comments apply to |
Participants
The participants import table enables you to specify that a particular ODS entity (person, user or organisation) plays a particular role on your sharedo.
| Attribute | Description |
|---|---|
| OdsReference | This points to an ODS record indicating the person, organisation, user, team or vehicle that plays this role on the sharedo |
| ODSType | The type of ODS entity that plays this role - person, organisation, user, team or vehicle |
| participantRoleSystemName |
You can determine the valid participantRoleSystemNames for your work type by clicking on the Participant Roles tab on the work type modeller
Typically the minimum set of participant roles that should be created for a sharedo are specified by the Mandatory flag. Note: all sharedo’s should have a Creator participant specified. |
| customReference | Allows a reference to be set against the participant (maps to participant reference) |
| addressReference | When set, allows a specific address (from import.address) to be set as the location for this participant. |
Participants (Security Roles)
Sharedo also uses its participant model for the purposes of security. Depending upon configuration; participant roles can be assigned permissions including Read, Update on specific sharedo’s.
For the purposes of assigning security please following the guidance in the table below with respect to populating security roles
| Attribute | Description |
|---|---|
| OdsReference | This points to an ODS record indicating the user or team that can access this record. We strongly advise creating a small number of teams for security purposes e.g. “All Employees” or the like. |
| ODSType | The type of ODS entity that plays this role – user or team |
| participantRoleSystemName |
Although sharedo allows flexible configuration of security roles you should plan initially to populate a row for
Note: We typically recommend you associate these roles with ACL teams. |
NOTE: You should typically create 2 records for every sharedo e.g. Matters, Offers, Proceedings, Tasks etc
NOTE: This is not required when using the sharedo dataload flag of DerivePermissionsFromSoW
PARTICIPANT ROLE SPECIFIC ATTRIBUTES
In ShareDo it is possible to extend the information that is captured for participants via a set of extended attributes. These attributes are defined
- For a given role
- Contained within a form definition
To understand the aspect that are configure for a specific role
- go to the Participant Roles section of the modeller
- Open a Role’s aspect settings
- Make note of the form definition and thefield name
To load participant role attributes you must populate the following table
| Attribute | Description |
|---|---|
| participantReference | Foreign key to the main participant role import record |
| formDefinition |
The name of the form that has been defined for this participant. The available form definitions within the system are determined by running the query above. |
| fieldname | The relevant field name for the attribute should be specified by running the query above. |
| fieldValue | In this field you specify the field value. |
Participant Role Injury Attributes
Sharedo has an extensible model for capturing participant injuries.
To load participant injury attributes you must populate the following table.
| Attribute | Description |
|---|---|
| participantReference | Foreign key to the main participant role import record |
| hasBodilyInjury | Y/n as to whether the participant was injured |
| bodilyInjuryAdditionalDetails | A free text field to specify bodily injuries |
Not Supported
Note: at this time we do not support the specification of injury hierarchies in the dataload schema
| injuryHierarchy1 | Enables you to specify a hierarchy of injury codes using “/” as a separator |
| injuryHierarchy1Notes | Enables you to specify notes for an injury hierarchy |
| injuryHierarchy2 | Enables you to specify a hierarchy of injury codes using “/” as a separator |
| injuryHierarchy2Notes | Enables you to specify notes for an injury hierarchy |
Key Dates
Key dates represent specific milestones on a case and are used extensively for sharedo’s of type case and proceedings. Other sharedo types such as invoice, offer and instruction also make use of keydates.
To create key dates the following table should be populated.
| Attribute | Description |
|---|---|
| keyDateType |
Key date types are defined as sharedo’s. The list of defined key dates can be identified via the work type modeller as being descendants of Key date.
|
| keyDate | The date of the sharedo, expressed in the correct timezone. For example, a UK summertime date should be presented as UTC accounting for the one hour offset from local time. Presentation of a date in local time is a UI concern. |
| keyDateStatusCode |
Key dates can be marked as milestone-planned (this key date is in the future), milestone-missed (key date complete but outside of milestone), milestone-done (key date completed within the milestone) Note: these statuses relate to the phase plan system names for the key date work type. |
Permissions for keydates are usually set post-load; depending on client requirements they can be set with a simple permission profile or more complex depending on business needs (see ETL consultant for guidance).
Phase History
Sharedo’s can be fully specified using the PhaseSystemName column in the sharedo import schema if required.
You can also, optionally, specify the phases that a sharedo has moved through during its lifecycle. This is typically used for reporting purposes.
| Attribute | Description |
|---|---|
| fromPhaseSystemName |
The starting phase for your sharedo. You can see the applicable phases for your work type via the phase model UI
|
| toPhaseSystemName | The phase that was transition to |
| transitionDateTime | Date transition happened |
| userRef | The user who affected to the change |
| description | Any description associated with the phase change |
| transitionReason | Any reason captured for the change |
| sharedoReference | The sharedo this phase history is against |
Smart Plan Event Triggers
Note: this feature is in ALPHA.
In order to affect specific event processing the sharedo migration schema allows you to specify specific event triggers that can be raised in order to trigger specific SmartPlan processing.
| Attribute | Description |
|---|---|
| eventSystemName | The smart plan subscription event that is to be raised |
| eventPayload | The JSON event payload that may or may not be required to affect the processing of the workflow |
Time Recording
Time recording entries are recorded against tasks rather than cases.
You can see if a sharedo type has time recording enabled for it by looking at the allowsTimeEntry flag on the sharedoTypes table.
Time entries should be loaded into the import.timeentries table as follows.
| Name | Type | Not Null | Notes |
|---|---|---|---|
| userRef | Nvarchar | True | The user who logged the time entry |
| paricipantReference | Nvarchar | True |
The participant role reference the user was assigned to “participantReference” is used to provide the participant role reference of the user on this specific matter/task, for when time code classification matching rules check this. It’s currently mandatory in the data load process, but is only used during processing if the time classification business rules require it to be checked. If the time classification business rules don’t require it, then any participant role reference can be provided, and the time entry will successfully load and display within ShareDo. For example, when a user needs time migrating against a task/matter, but they don’t have a participant role on said task/matter. |
| StartTime | Datetime | True | The start of time recording |
| EndTime | Datetime | False | The end of the time recording |
| durationInSeconds | Int | False | The time in seconds being recorded |
| Notes | Nvarchar | False | Any notes about the time recording |
| Submitted | Bit | False | Has this time recording been submitted |
| createTaskInLineFlag | Bit | True | If this is set to true then the following fields are used to create a task in-line. If this isn’t set to true then sharedoReference should be set and should be a valid type that supports time recoring. |
| Fields required when createTaskInLineFlag=FALSE | |||
| sharedoReference | Nvarchar | True | The parent sharedo that this time is being recorded against |
| Fields required when createTaskInLineFlag=TRUE | |||
| parentSharedoReference | Nvarchar | False | The parent sharedo that this time is being recorded against; typically a case |
| taskSystemName | Nvarchar | False | The type of task that should be created |
| taskTitle | Nvarchar | False | The title of the task |
| taskDescription | Nvarchar | False | The description of the task |
| taskPhaseSystemName | Nvarchar | False | In this column you specify the current phase of the sharedo. For time recording this will typically be a closed state. |
| taskCategoryId | Sharedo allows you to optionally specify the sub categorisation of a sharedo | ||
NOTE: When creating tasks in-line unless your system has dedicated information we recommend the following values.
| Attribute | Notes |
|---|---|
| taskTitle | “Quick Activity” |
| taskDescription | “Data Migration” |
| taskSystemName | task-activity-quick-time |
| taskPhaseSystemName | Done |
NOTE: the userRef will become the primary owner of the task.
Reserves / Heads Of Loss
Reserves or heads of losses are typically specified for dispute or PI cases where they record the financial exposure for a case. These are imported via the import.reserves table.
| Attribute | Description |
|---|---|
| reserveTypeCode |
In sharedo reserve type codes can be specialised by sharedo (case) type. To determine a valid list of reserve type codes you should (i) Review the budget structures configured for this type (ii) Inspect the configured account codes |
| reserveAmount | Amount of the reserve |
| createdDate | When the reserve was created. To reflect an initial and current reserve amount is required the earliest createdDate will form the initial and subsequent reserves will be tracked as changes |
| userReference | Who created the reserve (can use the user dataQualitySetup if required) |
| reserveReason | Required (although can be optional in the UI) |
| accountSystemName | |
| opponentAmount | |
| settledAmount | Amount that was settled |
| settledAmountVAT | Amount that was settled |
Note: Reserves act as a debit and credit system and hence it is possible to either
- Import reserve balances
- OR import reserve movements
Settlements
In sharedo settlements are stored in the following places
- Settlement Agreement – this records the settlement outcome for a set of accounts e.g. Damages or Costs
- Settlement Amounts – these record the actual amounts for settlement.
The table import.settlements should be populated as follows.
| Attribute | Description |
|---|---|
| AccountSystemName |
Settlements can be recorded for different accounts e.g. Judicial or Costs. The types of accounts supported in the system can be viewed by reviewing the settlement configuration |
| Outcome | This is the outcome of the settlement – valid values for outcomes can be determined by reviewing the settlement config |
| agreementDate | Date the account was settled |
In addition to specifying the settled amount, the reserves/ heads of loss import table can be populated as follows.
| Attribute | Description |
|---|---|
| reserveTypeCode | See above |
| settlementAmount | Amount that was settled |
| settlementAmountVAT | Amount that was settled |
| createdDate | When the reserve was created |
| userReference | Who created the reserve (can use the user dataQualitySetup if required) |
| reserveReason | Required (although can be optional in the UI) |
ShareDo Relationships
Sharedo manages the relationships between the different sharedo types via a relationships table. Examples of key relationships include:
- Cases are related to statements of work
- Offers are related to Cases
- Tasks are related to Cases
- Proceedings are related to Cases
To create a relationship the import.sharedorelationships table should be populated as follows.
| Name | Notes |
|---|---|
| leftSharedoReference | Parent sharedo of the relationship |
| rightSharedoRelationship | of the relationship |
| sharedoRelationshipTypeSystemName |
The type of relationship. You can determine the allowable relationship types in the modeler screen
When migrating data you should typically use the following relationship types
|
Often when importing data into sharedo you will want to relate an imported sharedo to some existing data. For example you may want to import a new matter against an existing statement of work.
Tasks
Creating a task involves the population of many of the tables above; when doing so please consider some of the following guidance for the population of each table.
| Table | Guidance |
|---|---|
| Sharedo |
Every task should have an entry in the sharedo import table. Typically task migrations will use the following system types
|
| Comments | Comments are not mandatory for tasks |
| Participants |
A task should always have the following participant roles defined - Primary-Owner – who the task belongs to |
| Key dates | Out of the box tasks do not use key dates and hence this table should typically not be populated. |
| Phase History | If you require visibility of how long tasks take to complete then this table should be populated. |
| Time Recording | Time recording entries should typically always be associated with tasks |
| Sharedo Relationships | Within the system the majority of tasks should be associated with thecase sharedo however you do not need to use this and can instead use the column parentSharedoReference |
In addition to populating the core tables the import.task table should also be populated with the following information.
| Attribute | Description |
| parentSharedoReference |
If the task is to be related to a case then this is the case Reference. However, it should be noted that tasks may also be related to
NOTE: You do not have to populate the sharedo relationships table for tasks instead you can relate a task to its parent case, offer etc through the parentSharedoReference. |
| dueDateTime | When this task is due |
Offers
Creating an offer involves the population of many of the tables above; when doing so please consider some of the following guidance for the population of each table.
| Table | Guidance |
|---|---|
| Sharedo |
Every offer should have an entry in the sharedo import table. The systemName for offers can be determined via the work type modeller In addition the sharedo category should be populated with appropriate values to determine the type of offer. For clarity, ETL set the category column, enrichments populate the categoryId column. |
| Comments | Comments are not mandatory for offers |
| Participants |
An offer should have the following participant roles defined
You can query the system names for offer roles via the modeller UI |
| Key dates |
Offers rely on the following key dates being populated
|
| Phase History | If you require visibility of how long offers take to process then this table should be populated. Note: an offers acceptance is also denoted via the phases. |
| Sharedo Relationships | Offers must be associated with cases however you do not need to use the relationships table but instead can populate the column parentSharedoReference |
In addition to populating the core tables the import.offers table should also be populated with the following information.
| Attribute | Description |
| rationale | Free text. |
Together with the key information for the offer the financial details of the offer should also be populated, indeed this is mandatory. This is performed via the import.offerAmounts table
| Attribute | Description |
|---|---|
| reserveTypeCode | In sharedo reserve type codes can be specialised by case type. |
| amount | Amount of the offer |
It should be noted that there is validation within the application UI to check that an offer is supported by an appropriate heads of loss amount and hence you should ensure that any offer is supported by a reserve balance.
Case / Matter
Creating a case involves the population of many of the tables above; when doing so please consider some of the following guidance for the population of each table.
| Table | Guidance |
|---|---|
| Sharedo | Every matter should have an entry in the sharedo import table. |
| Comments | Comments are not mandatory for matters but this is typically where most comments should reside |
| Participants |
A matter should always have the following participant roles defined
|
| Key dates | Matters make extensive use of key dates and these should be populated. |
| Phase History | If you require visibility of the lifecycle for a matter then this table should be populated. |
| Time Recording | Time recording entries should not be populated |
In addition to populating the core tables the import.matter table should also be populated with the following information – this holds the top level information about the case.
| Attribute | TYPE | Description |
|---|---|---|
| jurisdictionCode | Text | Jurisdiction that this case is being performed under as specified in the optionset - jurisdictions |
| clientSoWReference | Text |
Reference for the client of the statement of work – this can be used instead of creating a relationship. You can determine the references for valid statements of work within the system by view these from your workbenches contract view
You can determine if a statement of work is valid for the case work type by inspecting its work type inception rules
|
| feeTemplateSystemName | Text |
The Fee Structure template that is to be used for this sharedo type. System will validate the Template name against the templates defined in config.feeTemplates. |
| clientOdsReference | Text | The ods reference of the associated client (organisation)that matches on the SoW selection rules. If not known can be the default org. |
Instruction
Creating an instruction involves the population of many of the tables above; when doing so please consider some of the following guidance for the population of each table.
| Table | Guidance |
|---|---|
| Sharedo |
Every instruction should have an entry in the sharedo import table. If an instruction has created a case then you should ensure that the instruction is in a closed state. |
| Comments | Comments are not mandatory for instructions |
| Participants |
An instruction should always have the following participant roles defined
|
| Key dates | Instructions make extensive use of key dates although these are also, typically, copied across to a case. If key dates change over time then the original key date should be specified on the instruction. |
| Phase History | If you require visibility of the lifecycle for an instruction then this table should be populated. |
| Time Recording | Time recording entries should not be populated |
| Sharedo Relationships | This is the link to (usually) the matter; is required. Use the relationship types of parent-child and/or linked-case depending on requirements. |
In addition to populating the core tables the import.instruction table should also be populated with the following information.
| Attribute | Description |
|---|---|
| sourceOfBusiness | How the instruction was received; this is specified in the optionset b2c-referral-sources |
| jurisdiction | Jurisdiction that this case is being performed under as specified in the optionset - jurisdictions |
| caseWorkType | The category of the case sharedo type |
| caseSharedoTypeSystemName | The case type that this instruction is designed to create |
Payment Requests
Creating a payment involves the population of many of the tables above; when doing so please consider some of the following guidance for the population of each table.
| Table | Guidance |
|---|---|
| Sharedo |
Every payment should have an entry in the sharedo import table. If the Payment requires a sub type (category) this should also be populated |
| Comments | Comments are not mandatory for payments |
| Participants |
A payment should always have the following participant roles defined
|
| Key dates | Key dates are not used for payments |
| Phase History | If you require visibility of the lifecycle for a payment then this table should be populated. |
| Time Recording | Time recording entries should generally not be populated |
In addition to populating the core tables the import.payments table should also be populated with the following information.
| Attribute | Description |
|---|---|
| paymentTypeCode | Payment Method e.g. BACS cheque etc, optional. |
| dateOfPayment | Date the payment was made – this should correlate with the phase history, optional |
| paymentDetails | Details regarding the payment |
| parentSharedoReference | The parent reference –generally this is the reference of the case |
In addition to specify the top level payment details you also need to specify the payment transactions in the table import.paymentRequestAmounts
| Attribute | Description |
|---|---|
| sharedoReference | The Payment Request sharedo that these transactions belong to |
| reserveTypeCode |
In sharedo reserve type codes can be specialised by case type. To determine a valid list of reserve type codes you should inspect the payment account configuration. |
| Amount | Amount of the payment – must be positive |
| reserveReason | The is a free text description field |
The following tables are populated by this loader, other tables (e.g. participants) are not detailed here.
| Table | Description |
|---|---|
| core.sharedos | Holds the sharedo details of the payment |
| core.sharedoRelationships | Places the payment into the relationship graph, typically a payments parent is a case, so a row with descendant depth 4 is typical. |
| legal.paymentRequests | Primary table holding payment information; shares primary key with core.sharedos |
| legal.paymentRequestsTransactions | One row per payment amount (as taken from import. paymentRequestAmounts) |
| legal.paymentRequestPurchaseOrder | One row per payment, population matches user interaction with the payments feature (blade and widget listing payments). |
Invoice
Creating an invoice involves the population of many of the tables above; when doing so please consider some of the following guidance for the population of each table
| Table | Guidance |
|---|---|
| Sharedo |
Every invoice should have an entry in the sharedo import table. If the invoice requires a sub type (category) this should also be populated |
| Comments | Comments are not mandatory for payments |
| Participants |
An invoice should always have the following participant roles defined
|
| Key dates | This keydates will match the configuration in config.keydateAssociations, but is likely to be of the type ‘invoice-payment-due’ |
| Phase History | If you require visibility of the lifecycle for an invoicethen this table should be populated. |
| Time Recording | Time recording entries should generally not be populated |
In addition to populating the core tables the import.invoices table should also be populated with the following information.
| Attribute | Description |
|---|---|
| paymentTypeCode | Payment Method e.g. BACS cheque etc, optional. |
| dateOfPayment | Date the invoice was made – this should correlate with the phase history, optional |
| parentSharedoReference | The parent reference – generally this is the reference of the case |
| details | Text description |
| invoiceIssuedDate | The date the invoice was issued |
| createdDate | The date the invoice was created |
In addition to specify the top level invoice details you also need to specify the transaction items in the table import.invoiceTransactionItems
| Attribute | Description |
|---|---|
| sharedoReference | The invoice request sharedo that these transactions belong to |
| reserveTypeCode |
In sharedo reserve type codes can be specialised by case type. To determine a valid list of reserve type codes you should inspect the payment account configuration. |
| amount | Amount of the invoice item – must be positive |
| vat | The vat amount, may be zero |
| description | |
| quantity | May be null |
| unitOfMeasure | May be null |
| taxRate | May be null |
| creditAccountCodes | May be null |
| currency | May be null |
| status | Not null |
| transactionItemType | Must match legalConfig.transactionItemTypes |
In addition to specify the top level invoice details you could also provide receipt items in the table import.invoiceReceiptItems
| Attribute | Description |
|---|---|
| sharedoReference | The invoice request sharedo that these transactions belong to |
| reserveTypeCode |
In sharedo reserve type codes can be specialised by case type. To determine a valid list of reserve type codes you should inspect the account configuration. |
| amount | Amount of the payment – must be positive |
| receiptDate | Required |
| paymentMethod | Option set list |
The following tables are populated by this loader, other tables (e.g. participants) are not detailed here.
| Table | Description |
|---|---|
| core.sharedos | Holds the sharedo details of the payment |
| core.sharedoRelationships | Places the payment into the relationship graph, typically a payments parent is a case, so a row with descendant depth 4 is typical. |
| legal.invoices | Primary table holding payment information; shares primary key with core.sharedos |
| legal.invoiceTransactionItems | One row per payment amount (as taken from import. paymentRequestAmounts) |
| legal.invoiceReceipts | One row per payment, population matches user interaction with the payments feature (blade and widget listing payments). |
Proceedings
Creating a proceeding involves the population of many of the tables above; when doing so please consider some of the following guidance for the population of each table
| Table | Guidance |
|---|---|
| Sharedo | Every proceeding should have an entry in the sharedo import table. |
| Comments | Comments are not mandatory for proceedings but can be used if required |
| Participants |
A proceeding should always have the following participant roles defined
In addition it is recommended that any participants which are required on the proceedings are also created there. These typically include
|
| Key dates | Proceedings make extensive use of key dates and these should be populated. |
| Phase History | If you require visibility of the lifecycle for a case then this table should be populated. |
| Time Recording | Time recording entries should not be populated |
| Sharedo Relationships | Proceedings must be associated with cases although this can also be specified via the parentSharedoReference field (not via the import.proceeding.parentSharedoRefernce as this is a legacy field) |
In addition to populating the core tables the import.proceedings table should also be populated with the following information.
| Attribute | Description |
|---|---|
| courtCaseReference | Court Case reference |
| CourtTrack |
The valid courts for a Litigation Type (sharedo type of the proceeding) can be seen in the Litigation feature configuration
|
| Jurisdiction | The valid jurisdictions for a Litigation Type can also be seen in the screen above |
| LitigationReason | The valid litigation reasons can be queried via the'litigation-reasons'optionset |
Scorecards
Score cards are used to capture a score value against several metrics. These metrics are then aggregated into a score card and an overall score can be displayed. The import.scorecard table in the import database is used to import this data.
| Attribute | Description |
|---|---|
| sharedoReference | The sharedo this scorecard relates to. For example if this is a case scorecard this would be the case reference. |
| templateId |
The id of the template this score value is attached to. A list of these templates can be found using the following query. SELECT* FROM [config].[scorecardTemplates] |
| metricId |
The id of the metric this score value is recorded against. For a list of metrics available on the desired scorecard use the following query. SELECT* FROM [config].[scorecardTemplates] innerjoin [config].[scorecardMetricTemplates] on [scorecardTemplates].id = [scorecardMetricTemplates].scorecardTemplateId innerjoinconfig.scorecardMetricsonscorecardMetricId= scorecardMetrics.id where scorecardTemplates.id =‘your scorecard template id’ |
| scoreValue |
The integer value for the score. To see what the corresponding scores label is you can use the following query. SELECT * FROM [config].[scorecardMetricLabels] wherescorecardMetricId='your metric id' |
| ScoreCreatedDate | The date the score was added to the system. Note you can add multiple scores for the same metric with different dates. The loader will treat the most recent as the current score and any others as historical values. |
| Reference | The unique reference for this metric value, this is only used to select the correct record and report any errors during the import process |
Liability
Import Table Structure and Population
Liability is used to capture a liability position against a case. To populate liability please specify the following information:
| Attribute | TYPE/ REQUIRED | Description |
|---|---|---|
| reference | String / yes | Unique row reference, not used elsewhere |
| sharedoReference | Guid / yes | The sharedo this liability assessment applies to. This will typically be a case. |
| isOurPosition | Bit / no | |
| participantTakingPositionOnOdsReference | String / no | |
| positionTakenOnParticipantOdsReference | String / yes | |
| positionDate | Date / no | |
| liabilityPosition | Int / no | Describes the decision for liability. Valid values are in the optionsetliable-decisions |
| decisionDate | Date / no | Date the liability decision was made. |
| liabilityRationale | String / no | Associated commentary text |
| liabilityContrib | Decimal / no |
Notes
It is valid to provide multiple rows of liability per case.
Fees
In sharedo fees can in theory be attached to any sharedo although in practice they are only usually attached to case or statements of work.
Typically a fee structure will be
- Created based on a template – in this case it is not overridden
- Can include updates to that template.
In day to day running this hierarchy is also used to “copy down” fee structures from SoW to cases.
This however is cumbersome for data migration and hence we allow the creation of a fee structure at different levels in the hierarchy through the import tables.
Note: data load does not support the upload of templates.
Fee Structures
The first step to creating a fee structure in sharedo is to reference the template that is used. This is done through the following attribute that is present on the Matters (case) and Statement of work import tables.
| Attribute | TYPE/ REQUIRED | Description |
|---|---|---|
| feeTemplateSystemName | Text |
The Fee Structure template that is to be used for this sharedo type. System will validate the Template name against the templates defined in Admin / Finance / Fee Templates. |
Fee Structure Sections
If a case is to use a template without any changes then there is no need to populate either this table or the FEE STRUCTURE ELEMENTS table. However, if you want to override the template with case specific section values then these will be populated and the Fee Structure will have its version incremented accordingly.
The following information can be imported for Fee Structure Sections.
| Attribute | TYPE/ REQUIRED | Description |
|---|---|---|
| sharedoReference | Guid / yes | The sharedo this fee structure applies to. This will typically be a case. |
| feeStructureSectionSystemName | Text |
The Fee Structure section that is to be varied for this sharedo. Valid sections for a template are defined in config.feeTemplateSections.feeSectionSystemName System will validate that the - System name is a valid section - That the section is valid for the specified template |
| InclusiveOfVAT | Bit | Specifies whether this section is inclusive of VAT or not |
| userSpecifiedMinAmount | Decimal | Specifies the minimum fee amount. |
| userSpecifiedMaxAmount | Decimal/ no | Specifies the maximum fee amount. |
| guaranteedNoWorseOff | Decimal | Specifies the minimum amount the third party will receive after fees have been deducted. |
| guaranteedRingFenced | decimal | Specifies the minimum amount the third party will receive after fees have been deducted. |
| specialInstructions | Text | Free text field to provide specific instructions relating to the allocation of fees within this section. |
Note: If the values in this table differs from the template values then a new version will be created and approved automatically.
Fee Structure Elements
If a case is to use a template without any changes then there is no need to populate either this table or the FEE STRUCTURE SECTIONS table. However, if you want to override the template with case specific values then this template should be populated.
The following information can be imported for Fee Structure Elements.
| Attribute | TYPE/ REQUIRED | Description |
|---|---|---|
| sharedoReference | Guid / yes | The sharedo this fee structure applies to. This will typically be a case. |
| feeElementSystemName | Text |
Unique identifier for a fee element within a template. System validates
|
| estimatedFeeAmount | Decimal |
Specifies the estimate fee amount System validates
|
| estimateFeePct | Decimal |
Specifies the fee percentage for conditional types System validates
|
| tieredLowerThreshold | Decimal |
Specifies the lower threshold for tiered fees System validates
|
| tieredUpperThreshold | Decimal |
Specifies the upper threshold for tiered fees System validates
|
| actualFeeAmount | Decimal |
Specifies the actual fee amount System validates Element type is a fixed one |
| actualHours | Decimal | Specifies the actual number of hours billed from the Role and Hourly Rate. |
| actualRecognitionDate | Datetime | Specifies the recognition date. |
| hourlyRoleSystemName | Text |
Specifies the Participant Role system name to apply rates and hours against System validates Element is an hourly one |
| hourlyRate | Decimal |
Specifies the rate for hourly elements System validates
|
| hourlyMinHours | Decimal |
Specifies the minimum estimated hours for hourly System validates
|
| hourlyMaxHours | Decimal |
Specifies the minimum estimated hours System validates
|
Note: the import table above flattens the following core schema tables
- Core.feeStructureElementConditionalTiered
- Core.feeStructureElementFixed
- Core.feeStructureElementFixedTiered
- Core.feeStructureElementHourly
Statement Of Works
In sharedo statements of work are used to define the operating parameters for groups of cases including
- Their fee structures
- Their matching rules i.e. what
- Can include updates to that template.
Creating a statement of work involves the population of many of the tables above; when doing so please consider some of the following guidance for the population of each table
| Table | Guidance |
|---|---|
| Sharedo |
Every statement of work should have an entry in the sharedo import table. It should typically reference a type such as B2C Product or B2B Client. |
| Participants |
A statement of work should typically have the following participant roles defined
|
| Phase History | If you require visibility of the lifecycle for a statement of workthen this table should be populated. |
In addition to populating the core tables the import.StatementOfWork table should also be populated with the following information.
| Attribute | TYPE | Description |
|---|---|---|
| parentContractReference | Text |
Reference for the overarching contract – this can be used instead of creating a relationship. You can determine the references for valid contracts within the system by viewing the contract listing from your workbench
|
| feeTemplateSystemName | Text |
Optional; the Fee Structure template that is to be used for this sharedo type. If provided, the system will validate the Template name against the templates defined in config.feeTemplates. |
| matchingSharedoTypeSystemNamesCoverage | Text |
Specifies the work types and sub types that this statement of work covers. The loader can specify many work types separated by “,”. If sub types are also to be specified then they should be separated via a ~ e.g.matter-pi~Birth Injury;matter-clin-neg~subtype System validates
|
| matchingDateStart | DateTime |
Start date for matching of instructions System validates
|
| matchingDateEnd | DateTime |
End date for matching of instructions System validates
|
| matchingKeyDateSystemName | Text |
Specifies upon which date the SoW should be matched The user should specify a valid key date system name. System validate
|
| matchingParticipantRoleSystemNameSoW | Text |
Specifies the roles to be matched on the SOW System validates
|
| matchingParticipantRoleSystemNameInstruction | Text |
Specifies the roles to be matched on the Instruction System validates
|
| matchingBusinessSource | Text |
Specifies the business sources to be matched. User can specify multiple business sources separated by a “;” System validates
|
