Master Data Services Functionality

Master Data Management

Location Hierarchy

Create Location Hierarchy

Upon receiving a request to add Location hierarchy (e.g., Country - Region - Province - City- LAA) with the input parameters (code, name, hierarchy_level, hierarchy_level_name, parent_loc_code ,lang_code and is_active), the system stores the Location hierarchy in the Database

While storing the location hierarchy in the database, the system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • name - character (128) - Mandatory
   • hierarchy_level - smallint - Mandatory
   • hierarchy_level_name - character (64) - Mandatory
   • parent_loc_code - character (32) - Optional
   • lang_code - character (3) - Mandatory
   • is_active - boolean - Mandatory
2. Validate if the Location name received does not already exist in the hierarchy for which the location is getting created

   • If Location name already exist under the hierarchy level, throw an appropriate error
3. The API should not allow creation of the Location if the data is not received in default language
4. If the data for the Location is not received in all the configured languages, the API should allow the Location to be created given the Point 3 is satisfied.
5. The API should activate the Location while creation provided the data for all the configured languages is received during the initial creation

   • If the data for all the configured languages is not received, deactivate the Location while creation
6. While storing the location,

   • cr_by should be the Username of the user who is accessing this API
   • cr_dtimes should be the date-time at which the user is creating the Location
7. Responds with the Location Hierarchy created successfully
8. The component restricts the bulk creation of Master Data through API. However it could be done through a script as need be depending on the requirement of the country.
9. In case of exceptions, system triggers error messages as received from the Database

Update a Location

On receiving a request to update a Location with the input parameters (code, name, hierarchy_level, hierarchy_level_name, parent_loc_code, lang_code and is_active), the system updates the Location in the Location Database for the code received.

The system performs the following steps to update the location in the Master Database:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code character (36) - Mandatory
   • name character (128) - Mandatory
   • hierarchy_level smallint - Mandatory
   • hierarchy_level_name character (64) - Mandatory
   • parent_loc_code character (32) - Mandatory
   • lang_code character (3) - Mandatory
   • is_active boolean - Mandatory
2. Validate if the Location name received does not already exist in the hierarchy of the Location

   • If Location name already exist under the hierarchy level, throw an appropriate error
3. The API should not allow activation of Location if the data for the Location is not present in all the languages which are configured for a country
4. For the code received in the request, replaces all the data received in the request against the data existing in the Location database against the same code.
5. While receiving the request for activation, If the Location is already Active, the API should throw an error message. Refer messages section.
6. While receiving the request for deactivation, If the Location is already Inactive, the API should throw an error message. Refer messages section
7. If for a Location data, is_active flag is being sent as “False” and there are active child Locations (also the subsequent child locations) being mapped to received location, do not deactivate the location. Respond with appropriate message. Refer messages section
8. Deleted record are not be updated
9. upd_by should be the Username of the user who is accessing this API
10. upd_dtimes should be the date-time when the Location is being updated
11. Responds with data not found error if deleted record is received in the request
12. Responds with appropriate message if the Location is updated successfully
13. In case of Exceptions, system triggers relevant error messages

Verify Location

Upon receiving a request to validate the Location Name with input parameters (Location Name), the system checks the Location Name in the Master Database

While checking the location in the Database, the system performs the following steps:

1. Validates if the request contains the following input parameters

   • Location Name - Mandatory
2. If the mandatory input parameters are missing, throw the appropriate message
3. In case of Exceptions, system triggers relevant error messages

Fetch Location Hierarchy Levels based on a Language Code

Upon receiving a request to fetch the Location Hierarchy Levels with input parameters (Language Code), the system fetches the Location Hierarchy Levels in the requested language. The following steps are performed by the system:

1. Validates if the request contains following input parameters (Language Code)

   • Language Code - Mandatory
2. Validates if the response contains the Location Hierarchy Levels with the following attributes

   • Hierarchy Level
   • Hierarchy Name
   • IsActive
3. In case of Exceptions, system triggers relevant error messages

Fetch the Location Hierarchy Data based on a Location Code and a Language Code

Upon receiving a request to fetch all the Location Hierarchy Data with input parameters (Location Code and Language Code), the system fetches the Location Hierarchy Data based on requested Location code and language code. The following steps are performed by the system:

