Attachment 19 - JIFMS-JMS Web Service Interface Requirements Specifications.pdf
PDF 548 KB Posted
- Attached to
- Web-based Jury Management System (JMS)
- Solicitation number
- USCA24R0030
- Issued by
-
Administrative Office of the U.S. Courts
About this file
This document is a Requirements Specification for the Judicial Integrated Financial Management System (JIFMS) Jury Management System (JMS) Web Service Interface. It details the business, functional, technical, and application programming interface (API) service requirements for an automated interface between the JMS and JIFMS systems to facilitate the transfer of juror payment information from JMS to JIFMS.
The key requirements include: automating the transfer of JMS payment data to JIFMS, transforming the JMS data into the required JIFMS format, eliminating JIFMS payment files-at-rest, creating processed payment documents in JIFMS without manual intervention, leveraging the existing JIFMS batch processing functionality, and applying the appropriate payment approvals in JMS prior to transfer. The API service requirements specify the use of web service technology, RESTful APIs, JSON data format, and error handling. The document also outlines assumptions, open issues, constraints, and references related to the JIFMS JMS Web Service Interface.
View the file
Other files
Show all 45
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
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
Revision Table
Version No. Date Author Change Description
0.1 3/9/2016 Rupen Rao Initial draft.
0.2 9/16/2016 Samantha Parran, Rupen Rao Updates made to the initial draft.
0.3 9/27/2016 Samantha Parran, Rupen Rao Finalizing updates to the draft.
0.4 9/30/2016 Samantha Parran, Rupen Rao Updates to Sections 1.0, 2.0, 7.0, and 9.0.
Removed Sections 3.0 and 4.0.
0.5 11/09/2016 Samantha Parran, Rupen Rao
Changes made based on changes made to the Scope document after the Scope document feedback was received from stakeholders.
1.0 12/15/2016 Samantha Parran, Rupen Rao Added additional Functional Requirements and updated the version number for the document.
2.0 01/03/2017 Samantha Parran, Rupen Rao Added business requirement and additional functional requirements per Russ Follin during sign-off.
3.0 03/12/2019 Samantha Parran, Hong Kim, Minh Quan
Updates made to the entire document per the development team’s requirements review on 03/04/19
3.1 03/21/2019
Samantha Parran, Minh Quan, Gordon Mai, Vishal Batra, Hong Kim, Caleb Baker, Tushar Patel
Updates made to sections 2.0, 3.0, 8.0, 10.0, and 11.0
3.2 06/07/2019
Caleb Baker, Gordon Mai, Hong Kim, Minh Quan, Vishal Batra, Samantha Parran, Tushar Patel, Vladimir Mylnikov
Updates made to sections 3.0, 4.0, 5.0, 8.0, 10.0, and 11.0
3.3 06/24/2019 Samantha Parran, Tushar Patel Updates made to the change descriptions in the Revision History, section 8.0
3.4 09/26/19 Various stakeholders, JMS Interface Monthly Status Meeting (09/04/19)
Updates made to sections 2.0, 4.0, 5.0, 8.0, 10.0, and 11.0
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.
• Comments: Additional information about the requirement that may affect the stated 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-
006-006 record Juror Email Address from JMS.
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 – Jenn Pesek and Tushar Patel 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.
• Comments: Additional information about the requirement that may affect the stated 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.
• Comments: Additional information about the requirement that may affect the stated 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 Ayaz Siddiqui.
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.
• Comments: Additional information about the requirement that may affect the stated
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
| 1.0 Introduction |
| 2.0 Current State |
| 3.0 Assumptions |
| API Service: |
| JIFMS: |
| JMS: |
| 4.0 Open Issues |
| JIFMS |
| 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 |
File details come from the government source that posted it. Updated .