Skip to content

Rat Occurrence Rules

michaelrangstrup edited this page May 3, 2024 · 49 revisions

Various rules have been added over the years to ensure that Rat Occurrence data is dependable and uniform. This page lists the validations that you may encounter when working with Rat Occurrence records.

Transform Rules

R1 and R2 Authorization

  • We will ignore any value specified for exterminationCompany and instead automatically set it to the logged in user's extermination company as identified from his access token.
  • WHEN logged in user is from Extermination Company THEN
    • Any value supplied for exterminationPerformedBy Attribute will be ignored and the value will automatically be set to the context type of Extermination Company using the method. I.e. it will automatically be set to either Privat bekæmpelse (R1-autorisation) when logged in user is from R1 Extermination Company or Privat bekæmpelse (R2-autorisation) when user is R2 Exterminator.
  • InjunctionTypes added is ignored if any
  • When AuthorizationNumber is null or empty, THEN the value is automatically set to AuthorizationNumber of the logged in user

R2 Authorization

  • ExterminationPerformedBy is automatically set to Privat bekæmpelse (R2-autorisation)

  • When animal='Rat' AND completedDate<>null THEN

    • isSmokeTestPerformed is automatically set to FALSE
    • noSmokeTestReason is automatically set to '9' ("Andet"/"Other")
  • When animal='Rat' AND completedDate<>null THEN

    • isResidentsInformed is automatically set to TRUE
  • When animal='Rat' AND completedDate<>null THEN

    • isExterminationPerformed is automatically set to TRUE

Authorization Rules

Municipalities can create, update and delete rat occurrences within their own borders. R1 Extermination Companies and R2 Exterminators can only create, update, and delete rat occurrences where they are registered as exterminationCompany.

Municipality Users Creating, Updating and Deleting Rat Occurrences

WHEN a logged in municipality user is creating a rat occurrence THEN

  • If the property of the new rat occurrence after create will be located in a different municipality (as found by DAWA) than the logged in municipality user, then an error is thrown.
    • DK error message: "Du har kun oprette poster for ejendomme i din egen kommune. Din myndighed er {loggedInUserMunicipality}. Du forsøger at oprette en post med ejendom der ligger i {newRatOccurrenceMunicipality}."
    • EN error message: "You only have the right to create records for properties in your own municipality. Your authority is {loggedInUserMunicipality}. You are trying to create a record in {newRatOccurrenceMunicipality}."

WHEN a logged in municipality user is updating a rat occurrence THEN

  • If the property of an existing rat occurrence before update was located in a different municipality than the logged in municipality user, then an error is thrown.
    • DK error message: "Du forsøger at opdatere ejendom til en anden kommune end din som er {loggedInUserMunicipality}. Du forsøger at opdatere en ejendom der ligger i {ratOccurrenceBeingUpdatedMunicipality}."
    • EN error message: "You only have the right to update properties in your own municipality. Your authority is {loggedInUserMunicipality}. You are trying to update a record in {ratOccurrenceBeingUpdatedMunicipality}."
  • If the property of an existing rat occurrence after update will be located in a different municipality than the logged in municipality user, then an error is thrown.
    • DK error message: "Du har kun ret til at opdatere ejendomme i din egen kommune. Din myndighed er {loggedInUserMunicipality}. Du forsøger at opdatere en ejendom der tilhører {ratOccurrenceBeingUpdatedMunicipality}."
    • EN error message: "You are trying to update a record to belong to a different municipality than yours which is {loggedInUserMunicipality}. You are trying to update a record in {ratOccurrenceBeingUpdatedMunicipality}."

WHEN a logged in municipality user is deleting a rat occurrence THEN

  • If the occurrence being deleted is located in a different municipality than the logged in municipality user, then an error is thrown.
    • DK error message: "Du forsøger at slette en post der ikke tilhører din kommune {loggedInUserMunicipality}. Posten du forsøger at slette ligger i {ratOccurrenceBeingUpdatedMunicipality}."
    • EN error message: "You are trying to delete a record that does not belong to your municipality {loggedInUserMunicipality}. The record you are trying to delete is located in {ratOccurrenceBeingUpdatedMunicipality}."

Extermination Company Users Creating, Updating and Deleting Rat Occurrences