1. Validates if the request contains the following input parameters

   • Location Code - Mandatory
   • Language Code - Mandatory
2. If the mandatory input parameters are missing, throw the appropriate message.
3. Validates if the response contains the following location hierarchy data and the corresponding attributes against the Location Code and Language Code received in the input parameter (i) List of Countries against the Location Code

   • Country Code
   • Country Name
   • IsActive

   (ii) List of Regions against the Location Code

   • Region Code
   • Region Name
   • IsActive

   (iii) List of Provinces against the Location Code

   • Province Code
   • Province Name
   • IsActive

   (iv) List of Cities against the Location Code

   • City Code
   • City Name
   • IsActive

   (v) List of Local Administrative authorities against the Location Code

   • Local Administrative Authority Code
   • Local Administrative Authority Name
   • IsActive

   (vi) List of Pincodes against the Location Code

   • Pincode
   • IsActive
4. Responds to the source with all the Location Hierarchy Data based on the Location Code
5. In case of Exceptions, system triggers relevant error messages.

Fetch the Location Hierarchy Data for the bottom next hierarchy based on a Location Code and a Language Code

Upon receiving a request to fetch all the Location Hierarchy Data with input parameters (Location Code and Language Code), the system fetches the Location Hierarchy Data for the next hierarchy level. The following steps are performed by the system:

1. Validates if the request contains the following input parameters

   • Location Code - Mandatory
   • Language Code - Mandatory
2. If the mandatory input parameters are missing, throws the appropriate message.
3. Fetches the Location data of only the child hierarchy of location code received (For e.g., if the location code for a particular Province is received, responds with the data of all the Cities existing in that Province, similarly if location code of a City is received, responds all the data regarding the Local Administrative Authorities existing under that City)
4. Responds to the source with the data fetched
5. In case of Exceptions, system should trigger an error message.

Delete a Location

On receiving a request to delete a Location with the input parameters (code), the system updates the is_deleted flag to true in the Location Database against the code received.

The system performs the following steps in order to delete the loaction received in the code:

1. Validates if all required input parameters have been received as listed below for each specific request
2. Delete all records for the code received
3. Deleted record are not be deleted again
4. Responds with data not found error if deleted record is received in the request
5. Responds with dependency found error if a record to be deleted is used as foreign key in the dependent table
6. Responds with the Code for the Location Hierarchy deleted successfully

   • code - character (36) - Mandatory
7. In case of Exceptions, system triggers relevant error messages.

List of Holidays

Create Holiday

Upon receiving a request to add Holiday Data with the input parameters (location_code, holiday_date, holiday_name, holiday_desc, lang_code and is_active), the system stores the Holiday in the Database. The following steps are performed by the system:

1. This API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • location_code - Character - 128 - Mandatory
   • holiday_date - Date Format (yyyy-mm-dd) - Mandatory
   • holiday_name - Character - 64 - Mandatory
   • holiday_desc - Character - 128 - Optional
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message.
6. 'location_code' received should be from list of 'codes' from 'location' masterdata table

   • If not, the API should throw an error.
7. If all the above validations are successfull, the API should update the data in the database agianst the id received
8. API should perfrom below multi-language validations on the Holiday data recieved
9. If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Holiday as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
10. API should store upd_by as the Username of the user who is accessing this API
11. API should store upd_dtimes as the date-time at which the user is modiying the Holiday details
12. API should only allow creation of one record at a time and should restrict bulk creation
13. API should audit the relevant data when the API is called successfully or when an error is encountered

Update Holiday

1. This API should only be accessible to Global Admin
2. The API should accept only the below parameter

   • id - Character - 36 - Mandatory
   • location_code - Character - 128 - Mandatory
   • holiday_date - Date Format (yyyy-mm-dd) - Mandatory
   • holiday_name - Character - 64 - Mandatory
   • holiday_desc - Character - 128 - Optional
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message.

   • 'location_code' received should be from list of 'codes' from 'location' masterdata table
6. If not, the API should throw an error.
7. If all the above validations are successfull, the API should update the data in the database agianst the id received
8. API should perfrom below multi-language validations on the Template data recieved
9. If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Template as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
10. API should store upd_by as the Username of the user who is accessing this API
11. API should store upd_dtimes as the date-time at which the user is modiying the Template details
12. API should only allow creation of one record at a time and should restrict bulk creation
13. API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch List of Holidays based on a Registration Center ID, a Year and a Language Code

