Overview

The Collection service is to serve as a revenue collection platform for all the billing systems through cash, cheque, demand draft, and swipe machines. It enables payment for all services provided by the eGov platform at a single point for the citizen and counter collection in municipal alike.

Pre-requisites

• Prior knowledge of Java/J2EE

• Prior knowledge of SpringBoot

• Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc

• Prior knowledge of Kafka and related concepts like Producer, Consumer, Topic, etc.

• The following services should be up and running:

  • egov-localization

  • egov-mdms

  • egov-idgen

  • egov-url-shortening

  • billing-service

Key Functionalities

• Allows citizens to create a payment.

• Allows employees to create the payment for the citizen indirectly.

• provides facilities to capture partial and advanced payments based on configs.

• allows payment cancellation to help with scenarios of bad checks and other failed payment scenarios.

• Integrates with billing service for demand back-update of payment.

Deployment Details

• deploy the latest version of the collection-services docker builds.

Configuration Details

The MDMS data configuration uses the same data updated by Billing-Service

Billing Service | Configuration-Details: Refer to the MDMS data config from here.

Following are the properties in the application.properties

Integration Details

Integration Scope

Collection service can be integrated with any organization or system that wants a payment system to keep track of its payments. Organizations can customize part of the application or its functionality based on their requirements.

Integration Benefits

• Easy payments and tracking of payments.

• Configurable functionalities according to client requirements.

Steps to Integration

• Customers can create a payment using the /payments/_create.

• Actors on the system can keep track of payments using /payments/_searchendpoint.

• Once the payment is done but it encounters a technical issue outside of the system then it can be cancelled with /payments/_workflow.

• For employees to access the payments API the respective module name should be appended after the payment API path - /payments/PT/_workflow - here PT refers to the property module.

IFSC Code Migration - Collection Service

• Port forward the collection service to the current environment where the IFSC CODE bank details data is to be migrated. Sample command - 1kubectl port-forward collection-services-76b775f976-xcbt2 8055:8080 -n egov

• Import postman collection from API list which refers as /preexistpayments/_update and runs with the same localhost to where we port forwarded using the above command.

• Expected result. In the EGCL_PAYMET table where IFSCODE data is present for those records, EGCL_PAYMET.ADDITIONALDETAILS bankdetails will be updated.

  Ex: For IFSCCODE : UCBA0003047 Response from API https://ifsc.razorpay.com/UCBA0003047 is updated in EGCL_PAYMET.ADDITIONALDETAILS as {"bankDetails": {"UPI": true, "BANK": "UCO Bank", "CITY": "BHIKHI", "IFSC": "UCBA0003047", "IMPS": true, "MICR": "151028452", "NEFT": true, "RTGS": true, "STATE": "PUNJAB", "SWIFT": "", "BRANCH": "BHIKHI", "CENTRE": "MANSA", "ADDRESS": "ADJOINING HP PETROL PUMP MANSA ROADDISTRICT MANSA","BANKCODE":"UCBA","DISTRICT":"MANSA","CONTACT":"+918288822548"}

Interaction Diagram

Billing-Collection-Integration Refer to the integration with details and explanation.

Reference Docs

Doc Links

API List

Overview

According to the new collection service, which follows the payment structure for storing information about payments and payment details, it is necessary to migrate the old collection structure into the new payment structure.

Migration Details

In the old collection service, for every transaction, the receipt number is generated on the bill detail level. Since the bill contains multiple bill details each transaction is mapped to multiple receipt numbers. So after payment of a single bill, multiple receipt numbers are generated. The mapping of the transactions to the receipt number changed in the new collection service.

In the new collection service, the receipt number is generated at the bill level. For each bill transaction, one receipt number is generated. So every bill for a consumer code and business service has one receipt number.

The records from tables egcl_receiptheader, egcl_receiptdetails, egcl_instrument, egcl_instrumentheader need to be transferred into tables egcl_payment, egcl_paymentdetail, egcl_bill, egcl_billdetial, egcl_billaccountdetail.

For smooth data transactions, the record from the old receipt is mapped according to the payment structure. The new payment response can be formed with receipt data.

The table below provides the mapping between receipt and payment structure with some remarks.

After the creation of the payment response with receipt data, it is pushed into the Kafka topic “egov.collection.migration-batch”. The persister inserts the payment data into tables - egcl_payment, egcl_paymentdetail, egcl_bill, egcl_billdetial, egcl_billaccountdetail.

Indexer config for the legacy data index and new payments.

persister config -

These need to get promoted before initiating the migration process. Migration happens through an API call, add role-actions based on your requirement. Otherwise, port-forwarding will work.

API Details

Endpoint: /collection-services/payments/_migrate?batchSize=100&offset= Body: { "RequestInfo": { "apiId": "Rainmaker", "action": "", "did": 1, "key": "", "msgId": "20170310130900|en_IN", "ts": 0, "ver": ".01", "authToken": "a6ad2a1b-821c-4688-a70e-4322f6c34e54" }

In case of any failure and restarting migration, take the value of offset and tenantId printed in the logs and resume the migration process.

/collection-services/payments/_migrate?batchSize=100&offset=200&tenantId='pb.tenantId'

Collection-service build:- collection-services-db:9-COLLECTION_MIGRATION-e9701c4

Overview

The Collection Service serves as a revenue collection platform for all the billing systems through cash, cheque, demand drafts, or the swipe machine. It enables payment for all services provided by the eGov platform at a single point directly from the citizen or over-the-counter collection within municipalities.

Pre-requisites

• Prior Knowledge of Java/J2EE

• Prior Knowledge of SpringBoot

• Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc

• Prior Knowledge of Kafka and related concepts like Producer, Consumer, Topic, etc.

• The following services must be up and running:

  • egov-localization

  • egov-mdms

  • egov-idgen

  • egov-url-shortening

  • billing-service

Key Functionalities

• Allows citizens to create a payment.

• Allows employees to create the payment for the citizen indirectly.

• Provides facilities to capture partial and advanced payments based on configs.

• Allows payment cancellation to help with scenarios of bad checks and other failed payment scenarios.

• Integrates with billing service for demand back-update of payment.

Deployment Details

• deploy the latest version of the collection-services docker builds.

Configuration Details

The MDMS data configuration uses the same data updated by the Billing-Service.

Billing Service | Configuration-Details: Refer to the MDMS data configuration here.

The table below lists the application properties.

Integration

Integration Scope

Collection service can be integrated with any organization or system that requires a payment system to keep track of its payments. Organizations can customize part of the application or its functionalities based on their requirements.

Integration Benefits

• Easy payments and tracking of payments.

• Configurable functionalities according to client requirement

Steps to Integration

1. Customers can create a payment using the /payments/_create

2. Actors on the system can keep track of payments using /payments/_searchendpoint

3. Once the payment is done and it encounters a technical issue that is beyond the system - the payment can be cancelled with /payments/_workflow

4. For employees to access the payments API the respective module name should be appended to the payment API path - /payments/PT/_workflow. Here PT refers to the property module.

Interaction Diagram

Billing-Collection-Integration - Refer to the integration details.

Reference Docs

Doc Links

API List