WHEN a logged in extermination company user (both R1 and R2) is updating a rat occurrence THEN

  • If the extermination company registered on the rat occurrence before update was from a different extermination company than the logged in extermination company user, then an error is thrown.
    • DK error message: "Du forsøger at opdatere en rotteanmeldelser der ikke tilhører dit firma {loggedInUserExterminationCompany}."
    • EN error message: "You are trying to update a rat occurrence that does not belong to your company {loggedInUserExterminationCompany}."

WHEN a logged in extermination company user is deleting a rat occurrence THEN

  • If the occurrence being deleted belongs to a different extermination company than the logged in extermination company user, then an error is thrown.
    • DK error message: "Du forsøger at slette en rotteanmeldelser der ikke tilhører dit firma {loggedInUserExterminationCompany}."
    • EN error message: "You are trying to delete a rat occurrence that does not belong to your company {loggedInUserExterminationCompany}."

Remarks

Municipality users should not be able to edit exterminatorRemarks and R1 and R2 Exterminators should not be able to view or edit municipalityRemarks.

  • If R1 and R2 Exterminators add values for the municipalityRemarks attribute, these will be ignored on create/update of Rat Occurrence. Whatever the value was before update will be kept as before.
  • If a Municipality User adds value for the exterminatorRemarks attribute, these will be ignored on create/update of Rat Occurrence. Whatever the value was before update will be kept as before.

Status Rules

Yearly submission

You cannot update rat occurrences with notifiedDate inside years where the contact Municipality has already closed (officially submitted) the year in question.

Update using ID of Deleted Rat Occurrence Records

When you initially commit a Rat Occurrence via the REST service, you will in the response be given an ID. You must save this ID in your own system so that when you wish to update the Rat Occurrence, you can do this using this identifier. This is important in order to avoid duplication issues as specified later.

If the user tries to update Rat Occurrence using an ID that belongs to a deleted record, he will be shown the following error:

  • DK error message: "Id '{Id}' hører til en slettet rotteanmeldelse og kan derfor ikke opdateres"
  • EN error message: "Id '{Id}' belongs to a deleted rat occurrence and can therefore not be updated"

If the user tries to update Rat Occurrence using an ID that does not exist, he will be shown the following error:

  • DK error message: "Det Id du har brugt '{Id}' findes ikke i systemet"
  • EN error message: "The Id you have used '{Id}' does not exist in the system"

Delete using ID of Deleted Rat Occurrence Records

When you initially commit a Rat Occurrence via the REST service, you will in the response be given an ID. You must save this ID in your own system so that when you wish to delete the Rat Occurrence, you can do this using this identifier.

If the user tries to delete a Rat Occurrence using an ID that belongs to a deleted record, he will be shown the following error:

  • DK error message: "Id '{Id}' hører til en slettet rotteanmeldelse og kan derfor ikke slettes igen"
  • EN error message: "Id '{Id}' belongs to a deleted rat occurrence and can therefore not be deleted again"

If the user tries to delete a Rat Occurrence using an ID that does not exist, he will be shown the following error:

  • DK error message: "Det Id du har brugt '{Id}' findes ikke i systemet"
  • EN error message: "The Id you have used '{Id}' does not exist in the system"

Editing or Deleting Handed Over Rat Occurrences

When a rat occurrence is handed over from an R2 Exterrminator to a municipality or R1 Extermination Company, it is no longer possible to edit or delete the original rat occurrence.

  • If a rat occurrence has a parent and user tries to edit it then throw error message
    • DK error message: "Denne rotteanmeldelse er blevet overtaget af en anden ansvarlig og kan derfor ikke længere redigeres."
    • DK error message: "This rat occurrence has been handed over to another responsible entity and can therefore no longer be edited."
  • If a rat occurrence has a parent and user tries to delete it then throw error message
    • DK error message: "Denne rotteanmeldelse er blevet overtaget af en anden ansvarlig og kan derfor ikke længere slettes."
    • DK error message: "This rat occurrence has been handed over to another responsible entity and can therefore no longer be deleted."

Rat Occurrence Duplication Rules

Setting Coordinates of a Rat Occurrence