On receiving a request to fetch the list of Holidays with the input parameters (Registration Center ID, Year and Language Code), the system fetches the list of Holidays mapped to a Registration Center and for the year and Language Code received in input parameter as per the below steps:

1. Validates if the received request contains the following input parameters

   • Registration Center ID - Mandatory
   • Year - Mandatory
   • Language Code - Mandatory
2. If the mandatory input parameters are missing, throws the appropriate message
3. Validates if the response contains the List of Holidays against the Registration Center ID and the year received and contains the following attributes for a Region

   • Holiday ID
   • Holiday Date
   • Holiday Name
   • IsActive
4. Responds to the source with the List of Holidays
5. In case of Exceptions, system triggers relevant error messages

Biometric Authentication Type

Create Biometric Authentication Type

On receiving a request to add Biometric Authentication Type (e.g., Fingerprint, Iris) with the input parameters (code, name, descr, lang_code and is_active), the system stores the Biometric Authentication Type in the Database as per the below steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • name - character (64) - Mandatory
   • descr - character (256) - Optional
   • lang_code - character (3) - Mandatory
   • is_active - boolean - Mandatory
2. Responds with the Biometric Authentication Type Code and Language Code for the Biometric Authentication Type created successfully
3. The component restricts the bulk creation of Master Data
4. In case of Exceptions, system triggers error messages as received from the Database.

Fetch the List of Biometric Authentication Type based on a Language Code

On receiving a request to fetch the List of Biometric Authentication Type with input parameters (Language Code), the system fetches the List of Biometric Authentication Type against the Language Code as per the below steps:

1. Validates if the request to add Biometric Authentication Type contains the following parameters

   • Language Code - Mandatory
2. If the mandatory input parameters are missing, responds with all the data.
3. Validates if the response contains the List of Biometric Authentication Type against the Language Code along with the IsActive Flag for each Biometric Authentication Type
4. Responds to the source with List of Biometric Authentication Type
5. In case of Exceptions, system triggers relevant error messages

Biometric Attribute Type

Create Biometric Attribute

On receiving a request to add Biometric Attribute (e.g., Right Thumb, Left Thumb) with the input parameters (code, name, descr, bmtyp_code, lang_code and is_active), the system stores the Biometric Attribute in the Database as per the below steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • name - character (64) - Mandatory
   • descr - character (128) - Optional
   • bmtyp_code - character (36) - Mandatory
   • lang_code - character (3) - Mandatory
   • is_active - boolean - Mandatory
2. Responds with the Biometric Attribute Code and Language Code for the Biometric Attribute created successfully
3. The component restricts the bulk creation of Master Data
4. Responds to the source with the appropriate message.
5. In case of Exceptions, system triggers error messages as received from the Database

Fetch the List of Biometric Attributes based on the Biometric Authentication Type and a Language Code

On receiving a request to fetch the List of Biometric Attributes with input parameters (Biometric Authentication Type and Language Code), the system fetches the List of Biometric Attributes against the Biometric Authentication Type and the Language Code Received as per the below steps:

1. Validates if the request contains the following input parameters

   • Biometric Authentication Type - Mandatory
   • Language Code - Mandatory
2. If no data is present in the Database for the input parameter received, responds with an appropriate message.
3. If both the input parameter is missing, responds with all the data.
4. If one of the input parameters is missing, throw the appropriate message. Refer "Messages" section.
5. Validates if the response contains the List of Biometric Attributes with all the attributes against Biometric Authentication Type and Language Code Received

   • Biometric Attribute Code - Mandatory
   • Biometric Attribute Name - Mandatory
   • Biometric Attribute Description - Optional
   • IsActive – Mandatory
6. Responds to the source with the Fetched Data
7. In case of Exceptions, system triggers relevant error messages

Gender

Create Gender Types

