Attachment 19 JIFMS-JMS Web Service Interface Requirements Specifications REVISED.pdf

Administrative Office of the U.S. Courts

Judicial Integrated Financial Management System (JIFMS) Jury Management System (JMS) Web Service Interface Requirements Specification Document

09/26/19

Version 3.4

Judicial Integrated Financial Management System (JIFMS) Jury Management System

(JMS) Web Service Interface Requirements Specification Document

This page has been intentionally left blank.

Table of Contents

1.0 INTRODUCTION

2.0 CURRENT STATE

3.0 ASSUMPTIONS

4.0 OPEN ISSUES

5.0 CONSTRAINTS

6.0 REFERENCES

7.0 BUSINESS REQUIREMENTS

8.0 FUNCTIONAL REQUIREMENTS

9.0 TECHNICAL REQUIREMENTS

10.0 API SERVICE TECHNICAL REQUIREMENTS

11.0 JMS SYSTEM REQUIREMENTS

List of Tables

Table 1: Business Requirements

Table 2: Functional Requirements

Table 3: Technical Requirements

Table 4: API Service Technical Requirements

Table 5: JMS System Requirements

1.0 Introduction

The purpose of the Judiciary Integrated Financial Management System (JIFMS) Jury Management System (JMS) Web Service Interface is to capture payment information in JIFMS via an automated process. The following objectives have been identified for the JIFMS JMS Web Service Interface:

• Relieve the JMS team of the burden of transforming JMS raw data into the required format for JIFMS JMS input files.

o Eliminate the need to establish and maintain accounting reference tables within

JMS.

• Address audit findings related to JIFMS payment files-at-rest.

• Minimize the impacts to the courts.

2.0 Current State

ACS JUROR, known as JMS within the Judiciary, is the system used by the 94 district courts to facilitate the jury management process. JMS captures juror information and facilitates the jury pool, jury panel creation, and jury selection activities. JMS also captures the information required to generate complete and accurate payments for jury services provided.

Jurors are paid an attendance fee plus applicable reimbursable expenses for each day they serve. Juror for Windows (JFW)/JMS calculates payment by multiplying this value by the number of permanent attendance records (days a person was in attendance) an individual has accrued between a certain range of dates.

The payment process is as follows:

• Scan in participants at a court.

• Confirm the day’s expenses.

• Make any payment corrections prior to executing payment function.

• Execute payment process.

o NOTE: Jurors may either be paid on a periodic basis regardless of whether the trial they are serving on is still in session or when the service is completed.

• Download the Accounts Payable (A/P) Download financial payment file.

The JMS financial payment file is imported into JIFMS via a batch process to create payment documents. Currently, district court personnel transfer the JMS input files to the appropriate court folder on the JIFMS server. JIFMS automation queries the courts’ folders for new JMS input files every 30th minute of the hour between 8am ET and 2am ET Monday through Friday.

When new files are found, they are retrieved and processed without manual intervention.

Upon completion of the import process, JIFMS automation sends an email notification to the court’s JMS Interface LISTSERV mail group with the following attachments:

• Status of the JMS import process.

• Status of rejected forms.

• JMS Import Offline Report.

• JMS Summary Report.

Transactions are imported as processed documents that are ready for level 2 approval. Court certifying officers apply the certifying officer level 2 approval of the processed documents on the JIFMS Undisbursed Payment Query. Transactions that reject upon import are manually corrected and processed in JIFMS using a unique document type. Processed documents that require cancellation must be cancelled prior to the application of the level 2 approval within JIFMS. If required, they are manually re-created and processed in JIFMS using a unique document type. To complete the import process, the JMS Report and the JIFMS JMS Summary Report are used to reconcile JIFMS to JMS.

Approved jury payments are included in the Automated Disbursement batch process that is executed on the next business day at 7am ET. Payments are disbursed from JIFMS via the Treasury disbursing model and are issued via US Treasury checks.

3.0 Assumptions

The following assumptions have been identified for the JIFMS JMS Web Service Interface:

API Service:

1. The interface solution will be developed using the Application Programming

Interface (API) gateway web service technology in conjunction with the current JIFMS JMSIMPORT batch process.

JIFMS:

1. JMS payment data will be transferred to JIFMS using the existing JIFMS JMSIMPORT batch process.

2. A miscellaneous vendor code will be imported with each payment document.

3. Payment documents will be imported as processed documents that are approved for disbursement.

4. Documents imported with a status of 'rejected' will be manually corrected and processed JIFMS.

a. Manually created payment documents will require two levels of approval.

5. Users will have the ability to cancel processed payment documents that have not been disbursed.

a. Processed documents must be cancelled by close of business on the day of import, if required, as approved documents will be included in the Automated Disbursements batch process on the next business day.

b. Canceled payment documents must be manually recreated in JIFMS, if required.

6. Payment adjustments, including the cancellation of processed documents, will be addressed manually in JIFMS prior to disbursement.

7. Issues identified with the JIFMS batch processing (e.g., hexadecimal, special characters, etc.) will be addressed and validated during the data transformation process within the API Service.

8. The JIFMS JMS input file name format will be modified as follows: JA_XXX_YYYY- MM-DD_######.txt where:

a. JA – Fixed value

b. XXX – Court ID (e.g., CAC)

c. YYYY – Year (e.g., 2019)

d. MM – Month (e.g., 03)

e. DD – Day (e.g., 12)

f. ###### - JA document number

9. There are no impacts to the month-end and year-end accrual processes.

10. The JA document number format is ###### where:

a. The first two characters equal the fiscal year.

b. The third, fourth, and fifth characters equal the Julian date (e.g., 71 is the Julian date for 03/12/19).

c. The sixth character equals the batch number.

11. Each payment file may include up to 9,999 payment transactions.

12. A maximum of ten payment files may be submitted per day for a specific court.

JMS:

1. Configuration changes will be applied to the JMS application as needed to support the JIFMS JMS Web Service Interface solution.

2. The Court Programs Division (CPD), Special Programs Branch (SPB) is responsible for ensuring that JMS is in compliance with the Judiciary Information Security Framework to support the ability to apply the certifying officer approval for payment documents in JMS.

a. It is assumed security improvements unique to finance will be made to JMS by incremental steps starting with any issues identified as high and addressing medium and low issues in subsequent releases.

b. It is assumed that finance related issues rated high can be addressed by a reasonable level of effort and expenditure of resources.

3. The Level 1 and level 2 (payment certification) approval of payment documents will be applied in JMS.

4.0 Open Issues

The following open issues have been identified for the JIFMS JMS Web Service Interface:

JIFMS

1. Confirm whether the following existing JIFMS jury payment document types will be used for this interface:

a. General Payment Voucher – JMS Automated (GPJ)

b. General Payment Voucher – JMS Manual (GJM)

NOTE: The implementation approach must be considered when making this decision due to the following:

▪ If the unified JMS system has been implemented, then all JMS instances will reside on one server, thereby allowing the required changes to be applied globally.

▪ If the unified JMS system has not been implemented, then a phased implementation approach may be required, resulting in the need for new unique JIFMS document types.

2. Confirm whether disbursement cut-off dates will be implemented at month-end and year-end.

3. Confirm whether there will be impacts to the 1099 reporting process.

4. Determine whether additional considerations and/or requirements are needed to support the Finance and Accounting Division (FAD) Tax Withholdings project:

a. Distinguish between backup withholdings and tax withholdings for tax reporting.

b. Determine whether backup withholdings be required if the juror refused the

SSN?

c. Identify the business process changes, policy impacts, and training needs

NOTE: Currently, backup withholdings are not impacting juror payments.

5. Define the miscellaneous vendor code to assign to jury payments upon import into JIFMS that are eligible for tax withholdings.

NOTE: A dummy taxpayer identification number/social security number (TIN/SSN), 111-11-1111, will be manually entered in JMS for payment transactions that meet the criteria for tax withholdings.