In most cases, you will not have to worry about setting coordinates for a Rat Occurrence. As long as you specify valid address information, then the Rotte system will use these to look up the coordinates of the property using DAWA's official API. The Rotte System will make sure to attach these coordinates as both the location of the property and the coordinate of the Rat Occurrence. On larger properties, the Rat Occurrence may be far from the property's coordinates as known in DAWA and in this case you may want to supply an exact x and y coordinate to replace the one found by DAWA. Doing this will be important if you need to work on multiple open Rat Occurrence records on the same property at the same time, as you will understand from the validations described below.

Exact Date and Address Rat Occurrence Duplicates

You cannot create more than one Rat Occurrence on the same address on the same date when it was performed by the same R1 Extermination Company or R2 Exterminator at the same coordinate on the Property. Same address is in the system interpreted as the same streetName, houseNumber and zipCode. So generally, two apartments in the same building is interpreted as the same address. Same coordinate is interpreted as the same {position.x} and {position.y} of the rat occurrence record.

If you are indeed handling two separate Rat Occurrences on the same address, which fx can happen on large properties like airports and industrial sites, you will need to register separate coordinates for the separate instances.

Error message when trying to create a date and address rat occurrence duplicate:

  • DK error message: "Følgende rotteanmeldelser lader til at være et duplikat af den du forsøger at oprette:'{Id of duplicate}'"
  • EN error message: "The following rat occurrence seems to be a duplicate of the one you are trying to create:'{Id of duplicate}'"

Overlapping Date and Address Rat Occurrence Duplicates

You cannot create more than one Rat Occurrence on the same address, performed by the same R1 Extermination Company or R2 Exterminator, and at the same coordinate on the Property when the notifiedDate of one Rat Occurrence is placed within the notifiedDate and completedDate of the other Rat Occurrence. Same address is in the system interpreted as the same streetName, houseNumber and zipCode. So generally, two apartments in the same building is interpreted as the same address. Same coordinate is interpreted as the same {position.x} and {position.y} of the rat occurrence record.

Error message when trying to create a overlapping date and address rat occurrence duplicate:

  • DK error message: "Følgende rotteanmeldelser lader til at være i samme tidsrum som en anden rotteanmeldelse på samme adresse:'{Id of duplicate}'"
  • EN error message: "The following rat occurrence seems to be in the same time period as another rat occurrence on the same address:'{Id of duplicate}'"

Date and Address Newer Incomplete Rat Occurrence Duplicates

You cannot create a Rat Occurrence when there is another incomplete (no completed date) Rat Occurrence on the same address, on the same date, performed by the same R1 Extermination Company or R2 Exterminator, and on the same coordinate on the Property. Same address is in the system interpreted as the same streetName, houseNumber and zipCode. So generally, two apartments in the same building is interpreted as the same address. Same coordinate is interpreted as the same {position.x} and {position.y} of the rat occurrence record.

Error message when trying to create a date and address newer incomplete rat occurrence duplicate:

  • DK error message: "Du kan ikke lave en ny anmeldelse da følgende anmeldelse på samme adresse er ikke afsluttet:'{Id of incomplete duplicate}'"
  • EN error message: "You cannot create a new rat occurrence as the following rat occurrence on the same address has not been completed:'{Id of incomplete duplicate}'"

Date and Address Older Incomplete Rat Occurrence Duplicates

You cannot create an incomplete Rat Occurrence record (without a completion date), when there is a another complete (with completed date) Rat Occurrence on the same address, with a later notified date, performed by the same R1 Extermination Company or R2 Exterminator, and on the same coordinate on the Property. Same address is in the system interpreted as the same streetName, houseNumber and zipCode. So generally, two apartments in the same building is interpreted as the same address. Same coordinate is interpreted as the same {position.x} and {position.y} of the rat occurrence record.

Error message when trying to create a date and address older incomplete rat occurrence duplicate:

  • DK error message: "Du kan ikke igangsætte en ny ikke-færdiggjort anmeldelse da der findes en senere færdiggjort anmeldelse på samme adresse:'{Id of later completed duplicate}'"
  • EN error message: "You cannot initiate a new non-completed rat occurrence as there exists a later completed rat occurrence on the same address:'{Id of later completed duplicate}'"

28 Days Newer Proximity and Address Rat Occurrence Duplicates