1. This API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • name - Character - 64 - Mandatory
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message. Refer messages section
6. API should perfrom below multi-language validations on the Gender Type data recieved
7. If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Gender Type and throw an error message. Refer messages section
8. If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Gender Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
9. If all the above validations are successfull, the API should store the data the the database Gender Type Code should be generated at the back-end for any Gender Type added using a UUID generator
10. API should store cr_by as the Username of the user who is accessing this API
11. API should store cr_dtimes as the date-time at which the user is creating the Gender Type
12. API should only allow creation of one record at a time and should restrict bulk creation
13. API should audit the relevant data when the API is called successfully or when an error is encountered

Update a Gender Type

On receiving a request to update a Gender Type with the input parameters (code, name, lang_code and is_active), the system updates the Gender Type in the Gender Type Database for the code received as per the below steps:

1. This API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • code - Character - 36 - Mandatory
   • name - Character - 64 - Mandatory
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message. Refer messages section
6. If all the above validations are successfull, the API should update the data in the database agianst the code received
7. API should perfrom below multi-language validations on the Gender Type data recieved
8. If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Gender Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
9. API should store upd_by as the Username of the user who is accessing this API
10. API should store upd_dtimes as the date-time at which the user is modiying the Gender Type details
11. API should only allow creation of one record at a time and should restrict bulk creation
12. API should audit the relevant data when the API is called successfully or when an error is encountered

Check the existence of a Gender in Master Database

On receiving a request to validate the Gender Name with input parameters (Gender Name), the system checks the Gender Name in the Master Database as per the below listed steps:

1. Validates if the request contains the following input parameters

   • Gender Name - Mandatory
2. If the mandatory input parameters are missing, throws the appropriate message.
3. Responds to the source with the appropriate message
4. In case of Exceptions, system triggers relevant error messages

Fetch the List of Gender Types based on a Language Code

On receiving a request to fetch the List of Gender Types with the input parameters (Language Code), the system fetches the List of Gender Types against the Language Code received as per the below listed steps:

1. Validates if the request contains the following input parameters

   • Language Code - Mandatory
2. If the Language code is missing, responds with all the data.
3. Validates if the response contains the List of Gender Types with the following attributes

   • Gender Code
   • Gender Name
   • isActive
4. Responds to the source with the List of Gender Types
5. In case of Exceptions, system triggers relevant error messages

Document Category

Create Document Category in Master Database

On receiving a request to add Document Category with the input parameters (code, name, descr, lang_code and is_active), the system stores the Document Category in the Database as per the below listed steps:

1. This API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • name - Character - 64 - Mandatory
   • descr - Character - 128 - Optional
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message.
6. API should perfrom below multi-language validations on the Document Category data recieved
7. If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Document Category and throw an error message.
8. If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Document Category as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
9. If all the above validations are successfull, the API should store the data the the database
10. Document Category Code should be generated at the back-end for any Document Category added using a UUID generator
11. API should store cr_by as the Username of the user who is accessing this API
12. API should store cr_dtimes as the date-time at which the user is creating the Document Category
13. API should only allow creation of one record at a time and should restrict bulk creation
14. API should audit the relevant data when the API is called successfully or when an error is encountered

Update a Document Category in the Document Category Master Database

On receiving a request to update a Document Category with the input parameters (code, name, descr, lang_code and is_active), the system update the Document Category in the Document Category Database for the Code received as per the below listed steps:

1. The API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • code - Character - 36 - Mandatory
   • name - Character - 64 - Mandatory
   • descr - Character - 128 - Optional
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message.
6. If all the above validations are successfull, the API should update the data in the database agianst the code received
7. API should perfrom below multi-language validations on the Document Category data recieved
8. If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Document Category as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
9. API should store upd_by as the Username of the user who is accessing this API
10. API should store upd_dtimes as the date-time at which the user is modiying the Document Category details
11. API should only allow creation of one record at a time and should restrict bulk creation
12. API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch list of Document Categories based on a Language Code

On receiving a request to fetch Document Category Details with the input parameters (Language Code), the system fetches all the Document Categories for the Language Code Received as per the below listed steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • Language Code - Mandatory
2. If the mandatory input parameters are missing, responds with all the data.
3. Validates if the response contains the following attributes for the Document Category Code

   • Document Category Code - Mandatory
   • Document Category Name - Mandatory
   • Document Category Description - Optional
   • IsActive - Mandatory
4. In case of Exceptions, system triggers relevant error messages

Document Type

