KBA00040007

Summary

UCR reports are reports that are used to report the number of occurrences each offense in a UCR class has a occurred. These reports are then submitted to the FBI for statistical analysis. The way these reports work are based on the offense codes,which are each assigned a UCR Action code in the tboff table. They are also used to analyze totals for property and vehicles stolen as well as the value of the property / vehicles.

Details

This Article covers UCR that isn't for a specific state if you do use a state specific UCR please refer to the UCR manual for your state. 
Icon 
Classic UCR (or simply ucr reports) is being phased out as it is missing some important offense codes and race codes. It also has some out of date language. Please use UCR 2013 as it adheres to current FBI standards.
UCR 2013 
This section Covers the various UCR reports for UCR 2013 to run this report please type ucr2013 in the spillman command line. SAA's please make sure records personnel that need to run UCR have the sypriv "ucr2013".
Also for your reference anyone running these reports will need access to the following fields. They will also need access to any non-agency partitioned records that need to be counted on the report.

 
 
ucr2013.xa 
 
When the ucr2013.xa report is run, it first calculates which offense is highest. The reason it does this is because only one offense is reported to UCR per incident number, which is always the most severe offense.
This is identified by taking the UCR Action code in the TBOFF table (tboff.action) and using the offense with the highest action code among the offenses attached to an incident. For example, if a person has the offenses of theft of property (code 49)  and Homicide (code 107) then Homicide will be counted because it has the higher offense code.  The only exception to this is crimes against persons, so if a crime is committed against two people then both offenses will be counted (eg. two people are killed).
The report increments the counter for the cell that corresponds with how the incident was cleared. There are several columns, one for each clearance type and one for the total offenses reported. The total offenses reported column is an aggregate of all offenses reported period regardless of how the incident was cleared. The Unfounded Complaint column is based on the lwmain.dispos field have the code of UNF. If this code is found then it will increment this column and subtract this number from the Offenses reported column to create the Actual Offense column. The last two columns are determined by the clearance codes as found in the lwtbdisp (the code table for the lwmain.dispos field).  If the clearance code from lwtbdisp.action is equal to 5, 6, 7, 8, 9, 10 then it will count toward the first column Offenses Cleared. A 6, 8 or 10 code will place it in the Juvenile Clearance column. (This is just a subsection of the first column)


Another thing to keep in mind is the Return A report only counts  all offense codes > 46 (tboff.action).
Officer Leoka data:
The return A also includes data about Arson cases, leoka data, and offenses cleared by adult and juvenile arrests. 
The officers assaulted field is determined by these offense codes action codes. (tboff.action) 48, 68, 71, 73, 75 if the offense in the incident table matches any of these tboff.action codes then it will count toward an officer assaulted.
There is a known bug that has caused this number to be off if their number is off here is the bug number STI-19996 just let us know you are seeing it. (It should have been checked in but they may not have been patched yet)
The clearance by adult arrests are pulled from the lwmain.dispos field where the lwtbdisp.action code is equal to 5. The same thing for Juvenile arrests but action code 6.
Arson cases are determined by the offense codes from tboff and includes any action code from tboff.action that is equal to or between 30 and 46


 
If you are struggling to find out why the report is showing strange data a good tool is to run the ucrauda report which takes a look at each incident that is viewed by ucr2013 and will help identify record problems.

 
ucr2013.xsupa 
This first part of this return is focused on property types and values and is mostly for reporting theft, burglary, and the items recovered or stolen.
 
It counts the value of each item type that is stolen and also the value types that are recovered.
To determine the value type it looks at the law table to find all of the incidents that have eligible property involvements. First it finds whether or not the disposition is equal to unf then it stores that data for later. Next it checks if lwmain.dtrepor field is within their date range they searched for if it doesn't then then it checks if the disposition date falls in the time period and the case is unfounded if it meets this criteria then it subtracts the value from the total. If it does then it determines if the lwmain.dispdat falls within the time period if it does  and the dispdat falls in the time period and the case is unfounded then it doesn't count it. If it isn't unfounded then it is counted.
 
Since this is hard to understand I'll draw a small diagram:

Next it looks at the property and vehicles tables to count the values based on the involvements found from the law table to these tables.
 
The different fields it looks at are as follows first it looks at the status field from the vhmhist, vhmain, prmhist, and prmain tables to determine what status the property is in to determine how it should be counted. This table is coded to tbstats which is where we find the values that we care about (the  tbstats.action field) if this field value is 1 , 2, or 3 then the property is counted otherwise it is not counted. 
 
In order to count the property it takes the value found in the table.value(vhmain, prmain, prmhist, vhmhist) field and adds it to the property type to which it belongs. In order for it to do that it reads the value found in the pr*.ucr or the vehicle tables and determines the property type based on its code found in the prtbucr.action field.  If it’s a vehicle it just counts it assuming all other conditions are met. The codes in the UCR action code from this table will correspond with the group as follows:
 
Currency = 1
Jewelry = 2
Clothing = 3
ALL Vehicles = no code in prtbucr
Office Equipment = 4
TV's radios etc = 5
Firearms = 6
Household items = 7
Consumables = 8
Livestock = 9
Misc = 10
 
So the code that is used in the property table needs to have this matching code in the UCR action code field for it to be placed in the appropriate section of this report.
Below is a sample for this part of the report.