You cannot create more than one Rat Occurrence on the same address within 28 days of completion date of another when it was performed by the same R1 Extermination Company or R2 Exterminator at the same coordinate on the Property. Same address is in the system interpreted as the same streetName, houseNumber and zipCode. So generally, two apartments in the same building is interpreted as the same address. Same coordinate is interpreted as the same {position.x} and {position.y} of the rat occurrence record. 28 days newer proximity means that the notified date of the new rat occurrence you are creating is less than 28 days since the completed date of the duplicate rat occurrence.

In this scenario, you are expected to reopen the earlier Rat Occurrence and continue the extermination efforts in the context of that record.

If you are indeed handling two separate Rat Occurrences on the same address, which fx can happen on large properties, like airports and industrial sites, you will need to register separate coordinates for the separate instances.

Error message when trying to create a 28 days newer proximity and address rat occurrence duplicate:

  • DK error message: "Følgende rotteanmeldelser lader til at påbegynde tidligere end 28 dage efter en anmeldelse på samme adresse ('{Id of duplicate}'). Du skal genåbne den tidligere anmeldelse og fortsætte den i stedet for at påbegynde en ny."
  • EN error message: "The following rat occurrence seems to start up less than 28 days after a rat occurrence on the same address ('{Id of duplicate}'). You must reopen the earlier rat occurrence and continue work on it instead of starting up a new one."

28 Days Older Proximity and Address Rat Occurrence Duplicates

You cannot create more than one Rat Occurrence on the same address within 28 days of completion date of another when it was performed by the same R1 Extermination Company or R2 Exterminator at the same coordinate on the Property. Same address is in the system interpreted as the same streetName, houseNumber and zipCode. So generally, two apartments in the same building is interpreted as the same address. Same coordinate is interpreted as the same {position.x} and {position.y} of the rat occurrence record. 28 days older proximity means that the completed date of the new rat occurrence you are creating is less than 28 days before the notified date of the duplicate rat occurrence.

In this scenario, you are expected to reopen the later Rat Occurrence, change its start date and continue the extermination efforts in the context of that record.

If you are indeed handling two separate Rat Occurrences on the same address, which fx can happen on large properties, like airports and industrial sites, you will need to register separate coordinates for the separate instances.

Error message when trying to create a 28 days older proximity and address rat occurrence duplicate:

  • DK error message: "Følgende rotteanmeldelser lader til at slutte mindre end 28 dage frem til startdatoen af en anmeldelse på samme adresse ('{Id of duplicate}'). Du skal genåbne den senere anmeldelse og opdatere den i stedet for at påbegynde en ny."
  • EN error message: "The following rat occurrence seems to end less than 28 days before the notified date of a rat occurrence on the same address ('{Id of duplicate}'). You must reopen the later rat occurrence and update it instead of starting up a new one."

Data Rules

Required Core Data

  • The Property object requires the following data:
    • HouseNumber: Must have value
    • ZIPCode: Must have value and greater than 0
    • StreetCode or StreetName: At least one of them must have a value.
    • PropertyType2: It must have a value and be within a specified list: [Tilsynspligtig ejendom, Beboelsesejendom, Fødevarevirksomhed, Anden industri, Kommunal institution m.v., Privat-, statslig- eller regional institution m.v., Andet]
  • notifiedDate is required
  • Exterminator or AuthorizationNumber: At least one of them must have a value.

exterminationPerformedBy Attribute Required

The exterminationPerformedBy attribute is required and vital in order to validate that the correct data was supplied for a Rat Occurrence.

  • WHEN logged in user is from Municipality THEN

    • User must choose a value from the following list: [Kommunal bekæmpelse - eget personale, Kommunal bekæmpelse - bekæmpelsesfirma, Privat bekæmpelse (R1-autorisation), Privat bekæmpelse (R2-autorisation)]
  • WHEN exterminationPerformedBy = Kommunal bekæmpelse - eget personale THEN:

    • completedDate must be have a value.
    • ExterminationCompany must be null.
  • WHEN exterminationPerformedBy <> Kommunal bekæmpelse - eget personale THEN:

    • ExterminationCompany must have value and exist in database, AND
      • WHEN value = Privat bekæmpelse (R1-autorisation) or value = Kommunal bekæmpelse - bekæmpelsesfirma THEN exterminationCompany must be R1
      • WHEN value = Privat bekæmpelse (R2-autorisation) THEN exterminationCompany must be R2