Create Document Type

On receiving a request to add Document Type with the input parameters (code, name, descr, lang_code and is_active), the system stores the Document Type in the Database

Refer below for the process:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • name - character (64) - Mandatory
   • descr - character (128) - Optional
   • lang_code - character (3) - Mandatory
   • is_active - boolean - Mandatory
2. The API should not allow creation of the Document Type if the data is not received in default language
3. If the data for the Document Type is not received in all the configured languages, the API should allow the Document Type to be created given the Point 2 is satisfied.
4. The API should activate the Document Type while creation provided data for all the configured languages is received during the initial creation
5. cr_by should be the Username of the user who is accessing this API
6. cr_dtimes should be the date-time when the user is creating the Document Type
7. If the data for all the configured languages is not received, deactivate the Document Type while creation
8. Responds with an appropriate message for the Document Type created successfully
9. In case of Exceptions, system triggers relevant error messages

Update a Document Type

On receiving a request to update a Document Type with the input parameters (code, name, descr, lang_code and is_active), the system updates the Document Type in the Document Type Database for the Code received

Refer below for the process:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • name - character (64) - Mandatory
   • descr - character (128) - Optional
   • lang_code - character (3) - Mandatory
   • is_active - boolean - Mandatory
2. For the code received in the request, replaces all the data received in the request against the data existing in the Document Type database against the same code
3. upd_by should be the Username of the user who is accessing this API upd_dtimes should be the date-time when the user updates the Document Type Details
4. The API should not allow activation of Document Type if the data for the Document Type is not present in all the languages which are configured for a country
5. While receiving the request for activation, If the Document Type is already Active, the API should throw an error message. Refer messages section.
6. While receiving the request for deactivation, If the Document Type is already Inactive, the API should throw an error message. Refer messages section.
7. Deleted record are not be updated
8. Responds with data not found error if deleted record is received in the request
9. Responds with the appropriate message for the Document Category updated successfully
10. In case of Exceptions, system triggers relevant error messages

Delete a Document Type

On receiving a request to delete a Document Type with the input parameters (code), the system updates the is_deleted flag to true in the Document Type Database against the code received

Refer below for the process:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
2. Delete all records for the code received
3. Deleted record are not be deleted again
4. Responds with data not found error if deleted record is received in the request
5. Responds with dependency found error if a record to be deleted is used as foreign key in the dependent table
6. Responds with the Document Category Code for the Document Category deleted successfully
7. In case of Exceptions, system triggers relevant error messages

Applicant Type - Document Category - Document Type Mapping

Fetch list of Document Categories based on Applicant Type from Master Database

Upon receiving a request to fetch List of Document Categories with the input parameters (Applicant Type Code), the system fetches all the Document Categories for the Applicant Type Code Received

While fetching the list of documents, the system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • Applicant Type Code - Mandatory
2. If the mandatory input parameter is missing, responds with the appropriate error message
3. Validates if the response contains the following attributes for each Document Category Code

   • Document Category Code
   • Name
   • Description
   • Language Code
   • Is Active
4. In case of Exceptions, system triggers relevant error messages

Fetch List of Document Category-Document Type mappings based on Applicant Type and a List of Language Codes

Upon receiving a request to fetch List of Document Category-Document Type mappings with input parameters (Applicant Type and List of Language Codes), the system fetches the required data

While fetching the data, the system performs the following steps:

1. Validates if the request contains the following input parameters

   • Applicant Type - Mandatory
   • List of Language Codes - Mandatory
2. If the mandatory input parameters are missing, throws the appropriate message.
3. Fetches the Document Category-Document Type mapping for all language codes received in response
4. The response contains the List of Mappings of Document Category and Document Type against each Document Category
5. Each Document Category contains the below attributes

   • Document Category Code
   • Name
   • Description
   • Language Code
   • Is Active
6. Each Document Type contains the below attributes

   • Document Type Code
   • Name
   • Description
   • Language Code
   • Is Active
7. In case of Exceptions, system triggers relevant error messages

Delete a Document Category-Type mapping in the Document Category-Type mapping Master Database

On receiving a request to delete a Document Category-Type mapping with the input parameters (doccat_code, doctyp_code), the system updates the is_deleted flag to true in the Document Category-Type mapping Database against the input received

