Request for Proposal s59

1 Introduction

1.1 Background

TINXSYS is a centralized system facilitating information exchange among the state CTD HQs for better administration of interstate trade. It is a repository of the information pertaining to the dealers and forms of the various states, registered under the CST Act and act as a data warehousing and business intelligence platform.

TINXSYS over the period of times has become a master repository of the information pertaining to the dealers of the various States. TINXSYS is conceived as a centralized system facilitating information exchange among the state CTD HQs for better administration of interstate trade.

2 Uptake Details for the TINXSYS Web Services

2.1 Validation TIN Number Service

The CTD officials are not able to verify the valid TIN No’s while issuing the C-Form to seller states. This API would enable the state to verify the counter party interstate dealer in any other State.

2.1.1 Assumption & Prerequisite

1. The state client side application should be able to consume web services published on public IP.

2. The issue of various forms of dealers should be through IT system.

3. The states should send the IP addresses of the production and development servers from where this API will be called. These IP addresses will be configured in the firewall as this will restrict the traffic to the configured IP addresses only.

4. The xml need not be encrypted for using this service.

2.1.2 Uptake Details

Client Web service needs to be developed by state SI in order to consume web services developed by Wipro based on WSDL file, request and response XMLs shared. It is based on JAVA, and uses TOMCAT server. The java is not a limiting factor and the web services can be developed in Java or DotNet.

Client Application can be developed taking reference from below mentioned WSDL file.

http://115.249.166.236:8080/SearchTINService/searchTIN?wsdl

2.1.3 Input / Output Parameters

Data to be sent to web service URL needs to be a sent in the below input format. The details of input/output is defined below:

S.No / Attribute Name / Description / Type/Length
Input Parameter
1 / TIN No / String(11)
Output Parameter
1 / DealerName / Dealer Name / String(99)
2 / address / Address of Dealer / String(180)
3 / mainBusinessNature / Nature of Business / String(100)
4 / registerDate / Registration Date / DD-MM-YYYY
5 / cancelDate / Cancellation Date is null for Active Dealers. / DD-MM-YYYY
7 / checkerDate / Date on which the data was uploaded by in TINXSYS system / DD-MM-YYYY
8 / active / A- Active , C- Cancelled / String(1)
9 / stateName / State Name / String(30)

2.1.4 Output xml Format

<dealerName>MANISH METAL WORKS</dealerName>

<address>43/21 EAST AZAD NAGAR DELHI </address>

<stateName>Delhi</stateName>

</tinSearchResponse>

2.1.5 Error Code

The defined error codes is mentioned below:

S.No / Error Codes / Description
1 / 400 / Invalid Tin Number
2 / 600 / Other Exception

2.1.6 Integration Steps and Code

1. Call wsdl url.

2. Create definition/ Qname

3. Call service

4. Consume web service method.

5. Sample code below.

URL url;
url = new URL(URL);
QName qname = new QName("http://searchtin/", "SearchTINImplService");
Service service = Service.create(url, qname);
SearchTIN s=service.getPort(SearchTIN.class);
String response=s.searchTIN(tin);

2.2 Create and Cancel Dealer Registration

Presently registration extraction process involves migration of each state data into central TINXSYS repository manually. Each of the states provides the registration data file in a particular directory at the client end. The Wipro team picks up the data from the specified directory for each states and uploads it manually. The MSP resource at CTD makes sure the data file is being placed in the defined directory.

In order to accomplish this we have two applications. One is the Server-side application and the other is Client Application (it is customized for each state based on whether state is giving access to DB, or keeping the files themselves).

State CTD will be giving the incremental registered data from the state VAT system on a daily basis in XML format. This data has to be consumed and updated in TINXSYS repository and appropriate response would be given back to state system, whether the updation in TINXSYS repository is successful or not.In case any data is not successfully updated in TINXSYS the same will be conveyed in response by TINXSYS web service with pre-defined error code. State VAT can provide the data again after necessary correction for updation in TINXSYS server.

This web service would be consumed by states to push the incremental dealer registration data onto central TINSYS system on a real time basis or near real time basis.

