Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
eChallan system enables employees to generate the challans for Adhoc services so that the payment can be recorded into the system along with service-specific details.
It also enables citizens to make payments online based on challan no.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has workflow persister config path added in it
PSQL server is running and a database is created to store workflow configuration and data
Allow the employee to capture service details for miscellaneous services and collect payment
Allow the employee to update / cancel challan.
Search, download, and print echallan / bill for miscellaneous service
Generate and view echallan / bill pdf for all miscellaneous and ad-hoc services
Send SMS and an email bill notification to the citizen with a payment link and bill link
Actions
Role Action Mapping
Roles to be available:
Add MDMS configs required for eChallan Service and calculator and restart MDMS service
Deploy the latest version of eChallan Service and calculator
Add eChallan Service persister yaml path in persister configuration and restart persister service
Add Role-Action mapping for API’s
Add pdf configuration file for challan and bill
The eChallan service is used to generate e-challans / bill for all miscellaneous / adhoc services which citizens avail from ULBs.
Can perform service-specific business logic without impacting the other module.
Provides the capability of capturing the unique identifier of the entity for which the challan is generated.
In the future, if we want to expose the application to citizens then it can be done easily.
Workflows or Service-specific workflows can be enabled at the challan service level at any time without changing the design.
Allow an employee to update/cancel challan
To integrate, a host of echallan-services modules should be overwritten in the helm chart.
echallan-services/eChallan/v1/_create should be added as the create endpoint for creating eChallan in the system
echallan-services/eChallan/v1/_search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria
echallan-services/eChallan/v1/_update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.
(Note: All the APIs are in the same Postman collection therefore the same link is added in each row)
| Title | Link |
|---|---|
| Title | Link |
|---|---|
API Swagger Documentation
echallan-services/eChallan/v1/_create
echallan-services/eChallan/v1/_update
echallan-services/eChallan/v1/_search
echallan-services/eChallan/v1/_count
Service configuration details are available on the links below.
We are using re-indexing to get all the data to the respective indexer. We have 2 steps for this. The first is to run the connector from the playground, which is followed by the legacyindexer service call from the indexer service, which internally calls the respective plain search service to get the data and send it to the respective indexer.
Access to kubectl of the environment targetted
Postman scripts
Plain search apis in the respective services
mCollect/echallan-services reindexing steps
Configure the eChallan indexer with the configKey as LEGACYINDEX with the new topic name in the respective indexer yaml file
Connect to playground pod.
Delete the kafka connector if already exists with the kafka connection, using below command through playground pod.
Run the below kafka connector curl from playground pod:
port forward to egov-indexer pod and run below curl throw postman
Delete the kafka connection after all the data has been re-indexed by follwing below command through playground pod
Alias firenoc-services-enriched as water-services through kibana server.
NOW your echallan-services index is updated with the eChallan/mCollect data.
e-Challan Calculator service is used to calculate the e-challan amount based on the details present in the e-challan request. This module is designed in such a way that it can be used to serve e-challan for different types of services.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running.
PSQL server is running and a database is created to store eChallan Calculator Application data.
Following services should be up and running:
egov-mdms
echallan-services
billing-service
e-challan service internally call e-challan-calculator to generate demand.
Based on the tax head and tax amount defined in e-challan request, e-challan calculator service creates the demand.
After Demand creation, it calls the billing service to generate the fees.
MDMS Config
Define the tax period in the below MDMS file for the business service defined in the e-challan service.
https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/BillingService/TaxPeriod.json
Define the tax head in the below MDMS file for the business service defined in the e-challan service.
https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/BillingService/TaxHeadMaster.json
Define the action and role action mapping for the APIs in the below MDMS files.
Add MDMS configs required for e-Challan Service and calculator and restart MDMS service.
Deploy the latest version of e-Challan Service and calculator.
Add e-Challan Service persister yaml path in persister configuration and restart persister service
Add role-action mapping for APIs.
e-Challan-calculator is integrated with e-Challan-services. The e-Challan-services internally invoke the e-Challan-calculator service to calculate and generate demand for the e-Challan request.
The e-Challan calculator application is used to calculate the e-Challan Fees based on the data mentioned in e-Challan creation. Based on the tax amount mentioned in the e-Challan, demand is created. So because of the e-Challan calculator, the calculation and demand generation logic is separated out from eChallan services. So in future, if calculation logic requires changes, the modifications can be carried out for each implementation without making any changes to the e-Challan services.
e-Challan service application needs to call the eChallan-calculator/v1/_calculate API to calculate and generate the demand for the e-Challan application.
Provide employees with the option to Cancel a Receipt for a specific receipt number.
Route - mSeva
The search page displays the receipts. Click on the specific receipt number navigates the user to view the receipt details.
View receipt details are available here https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/receipts/src/pages/ReceiptDetails.js
The initial MDMS call is made on page load. CancelReceiptReason MDMS is used to display multiple reasons for cancelling.
Action modal - This appears with the click of Cancel Receipt. The cancel receipt action is shown only for the following state of receipt.
Receipt?.paymentStatus !== "CANCELLED" && Receipt?.paymentStatus !== "DEPOSITED" && (Receipt?.instrumentStatus == "APPROVED" || Receipt?.instrumentStatus == "REMITTED"
Data fetch, load and render
Once the Receipt is searched using collection-services/payments/{selectedbusinessService}/_search API, the user can cancel the receipt using /collection-services/payments/{selectedbusinessService}/_workflow API
Acknowledgement screen It gets shown once the cancel receipt is clicked. File details - https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/receipts/src/pages/ReceiptAcknowledgement.js
To provide users with the bill details and the options to cancel the bill.
The screen development file is available in the egov-abg-dev folder within the below link:
The details of the Bill are fetched by calling BillingService fetchBill API and the Consumer.No is used in the query param.
FetchBill API returns the Bill Object which contains all the details about the bill including Billing Period, Due Amount, Due Date, and information about the Tax, Cess, Rebate, and Penalty applied to this bill.
NextStep - On clicking on the next step, the screen navigates to the cancel bill screen. The user must select the option that best states the reason for bill cancellation. More details for the cancel bill screen is available on this page - Cancel Bill
Frontend Repo
Once the user logs in with WS_CEMP or SW_CEMP roles the BillGenie tree option is available on the left panel of the screen.
Clicking on the BillGenie displays two options as seen in the screenshot below.
Click on the Bill Cancellation option. This routes the user to the search bill screen.
Objective: This option allows employees to search for active bills, download bills, or cancel bills.
For instance, a bill can be cancelled if the tax head information is entered wrong in a bill.
Route - mSeva
Initial MDMS call is made on page load
Note: The search, cancel bill and service category options are available only for enabled services. This is configured in uiCommonPay config by marking the followingcancelBill path as true.
Example:
Table Structure
MUIDataTable is used to implement the table component.
Every column entry is treated as an object.
Any customizations at column level are done through the customBodyRender hook available with the option property of the columns.
Once the data is fetched using egov-searcher/bill-genie/billswithaddranduser/_get API, the returned data is formatted and dispatched to redux.
As seen in the above screenshot, the data is assigned to a specific path inside props.
The table component now fetches the data from its props as shown below.
To cancel bills, employees have to click on the Cancel Bill option. The system navigates to the Bill Details page that displays the bill amount and other details. The bill can be cancelled from this page.
For bill details refer to the document here - Bill Details.
egov-mdms-service/v1/_search,
egov-searcher/bill-genie/billswithaddranduser/_get
Technical Doc
DSS has two sides to it. One is the process in which the Data is pooled into ElasticSearch and the other is the way it is fetched, aggregated, computed, transformed and sent across.
As this revolves around a variety of data sets, there is a need for making this configurable. So that, tomorrow, given a new scenario is introduced, it is just a configuration away from getting the newly introduced scenario involved in this flow of the process.
This document explains the steps on how to define the configurations for the analytics side of DSS for W&S.
What is analytics?
Analytics: Micro Service which is responsible for building, fetching, aggregating and computing the Data on ElasticSearch to a consumable Data Response. Which shall be later used for visualizations and graphical representations.
Analytics Configurations: Analytics contains multiple configurations. we need to add the changes related to mCollect in this dashboard analytics.
Here is the location : configs/egov-dss-dashboards/dashboard-analytics at qa · egovernments/configs
Below is a list of configurations that need to be changed to run W&S successfully.
Chart API Configuration
Master Dashboard Configuration
Role Dashboard Mappings Configuration
Chart API Configuration
Each visualization has its own properties. Each visualization comes from different data sources (Sometimes it is a combination of different data sources).
In order to configure each visualization and its properties, we have a Chart API Configuration Document.
In this, the visualization code, which happens to be the key, will have its properties configured as a part of the configuration and are easily changeable.
Here is the sample ChartApiConfiguration.json data for the mCollect.
Click here for the complete configuration
The master dashboard configuration is the main configuration which defines the Dashboards to be painted on screen. It includes all the visualizations, their groups, the charts which comes within them and even their dimensions as what should be their height and width.
Click here for the complete configuration
The master dashboard configuration explained earlier holds the list of dashboards which are available. Given the instance where Role Action Mapping is not maintained in the Application Service, this configuration will act as a role-dashboard mapping configuration.
In this, each role is mapped against the dashboard which they are authorised to see. This was used earlier when the role action mapping of eGov was not integrated. Later, when the role action mapping started controlling the dashboards to be seen on the client side, this configuration was just used to enable the dashboards for viewing.
Click here for the complete configuration
common-masters/uiCommonConstants.json
Click here for the complete configuration
roleaction.json
Click here for the complete configuration
Action test.json
Click here for complete configurations
mCollect-DSS consists of multiple graphs which represent the data of W&S. Each graph has its own configuration which will describe the chart and its type.
DSS consists of the following charts in mCollect:
Overview
Total Cumulative Collection
Receipts by Payment Mode
Collection By Payment Mode
Challan Count by Status
Receipts Count By Status
Collection By Status
Top Categories Collections
Monthly Collections
Collection Report
Overview: The Overview graph contains multiple data information as below in the selected time period.
Today’s Collection: This represents today’s collection amount for mCollect
Total Collection: This represents the total collection amount for mCollect
Total Challans: This represents the total number of challans created.
Total Receipts: This represents the total number of receipts.
Total Categories: Number of categories against which miscellaneous collections have been made.
Total Cumulative Collection: This Graph contains the mCollect collection amount information on a monthly base as a cumulative line graph. This will change as per the denomination amount filter selection.
line - this graph/chart is data representation on date histograms or date groupings.
Receipts by Payment Mode: This graph represents the number of receipts according to the payment mode used.
Collection by Payment Mode: This graph represents the total collection according to the payment mode used.
Challan Count By Status: This graph shows the total number of challans according to status
Receipts Count by Status: This graph shows the total number of receipts according to status
Collection by Status: This graph shows the total collection according to status
Top Categories Collection: This graph shows the category-wise collection for all the categories in descending order.
Monthly Collections: This shows the monthly break-up of total collections and the total number of receipts.
Collection Report: This tabular chart representation graph shows multiple mCollect information like Total Challans, Total Collection and the total number of receipts. This table also shows the data at the district level and the drill-down chart for each district to ULB and from ULBs to ward level data for the same.
xtable type allows the addition of multiple computed fields with the aggregated fields dynamically added.
To add multiple computed columns, computedFields [] where actionName (IComputedField<T> interface), fields [] names as in exist in query key, newField as name to appear for computation must be defined.
Clicking on any district name drills down charts to provide the data specific to the listed District.
Clicking on the ULB navigates to the wards for the specified ULB and displays the ward-specific data.
Key(eg: fsmTotalrequest): This is the Visualization Code. This key will be referred to in further visualization configurations. This is the key which will be used by the client application to indicate which visualization is needed for display.
chartName: The name of the Chart which has to be used as a label on the Dashboard. The name of the Chart will be a detailed name.
In this configuration, the Name of the Chart will be the code of Localization which will be used by the Client Side.
queries: Some visualizations are derived from a specific data source. While some others are derived from different data sources and are combined together to get a meaningful representation.
The queries of aggregation which are to be used to fetch the right data in the right aggregated format are configured here.
queries.module: The module/domain level, on which the query should be applied on.
queries.indexName: The name of the index upon which the query has to be executed is configured here.
queries.aggrQuery: The aggregation query in itself is added here. Based on the Module and the Index name specified, this query is attached to the filter part of the complete search request and then executed against that index
queries.requestQueryMap: Client Request would carry certain fields which are to be filtered. The parameters specified in the Client Request are different from the parameters in each of these indexed documents.
In order to map the parameters of the request to the parameters of the ElasticSearch Document, this mapping is maintained.
queries.dateRefField: Each of these modules have separate indexes. And all of them have their own date fields.
When there is a date filter applied against these visualizations, each of them has to apply it against their own date reference fields.
In order to maintain what is the date field in which index, we have this configured in this configuration parameter.
chartType: As there are different types of visualizations, this field defines what is the type of chart/visualization that this data should be used to represent.
metric - this represents the aggregated amount/value for records filtered by the aggregate es query
pie - this represents the aggregated data on grouping. This is can be used to represent any line graph, bar graph, pie chart or donuts
line - this graph/chart is data representation on date histograms or date groupings
perform - this chart represents groping data performance-wise.
table - represents a form of plots and values with headers as grouped on and a list of its key, values pairs.
xtable - represents an advanced feature of the table - it has the capabilities for dynamically adding header values.
valueType: In any instance of data, the values which are sent for plotting, might be a percentage, sometimes an amount and sometimes it is just a count.
In order to represent them and differentiate the numbers from the amount from the percentage, this field is used to indicate the type of value that this Visualization will be sending.
action: Some of the visualizations are not just aggregations of data sources. There might be some cases where we have to do a post-aggregation computation.
documentType: The type of document upon which the query has to be executed is defined here.
drillChart: If there is a drill down on the visualization, then the code of the Drill Down Visualization is added here. This will be used by Client Service to manage drill-downs.
aggregationPaths: All the queries will be having Aggregation names in them. In order to fetch the value out of each Aggregation Responses, the name of the aggregation in the query will be an easy bet. These aggregation paths will have the names of Aggregation in them.
insights: It is to show the data with the comparison of last year with arrow symbols, it will show the data in how much % is increased or decreased.
_comment: In order to display information on the “i” symbol of each visualization, Visualization Information is maintained in this field.
To provide users with the option to select cancel reasons and the options to cancel the bill.
The screen development files are available in the egov-abg-dev folder within the below-mentioned link.
The reasons for bill cancellation options are fetched from the MDMS service.
PREVIOUS STEP: Clicking on the Previous Step option redirects users to the bill details screen.
Clicking on the cancel bill option triggers the cancel bill API (billing-service/bill/v2/_cancelbill ). Once the API call is successful it routes to the acknowledgement screen.
The Next Step button file is available in the below-mentioned file path.
Acknowledgement Screen
For localisation, the “rainmaker-ws” and “rainmaker-abg” modules are re-used. In case they are any new keys, these are added under “rainmaker-abg”.
Challans are created using create Challan, it is explained in
Provide Employee to update / Cancel / Pay Challan against a Challan number.
Route -
After searching for a Challan with a click on the Challan number it navigates to viewing the Challan details. The view Challan details is mentioned over
Action modal - This comes up on the click of cancel Challan.
Click on yes, the challan will be cancelled and users will be routed to the acknowledgement screen.
Clicking on the Update Challan option updates and routes users to the acknowledgement screen.
The common pay screen is visible once the user clicks on the Pay Challan/Proceed button to payment from the acknowledgement screen.
This pay screen is common for all the modules.
Clicking on the Collect Payment button payment allows users to collect and route to the acknowledgement screen it is common for all modules.
Click on Print Receipt, qa.digit.org/collection-services/payments/{challanBusinessService}/_search (we need to configure bussinessServices to the respective roles in the MDMS like below ) API will get the payment response, by using that response again we need to call pdf-service/v1/_create API.
Data fetch, load and render
Once the Challan is searched using echallan-services/eChallan/v1/_search API, then we can search for bill details using billing-service/bill/v2/_search for the tax head breakup information.
For Updating/Cancelling the Challan, we can use the API /echallan-services/eChallan/v1/_update.
download/print Challan using egov-pdf/download/UC/mcollect-challan API.
rainmaker-uc
egov-mdms-service/v1/_search
echallan-services/eChallan/v1/_update
egov-pdf/download/UC/mcollect-challan
echallan-services/eChallan/v1/_search
billing-service/bill/v2/_search
collection-services/payments/ADVT.Gas_Balloon_Advertisement/_search we need to pass the businessService (collection-services/payments/{businessService}/_search ).
collection-services/payments/_create
billing-service/bill/v2/_fetchbill
pdf-service/v1/_create
Provide employees with the option to create Challan, by selecting the service category, and entering all consumer information and tax head details.
Created hooks for MDMS in mCollect, by using hooks will get the response by passing on the details in the method.
Based on the response, Service Type and Service category Dropdowns are Loaded. For eg: Refer to the response object
Based on that "businessService": "WaterCharges.Metered"
The service Category will be "WaterCharges"
The service Type will be "Metered"
Based on the MDMS response TaxHeadMaster are formed by the selected service type dropdown. Filter the initial Taxhead master with the selected service type with service the attributes in each Taxheads.
createChallan the method is used to create challan.
/echallan-services/eChallan/v1/_create API is used to create a challan.
Once Challan is created successfully, you will be able to see the Challan Acknowledgement.
Actions available:
Print Challan
Go to home
Proceed to Payment
Print Challan: Click on Print Challan, Challan will be downloaded using egov-pdf/download/UC/mcollect-challan API.
Go to home: Click on Go TO Home routes users to the home screen.
rainmaker-uc
egov-mdms-service/v1/_search
echallan-services/eChallan/v1/_update
egov-pdf/download/UC/mcollect-challan
collection-services/payments/ADVT.Gas_Balloon_Advertisement/_search we need to pass the businessService (collection-services/payments/{businessService}/_search ).
collection-services/payments/_create
billing-service/bill/v2/_fetchbill
pdf-service/v1/_create
Provide employees with the option to search challans, download receipts, check the current status, cancel challans, update challans and collect payment.
Once the user login with UC_EMP Role, then the User will get the mCollect module card with the Total Challan Count.
The clicking of Search Challan navigates to the Inbox/search challan screen.
Inbox File link -
Clicking on the Collect button routes users to the common-pay screen with the URL.
example: “https://qa.digit.org/digit-ui/employee/payment/collect/{selectedbusinessService}/{selectedChallanNumber}/tenantId={tenantId}?workflow=mcollect”
This screen is common for all modules.
On Click on download receipt, able to download the receipt of the respective challan number using pdf service API egov-pdf/download/PAYMENT/consolidatedreceipt.
MDMS Configs used in this inbox screen - applicationStatus to show all required statuses in the inbox, similarly uiCommonPay to get service categories.
Table Structure
Uses the same table component similar to other modules.
Once the data is fetched using echallan-services/eChallan/v1/_search API is being used to search and get data, after that using consumer codes, need to call fetch Bill API billing-service/bill/v2/_fetchbill to get bills for respective challan for showing status, amount and date etc.
The count APIechallan-services/eChallan/v1/_count to get the count of total challans.
rainmaker-uc
egov-mdms-service/v1/_search
echallan-services/eChallan/v1/_create
egov-pdf/download/UC/mcollect-challan
echallan-services/eChallan/v1/_count
This page offers the UI details for the search and pays challan feature. Once a challan is created, in order to pay the challan or update the challan, we have to find the relevant challan.
A citizen can only search for the challan, download the challan, and pay for the challan.
In order to make any payment for challans, both Citizen and Employee roles, use the Bill genie screens to get the bill and can proceed with payment.
To enable the service category to search we have to configure billGineiURL in MDMS as follow.
Once billGineiURL is configured for a service, we get an option in bill genie to search for it.
Once the challan is created to Update or cancel challan we use Challan Search.
rainmaker-uc
API Used
egov-mdms-service/v1/_search
echallan-services/eChallan/v1/_search
Provide employees with the option to search receipts specific to a module, download receipts, check the current status and cancel selected receipts.
Once the user logins with the CR_PT role, the system displays the Receipts module card along with the Total Receipts count.
Clicking on the Search Receipts redirects users to the Inbox/search receipt screen.
MDMS Configs used in this inbox screen ReceiptStatus show the required status in the inbox similarly uiCommonPay fetches the service categories.
The Search and Cancel Receipts option is available only for enabled services. This is configured in uiCommonPay config by setting true the cancelReceipt.
Table Structure
Uses the same table component similar to other modules.
Once the data is fetched using collection-services/payments/{selectedbusinessService}/_search API is used to search and get the required receipt details.
The Same API collection-services/payments/{selectedbusinessService}/_search with a flag isCountRequest to get the required count of total receipts.
Localisation Modules used
rainmaker-common rainmaker-receipts
To enable multiple business services -
MDMS needs to be updated ascancelReceipt : truefor that specific business service.
Role Actions, update the payment search and workflow API for the new USER Role.
Only the CR_PT role is allowed to use this module.
This document provides details about the edit challan feature in the mCollect module. Challans are created using create challan option explained in the page.
The edit challan workflow enables users to make any correction in the challan or even cancel created challans.
Use the search tool to find the relevant challan and edit it. The Search and Pay Challan page provides information on how to use the search tool.
Click on the search result to navigate to the view challan screen. The service details are .
Here we use echallan-services/eChallan/v1/_search API to get the Challan Information andbilling-service/bill/v2/_searchto the tax head breakup information. Download/Print using egov-pdf/download/UC/mcollect-challan API.
Actions
Update challan to edit
Cancel challan
To cancel challan, click on cancel and enter the reason for cancellation. This action calls the echallan-services/eChallan/v1/_update API to cancel.
Update challan can be used to edit only Tax head information. Any other information that is freezed, can be changed accordingly to support the requirement.
Once you click on update challan echallan-services/eChallan/v1/_update? API will be called and the challan will be updated accordingly.
rainmaker-uc
API Used
egov-mdms-service/v1/_search
echallan-services/eChallan/v1/_update
egov-pdf/download/UC/mcollect-challan
echallan-services/eChallan/v1/_search
billing-service/bill/v2/_search
UI details for eChallan feature in mCollect module
This page offers a detailed insight into the user interface features, screens, and navigation available for the eChallan service in the mCollect module. Browse through this document to find the e-Challan service details, MDMS and localization details.
Objective
Generate e-challans / bills for all miscellaneous / Adhoc services which citizens avail from ULBs
The ability for ULBs to Notify citizens about outstanding payments - Online and offline
Enable Digital payments for citizens - QR code, payment link in notifications, etc.
Employees can Create Challan, by selecting the service category, and entering all consumer information and tax head details.
Selecting City is disabled as UC Employee of City A should be able to access/create only City A-related challans.
Based on the response, Service Type and Service category Dropdowns are Loaded. For eg: Refer to the response object
Based on that "businessService": "WaterCharges.Metered"
Based on the MDMS response TaxHeadMaster are formed by the selected service type dropdown.
Filter the initial Taxhead master with the selected service type with service attribute in each Taxheads.
createChallan method is used to create challan.
/echallan-services/eChallan/v1/_create API is used to create a challan.
Users will be able to see the Challan Acknowledgement once the Challan is created successfully,
Actions available:
Proceed to Payment
Download/print Challan
Navigate back to the Home page
Challan’s can be downloaded through this API egov-pdf/download/UC/mcollect-challan?challanNo=
rainmaker-uc
API Used
egov-mdms-service/v1/_search
echallan-services/eChallan/v1/_create
egov-pdf/download/UC/mcollect-challan
| Title | Link |
|---|---|
| Title | Link |
|---|---|
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
| API | Roles | Action ID |
|---|---|---|
The Next Step button file is available in the file path below: frontend/viewBillFooter.js at master · egovernments/frontend
| API | Action ID | Roles |
|---|---|---|
Initial page - frontend/billSearch.js at master · egovernments/frontend
Form rendering details available in frontend/billSearchCard.js at master · egovernments/frontend
Table rendering details available in frontend/searchResults.js at master · egovernments/frontend
The Bill Search API and formatting data is available in frontend/function.js at master · egovernments/frontend
| API | Roles | Action ID |
|---|---|---|
| API | Action ID | Roles |
|---|---|---|
File path of acknowledgement screen:
Update Challan screen, This comes up on the click of update Challan ( ).
File path:
File Path:
| API | Roles | Action ID |
|---|
| Related Title | Documentation |
|---|
File Path:
Digit.MDMSService.getPaymentRules(tenantId, "[?(@.type=='Adhoc')]"); which is present in the below file:
MDMS File path:
Other Validations and Create challan can be referred in
File Path:
Proceed To Payment: Clicking on this routes users to the common pay screen and it is common for all modules also refer to .
| API | Roles | Action ID |
|---|
| Related Title | Documenation |
|---|
Route -
On search results we can click on the challan number to update/cancel any challan, it is explained in the following documentation -
| API | Roles | Action ID |
|---|
| Related Title | Documentation |
|---|
Click here to find the and the .
| API | Roles | Action ID |
|---|
| Related Title | Documentation |
|---|
All content on this page by is licensed under a .
Route -
Inbox File details
On the search results page, users can click on the receipt number to cancel any receipt. The details of this are available in the following document -
Function logic should be updated to support multiple services. getDefaultReceiptService = () => { return RECEIPTS_DEFAULT_SERVICE;}
| API | Roles | Action ID |
|---|
| API | Roles | Action ID |
|---|
| Related Title | Documentation |
|---|
All content on this page by is licensed under a .
Click here to find the .
The service Category is "WaterCharges" and the service Type is "Metered"
The conversion of business Service utils is setServiceCategory method present in ``
Other Validations and Create challan can be referred to in
| API | Roles | Action ID |
|---|
| Related Title | Documentation |
|---|
All content on this page by is licensed under a .
egov-mdms-service/v1/_search
CR_PT
954
collection-services/payments/PT/_search
CR_PT
2029
/collection-services/payments/PT/_workflow
CR_PT
2028
/ws-calculator/meterConnection/_search
1936
EMPLOYEE
/billing-service/bill/v2/_fetchbill
1862
EMPLOYEE
/ws-services/wc/_search
1900
SW_CEMP , WS_CEMP
/sw-services/swc/_search
1940
SW_CEMP , WS_CEMP
/property-services/property/_search
1897
SW_CEMP , WS_CEMP
egov-mdms-service/v1/_search
954
egov-searcher/bill-genie/billswithaddranduser/_get
SUPERUSER , EMPLOYEE
1804
billing-service/bill/v2/_cancelbill
1936
SUPERUSER, SW_CEMP, WS_CEMP
egov-mdms-service/v1/_search
954
echallan-calculator/v1/_calculate
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 954 |
| UC_EMP | 2114 |
|
|
|
|
|
|
egov-mdms-service/v1/_search | 954 |
echallan-services/eChallan/v1/_update | UC_EMP | 2117 |
egov-pdf/download/UC/mcollect-challan | UC_EMP | 2115 |
echallan-services/eChallan/v1/_search | UC_EMP | 2114 |
billing-service/bill/v2/_search | 1861 |
| 954 |
| UC_EMP | 2112 |
| UC_EMP | 2115 |
API Swagger Contract
eChallan Service Document
MCollect Create Challan |
MCollect Search Challan |
MCollect Search |
MCollect Update/Cancel Challan |
MCollect Create Challan |
MCollect Edit / Update Challan |
MCollect Create Challan |
MCollect Pay Challan |
MCollect Edit / Update Challan |
MCollect Create Challan |
MCollect Search Challan |
MCollect Pay Challan |
MCollect Search Challan |
MCollect Pay Challan |
MCollect Edit / Update Challan |