The system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • doccat_code - character (36) - Mandatory
   • doctyp_code - character (36) - Mandatory
2. Responds with the doc_type Code and doccat_code for the Document Category-Type mapping deleted successfully
3. In case of Exceptions, system triggers relevant error messages.

Fetch applicant type based on Individual Type Code, Date of Birth, Gender Type Code and Biometric Exception Type

On receiving a request to get Applicant type with input parameters (Individual Type Code, Date of Birth, Gender Type Code and Biometric Exception Type), the system derives the Applicant Type from the input parameter and performs the following steps:

1. Validates if the request contains the following input parameters

   • Individual Type Code - Mandatory
   • Date of Birth - Mandatory
   • Gender Type Code - Mandatory
   • Biometric Exception Type - Optional
2. Derives the Age Group Type based on following logic

   • Child if Age < 5
   • Adult if Age >= 5
3. If the mandatory input parameters are missing, throws the appropriate message
4. Derives the applicant type as per the define logic
5. In case of Exceptions, system triggers relevant error messages

Check the mapping of Applicant Type-Document Category Name-Document Type Name

On receiving a request to check the mapping of Applicant Type-Document Category-Document Type mapping parameters (Applicant Type, Document Category Name and Document Type Name), the system checks the mapping and performs the following steps:

1. Validates if the request contains the following input parameters

   • Applicant Type Code
   • Document Category Name
   • Document Type Name
2. If the mandatory input parameters are missing, throws the appropriate message.
3. If the mapping exists, responds with "Valid".
4. If the mapping does not exist, responds with "Invalid".
5. In case of Exceptions, system triggers relevant error messages

List of Rejection Reasons

Create a Rejection Reason in Reason List Master Database

Upon receiving a request to add a Reason with the input parameters (code, name, descr, rsncat_code, lang_code and is_active), the system stores the Reason in the Database

The system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • code - character (64) - Mandatory
   • descr - character (256) - Mandatory
   • rsncat_code - character (36) – Mandatory (The parameter rsncat_code refers to a Language stored in Language Masterdata)
   • lang_code - character (3) – Mandatory (The parameter lang_code refers to a Language stored in Language Masterdata)
   • is_active - boolean - Mandatory
2. Validates if the response contains the following attributes for a Reason Category Code added

   • Code
   • Language Code
   • Rsncat_code (Reason Category Code)
3. Responds to the source with the appropriate message.
4. In case of Exceptions, system triggers relevant error messages.

Fetch the requested list of reasons based on Reason Category Code and Language Code

Upon receiving a request to Fetch the requested List of Reasons with the required input parameters (Reason 1. Category Code, Language Code), the system fetches the requested List of reasons stored against the Reason Category Code and Language Code received.

The system performs the following steps:

1. Validates if the request contains the following input parameters

   • Language Code - Mandatory
   • Reason Category Code - Mandatory
2. If either of the mandatory input parameters is missing, responds with the appropriate message as define below in message sections
3. Validates if the response contains the:

   • Requested list based on the requested Language Code and Reason Category Code
   • List of Reasons with the corresponding attributes for the list

     • Reason ID
     • Reason Name (per Reason ID)
     • Language Code
     • Reason Category Code
     • IsActive
4. Responds to the source with the relevant List of Reasons, as per the stated business rules
5. In case of Exceptions, system triggers relevant error messages as listed below

List of Languages

Create List of Languages

After receiving a request to add Language Details with the input parameters (code, name, family, native_name and is_active), the system stores the Language Details in the Database and performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (3) - Mandatory
   • name - character (64) - Mandatory
   • family - character (64) - Optional
   • native_name - character (64) - Optional
   • is_active - boolean - Mandatory
2. Responds with the Language Code for the language successfully created
3. In case of Exceptions, system triggers relevant error messages

Fetch the List of Languages

After receiving a request to fetch the List of Languages, the system fetches the List of Languages and performs the following steps:

1. Validates if the response contains the List of all Languages with the following attributes

   • Language Code - Mandatory
   • Language Name - Mandatory
   • IsActive – Mandatory
2. Responds to the source with the List of Languages
3. In case of Exceptions, system triggers relevant error messages

Update and Delete a Language in the List of Languages Master Database

Update