The states would be required to send the Dealer details data in a predefined xml format as specified by GSTN and invoke the API so that the dealer gets registered in TINXSYS system. The dealer details format will be shared with states after the API has been developed. The API would return appropriate status in case of success or failure.

2.2.1 Assumption & Prerequisite

1. The state client side application should be able to consume web services published on public IP.

2. The registration of dealers should be through IT system.

3. The IP address of the production and development server needs to be configured in the TINXSYS firewall.

2.2.2 Uptake Process

Below are the uptake processes that needs to be followed to uptake the Incremental Dealer Registration, Update and Cancel Registration API. The WSDL is same for Incremental, Update and Cancel API. Only the input xml method is different.

Client Application can be developed taking reference from below mentioned WSDL file.

http://115.249.166.236:8081/RegDatav1_uat/regDataService?wsdl

1. Create XML as shown below.

2. Convert it to String.

3. Encrypt the data with keyValue (provided during handshake).

4. Generate hashCode() of encrypted string.

5. Encrypt generate hashCode with hashKey (provided during handshake).

6. Put the hash in header map under key “hash”.

7. Send encrypted data.

8. Decrypt the response received

2.2.3 Input / Output Parameters

The details of the input / out parameters is mentioned below –

S.No / Attribute Name / Description / Type/Length
1 / userId / User Id of State / VARCHAR2(10)
2 / Password / Password – States is free to change password at the TINXSYS portal and send the same. / VARCHAR2(10)
2 / tin / TIN Number / VARCHAR2(11)
4 / cst / CST Number / VARCHAR2(30)
5 / name / Dealer Name / VARCHAR2(60)
6 / address1 / address1 / VARCHAR2(60)
7 / address2 / address2 / VARCHAR2(60)
8 / address3 / address3 / VARCHAR2(60)
9 / address4 / address4 / VARCHAR2(60)
10 / address5 / address5 / VARCHAR2(60)
11 / address6 / address6 / VARCHAR2(60)
12 / distcode / District Code / VARCHAR2(10)
13 / offcode / Office Code / VARCHAR2(10)
14 / businessnature / Business Nature (Manufacturing/Trading/Retailer/etc.) / VARCHAR2(100)
15 / registrationdate / Registration Date / DD-MON-YYYY
16 / pandetails / PAN Number / VARCHAR2(10)
17 / method / Method are : create / update/cancel

2.2.4 Sample Create xml

The below is the sample xml that the states needs to send to TINXSYS system:

<Password>password</Password>

</authentication>

<address1>address1</address1>

<address2>address2</address2>

<address3>address3</address3>

<address4>address4</address4>

<address5>address5</address5>

<address6>address6</address6>

<businessnature>businessnature</businessnature>

<businessstyle>businessstyle</businessstyle>

<pandetails>pandetails</pandetails>

<method>create</method>

2.2.5 Sample Update xml

<Password<password</Password>

</authentication>

<address1>address1</address1>

<address2>address2</address2>

<address3>address3</address3>

<address4>address4</address4>

<address5>address5</address5>

<address6>address6</address6>

<businessnature>businessnature</businessnature>

<businessstyle>businessstyle</businessstyle>

<pandetails>pandetails</pandetails>

<method>update</method>

<canceldate</canceldate>

2.2.6 Sample Cancel xml

<Password>password</Password>

</authentication>

<name</name>

<address1</address1>

<address2</address2>

<address3</address3>

<address4</address4>

<address5</address5>

<address6</address6>

<distcode</distcode>

<offcode</offcode>

<businessnature</businessnature>

<businessstyle</businessstyle>

<registrationdate</registrationdate>

<pandetails</pandetails>

<method>cancel</method>

2.2.7 Security of xml

The web service takes XML in form of String as an input encrypted by AES 256-bit. Accordingly a String response is provided encrypted in same format.

Data encryption and decryption code is attached. Refer Annexure – A.

2.2.8 Error Codes

S.No / Error Codes / Description
1 / 100 / Failure in decryption
2 / 200 / XML received not complaint with XSD
3 / 300 / UserID/Password invalid
4 / 400 / TIN data already exist
5 / 500 / Data value is not valid (TIN, CST, ADDRESS, etc.)
6 / 600 / other exception

Version .1.0

CONFIDENTIAL Page 9 of 9