NotifiedDate

When completedDate<>null THEN notifiedDate must be earlier or same as completedDate or an error will be thrown.

  • DK error message: "Anmeldelsesdato skal være før eller lig afslutningsdato"
  • EN error message: "Notified date must be earlier than or same date as completed date"

Follow-up date

  • Each follow-up date value must be unique.
  • Only one follow-up date value can be set in the future.
  • All follow-up date values must be after the reported date.
  • All follow-up date values must be before the completed date.

Enumerations

Find parameter enumerations at https://github.com/danmarksmiljoeportal/rotter/wiki/Parameter-Enumerations

Users will get an error if they try to use enumerations not listed on the above wiki page.

  • DK error message: "Enumerationen {enumerationNumber} er ikke en lovlig værdien for {enumerationListName}"
  • EN error message: "The enumeration {enumerationNumber} is not a legal value for {enumerationListName}"

R2-extermination companies cannot choose the following enumerations when updating Rat Occurrences:

  • Poison with key value: 5, 6, 7
  • Animal with key value: 2, 3, 4, 5, 6, 7, 8
  • All values of NoExterminationReason

Duplicated Enumerable

  • ExterminationMethods must contain unique values
  • Reason must contains unique values
  • InjunctionTypes must contain unique values
  • RatObserveds must be contains unique values

Completion Rules for Municipality Users Only

When municipalities update any rat occurrence where animal='Rat' AND completedDate<>null then we want to know if any enforcement (håndhævelse) was carried out on it. Therefore the following validations are done:

  • isEnforcementPerformed must have a value of TRUE or FALSE else error message is thrown.
    • if isEnforcementPerformed=TRUE THEN InjunctionTypes is required ELSE error message is thrown.
    • if isEnforcementPerformed=TRUE THEN EnforcementType is required ELSE error message is thrown.

Completion Rules for All User Types

When user sets a Rat Occurrence as complete, we will do some final checks that all required data has been added. A Rat Occurrence is seen as set completed when completedDate is NOT NULL. In this situation we will validate the following rules.

  • When completedDate<>null AND THEN

    • animals property must have a value
    • ELSE throw error message: DK: 'Du skal vælge det dyr der forårsagede anmeldelsen' EN: 'You must select the animal that caused the occurrence'
  • When animal='Rat' AND completedDate<>null AND isExterminationPerformed=TRUE THEN

    • exterminationMethods must have at least one item selected
    • ELSE throw error message: DK: 'Du skal specificere mindst en bekæmpelsestype der er benyttet på anmeldelsen' EN: 'You must specify at least one extermination method used on the rat occurrence'
    • If the value of ExterminationMethods is 3 (Udlægning af gift), at least one poisonUseds must be specified.
    • ELSE throw error message: DK: 'Du skal specificere mindst en gift som blev udlagt når du har brugt gift som bekæmpelsesmetode' EN: 'You have to specify at least one used poison when having used poison as extermination method'
  • When animal='Rat' AND completedDate<>null THEN

    • ratObserveds property must have a value
    • ELSE throw error message: DK: 'Du skal specificere mindst en måde hvorpå rotter blev observeret' EN: 'You have to specify at least one way in which rats were observed'
  • When animal='Rat' AND completedDate<>null THEN

    • isIndoor property must have a value
    • ELSE throw error message: DK: 'Du skal specificere om rotter blev set indendørs eller udendørs' EN: 'You must specify whether rats were seen indoors or outdoors'
  • When animal='Rat' AND completedDate<>null THEN

    • reasons must have a value
    • ELSE throw error message: DK: 'Du skal specificere mindst en årsag til at der har været rotteforekomst' EN: 'You must specify at least one reason for the occurrence of rats'