After receiving a request to update a Language with the input parameters (code, name, family, native_name and is_active), the system updates the Language Details in the List of languages Database for the Code received in request

The system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (3) - Mandatory
   • name - character (64) - Mandatory
   • family - character (64) - Optional
   • native_name - character (64) - Optional
   • is_active - boolean - Mandatory
2. For the Code received in the request, replaces all the data received in the request against the data existing in the List of languages database against the same code.
3. Deleted record are not updated
4. Responds with data not found error if deleted record is received in the request
5. Responds with the Language Code for the language successfully updated
6. In case of Exceptions, system triggers relevant error messages

Delete

After receiving a request to delete a Language with the input parameters (code), the system updates the is_deleted flag to true in the List of languages Database against the code received in request

The system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (3) - Mandatory
2. Deleted record should not be deleted again
3. Responds with data not found error if deleted record is received in the request
4. Responds with the Language Code for the language successfully deleted
5. In case of Exceptions, system triggers relevant error messages.

List of Titles

Create a Title

On receiving a request to add a Title (e.g., MR., Mrs.) with the input parameters (code, name, descr, lang_code and is_active), the system stores the Title in the Database and performs the following steps:

1. The API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • name - Character - 64 - Mandatory
   • descr - Character - 128 - Optional
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message. Refer messages section
6. API should perfrom below multi-language validations on the Title data recieved
7. If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Title and throw an error message. Refer messages section
8. If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Title as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
9. If all the above validations are successfull, the API should store the data the the database
10. Title Code should be generated at the back-end for any Title added using a UUID generator
11. API should store cr_by as the Username of the user who is accessing this API
12. API should store cr_dtimes as the date-time at which the user is creating the Title
13. API should only allow creation of one record at a time and should restrict bulk creation
14. API should audit the relevant data when the API is called successfully or when an error is encountered

Update a Title

On receiving a request to update a Title with the input parameters (code, name, descr, lang_code and is_active), the system updates the Title in the Title Database for the code received and performs the following steps:

1. This API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • code - Character - 36 - Mandatory
   • name - Character - 64 - Mandatory
   • descr - Character - 128 - Optional
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message. Refer messages section
6. If all the above validations are successfull, the API should update the data in the database agianst the code received
7. API should perfrom below multi-language validations on the Title data recieved
8. If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Title as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
9. API should store upd_by as the Username of the user who is accessing this API
10. API should store upd_dtimes as the date-time at which the user is modiying the Title details
11. API should only allow creation of one record at a time and should restrict bulk creation
12. API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch the List of Titles

On receiving a request to fetch Title Details with the input parameters (Language Code), the system fetches all the Titles with all the attributes for the Language Code Received

The system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • Language Code - Mandatory
2. If the mandatory input parameters are missing, responds with all the data.
3. Validates if the response contains List of Titles against the received Language Code along with the following attributes for the Title Code

   • Title Code - Mandatory
   • Title Name - Mandatory
   • Title Description - Optional
   • IsActive - Mandatory
4. In case of Exceptions, system triggers relevant error messages

Template File Format

Create Template File Format

On receiving a request to add Template File Format with the input parameters (code, descr, lang_code and is_active), the system stores the Template File Format in the Database and performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • descr - character (256) - Mandatory
   • lang_code - character (3) - Mandatory
   • is_active - boolean - Mandatory
2. Validates if the response contains the following attributes for a Template File Format added

   • Code
   • Language Code
3. Responds with the Template File Format Code and Language Code for the Template File Format created successfully
4. In case of Exceptions, system triggers relevant error messages.

Create Template File Format

Update and Delete a Template File Format in Template File Format Master Database

Update

On receiving a request to update a Template File Format with the input parameters (code, descr, lang_code and is_active), the system updates the Template File Format in the Template File Format Database for the Code received

While updating the Template File Format, the system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • descr - character (256) - Optional
   • lang_code - character (3) - Mandatory
   • is_active - boolean - Mandatory
2. For the code received in the request, replaces all the data received in the request against the data existing in the Template File Format database against the same code.
3. Deleted record are not updated
4. Responds with data not found error if deleted record is received in the request
5. Responds with the Template File Format Code and Language Code for the Template File Format updated successfully
6. In case of Exceptions, system triggers relevant error messages