6. Confirm the criteria and scenarios for rejecting jury payment transactions in JIFMS.

NOTE: Rejected jury payment transactions will not be sent back to JMS for correction if the dummy TIN/SSN is the only rejected element.

5.0 Constraints

The following constraints have been identified for the JIFMS JMS Web Service Interface:

• New requirements may be identified as a result of collaboratively testing the JMS interface process and the API Service.

6.0 References

The following documents have been referenced for the JIFMS JMS Web Service Interface:

• JMS Interface Requirements document version 3.0 (batch process)

7.0 Business Requirements

Business Requirements are intended to accomplish high level business needs of the JIFMS JMS Web Service Interface.

The following are the fields that comprise each business requirement:

• Business Requirement Number (BR#): This is the unique business requirement number for the business requirement.

• Business Requirement: Detailed description of the business requirement.

• Comments: Additional information about the requirement that may affect the stated business requirement.

The following section describes the business requirements for the JIFMS JMS Web Service Interface.

Table 1: Business Requirements

BR # Business Requirement Comments

INT-JMB-

001-000

JIFMS shall provide the ability to accurately record juror payments.

INT-JMB-

002-000

JIFMS shall provide the ability to disburse juror payments through Treasury.

003-000

JIFMS shall issue 1099 forms to jurors.

INT-JMB-

004-000

The JIFMS JMS Web Service Interface process shall leverage an automated process to transfer JIFMS JMS input files to the JIFMS file server.

005-000

The JIFMS JMS Web Service Interface process shall leverage the existing JIFMS JMSIMPORT batch process functionality to import payment data from JMS to JIFMS via files uploaded from the API Service.

006-000

The JIFMS JMS Web Service Interface process shall transform JMS raw data into the required format for JIFMS JMS input files.

007-000

The JIFMS JMS Web Service Interface process shall eliminate the ability to have JIFMS JMS payment files-at-rest.

8.0 Functional Requirements

Functional Requirements detailed in this section describe the business requirement in depth.

The functional requirements will accomplish the business requirement’s goals.

The following are definitions of the column headings for the table below, detailing the functional requirements for the JIFMS JMS Web Service Interface.

• Functional Requirement Number (FR#): This is the unique functional requirement number for the functional requirement.

• Functional Requirement: Detailed description of the functional requirement.

functional requirement.

The following section describes the functional requirements for the JIFMS JMS Web Service

Table 2: Functional Requirements

FR # Functional Requirement Comments

INT-JMF-

001-000

The JIFMS JMS Web Service Interface process shall provide juror payment information from each court instance of JMS.

INT-JMF-

002-000

The JIFMS JMS Web Service Interface process shall require:

• At least one line per payment document for each juror.

• Accounting line(s) that are greater than zero.

002-001

The JIFMS JMS Web Service Interface process shall drop off zero-dollar payment transactions upon import into JIFMS.

Zero-dollar transactions may be imported if a juror opts to waive the jury payment.

INT-JMF-

002-002

The JIFMS JMS Web Service Interface process shall include zero-dollar payment transactions on the JIFMS JMS Zero Dollar Transaction Report.

Zero-dollar transactions may be imported if a juror opts to waive the jury payment.

INT-JMF-

003-000

The JIFMS JMS Web Service Interface process shall create GPJ (General Payment Voucher – JMS Automated) documents in JIFMS.

Confirmation of open issue # 1 is required

INT-JMF-

004-000

The JIFMS JMS Web Service Interface process shall secure payments against local court security organizations.

005-000

The JIFMS JMS Web Service Interface process shall record the JIFMS court unit prefix and the JMS document number to create a unique document number in JIFMS.

Sample document number:

19031210001123456789 19 – fiscal year 03 – fiscal month 12 – day of month 1 – batch number 0001 – counter (sequential # for each payment “0001 – 9999”) 1234567890 – participant *participant # is equal to 10 blank spaces

INT-JMF-

006-000

The JIFMS JMS Web Service Interface process shall provide the ability to create payments based on information received from JMS.

Treasury checks will be issued to jurors.

INT-JMF-

006-001

The JIFMS JMS Web Service Interface process shall record Document Number from JMS.

006-002

The JIFMS JMS Web Service Interface process shall record Juror Name (First and Last) from JMS.

Middle initial may be recorded in the First Name field.

INT-JMF-

006-003

The JIFMS JMS Web Service Interface process shall record the following for Juror Address from JMS:

• Street

• City

• State

• Postal

006-004 record Juror Contact Phone Number from JMS.

006-005

The JIFMS JMS Web Service Interface process shall record Juror Social Security Number (SSN), if populated, from JMS.

SSN needed for 1099 reporting.

INT-JMF- The JIFMS JMS Web Service Interface process shall

006-006 record Juror Email Address from JMS.

INT-JMF-

006-007 record Line Type from JMS.

006-008 record Line Payment Amount from JMS.

006-009

The JIFMS JMS Web Service Interface process shall record the following Accounting dimensions:

• Fund

• Fiscal Year

• Cost Organization

• Budget Organization

• Budget Object Code (BOC)

The use of the accounting template will set unpopulated values to the default values.

INT-JMF-

006-010

The JIFMS JMS Web Service Interface process shall record Juror Participant Number (Part. No.) from

JMS.

The participant number will not be globally unique across the Judiciary. It will be unique for a specific judicial district. Judicial district plus participant number will be unique.

INT-JMF-

006-011

The JIFMS JMS Web Service Interface process shall record the following identifying information for each approver from JMS:

• Level 1 Approver Name

• Level 2 Approver Name

007-000

The JIFMS JMS Web Service Interface process shall require the following document data values in order to process payments:

• Document Type

• Vendor Code (JMS_MISC)

• Disbursing Office

• Disbursing Method

• Disbursing Model

• Document Number

• Document Number Prefix

• Document Type

A unique miscellaneous vendor code will be used for payment transactions that are eligible for tax withholdings.

• Document Date

INT-JMF-

008-000

The JIFMS JMS Web Service Interface process shall provide the ability to create processed payment documents without manual intervention.

009-000 create header accounting lines.

010-000

The JIFMS JMS Web Service Interface process shall prohibit courts from importing transactions for other courts.

011-000

The JIFMS JMS Web Service Interface process shall create jury payment documents with a status of Rejected for each payment that fails validation upon import.

013-000 record Voucher Date from JMS.

014-000

The JIFMS JMS Web Service Interface process shall capture the JMS client service account ID used for basic authentication of each API call.

All API calls require basic authentication credentials.

INT-JMF-

015-000

The JIFMS JMS Web Service Interface process shall resolve the following information based on data provided from JMS to be used on the Header Page:

• Authorization Date

• Document Number

• Document Number Prefix

• Document Type

• Security Org

• Vendor Address Code (001)

• Vendor Code (JMS_MISC)

• Vendor Name

The Accomplished Date in JIFMS is populated after the payment schedule for the transaction is confirmed.

The following fields will auto-populate in JIFMS based on the date of import:

• Accounting Period

• Reporting Accounting Period

• Authorization Date

INT-JMF-

015-001

The JIFMS JMS Web Service Interface process shall resolve the following information based on data provided from JMS to be used on the Header Accounting Line:

• Accounting Template/Budget Org

• BBFY (Beginning Budget Fiscal Year)

• BETC (Business Event Type Code)

• Budget Org

• Cost Organization

• Document Number

• Document Type

• Fund

• Judicial District/AO Division

• Line Amount After Withholding

• Line Amounts

• Line Number

• Line Type

• Net Total

• Object Code

• Payment

• Suspension Amount

• Transaction Amount

• Transaction Type

• YBA (Year of Budget Authority)

INT-JMF-

015-002

The JIFMS JMS Web Service Interface process shall capture the following information from JMS on the More tab of the Header Page:

• Vendor Address Code

• Vendor Address Line 1

• Vendor Address Line 2

• Vendor Address Line 3

• Vendor Address Line 4

• Vendor Address Line 5

• Vendor Code

• Vendor Name

• Vendor Phone

• Vendor TIN

• Vendor City

• Vendor State

• Vendor Postal Code

• Vendor Email

• Vendor Country

INT-JMF-

015-003

The JIFMS JMS Web Service Interface process shall capture the following information from JMS as separate values (rows) in the Description field of the Header Page:

• JMS Juror Participant Number

• JMS Level 1 Approver

• JMS Level 2 Approver

016-000

The JIFMS JMS Web Service Interface process shall only allow JIFMS JMS input files that pass all validations to create processed payment documents in JIFMS.

017-000

The JIFMS JMS Web Service Interface process shall leverage the existing defined notification process via the courts’ listserv mail group to send notifications to specific JMS users via JIFMS automation.

018-000

The JIFMS JMS Web Service Interface process shall reject jury payment transactions with the following dummy TIN/ SSN upon import:

• 111-11-1111

ACTION: Revisit the use cases and logic associated with each.

09/04/19 – The System Integrator POCs should participate in the discussion.

The payment transaction will not be sent back to JMS if the dummy TIN/SSN is the only rejected element.

9.0 Technical Requirements

Technical Requirements detailed in this section identifies the technical aspects of the business requirements as well as functional requirements.

The following are definitions of the column headings for the table below, detailing the technical requirements for the JIFMS JMS Web Service Interface.

• Technical Requirement Number (TR#): This is the unique technical requirement number for the technical requirement.

• Technical Requirement: Detailed description of the technical requirement.

technical requirement.

The following section describes the technical requirements for the JIFMS JMS Web Service

Table 3: Technical Requirements

TR # Technical Requirement Comments

INT-JMT-

100-000

The JIFMS JMS Web Service Interface shall utilize web service technology.

The API gateway technology solution shall be used in conjunction with the existing JIFMS JMSIMPORT batch process.

10.0 API Service Technical

Requirements

The API Service technical requirements are specific to the transference of data from the API Service to JIFMS. The API Service technical requirements are intended to identify configuration changes needed to support the JIFMS JMS Web Service Interface.

The following are the fields that comprise each API Service technical requirement:

• API Service Technical Requirement Number: This is the unique API Service technical requirement number.

• API Service Technical Requirement: Detailed description of the API Service technical requirement.

API Service technical requirement.

The following section describes the API Service technical requirements.

Table 4: API Service Technical Requirements

API Service

TR #

API Service Technical Requirement Comments

INT-JMA-

200-000

The API Service shall access the required JIFMS Accounting Dimensions reference tables.

INT-JMA-

201-000

The API Service shall accommodate for JIFMS maintenance resulting in down-time and allow for ‘in-process’ transaction status.

A signal to the API will need to be created regarding the maintenance window to signal the retries.

Determine how many retries will be allowed. - Requires an action by an individual.

*Possibly a Day 2 requirement.

INT-JMA-

202-000

The API Service shall send payment lines to JIFMS via existing JIFMS Batch Processing facility.

TR #

API Service Technical Requirement Comments

INT-JMA-

203-000

The API Service shall identify the following new file name convention for the JIFMS JMS input file, JA_XXX_YYYY-MM-DD_######.txt where:

• JA – Fixed value

• XXX – Court ID (e.g., CAC)

• YYYY – Year (e.g., 2019)

• MM – Month (e.g., 03)

• DD – Day (e.g., 12)

• ###### - JA document number

204-000

The API Service shall log the status of each transaction in a log database.

205-000

The API Service shall combine JMS payment information with Accounting Dimensions reference tables to produce JIFMS compatible payment lines.

206-000

The API Service shall create a tilde separated batch file per the JIFMS JMSIMPORT batch specifications to contain payment data.

207-000

The API Service shall use the tilde separated batch file as the source to import payment data in JIFMS.

208-000

The API Service shall transfer the tilde separated batch file to JIFMS using SFTP.

209-000

The API Service response to the RESTful GET API initiated by JMS shall include the following:

• Errors in the original POST contents

• Status of batch file submission to JIFMS

210-000

The API Service shall require basic authentication for all calls.

210-001

The API Service shall capture the JMS service account ID in the log database.

ACTION: Confirm the JIFMS mapping with the ASO-OMB Chief.

INT-JMA-

211-000

The API Service shall disallow the transference of the following special characters:

• Non-7-bit ASCII

Single and double quotes may lead to a malformed

JSON.

TR #

API Service Technical Requirement Comments

• Long “|” pipe

• Tilde characters

• Single quotes

• Double quotes

Additional non-allowable characters may be identified during testing.

INT-JMA-

212-000

The API Service shall provide the following JSON body element types in the initial RESTful POST API and subsequent RESTful GET APIs:

• id

• status

• data

The structure of the standard JSON response will be changed which will require changes to the values. The return data will remain the same.

INT-JMA-

213-000

The API Service shall use a RESTful GET API to return the processing status to JMS for a specified transaction.

214-000

The API Service shall allow the use of a RESTful POST API to provide JMS payment information to the API Service.

215-000

The API Service shall receive JMS payment information in the body of the RESTful POST API in JSON format.

216-000

The API Service shall process the following sections in the body of the RESTful POST API:

• Batch

• Payments

217-000

The API Service shall process the following payment information within the Batch section of the body of the RESTful POST API:

• courtID

• currentDate

• batchNumber

• batchTotalPayment

• transactionID

• Level 1 Approver

• Level 2 Approver

TR #

API Service Technical Requirement Comments

INT-JMA-

218-000

The API Service shall process the following information within the Payments section of the body of the RESTful POST API:

• juryType

• disbursementMethod

• disbursingModel

• participantNumber

• addressName

• addressLine1

• addressLine2

• addressLine3

• addressLine4

• addressLine5

• addressCity

• addressState

• addressZipCode

• addressPhoneNumber

• addressEmail

• subTotalPayment

• paymentLines (NOTE: Multiple payment lines may exist.)

219-000

The API Service shall return the following Hypertext Transfer Protocol (HTTP) status codes for each transaction:

• Normal processing with no intervening error conditions (200s)

• Errors with submitted JSON or API Service error (400's)

• Errors related to the web server, middleware stack, and possibly the API Service (500's)

220-000

The API Service shall categorize errors into one of the following categories:

• Errors before the start of the request content verification

• Errors during the request content verification

TR #

API Service Technical Requirement Comments

• Errors during the request processing

INT-JMA-

221-000

The API Service shall categorize errors received during the request content verification into one of the following categories:

• Invalid character found

• Invalid JSON format

• Missing required property

• Data value not allowed

• Invalid data length

• Invalid data format

• Business validation failure

222-000

The API Service shall detect the following errors for RESTful GET APIs and RESTful POST APIs with validated request content:

• Errors for an invalid TransactionID

• Errors for a duplicate batch number

• Errors detected with any component of the processing (e.g., database or JIFMS connections)

• All other server-side errors with the API Service processing

223-000

The API Service shall identify the following payment types as valid within the Payment Lines section of the body of the RESTful POST API:

• Attendance

• Mileage

• Parking

• Subsistence

The JIFMS labels are as follows for the jury-related BOCs and sub- BOCs:

• Attendance (1182)

• Mileage (2140-02)

• Subsistence (2140- 03)

• Parking (includes public, transit, and miscellaneous [2140- 04])

11.0 JMS System Requirements

The JMS system requirements are intended to identify configuration changes needed to support the JIFMS JMS web service interface.

The following are the fields that comprise each JMS system requirement:

• JMS System Requirement Number: This is the unique JMS system requirement number.

• JMS System Requirement: Detailed description of the JMS system requirement.

JMS system requirement.

The following section describes the JMS system requirements.

Table 5: JMS System Requirements

JMS Req # JMS System Requirement Comments

JMS-001-

JMS shall provide the ability to apply the following approvals to payments prior to import into JIFMS:

- Level 1 Approval

- Level 2 Approval (district court certifying officer)

JMS-003-

JMS shall capture the JIFMS court unit prefix for each payment transaction.

JMS-005-

JMS shall include the following data elements when establishing the web service for the JIFMS JMS Web Service Interface:

• Disbursing Method

• Disbursing Model

JMS-005-

JMS shall provide the following values when establishing the web service for the JIFMS JMS Web Service Interface:

• disbursementMethod: “C”

• disbursementModel: “agencyPrinting” agencyPrinting maps to the Treasury Disbursing Disbursement model in

JIFMS.

JMS-007-

JMS shall replace the existing JIFMS Batch File with a RESTful POST API to the API Service.

JMS-008-

JMS shall send the payment information to the API Service using a JSON format.

JMS-009-

JMS shall include the following payment information data elements in the Batch section of the RESTful POST API to the API Service:

• courtID

• currentDate

• batchNumber

• batchTotalPayment

• TransactionID

• Level 1 Approver

• Level 2 Approver

JMS-010-

JMS shall include the following payment information data elements in the Payments section of the RESTful POST API to the API Service:

• juryType

• disbursementMethod

• disbursingModel

• participantNumber

• addressName

• addressLine1

• addressLine2

• addressLine3

• addressLine4

• addressLine5

• addressCity

• addressState

• addressZipCode

• addressPhoneNumber

• addressEmail

• subTotalPayment

JMS-011-

JMS shall include the following payment information data elements in the paymentLines section of the RESTful POST API to the API Service for each payment type included in the payment transaction:

• paymentType

• amount

JMS-012-

JMS shall include one or more of the following valid payment types in the paymentLines section of the RESTful POST API to the API Service for each payment transaction:

• Attendance

• Parking

• Mileage

• Subsistence

The inclusion of the Carrier payment type (JIFMS BOC 2140, Sub- BOC 05 – Common Carrier Fares – Jury) is not required per the Budget office.

The JIFMS labels are as follows for the jury-related BOCs and sub- BOCs:

• Attendance (1182)

• Mileage (2140-02)

• Subsistence (2140- 03)

• Parking (includes public, transit, and miscellaneous [2140- 04])

JMS-013-

JMS shall initiate a RESTful GET API to the API Service for success/failure status information.

JMS-014-

JMS shall provide the ability to display API service responses to the RESTful GET API initiated by JMS for the following:

• Errors in the original POST contents

• Status of batch file submission to JIFMS

JMS-015-

JMS shall include unique Transaction ID in the original RESTful POST API to track requests initiated via the RESTful GET API from JMS to JIFMS via the API Service.

The Transaction ID will include court prefix (unique per judicial district) and an auto-generated number for the specified judicial district.

JMS-016-

JMS shall provide the ability the correct rejected data, including but not limited to the following:

• Non-7-bit ASCII values

• Long “|” pipe

• Tilde characters

• Single quotes

• Double quotes

Single and double quotes may lead to a malformed

JSON.

Additional non-allowable characters may be identified during testing.

Appendix A: Abbreviations and Acronyms

The following abbreviations and acronyms are used throughout this document:

Abbreviation/Acronym Meaning

AO Administrative Office of the U.S. Courts

AP Accounts Payable

API Application Programming Interface

BBFY Beginning Budget Fiscal Year

BETC Business Event Type Code

BOC Budget Object Code

BR Business Requirement

CPD Court Programs Division

FAD Finance and Accounting Division

FR Functional Requirement

GJM General Payment Voucher – JMS Automated

GPJ General Payment Voucher – JMS Manual

HTTP Hypertext Transfer Protocol

JFW Juror for Windows

JIFMS Judiciary Integrated Financial Management System

JMS Jury Management System

JSON JavaScript Object Notation

SPB Special Programs Branch

SSN Social Security Number

TIN Taxpayer Identification Number

TR Technical Requirement

YBA Year of Budget Authority