Completion Rules for Non-R2 Authorization

  • When animal='Rat' AND completedDate<>null AND exterminationPerformedBy<>Privat bekæmpelse (R2-autorisation) THEN

    • isExterminationPerformed must have a value
    • ELSE throw error message: DK: 'Du skal sætte ja eller nej til om bekæmpelse er foretaget' EN: 'You have to answer yes or no to whether extermination was carried out'
  • When animal='Rat' AND completedDate<>null AND isExterminationPerformed=FALSE AND exterminationPerformedBy<>Privat bekæmpelse (R2-autorisation) THEN

    • noExterminationReason must have a value
    • ELSE throw error message: DK: 'Du skal specificere en årsag til at der ikke blev udført bekæmpelse' EN: 'You have to specify a reason for why extermination efforts were not performed'
  • When animal='Rat' AND completedDate<>null AND exterminationPerformedBy<>Privat bekæmpelse (R2-autorisation) THEN

    • isResidentsInformed must have a value
    • ELSE throw error message: DK: 'Du skal sætte en værdi for hvorvidt ejer, lejer eller dennes repræsentant blev informeret om giftudlægning' EN: 'You have to specify whether owner, tenant or their representative were informed about poison usage'
  • When animal='Rat' AND completedDate<>null AND exterminationPerformedBy<>Privat bekæmpelse (R2-autorisation) THEN

    • isSmokeTestPerformed must have a value
    • ELSE throw error message: DK: 'Du skal specificere hvorvidt der er udført røgprøve på anmeldelsen' EN: 'You must specify whether a smoke test was carried out on the rat occurrence'
  • When animal='Rat' AND completedDate<>null AND isSmokeTestPerformed=FALSE AND exterminationPerformedBy<>Privat bekæmpelse (R2-autorisation) THEN

    • noSmokeTestReason must have a value
    • ELSE throw error message: DK: 'Du skal tilføje en årsag til at der ikke blev udført røgprøve på anmeldelsen' EN: 'You must specify a reason why no smoke test was carried out on the rat occurrence'

Poison Rules

Editing Used and Returned Poison Registrations

Users can specify not only the amount of poison that was used (brought out) to combat the Rat occurrence, but also how much of this poison was brought back again after completion.

When logged in user is user type R1 Extermination Company OR R2 Exterminator, then the User cannot change already submitted Poison Usage or Return records. To correct discrepancies, you must add additional used or returned poison records to adjust the total value.

Technical explanation:

  • {poisonUseds} and {poisonReturneds} objects that were saved for a Rat Occurrence earlier, must still exist in the updated Rat Occurrence. I.e. you are not allowed to edit or delete {poisonUseds} and {poisonReturneds} objects when updating. If you want to change total net values used, you will need to add adjustments using additional {poisonUseds} and {poisonReturneds} objects.
  • the way the code tests this is to compared the existing {poisonUseds} and {poisonReturneds} objects on the database with the {poisonUseds} and {poisonReturneds} objects on the Update Rat Occurrence request. If the former records do not all exist in the latter objects, then an error message will be returned.

Date Required for Returned Poison

With the newest version of the system, the Returned Poison record will require values specified for all attributes of the returnedPoisons objects including date (which was not required for earlier versions):

  • The date, amount, poison and poisonType attributes will all be required.

Final Calculation of Returned Poison Required

In order to ensure, that a final tally is carried out of poison used as compared to poison returned on a Rat Occurrence record, poison returned records will be required for all poison / poison type combinations, which until the completion date has a net usage of above 0 kilogram. This rule will be applied to the methods for create and update Rat Occurrence records. The rule specifies that:

WHEN

  • A Rat Occurrence's completedDate is NOT NULL and notifiedDate (anmeldelsesdato) is equal to or larger than July 1, 2024. THEN
  • The rule requires that there must exist poisonReturneds objects for any combination of poison and poisonType used (poisonUseds) on the Rat Occurrence. WHERE:
  • the poisonUseds.Date = completedDate AND
  • the net poison used* on the Rat Occurrence for the poison and poisonType is more than 0 kilogram (* net poison used is calculated as all the used poison/poisonType minus all the returned poison/poisonType on the Rat Occurrence) AND
  • the amount registered must be equal to or above 0 kilogram* (*I.e. if there is no final change for returned poison, you must still register a poisonReturneds record for the poison/poisonType where amount=0)

ELSE

  • You will not be allowed to register the Rat Occurrence record and get error message "You have to make a final registration of returned poison on the date of completion for any combination of poison/poisontype that you have used on the Rat Occurrence even if that value is 0. You are missing final returned poison registrations for the following poison/poisontypes: {poison_1/poisontype_1}, {poison_2/poisontype_2}, ..., {poison_n/poisontype_n}."
Clone this wiki locally