Delete

On receiving a request to delete a Template File Format with the input parameters (code), the system updates the is_deleted flag to true in the Template File Format Database against the code received

While deleting the Template File Format, the system performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
2. Delete all records for the code received
3. Deleted record are not deleted again
4. Responds with data not found error if deleted record is received in the request
5. Responds with dependency found error (Refer Acceptance criteria) if a record to be deleted is used as foreign key in the dependent table
6. Responds with the Template File Format Code for the Template File Format deleted successfully
7. In case of Exceptions, system triggers relevant error messages.

List of Template Types

MOSIP system can create Template Type in the Master Database.

Upon receiving a request to add Template Type (e.g., SMS Notification template - New Registration) with the input parameters (code, descr, lang_code and is_active), the system stores the Template Type in the Database and performs the following steps:

1. Validates if all required input parameters have been received as listed below for each specific request

   • code - character (36) - Mandatory
   • descr - character (256) - Mandatory
   • lang_code - character (3) - Mandatory
   • is_active - boolean – Mandatory
2. Responds with the Template Type Code and Language Code for the Template Type created successfully
3. This component also restricts the bulk creation of Master Database
4. In case of Exceptions, system triggers relevant error messages as listed below.

List of Templates

Create Template

On receiving a request to add a Template with the input parameters (id, name, descr, file_format_code, model, file_txt, module_id, module_name, template_typ_code, lang_code and is_active), the system stores the Template in the Database and performs the following steps:

1. This API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • name - Character - 128 - Mandatory
   • descr - Character - 256 - Optional
   • file_format_code - 36 - Mandatory
   • model - Character - 128 - Optional
   • file_txt - Character - 4086 - Mandatory
   • module_id - Character - 36 - Mandatory
   • module_name - Character - 128 - Mandatory
   • template_typ_code - Character - 36 - Mandatory
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message.
6. 'file_format_code' received should be from list of 'codes' from 'template_file_format' masterdata table

   • If not, the API should throw an error.
7. 'template_typ_code' received should be from list of 'codes' from 'template_type' masterdata table

   • If not, the API should throw an error.
8. If all the above validations are successfull, the API should update the data in the database agianst the id received
9. API should perfrom below multi-language validations on the Template data recieved
10. If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Template as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
11. API should store upd_by as the Username of the user who is accessing this API
12. API should store upd_dtimes as the date-time at which the user is modiying the Template details
13. API should only allow creation of one record at a time and should restrict bulk creation
14. API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch Template based on a Template Type and a Language Code

On receiving a request to fetch a Template with the input parameters (Template Type Code and List of Language Code), the system fetches the Template for the Template Type Code and all Language Codes received

Refer below for the process:

1. Validates if all required input parameters have been received as listed below for each specific request

   • Template Type Code - Mandatory
   • List of Language Code - Mandatory
2. If the mandatory input parameters are missing, throws the appropriate message. Refer "Messages" section.
3. Response must contain templates for all the language codes received in the input parameter
4. Validates if the response contains the Template along with the following attributes

   • Template Type Code - Mandatory
   • Template - Mandatory
   • IsActive
5. In case of Exceptions, system triggers relevant error messages

Update a Template

On receiving a request to update a Template with the input parameters (id, name, descr, file_format_code, model, file_txt, module_id, module_name, template_typ_code, lang_code and is_active), the system updates the Template in the Template Database for the id received and performs the following steps:

1. This API should only be accessible to Global Admin
2. The API should accept only the below parameters

   • id - Character - 36 - Mandatory
   • name - Character - 128 - Mandatory
   • descr - Character - 256 - Optional
   • file_format_code - 36 - Mandatory
   • model - Character - 128 - Optional
   • file_txt - Character - 4086 - Mandatory
   • module_id - Character - 36 - Mandatory
   • module_name - Character - 128 - Mandatory
   • template_typ_code - Character - 36 - Mandatory
   • lang_code - Character - 3 - Mandatory
   • is_active - boolean (true/false) - Mandatory
3. All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
4. The API should validate the data type and length for each attribute as mentioned above.
5. In case of any failed validation, API should respond with appropriate error message. Refer messages section
6. 'file_format_code' received should be from list of 'codes' from 'tem