Second part of ucr2013.xsupa takes all of the offenses for each incident and all of the property involved in an incident and checks to see if that property was stolen. If property was stolen along with the committed offense then the value will be counted toward that offense in part1. In part 2 the report breaks down the larceny offenses by type of larceny along with showing the number of motor vehicles recovered locally. Like with the first part of the report items will be subtracted or not counted based on the date that the disposition changed and whether or not the record is unfounded refer to the chart in the earlier in this section for more details. 
Something to keep in mind is that if the UCR Incident field isn't filled out with the correct incident number then it won't show up correctly on this report. Really though all fields in the property / vehicle tables that start with IBR/UCR should be filled out correctly or the report will show incorrect results.

Another gotcha is the IBR/UCR Status field if the prmain.status / vehicle.status tables which are coded to tbstats.action need to be equal to 1, 2, or 3 to show up on this report. If not then it won't be counted as stolen and the property /vehicle values with be calculated incorrectly.

Below is an example of this part of the report:


ucr2013.xd and .xe 
 This return along with Return D and E counts all of the people arrested (keying off of the jlarrest table) for an offense by the most severe offense from the jloffens table and shows the demographic information of the person arrested. The demographic information includes the persons age race, and sex. The return looks like this:



If you are having problems with this report make sure that the offense codes, ages, juvenile status, are all correct. This report uses offense codes NOT statutes.
 
ucr2013.xi 
 ucr2013.xi or return I prints the arson offenses in a format similar to return a (.xa). Everything works the same as return A except that it pulls its amount codes from the lwoffs.amount field as shown below.

Here is a sample of the report:

ucr2013.xh 
ucr2013.xh is the added offenses for human trafficking and prostitution for the return A portion. And is essentially and an addition to return A (.xa) It works exactly the same but only counts human trafficking and prostitution offenses.
Below is a sample of the report.

Classic UCR 
For the reasons below please use UCR 2013 you can run it by typing ucr2013 in the Spillman command line.
Classic UCR is exactly the same as UCR 2013 except for the following changes:
 Missing Offense codes:
108 - Purchasing Prostitution
109 - Assisting/Promoting Prostitution
110 - Human Trafficking/Involuntary S
111 - Human Trafficking/Commercial Se
 
It is also missing on return D and return E, an additional Ethnicity column for “Native Hawaiian or Other Pacific Islander”.
The following language is also updated on UCR 2013:
Line 20 has been changed from “Forcible Rape” to “Rape”
Line 21 has been changed from “Rape by Force” to “Rape”
Line 22 has been changed from “Attempt Forcible Rape” to “Attempts to Commit Rape”
 
 
 
State Specific UCR 
Each of these UCR reports are specific to a State. The States are Florida, New Jersey, Illinois, Georgia, California and Pennsylvania.
NJUCR 
NJUCR works mostly like standard UCR but it too has some key differences. (See UCR 2013 section)

1. Supplemental murder and manslaughter. One key difference is the Homicide detail screen where users will need to enter the offender victim relationship type, the weapon used, the relationship between the offender and victim and the  Circumstances for the homicide. The assault firearm must also be included in the circumstances field on the law screen. For more details see pages 10-13 in the NJUCR manual.

2. Another key difference is this report only prints one report that contains all of the other sub reports that normally are included in standard UCR. 

3. Finally there are some extra codes that need to be added to the code tables when being setup however most agencies should already be setup. For more details on these code tables that need extra work see pages 17-18.

FLUCR 
 
Florida works mostly like standard except for some key changes:

1. There is only one report to run that contains all of the sub reports from standard UCR into one report.

2. Florida uses the syxfrout translation table to translate local codes to state excepted codes so they can submit UCR to the state. This part is very important for state submissions to go through. The default codes are included in the attached manual below. However if they want to add more code translations they will need to add an entry in the syxfrout table to match the local code to the remote code. See manual pages 32-40.

3. Another key difference is the need to use the Homicide detail window. Although the manual explains this the import part is making sure users have the right code for the right situation.

 
In this instance the situation code is A because there is only one offender and one victim if it were different and there was one offender and multiple victims then there would need to be code C. So the counting is correct. This is because we would need to count 2 or more homicides instead of just one even though there is one law incident. This because in the state of Florida it is number of victims based with severe offenses such as homicides so that the FBI is aware of the total number of homicides. Once again you can see the manual pages 10-13 for more details.

1. Domestic Violence works very similar to the Homicide screen and should also be filled out appropriately. See manual pages 14-16.

2. The Leoka screen is used to report Officers Killed and works very similar to how IBR works. The record needs to be filled out with the correct information. For multiple victims or offenders enter each offender and victim only once so if there is one offender and multiple victims enter the offender on the first record but not on the second. For more details see the manual pages 16-21.

3. Once again the total number of offenses is based on the number of victims/offenders relationship so multiple victims mean multiple offenses. See page 22 for more details.

4. Another key difference is that when the FLUCR report is run there are logs that run and will display warnings and errors at the top of the report that are items that may need to be fixed. These logs are also stored in .txt files on the server in $CUSTDIR/FDLE/user_name/submit. You can view all of the different types of errors in this directory. The errors are split up based on type and where the error took place. Fore instance errors related to the vehicle table will be stored in the VEHICLE.TXT log. For more details see manual pages  23-29

 
 
These States are more closely related to NIBRS in functionality if you are at all familiar with NIBRS then it works more similarly to that means of reporting the FBI. Really the best place to go for information is going to be the individual manuals.