# E-Marketplace Developed by Ravi Prakash, Dr. P. S. Ramkumar, Vikash Madduri, Caroline Mulligan, Ibrahim Elbhery, Mohammed Elgendy, Sujith Nair, Umesh Mohanty, Bharath Ganapathy, Ben Vandersteen, Gavin Hayman # 1 Version History The version history table describes the major changes to the specifications between published versions. | Version | Authors | Comment | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------- | | 0.1 | Ravi Prakash, Dr. P. S. Ramkumar, Vikash Madduri, Caroline Mulligan, Ibrahim Elbhery, Mohammed Elgendy, Sujith Nair, Umesh Mohanty, Bharath Ganapathy, Ben Vandersteen, Gavin Hayman | Developed use cases and first draft of full specification | # 2 Description This section provides the context of the building block. Governments are involved, directly or indirectly, in the purchase of various goods and services like computers/goods for their employees or technical services for projects to be implemented for the public welfare. E-Marketplace Building Block enables the trade of products and/or services via electronic media where at least one of the transacting parties taking part in the transaction is the government (either as the consumer or the provider) and the other party(ies) can be either pre-qualified providers or consumers of such goods and services (respectively). The government eMarketplace facilitates transparency by creating equal opportunities for all the stakeholders (providers and consumers) and thus creates an efficient market for goods and services. It helps build new relationships and thus builds trust. The consumer gains more insights into price information from different providers and is empowered to make rational decision-making. The sellers can optimize the sales/marketing costs and can improve their product range/portfolio by observing the demand in their domains thus multiply their market options even in international markets. The digital facility reduces time constraints for both parties. This document guides the creation of an e-Marketplace digital public infrastructure by connecting a set of interacting microservices. In the context of government, the government can itself act as a provider (For example: transferring money to citizens i.e. G2P), providing healthcare services (G2P); and also can demand goods and services , and other public entities (departmental transfers i.e. G2G) and private entities (For example: purchasing computers/ building and maintaining roads/technical/advisory/other maintenance services i.e. business to government (B2G)). This infrastructure is fundamentally decentralized or federated, although all the services can exist on a single cloud. This specification does not assume any specific implementation architecture or technology. Instead, it defines the actors and the interfaces that need to be implemented by the transacting entities. The current document focuses on enabling basic functionalities such as provider/consumer registration, listing a catalog of goods and services, and initiating a cycle of activities once a user selects a service. The document has considered payments/financial transactions between any two entities as optional based on the policies of the implementing government. > *There may be more functionalities required in the larger context of government procurement lifecycle that may complement the functionalities we have considered as relevant for an e-marketplace. For some country contexts, these specification might only be applicable to governments post-procurement. Such complementary functionalities may be included in future enhancements of this specification.* The eMarketplace Building Block could be useful in a variety of applications in different sectors for example: **Government purchase of goods and services (B2G)** * In the Health Sector, purchase of supplies to government hospitals. * In the Civil infrastructure sector, purchase of engineering services such as the construction of dams, buildings, computers, etc. * In the transportation sector, purchase of vehicles and associated maintenance services. **Government providing goods and services (G2B)** * In the Social Security sector, cash/subsidy support services of government to eligible citizens. * In the health sector, supply of nutrition and medicine to homes of patients/ pregnant mothers. * In the education sector government providing free learning materials to students. ## 2.1 **Current scope** While there may be many such use cases, within the current scope The functional requirements to cover the services required from the eMarketplace Building Block currently have considered specific use cases like, **Business to Government (B2G)** 1. [B2G-Use Case 1: Ministry of Justice - HMPPS Data & Reporting platform](https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/PUIGDILlDRSOB6K47k6e/~/changes/4/b2g-uc1-moj-hpmms-data-and-reporting-platform) 2. [B2G-Use Case 2: Purchase of Sporting Goods by a registered sporting authority](https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/PUIGDILlDRSOB6K47k6e/~/changes/4/mkt-b2g-uc2-sgp-sporting-goods-procurement) **Government to People (G2P)** 1. [G2P-Use Case 2: Online Reservation System (ORS)](https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/PUIGDILlDRSOB6K47k6e/~/changes/4/g2p-uc2-online-reservation-system-ors) 2. [G2P-Use Case 3: Government Auctions Marketplace (GAM)](broken://pages/bKR14Ts0cY1lfF4aRAzD) These use cases have business processes with several steps, where in specific steps that involve the e-Marketplace Building Block services were studied as example implementations (such as Discovery, Ordering, Fulfillment, and Post-Fulfillment of services rendered by individual entities and users in various roles. Currently, the following actors have been identified as "users" of the e-Marketplace Building Block: * "Provider" is who manages the Building Block's implementation settings. A Building Block admin is also responsible for the enrolment of entitles and Organizers of those entities that use the eMarketplace Building Block. The Admins interact with the list of goods and services, the cycle of purchase activities, and communication management. * "Consumer" is the one who participates in events to perform various activities. Consumers must be registered in the eMarketplace Building Block before they can be enrolled in events. Resources may apply/respond to multiple goods and services in a catalog. Hence a registered consumer should be able to offer services in parallel if they are short-listed by the Provider. * "Subscribers" are platforms who participate in events to consume various activities. Subscribers must be registered in the e-Marketplace before they can be enrolled in activities. Subscribers may be enrolled in multiple events and may be passive to provider's requests. * "Internal team member" who participates in internal activities such as technical and financial evaluation of the bids received on the consumer side; preparation of documents and coordination across business development, technical, and managerial teams on the provider side. The corresponding "internal team member" communicates with the "provider" or "consumer", respectively. For the sake of simplicity, the B2G use cases covered in this scope assume that the providers (businesses) are already vetted and empanelled by the consumer. Additional features that may be required in a complete procurement process will be considered in future versions of this specification. For more details, visit the Future Considerations section in Chapter 10 : Other Resources. # 3 Terminology Terminology used within this specification.
TermDescription
B2GBusinesses selling products/services to government.
G2PGovernment providing products/services to persons.
e-MarketplaceAn e-Marketplace enables trade of products and/or services via electronic media. This is supported by innovative information and communication technologies to match supply and demand.

Government

e-marketplace

An online, end-to-end e-marketplace for the procurement and sale of commonly used goods and services by/from Government ministries, departments, public sector undertakings (PSUs), and other affiliated bodies.
SpecificationA technical document that describes how a system is to be developed to achieve a specific set of objectives or requirements.
EcosystemAn ecosystem is a community of stakeholders that support platforms implementing the specification. Ecosystems can be made up of developers, resellers, customers, software, services, and more.
Ecosystem MaturityThe level of readiness of an ecosystem to design, build, and use implementations of the specification. This can range from basic access to internet infrastructure to more advanced features like digital identities, assets, payments, and trust infrastructure.
ConsumerA person, or an organization that wants to discover, buy or avail products, services, and/or opportunities.
ProviderA person, or an organization that wants to publish, sell, allocate, or provide products, services, and/or opportunities.
Application PlatformThe platform where the consumer (typically the buyer) is onboarded.
Provider PlatformThe platform where the provider (typically the seller) is onboarded.
IntentA consumer’s desire to purchase, procure, or avail something being offered by a provider.
CatalogA provider’s list of products, services, and opportunities that is made available to consumers.
# 4 Key Digital Functionalities Key Digital Functionalities describe the core (required) functions that this Building Block must be able to perform. In General, this Building Block shall be accessible on various delivery channels such as Mobile, Kiosk, Web, and applications and should be digitally inclusive for users with different capabilities. The Building Block minor features such as physical delivery of goods and services, client feedback, etc. should be able to work on feature phones (without internet) as well. To facilitate various activities and different actors as described in section 2, the e-Marketplace Building Block must have specific Key Digital Functionalities. e-Marketplace transactions by definition should have: * Consumer Platforms (i.e. Super-apps, Chat messengers, Storefronts, etc.) to provide a rich, demand-centric experience; * Provider Platforms (i.e. a Hospital Management System, a Tendering Platform, or a Store Backend) that provide a rich, supply-centric experience; * Consumers (i.e. patients, citizen applicants, personnel, organizations, etc.); * Providers (i.e. hospitals, government departments, stores, organizations); * Agent (i.e. government service personnel, sellers, drivers, doctors, etc.); * Intent (i.e. a search by product, search by category, search by provider, etc.); * Catalogs (i.e. products, offers, add-ons, services); * Payments and Settlements (i.e. Cash on Delivery, Prepayment, T+n settlement, etc.); * Order management (i.e. contracts, appointments, bids, service requests); * Fulfillments (i.e. appointments, tender approval, delivery of goods and services); * Management of order lifecycle activities (from tendering to bidding, evaluation ordering, delivery tracking to feedback, etc.). The e-Marketplace Building Block must utilize the above objects to primarily support various consumer-provider interactions like discovery, ordering, fulfillment, and post-fulfillment. For example, a patient (Consumer) on WhatsApp (Consumer Platform) can search (Discovery) for a doctor (Agent) by his name (Intent). This request can be sent to ORS (Healthcare Provider Platform) that returns a list of Hospitals (Providers), with the various services offered (Catalog). Once identified, the patient (Consumer) can book an appointment (Order) with the Doctor (Agent). The various actors and their activities described in section 2 must be supported by a set of non-redundant, Key Digital Functionalities listed below: ## 4.1 Catalog Management This key digital functionality should allow providers to quickly and efficiently return a matching catalog upon receipt of a search intent. This e-Marketplace must also allow authorized administrators of the host entity to create and manage aggregated catalogs of providers, products, and services that can operate across multiple locations and timings. This functionality does not only apply to catalogs of products and services, it can be used to publish any economic resource that has a fulfillment cycle (e.g. it should allow government departments to create and manage catalogs of tenders across multiple departments spread across multiple locations). Admins must be able to create, read, update, or delete catalogs, and any sub-component of this catalog like Items/Categories/Providers/Locations/Agents/Fulfillments/Payments/etc. For tendered purchase, the government can publish tenders along with associated documents (e.g. Request for Proposals) in the tender's catalog. Pre-qualified providers already registered in the system can search the catalog and bid accordingly through quotation management services. In summary, the Building Block enables the cataloging of various elements such as providers/products/services/consumers/tenders/agents/etc., such that they can be searched, retrieved, and shared in appropriate workflows. ## 4.2 Inventory Management Authorized users of provider platforms should be able to manage the inventory of various resources available in a catalog. Providers should be able to manage the availability of products/agents/vehicles/etc., dynamically/on a real-time basis, in this Building Block. ## 4.3 Quotation Management This key digital functionality should allow consumers to select items, offers, and add-ons from a catalog and build a tender. It should be able to transmit them to pre-qualified providers and request a quotation with a proposal. Using this functionality, the providers must be able to submit their proposals with quotations. The consumers should be able to evaluate the quotations and proposals and select items (one or more) from (one or more different sources/providers) in order to generate the respective orders. Providers should be able to calculate a quote basis the item/offers/add-ons selected and to add dynamic offers without being specifically requested by the consumer. For example, a consumer should be able to add items from a provider's catalog, add offers, select add-ons into a common cart, and view the total cart value. This functionality should also allow providers to request additional information from the consumer that is required to proceed to the next stage. This functionality should also allow consumers and providers to transmit requests to each other to allow consented information sharing required to decide on a quote. ## 4.4 Terms Management This key digital functionality should allow the consumer to share billing details, fulfillment details, legal jurisdiction of dispute and resolution mechanism, and any additional information required for the provider to generate the final contract/order with the terms of fulfillment, payment, cancellation, refund, returns, and replacements. Administrators of the provider platforms should be able to configure various rules for final quote calculation, payment terms, and other terms of service depending upon the information received from the consumer. Providers should be able to evaluate the additional information that was requested when executing the quote agreement function and re-calculate the quote. For example, a healthcare service might have a standard quote for general citizens, but provide a discounted rate when it discovers from the additional data that the consumer is a senior citizen. It should allow the consumer to view the final payment terms and all details that will be included in the final contract. This functionality should allow for the final draft order/contract to be exchanged between the consumer and the provider. ## 4.5 Order Management This key digital functionality should allow the consumer to confirm an order. Bidders can confirm a bid in an auction. It should allow the creation and confirmation of an order expressed as a dual-digitally signed contract, with the terms that were agreed upon. In case the terms require payment before the creation of the contract, it should: allow the transmission of the proof of payment made from the payer to the payee, allow the provider to transmit a contract to the consumer, allow the consumer to request the provider to update various elements of the contract, allow updates to the terms of the contract and inform the consumer of the update, and allow browsing of contracts based on its various attributes. ## 4.6 Order Fulfillment This key digital functionality should allow the consumer of a service to receive various status updates regarding the fulfillment of a contract. This should allow providers to send various fulfillment updates to the consumer, and allow providers to allocate service agents manually/algorithmically (e.g. ambulance allocation as a response to a nearby emergency). The contract fulfilment could have a long duration of workflow (i.e. 3 years), depending upon the nature of the contract signed. The Building Block should be able to facilitate all the processes and reflect the dynamic status of a signed contract with updates/remarks/comments. For example, the sign-off agreement with feedback, and lessons learned report shall be submitted as and when the project finishes formally. ## 4.7 Order Tracking Consumers should be able to track the fulfillment of an order in real-time. Providers should be able to stream real-time data to the consumer related to the fulfillment of an order. This tracking is not necessarily geospatial but can contain any information that provides the consumer with real-time information like tracking of physical variables like temperature, speed, and countdown timers in bidding use cases. This functionality should render the real-time data to the consumer via a tracking page. ## 4.8 Order Cancellation This key digital functionality should allow the consumer or the provider to cancel a contract. This functionality should allow a consumer to view the terms of cancellation sent by a provider in response to a cancellation request. It should also allow both parties to see the canceled order. Providers should be able to request a cancellation reason along with additional information related to the reason for the cancellation. Consumers should be able to provide a cancellation reason and additional information related to the cancellation request. Once a cancellation is agreed upon by both parties, the current and historical data related to this activity/chain of activities shall be rolled back or archived, as per the policy. ## 4.9 Rating and Feedback Management Users of this key digital functionality should be able to rate various entities involved in the fulfillment of a contract. These users can be both consumers and providers. A consumer should be able to rate various aspects of the service like the agent, vehicle, quality of service, customer support, etc. A provider’s agent should be able to rate the consumer as well. Upon receipt of a rating, a provider can ask for additional feedback related to the rating. This means that the activity can occur throughout the cycle of various activities, not just at the end of a single process. ## 4.10 Support Management Users of this key digital functionality should be able to contact the support center to enquire about any issues that they may be facing and create a ticket. Customer support executives should be able to view details of a contract, fetch related information, view open tickets, and resolve them. If needed, customer support executives can fetch the contact details of a provider, or their agents to gain more information related to the fulfillment of an order. ## 4.11 Bid Evaluation The Building Block should facilitate the bid evaluation process (financial/technical/etc.) with defined criteria. The evaluation shall be conducted by the consumer, only. At first, the consumer defines an evaluation criteria for a good or service. Then the consumer admin/a group of professionals will receive the documents/details submitted by the provder; and evaluate them based on the pre-defined criteria. In case the consumers/providers have any clarifications, the concerned party should be able to seek guidance through writing questions/addendum/corrigendum. Finally, the evaluation should select the best bidder/provider. # 5 Cross-Cutting Requirements This section will highlight important requirements or describe any additional cross-cutting requirements that apply to this Building Block. ## 5.1 Personal Data Privacy (REQUIRED) Personal data must be kept private and never shared with any parties, except where specific authorization has been granted. The Consent Building Block shall follow the privacy principles as laid out in the GovStack architecture and security recommendations. ## 5.2 All transactions must be Audit Logged (RECOMMENDED) Logs should be kept in a database of all created, updated, or deleted records. Logs must include timestamps and identify the user and affiliation that performed the transaction. All audit logs shall be integrity-protected against tampering. The Consent Building Block shall follow the data policy and audit logging requirements as required by local policies. ## 5.3 Rollback capability (RECOMMENDED) The Building Block must perform various activities starting from initiation of purchase request/expression of interest to completion of order with feedback etc. In case of any non-compliance (due to both technical and functional reasons), it should be able to roll back to the initial state to safeguard the integrity of the application. # 6 Functional Requirements This section lists the technical capabilities of this Building Block. The e-Marketplace does not assume any particular standard like REST (Representational State Transfer) for all internal resource management. A brief description of the functional requirements necessary to orchestrate each key digital functionality is given below, considering the development of a minimum viable product. Detailed design and more elaborate feature lists of these functionalities can be customized by developers to optimally match respective implementation needs. It is also left to the application implementing this Building Block to receive the responses from the e-Marketplace and present them appropriately and provision for associated user interface interactions. ### **6.1 Catalog Management** * The e-Marketplace must allow the creation of a search request with a context and a message. The context must contain the action performed (“search”), the location where the search is limited to (e.g. country, city, area code, etc.), the domain/category of search (e.g. healthcare, services, etc.), the identity of the platform generating the search (e.g. domain, name), the callback URL of the platform generating the search. (REQUIRED) * The context must also contain a unique transaction ID to represent a sequence of interactions. It must also contain a unique message ID to match a request with a callback. The search context must contain a timestamp denoting the time of the search. (REQUIRED) * It should allow the addition of an intent to the message. The intent should contain fulfillment details in case the customer wants their order fulfilled in a specific way. If there is a preferred method of payment the intent should contain the payment details. The intent should define the category of the search. If search criteria is specific to an offer, intent must contain the offer detail. (REQUIRED) * It should allow multiple search parameters and should allow updates of search parameters, the system should provide the flexibility to update the search criteria, ex-search is to be modified for category, payment type, etc. (REQUIRED) * Once a call is made and the user wants to make a next search call that can not be fulfilled with the existing data from the previous search call, the system should be able to use the selected fields and the modified search fields for the next search call. (REQUIRED) * It must be able to transmit the search request along with all the search parameters to the provider platform. (REQUIRED) * This Building Block should allow fetching of catalogs that match the maximum number of search parameters. (RECOMMENDED) * The e-Marketplace must allow the creation of a catalog request for which context is required and should have a message. (REQUIRED) * The context is used to describe the metadata of the details provided in the message part. The context must contain an action. It also must contain a unique transaction ID received by the search request to represent a sequence of interactions. It must also contain a unique message ID to match a request with a callback. It must contain a timestamp denoting the time of the search requested for the catalog. (REQUIRED) * The message must contain a catalog. The catalog is used to describe the products or services provided by the platform. The catalog should be formed based on the search request made by the user and the data filtered accordingly and added to the catalog. (REQUIRED) * The catalog should be able to provide a description, it will have a description of the product or service, and it can have short/long descriptions or descriptions for images. (REQUIRED) * The catalog should provide fulfillment details, it will provide the details about the fulfillment mode if the e-Marketplace takes responsibility for the fulfillment. (RECOMMENDED) * The catalog should provide payment details about the payment terms offered by the e-Marketplace. The terms can be overridden by the providers' section, in case e-Marketplace does not take responsibility for the payments. (REQUIRED) * The catalog should provide expiry details about the time (timestamp) after which the catalog will not be valid. The consumer platform must be able to process the expiry and invalidate the catalog. E.g. A limited-time offer on a service/product. (REQUIRED) * The catalog should provide details of the time to live (TTL), which describes the time to set to exist for the catalog before it is discarded by a router and expires. The consumer platform must be able to process the TTL and invalidate the catalog. (REQUIRED) * The provider platform must be able to call the on\_search API provided by the Consumer platform to provide the catalog of the products. (REQUIRED) * The Consumer platform should provide a mechanism to handle the response (catalog) for a search, it should display the products/services in the catalog properly and filter the products at the UI layer. (REQUIRED) * The consumer platform should be able to handle multiple responses against a search tied with a message ID made, as the response can be from multiple providers. (REQUIRED) ### 6.2 Inventory Management * The e-Marketplace must allow the providers to add new products to their inventory. (REQUIRED) * It should be able to provide the current status of the inventory products, and the reporting should provide various filters based on which report can be generated. (REQUIRED) * It should allow updating the quantity and location of Items across multiple Providers and must restrict access to the providers' internal inventory. (REQUIRED) * Inventory must get adjusted based on the order placed (confirm/cancel/return). (REQUIRED) * It must allow checking of the availability of an Item in a catalog to avoid out-of-stock and over-stocking of the product. (REQUIRED) * It should provide a configurable system for notification which notifies based on the defined criteria. E.g. If the product quantity is less than 50, it must notify the provider by email or SMS. (RECOMMENDED) ### 6.3 Quotation Management * The e-Marketplace must enable the construction of a cart (or a cart-like experience) on the consumer platform, it must consist of context and message. (REQUIRED) * It must allow the addition/removal/update of multiple items and their respective quantities in the cart. (REQUIRED) * It must allow the consumer to choose from different offers available, and users should be able to modify or remove the offer before an order is placed. (REQUIRED) * It must allow users to modify the addons in the cart, the cart should not be frozen before an order is placed. The consumer should be able to modify the products i.e. add/remove products or modify the quantity of the product. (REQUIRED) * It must allow the transmission of the cart from the consumer platform to the provider platform. (REQUIRED) * Upon receiving the cart from the consumer platform, it must allow the provider platform to check for the availability of items in the cart. (REQUIRED) * It should check the validity of offers against the items in the cart. (REQUIRED) * it should dynamically calculate the quote based on the available items, offers, and add-ons. (REQUIRED) * It should transmit the cart with the updated quote from the provider platform to the consumer platform. (REQUIRED) * Provider platform should respond with context and either order or show error. (REQUIRED) * The consumer platform must process the quote properly and show the details along with the offers/delivery/payments details and break up of the quote. (REQUIRED) ### 6.4 Terms Management * The e-Marketplace must enable the construction of a draft order (or a pre-checkout-like experience) on the consumer platform, the draft order must contain context and a message with order details. (REQUIRED) * Consumer applications must allow the modification of the billing details of the order before a request is sent to the provider. (REQUIRED) * It must allow the consumers to modify the fulfillment details. E.g a consumer that has multiple addresses stored in the application should be able to select the address or add a new address for fulfillment. Consumers should also be able to choose from the available fulfillment options. (REQUIRED) * It must allow the transmission of the draft order from the consumer platform to the provider platform. (REQUIRED) * The consumer app must recalculate the quote based on the modifications made in the fulfillment details. (REQUIRED) * The consumer app must check the serviceability of the order based on agent availability. (REQUIRED) * Provider platform must re-check the availability of items and validity of offers, and re-calculate the quote based on the selection made by the consumer. (REQUIRED) * Provider platform must allow creation and modification of payment terms containing the payment stage, final payable amount, payment endpoint, and payment schedule to the draft order. (REQUIRED) * Provider app must allow the addition of terms of service, cancellation, returns, replacements, and refunds wherever applicable. (REQUIRED) * Provider platform must respond with context and either order or an error. (REQUIRED) * It must allow the transmission of the final draft order containing all the details of the order to the consumer platform. (REQUIRED) * The consumer platform must be able to handle the final draft order received from the provider and display the final order draft. (REQUIRED) ### 6.5 Order Management * The e-Marketplace must enable the creation of a confirmed order with a unique Order ID, the confirmed order must contain context and message. (REQUIRED) * Before confirming an order to the provider platform consumer platform must allow modification of a fulfillment state in the order. (REQUIRED) * The consumer platform must allow the transmission of the final draft order to the provider platform. (REQUIRED) * Provider platform must again allow re-checking of inventory availability before creating the order. (REQUIRED) * It must allow the transmission of the confirmed order from the provider platform to the consumer platform. (REQUIRED) * Provider platform response to a confirmed order must contain context and either an order or an error. (REQUIRED) * The consumer platform must be able to handle the order confirmation received from the provider platform and display the success message to the consumer along with the order ID and the product's details in the order. (REQUIRED) ### 6.6 Order Fulfillment * The e-Marketplace must enable the discovery and allocation of an Agent (if applicable) to the fulfillment of a confirmed order. (REQUIRED) * Consumer application must be able to fetch the status of the order from the provider platform. (REQUIRED) * Provider platform must be able to find out the status of the order and provide the details back to the consumer application. (REQUIRED) * Provider application must allow updates on the status of the order. (REQUIRED) * When a new event occurs on the fulfillment, the provider platform must pass on the information to the consumer platform. (REQUIRED) ### 6.7 Order Tracking * The e-Marketplace must enable the fetching of tracking information related to the order. (REQUIRED) * It must allow real-time data to be transmitted from the provider to the consumer. (REQUIRED) * It must allow the consumer platform to transmit a webhook endpoint to the provider platform which will handle the real-time updates on the tracking. (REQUIRED) * It must allow the provider platform to transmit a tracking link to the consumer platform. (REQUIRED) * The consumer platform must allow the display of the tracking details to the consumer along with the history. (REQUIRED) * Consumer applications must be able to segregate the tracking details based on the order ID. (REQUIRED) ### 6.8 Order Cancellation * The consumer platform must allow the creation of an order cancellation request for all the active orders that are yet not fulfilled. (REQUIRED) * The consumer platform must provide the order ID and allow the addition of the cancellation reason to the cancellation request. (REQUIRED) * Provider platform must handle the cancel order request and respond to the consumer platform. (REQUIRED) * Provider platform must allow modification of the order status and de-allocation of fulfillment services and the agents associated with the fulfillment of the contract. (REQUIRED) * It must allow the calculation of cancellation terms (if applicable) depending on the reason provided and the time of the cancellation request. (REQUIRED) * It must be possible to add a link to the cancellation terms (including cancellation fee) document to the order. (REQUIRED) * It must allow transmission of the canceled order between the consumer and the provider. (REQUIRED) * On cancellation of an order the provider platform must adjust the inventory of the products canceled. (REQUIRED) * The consumer platform must handle the response from the provider platform for a cancellation request, and update the order status, and display the details of the cancellation of the order along with the cancellation terms (including the cancellation fee). (REQUIRED) ### 6.9 Rating and Feedback Management * The e-Marketplace must allow ratings for various rateable entities to be captured by people involved in a transaction. (REQUIRED) * It must allow the transmission of ratings from the consumer platform to the provider platform. (REQUIRED) * It must allow the creation of feedback by the provider platform to get detailed additional information on the rating provided. (RECOMMENDED) * It must allow the creation of a request to collect additional feedback related to a rating. (RECOMMENDED) * It must allow fetching of various rateable entities related to an order. (RECOMMENDED) ### 6.10 Support Management * The e-Marketplace must allow support center information like email, phone number, and chat URL concerning an order to be transmitted between the consumer and the provider platforms. (REQUIRED) * It must allow the creation/read/update/deletion of tickets concerning an issue raised by a consumer, or an agent. (REQUIRED) ### 6.11 Information Mediator Interface * This sub-block runs protocols to communicate with the information mediator Building Block for exposing e-marketplace services to external Building Blocks and applications. (REQUIRED) * It also provides specific calls to APIs of information mediator Building Block to access services of external applications and Building Blocks. (REQUIRED) * It also handles any errors and failures in data exchange between the e-Marketplace and other Building Blocks/Apps (such as backoff and retries, etc.). (REQUIRED) * It routes error information if any to the logger sub-block. (REQUIRED) * It maintains a list of endpoint addresses of Information Mediator, or other Building Blocks/Applications. (REQUIRED) ### 6.12 Payment Interface * These are dedicated API interfaces defined in the Payments Building Block and hence not defined here: * The Payment interface should provide the necessary protocol, data format, and information and interface to interact with the Payments Building Block for sending payment collection or settlement instructions to existing payment infrastructures like Banking Systems, Credit Card Networks, Payment Gateways, etc. to facilitate payments made during a transaction in the e-Marketplace. (RECOMMENDED) ### 6.13 E-Signature Interface * These are dedicated API interfaces defined in the e-Signature Building Block and hence not defined here: * The E-Signature interface should provide the necessary protocol, data format, information, and interface to interact with the e-Signature Building Block for the digital signing and subsequent verification of each message that is transmitted between the consumer platform and the provider platform. (RECOMMENDED) ### 6.14 Registration Interface * These are dedicated API interfaces defined in the Registration Building Block and hence not defined here: * The Registration interface should provide the necessary protocol, data format, and information and interface to interact with the Registration Building Block to enable users on the Consumer Platform and the Provider Platform to sign up on their respective platforms with the required information necessary to perform transactions on the e-Marketplace. (RECOMMENDED) ### 6.15 Digital Identity & Verification Interface * These are dedicated API interfaces defined in the Digital Identity and Verification Building Block and hence not defined here: * The Digital Identity and Verification Building Block should provide the necessary protocol, data format, and information and interface to interact with the Digital Identity & Verification Building Block to enable users on the Consumer Platform and the Provider Platform interface to verify the digital identities in the e-Marketplace based on their national data registers. (RECOMMENDED) ### 6.16 Promotional Communications * These are dedicated API interfaces defined in the Communication and Outreach Building Block and hence not defined here: * The Communication and Outreach Building Block should provide the necessary protocol, data format, and information and interface to interact with the Communication and Outreach Building Block to enable users on the Consumer Platform and the Provider Platform interface to integrate with social media and messaging platforms. (RECOMMENDED) ### 6.17 **Content Management Interface** * These are dedicated API interfaces defined in the Content Management Interface Building Block and hence not defined here: * The Content Management Interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the Content Management Interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to manage content creation. (RECOMMENDED) * The interface should be able to moderate, and curate content creation. (RECOMMENDED) * The interface should enable the user (consumer/provider) to submit a document, and best practices in a prescribed format. (RECOMMENDED) * The interface should be able to store the documents in an organized manner. (RECOMMENDED) * It should allow any user to access the organized content. (RECOMMENDED) * The interface allows the providers to add text, images, product description details, etc. to a good/service. (RECOMMENDED) ### 6.18 **Workflow Interface** * These are dedicated API interfaces defined in the Workflow interface Building Block and hence not defined here: * The Workflow interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the Workflow interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to define and orchestrate the workflow within the system. (RECOMMENDED) * The interface should automate the processes involved in a lifecycle of technical activities, as defined by the administrator. (RECOMMENDED) * The status of each process should be 'Live', accompanied by timestamp details. (RECOMMENDED) * Upon a status is technically fulfilled (whether completed/achieved, failed, or canceled), the next relevant process should get triggered automatically. (RECOMMENDED) ### 6.19 **Dashboard & Business Analytics Interface** * These are dedicated API interfaces defined in the Dashboard and Business Analytics interface Building Block and hence not defined here: * The dashboard and business analytics interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the dashboard & business analytics interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to visualize the data in the system. (RECOMMENDED) * This interface should visualize the 'live' data on the identified set of data fields such as the number of items in stock, canceled items, etc. (RECOMMENDED) * This interface should analyze the data using basic mathematical operations (e.g. addition, average, and percentage) and offer insights. (RECOMMENDED) * The interface may have advanced mathematical operations such as analyzing historical data, and prediction analyses using linear regression and machine learning algorithms. (OPTIONAL) * This interface may be able to perform and fetch advance statistics, upon a request from the administrator, such as annual/half-yearly procurement/sales of goods and services, year-on increments, etc. (OPTIONAL) ### 6.20 **GIS Building Block Interface** * These are dedicated API interfaces defined in the GIS interface Building Block and hence not defined here: * The GIS interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the GIS interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to use GIS-based services like GIS tagging, tracking, etc. (RECOMMENDED) * This interface should track the goods/services, with timestamps. (RECOMMENDED) * The interface should tag the coordinates of entities, of persons as defined by the administrator. (RECOMMENDED) * The interface should be live. (RECOMMENDED) ### 6.21 Consent Management Interface * These are dedicated API interfaces defined in the Consent Management Interface Building Block and hence not defined here: * The Consent Management Interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the consent management interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to capture and validate the consent of the users. (RECOMMENDED) * This interface should accept data of different types and forms (biometrics, electronic messages, physical inputs). (RECOMMENDED) * The interface should let the user decide to accept/reject to share their consent to the applications. (RECOMMENDED) * The interface must respect the Consent protocols/related policies as defined by the administrator. (REQUIRED) * The interface must validate the consent of the user, as required. (REQUIRED) ### 6.22 Messaging Interface * These are dedicated API interfaces defined in the Messaging interface Building Block and hence not defined here: * The Messaging interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the messaging interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to exchange messages over a secured channel and have logging features. (RECOMMENDED) * This interface must act as a secured channel between sending and receiving users. (REQUIRED) * This interface should facilitate messages both encrypted and non-encrypted. (RECOMMENDED) * Logging, backup, retrieval of lost messages, and storage features shall be enabled by this interface. (RECOMMENDED) ### 6.23 Scheduling Interface * These are dedicated API interfaces defined in the Scheduling interface Building Block and hence not defined here: * The Scheduling interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the Scheduling interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to automate the process based on the events in the system. (RECOMMENDED) * The consumer must be able to publish advertisements/announcements on their website/mobile app/kiosk application about their requirements, vacancies, expertise, hosting events (physical or online), videos, advertisements, schedule of activities for the next 6 months, etc. (REQUIRED) * The platform should be able to connect with social media networks and reach the target audience. (RECOMMENDED) * The providers, consumers, and entities should be able to subscribe to social media channels and to the website to receive updates from the consumer. (RECOMMENDED) * The consumer should be able to send alerts, messages, and emails to subscribers about the new announcements. (RECOMMENDED) * The subscriber should be able to cancel their subscriptions as and when desired. (RECOMMENDED * This interface should orchestrate processes with time stamps when triggered. (RECOMMENDED) * It should update the processes and current list of stock items. (RECOMMENDED) * It should perform communication-related activities such as sending alerts, reminders, and automated messages, upon achieving a stage/state. (RECOMMENDED) ### 6.24 Bid Evaluation * The e-Marketplace must allow the consumer to perform an evaluation (financial, technical, any other). (REQUIRED) * The e-Marketplace must allow the consumer to pre-define an evaluation criteria for a good or service. (REQUIRED) * It shall facilitate the consumer and provider to seek clarification on any of the questions, they might have. (REQUIRED) * It must allow the individual members to read the documents, and other details and share their scores, remarks, and ranking based on the pre-defined criteria. (REQUIRED) * The evaluation report/remarks shall be fed to the administrator and the final acceptance (not the details) may be communicated to the providers. (REQUIRED) ## **The eMarketplace Building Block must enable Admins to** * enable the registration process of both prividers and consumers. * enable the verification of Foundational IDs come with no specified purpose or attached entitlement but functionalities simply let an entity prove who it is. * Captures only limited information about users, such as name, date of birth, address, and gender. * For a given set of credentials, fetches a corresponding ID if it exists in the registry. * Uses different biometric methods to identify and authenticate users through means other than user photographs (e.g. fingerprints, iris scans, facial recognition) to ensure there are no duplicates or fakes, creating a highly trustworthy database. * open bank accounts, buy SIM cards, receive entitlements from the government, sign forms electronically, invest in mutual funds, and get credit. * Incorporate privacy into its design when the purpose of the authentication is not revealed if a service provider sends an authentication request. **The e-Marketplace must enable Building Block Admins (Provider and Consumers) to** * seek consent from the entities, and people while registration. * dynamically identify, verify, and validate the registration details against those of public registries. * register without duplication an entity, into its Entity List with details (e.g. name, phone, email, website, etc.). The entities host various "activities" involving their affiliated resources (client case management). * categorize entities for easy searching and sorting, e.g. "department" or "ministry" . * configure rules for performance, security, and communication management between the eMarketplace and other Building Blocks (e.g. Registries, Identity and Verification, Information Mediation), applications (across different departments/ministries), and event participants. The exact parameters may be decided at implementation time. * extract log reports from the system as needed for monitoring and administering the Building Block operations. * register subscribers (persons/citizens/individuals) without duplication into eMarketplace's Subscriber list with contact details (phone/mail/URL/) as needed for communication, and reuse for enrolment to multiple activities. * register order life cycle events with a defined starting and ending time and an optional deadline for participants to log in their attendance in the activity if needed. * access a restricted number of subscribers to an activity, based on the sorting/category filter. * define and maintain a library of a predefined stack of messages/notifications for a specific host entity so that it can be reused in multiple activities conducted by the specific host entity. * define alert schedules for sending specific alert messages associated with a certain event at a determined date-time to associated subscribers or resources or both. * to extract logs related to activities that help in continuous improvement in order lifecycle event management. * to generate (i.e. purchase order/request), upload, and download the correspondence, circulars, and agreements in ".doc" and ".pdf" formats (document management). * (the provider) to implement large-scale outreach communication, and awareness campaign activities through electronic means. * to have a grievance readdress mechanism. * to facilitate seek/offer/resolve/implement feedback mechanisms once the enrolled activities are completed. * to delegate access management so that a particular role can perform only the tasks/activities that they are intended to. * to facilitate workflow management amongst active providers and consumers. * to handle exceptions when registration fails is unable to generate a purchase request, etc. * to facilitate communication between both parties, such as seeking clarification, responding to questions raised by the bidder on the bidding process or any other, etc. **The e-Marketplace must enable consumers and subscribers to** * search and extract their registration details in the eMarketplace. * search and extract their affiliation details across associated entities. * search and extract details of activities they are enrolled into. * search and extract details of subscribers of activities they are enrolled into. * receive scheduled alert messages from activities they are enrolled in. * search and list details of activities of a chosen category in a specified date-time range. * log status/attendance updates related to activities they are enrolled in. * view current status, details, and list of activities dynamically. #### The e-Marketplace must enable the administrator to catalog goods and services * get displayed a list of goods and/or services when an appropriate filter is used (e.g. a ministry or a type of service). * get displayed a list of active/closed/in progress items of ordering; with its stages for the Provider. * get displayed the number of days remaining of the entire project duration, payment milestones, and list of deliverables under the consumer department/ministry. #### The e-Marketplace must have system-automated internal functionality to * track all order lifecycle stages/events and send corresponding alert messages with unique tokens/IDs to relevant participants at appropriate times. * detect communication failure with other Building Blocks and applications and perform retries according to configured rules before logging a communication failure. Associated implementation-specific details that are not specified here. # 7 Data Structures This section provides information on the core data structures/data models that are used by this Building Block. The proposed resource model showing the relationship between data objects that are used by this Building Block is illustrated in the diagram below. ## 7.1 E-Marketplace Building Block Data Model
## 7.2 Data Structures ### 7.2.1 Ack **Description:** Outlines the acknowledgement sent in response to an API call. If the implementation uses HTTP/S, then Ack must be returned in the same session. Every API call to a Provider Platform must be responded to with an Ack whether the Provider Platform intends to respond with a callback or not. This has the property `status` that indicates the state of the Acknowledgement. **Fields:**
NameTypeDescriptionNotesNotes
statusstringThe status of the acknowledgement. If the request passes the validation criteria of the Provider Platform, then this is set to ACK. If a Provider Platform responds with status = ACK to a request, it is required to respond with a callback. If the request fails the validation criteria, then this is set to NACK. Additionally, if a Provider Platform does not intend to respond with a callback even after the request meets the validation criteria, it should set this value to NACK.Enum Data Type in C: ACK, NACK
tagsTagGroup arrayA grouped list of tags containing any additional information sent along with the Acknowledgement.
### 7.2.2 AddOn **Description:** Shows an additional item offered as a value-addition to a product or service. This does not exist independently in a catalog and is always associated with an item. **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | --------------------------------- | | id | string | Provider-defined ID of the add-on | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the add-on | | price | [Price](#7.2.40-price) | Price of the add-on | ### 7.2.3 Address **Description:** Outlines a postal address that is stored as a string value. ### 7.2.4 Agent **Description:** Outlines the direct performer, driver or executor that fulfils an order. It is usually a person. But in some rare cases, it could be a non-living entity like a drone, or a bot. Some examples of agents are a doctor in the healthcare sector, a driver in the mobility sector, or a delivery person in the logistics sector. This object can be set at any stage of the order lifecycle. This can be set at the discovery stage when the Provider Platform wants to provide details on the agent fulfilling the order, like in healthcare, where the doctor's name appears during a search. This object can also be used to search for a particular person that the customer wants to fulfil an order. Sometimes, this object gets instantiated after the order is confirmed, like in the case of on-demand taxis, where the driver is assigned after the user confirms the ride. **Fields:** | Name | Type | Description | | ------------ | ------------------------------------ | --------------------------------------------------- | | person | [Person](#7.2.39-person) | Personal details of the agent | | contact | [Contact](#7.2.13-contact) | Contact details of the agent | | organization | [Organization](#7.2.37-organization) | The organization details which the agent belongs to | | rating | [Rating](#7.2.43-rating) | The average user rating of the agent | ### 7.2.5 Authorization **Description:** Outlines an authorization mechanism used to start or end the fulfilment of an order. For example, in the mobility sector, the driver may require a one-time password to initiate the ride. In the healthcare sector, a patient may need to provide a password to open a video conference link during a teleconsultation. **Fields:**
NameTypeDescriptionNotesEnum
typestringType of authorization mechanism used. The allowed values for this field can be published as part of the network policy.
tokenstringToken used for authorization. This is typically generated at the Provider Platform. The Application Platform can send this value to the user via any channel that it uses to authenticate the user like SMS, Email, Push notification, or in-app rendering.
valid_fromstringTimestamp in RFC3339 format from which token is valid.Format: date-time
valid_tostringTimestamp in RFC3339 format until which token is valid.Format: date-time
statusstringStatus of the token.
### 7.2.6 Billing **Description:** Outlines the billing details of an entity. This has properties like name, organization, address, email, phone, time, tax\_number, created\_at,updated\_at. **Fields:**
NameTypeDescriptionNotesEnum
namestringName of the billable entity
organizationOrganizationDetails of the organization being billed.
addressAddressThe address of the billable entity
stateStateThe state where the billable entity resides. This is important for state-level tax calculation
cityCityThe city where the billable entity resides.
emailstringEmail address where the bill is sent toFormat: email
phonestringPhone number of the billable entity
timeTimeDetails regarding the billing period.
tax_idstringID of the billable entity as recognized by the taxation authority
### 7.2.7 Cancellation **Description:** Outlines a cancellation event. **Fields:**
NameTypeDescriptionFormatEnum
timestringDate-time when the order was cancelled by the buyerFormat: date-time
cancelled_bystringEnum Data Type in C: CONSUMER, PROVIDERCONSUMER, PROVIDER
reasonOption arrayThe reason for cancellation.
additional_descriptionDescriptorAny additional information regarding the nature of cancellation.
### 7.2.8 CancellationTerm **Description:** Outlines the cancellation terms of an item or an order. This can be referenced at an item or order level. Item-level cancellation terms can override the terms at the order level. **Fields:** | Name | Type | Description | | ------------------ | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | fulfillment\_state | [FulfillmentState](#7.2.26-fulfillmentstate) | The state of fulfillment during which this term is applicable. ([Fulfillment State](#7.3.26-fulfillmentstate)) | | reason\_required | boolean | Indicates whether a reason is required to cancel the order | | cancel\_by | [Time](#7.2.54-time) | Information related to the [time](#7.3.54-time) of cancellation. | | cancellation\_fee | [Fee](#7.2.23-fee) | The cancellation fees levied on the customer | | xinput | [XInput](#7.2.57-xinput) | Form to capture information related to the cancellation | | external\_ref | [MediaFile](#7.2.33-mediafile) | Any attachements related to the cancellation | ### 7.2.9 Catalog **Description:** Outlines the products or services offered by a Provider Platform. This is typically sent as the response to a search intent from an Application Platform. The payment terms, offers and terms of fulfilment supported by the Provider Platform can also be included here. The Provider Platform can show the hierarchical nature of products/services in its catalog using the parent\_category\_id in categories. The Provider Platform can also send a TTL (time to live) in the context which is the duration for which an Application Platform can cache the catalog and use the cached catalog. This has properties for Business to Business Procurement (BBP) like descriptor/categories/fulfillments/payments/offers/providers/exp. This is used in the following situations. This is typically used in the discovery stage when the Provider Platform sends the details of the products and services it offers as a response to a search intent from the Application Platform. **Fields:**
NameTypeDescriptionNotesEnum
descriptorDescriptorDescription of the catalog
fulfillmentsFulfillment arrayFulfillment modes offered at the Provider Platform level. This is used when a Provider Platform itself offers fulfillments on behalf of the providers it has aggregated.
paymentsPayment arrayPayment terms offered by the Provider Platform for all transactions. This can be overriden at the provider level.
offersOffer arrayOffers at the Provider Platform-level. This is usually used when the platform aggregates catalogs of multiple providers
providersProvider arrayProvider of service or product.
expstringTimestamp after which catalog will expireFormat: date-time
ttlstringDuration in seconds after which this catalog will expire
### 7.2.10 Category **Description:** A label under which a collection of items can be grouped. **Fields:** | Name | Type | Description | | -------------------- | ---------------------------------- | ---------------------------------------------- | | id | string | ID of the category | | parent\_category\_id | [Category](#7.2.10-category) | ID of the parent category | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the category | | time | [Time](#7.2.54-time) | Time at or during which this category is valid | | ttl | string | Time to live for an instance of this schema | | tags | [TagGroup](#7.2.53-taggroup) array | Array of grouped key value pairs | ### 7.2.11 Circle **Description:** Describes a circular region of a specified radius centered at a specified GPS coordinate. **Fields:** | Name | Type | Description | | ------ | ------------------------ | ------------------------------ | | gps | [Gps](#7.2.27-gps) | GPS Co-ordinates of the center | | radius | [Scalar](#7.2.47-scalar) | Radius of the circle | ### 7.2.12 City **Description:** Outlines a city **Fields:** | Name | Type | Description | | ---- | ------ | ---------------- | | name | string | Name of the city | | code | string | City code | ### 7.2.13 Contact **Description:** Outlines the contact information of an entity. **Fields:** | Name | Type | Description | | ----- | ------ | ---------------------------------------------------------------- | | phone | string | | | email | string | | | jcard | object | A Jcard object as per draft-ietf-jcardcal-jcard-03 specification | ### 7.2.14 Context **Description:** Every API call in Beckn Protocol has a context. It provides a high-level overview to the receiver about the nature of the intended transaction. Typically, it is the Application Platform that sets the transaction context based on the consumer's location and action on their UI. But sometimes, during unsolicited callbacks, the Provider Platform also sets the transaction context but it is usually the same as the context of a previous full-cycle, request-callback interaction between the Application Platform and the Provider Platform. The context object contains four types of fields. Demographic information about the transaction using fields like `domain`, `country`, and `region`. Addressing details like the sending and receiving platform's ID and API URL. Interoperability information like the protocol version that is implemented by the sender and transaction details like the method being called at the receiver's endpoint, the transaction\_id that represents an end-to-end user session at the Application Platform, a message ID to pair requests with callbacks, a timestamp to capture sending times, a ttl to specify the validity of the request, and a key to encrypt information if necessary. This object must be passed in every interaction between an Application Platform and a Provider Platform. In HTTP/S implementations, it is not necessary to send the context during the synchronous response. However, in asynchronous protocols, the context must be sent during all interactions. **Fields:**
NameTypeDescriptionNotesEnum
domainDomainIndustry sector code that is relevant to this transaction
locationLocationThe location where the request is restricted to
actionstringThe Beckn protocol method being called by the sender and executed at the receiver.
versionstringVersion of transaction protocol being used by the sender.
bap_idstringSubscriber ID of the Application Platform
bap_uristringSubscriber URL of the Application Platform for accepting callbacks from Provider Platforms.
bpp_idstringSubscriber ID of the Provider Platform
bpp_uristringSubscriber URL of the Provider Platform for accepting calls from Application Platforms.
transaction_idstringThis is a unique value which persists across all API calls from search through confirm. This is done to indicate an active user session across multiple requests. The Provider Platforms can use this value to push personalized recommendations, and dynamic offerings related to an ongoing transaction despite being unaware of the user active on the Application Platform.Format: uuid
message_idstringThis is a unique value which persists during a request / callback cycle. Since beckn protocol APIs are asynchronous, Application Platforms need a common value to match an incoming callback from a Provider Platform to an earlier call. This value can also be used to ignore duplicate messages coming from the Provider Platform. It is recommended to generate a fresh message_id for every new interaction. When sending unsolicited callbacks, Provider Platforms must generate a new message_id.Format: uuid
timestampstringTime of request generation in RFC3339 formatFormat: date-time
keystringThe encryption public key of the sender
ttlstringThe duration in ISO8601 format after timestamp for which this message holds valid
### 7.2.15 Country **Description:** Outlines a country. **Fields:** | Name | Type | Description | | ---- | ------ | ---------------------------------------------------- | | name | string | Name of the country | | code | string | Country code as per ISO 3166-1 and ISO 3166-2 format | ### 7.2.16 Credential **Description:** Outlines a credential of an entity (Person or Organization). **Fields:**
NameTypeDescriptionNotesEnum
idstring
typestringTakes a default value of "VerifiableCredential"
urlstringURL of the credentialFormat: uri
### 7.2.17 Customer **Description:** Outlines a customer buying/availing a product or a service. **Fields:** | Name | Type | Description | | ------- | -------------------------- | -------------------------------- | | person | [Person](#7.2.39-person) | Personal details of the customer | | contact | [Contact](#7.2.13-contact) | Contact details of the customer | ### 7.2.18 DecimalValue **Description:** Outlines a numerical value in decimal form. The string value should match the pattern "\[+-]?(\[0-9]\*\[.])?\[0-9]+". ### 7.2.19 Descriptor **Description:** Physical description of something. **Fields:** | Name | Type | Description | | ---------------- | ------------------------------------ | ------------------------------------------------------------------------ | | name | string | Name of the entity being described using this object | | code | string | Code of the entity being described using this object | | short\_desc | string | Short description of the entity being described using this object | | long\_desc | string | Long description of the entity being described using this object | | additional\_desc | object | Additional descriptions of the entity being described using this object | | media | [MediaFile](#7.2.33-mediafile) array | Multimedia files describing the entity being described using this object | | images | [Image](#7.2.28-image) array | Image describing the entity being described using this object | ### 7.2.20 Domain **Description:** Outlines the industry sector or sub-sector. The network policy should contain codes for all the industry sectors supported by the network. Domains can be created in varying levels of granularity. The granularity of a domain can be decided by the participants of the network. Too broad domains will result in irrelevant search broadcast calls to Provider Platforms that don't have services supporting the domain. Too narrow domains will result in a large number of registry entries for each Provider Platform. It is recommended that network facilitators actively collaborate with various working groups and network participants to carefully choose domain codes keeping in mind relevance, performance, and opportunity cost. It is recommended that networks choose broad domains like mobility, logistics, healthcare etc, and progressively granularize them as and when the number of network participants for each domain grows large. **Fields:** | Name | Type | Description | | ---------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | name | string | Name of the domain | | code | string | Standard code representing the domain. The standard is usually published as part of the network policy. Furthermore, the network facilitator should also provide a mechanism to provide the supported domains of a network. | | additional\_info | string | A url that contains addtional information about that domain. | ### 7.2.21 Duration **Description:** Outlines duration as per ISO8601 format. ### 7.2.22 Error **Description:** Outlines an error object that is returned by an Application Platform, Provider Platform or BG as a response or callback to an action by another network participant. This object is sent when any request received by a network participant is unacceptable. This object can be sent either during Ack or with the callback. **Fields:** | Name | Type | Description | | ------- | ------ | -------------------------------------------------------------------------------------------------------------------------------- | | code | string | Standard error code. For full list of error codes, refer to docs/protocol-drafts/BECKN-005-ERROR-CODES-DRAFT-01.md of this repo" | | paths | string | Path to json schema generating the error. Used only during json schema validation errors | | message | string | Human readable message describing the error. Used mainly for logging. Not recommended to be shown to the user. | ### 7.2.23 Fee **Description:** A fee applied to a particular entity. **Fields:** | Name | Type | Description | | ---------- | ------------------------------------ | --------------------------------------- | | percentage | [DecimalValue](#7.2.18-decimalvalue) | Percentage of order value levied as fee | | amount | [Price](#7.2.40-price) | Value of the fee levied | ### 7.2.24 Form **Description:** Outlines a form. **Fields:** | Name | Type | Description | Notes | Enum | | -------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------------- | | url | string | The URL from where the form can be fetched. The content fetched from the url must be processed as per the mime\_type specified in this object. Once fetched, the rendering platform can choosed to render the form as-is as an embeddable element; or process it further to blend with the theme of the application. In case the interface is non-visual, the the render can process the form data and reproduce it as per the standard specified in the form. | Format: uri | | | data | object | The form submission data | | | | mime\_type | string | This field indicates the nature and format of the form received by querying the url. MIME types are defined and standardized in IETF's RFC 6838. | | text/html, application/xml | | submission\_id | string | | Format: uuid | | ### 7.2.25 Fulfillment **Description:** Outlines how an order will be rendered/fulfilled to the end customer. **Fields:** | Name | Type | Description | | -------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | id | string | Unique reference ID to the fulfillment of an order | | type | string | A code that describes the mode of fulfillment. This is typically set when there are multiple ways an order can be fulfilled. For example, a retail order can be fulfilled either via store pickup or a home delivery. Similarly, a medical consultation can be provided either in-person or via tele-consultation. The network policy must publish standard fulfillment type codes for the different modes of fulfillment. | | rateable | boolean | Whether the fulfillment can be rated or not | | rating | [Rating](#7.2.43-rating) | The rating value of the fulfullment service. | | state | [FulfillmentState](#7.2.26-fulfillmentstate) | The current state of fulfillment. The Provider Platform must set this value whenever the state of the order fulfillment changes and fire an unsolicited `on_status` call. | | tracking | boolean | Indicates whether the fulfillment allows tracking. Has a default value of false. | | customer | [Customer](#7.2.17-customer) | the intended recipient of a fulfilled order | | agent | [Agent](#7.2.4-agent) | The agent that is currently handling the fulfillment of the order | | contact | [Contact](#7.2.13-contact) | Contact details related to the fulfillment | | vehicle | [Vehicle](#7.2.56-vehicle) | Vehicle used for fulfillment of the order | | stops | [Stop](#7.2.50-stop) array | The list of logical stops encountered during the fulfillment of an order. | | path | string | The physical path taken by the agent that can be rendered on a map. The allowed format of this property can be set by the network. | | tags | [TagGroup](#7.2.53-taggroup) array | List of grouped key-value pairs to transmit extended metadata related to the fulfillment | ### 7.2.26 FulfillmentState **Description:** Outlines the state of fulfilment. **Fields:**
NameTypeDescriptionNotesEnum
descriptorDescriptorThe description of the current fulfillment state of a confirmed order
updated_atstringTime at which the state of fulfillment was updatedFormat: date-time
updated_bystringID of entity which changed the state
### 7.2.27 Gps **Description:** Outlines a GPS coordinate. The string value should be of the pattern "^\[-+]?(\[1-8]?\d(\\.\d+)?|90(\\.0+)?),\s\*\[-+]?(180(\\.0+)?|((1\[0-7]\d)|(\[1-9]?\d))(\\.\d+)?)$". ### 7.2.28 Image **Description:** Outlines an image. **Fields:** | Name | Type | Description | Notes | Enum | | ---------- | ------ | ---------------------------------------------------------------------------------------- | ----------- | -------------------------- | | url | string | URL to the image. This can be a data url or an remote url | Format: uri | | | size\_type | string | The size of the image. The network policy can define the default dimensions of each type | | xs, sm, md, lg, xl, custom | | width | string | Width of the image in pixels | | | | height | string | Height of the image in pixels | | | ### 7.2.29 Intent **Description:** The intent to buy or avail of a product or a service. The Application Platform can declare the intent of the consumer containing what they want (A product, service, offer)/Who they want (A seller, service provider, agent etc)/Where they want it and where they want it from/When they want it (start and end time of fulfilment/How they want to pay for it/This has properties like descriptor, provider, fulfilment, payment, category, offer, item, tags. This is typically used by the Application Platform to send the purpose of the user's search to the Provider Platform. This will be used by the Provider Platform to find products or services it offers that may match the user's intent. For example, in Mobility, the mobility consumer declares a mobility intent. In this case, the mobility consumer declares information that describes various aspects of their journey like, where would they like to begin their journey (intent.fulfillment.start.location)/Where would they like to end their journey (intent.fulfillment.end.location)/When would they like to begin their journey (intent.fulfillment.start.time)/When would they like to end their journey (intent.fulfillment.end.time)/Who is the transport service provider they would like to avail services from (intent.provider)/Who is traveling (This is not recommended in public networks) (intent.fulfillment.customer)/What kind of fare product would they like to purchase (intent.item)/What add-on services would they like to avail/What offers would they like to apply on their booking (intent.offer)/What category of services would they like to avail (intent.category)/What additional luggage are they carrying/How would they like to pay for their journey (intent.payment). For example, in health domain, a consumer declares the intent for a lab booking the describes various aspects of their booking like, where would they like to get their scan/test done (intent.fulfillment.start.location)/When would they like to get their scan/test done (intent.fulfillment.start.time)/When would they like to get the results of their test or scan (intent.fulfillment.end.time)/Who is the service provider they would like to avail services from (intent.provider)/Who is getting the test or scan (intent.fulfillment.customer)/What kind of test or scan would they like to purchase (intent.item)/What category of services would they like to avail (intent.category)/How would they like to pay for their journey (intent.payment). **Fields:** | Name | Type | Description | | ----------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------ | | descriptor | [Descriptor](#7.2.19-descriptor) | A raw description of the search intent. Free text search strings, raw audio, etc can be sent in this object. | | provider | [Provider](#7.2.41-provider) | The provider from which the customer wants to place to the order from | | fulfillment | [Fulfillment](#7.2.25-fulfillment) | Details on how the customer wants their order fulfilled Fulfillment | | payment | [Payment](#7.2.38-payment) | Details on how the customer wants to pay for the order. Payment | | category | [Category](#7.2.10-category) | Details on the item category | | offer | [Offer](#7.2.34-offer) | details on the offer the customer wants to avail | | item | [Item](#7.2.31-item) | Details of the item that the consumer wants to order | | tags | [TagGroup](#7.2.53-taggroup) array | [Tags](#7.3.52-tag) | ### 7.2.30 ItemQuantity **Description:** Outlines the count or amount of an item. **Fields:** | Name | Type | Description | | --------- | ------ | -------------------------------------------------------------------------------------------------------------------- | | allocated | object | This represents the exact quantity allocated for purchase of the item. | | available | object | This represents the exact quantity available for purchase of the item. The buyer can only purchase multiples of this | | maximum | object | This represents the maximum quantity allowed for purchase of the item | | minimum | object | This represents the minimum quantity allowed for purchase of the item | | selected | object | This represents the quantity selected for purchase of the item | | unitized | object | This represents the quantity available in a single unit of the item | ### 7.2.31 Item **Description:** Outlines a product or a service offered to the end consumer by the provider. In the mobility sector, it can represent a fare product like a one-way journey. In the logistics sector, it can represent the delivery service offering. In the retail domain, it can represent a product like a grocery item. **Fields:** | Name | Type | Description | | ---------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | id | string | ID of the item. | | parent\_item\_id | string | ID of the item, this item is a variant of | | parent\_item\_quantity | [ItemQuantity](#7.2.30-itemquantity) | The number of units of the parent item this item is a multiple of | | descriptor | [Descriptor](#7.2.19-descriptor) | Physical description of the item | | creator | [Organization](#7.2.37-organization) | The creator of this item | | price | [Price](#7.2.40-price) | The price of this item, if it has intrinsic value | | quantity | [ItemQuantity](#7.2.30-itemquantity) | The quantity of the item | | category\_ids | array | Categories this item can be listed under | | fulfillment\_ids | array | Modes through which this item can be fulfilled | | location\_ids | array | Provider Locations this item is available in | | payment\_ids | array | Payment modalities through which this item can be ordered | | add\_ons | [AddOn](#7.2.2-addon) array | Add-ons to be included with the item | | cancellation\_terms | [CancellationTerm](#7.2.8-cancellationterm) array | Cancellation terms of this item | | refund\_terms | RefundTerm array | Refund terms of this item | | replacement\_terms | [ReplacementTerm](#7.2.45-replacementterm) array | Terms that are applicable be met when this item is replaced Replacement Terms | | return\_terms | [ReturnTerm](#7.2.46-returnterm) array | Terms that are applicable when this item is returned Return Terms | | xinput | [XInput](#7.2.57-xinput) | Additional input required from the customer to purchase / avail this item XInput | | time | [Time](#7.2.54-time) | Temporal attributes of this item. This property is used when the item exists on the catalog only for a limited period of time. | | rateable | boolean | Whether this item can be rated | | rating | [Rating](#7.2.43-rating) | The rating of the item | | matched | boolean | Whether this item is an exact match of the request | | related | boolean | Whether this item is a related item to the exactly matched item | | recommended | boolean | Whether this item is a recommended item to a response | | ttl | string | Time to live in seconds for an instance of this schema | | tags | [TagGroup](#7.2.53-taggroup) array | Grouped list of extended data regarding the item | ### 7.2.32 Location **Description:** The physical location of something. **Fields:** | Name | Type | Description | Notes | Enum | | ---------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------- | ---- | | id | string | | | | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the location | | | | map\_url | string | The url to the map of the location. This can be a globally recognized map url or the one specified by the network policy. | Format: uri | | | gps | [Gps](#7.2.27-gps) | The GPS co-ordinates of this location. | | | | address | [Address](#7.2.3-address) | The address of this location. | | | | city | [City](#7.2.12-city) | The city this location is, or is located within | | | | district | District | The district this location is, or is located within | | | | state | [State](#7.3.49-state) | The state this location is, or is located within | | | | country | [Country](#7.2.15-country) | The country this location is, or is located within | | | | area\_code | string | Area code of the location ex : ZIP code, Pincode etc | | | | circle | [Circle](#7.2.11-circle) | Circle that forms the boundary of the location | | | | polygon | string | The boundary polygon of this location | | | | 3dspace | string | The three dimensional region describing this location | | | | rating | [Rating](#7.2.43-rating) | The rating of this location | | | ### 7.2.33 MediaFile **Description:** This object contains a URL to a media file. **Fields:**
NameTypeDescriptionNotesEnum
mimetypestringindicates the nature and format of the document, file, or assortment of bytes. MIME types are defined and standardized in IETF's RFC 6838
urlstringThe URL of the fileFormat: uri
signaturestringThe digital signature of the file signed by the sender
dsastringThe signing algorithm used by the sender
### 7.2.34 Offer **Description:** An offer associated with a catalog. This is typically used to promote a particular product and enable more purchases. **Fields:** | Name | Type | Description | | ------------- | ---------------------------------- | -------------------------------------------- | | id | string | | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the offer | | location\_ids | array | IDs of the Locations this offer is valid in | | category\_ids | array | IDs of the Categories this offer is valid in | | item\_ids | array | IDs of the items this offer is valid in | | time | [Time](#7.2.54-time) | Time for which this offer is valid | | tags | [TagGroup](#7.2.53-taggroup) array | Additional metadata related to this offer | ### 7.2.35 Option **Description:** Outlines a selectable option. **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | ------------------------- | | id | string | | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the option | ### 7.2.36 Order **Description:** Outlines a legal purchase order. It contains the complete details of the legal contract created between the buyer and the seller. **Fields:**
NameTypeDescriptionNotesEnum
idstringHuman-readable ID of the order. This is generated at the Provider Platform layer. The Provider Platform can either generate order id within its system or forward the order ID created at the provider level.
ref_order_idsarrayA list of order IDs to link this order to previous orders.
statusstringStatus of the order. Allowed values can be defined by the network policyEnum Data Type in C: ACTIVE, COMPLETE, CANCELLEDACTIVE, COMPLETE, CANCELLED
typestringThis is used to indicate the type of order being created to Provider Platforms. Sometimes orders can be linked to previous orders, like a replacement order in a retail domain. A follow-up consultation in healthcare domain. A single order part of a subscription order. The list of order types can be standardized at the network level. Has a default value of "DEFAULT"Enum Data Type in C: DRAFT, DEFAULTDRAFT, DEFAULT
providerProviderDetails of the provider whose catalog items have been selected.
itemsItems arrayThe items purchased / availed in this order
add_onsAddOn arrayThe add-ons purchased / availed in this order
offersOffers arrayThe offers applied in this order
billingBilling arrayThe billing details of this order
fulfillmentsFulfillment arrayThe fulfillments involved in completing this order
cancellationCancellationThe cancellation details of this order
cancellation_termsCancellationTerm arrayCancellation terms of this item
refund_termsRefundTerm arrayRefund terms of this item
replacement_termsReplacementTerm arrayReplacement terms of this item
return_termsReturnTerm arrayReturn terms of this item
quoteQuotationThe mutually agreed upon quotation for this order.
paymentsPayment arrayThe terms of settlement for this order
created_atstringThe date-time of creation of this orderFormat: date-time
updated_atstringThe date-time of updated of this orderFormat: date-time
xinputXInputAdditional input required from the customer to confirm this order
tagsTagGroup arrayGrouped list of extended metadata related to the Order
### 7.2.37 Organization **Description:** An organization. Usually a recognized business entity. **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | ------------------------------------------------------------ | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the organization | | address | [Address](#7.2.3-address) | The postal address of the organization | | state | [State](#7.3.49-state) | The state where the the organization's address is registered | | city | [City](#7.2.12-city) | The city where the the organization's address is registered | | contact | [Contact](#7.2.13-contact) | Contact details of the organization | ### 7.2.38 Payment **Description:** Outlines the terms of settlement between the Application Platform and the Provider Platform for a single transaction. When instantiated, this object contains the amount that has to be settled/The payment destination details/When the settlement should happen/A transaction reference ID. During a transaction, the Provider Platform reserves the right to decide the terms of payment. However, the Application Platform can send its terms to the Provider Platform first. If the Provider Platform does not agree to those terms, it must overwrite the terms and return them to the Application Platform. If overridden, the Application Platform must either agree to the terms set by the Provider Platform in order to preserve the provider's autonomy or abort the transaction. In case of such disagreements, the Application Platform and the Provider Platform can perform offline negotiations on the payment terms. Once an agreement is reached, the Application Platform and Provider Platform can resume transactions. **Fields:**
NameTypeEnumFormatDescription
idstringID of the payment term that can be referred at an item or an order level in a catalog
collected_byThis field indicates who is the collector of payment. The Application Platform can set this value to 'Application Platform' if it wants to collect the payment first and settle it to the Provider Platform. If the Provider Platform agrees to those terms, the Provider Platform should not send the payment url. Alternatively, the Provider Platform can set this field with the value 'Provider Platform' if it wants the payment to be made directly.
urlstringFormat: uriuriA payment url to be called by the Application Platform. If empty, then the payment is to be done offline. The details of payment should be present in the params object. If tl_method = http/get, then the payment details will be sent as url params. Two url param values, $transaction_id and $amount are mandatory.
paramsobject
typestringPRE-ORDER, PRE-FULFILLMENT, ON-FULFILLMENT, POST-FULFILLMENT
statusstringPAID, NOT-PAID
timeTimeTemporal details related to the settlement of the orderTime
tagsTagGroup arrayGrouped list of metadata related to the settlement of the orderTags
### 7.2.39 Person **Description:** Outlines a person as any individual. **Fields:**
NameTypeDescriptionNotesEnum
idstringDescribes the identity of the person
urlstringProfile url of the personFormat: uri
namestringthe name of the person
imageImageImage
ageDurationAge of the person
dobstringDate of birth of the personFormat: date
genderstringGender of something, typically a Person, but possibly also fictional characters, animals, etc. While Male and Female may be used, text strings are also acceptable for people who do not identify as a binary gender.Allowed values for this field can be published in the network policy
credsCredential arrayList of the person's credentials
languagesarray
skillsarray
tagsTagGroup arrayGrouped list containing extended metadata about the person
### 7.2.40 Price **Description:** Outlines the price of an Item **Fields:** | Name | Type | Description | | ---------------- | ------------------------------------ | -------------------------------- | | currency | string | | | value | [DecimalValue](#7.2.18-decimalvalue) | Default value of the Item price | | estimated\_value | [DecimalValue](#7.2.18-decimalvalue) | Estimated value of an Item price | | computed\_value | [DecimalValue](#7.2.18-decimalvalue) | Computed value of an Item price | | listed\_value | [DecimalValue](#7.2.18-decimalvalue) | Listed value of an Item price | | offered\_value | [DecimalValue](#7.2.18-decimalvalue) | Offered value of an Item price | | minimum\_value | [DecimalValue](#7.2.18-decimalvalue) | Minimum value of an Item price | | maximum\_value | [DecimalValue](#7.2.18-decimalvalue) | Maximum value of an Item price | ### 7.2.41 Provider **Description:** Outlines the catalog of a business. **Fields:**
NameTypeDescriptionNotesEnum
idstringId of the provider
descriptorDescriptorDescription of the provider
category_idstringCategory Id of the provider at the Provider Platform-level catalog
ratingRatingRating of the provider
timeTimeTime during which the catalog is available
categoriesCategory arrayCategories in the catalog
fulfillmentsFulfillment arrayList of fulfillment terms of the provider
paymentsPayment arrayList of payment terms of the provider
locationsLocation arrayLocations where the provider can be accessed
offersOffer arrayOffers listed by the provider
itemsItem arrayItems cataloged by the provider
expstringTime after which catalog has to be refreshedFormat: date-time
rateablebooleanWhether this provider can be rated or not
ttlintegerThe time-to-live in seconds, for this object. This can be overriden at deeper levels. A value of -1 indicates that this object is not cacheable.
tagsTagGroup arrayGrouped metadata related to the provider
### 7.2.42 Quotation **Description:** Outlines a quote. It is the estimated price of products or services from the Provider Platform. This has properties like price, breakup, and TTL. **Fields:**
NameTypeDescriptionNotesEnum
idstringID of the quote.Format: uuid
pricePriceThe total quoted price
breakuparraythe breakup of the total quoted price
ttlDurationDuration for which the quotation is valid
### 7.2.43 Rating **Description:** Outlines the rating of an entity. **Fields:**
NameTypeDescriptionNotesNotes
rating_categorystringCategory of the entity being ratedEnum Data Type in C: Item, Order, Fulfillment, Provider, Agent, Support
idstringId of the object being rated
valuestringRating value given to the object. This can be a single value or can also contain an inequality operator like gt, gte, lt, lte. This can also contain an inequality expression containing logical operators like && and.
### 7.2.44 Region **Description:** Outlines an arbitrary region of space. The network policy should contain a published list of supported regions by the network. **Fields:**
NameTypeDescriptionNotesFormat
dimensionsstringThe number of dimensions that are used to describe any point inside that region. The most common dimensionality of a region is 2, that represents an area on a map. There are regions on the map that can be approximated to one-dimensional regions like roads, railway lines, or shipping lines. 3 dimensional regions are rarer, but are gaining popularity as flying drones are being adopted for various fulfillment services.Enum Data Type in C: 1, 2, 3
typestringThe type of region. This is used to specify the granularity of the region represented by this object. Various examples of two-dimensional region types are city, country, state, district, and so on. The network policy should contain a list of all possible region types supported by the network.
namestringName of the region as specified on the map where that region exists.
codestringA standard code representing the region. This should be interpreted in the same way by all network participants.
boundarystringA string representing the boundary of the region. One-dimensional regions are represented by polylines. Two-dimensional regions are represented by polygons, and three-dimensional regions can represented by polyhedra.
map_urlstringThe url to the map of the region. This can be a globally recognized map or the one specified by the network policy.
### 7.2.45 ReplacementTerm **Description:** The replacement policy for an item or an order. **Fields:** | Name | Type | Description | | ------------------ | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | fulfillment\_state | [FulfillmentState](#7.2.26-fulfillmentstate) array | The state of fulfillment during which this term is applicable. | | replace\_within | [Time](#7.2.54-time) | Applicable only for buyer managed returns where the buyer has to replace the item before a certain date-time, failing which they will not be eligible for replacement. | | external\_ref | [MediaFile](#7.2.33-mediafile) | Any file containing info related to the terms | ### 7.2.46 ReturnTerm **Description:** Outlines the return policy of an item or an order. **Fields:**
NameTypeDescriptionNotesxx
fulfillment_stateFulfillmentState arrayThe state of fulfillment during which this term IETF''s applicable.
return_eligiblebooleanIndicates whether the item is eligible for return
return_timeTimeApplicable only for buyer managed returns where the buyer has to return the item to the origin before a certain date-time, failing which they will not be eligible for refund.
return_locationLocationThe location where the item or order must / will be returned to
fulfillment_managed_bystringThe entity that will perform the returnEnum Data Type in C: CONSUMER, PROVIDER
### 7.2.47 Scalar **Description:** Outlines a scalar. **Fields:**
NameTypeDescriptionNotesFormat
typestringEnum Data Type in C: CONSTANT, VARIABLE
valueDecimalValueDefault value
estimated_valueDecimalValueEstimated value
computed_valueDecimalValueComputed value
rangeDecimalValueRange of values
unitstringunit of value
### 7.2.48 Schedule **Description:** Outlines schedule as a repeating time period used to describe a regularly recurring event. At a minimum, a schedule will specify frequency which describes the interval between occurrences of the event. Additional information can be provided to specify the schedule more precisely. This includes identifying the timestamps(s) of when the event will take place. Schedules may also have holidays to exclude a specific day from the schedule. This has properties like frequency, holidays, and times. **Fields:** | Name | Type | Description | | --------- | ---------------------------- | ----------------------- | | frequency | [Duration](#7.2.21-duration) | Frequency of recurrence | | holidays | array | Holidays | | times | [Time](#7.2.54-time) array | Time slots | ### 7.3.49 State **Description:** A bounded geopolitical region of governance inside a country. **Fields:** | Name | Type | Description | | ---- | ------ | ---------------------------------------------------- | | name | string | Name of the state | | code | string | State code as per country or international standards | ### 7.2.50 Stop **Description:** A logical point in space and time during the fulfilment of an order. **Fields:** | Name | Type | Description | | ---------------- | -------------------------------------- | --------------------------------------------------------------------------------------- | | id | string | | | parent\_stop\_id | string | | | location | [Location](#7.2.32-location) | [Location](#7.3.32-location) of the stop | | type | string | The type of stop. Allowed values of this property can be defined by the network policy. | | time | [Time](#7.2.54-time) | Timings applicable at the stop. | | instructions | [Descriptor](#7.2.19-descriptor) array | Instructions that need to be followed at the stop | | contact | [Contact](#7.2.13-contact) | Contact details of the stop | | person | [Person](#7.2.39-person) | The details of the person present at the stop | | authorization | [Authorization](#7.2.5-authorization) | Authorization details required to commence this leg of fulfillment | ### 7.2.51 Support **Description:** Details of customer support. **Fields:**
NameTypeDescriptionNotesEnum
ref_idstring
callback_phonestringFormat: phone
phonestringFormat: phone
emailstringFormat: email
urlstringFormat: uri
### 7.2.52 Tag **Description:** Outlines a tag. This is used to contain extended metadata. This object can be added as a property to any schema to describe extended attributes. For Application Platforms, tags can be sent during search to optimize and filter search results. Provider Platforms can use tags to index their catalog to allow better search functionality. Tags are sent by the Provider Platform as part of the catalog response in the `on_search` callback. Tags are also meant for display purposes. Upon receiving a tag, Application Platforms are meant to render them as name-value pairs. This is particularly useful when rendering tabular information about a product or service. **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the Tag, can be used to store detailed information. | | value | string | The value of the tag. This set by the Provider Platform and rendered as-is by the Application Platform. | | display | boolean | This value indicates if the tag is intended for display purposes. If set to `true`, then this tag must be displayed. If it is set to `false`, it should not be displayed. This value can override the group display value. | ### 7.2.53 TagGroup **Description:** A collection of tag objects with group-level attributes ([Documentation on Tag Groups schema](https://github.com/beckn/protocol-specifications/discussions/316)). **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | display | boolean | Indicates the display properties of the tag group. If display is set to false, then the group will not be displayed. If it is set to true, it should be displayed. However, group-level display properties can be overriden by individual tag-level display property. As this schema is purely for catalog display purposes, it is not recommended to send this value during search. Has a default value of true. | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the TagGroup, can be used to store detailed information. | | list | array | An array of Tag objects listed under this group. This property can be set by Application Platforms during search to narrow the `search` and achieve more relevant results. When received during `on_search`, Application Platforms must render this list under the heading described by the `name` property of this schema. | ### 7.2.54 Time **Description:** Outlines time in its various forms. It can be a single point in time/duration or a structured timetable of operations. This has properties like label, timestamp, duration, range, days, and schedule. **Fields:**
NameTypeDescriptionNotesEnum
labelstring
timestampstringFormat: date-time
durationDurationDuration between two instances of time
rangeobject
daysstringcomma separated values representing days of the week
scheduleScheduleschedule
### 7.2.55 Tracking **Description:** Contains tracking information that can be used by the Application Platform to track the fulfillment of an order in real-time. which is useful for knowing the location of time-sensitive deliveries. **Fields:** | Name | Type | Description | Format | Enum | | -------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ---------------- | | id | string | A unique tracking reference number | | | | url | string | A URL to the tracking endpoint. This can be a link to a tracking webpage, a webhook URL created by the Application Platform where Provider Platform can push the tracking data, or a GET url creaed by the Provider Platform which the Application Platform can poll to get the tracking data. It can also be a websocket URL where the Provider Platform can push real-time tracking data. | uri | | | location | [Location](#7.2.32-location) | In case there is no real-time tracking endpoint available, this field will contain the latest location of the entity being tracked. The Provider Platform will update this value everytime the Application Platform calls the track API. | | | | status | string | This value indicates if the tracking is currently active or not. If this value is `active`, then the Application Platform can begin tracking the order. If this value is `inactive`, the tracking URL is considered to be expired and the Application Platform should stop tracking the order. | | active, inactive | ### 7.2.56 Vehicle **Description:** Outlines a vehicle is a device that is designed or used to transport people or cargo over land, water, air, or through space. This has properties like category, capacity, make, model, size, variant, colour,energy\_type, and registration. **Fields:** | Name | Type | Description | | ------------------ | ------- | ----------- | | category | string | | | capacity | integer | | | make | string | | | model | string | | | size | string | | | variant | string | | | color | string | | | energy\_type | string | | | registration | string | | | wheels\_count | string | | | cargo\_volumne | string | | | wheelchair\_access | string | | | code | string | | | emission\_standard | string | | ### 7.2.57 XInput **Description:** Contains any additional or extended inputs required to confirm an order. This is typically a Form Input. Sometimes, the selection of catalog elements is not enough for the Provider Platform to confirm an order. For example, to confirm a flight ticket, the airline requires details of the passengers along with information on baggage, and identity, in addition to the class of ticket. Similarly, a logistics company may require details on the nature of the shipment in order to confirm the shipping. A recruiting firm may require additional details on the applicant in order to confirm a job application. For all such purposes, they can choose to send this object attached to any object in the catalog that is required to be sent while placing the order. This object can typically be sent at an item level or at the order level. The item level XInput will override the Order level XInput as it indicates a special requirement of information for that particular item. Hence the Application Platform must render a separate form for the Item and another form at the Order level before confirmation. **Fields:** | Name | Type | Description | | -------- | -------------------- | ------------------------------------------------------------------------------------------------------ | | form | [Form](#7.2.24-form) | Form details to capture input | | required | boolean | Indicates whether the form data is mandatorily required by the Provider Platform to confirm the order. | | head | object | Form headers | # 8 Service APIs This section provides a reference for APIs that should be implemented by this Building Block. This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block. To develop the E-Marketplace Building Block API, we have referred to various open-source specifications and data standards. The objective is to develop an API specification for this building block that is future-proof to accommodate a broad range of use cases that is agnostic of industry sector, region, and implementation technology. To develop a common data standard, Several sector-specific marketplace specifications were referred to like [NetEx](https://www.transmodel-cen.eu/netex-standard/), [TOMP](https://github.com/TOMP-WG/TOMP-API), (for mobility), [Electronic Data Interchange](https://www.edibasics.com/what-is-edi/) for logistics, [Open Contracting and Data Standards](https://www.open-contracting.org/data-standard/) (OCDS), [Universal Business Language](http://docs.oasis-open.org/ubl/UBL-2.1.html) (UBL) for procurements, [HL7 / FHIR ](https://www.hl7.org/implement/standards/index.cfm?ref=nav)for healthcare. To understand activities involved in administering the e-marketplace, several open-source e-marketplace software APIs like [Magento](https://business.adobe.com/products/magento/magento-commerce.html), [WooCommerce](https://woocommerce.com/), and [OpenCart](https://www.opencart.com/), were also referred. To facilitate interoperability, we have referred to various open-source communication protocols, API and data standards like, [Schema.org](http://schema.org/) , [HTTP/2](https://datatracker.ietf.org/doc/html/rfc9113), and [DNS](https://datatracker.ietf.org/doc/html/rfc1035) and [Beckn protocol](https://becknprotocol.io/). Privacy and Security is especially important to Government E-marketplaces as they usually contain sensitive information about customers and businesses. In such a scenario, it is not recommended to create a “store-of-value” in between the consumer and the marketplace. Instead a more federated approach is needed that transforms a “Store-of-value” into a “Flow-of-value”. Such an architecture will ensure privacy and security of data, minimize concentration risk, and allow for innovation to happen at the edges rather than at the center. The E-Marketplace building block API specification has been *adapted* from Beckn protocol APIs and schema. Currently Beckn protocol is the only open-source specification that enables transaction interoperability in e-marketplaces through a peer-to-peer (flow-of-value) protocol. It is an open-source generic transaction protocol that when implemented, allows any application to perform discovery, ordering, fulfillment, and post-fulfillment activities *without* the need of a central intermediary. It is a widely adopted open-source protocol specification built using design principles and standards from all of the above mentioned technologies and standards. It is agnostic of industry sector, region, or implementation technology. It is highly recommended for any e-marketplace application in GovStack to also implement a Beckn protocol interface to allow any platform inside or outside the GovStack ecosystem to access the e-marketplace without the need of a central platform intermediary. Furthermore, It can be adapted to any existing sector-specific standard like the ones mentioned above. The [GovStack non-functional requirements](https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements/6-onboarding) document provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here. # 8.1 Catalog Management Platform Administration APIs consist of all the endpoints that are used to provide user experience and manage the business workflows like catalog management, cart management, checkout, terms management, content management, etc. These follow REST Standards for the creation, read, update, and deletion of objects in the database. {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/search" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/catalog/{resource}/{id}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/catalog/{resource}/{id}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/catalog/{resource}/{id}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/catalog/{resource}" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/catalog/provider/{providerId}/{resource}/{id}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/catalog/provider/{providerId}/{resource}/{id}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/catalog/provider/{providerId}/{resource}/{id}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/catalog/provider/{providerId}/{resource}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} # 8.2 Inventory Management Since inventory is a provider-centric feature, it does not interface with a customer. However, it is called by other services like quotation management, order management, and fulfillment management services. {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/search" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/inventory/checkAvailability/{resource}/{id}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/inventory/item/add" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/inventory/item/remove" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/inventory/item/block" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/inventory/addOn/unblock" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/inventory/addOn/block" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/inventory/item/unblock" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} # 8.3 Quotation Management {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/quotation" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} # 8.4 Order Terms Management {% openapi src="/files/O0xuMogVaCGC1bCwoMvX" path="/terms/payment" method="post" %} [beckn-e-marketplace-bb-0.2-resolved.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FBsxJlh2V5a3igTE0tuW7%2Fbeckn-e-marketplace-bb-0.2-resolved.yaml?alt=media\&token=4684cc1c-f253-4fcb-be44-b0312d6309b5) {% endopenapi %} {% openapi src="/files/O0xuMogVaCGC1bCwoMvX" path="/terms/fulfillment" method="post" %} [beckn-e-marketplace-bb-0.2-resolved.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FBsxJlh2V5a3igTE0tuW7%2Fbeckn-e-marketplace-bb-0.2-resolved.yaml?alt=media\&token=4684cc1c-f253-4fcb-be44-b0312d6309b5) {% endopenapi %} {% openapi src="/files/O0xuMogVaCGC1bCwoMvX" path="/terms/cancellation" method="post" %} [beckn-e-marketplace-bb-0.2-resolved.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FBsxJlh2V5a3igTE0tuW7%2Fbeckn-e-marketplace-bb-0.2-resolved.yaml?alt=media\&token=4684cc1c-f253-4fcb-be44-b0312d6309b5) {% endopenapi %} # 8.5 Order Management {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/orders" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/orders/{orderId}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/orders/{orderId}/updatePayment" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/orders/{orderId}/updateFulfillment" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/orders/{orderId}/updateBilling" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/orders/{orderId}/updateItems" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/orders/{orderId}/updateAddOns" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} {% openapi src="/files/n7oNKucJjLKy8tgNWea1" path="/orders/{orderId}/cancel" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F7wmyS46pPGjr2UJMi4Y8%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=ba08e80b-48d1-489f-8782-4123d6473618) {% endopenapi %} # 8.6 Order Fulfillment {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/fulfillments" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/fulfillments/{fulfillmentId}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/fulfillments/{fulfillmentId}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/fulfillments/{fulfillmentId}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/fulfillment/checkServiceability" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/fulfillment/{fulfillmentId}/agent/allocate" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/fulfillment/{fulfillmentId}/agent/deallocate" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} # 8.7 Order Tracking {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/tracking/start" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/tracking/stop" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/tracking/{order\_id}/update\_location" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} # 8.9 Rating and Feedback Management {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/forms" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/forms/{formId}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/forms/{formId}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/forms/{formId}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/generateFeedbackForRating" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} # 8.12 Support Management These endpoints enables all customer support services to be managed. {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/support/{orderId}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/support/{orderId}" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/support/{orderId}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/support/{orderId}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/support/{orderId}/agent" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/support/{orderId}/agent" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} {% openapi src="/files/jl6d6DgsUdyLeUw57XlH" path="/support/{orderId}/agent" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://1714732563-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FF5Pn2d5d2HqJIEjHcHW2%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media\&token=5ef6b045-a5a2-491e-ad96-69366ed4e7cb) {% endopenapi %} # 8.13 Order Lifecycle APIs These APIs are implemented as a beckn protocol endpoint to enable the E-Marketplace BB to become accessible by any consumer application inside or outside the GovStack ecosystem. These APIs are implemented as a beckn protocol endpoint to enable the E-Marketplace BB to become accessible by any consumer application inside or outside the GovStack ecosystem. # 8.13.1 Requests {% openapi src="" path="/search" method="post" %} {% endopenapi %} {% openapi src="" path="/select" method="post" %} {% endopenapi %} {% openapi src="" path="/init" method="post" %} {% endopenapi %} {% openapi src="" path="/confirm" method="post" %} {% endopenapi %} {% openapi src="" path="/status" method="post" %} {% endopenapi %} {% openapi src="" path="/update" method="post" %} {% endopenapi %} {% openapi src="" path="/track" method="post" %} {% endopenapi %} {% openapi src="" path="/cancel" method="post" %} {% endopenapi %} {% openapi src="" path="/rating" method="post" %} {% endopenapi %} {% openapi src="" path="/support" method="post" %} {% endopenapi %} {% openapi src="" path="/get\_rating\_categories" method="post" %} {% endopenapi %} {% openapi src="" path="/get\_return\_reasons" method="post" %} {% endopenapi %} {% openapi src="" path="/get\_cancellation\_reasons" method="post" %} {% endopenapi %} # 8.13.2 Callbacks {% openapi src="" path="/on\_search" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_select" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_init" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_confirm" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_status" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_rating" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_support" method="post" %} {% endopenapi %} {% openapi src="" path="/rating\_categories" method="post" %} {% endopenapi %} {% openapi src="" path="/cancellation\_reasons" method="post" %} {% endopenapi %} {% openapi src="" path="/return\_reasons" method="post" %} {% endopenapi %} # 9 Internal Workflows This section provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases. In this section, we identify workflows to manifest some of the main services. These may be enhanced or customized as needed for specific implementation needs. The following common preconditions may need to be met before utilizing these services: Entities are registered and active in the system. Currently, acting entities will be logged in the system and have sufficient roles to act. The Initiator Building Block and the target block must be registered in the system as network participants with status as subscribed and should be active. This section captures the example workflows that may take place between internal functional blocks to orchestrate key functionalities for a minimum viable product as follows. The exact workflows may be decided depending on implementation time considerations. * User search for product/service from a provider platform. * Viewing an item from the provider catalog. * Inventory management. * Selection of the product. * Initiation of the purchase request. * Confirmation of the order. * Checking the status of the order. * Cancellation of the order. * Tracking of an active order. * Feedback for an order. * support for an order. * Catalog management. ## 9 Order Lifecycle Workflows ### 9.1 Searching for Items The search flow allows consumers to search for available products or services. When a consumer initiates a search request, the catalog providers relevant products or services available respond to the search request by sending back detailed information about their offerings. This includes product details such as descriptions, images, specifications, prices, and any applicable offers or promotions. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Catalog Management end consumer-->>consumer interface: search consumer interface->>Catalog Management:declare search intent Catalog Management->>consumer interface:return catalog consumer interface-->>consumer:view search results" %} ### 9.2 Catalog Management This allows the creation of a catalog for a product or a service based on the request made by the user. This allows users to update the catalogs of a product or service. New attributes can be added or removed from a catalog. Users while searching for products can request the catalog of the product or the services, and the platform will fetch and serve back user with the required catalog. {% @mermaid/diagram content="sequenceDiagram UI->>consumer platform interface: catalog consumer platform interface->>provider platform interface: catalog provider platform interface->>Catalog:catalog provider platform interface->>consumer platform interface: on\_catalog consumer platform interface->>UI: catalog Response" %} ### 9.3 Inventory Management This enables users to manage inventory of the products also they can add or remove products from the inventory. {% @mermaid/diagram content="sequenceDiagram Admin UI->>provider interface: fetch inventory list provider interface->>Inventory: fetch inventory list Inventory->>provider interface: return inventory list provider interface->>Admin UI:Return invetory list" %} ### 9.4 Quotation Management The consumer utilizes the internal workflow within the platform to explore and select from a range of available offers and attributes. These choices have an impact on the pricing, as different combinations can result in varying costs. Once the consumer has made their selections, the consumer platform sends a request to the provider platform. The purpose of this request is to validate the chosen offers and attributes against the provider's system. The provider platform conducts the necessary validation checks to ensure the selected offers and attributes are accurate and permissible. If any discrepancies or changes are identified, the provider platform communicates this information back to the consumer. Upon receiving the feedback from the provider platform, the consumer can review the changes and make any necessary adjustments or confirm the modified selections. This internal workflow allows the consumer to have control and flexibility in selecting offers and attributes, while also ensuring that the provider's systems validate the choices for accuracy and feasibility. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Quotation Management participant Inventory Management end consumer-->>consumer interface: select items
from catalog consumer interface->>Quotation Management:request
quote Quotation Management->>Inventory Management: check availability Inventory Management->>Quotation Management: return availability Quotation Management->>consumer interface:return quote
with breakup consumer interface-->>consumer: view quote
with breakup" %} ### 9.5 Initializing an order by providing billing and fulfillment details The consumer carefully reviews the contents of their cart, ensuring that everything selected is accurate and satisfactory. Once satisfied, the consumer initiates a checkout call, indicating their intention to proceed with the payment. This action finalizes the cart, preventing any further modifications. The consumer platform then sends a request to the provider platform to initialize the payment process for the products or services in the cart. In response, the provider platform generates a payment link and presents the consumer with additional terms and conditions related to the payment. The payment link serves as a gateway for the consumer to complete the transaction securely. It directs them to a designated payment page where they can input their payment information and finalize the purchase. Alongside the payment link, the provider platform communicates any specific terms and conditions associated with the payment, ensuring that the consumer is aware of any applicable fees, refund policies, or other relevant details. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Terms Management participant Inventory Management participant Quotation Management participant Fulfillment Management end consumer-->>consumer interface: provide billing
and fulfillment details consumer interface->>Order Management: initialize
draft order Order Management->>Inventory Management: check availability Inventory Management->>Order Management: return availability Order Management->>Inventory Management: lock inventory Inventory Management->>Order Management: return inventory
lock status Order Management->>Quotation Management: fetch quote Quotation Management->>Order Management: return quote Order Management->>Fulfillment Management: check serviceability Fulfillment Management->>Order Management: return serviceability
with fulfillment charges Order Management->>Terms Management: fetch Payment Terms,
Cancellation Terms,
Fulfillment Terms Order Management->>consumer interface: return draft
order with terms consumer interface-->>consumer:view final order
with checkout link " %} ### 9.6 Confirming an Order Once the consumer receives the payment link and reviews the terms and conditions, they proceed to make a payment. Upon a successful transaction, the consumer platform initiates a confirmation call to the provider platform. This call serves as a notification that the payment has been completed and confirms the order placement. The provider platform acknowledges the confirmation call and responds with a success message. Along with the success message, the provider platform shares the details of the order that has been placed. These order details typically include information such as the order ID, items purchased, quantity, price, and any additional relevant data. The consumer can then utilize the order details received from the provider platform to further check the status of their order. This information allows the consumer to track the progress of their order, anticipate the delivery, and stay informed about any updates or changes related to the order. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Fulfillment Management participant Payment BB Interface participant E-Signature BB Interface end consumer-->>consumer interface: checkout consumer interface->>Payment BB Interface: pay for order consumer interface->>E-Signature BB Interface:sign order consumer interface->>Order Management:confirm order Order Management->>E-Signature BB Interface:verify signature Order Management->>Order Management: Create Order Order Management->>Fulfillment Management: check serviceability Order Management->>E-Signature BB Interface:sign order Order Management->>consumer interface: Return Confirmed Order consumer interface->>E-Signature BB Interface:verify signature consumer interface-->>consumer:view confirmed order " %} ### 9.7 Checking the status of an order Once an order is confirmed, the user receives the details of the confirmed order, and they have the option to check the status of their order. The order status typically includes stages such as "placed," "packed," "dispatched," and so on. The "placed" status indicates that the order has been successfully received and recorded. The "packed" status signifies that the items in the order have been gathered and prepared for shipment. The "dispatched" status indicates that the package has been handed over to the delivery service for transportation. #### 9.7.1 User explicitly requests for the fulfillment status of the order {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Fulfillment Management end consumer-->>consumer interface: view order consumer interface->>Order Management:get order status Order Management->>Fulfillment Management:fetch fulfillment state Fulfillment Management->>Order Management: return current status
of fulfillment Order Management->>consumer interface: return latest order state consumer interface-->>consumer: display latest status of order" %} #### 9.7.2 Provider's Agent asynchronously updates the fulfillment status of an order at their end {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Fulfillment Management end participant Agent Interface Actor Agent Agent -->> Agent Interface: update fulfillment status Agent Interface-->>Fulfillment Management: Update fulfillment status Fulfillment Management->>Order Management: update current status
of fulfillment Order Management->>consumer interface: return latest order state consumer interface-->>consumer: display latest status of order" %} ### 9.8 Tracking the fulfillment of an order When a consumer places an order and it is confirmed, they are provided with the option to track the status of their order. This tracking feature allows the consumer to stay informed about the progress of their purchase. The order status typically encompasses various updates related to the delivery process, giving the consumer insights into the whereabouts and estimated arrival time of their package. One of the primary aspects of the order status is the delivery status, which indicates whether the package has been dispatched from the provider's location or the warehouse. It confirms that the order is on its way to the consumer. This status assures the consumer that their purchase is in the process of being delivered. #### 9.8.1 Update Agent's tracking information Users can update the tracking status of an order. {% @mermaid/diagram content="sequenceDiagram box E-Marketplace BB participant Tracking Management end participant Agent interface Actor Agent loop periodically Agent-->>Agent interface: generate tracking data Agent interface->>Tracking Management: push tracking data end" %} #### 9.8.2 Tracking an order Users can request to get the tracking status of an order. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Tracking Management end consumer-->>consumer interface: track order consumer interface->>Order Management: track order Order Management->>Tracking Management: track order Order Management->> Tracking Management: fetch tracking link Order Management->> consumer interface: send tracking link consumer interface-->>consumer: render real-time
tracking screen consumer interface-->>Tracking Management: start tracking Tracking Management-->>consumer interface: stream real-time tracking data consumer interface-->>consumer: view real-time
tracking data " %} ### 9.9 Updating an Order #### 9.9.1 Consumer-initiated update {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Terms Management participant Fulfillment Management participant Payment BB Interface end consumer-->>consumer interface: provide updated information consumer interface->>Order Management:update order Order Management->>Terms Management:validate
update terms Terms Management->>Order Management: return
update charges Order Management->>Fulfillment Management:update fulfillment Order Management->>consumer interface: return updated order consumer interface-->>consumer: display update
order with
update charges Order Management->>Payment BB Interface: Initiate Payment / Refund" %} #### 9.9.2 Provider Initiated Update {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Fulfillment Management participant Payment BB Interface end participant Agent interface Actor Agent Agent-->>Agent interface: update order information Agent interface->>Fulfillment Management:update order state Fulfillment Management->>Order Management:update fulfillment Order Management->>consumer interface: send updated order consumer interface-->>consumer: display updated
order Order Management->>Payment BB Interface: (Optionally) Initiate Refund
to consumer" %} ### 9.10 Cancelling an Order When a consumer places an order and it is confirmed, they are provided with the option to cancel their order. This will allow the user to cancel the order before receiving an order. #### 9.10.1 Consumer initiated cancellation {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Terms Management participant Fulfillment Management participant Payment BB Interface end consumer-->>consumer interface: cancel order consumer interface->>Order Management:cancel order with reason Order Management->>Terms Management:validate
cancellation terms Terms Management->>Order Management: return
cancellation charges Order Management->>Fulfillment Management:cancel fulfillment Order Management->>consumer interface: return cancelled order consumer interface-->>consumer: display cancelled
order with
cancellation fees Order Management->>Payment BB Interface: Initiate Refund" %} #### 9.10.2 Provider Initiated Cancellation {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Terms Management participant Fulfillment Management participant Payment BB Interface end participant Agent interface Actor Agent Agent-->>Agent interface: cancel fulfillment Agent interface->>Fulfillment Management:cancel fulfillment with reason Fulfillment Management->>Order Management:cancel fulfillment Order Management->>consumer interface: return cancelled order consumer interface-->>consumer: display cancelled
order with
cancellation fees Order Management->>Payment BB Interface: Initiate Refund
to consumer " %} ### 9.11 Rating and Feedback Management This allows users to rate any rate-able entity in the system, it can be a product, service, agent, etc. Users can also provide detailed feedback on the entities. #### 9.11.1 Rating an Order (without feedback) {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Rating Management end consumer interface->>Rating Management: fetch rateable entities Rating Management->>consumer interface: Return rateable entities consumer-->>consumer interface: provide rating consumer interface->>Rating Management: rate entity Rating Management->>consumer interface: Acknowledge rating " %} #### 9.11.2 Rating an order with feedback {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Rating Management participant Feedback Management end consumer interface->>Rating Management: fetch rateable entities Rating Management->>consumer interface: Return rateable entities consumer-->>consumer interface: provide rating consumer interface->>Rating Management: rate entity Rating Management->>Feedback Management: fetch form link Rating Management->>consumer interface: Acknowledge rating with
link to feedback form consumer interface-->>consumer: Display feedback form consumer-->>consumer interface: provide feedback consumer interface->>Feedback Management: Submit feedback Feedback Management->>consumer interface: Acknowledge feedback" %} ### 9.12 Support Management Users can request support, this can happen anytime during the lifecycle of an order. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Support Management participant Order Management end participant Customer Support Interface Actor customer support executive consumer-->>consumer interface: contact support consumer interface->>Support Management: fetch support info Support Management->>Order Management: fetch order Order Management->>Support Management: order details Support Management->> consumer interface: send support center info consumer interface-->>consumer: render support
center screen consumer interface->>Support Management: start chat session Support Management->>Support Management: Allocate executive Support Management->>Customer Support Interface: Notify executive Customer Support Interface-->>customer support executive: Open chat session Customer Support Interface-->>consumer interface: stream real-time chat data consumer interface-->>Customer Support Interface: stream real-time chat data " %} # 10 Other Resources This section links to any external documents that may be relevant, such as standards documents or other descriptions of this Building Block that may be useful. ## 10.1 Example Cross-Building Block Workflows Some common workflows that leverage the eMarketplace Building Block can be found here: [https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/em-b2g-uc2-sgp-sporting-goods-purchase](broken://spaces/YLLEfCKTnmzAMDSDzJJH/pages/01J9vycXVm3fePwLZ1wb) [https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/em-g2p-uc2-online-reservation-system-ors](broken://spaces/YLLEfCKTnmzAMDSDzJJH/pages/yjIfdDWZUD0ENjbx8oqM) [https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/em-g2p-uc3-government-auctions-marketplace-gam](broken://spaces/YLLEfCKTnmzAMDSDzJJH/pages/bS4Z0M1CzfQNXf4xQGja) ## 10.2 Key Decision Log NA ## 10.3 Future Considerations The E-Marketplace Building Block is agnostic to all forms of economic transactions. It provides a generic framework that standardizes any consumer-provider interaction like discovery, ordering, fulfillment and post-fulfillment. Due to its abstracted nature, it may be adapted to any use case. However, for the sake of simplicity, the use cases covered in this scope, especially in the case of procurements (B2G), assume that the suppliers (businesses) are already vetted and empanelled by the buyer. The actual process of proposal, evaluation, and awarding of contract though adaptable to the generic framework is kept out of scope for the sake of simplicity. These features will be included later in future versions of the specification as and when diverse procurement use cases from across the globe and across domains are considered, abstracted and adapted to this framework. # EM-G2P-UC2-Online Reservation System (ORS) ## eM-G2P-UC2-Online Reservation System (ORS) #### MKT-G2P-UC2-ORS-Online Reservation System **Product Use Case Summary** | ID | MKT | | ------- | ------------------------- | | Name | Online Reservation System | | Sector | Government Marketplace | | Version | 1.0 | | Status | Draft | This use case explain the three broad steps in booking a doctor's appointment by a citizen. The three steps included are (1) Citizen's registration (2) Hospital Staff Registration (3) Booking a doctors appointment by a citizen. The ORS service involves a health application consisting of registered hospitals with various departmental services in it pooled across multiple cities in a state or a country. A citizen can choose to select a service in a particular hospital and book an appointment. Then, the citizen can visit the hospital as per the appointment time and seek medicine receipts/diagnostic services, if any, into his/her registered account. A citizen can avail deemed social benefits as per eligible criterian defined by the government. For example, a citizen can choose to scroll through nearest town/city, select a general or specialized government hospital (for ex. Cancer hospital) and then select a department (oncology) and see who all doctors/slots are available; and then book an appointment as per their convenience. Once the appointment is booked, the citizen receives confirmation details and visits the hospital to consult the doctor. If the doctor suggests any prescription, the same is uploaded into citizen's account by hospital staff-which can be shown across medical shops to get medicine. Nominal fee payments, receiving of medical aid in terms of cash etc. are not considered in this case study. #### **SDG Targets​** 12.7: Promote public procurement practices that are sustainable, in accordance with national policies and priorities 12.7.1: Number of countries implementing Sustainable Public Procurement policies and action plans **3.7 By 2030, ensure universal access to sexual and reproductive health-care services, including for family planning, information and education, and the integration of reproductive health into national strategies and programmes.** **3.8 Achieve universal health coverage, including financial risk protection, access to quality essential health-care services and access to safe, effective, quality and affordable essential medicines and vaccines for all.** #### **Building Blocks​** 1. Consent 2. Identification and Verification 3. Messaging 4. Registration 5. Scheduling 6. Information Mediator 7. Work flow and Algorithm 8. Registries Future building blocks inclusion * Payments * UI/UX * Analytics and Business Intelligence * Artificial Intelligence (AI) * Geographic Information Services (GIS) ​Steps1 - Outreach Communications Staff from the Ministry of Health or another leading agency / organization organizes an information awareness campaign about booking health appointments and its benefits through ORS through various channels of communication via mobile messaging and/or aired on national radio/television, internet, social media. Outreach communication is intensive during the kick-off phase of the new programme, but also requires ongoing touchpoints and additional information sharing, e.g. on grievance redressal, rights and responsibilities, behavioural change communication, etc. Workflows * **Client communication** to facilitate the spreading of programme awareness for target audience and encouraging enrolment via mobile,web, kiosk, media channel(s) * Client education for educating potential target beneficiaries around the approach and objective(s), benefit(s), constraint(s), partner(s), etc. of the programme * **Content management** for the backend Health department and stakeholder staff to populate relevant educational and promotional content that local officers can use during on-the-ground outreach campaigns * **Identification and Registration** (with aid of geographic information services tool for potential use) in mapping and locating households and individuals for outreach target **Example Implementation** To do **Building Blocks​** Messaging ​Scheduling Information Mediation \*\*2 - Registration, \*\***Identification and Verification** Registration is the process of collecting information of stakeholders such as citizens and hospital staff, in this use case. Depending on specific grography context, registration works in very different ways – either through self registration, on-demand at local hospitals (either approach potentially building on interoperability existing data sources) or single admin registration of hospital staff. While the practicalities of data collection differ across the types, with very different implications for data quality, currency and completeness, the underlying digital processes are broadly the same. A self registration involves providing data inputs by the citizen while the on-demand registration will facilitate the same services for the individuals who might not be able to help themselves. Further, an adminstrator of hospital may also choose to enrol/register all the doctors details (for example), on behalf of them. The data registered can be saved into type of registries (for example, citizens, hospital staff registries, hospitals registry, cities registry, departments registry) and can be accessed to collect, organize, store, process, transform, create, and distribute information necessary to support intake and registration of potential beneficiaries (gateway function). **Workflows** **Data Collection and Reporting** for capturing interview responses or observations during registration process **Identification and Registration** for enrolled identified beneficiaries in the system and enabling possible permissions for interaction with the Health Application, and (with aid of geographic information services tool) to potentially locate and track households during the interview process **Client Case Management** for creating beneficiary user records **Example Implementation** [Citizen Registration](#g2p-uc2-ors-s1-citizen-registration) [Hospital Staff Registration](#g2p-uc2-ors-s2-hospitalstaff-registration) **Building Blocks** ​Consent​ Registration​​ Registries Identity and Verification Information Mediation Messaging **3 - Booking a doctor's apointment** This is a key process of the use case where a citizen access the health application (ORS) and books an appointment. The process involves a citizen visiting a catalogue of cities, government hospitals in each city; and selects a department (for example: neurology) in a selected hospitals and books a doctor's appointment at a scheduled slot. Once the citizen visits the hospital, their appointment is reconfirmed and entitlements, if any, are verified by the hospital staff. The doctor, upon completion of diagnosis, can direct the staff to upload the prescriptions, diagnosis results in the same account of the citizen so that the citizen can show case the same to receive medicine and to store the health hisory. **Workflows** **Cross verification** of citizen appointment details when the later visits the hospital **Catalogue of services** The citizen should be able to select a service under a department of a hospital in a city **Client Case Management** for determining and assigning benefit packages and benefit levels to specific user groups **Data Analysis and Business Intelligence** / Decision Support potentially for identifying different benefit levels / types in correlation to target groups’ socioeconomic / demographic information, based on existing eligibility criteria **Document Management** that uploads/stores the prescriptions, diagnosis results by the hospital staff **Scheduling** The time slot shall get updated automatically whenever a slot is booked or when the slot is cancelled. It shall also communicate the appointment details to citizen and to the hospital staff. **Example Implementation** [Booking an appointment](#g2p-uc2-ors-s3-bookingdoctorsappointment) **Building Blocks** ​Identity and Verification Consent Information Mediation Digital Registries Registration Scheduling UI/UX Messaging Client Case Management Analytics and Business Intelligence **Outputs** 1. The citizen is able to successfully register a doctor's appointment in a government hospital **Failure Points** 1. Internet connectivity 2. Lack of awareness 3. Technical failure of the application ## G2P-UC2-ORS-S1-Citizen Registration | Use Case Step | Self-Registration of citizen (how about Mee-Seva channels?) | | | | | | | | | | | | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -- | ----- | ---- | ----- | - | -- | ------ | ------------ | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) |
  • The citizen has already registered in a national identification system (IDBB) and has a unique electronic identity/social protection number to register an account and to avail related benefits/schemes offered by the government.
  • Good internet connectivity, access channels (web/mobile/kiosk) shall be available.
  • Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (consent) and respective REST API services in Information Mediator have been opened to Registration BB.
  • The citizen owns the identity proof (card, QR code, ID number, etc) available together with the required credentials for the healthcare platform that can be verified and authenticated with the national ID system.
| | | | | | | | | | | | Data inputs |
  • Name, Age, Gender of the citizen
  • National ID number of the citizen
  • Electronic Health Record(HER) number
  • Registered mobile number
  • Captcha Chat/non-robot verification
  • OTP
  • Permanent address details (Door number, Lane, PIN, City, State, Nation)
| | | | | | | | | | | | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) |

Human: CitizenSystem:

  • Healthcare platform application
  • Digital Registries BB/(EHR)
  • Registration BB
  • Identity BB
  • Consent BB
  • Messaging BB
  • Information Mediator BB
  • National Population Registry (Digital Registries BB or Identity BB)
| | | | | | | | | | | | Normal Course (what happens if the event is triggered and the preconditions have been met) |

The registration form screen for the Healthcare application provides a list of initial details required to proceed with the registration (eligibility verification, required documents such as national ID/EHR proof).Step 1: The citizen enters the required initial details, including, but not limited to the following:

  1. 1.Citizen’s National ID number
  2. 2.Name of the Citizen
  3. 3.Date of Birth
  4. 4.Gender at Birth
  5. 5.Address details
  6. 6.Mobile number
  7. 7.
  8. 8.The application shall seek the consent of the citizen to retrieve additional data from multiple registries.
  9. 9.

Feature: Get Consent AgreementScenario: Healthcare Application retrieves Consent Agreement for citizenGiven an Agreement citizen registration that exists in Consent BBAnd Healthcare Application has Citizen’s \ and authentication token for the registration sessionWhen Healthcare application fetches a Consent Agreement for Citizen registrationThen Healthcare application gets a valid Draft Consent Agreement associated with Citizen's IDAPI EndpointsStep 2: The health Application introduces to the citizen the Consent Agreement for fetching the relevant details from the Population registry (Should it check with EHR also?) for verification and appropriate use with the health application and captures signature to the Consent Agreement from the citizen.Feature: Sign Consent RecordBackground:Given Health Application has the Draft Consent Agreement associated with Citizen's ID and authentication token for the registration sessionAnd Citizen has read the Draft Consent AgreementAnd Citizen approves to sign the Draft Consent Agreement associated with Citizen's ID (What language and what if the citizen does not agree?)Scenario: Sign Consent Record on PaperGiven Health application has captured the consent in a digital form (for example: scan of a paper form)When Health application sends digital Consent Record payload to Consent BBThen Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Citizen has been successfully signedScenario: Sign Consent Record DigitallyGiven Citizen has capability to sign Consent Record digitallyWhen Health Application sends the Draft Consent Agreement to Consent BBThen Consent BB creates a paired ConsentRecord and Signature objectAnd Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Citizen has been successfully signedAPI EndpointsStep 3: The Health application form submits the national ID number to the Population registry hosted in the IDBB/Digital Registries BB seeking relevant details of the Citizen, by invoking the API “Data read value” on the Govstack Digital Registries BB.This scenario uses a set of features:

  • Verify Consent Record by Consent BB
  • Import data from a registry by Registry BB

Feature: Verify Consent RecordHealth Application verifies if Citizen has signed Consent Record to fetch the needed personal data from Population registry for Health Application user registrationScenario: Retrieve valid Consent RecordGiven Citizen has Signed Consent Record stored in Consent BBWhen Health Application makes the request to population registry API to fetch Citizen's personal dataThen Health Application makes prior request to Consent BB API to retrieve Citizen's Signed Consent RecordAnd Consent BB sends the signed Consent Record to Health ApplicationFeature: Imports client personal data from a registryImport Citizen's personal information from Population Registry to the e-service formGiven Citizen has entered \ in the Registration e-service registration form, national ID number fieldAnd Health Application has received Signed Consent Record from Consent BBWhen the Health Application user pushes a button "Import Citizen's information"Then the Health Application makes a request to Population Registry APIAnd Population Registry returns requested data to Health ApplicationAnd Health Application fills the form on the screen with Citizen’s data \,\, \, \Examples: | ID | first | last | birth | | 53 | Sowmya | Krishnamurti | 2023-02-14 | In response, the Govstack IDBB/ Digital Registries BB is expected to return the following: Data returned from Registry\

| | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) |

If the Citizen does not possess a national ID, the registration application needs to provide an alternate mechanism for <>GetIdentityProfile – elaborate

  1. 1.If the consent record is previously created and available, the registration application should fetch the consent agreement by invoking the API: “serviceListIndividualRecord” on the Govstack Consent BB

“GET /dataconsumer/consent/”

| | | | | | | | | | | | Data output | The successful completion of the citizen registration process will result in confirmation and issuance of a program-specific ID that can be used by the citizen for future interactions with the program.Expected data from Registration BB | | | | | | | | | | | | Post-Conditions (the success criteria) | The citizen has registered in the Health Application registry. | | | | | | | | | | | | Exceptions(error situations) |
  • A citizen can be only registered once in Health Application. The system must prevent multiple registrations.
  • Provide details on exception code and message
  • Mitigation steps: Describe steps to be taken by the actors
  • If the citizen has entered incorrect information then the Health Application inform the citizen to check/validate the same.
  • Provide details on exception code and message
  • Mitigation steps: Describe steps to be taken by the actors
  • If Identity BB or Consent BB is not available (service outage), then …..
  • Mitigation steps: Describe steps to be taken by the actors
  • If no internet, then the system is not available and information must be collected on paper forms or on offline data capturing devices.
  • Mitigation steps: Describe steps to be taken by the actors
| | | | | | | | | | | | Related BBs(working groups related to this example implementation) |
  • Identity BB
  • Consent BB
  • Registration BB
  • Digital Registries BB
| | | | | | | | | | | ## G2P-UC2-ORS-S2-HospitalStaff Registration USE CASE: Booking a doctor’s appointment on a Government healthcare platform | Use Case Step | Hospital Staff Registration by a system administrator | | --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) | · The staff is an identified and registered person with a hospital; and is registered in a national identification system (IDBB) with a unique electronic identity number.· The role of the staff is clearly pre-defined and is mapped to a department by the hospital. For example, a doctor, a diagnostic officer, radiologist, document uploader, bill clearance officer etc.· Good internet connectivity, access channels (web/mobile/kiosk) shall be available.· Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (consent) and respective REST API services in Information Mediator have been opened to Registration BB. | | Data inputs | · Name, Age, Gender of the Staff· National ID number of the Staff· Registered mobile number· Captcha Chat/non-robot verification· OTP· Permanent address details (Door number, Lane, PIN, City, State, Nation) | | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: Staff membersSystem:· Healthcare platform application· Digital Registries BB (Hospital staff)· Registration BB· Identity BB· Consent BB· Messaging BB· Information Mediator BB· National Population Registry (Digital Registries BB or Identity BB) | | Normal Course (what happens if the event is triggered and the preconditions have been met) | The registration form screen for the Healthcare application provides a list of initial details required to proceed with the registration (eligibility verification, required documents such as national ID/Staff ID).Step 1: The staff enters the required initial details, including, but not limited to the following:1. Staff’s National ID number / Staff’s ID in the hospital2. Name of the Staff3. Date of Birth4. Gender at Birth5. Address details6. Mobile number​The application shall seek the consent of the staff to retrieve additional data from multiple registries.​Feature: Get Consent AgreementScenario: Healthcare Application retrieves Consent Agreement for StaffGiven an Agreement Staff registration that exists in Consent BBAnd Healthcare Application has Staff’s \ and authentication token for the registration sessionWhen Healthcare application fetches a Consent Agreement for Staff registrationThen Healthcare application gets a valid Draft Consent Agreement associated with Staff's IDAPI EndpointsStep 2: The health Application introduces to the Staff the Consent Agreement for fetching the relevant details from the Population/Staff registry for verification and appropriate use with the health application and captures signature to the Consent Agreement from the Staff.Feature: Sign Consent RecordBackground:Given Health Application has the Draft Consent Agreement associated with Staff's ID and authentication token for the registration sessionAnd Staff has read the Draft Consent AgreementAnd Staff approves to sign the Draft Consent Agreement associated with Staff’s IDScenario: Sign Consent Record on PaperGiven Health application has captured the consent in a digital form (for example: scan of a paper form)When Health application sends digital Consent Record payload to Consent BBThen Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Staff has been successfully signedScenario: Sign Consent Record DigitallyGiven Staff has capability to sign Consent Record digitallyWhen Health Application sends the Draft Consent Agreement to Consent BBThen Consent BB creates a paired ConsentRecord and Signature objectAnd Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Staff has been successfully signedAPI EndpointsStep 3: The Health application form submits the national ID number to the Population registry hosted in the IDBB/Digital Registries BB seeking relevant details of the Staff, by invoking the API “Data read value” on the Govstack Digital Registries BB.This scenario uses a set of features:· Verify Consent Record by Consent BB· Import data from a registry by Registry BB·Feature: Verify Consent RecordHealth Application verifies if Staff has signed Consent Record to fetch the needed personal data from Population registry for Health Application user registrationScenario: Retrieve valid Consent RecordGiven Staff has Signed Consent Record stored in Consent BBWhen Health Application makes the request to population registry API to fetch Staff's personal dataThen Health Application makes prior request to Consent BB API to retrieve Staff's Signed Consent RecordAnd Consent BB sends the signed Consent Record to Health ApplicationFeature: Imports client personal data from a registryImport Staff's personal information from Population Registry to the e-service formGiven Staff has entered \ in the Registration e-service registration form, national ID number fieldAnd Health Application has received Signed Consent Record from Consent BBWhen the Health Application user pushes a button "Import Staff's information"Then the Health Application makes a request to Staff Registry APIAnd StaffRegistry returns requested data to Health ApplicationAnd Health Application fills the form on the screen with Staff’s data \,\, \, \Examples:\|ID\|first\|last\|birth\|\|32\|Aparna\|Vijay\|2023-03-17\|In response, the Govstack IDBB/ Digital Registries BB is expected to return the following:Data returned from Registry | | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | If the Staff does not possess a national ID, the registration application needs to provide an alternate mechanism for \GetIdentityProfile – elaborate1. If the consent record is previously created and available, the registration application should fetch the consent agreement by invoking the API: “serviceListIndividualRecord” on the Govstack Consent BB“GET /dataconsumer/consent/” | | Data output | The successful completion of the Staff registration process will result in confirmation and issuance of a program-specific ID that can be used by the Staff for future interactions with the program.Expected data from Registration BB | | Post-Conditions (the success criteria) | The Staff has registered in the Health Application registry. | | Exceptions(error situations) | · A Staff can be only registered once in Health Application. The system must prevent multiple registrations.o Provide details on exception code and messageo *Mitigation steps:* Describe steps to be taken by the actorso· If the Staff has entered incorrect information then the Health Application inform the Staff to check/validate the same.o Provide details on exception code and messageo *Mitigation steps:* Describe steps to be taken by the actorso· If Identity BB or Consent BB is not available (service outage), then …..o *Mitigation steps:* Describe steps to be taken by the actorso· If no internet, then the system is not available and information must be collected on paper forms or on offline data capturing devices.o *Mitigation steps:* Describe steps to be taken by the actors | | Related BBs(working groups related to this example implementation) | · Identity BB· Consent BB· Registration BB· Digital Registries BB· IM BB | ## G2P-UC2-ORS-S3-BookingDoctorsAppointment | Use Case Step | Booking a doctor’s appointment in the Health Application | | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) |
  • The citizen has already registered/created an account in the health application portal.
  • Good internet connectivity, access channels (web/mobile/kiosk) are available.
  • The citizen owns the identity proof (card, QR code, ID number, etc), mobile phone available together with the required credentials for the healthcare platform that can be verified and authenticated with the Health Application registry.
| | Data inputs |
  • Username, Password
  • National ID number of the citizen
  • Electronic Health Record(EHR) number
  • Registered mobile number
  • Captcha Chat/non-robot verification
  • OTP
| | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) |

Human: CitizenSystem:

  • Healthcare platform application
  • Digital Registries BB/(EHR)
  • Registration BB
  • Identity BB
  • Consent BB
  • Messaging BB
  • Information Mediator BB
  • National Population Registry (Digital Registries BB or Identity BB)
  • Scheduler BB
  • UI/UX BB
| | Normal Course (what happens if the event is triggered and the preconditions have been met) |

Once the user logs-in, the user should be able to search for list of hospitals, different services under each hospital, select the health service, upload documents (if necessary) and get a confirmation of the appointment.Step 1: The citizen enters the required initial details, including, but not limited to the following:

  1. 1.Username, password, Captcha, Mobile number, OTP
  2. 2.The application shall input the entered data, validate, and logs into the Health Application home page.

Feature: Verify and validate the citizen account detailsScenario: Healthcare Application retrieves citizen details from Health Application Registry.Given an Agreement citizen registration that exists in Consent BBAnd Healthcare Application has Citizen’s \ and authentication token for the registration sessionWhen Healthcare application fetches a valid Health Application Account IDThen Healthcare application successfully logs in the citizen​Step 2: The citizen searches for health care providers in a particular cityThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government.The validated citizen ID/session ID fetches the details from \, and \ with multiple filters.Feature: Catalogue Search for identifying cities and healthcare providersBackground:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Search for CitiesGiven Health application account ID/Session ID has been presented with catalogue of citiesWhen Health application account ID/Session ID selects a city from the Cities RegistryThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Cities Registry details are fetched successfullyScenario: Search for Hospital/ClinicGiven Health application account ID/Session ID has been presented with catalogue of citiesWhen Health application account ID/Session ID selects a city from the Cities RegistryAnd the \ fetches all the hospitals and clinics under the selected citiesThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital and Clinics details under Cities Registry are fetched successfully​Step 3: The citizen views a catalogue of hospitals and clinics in the city and selects the department for which the appointment is requiredThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government.The validated citizen ID/session ID fetches the details from \, \, with multiple filters; which are under \ and \.Feature: Catalogue Search for identifying departments and services (for example: Department of Neurology associated with Brain, Spine, Peripheral nerves, muscles related services etc.), with multiple filters.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in session ; and has been presented with details of \ and \Scenario: Search for Departments in a hospitalGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitalsWhen Health application account ID/Session ID selects a hospital from the Hospitals RegistryThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Departments Registry details are fetched successfullyScenario: Search for a serviceGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departmentsWhen Health application account ID/Session ID selects a service from the Services RegistryAnd the \ fetches all the services under the Departments in a hospital in a city.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services details in a City are fetched successfully​Step 4: The citizen views available appointment slots in the calendar published by the particular hospitalThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government. The citizen selects a city, health provider, department and a service.The validated citizen ID/session ID fetches the details from \, \, \, \, with multiple filters.Feature: Catalogue Search for appointment slot and its selectionBackground:Given Health Application/Session ID has the Health Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Search for appointment slots in the catalogueGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departmentsWhen Health application account ID/Session ID selects a service from the Services RegistryAnd the \ fetches all the services under the Departments in a hospital in a cityAnd a Catalogue of Appointment slots \ are fetched successfully.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Scheduler BB time slots details in a City are fetched successfullyScenario: Citizen selects and confirms a slot.Given Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, servicesWhen Health application account ID/Session ID selects a service from the Scheduler BBs catalogue/Time capabilityAnd the < Scheduler BB> fetches all the available slots for a service under the Departments in a hospital in a cityAnd a slot is selected, the details are communicated to Messaging BB successfully.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details are communicated to Scheduler BB, “Messaging BB” through IM BB.​Step 5: The citizen receives appointment details and the quoteThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals, departments, services, appointment slots.The validated citizen ID/session ID fetches the details from \, \, \, \, with multiple filters.Feature: The “Appointment” details are fetched from Scheduler BB and a quote (to submit additional information/time confirmation/pre-validation by citizen) is provided for citizen’s confirmation.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Receive appointment details on Application UI/UXGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, services, appointment/time capabilityWhen Health application account ID/Session ID selects a service time slot from the Scheduler BBsAnd the < Scheduler BBs > is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB.Then IM BB fetches the payload from Messaging BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details from Scheduler BB are communicated to “Messaging BB” and then to UI/UX BB.​Step 6: The citizen accepts the quote and shares the medical information history required for the appointmentThe citizen has been provided with appointment details, a quote to share additional but optional information.Feature: The “Appointment” details are fetched and a quote (to submit additional information/time confirmation/pre-validation by citizen) is provided for citizen’s confirmation.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Citizen shares additional details and then confirms the appointment.Given Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, services, appointment/time capabilityWhen Health application account ID/Session ID selects a service from the Scheduler BBs catalogue of appointment slots.And the \ is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB for validation and to share/affix additional details. Citizen updates the details (optional) and confirms the appointment details.Then IM BB fetches the payload from Messaging BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details are communicated to “Messaging BB” and then to UI/UX BB. The Registration BB is updated with new data (quotes) through Messaging BB and IM BB. Scheduler BB is updated. Appointment ID is updated in Health Application Account ID. The session is closed.​Step 7: The hospital staff validates the citizen’s appointment and consultation with the doctorThe citizen has been provided with appointment details, a quote to share additional but optional information. The citizen confirms the appointment and receives the appointment details via paper or SMS.Feature: Citizen visits the hospital on the scheduled time and the “Appointment”, received through a paper or SMS, is utilized.Background:The hospital staff members cross checks the Appointment ID, Account ID, Citizen ID using UI/UX BB, Scheduler BB, Registration BB, Registries BB.Scenario: Citizen visits the hospital and hospital staff checks the appointment detailsCitizen shares the appointment details (Paper/SMS) with the hospital staff. The Staff logs-in to the portal and verifies and validates the appointment, citizen details.When Staff ID/Session ID selects an appointment ID from the UI/UX, Scheduler BBsAnd the < Appointment slot> is selected; the appointment and citizen details are communicated to IM BB and Scheduler BB and then to UI/UX BB for validation. Staff confirms the appointment details.Then IM BB fetches the payload from Scheduler BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Staff account ID/Session ID confirms to Staff Account that Citizen Health Application Account details, Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details and citizen details are validated successfully.​Step 8: The Hospital updates the prescriptions, diagnosis to the citizen in the Health ApplicationThe citizen has visited the doctor and was advised some measures, medicines, diagnostics. The prescription and the in-house diagnostic services results are updated by the hospital staff in the patient registry associated with hospital account application ID of the citizen.Feature: The hospital staff uploads the prescriptions and diagnostics results of a citizen.Background:Given Staff ID/Session ID has the Health Application Account ID associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Citizen shares the prescription with the staff after undergoing in-house diagnostic services with results.Given Staff ID/Session ID has been presented with the Patients RegistriesWhen Staff ID/Session ID selects a Hospital Account ID/Citizen IDAnd the < Patients Registry> is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB. Staff updates/uploads the medicine advise/test result details (optional) associated with patients.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Staff ID/Session ID confirms to Health Application that Health Account ID associated with Citizen ID are fetched successfully and the test results (optional) and prescriptions are communicated to “IM BB” and then to UI/UX BB. The Registration BB is updated with new data (prescription/test results) through Messaging BB and IM BB. Patients Registry is updated.In response, the Govstack IDBB/ Digital Registries BB is expected to return the following: Data returned from Patients Registry

| | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) |

If the Citizen does not possess a national ID, the registration application needs to provide an alternate mechanism for <>GetIdentityProfile – elaborate

  1. 1.If the consent record is previously created and available, the registration application should fetch the consent agreement by invoking the API: “serviceListIndividualRecord” on the Govstack Consent BB

“GET /dataconsumer/consent/”

| | Data output | The successful completion of the citizen appointment process will result in confirmation and issuance of a Appointment ID that can be used by the citizen for future interactions with the hospital.Expected data from Registration BB | | Post-Conditions (the success criteria) | The citizen has booked an appointment successfully in the Health Application. | | Exceptions(error situations) |
  • A citizen can book multiple appointments (but not at same time) in Health Application. The system must provision this.
  • Provide details on exception code and message
  • Mitigation steps: Describe steps to be taken by the actors
  • If the citizen has entered incorrect information then the Health Application inform the citizen to check/validate the same.
  • Provide details on exception code and message
  • Mitigation steps: Describe steps to be taken by the actors
  • If Identity BB or Consent BB is not available (service outage), then …..
  • Mitigation steps: Describe steps to be taken by the actors
  • If no internet, then the system is not available and information must be collected on paper forms or on offline data capturing devices.
  • Mitigation steps: Describe steps to be taken by the actors

If the citizen does not find a required department/services then either “general physician” or “This service is not available at this hospital” message shall be displayed.If the appointment slots in a day are over the application and or Scheduler BB should make a suggestion such “There are no slots available for today” / “Please book your appointment on the next available day”

| | Related BBs(working groups related to this example implementation) |
  • Identity BB
  • Consent BB
  • Registration BB
  • Digital Registries BB
  • Scheduler BB
  • Messaging BB
  • UI/UX BB
| # EM-G2P-UC3-Government Auctions Marketplace (GAM) ## eM-G2P-UC3-Government Auctions Marketplace (GAM) #### MKT-G2P-UC3-GAM-Government Auctions Marketplace **Product Use Case Summary** | ID | MKT | | ------- | ------------------------------- | | Name | Government Auctions Marketplace | | Sector | Government Marketplace | | Version | 1.0 | | Status | Draft | This use case streamlines the process of selling surplus government property, making it easier for both the government agency to dispose of property it no longer needs and generate revenue, and for buyers to find and purchase a property. This use case involves the process of a government agency identifying property it no longer needs and transferring it to a centralized platform for disposal. The property is listed on the platform and promoted to potential buyers. Interested registered buyers bid on the property and the highest bidder is awarded the property. Finally, the buyer then pays for and takes possession of the property. The use case steps are 1. **Identifying property** Government agency identifies the surplus property it no longer needs 2. **Transferring property** Government agency transfers the property to Surplus Property Management Office (SPMO) 3. **Listing property** Surplus Property Management Office lists the property on the Surplus Property Auctions marketplace 4. **Bidding on property** Registered bidders bid on the property 5. **Awarding property** The highest bidder is awarded the property 6. **Transfer of property** The buyer takes possession of the property #### SDG Targets **Target 8.2** Achieve higher levels of economic productivity through diversification, technological upgrading, and innovation, including through a focus on high-value-added and labour-intensive sectors. **Target 12.5** By 2030, substantially reduce waste generation through prevention, reduction, recycling, and reuse. #### Building Blocks · Identification and authentication · Content Management · Information Mediator · eMarketplace · Digital registries · Messaging · Payment **Future Building Blocks** · Artificial Intelligence · Mobility management #### Steps ***Step 1 - Identifying property*** This step involves the government agency identifying the property that is no longer needed and can be sold to interested buyers. The Property could be any type of item or asset that the government agency has deemed as surplus and is looking to dispose of. **Workflows**: The workflows involved in this step: * The Government Agency identifies surplus property that it no longer needs. * The Property Officer conducts a physical inspection of the property and prepares a condition report. * The Property Officer gets approvals from stakeholders within the government agency. * The agency adds the property to its inventory of surplus property. **Building Blocks for Workflows:** * Identification and authentication * Digital Registeries * Content Management **Example Implementation** Go to G2P-UC3-GAM-S.1 ***Step 2 -***** Transferring property to Surplus Property Management Office** The government agency that owns surplus property initiates the transfer of the property to the Surplus Property Management Office for disposal. This involves preparing the necessary documentation for the property and obtaining the required approvals. **Workflows**: The workflows involved in this step: * Government agency makes the transfer by submitting the description of the property, its condition, and any other relevant details. * The transfer will be reviewed and approved by the relevant stakeholders. * Surplus Property Management Office takes possession of the property and responsibility for its sale. **Building Blocks for Workflows:** * Case Management. * Content Management. * Digital registries. * Identification and authentication. ***Step 3 -***** Listing property** This step involves Surplus Property Management Office listing the Property on the Surplus Property Management Auctions marketplace, which is a platform for selling surplus and unneeded Gov. assets to the public. The website allows buyers to search for and bid on a wide range of Gov. assets, including Property, equipment, real estate, and more. **Workflows**: The workflows involved in this step: * Surplus Property Management Office determines the appropriate listing category for the property based on its type, condition, and other relevant factors. * Surplus Property Management Office sets a starting bid price and bidding period for the property. * Surplus Property Management Office reviews bids as they come in and updates the listing to reflect the current high bid. **Building Blocks for Workflows:** * eMarketplace. * Digital registries. * Content Management. **Example Implementation** Go to G2P-UC3-GAM-S.3 ***Step 4 -***** Bidding on property** This step involves the registered bidders submitting their bids on the property listed for sale by the Surplus Property Management Office on Auctions platform. **Workflows**: The workflows involved in this step: * Bidders view the listing of the property on the Surplus Property Auctions marketplace. * Bidders submit their bid amount and bidder information through the Surplus Property Auctions marketplace. * Surplus Property Management Office receives and records the bid amounts and bidder information. * The bidding period ends. * Surplus Property Management Office reviews the bids and selects the highest bidder. **Building Blocks for Workflows:** * eMarketplace * Authentication & Authorization **Example Implementation** Go to G2P-UC3-GAM-S.4 ***Step 5 -***** Awarding property** The Surplus Property Management Office reviews the highest bid and selects the winning bidder to be awarded the property. **Workflows**: The workflows involved in this step: * Surplus Property Management Office updates its inventory to reflect the transfer of the property. * Surplus Property Management Office verifies the payment and transfer details and authorizes the transfer of the property to the highest bidder. * The highest bidder confirms acceptance of the bid and provides payment and transfer details to the Surplus Property Management Office. * Surplus Property Management Office sends a notification to the highest bidder that their bid has been accepted and requests payment and transfer of the property. * Surplus Property Management Office reviews the bids and selects the highest bidder. **Building Blocks for Workflows:** * Notifications * Payment * eMarketplace * Messaging **Example Implementation** Go to G2P-UC3-GAM-S.5 ***Step 6 -***** Transfer of property** This step involves the highest bidder paying for the property they have won in the auction and taking possession of it from the seller, in this case, the Surplus Property Management Office. It includes the payment validation and transfer of ownership to the buyer. **Workflows**: The workflows involved in this step: * The Surplus Property Management Office confirms receipt of payment and prepares the necessary transfer of ownership and registration documents * The buyer and Surplus Property Management Office coordinate the transfer of the property, including pickup or delivery arrangements * The Surplus Property Management Office transfers ownership and registration documents to the buyer, completing the transaction. **Building Blocks for Workflows:** * Payment * eMarketplace **Example Implementation** ## G2P-UC3-GAM-S.1 | ID | G2P-UC3-GAM-S.1 | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Use Case Step | Identifying property | | Preconditions |
  • The Government agency must have surplus property that it no longer needs.
  • The government agency has identified surplus property that it no longer needs.
| | Data Inputs |
  • Description of the property
  • Property condition report
  • Supporting documentation, such as registration, title, and other certificates
  • Identification of the Government agency that owns the property.
| | Actors |
  • Government Agency: Initiates the process of identifying surplus property that is no longer needed.
  • Property Officer: Conducts a physical inspection of the property and prepares a condition report.
  • Surplus Property Auctions marketplace.
| | Normal Course |
  1. 1.The Government Agency identifies surplus property that it no longer needs.
  2. 2.The Property Officer conducts a physical inspection of the property and prepares a condition report.
  3. 3.The Property Officer gets approvals from stakeholders within government agency.
  4. 4.The agency adds the property to its inventory of surplus property.
| | Alternative Course | If the property is not suitable for sale on the Surplus Property Auctions marketplace, it may be disposed of through other means, such as recycling, donation, or destruction. | | Data Output | Information about the identified surplus property is added to the government agency's inventory. | | Post-Conditions | The surplus property has been successfully identified, inspected, and ready for transfer to the Surplus Property Management Office for listing on the Surplus Property Auctions marketplace. | | Exceptions | NA | | Related BBs |
  • Identification and authentication
  • Digital registries
  • Content Management
| | Sequence Diagram | Surplus Property Identification Process​`Government Agency->Property Officer: Identify surplus property Property Officer->Property Officer: Conduct physical inspection and prepare condition report Property Officer->Government Agency: Get approvals from stakeholders Government Agency->Government Agency: Add property to inventory of surplus property` | ![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FPs03umrTGr2kKZAChFog%2FScreen%20Shot%202023-03-29%20at%207.24.49%20AM.png?alt=media\&token=63ce324e-fbb9-466e-abc6-cf33ffe6a788)
## G2P-UC3-GAM-S.2 | ID | G2P-UC3-GAM-S.2 | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Transferring property | | Preconditions |
  • The Government Agency has identified surplus property that it wishes to transfer to the Surplus Property Management Office.
  • Approval from relevant stakeholders within the Government Agency for the transfer.
| | Data inputs |

Details of the surplus property to be transferred, including

  • Description
  • Condition report
  • Inventory number
| | Actors |
  • Government Agency: Initiates the process of transferring surplus property to the Surplus Property Management Office.
  • Surplus Property Management Office: Receives surplus property from the Government Agency.
| | Normal Course |
  1. 1.The Government Agency initiates the transfer process and provides details of the surplus property to the Surplus Property Management Office.
  2. 2.The Surplus Property Management Office verifies that it is willing and able to accept the property.
  3. 3.The Government Agency provides approval for the transfer from relevant stakeholders within the organization.
  4. 4.The Surplus Property Management Office takes possession of the property and updates its inventory to reflect the new acquisition.
| | Alternative Course |
  • If the Property does not meet the transfer requirements, the Surplus Property Management Office rejects the transfer and sends the Property back to the government agency.
  • If the transfer document is incomplete or contains errors, the government agency must correct them and resubmit the transfer document.
  • If the Surplus Property Management Office is unable to accept the property, the Government Agency may need to identify an alternative recipient.
| | Data output |
  • Legal ownership of the Property is transferred from the government agency to the Surplus Property Management Office.
  • The Surplus Property Management Office updates its inventory to reflect the new acquisition.
  • The Property's status is updated in the centralized database.
| | Post-Conditions |
  • The government agency has successfully transferred the Property to the Surplus Property Management Office.
  • The Surplus Property Management Office assumes responsibility for the Property's sale.
  • Legal ownership of the Property is transferred from the government agency to the Surplus Property Management Office.
| | Exceptions |
  • The Surplus Property Management Office is unable to accept the property.
  • The property is found to be in unacceptable condition.
| | Related BBs |
  • Identification and authentication.
  • Digital registries.
  • Content Management.
  • Case Management.
| | Sequence Diagram | title Transferring Property​`Government Agency->Surplus Property Management Office: Initiate transfer and provide property details Surplus Property Management Office->Government Agency: Verify willingness and ability to accept property Government Agency->Government Agency: Obtain approval from relevant stakeholders Government Agency->Surplus Property Management Office: Provide approval for transfer Surplus Property Management Office->Government Agency: Take possession of property Surplus Property Management Office->Surplus Property Management Office: Update inventory to reflect new acquisition` | ​![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FaIO1C19QbJ0EZamaloft%2FScreen%20Shot%202023-03-29%20at%207.46.17%20AM.png?alt=media\&token=879f3d87-8dfd-4b52-9384-1ba108659eab)
## G2P-UC3-GAM-S.3 | ID | G2P-UC3-GAM-S.3 | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Listing property | | Preconditions |
  • The property must have been successfully transferred to the Surplus Property Management Office.
  • The property must have been inspected and evaluated for condition by the Property Officer.
| | Data inputs |
  • Property information and details (e.g. description, condition, images).
  • Property images or videos for showcasing the property
  • Property Officer's Inspection report
| | Actors |
  • Surplus Property Management Office
  • Property Officer
  • Surplus Property Auctions marketplace.
| | Normal Course |
  1. 1.Surplus Property Management Office receives the property from the government agency.
  2. 2.The Surplus Property Management Office adds the property to its inventory of available surplus property.
  3. 3.The Surplus Property Management Office creates a listing of the property on the Surplus Property Auctions marketplace, including the property details and any images or videos provided.
  4. 4.Surplus Property Management Office publishes the listing to the Surplus Property Auctions marketplace.
| | Alternative Course | If the property does not meet the criteria for listing on the Surplus Property Auctions marketplace, the property may be disposed of through other means (e.g. donated, recycled, or scrapped). | | Data output | Property listing on the Surplus Property Auctions marketplace. | | Post-Conditions | Property is listed for auction on the Surplus Property Auctions marketplace. | | Exceptions |
  • The property does not meet the criteria for listing on the Surplus Property Auctions marketplace.
  • Technical errors or system issues prevent the creation of the property listing
| | Related BBs |
  • eMarketplace.
  • Digital registries.
  • Content Management.
| | Sequence Diagram | title Surplus Property Listing​`Government Agency->Surplus Property Management Office: Transfer property Surplus Property Management Office->Surplus Property Management Office: Add property to inventory Surplus Property Management Office->Surplus Property Management Office: Create property listing Surplus Property Management Office->Surplus Property Auctions marketplace: Publish listing` | ​![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2Fw8pgTUnVmSFWqGnf27jo%2FScreen%20Shot%202023-03-29%20at%207.59.43%20AM.png?alt=media\&token=0f6b51d5-f914-4e90-acd1-82d43bdb7e90)
## G2P-UC3-GAM-S.4 | ID | G2P-UC3-GAM-S.4 | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Bidding on property | | Preconditions |
  • The property has been listed on the Surplus Property Auctions marketplace.
  • Bidders are registered and authenticated on the Surplus Property Auctions marketplace.
| | Data inputs |
  • Bid amount
  • Bidder information
| | Actors |
  • Bidders
  • Surplus Property Management Office
  • Surplus Property Auctions marketplace
| | Normal Course |
  1. 1.Bidders view the listing of the property on the Surplus Property Auctions marketplace.
  2. 2.Bidders submit their bid amount and bidder information through the Surplus Property Auctions marketplace.
  3. 3.Surplus Property Management Office receives and records the bid amounts and bidder information.
  4. 4.The bidding period ends.
  5. 5.Surplus Property Management Office reviews the bids and selects the highest bidder.
| | Alternative Course | If there are no bids, the Surplus Property Management Office may choose to re-list the property for auction. | | Data output |
  • Winning bid amount
  • Bidder information
| | Post-Conditions | The highest bidder is identified and notified of their win. | | Exceptions |
  • Invalid bid amount or information is submitted.
  • Technical issues with the Surplus Property Auctions marketplace.
  • Other unforeseen issues that prevent the auction from being completed.
| | Related BBs |
  • Authentication & Authorization
  • eMarketplace
| | Sequence Diagram | title Bidding on Property`Bidders->Surplus Property Auctions: View property listing Surplus Property Auctions->Bidders: Display property listingBidders->Surplus Property Auctions: Submit bid and bidder information Surplus Property Auctions->Surplus Property Management Office: Record bid and bidder information Note right of Surplus Property Management Office: Bidding period ends Surplus Property Management Office->Surplus Property Auctions: Provide bid results Surplus Property Auctions->Bidders: Display bid resultsSurplus Property Management Office->Bid Winner: Notify bid winner` | ![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FlDfENk6ycmema5RThGXX%2FScreen%20Shot%202023-03-29%20at%208.13.44%20AM.png?alt=media\&token=ef681c31-6f71-4c93-b928-97325c5b80c2)
## G2P-UC3-GAM-S.5 | ID | G2P-UC3-GAM-S.5 | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Awarding property | | Preconditions |
  • The property has been listed on the Surplus Property Auctions marketplace.
  • Registered bidders have placed bids on the property.
  • There is at least one bidder for the property.
  • The bidding period has ended.
| | Data inputs |
  • Bid information for all bidders.
  • Property information.
| | Actors |
  • Surplus Property Management Office
  • Surplus Property Auctions marketplace
| | Normal Course |
  1. 1.Surplus Property Management Office reviews the bids and selects the highest bidder.
  2. 2.Surplus Property Management Office sends a notification to the highest bidder that their bid has been accepted and requests payment and transfer of the property.
  3. 3.The highest bidder confirms acceptance of the bid and provides payment and transfer details to the Surplus Property Management Office.
  4. 4.Surplus Property Management Office verifies the payment and transfer details and authorizes the transfer of the property to the highest bidder.
  5. 5.Surplus Property Management Office updates its inventory to reflect the transfer of the property.
| | Alternative Course | If the highest bidder fails to provide payment or transfer details within a specified timeframe, the Surplus Property Management Office may select the next highest bidder. | | Data output |
  • Notification to the highest bidder that their bid has been accepted.
  • Authorization for the transfer of the property.
| | Post-Conditions |
  • The property has been transferred to the highest bidder.
  • Payment has been received by the Surplus Property Management Office.
| | Exceptions |
  • The highest bidder fails to provide payment or transfer details.
  • The highest bidder provides incorrect payment or transfer details.
  • The property is damaged or not as described in the listing.
  • The Surplus Property Management Office is unable to transfer the property to the highest bidder for legal or other reasons.
| | Related BBs |
  • Messaging
  • eMarketplace
  • Payment
  • Notifications
| | Sequence Diagram | title Awarding Property​`Surplus Property Management Office -> Surplus Property Management Office: Review Bids\nSelect Highest Bidder Surplus Property Management Office -> Highest Bidder: Send Notification\nRequest Payment & Transfer Details Highest Bidder -> Surplus Property Management Office: Confirm Bid\nProvide Payment & Transfer Details Surplus Property Management Office -> Surplus Property Management Office: Verify Payment & Transfer Details\nAuthorize Transfer of Property Surplus Property Management Office -> Surplus Property Management Office: Update Inventory` | ![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F5M2VW5J5PSBxlkiu4fYp%2FScreen%20Shot%202023-03-29%20at%208.24.47%20AM.png?alt=media\&token=28b07e63-991f-4146-b69a-7d377937cf4f)
## G2P-UC3-GAM-S.6 | ID | G2P-UC3-GAM-S.6 | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Transfer of property | | Preconditions |
  • The Surplus Property Management Office has selected the highest bidder and sent a notification to them.
  • The highest bidder has confirmed their acceptance of the bid and provided payment and transfer details.
| | Data inputs |
  • Payment details (e.g. payment method, amount, transaction ID)
  • Transfer details (e.g. shipping address, tracking information)
| | Actors |
  • Surplus Property Management Office
  • Highest bidder
| | Normal Course |
  1. 1.The highest bidder provides payment and transfer details to the Surplus Property Management Office.
  2. 2.The Surplus Property Management Office verifies the payment and transfer details.
  3. 3.The Surplus Property Management Office authorizes the transfer of the property to the highest bidder.
  4. 4.The Surplus Property Management Office updates its inventory to reflect the transfer of the property.
  5. 5.The Surplus Property Management Office confirms the transfer of the property with the highest bidder.
| | Alternative Course | If the payment or transfer details provided by the highest bidder are not valid, the Surplus Property Management Office may request corrected information or cancel the transaction. | | Data output |
  • Confirmation of payment and transfer details
  • Confirmation of the transfer of the property
| | Post-Conditions |
  • The highest bidder has paid for and received the property.
  • The Surplus Property Management Office has updated its inventory to reflect the transfer of the property.
| | Exceptions |
  • Invalid payment or transfer details provided by the highest bidder.
  • Errors or delays in the payment or transfer process.
| | Related BBs |
  • Payment
  • eMarketplace
| | Sequence Diagram | title Transfer of Property​`Highest Bidder->Surplus Property Management Office: Provides payment and transfer details Surplus Property Management Office->Highest Bidder: Verifies payment and transfer details Surplus Property Management Office->Highest Bidder: Authorizes transfer of property Surplus Property Management Office->Surplus Property Management Office: Updates inventory Surplus Property Management Office->Highest Bidder: Confirms transfer of propert`y | ![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FdFdMmPK9Kh79f4WmnrTt%2FScreen%20Shot%202023-03-29%20at%208.35.12%20AM.png?alt=media\&token=763b143e-bb1f-4308-9ec2-a16305c83e9e)
# EM-B2G-UC2-SGP-Sporting Goods Procurement ## eM-B2G-UC2-SGP-Sporting Goods Procurement **Product use case summary** | ID | MKT | | ------- | -------------------------- | | Name | Sporting Goods Procurement | | Sector | Government Marketplace | | Version | 1.0 | | Status | Draft | This use case explains the procurement of sporting goods / equipment. The buyer is a registered government sporting authority. The seller is any eligible seller of sporting goods / equipment. Both the buyer and seller are registered as per the rules defined in the eMarketplace. For sake of simplicity, the eMarketplace is this use case is called as Government eMarketplace i.e. GEM. Once a seller is registered in GEM, it should publish its catalogue so that buyers are able to find the items they are searching for. The process of procurement involves 3 steps. 1. Create purchase requisition (PReq) - Buyer creates a PReq 2. Apply for purchase requisition (PReq) - Seller applies to participate in the PReq process 3. Award purchase requisition (PReq) - Buyer awards a purchase contract to a Seller The actual delivery of the items is out of scope of this use case. #### SGD targets **Target 8.2** Achieve higher levels of economic productivity through diversification, technological upgrading, and innovation, including through a focus on high-value-added and labour-intensive sectors. **Target 12.9** Support developing countries to strengthen their scientific and technological capacity to move towards more sustainable patterns of consumption and production. #### Building blocks * Registration * Digital registries * Identification and authentication * Content Management * Information Mediator * eMarketplace * Messaging * Payment #### Steps \ The preconditions for executing a PReq are as follows #### Register a buyer 1. Buyer submits registration information in the government portal 2. Buyer is evaluated (online or offline) 3. Buyer is approved 4. Buyer receives notification for approval #### Register a seller 1. Seller provides mandatory information on on the government portal 2. Seller is evaluated (online or offline) 3. Seller is approved (authorised seller) 4. Seller receives notification for approval #### Publish catalogue (by seller) 1. Seller logs in to the government portal 2. Seller uploads catalogue of products and/or services 3. Seller’s catalogue is evaluated 4. Seller catalogue is published on the government portal Once the preconditions are completed, a PReq can be created in the system. Listed below are the steps for creating a PReq leading to awarding of a purchase contract to the seller. #### Step 1 - Create purchase requisition (PReq) This step involves a formal request (broadcast of intent) by the sporting authority for the procurement of sporting goods. Here the sporting authority is the buyer and Seller is anybody who is registered in the government portal, usually a seller of sports goods. **Workflows** The workflows involved in this step are 1. The sporting authority (Buyer) representative logs in to the government portal. 2. Buyer searches for the sports goods (cricket kit) 3. Buyer views catalogue of matching products 4. Buyer selects the products that matches the requirements 5. Buyer provides the quantity required 6. Buyer provides the shipping / delivery location 7. Buyer provides the preferred vendor or a list of approved vendors 8. Buyer selected the option to create a requisition. 9. Buyer creates PReq and submits it for internal approvals. The sporting authority seeks internal approval before the requisition is published for response. **Building Blocks for Workflows** * Identity * Search **Functional Blocks for Workflows** * Catalogue * Cart * Fulfilment * Quotation #### Step 2 - Apply for purchase requisition (PReq) This step involves a Seller responding to the PReq through the government portal. The Seller is expected to respond in line with the terms and conditions of the PReq. **Workflows** The workflows involved in this step are 1. Seller logs in to the government portal. 2. Seller views the list of open PReqs 3. Seller offers a quote for the PReq 4. Seller is asked to authenticate 5. Seller submits the quote **Building Blocks for Workflows** * Identity * Search **Functional Blocks for Workflows** * Quotation #### Step 3 - Award purchase requisition (PReq) This step involves the Buyers evaluating all the responses from the interested Sellers and awarding a purchase contract to a selected Seller. The Buyers, in order to optimise the purchase contract, may engage in several iterations of negotiations. **Workflows** The workflows involved in this step are 1. Buyer logs in to the government portal. 2. Buyer views the list of quotations from the Sellers 3. Buyer is asked to authenticate before viewing the offer price 4. Buyer reviews the offer quotes and terms & conditions 5. Buyer creates preliminary purchase order for one or more offers 6. Buyer provides payment details 7. Buyer prints final purchase order (or contract) document 8. Buyer is asked to authenticate before the final print 9. Buyer confirms the purchase order to Seller 10. Seller receives notification **Building Blocks for Workflows** * Identity * Payment **Functional Blocks for Workflows** * Quotation * Order ### # eM-B2G-UC1-MoJ-HPMMS Data & Reporting Platform ## eM-B2G-UC1-MoJ-HPMMS Data & Reporting Platform Example Implementation ### MP-01-Registration-Buyer | Use Case Step | Use Case: Ministry of Justice - HMPPS Data & Reporting platform, Step: Registration (Public Sector buyer) | | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) | · The buyer must be employed by, or represent, a public sector organisation.· The buyer has a work email address to create an account OR· The buyer has successfully logged into their government SSO (Registration BB) and has the necessary authorization to complete the registration process.· Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (contract) and respective REST API services in Information Mediator has been opened to Registration BB.· The buyer email address domain is held on, or can be added to, a registry with approved or authenticated public sector domains. | | Data inputs | 1. Email address2. Password3. Name4. Organisation | | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: Public sector worker, System AdministratorSystem:· Digital Registries BB· Identity BB· Consent BB· Messaging BB· Information Mediator BB | | Normal Course (what happens if the event is triggered and the preconditions have been met) | Create a buyer account: Registration page provides a high level explanation of what is needed and process to create an account. “You must be employed by, or represent, a public sector organisation. Use your work email address to create an account. We use this to check that you are part of a public sector organisation. We will send an account activation email to this address. You will then be able to set your password.”Step 1: The public sector worker enters their email address to create an account:1. Enter email address2. Validate email address structure3. Confirm ‘Create account’Step 2: The application submits the email address to the relevant Digital Registries BB to verify it belongs to an authorised public sector organisation.Step 3: The application sends an email to the public sector worker with a URL to complete account creation.Step 4: The public sector worker completes account creation:1. Click on link in email2. Create account password3. Confirm | | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | If the public sector worker does not have an email address recognised by the registry, the registration application needs to provide an alternate mechanism for the worker to request an account.1. System Administrator confirms the domain is valid and adds to the registry.2. Public sector worker is notified and sent a link to create an account (URL to registration page) | | Data output | | | Post-Conditions (the success criteria) | The buyer is registered and can access buyer-only areas of the marketplace. | | Exceptions(error situations) | · A buyer can be only registered once. The system must prevent multiple registrations.o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actors· If the buyer does not have an email address with a domain registered in the Registry, then it is not possible to create an account (no personal emails).o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actors· If Identity BB or Consent BB is not available (service outage), then …..o Mitigation steps: Describe steps to be taken by the actors· If no internet, then the system is not available.o Mitigation steps: Display error page | | Related BBs(working groups related to this example implementation) | Identity BBApproval BBRegistration BBDigital Registries BB | | Sequence Diagram | | ### **MP-02-Registration-Supplier** | Use Case Step | Use Case: Ministry of Justice - HMPPS Data & Reporting platform, Step: Registration (Public Sector buyer) | | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) | · The supplier has an email address to create an account· The supplier must be employed by, and be authorised to represent, an organisation.· The supplier organisation is a legal entity and listed in the relevant registry (or via API to an official source).· Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (contract) and respective REST API services in Information Mediator has been opened to Registration BB. | | Data inputs | 1. Email address2. Password3. Name4. Organisation name5. Organisation address6. Contact phone number (for buyer communications)7. Contact email address (for buyer communications)8. Company ID (e.g.[ DUNS number](https://www.dnb.co.uk/duns-number/lookup/request-a-duns-number.html) in the UK, or registered on[ Companies House](https://find-and-update.company-information.service.gov.uk/)) | | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: Supplier representativeSystem:· Digital Registries BB· Identity BB· Consent BB· Messaging BB· Information Mediator BB | | Normal Course (what happens if the event is triggered and the preconditions have been met) | Create a supplier account: Registration page provides a high level explanation of what is needed and process to create an account. “You must provide:- a company name and company details that buyers may use to contact you- your own details to create a login- a DUNS number.It will take about 5 minutes to create your account. If your company isn’t registered with Companies House. If your company isn’t registered with Companies House, you may need to apply for a DUNS number before you can create a supplier account. It could take 3 to 5 days to get your DUNS number.”Step 1: The supplier enters their information to create an account:1. Enter company ID (e.g. DUNS) \*note this first step to reduce failing later in the process2. Enter company name3. Enter contact name4. Enter contact email address5. Enter contact phone number6. Confirm ‘Create account’Step 2: Create login details (not visible on the Marketplace)1. Enter work email address (note, can also add other email addresses later)2. Confirm ‘Continue’Step 3: Check your information:1. View ‘Company ID’, ‘Company name’, ‘Contact name’, ‘Contact email’, ‘Contact phone number’, ‘Login email’2. Option to change each field individually3. Confirm ‘Create account’4. Confirmation page with next step “We’ve sent an email to \. Use the link to activate your account and set your password.”Confirm application sends an email to the supplier with a URL to complete account creation.Step 4: The supplier completes account creation:5. Click on link in email6. Create account password7. Confirm | | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | | | Data output | | | Post-Conditions (the success criteria) | The supplier is registered and can access supplier-only areas of the marketplace. | | Exceptions(error situations) | · A supplier can be only registered once. The system must prevent multiple registrations.o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actors· If the supplier does not have a valid Company ID….o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actors· If Identity BB or Consent BB is not available (service outage), then …..o Mitigation steps: Describe steps to be taken by the actors· If no internet, then the system is not available.o Mitigation steps: Display error page | | Related BBs(working groups related to this example implementation) | Identity BBApproval BBRegistration BBDigital Registries BB | | Sequence Diagram | | # E-Marketplace Developed by Ravi Prakash, Dr. P. S. Ramkumar, Vikash Madduri, Caroline Mulligan, Ibrahim Elbhery, Mohammed Elgendy, Sujith Nair, Umesh Mohanty, Bharath Ganapathy, Ben Vandersteen, Gavin Hayman # 1 Version History The version history table describes the major changes to the specifications between published versions. | Version | Authors | Comment | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------- | | 0.1 | Ravi Prakash, Dr. P. S. Ramkumar, Vikash Madduri, Caroline Mulligan, Ibrahim Elbhery, Mohammed Elgendy, Sujith Nair, Umesh Mohanty, Bharath Ganapathy, Ben Vandersteen, Gavin Hayman | Developed use cases and first draft of full specification | # 2 Description This section provides the context of the building block. Governments are involved, directly or indirectly, in the purchase of various goods and services like computers/goods for their employees or technical services for projects to be implemented for the public welfare. E-Marketplace Building Block enables the trade of products and/or services via electronic media where at least one of the transacting parties taking part in the transaction is the government (either as the consumer or the provider) and the other party(ies) can be either pre-qualified providers or consumers of such goods and services (respectively). The government eMarketplace facilitates transparency by creating equal opportunities for all the stakeholders (providers and consumers) and thus creates an efficient market for goods and services. It helps build new relationships and thus builds trust. The consumer gains more insights into price information from different providers and is empowered to make rational decision-making. The sellers can optimize the sales/marketing costs and can improve their product range/portfolio by observing the demand in their domains thus multiply their market options even in international markets. The digital facility reduces time constraints for both parties. This document guides the creation of an e-Marketplace digital public infrastructure by connecting a set of interacting microservices. In the context of government, the government can itself act as a provider (For example: transferring money to citizens i.e. G2P), providing healthcare services (G2P); and also can demand goods and services , and other public entities (departmental transfers i.e. G2G) and private entities (For example: purchasing computers/ building and maintaining roads/technical/advisory/other maintenance services i.e. business to government (B2G)). This infrastructure is fundamentally decentralized or federated, although all the services can exist on a single cloud. This specification does not assume any specific implementation architecture or technology. Instead, it defines the actors and the interfaces that need to be implemented by the transacting entities. The current document focuses on enabling basic functionalities such as provider/consumer registration, listing a catalog of goods and services, and initiating a cycle of activities once a user selects a service. The document has considered payments/financial transactions between any two entities as optional based on the policies of the implementing government. > *There may be more functionalities required in the larger context of government procurement lifecycle that may complement the functionalities we have considered as relevant for an e-marketplace. For some country contexts, these specification might only be applicable to governments post-procurement. Such complementary functionalities may be included in future enhancements of this specification.* The eMarketplace Building Block could be useful in a variety of applications in different sectors for example: **Government purchase of goods and services (B2G)** * In the Health Sector, purchase of supplies to government hospitals. * In the Civil infrastructure sector, purchase of engineering services such as the construction of dams, buildings, computers, etc. * In the transportation sector, purchase of vehicles and associated maintenance services. **Government providing goods and services (G2B)** * In the Social Security sector, cash/subsidy support services of government to eligible citizens. * In the health sector, supply of nutrition and medicine to homes of patients/ pregnant mothers. * In the education sector government providing free learning materials to students. ## 2.1 **Current scope** While there may be many such use cases, within the current scope The functional requirements to cover the services required from the eMarketplace Building Block currently have considered specific use cases like, **Business to Government (B2G)** 1. [B2G-Use Case 1: Ministry of Justice - HMPPS Data & Reporting platform](https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/PUIGDILlDRSOB6K47k6e/~/changes/4/b2g-uc1-moj-hpmms-data-and-reporting-platform) 2. [B2G-Use Case 2: Purchase of Sporting Goods by a registered sporting authority](https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/PUIGDILlDRSOB6K47k6e/~/changes/4/mkt-b2g-uc2-sgp-sporting-goods-procurement) **Government to People (G2P)** 1. [G2P-Use Case 2: Online Reservation System (ORS)](https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/PUIGDILlDRSOB6K47k6e/~/changes/4/g2p-uc2-online-reservation-system-ors) 2. [G2P-Use Case 3: Government Auctions Marketplace (GAM)](https://github.com/GovStackWorkingGroup/bb-emarketplace/blob/23Q4/spec/broken-reference/README.md) These use cases have business processes with several steps, where in specific steps that involve the e-Marketplace Building Block services were studied as example implementations (such as Discovery, Ordering, Fulfillment, and Post-Fulfillment of services rendered by individual entities and users in various roles. Currently, the following actors have been identified as "users" of the e-Marketplace Building Block: * "Provider" is who manages the Building Block's implementation settings. A Building Block admin is also responsible for the enrolment of entitles and Organizers of those entities that use the eMarketplace Building Block. The Admins interact with the list of goods and services, the cycle of purchase activities, and communication management. * "Consumer" is the one who participates in events to perform various activities. Consumers must be registered in the eMarketplace Building Block before they can be enrolled in events. Resources may apply/respond to multiple goods and services in a catalog. Hence a registered consumer should be able to offer services in parallel if they are short-listed by the Provider. * "Subscribers" are platforms who participate in events to consume various activities. Subscribers must be registered in the e-Marketplace before they can be enrolled in activities. Subscribers may be enrolled in multiple events and may be passive to provider's requests. * "Internal team member" who participates in internal activities such as technical and financial evaluation of the bids received on the consumer side; preparation of documents and coordination across business development, technical, and managerial teams on the provider side. The corresponding "internal team member" communicates with the "provider" or "consumer", respectively. For the sake of simplicity, the B2G use cases covered in this scope assume that the providers (businesses) are already vetted and empanelled by the consumer. Additional features that may be required in a complete procurement process will be considered in future versions of this specification. For more details, visit the Future Considerations section in Chapter 10 : Other Resources. # 3 Terminology Terminology used within this specification.
TermDescription
B2GBusinesses selling products/services to government.
G2PGovernment providing products/services to persons.
e-MarketplaceAn e-Marketplace enables trade of products and/or services via electronic media. This is supported by innovative information and communication technologies to match supply and demand.

Government

e-marketplace

An online, end-to-end e-marketplace for the procurement and sale of commonly used goods and services by/from Government ministries, departments, public sector undertakings (PSUs), and other affiliated bodies.
SpecificationA technical document that describes how a system is to be developed to achieve a specific set of objectives or requirements.
EcosystemAn ecosystem is a community of stakeholders that support platforms implementing the specification. Ecosystems can be made up of developers, resellers, customers, software, services, and more.
Ecosystem MaturityThe level of readiness of an ecosystem to design, build, and use implementations of the specification. This can range from basic access to internet infrastructure to more advanced features like digital identities, assets, payments, and trust infrastructure.
ConsumerA person, or an organization that wants to discover, buy or avail products, services, and/or opportunities.
ProviderA person, or an organization that wants to publish, sell, allocate, or provide products, services, and/or opportunities.
Application PlatformThe platform where the consumer (typically the buyer) is onboarded.
Provider PlatformThe platform where the provider (typically the seller) is onboarded.
IntentA consumer’s desire to purchase, procure, or avail something being offered by a provider.
CatalogA provider’s list of products, services, and opportunities that is made available to consumers.
# 4 Key Digital Functionalities Key Digital Functionalities describe the core (required) functions that this Building Block must be able to perform. In General, this Building Block shall be accessible on various delivery channels such as Mobile, Kiosk, Web, and applications and should be digitally inclusive for users with different capabilities. The Building Block minor features such as physical delivery of goods and services, client feedback, etc. should be able to work on feature phones (without internet) as well. To facilitate various activities and different actors as described in section 2, the e-Marketplace Building Block must have specific Key Digital Functionalities. e-Marketplace transactions by definition should have: * Consumer Platforms (i.e. Super-apps, Chat messengers, Storefronts, etc.) to provide a rich, demand-centric experience; * Provider Platforms (i.e. a Hospital Management System, a Tendering Platform, or a Store Backend) that provide a rich, supply-centric experience; * Consumers (i.e. patients, citizen applicants, personnel, organizations, etc.); * Providers (i.e. hospitals, government departments, stores, organizations); * Agent (i.e. government service personnel, sellers, drivers, doctors, etc.); * Intent (i.e. a search by product, search by category, search by provider, etc.); * Catalogs (i.e. products, offers, add-ons, services); * Payments and Settlements (i.e. Cash on Delivery, Prepayment, T+n settlement, etc.); * Order management (i.e. contracts, appointments, bids, service requests); * Fulfillments (i.e. appointments, tender approval, delivery of goods and services); * Management of order lifecycle activities (from tendering to bidding, evaluation ordering, delivery tracking to feedback, etc.). The e-Marketplace Building Block must utilize the above objects to primarily support various consumer-provider interactions like discovery, ordering, fulfillment, and post-fulfillment. For example, a patient (Consumer) on WhatsApp (Consumer Platform) can search (Discovery) for a doctor (Agent) by his name (Intent). This request can be sent to ORS (Healthcare Provider Platform) that returns a list of Hospitals (Providers), with the various services offered (Catalog). Once identified, the patient (Consumer) can book an appointment (Order) with the Doctor (Agent). The various actors and their activities described in section 2 must be supported by a set of non-redundant, Key Digital Functionalities listed below: ## 4.1 Catalog Management This key digital functionality should allow providers to quickly and efficiently return a matching catalog upon receipt of a search intent. This e-Marketplace must also allow authorized administrators of the host entity to create and manage aggregated catalogs of providers, products, and services that can operate across multiple locations and timings. This functionality does not only apply to catalogs of products and services, it can be used to publish any economic resource that has a fulfillment cycle (e.g. it should allow government departments to create and manage catalogs of tenders across multiple departments spread across multiple locations). Admins must be able to create, read, update, or delete catalogs, and any sub-component of this catalog like Items/Categories/Providers/Locations/Agents/Fulfillments/Payments/etc. For tendered purchase, the government can publish tenders along with associated documents (e.g. Request for Proposals) in the tender's catalog. Pre-qualified providers already registered in the system can search the catalog and bid accordingly through quotation management services. In summary, the Building Block enables the cataloging of various elements such as providers/products/services/consumers/tenders/agents/etc., such that they can be searched, retrieved, and shared in appropriate workflows. ## 4.2 Inventory Management Authorized users of provider platforms should be able to manage the inventory of various resources available in a catalog. Providers should be able to manage the availability of products/agents/vehicles/etc., dynamically/on a real-time basis, in this Building Block. ## 4.3 Quotation Management This key digital functionality should allow consumers to select items, offers, and add-ons from a catalog and build a tender. It should be able to transmit them to pre-qualified providers and request a quotation with a proposal. Using this functionality, the providers must be able to submit their proposals with quotations. The consumers should be able to evaluate the quotations and proposals and select items (one or more) from (one or more different sources/providers) in order to generate the respective orders. Providers should be able to calculate a quote basis the item/offers/add-ons selected and to add dynamic offers without being specifically requested by the consumer. For example, a consumer should be able to add items from a provider's catalog, add offers, select add-ons into a common cart, and view the total cart value. This functionality should also allow providers to request additional information from the consumer that is required to proceed to the next stage. This functionality should also allow consumers and providers to transmit requests to each other to allow consented information sharing required to decide on a quote. ## 4.4 Terms Management This key digital functionality should allow the consumer to share billing details, fulfillment details, legal jurisdiction of dispute and resolution mechanism, and any additional information required for the provider to generate the final contract/order with the terms of fulfillment, payment, cancellation, refund, returns, and replacements. Administrators of the provider platforms should be able to configure various rules for final quote calculation, payment terms, and other terms of service depending upon the information received from the consumer. Providers should be able to evaluate the additional information that was requested when executing the quote agreement function and re-calculate the quote. For example, a healthcare service might have a standard quote for general citizens, but provide a discounted rate when it discovers from the additional data that the consumer is a senior citizen. It should allow the consumer to view the final payment terms and all details that will be included in the final contract. This functionality should allow for the final draft order/contract to be exchanged between the consumer and the provider. ## 4.5 Order Management This key digital functionality should allow the consumer to confirm an order. Bidders can confirm a bid in an auction. It should allow the creation and confirmation of an order expressed as a dual-digitally signed contract, with the terms that were agreed upon. In case the terms require payment before the creation of the contract, it should: allow the transmission of the proof of payment made from the payer to the payee, allow the provider to transmit a contract to the consumer, allow the consumer to request the provider to update various elements of the contract, allow updates to the terms of the contract and inform the consumer of the update, and allow browsing of contracts based on its various attributes. ## 4.6 Order Fulfillment This key digital functionality should allow the consumer of a service to receive various status updates regarding the fulfillment of a contract. This should allow providers to send various fulfillment updates to the consumer, and allow providers to allocate service agents manually/algorithmically (e.g. ambulance allocation as a response to a nearby emergency). The contract fulfilment could have a long duration of workflow (i.e. 3 years), depending upon the nature of the contract signed. The Building Block should be able to facilitate all the processes and reflect the dynamic status of a signed contract with updates/remarks/comments. For example, the sign-off agreement with feedback, and lessons learned report shall be submitted as and when the project finishes formally. ## 4.7 Order Tracking Consumers should be able to track the fulfillment of an order in real-time. Providers should be able to stream real-time data to the consumer related to the fulfillment of an order. This tracking is not necessarily geospatial but can contain any information that provides the consumer with real-time information like tracking of physical variables like temperature, speed, and countdown timers in bidding use cases. This functionality should render the real-time data to the consumer via a tracking page. ## 4.8 Order Cancellation This key digital functionality should allow the consumer or the provider to cancel a contract. This functionality should allow a consumer to view the terms of cancellation sent by a provider in response to a cancellation request. It should also allow both parties to see the canceled order. Providers should be able to request a cancellation reason along with additional information related to the reason for the cancellation. Consumers should be able to provide a cancellation reason and additional information related to the cancellation request. Once a cancellation is agreed upon by both parties, the current and historical data related to this activity/chain of activities shall be rolled back or archived, as per the policy. ## 4.9 Rating and Feedback Management Users of this key digital functionality should be able to rate various entities involved in the fulfillment of a contract. These users can be both consumers and providers. A consumer should be able to rate various aspects of the service like the agent, vehicle, quality of service, customer support, etc. A provider’s agent should be able to rate the consumer as well. Upon receipt of a rating, a provider can ask for additional feedback related to the rating. This means that the activity can occur throughout the cycle of various activities, not just at the end of a single process. ## 4.10 Support Management Users of this key digital functionality should be able to contact the support center to enquire about any issues that they may be facing and create a ticket. Customer support executives should be able to view details of a contract, fetch related information, view open tickets, and resolve them. If needed, customer support executives can fetch the contact details of a provider, or their agents to gain more information related to the fulfillment of an order. ## 4.11 Bid Evaluation The Building Block should facilitate the bid evaluation process (financial/technical/etc.) with defined criteria. The evaluation shall be conducted by the consumer, only. At first, the consumer defines an evaluation criteria for a good or service. Then the consumer admin/a group of professionals will receive the documents/details submitted by the provder; and evaluate them based on the pre-defined criteria. In case the consumers/providers have any clarifications, the concerned party should be able to seek guidance through writing questions/addendum/corrigendum. Finally, the evaluation should select the best bidder/provider. # 5 Cross-Cutting Requirements This section will highlight important requirements or describe any additional cross-cutting requirements that apply to this Building Block. ## 5.1 Personal Data Privacy (REQUIRED) Personal data must be kept private and never shared with any parties, except where specific authorization has been granted. The Consent Building Block shall follow the privacy principles as laid out in the GovStack architecture and security recommendations. ## 5.2 All transactions must be Audit Logged (RECOMMENDED) Logs should be kept in a database of all created, updated, or deleted records. Logs must include timestamps and identify the user and affiliation that performed the transaction. All audit logs shall be integrity-protected against tampering. The Consent Building Block shall follow the data policy and audit logging requirements as required by local policies. ## 5.3 Rollback capability (RECOMMENDED) The Building Block must perform various activities starting from initiation of purchase request/expression of interest to completion of order with feedback etc. In case of any non-compliance (due to both technical and functional reasons), it should be able to roll back to the initial state to safeguard the integrity of the application. # 6 Functional Requirements This section lists the technical capabilities of this Building Block. The e-Marketplace does not assume any particular standard like REST (Representational State Transfer) for all internal resource management. A brief description of the functional requirements necessary to orchestrate each key digital functionality is given below, considering the development of a minimum viable product. Detailed design and more elaborate feature lists of these functionalities can be customized by developers to optimally match respective implementation needs. It is also left to the application implementing this Building Block to receive the responses from the e-Marketplace and present them appropriately and provision for associated user interface interactions. ### **6.1 Catalog Management** * The e-Marketplace must allow the creation of a search request with a context and a message. The context must contain the action performed (“search”), the location where the search is limited to (e.g. country, city, area code, etc.), the domain/category of search (e.g. healthcare, services, etc.), the identity of the platform generating the search (e.g. domain, name), the callback URL of the platform generating the search. (REQUIRED) * The context must also contain a unique transaction ID to represent a sequence of interactions. It must also contain a unique message ID to match a request with a callback. The search context must contain a timestamp denoting the time of the search. (REQUIRED) * It should allow the addition of an intent to the message. The intent should contain fulfillment details in case the customer wants their order fulfilled in a specific way. If there is a preferred method of payment the intent should contain the payment details. The intent should define the category of the search. If search criteria is specific to an offer, intent must contain the offer detail. (REQUIRED) * It should allow multiple search parameters and should allow updates of search parameters, the system should provide the flexibility to update the search criteria, ex-search is to be modified for category, payment type, etc. (REQUIRED) * Once a call is made and the user wants to make a next search call that can not be fulfilled with the existing data from the previous search call, the system should be able to use the selected fields and the modified search fields for the next search call. (REQUIRED) * It must be able to transmit the search request along with all the search parameters to the provider platform. (REQUIRED) * This Building Block should allow fetching of catalogs that match the maximum number of search parameters. (RECOMMENDED) * The e-Marketplace must allow the creation of a catalog request for which context is required and should have a message. (REQUIRED) * The context is used to describe the metadata of the details provided in the message part. The context must contain an action. It also must contain a unique transaction ID received by the search request to represent a sequence of interactions. It must also contain a unique message ID to match a request with a callback. It must contain a timestamp denoting the time of the search requested for the catalog. (REQUIRED) * The message must contain a catalog. The catalog is used to describe the products or services provided by the platform. The catalog should be formed based on the search request made by the user and the data filtered accordingly and added to the catalog. (REQUIRED) * The catalog should be able to provide a description, it will have a description of the product or service, and it can have short/long descriptions or descriptions for images. (REQUIRED) * The catalog should provide fulfillment details, it will provide the details about the fulfillment mode if the e-Marketplace takes responsibility for the fulfillment. (RECOMMENDED) * The catalog should provide payment details about the payment terms offered by the e-Marketplace. The terms can be overridden by the providers' section, in case e-Marketplace does not take responsibility for the payments. (REQUIRED) * The catalog should provide expiry details about the time (timestamp) after which the catalog will not be valid. The consumer platform must be able to process the expiry and invalidate the catalog. E.g. A limited-time offer on a service/product. (REQUIRED) * The catalog should provide details of the time to live (TTL), which describes the time to set to exist for the catalog before it is discarded by a router and expires. The consumer platform must be able to process the TTL and invalidate the catalog. (REQUIRED) * The provider platform must be able to call the on\_search API provided by the Consumer platform to provide the catalog of the products. (REQUIRED) * The Consumer platform should provide a mechanism to handle the response (catalog) for a search, it should display the products/services in the catalog properly and filter the products at the UI layer. (REQUIRED) * The consumer platform should be able to handle multiple responses against a search tied with a message ID made, as the response can be from multiple providers. (REQUIRED) ### 6.2 Inventory Management * The e-Marketplace must allow the providers to add new products to their inventory. (REQUIRED) * It should be able to provide the current status of the inventory products, and the reporting should provide various filters based on which report can be generated. (REQUIRED) * It should allow updating the quantity and location of Items across multiple Providers and must restrict access to the providers' internal inventory. (REQUIRED) * Inventory must get adjusted based on the order placed (confirm/cancel/return). (REQUIRED) * It must allow checking of the availability of an Item in a catalog to avoid out-of-stock and over-stocking of the product. (REQUIRED) * It should provide a configurable system for notification which notifies based on the defined criteria. E.g. If the product quantity is less than 50, it must notify the provider by email or SMS. (RECOMMENDED) ### 6.3 Quotation Management * The e-Marketplace must enable the construction of a cart (or a cart-like experience) on the consumer platform, it must consist of context and message. (REQUIRED) * It must allow the addition/removal/update of multiple items and their respective quantities in the cart. (REQUIRED) * It must allow the consumer to choose from different offers available, and users should be able to modify or remove the offer before an order is placed. (REQUIRED) * It must allow users to modify the addons in the cart, the cart should not be frozen before an order is placed. The consumer should be able to modify the products i.e. add/remove products or modify the quantity of the product. (REQUIRED) * It must allow the transmission of the cart from the consumer platform to the provider platform. (REQUIRED) * Upon receiving the cart from the consumer platform, it must allow the provider platform to check for the availability of items in the cart. (REQUIRED) * It should check the validity of offers against the items in the cart. (REQUIRED) * it should dynamically calculate the quote based on the available items, offers, and add-ons. (REQUIRED) * It should transmit the cart with the updated quote from the provider platform to the consumer platform. (REQUIRED) * Provider platform should respond with context and either order or show error. (REQUIRED) * The consumer platform must process the quote properly and show the details along with the offers/delivery/payments details and break up of the quote. (REQUIRED) ### 6.4 Terms Management * The e-Marketplace must enable the construction of a draft order (or a pre-checkout-like experience) on the consumer platform, the draft order must contain context and a message with order details. (REQUIRED) * Consumer applications must allow the modification of the billing details of the order before a request is sent to the provider. (REQUIRED) * It must allow the consumers to modify the fulfillment details. E.g a consumer that has multiple addresses stored in the application should be able to select the address or add a new address for fulfillment. Consumers should also be able to choose from the available fulfillment options. (REQUIRED) * It must allow the transmission of the draft order from the consumer platform to the provider platform. (REQUIRED) * The consumer app must recalculate the quote based on the modifications made in the fulfillment details. (REQUIRED) * The consumer app must check the serviceability of the order based on agent availability. (REQUIRED) * Provider platform must re-check the availability of items and validity of offers, and re-calculate the quote based on the selection made by the consumer. (REQUIRED) * Provider platform must allow creation and modification of payment terms containing the payment stage, final payable amount, payment endpoint, and payment schedule to the draft order. (REQUIRED) * Provider app must allow the addition of terms of service, cancellation, returns, replacements, and refunds wherever applicable. (REQUIRED) * Provider platform must respond with context and either order or an error. (REQUIRED) * It must allow the transmission of the final draft order containing all the details of the order to the consumer platform. (REQUIRED) * The consumer platform must be able to handle the final draft order received from the provider and display the final order draft. (REQUIRED) ### 6.5 Order Management * The e-Marketplace must enable the creation of a confirmed order with a unique Order ID, the confirmed order must contain context and message. (REQUIRED) * Before confirming an order to the provider platform consumer platform must allow modification of a fulfillment state in the order. (REQUIRED) * The consumer platform must allow the transmission of the final draft order to the provider platform. (REQUIRED) * Provider platform must again allow re-checking of inventory availability before creating the order. (REQUIRED) * It must allow the transmission of the confirmed order from the provider platform to the consumer platform. (REQUIRED) * Provider platform response to a confirmed order must contain context and either an order or an error. (REQUIRED) * The consumer platform must be able to handle the order confirmation received from the provider platform and display the success message to the consumer along with the order ID and the product's details in the order. (REQUIRED) ### 6.6 Order Fulfillment * The e-Marketplace must enable the discovery and allocation of an Agent (if applicable) to the fulfillment of a confirmed order. (REQUIRED) * Consumer application must be able to fetch the status of the order from the provider platform. (REQUIRED) * Provider platform must be able to find out the status of the order and provide the details back to the consumer application. (REQUIRED) * Provider application must allow updates on the status of the order. (REQUIRED) * When a new event occurs on the fulfillment, the provider platform must pass on the information to the consumer platform. (REQUIRED) ### 6.7 Order Tracking * The e-Marketplace must enable the fetching of tracking information related to the order. (REQUIRED) * It must allow real-time data to be transmitted from the provider to the consumer. (REQUIRED) * It must allow the consumer platform to transmit a webhook endpoint to the provider platform which will handle the real-time updates on the tracking. (REQUIRED) * It must allow the provider platform to transmit a tracking link to the consumer platform. (REQUIRED) * The consumer platform must allow the display of the tracking details to the consumer along with the history. (REQUIRED) * Consumer applications must be able to segregate the tracking details based on the order ID. (REQUIRED) ### 6.8 Order Cancellation * The consumer platform must allow the creation of an order cancellation request for all the active orders that are yet not fulfilled. (REQUIRED) * The consumer platform must provide the order ID and allow the addition of the cancellation reason to the cancellation request. (REQUIRED) * Provider platform must handle the cancel order request and respond to the consumer platform. (REQUIRED) * Provider platform must allow modification of the order status and de-allocation of fulfillment services and the agents associated with the fulfillment of the contract. (REQUIRED) * It must allow the calculation of cancellation terms (if applicable) depending on the reason provided and the time of the cancellation request. (REQUIRED) * It must be possible to add a link to the cancellation terms (including cancellation fee) document to the order. (REQUIRED) * It must allow transmission of the canceled order between the consumer and the provider. (REQUIRED) * On cancellation of an order the provider platform must adjust the inventory of the products canceled. (REQUIRED) * The consumer platform must handle the response from the provider platform for a cancellation request, and update the order status, and display the details of the cancellation of the order along with the cancellation terms (including the cancellation fee). (REQUIRED) ### 6.9 Rating and Feedback Management * The e-Marketplace must allow ratings for various rateable entities to be captured by people involved in a transaction. (REQUIRED) * It must allow the transmission of ratings from the consumer platform to the provider platform. (REQUIRED) * It must allow the creation of feedback by the provider platform to get detailed additional information on the rating provided. (RECOMMENDED) * It must allow the creation of a request to collect additional feedback related to a rating. (RECOMMENDED) * It must allow fetching of various rateable entities related to an order. (RECOMMENDED) ### 6.10 Support Management * The e-Marketplace must allow support center information like email, phone number, and chat URL concerning an order to be transmitted between the consumer and the provider platforms. (REQUIRED) * It must allow the creation/read/update/deletion of tickets concerning an issue raised by a consumer, or an agent. (REQUIRED) ### 6.11 Information Mediator Interface * This sub-block runs protocols to communicate with the information mediator Building Block for exposing e-marketplace services to external Building Blocks and applications. (REQUIRED) * It also provides specific calls to APIs of information mediator Building Block to access services of external applications and Building Blocks. (REQUIRED) * It also handles any errors and failures in data exchange between the e-Marketplace and other Building Blocks/Apps (such as backoff and retries, etc.). (REQUIRED) * It routes error information if any to the logger sub-block. (REQUIRED) * It maintains a list of endpoint addresses of Information Mediator, or other Building Blocks/Applications. (REQUIRED) ### 6.12 Payment Interface * These are dedicated API interfaces defined in the Payments Building Block and hence not defined here: * The Payment interface should provide the necessary protocol, data format, and information and interface to interact with the Payments Building Block for sending payment collection or settlement instructions to existing payment infrastructures like Banking Systems, Credit Card Networks, Payment Gateways, etc. to facilitate payments made during a transaction in the e-Marketplace. (RECOMMENDED) ### 6.13 E-Signature Interface * These are dedicated API interfaces defined in the e-Signature Building Block and hence not defined here: * The E-Signature interface should provide the necessary protocol, data format, information, and interface to interact with the e-Signature Building Block for the digital signing and subsequent verification of each message that is transmitted between the consumer platform and the provider platform. (RECOMMENDED) ### 6.14 Registration Interface * These are dedicated API interfaces defined in the Registration Building Block and hence not defined here: * The Registration interface should provide the necessary protocol, data format, and information and interface to interact with the Registration Building Block to enable users on the Consumer Platform and the Provider Platform to sign up on their respective platforms with the required information necessary to perform transactions on the e-Marketplace. (RECOMMENDED) ### 6.15 Digital Identity & Verification Interface * These are dedicated API interfaces defined in the Digital Identity and Verification Building Block and hence not defined here: * The Digital Identity and Verification Building Block should provide the necessary protocol, data format, and information and interface to interact with the Digital Identity & Verification Building Block to enable users on the Consumer Platform and the Provider Platform interface to verify the digital identities in the e-Marketplace based on their national data registers. (RECOMMENDED) ### 6.16 Promotional Communications * These are dedicated API interfaces defined in the Communication and Outreach Building Block and hence not defined here: * The Communication and Outreach Building Block should provide the necessary protocol, data format, and information and interface to interact with the Communication and Outreach Building Block to enable users on the Consumer Platform and the Provider Platform interface to integrate with social media and messaging platforms. (RECOMMENDED) ### 6.17 **Content Management Interface** * These are dedicated API interfaces defined in the Content Management Interface Building Block and hence not defined here: * The Content Management Interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the Content Management Interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to manage content creation. (RECOMMENDED) * The interface should be able to moderate, and curate content creation. (RECOMMENDED) * The interface should enable the user (consumer/provider) to submit a document, and best practices in a prescribed format. (RECOMMENDED) * The interface should be able to store the documents in an organized manner. (RECOMMENDED) * It should allow any user to access the organized content. (RECOMMENDED) * The interface allows the providers to add text, images, product description details, etc. to a good/service. (RECOMMENDED) ### 6.18 **Workflow Interface** * These are dedicated API interfaces defined in the Workflow interface Building Block and hence not defined here: * The Workflow interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the Workflow interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to define and orchestrate the workflow within the system. (RECOMMENDED) * The interface should automate the processes involved in a lifecycle of technical activities, as defined by the administrator. (RECOMMENDED) * The status of each process should be 'Live', accompanied by timestamp details. (RECOMMENDED) * Upon a status is technically fulfilled (whether completed/achieved, failed, or canceled), the next relevant process should get triggered automatically. (RECOMMENDED) ### 6.19 **Dashboard & Business Analytics Interface** * These are dedicated API interfaces defined in the Dashboard and Business Analytics interface Building Block and hence not defined here: * The dashboard and business analytics interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the dashboard & business analytics interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to visualize the data in the system. (RECOMMENDED) * This interface should visualize the 'live' data on the identified set of data fields such as the number of items in stock, canceled items, etc. (RECOMMENDED) * This interface should analyze the data using basic mathematical operations (e.g. addition, average, and percentage) and offer insights. (RECOMMENDED) * The interface may have advanced mathematical operations such as analyzing historical data, and prediction analyses using linear regression and machine learning algorithms. (OPTIONAL) * This interface may be able to perform and fetch advance statistics, upon a request from the administrator, such as annual/half-yearly procurement/sales of goods and services, year-on increments, etc. (OPTIONAL) ### 6.20 **GIS Building Block Interface** * These are dedicated API interfaces defined in the GIS interface Building Block and hence not defined here: * The GIS interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the GIS interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to use GIS-based services like GIS tagging, tracking, etc. (RECOMMENDED) * This interface should track the goods/services, with timestamps. (RECOMMENDED) * The interface should tag the coordinates of entities, of persons as defined by the administrator. (RECOMMENDED) * The interface should be live. (RECOMMENDED) ### 6.21 Consent Management Interface * These are dedicated API interfaces defined in the Consent Management Interface Building Block and hence not defined here: * The Consent Management Interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the consent management interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to capture and validate the consent of the users. (RECOMMENDED) * This interface should accept data of different types and forms (biometrics, electronic messages, physical inputs). (RECOMMENDED) * The interface should let the user decide to accept/reject to share their consent to the applications. (RECOMMENDED) * The interface must respect the Consent protocols/related policies as defined by the administrator. (REQUIRED) * The interface must validate the consent of the user, as required. (REQUIRED) ### 6.22 Messaging Interface * These are dedicated API interfaces defined in the Messaging interface Building Block and hence not defined here: * The Messaging interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the messaging interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to exchange messages over a secured channel and have logging features. (RECOMMENDED) * This interface must act as a secured channel between sending and receiving users. (REQUIRED) * This interface should facilitate messages both encrypted and non-encrypted. (RECOMMENDED) * Logging, backup, retrieval of lost messages, and storage features shall be enabled by this interface. (RECOMMENDED) ### 6.23 Scheduling Interface * These are dedicated API interfaces defined in the Scheduling interface Building Block and hence not defined here: * The Scheduling interface Building Block should provide the necessary protocol, data format, and information and interface to interact with the Scheduling interface Building Block to enable users on the Consumer Platform and the Provider Platform interface to automate the process based on the events in the system. (RECOMMENDED) * The consumer must be able to publish advertisements/announcements on their website/mobile app/kiosk application about their requirements, vacancies, expertise, hosting events (physical or online), videos, advertisements, schedule of activities for the next 6 months, etc. (REQUIRED) * The platform should be able to connect with social media networks and reach the target audience. (RECOMMENDED) * The providers, consumers, and entities should be able to subscribe to social media channels and to the website to receive updates from the consumer. (RECOMMENDED) * The consumer should be able to send alerts, messages, and emails to subscribers about the new announcements. (RECOMMENDED) * The subscriber should be able to cancel their subscriptions as and when desired. (RECOMMENDED * This interface should orchestrate processes with time stamps when triggered. (RECOMMENDED) * It should update the processes and current list of stock items. (RECOMMENDED) * It should perform communication-related activities such as sending alerts, reminders, and automated messages, upon achieving a stage/state. (RECOMMENDED) ### 6.24 Bid Evaluation * The e-Marketplace must allow the consumer to perform an evaluation (financial, technical, any other). (REQUIRED) * The e-Marketplace must allow the consumer to pre-define an evaluation criteria for a good or service. (REQUIRED) * It shall facilitate the consumer and provider to seek clarification on any of the questions, they might have. (REQUIRED) * It must allow the individual members to read the documents, and other details and share their scores, remarks, and ranking based on the pre-defined criteria. (REQUIRED) * The evaluation report/remarks shall be fed to the administrator and the final acceptance (not the details) may be communicated to the providers. (REQUIRED) ## **The eMarketplace Building Block must enable Admins to** * enable the registration process of both prividers and consumers. * enable the verification of Foundational IDs come with no specified purpose or attached entitlement but functionalities simply let an entity prove who it is. * Captures only limited information about users, such as name, date of birth, address, and gender. * For a given set of credentials, fetches a corresponding ID if it exists in the registry. * Uses different biometric methods to identify and authenticate users through means other than user photographs (e.g. fingerprints, iris scans, facial recognition) to ensure there are no duplicates or fakes, creating a highly trustworthy database. * open bank accounts, buy SIM cards, receive entitlements from the government, sign forms electronically, invest in mutual funds, and get credit. * Incorporate privacy into its design when the purpose of the authentication is not revealed if a service provider sends an authentication request. **The e-Marketplace must enable Building Block Admins (Provider and Consumers) to** * seek consent from the entities, and people while registration. * dynamically identify, verify, and validate the registration details against those of public registries. * register without duplication an entity, into its Entity List with details (e.g. name, phone, email, website, etc.). The entities host various "activities" involving their affiliated resources (client case management). * categorize entities for easy searching and sorting, e.g. "department" or "ministry" . * configure rules for performance, security, and communication management between the eMarketplace and other Building Blocks (e.g. Registries, Identity and Verification, Information Mediation), applications (across different departments/ministries), and event participants. The exact parameters may be decided at implementation time. * extract log reports from the system as needed for monitoring and administering the Building Block operations. * register subscribers (persons/citizens/individuals) without duplication into eMarketplace's Subscriber list with contact details (phone/mail/URL/) as needed for communication, and reuse for enrolment to multiple activities. * register order life cycle events with a defined starting and ending time and an optional deadline for participants to log in their attendance in the activity if needed. * access a restricted number of subscribers to an activity, based on the sorting/category filter. * define and maintain a library of a predefined stack of messages/notifications for a specific host entity so that it can be reused in multiple activities conducted by the specific host entity. * define alert schedules for sending specific alert messages associated with a certain event at a determined date-time to associated subscribers or resources or both. * to extract logs related to activities that help in continuous improvement in order lifecycle event management. * to generate (i.e. purchase order/request), upload, and download the correspondence, circulars, and agreements in ".doc" and ".pdf" formats (document management). * (the provider) to implement large-scale outreach communication, and awareness campaign activities through electronic means. * to have a grievance readdress mechanism. * to facilitate seek/offer/resolve/implement feedback mechanisms once the enrolled activities are completed. * to delegate access management so that a particular role can perform only the tasks/activities that they are intended to. * to facilitate workflow management amongst active providers and consumers. * to handle exceptions when registration fails is unable to generate a purchase request, etc. * to facilitate communication between both parties, such as seeking clarification, responding to questions raised by the bidder on the bidding process or any other, etc. **The e-Marketplace must enable consumers and subscribers to** * search and extract their registration details in the eMarketplace. * search and extract their affiliation details across associated entities. * search and extract details of activities they are enrolled into. * search and extract details of subscribers of activities they are enrolled into. * receive scheduled alert messages from activities they are enrolled in. * search and list details of activities of a chosen category in a specified date-time range. * log status/attendance updates related to activities they are enrolled in. * view current status, details, and list of activities dynamically. #### The e-Marketplace must enable the administrator to catalog goods and services * get displayed a list of goods and/or services when an appropriate filter is used (e.g. a ministry or a type of service). * get displayed a list of active/closed/in progress items of ordering; with its stages for the Provider. * get displayed the number of days remaining of the entire project duration, payment milestones, and list of deliverables under the consumer department/ministry. #### The e-Marketplace must have system-automated internal functionality to * track all order lifecycle stages/events and send corresponding alert messages with unique tokens/IDs to relevant participants at appropriate times. * detect communication failure with other Building Blocks and applications and perform retries according to configured rules before logging a communication failure. Associated implementation-specific details that are not specified here. # 7 Data Structures This section provides information on the core data structures/data models that are used by this Building Block. The proposed resource model showing the relationship between data objects that are used by this Building Block is illustrated in the diagram below. ## 7.1 E-Marketplace Building Block Data Model
## 7.2 Data Structures ### 7.2.1 Ack **Description:** Outlines the acknowledgement sent in response to an API call. If the implementation uses HTTP/S, then Ack must be returned in the same session. Every API call to a Provider Platform must be responded to with an Ack whether the Provider Platform intends to respond with a callback or not. This has the property `status` that indicates the state of the Acknowledgement. **Fields:**
NameTypeDescriptionNotesNotes
statusstringThe status of the acknowledgement. If the request passes the validation criteria of the Provider Platform, then this is set to ACK. If a Provider Platform responds with status = ACK to a request, it is required to respond with a callback. If the request fails the validation criteria, then this is set to NACK. Additionally, if a Provider Platform does not intend to respond with a callback even after the request meets the validation criteria, it should set this value to NACK.Enum Data Type in C: ACK, NACK
tagsTagGroup arrayA grouped list of tags containing any additional information sent along with the Acknowledgement.
### 7.2.2 AddOn **Description:** Shows an additional item offered as a value-addition to a product or service. This does not exist independently in a catalog and is always associated with an item. **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | --------------------------------- | | id | string | Provider-defined ID of the add-on | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the add-on | | price | [Price](#7.2.40-price) | Price of the add-on | ### 7.2.3 Address **Description:** Outlines a postal address that is stored as a string value. ### 7.2.4 Agent **Description:** Outlines the direct performer, driver or executor that fulfils an order. It is usually a person. But in some rare cases, it could be a non-living entity like a drone, or a bot. Some examples of agents are a doctor in the healthcare sector, a driver in the mobility sector, or a delivery person in the logistics sector. This object can be set at any stage of the order lifecycle. This can be set at the discovery stage when the Provider Platform wants to provide details on the agent fulfilling the order, like in healthcare, where the doctor's name appears during a search. This object can also be used to search for a particular person that the customer wants to fulfil an order. Sometimes, this object gets instantiated after the order is confirmed, like in the case of on-demand taxis, where the driver is assigned after the user confirms the ride. **Fields:** | Name | Type | Description | | ------------ | ------------------------------------ | --------------------------------------------------- | | person | [Person](#7.2.39-person) | Personal details of the agent | | contact | [Contact](#7.2.13-contact) | Contact details of the agent | | organization | [Organization](#7.2.37-organization) | The organization details which the agent belongs to | | rating | [Rating](#7.2.43-rating) | The average user rating of the agent | ### 7.2.5 Authorization **Description:** Outlines an authorization mechanism used to start or end the fulfilment of an order. For example, in the mobility sector, the driver may require a one-time password to initiate the ride. In the healthcare sector, a patient may need to provide a password to open a video conference link during a teleconsultation. **Fields:**
NameTypeDescriptionNotesEnum
typestringType of authorization mechanism used. The allowed values for this field can be published as part of the network policy.
tokenstringToken used for authorization. This is typically generated at the Provider Platform. The Application Platform can send this value to the user via any channel that it uses to authenticate the user like SMS, Email, Push notification, or in-app rendering.
valid_fromstringTimestamp in RFC3339 format from which token is valid.Format: date-time
valid_tostringTimestamp in RFC3339 format until which token is valid.Format: date-time
statusstringStatus of the token.
### 7.2.6 Billing **Description:** Outlines the billing details of an entity. This has properties like name, organization, address, email, phone, time, tax\_number, created\_at,updated\_at. **Fields:**
NameTypeDescriptionNotesEnum
namestringName of the billable entity
organizationOrganizationDetails of the organization being billed.
addressAddressThe address of the billable entity
stateStateThe state where the billable entity resides. This is important for state-level tax calculation
cityCityThe city where the billable entity resides.
emailstringEmail address where the bill is sent toFormat: email
phonestringPhone number of the billable entity
timeTimeDetails regarding the billing period.
tax_idstringID of the billable entity as recognized by the taxation authority
### 7.2.7 Cancellation **Description:** Outlines a cancellation event. **Fields:**
NameTypeDescriptionFormatEnum
timestringDate-time when the order was cancelled by the buyerFormat: date-time
cancelled_bystringEnum Data Type in C: CONSUMER, PROVIDERCONSUMER, PROVIDER
reasonOption arrayThe reason for cancellation.
additional_descriptionDescriptorAny additional information regarding the nature of cancellation.
### 7.2.8 CancellationTerm **Description:** Outlines the cancellation terms of an item or an order. This can be referenced at an item or order level. Item-level cancellation terms can override the terms at the order level. **Fields:** | Name | Type | Description | | ------------------ | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | fulfillment\_state | [FulfillmentState](#7.2.26-fulfillmentstate) | The state of fulfillment during which this term is applicable. ([Fulfillment State](#7.3.26-fulfillmentstate)) | | reason\_required | boolean | Indicates whether a reason is required to cancel the order | | cancel\_by | [Time](#7.2.54-time) | Information related to the [time](#7.3.54-time) of cancellation. | | cancellation\_fee | [Fee](#7.2.23-fee) | The cancellation fees levied on the customer | | xinput | [XInput](#7.2.57-xinput) | Form to capture information related to the cancellation | | external\_ref | [MediaFile](#7.2.33-mediafile) | Any attachements related to the cancellation | ### 7.2.9 Catalog **Description:** Outlines the products or services offered by a Provider Platform. This is typically sent as the response to a search intent from an Application Platform. The payment terms, offers and terms of fulfilment supported by the Provider Platform can also be included here. The Provider Platform can show the hierarchical nature of products/services in its catalog using the parent\_category\_id in categories. The Provider Platform can also send a TTL (time to live) in the context which is the duration for which an Application Platform can cache the catalog and use the cached catalog. This has properties for Business to Business Procurement (BBP) like descriptor/categories/fulfillments/payments/offers/providers/exp. This is used in the following situations. This is typically used in the discovery stage when the Provider Platform sends the details of the products and services it offers as a response to a search intent from the Application Platform. **Fields:**
NameTypeDescriptionNotesEnum
descriptorDescriptorDescription of the catalog
fulfillmentsFulfillment arrayFulfillment modes offered at the Provider Platform level. This is used when a Provider Platform itself offers fulfillments on behalf of the providers it has aggregated.
paymentsPayment arrayPayment terms offered by the Provider Platform for all transactions. This can be overriden at the provider level.
offersOffer arrayOffers at the Provider Platform-level. This is usually used when the platform aggregates catalogs of multiple providers
providersProvider arrayProvider of service or product.
expstringTimestamp after which catalog will expireFormat: date-time
ttlstringDuration in seconds after which this catalog will expire
### 7.2.10 Category **Description:** A label under which a collection of items can be grouped. **Fields:** | Name | Type | Description | | -------------------- | ---------------------------------- | ---------------------------------------------- | | id | string | ID of the category | | parent\_category\_id | [Category](#7.2.10-category) | ID of the parent category | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the category | | time | [Time](#7.2.54-time) | Time at or during which this category is valid | | ttl | string | Time to live for an instance of this schema | | tags | [TagGroup](#7.2.53-taggroup) array | Array of grouped key value pairs | ### 7.2.11 Circle **Description:** Describes a circular region of a specified radius centered at a specified GPS coordinate. **Fields:** | Name | Type | Description | | ------ | ------------------------ | ------------------------------ | | gps | [Gps](#7.2.27-gps) | GPS Co-ordinates of the center | | radius | [Scalar](#7.2.47-scalar) | Radius of the circle | ### 7.2.12 City **Description:** Outlines a city **Fields:** | Name | Type | Description | | ---- | ------ | ---------------- | | name | string | Name of the city | | code | string | City code | ### 7.2.13 Contact **Description:** Outlines the contact information of an entity. **Fields:** | Name | Type | Description | | ----- | ------ | ---------------------------------------------------------------- | | phone | string | | | email | string | | | jcard | object | A Jcard object as per draft-ietf-jcardcal-jcard-03 specification | ### 7.2.14 Context **Description:** Every API call in Beckn Protocol has a context. It provides a high-level overview to the receiver about the nature of the intended transaction. Typically, it is the Application Platform that sets the transaction context based on the consumer's location and action on their UI. But sometimes, during unsolicited callbacks, the Provider Platform also sets the transaction context but it is usually the same as the context of a previous full-cycle, request-callback interaction between the Application Platform and the Provider Platform. The context object contains four types of fields. Demographic information about the transaction using fields like `domain`, `country`, and `region`. Addressing details like the sending and receiving platform's ID and API URL. Interoperability information like the protocol version that is implemented by the sender and transaction details like the method being called at the receiver's endpoint, the transaction\_id that represents an end-to-end user session at the Application Platform, a message ID to pair requests with callbacks, a timestamp to capture sending times, a ttl to specify the validity of the request, and a key to encrypt information if necessary. This object must be passed in every interaction between an Application Platform and a Provider Platform. In HTTP/S implementations, it is not necessary to send the context during the synchronous response. However, in asynchronous protocols, the context must be sent during all interactions. **Fields:**
NameTypeDescriptionNotesEnum
domainDomainIndustry sector code that is relevant to this transaction
locationLocationThe location where the request is restricted to
actionstringThe Beckn protocol method being called by the sender and executed at the receiver.
versionstringVersion of transaction protocol being used by the sender.
bap_idstringSubscriber ID of the Application Platform
bap_uristringSubscriber URL of the Application Platform for accepting callbacks from Provider Platforms.
bpp_idstringSubscriber ID of the Provider Platform
bpp_uristringSubscriber URL of the Provider Platform for accepting calls from Application Platforms.
transaction_idstringThis is a unique value which persists across all API calls from search through confirm. This is done to indicate an active user session across multiple requests. The Provider Platforms can use this value to push personalized recommendations, and dynamic offerings related to an ongoing transaction despite being unaware of the user active on the Application Platform.Format: uuid
message_idstringThis is a unique value which persists during a request / callback cycle. Since beckn protocol APIs are asynchronous, Application Platforms need a common value to match an incoming callback from a Provider Platform to an earlier call. This value can also be used to ignore duplicate messages coming from the Provider Platform. It is recommended to generate a fresh message_id for every new interaction. When sending unsolicited callbacks, Provider Platforms must generate a new message_id.Format: uuid
timestampstringTime of request generation in RFC3339 formatFormat: date-time
keystringThe encryption public key of the sender
ttlstringThe duration in ISO8601 format after timestamp for which this message holds valid
### 7.2.15 Country **Description:** Outlines a country. **Fields:** | Name | Type | Description | | ---- | ------ | ---------------------------------------------------- | | name | string | Name of the country | | code | string | Country code as per ISO 3166-1 and ISO 3166-2 format | ### 7.2.16 Credential **Description:** Outlines a credential of an entity (Person or Organization). **Fields:**
NameTypeDescriptionNotesEnum
idstring
typestringTakes a default value of "VerifiableCredential"
urlstringURL of the credentialFormat: uri
### 7.2.17 Customer **Description:** Outlines a customer buying/availing a product or a service. **Fields:** | Name | Type | Description | | ------- | -------------------------- | -------------------------------- | | person | [Person](#7.2.39-person) | Personal details of the customer | | contact | [Contact](#7.2.13-contact) | Contact details of the customer | ### 7.2.18 DecimalValue **Description:** Outlines a numerical value in decimal form. The string value should match the pattern "\[+-]?(\[0-9]\*\[.])?\[0-9]+". ### 7.2.19 Descriptor **Description:** Physical description of something. **Fields:** | Name | Type | Description | | ---------------- | ------------------------------------ | ------------------------------------------------------------------------ | | name | string | Name of the entity being described using this object | | code | string | Code of the entity being described using this object | | short\_desc | string | Short description of the entity being described using this object | | long\_desc | string | Long description of the entity being described using this object | | additional\_desc | object | Additional descriptions of the entity being described using this object | | media | [MediaFile](#7.2.33-mediafile) array | Multimedia files describing the entity being described using this object | | images | [Image](#7.2.28-image) array | Image describing the entity being described using this object | ### 7.2.20 Domain **Description:** Outlines the industry sector or sub-sector. The network policy should contain codes for all the industry sectors supported by the network. Domains can be created in varying levels of granularity. The granularity of a domain can be decided by the participants of the network. Too broad domains will result in irrelevant search broadcast calls to Provider Platforms that don't have services supporting the domain. Too narrow domains will result in a large number of registry entries for each Provider Platform. It is recommended that network facilitators actively collaborate with various working groups and network participants to carefully choose domain codes keeping in mind relevance, performance, and opportunity cost. It is recommended that networks choose broad domains like mobility, logistics, healthcare etc, and progressively granularize them as and when the number of network participants for each domain grows large. **Fields:** | Name | Type | Description | | ---------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | name | string | Name of the domain | | code | string | Standard code representing the domain. The standard is usually published as part of the network policy. Furthermore, the network facilitator should also provide a mechanism to provide the supported domains of a network. | | additional\_info | string | A url that contains addtional information about that domain. | ### 7.2.21 Duration **Description:** Outlines duration as per ISO8601 format. ### 7.2.22 Error **Description:** Outlines an error object that is returned by an Application Platform, Provider Platform or BG as a response or callback to an action by another network participant. This object is sent when any request received by a network participant is unacceptable. This object can be sent either during Ack or with the callback. **Fields:** | Name | Type | Description | | ------- | ------ | -------------------------------------------------------------------------------------------------------------------------------- | | code | string | Standard error code. For full list of error codes, refer to docs/protocol-drafts/BECKN-005-ERROR-CODES-DRAFT-01.md of this repo" | | paths | string | Path to json schema generating the error. Used only during json schema validation errors | | message | string | Human readable message describing the error. Used mainly for logging. Not recommended to be shown to the user. | ### 7.2.23 Fee **Description:** A fee applied to a particular entity. **Fields:** | Name | Type | Description | | ---------- | ------------------------------------ | --------------------------------------- | | percentage | [DecimalValue](#7.2.18-decimalvalue) | Percentage of order value levied as fee | | amount | [Price](#7.2.40-price) | Value of the fee levied | ### 7.2.24 Form **Description:** Outlines a form. **Fields:** | Name | Type | Description | Notes | Enum | | -------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------------- | | url | string | The URL from where the form can be fetched. The content fetched from the url must be processed as per the mime\_type specified in this object. Once fetched, the rendering platform can choosed to render the form as-is as an embeddable element; or process it further to blend with the theme of the application. In case the interface is non-visual, the the render can process the form data and reproduce it as per the standard specified in the form. | Format: uri | | | data | object | The form submission data | | | | mime\_type | string | This field indicates the nature and format of the form received by querying the url. MIME types are defined and standardized in IETF's RFC 6838. | | text/html, application/xml | | submission\_id | string | | Format: uuid | | ### 7.2.25 Fulfillment **Description:** Outlines how an order will be rendered/fulfilled to the end customer. **Fields:** | Name | Type | Description | | -------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | id | string | Unique reference ID to the fulfillment of an order | | type | string | A code that describes the mode of fulfillment. This is typically set when there are multiple ways an order can be fulfilled. For example, a retail order can be fulfilled either via store pickup or a home delivery. Similarly, a medical consultation can be provided either in-person or via tele-consultation. The network policy must publish standard fulfillment type codes for the different modes of fulfillment. | | rateable | boolean | Whether the fulfillment can be rated or not | | rating | [Rating](#7.2.43-rating) | The rating value of the fulfullment service. | | state | [FulfillmentState](#7.2.26-fulfillmentstate) | The current state of fulfillment. The Provider Platform must set this value whenever the state of the order fulfillment changes and fire an unsolicited `on_status` call. | | tracking | boolean | Indicates whether the fulfillment allows tracking. Has a default value of false. | | customer | [Customer](#7.2.17-customer) | the intended recipient of a fulfilled order | | agent | [Agent](#7.2.4-agent) | The agent that is currently handling the fulfillment of the order | | contact | [Contact](#7.2.13-contact) | Contact details related to the fulfillment | | vehicle | [Vehicle](#7.2.56-vehicle) | Vehicle used for fulfillment of the order | | stops | [Stop](#7.2.50-stop) array | The list of logical stops encountered during the fulfillment of an order. | | path | string | The physical path taken by the agent that can be rendered on a map. The allowed format of this property can be set by the network. | | tags | [TagGroup](#7.2.53-taggroup) array | List of grouped key-value pairs to transmit extended metadata related to the fulfillment | ### 7.2.26 FulfillmentState **Description:** Outlines the state of fulfilment. **Fields:**
NameTypeDescriptionNotesEnum
descriptorDescriptorThe description of the current fulfillment state of a confirmed order
updated_atstringTime at which the state of fulfillment was updatedFormat: date-time
updated_bystringID of entity which changed the state
### 7.2.27 Gps **Description:** Outlines a GPS coordinate. The string value should be of the pattern "^\[-+]?(\[1-8]?\d(\\.\d+)?|90(\\.0+)?),\s\*\[-+]?(180(\\.0+)?|((1\[0-7]\d)|(\[1-9]?\d))(\\.\d+)?)$". ### 7.2.28 Image **Description:** Outlines an image. **Fields:** | Name | Type | Description | Notes | Enum | | ---------- | ------ | ---------------------------------------------------------------------------------------- | ----------- | -------------------------- | | url | string | URL to the image. This can be a data url or an remote url | Format: uri | | | size\_type | string | The size of the image. The network policy can define the default dimensions of each type | | xs, sm, md, lg, xl, custom | | width | string | Width of the image in pixels | | | | height | string | Height of the image in pixels | | | ### 7.2.29 Intent **Description:** The intent to buy or avail of a product or a service. The Application Platform can declare the intent of the consumer containing what they want (A product, service, offer)/Who they want (A seller, service provider, agent etc)/Where they want it and where they want it from/When they want it (start and end time of fulfilment/How they want to pay for it/This has properties like descriptor, provider, fulfilment, payment, category, offer, item, tags. This is typically used by the Application Platform to send the purpose of the user's search to the Provider Platform. This will be used by the Provider Platform to find products or services it offers that may match the user's intent. For example, in Mobility, the mobility consumer declares a mobility intent. In this case, the mobility consumer declares information that describes various aspects of their journey like, where would they like to begin their journey (intent.fulfillment.start.location)/Where would they like to end their journey (intent.fulfillment.end.location)/When would they like to begin their journey (intent.fulfillment.start.time)/When would they like to end their journey (intent.fulfillment.end.time)/Who is the transport service provider they would like to avail services from (intent.provider)/Who is traveling (This is not recommended in public networks) (intent.fulfillment.customer)/What kind of fare product would they like to purchase (intent.item)/What add-on services would they like to avail/What offers would they like to apply on their booking (intent.offer)/What category of services would they like to avail (intent.category)/What additional luggage are they carrying/How would they like to pay for their journey (intent.payment). For example, in health domain, a consumer declares the intent for a lab booking the describes various aspects of their booking like, where would they like to get their scan/test done (intent.fulfillment.start.location)/When would they like to get their scan/test done (intent.fulfillment.start.time)/When would they like to get the results of their test or scan (intent.fulfillment.end.time)/Who is the service provider they would like to avail services from (intent.provider)/Who is getting the test or scan (intent.fulfillment.customer)/What kind of test or scan would they like to purchase (intent.item)/What category of services would they like to avail (intent.category)/How would they like to pay for their journey (intent.payment). **Fields:** | Name | Type | Description | | ----------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------ | | descriptor | [Descriptor](#7.2.19-descriptor) | A raw description of the search intent. Free text search strings, raw audio, etc can be sent in this object. | | provider | [Provider](#7.2.41-provider) | The provider from which the customer wants to place to the order from | | fulfillment | [Fulfillment](#7.2.25-fulfillment) | Details on how the customer wants their order fulfilled Fulfillment | | payment | [Payment](#7.2.38-payment) | Details on how the customer wants to pay for the order. Payment | | category | [Category](#7.2.10-category) | Details on the item category | | offer | [Offer](#7.2.34-offer) | details on the offer the customer wants to avail | | item | [Item](#7.2.31-item) | Details of the item that the consumer wants to order | | tags | [TagGroup](#7.2.53-taggroup) array | [Tags](#7.3.52-tag) | ### 7.2.30 ItemQuantity **Description:** Outlines the count or amount of an item. **Fields:** | Name | Type | Description | | --------- | ------ | -------------------------------------------------------------------------------------------------------------------- | | allocated | object | This represents the exact quantity allocated for purchase of the item. | | available | object | This represents the exact quantity available for purchase of the item. The buyer can only purchase multiples of this | | maximum | object | This represents the maximum quantity allowed for purchase of the item | | minimum | object | This represents the minimum quantity allowed for purchase of the item | | selected | object | This represents the quantity selected for purchase of the item | | unitized | object | This represents the quantity available in a single unit of the item | ### 7.2.31 Item **Description:** Outlines a product or a service offered to the end consumer by the provider. In the mobility sector, it can represent a fare product like a one-way journey. In the logistics sector, it can represent the delivery service offering. In the retail domain, it can represent a product like a grocery item. **Fields:** | Name | Type | Description | | ---------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | id | string | ID of the item. | | parent\_item\_id | string | ID of the item, this item is a variant of | | parent\_item\_quantity | [ItemQuantity](#7.2.30-itemquantity) | The number of units of the parent item this item is a multiple of | | descriptor | [Descriptor](#7.2.19-descriptor) | Physical description of the item | | creator | [Organization](#7.2.37-organization) | The creator of this item | | price | [Price](#7.2.40-price) | The price of this item, if it has intrinsic value | | quantity | [ItemQuantity](#7.2.30-itemquantity) | The quantity of the item | | category\_ids | array | Categories this item can be listed under | | fulfillment\_ids | array | Modes through which this item can be fulfilled | | location\_ids | array | Provider Locations this item is available in | | payment\_ids | array | Payment modalities through which this item can be ordered | | add\_ons | [AddOn](#7.2.2-addon) array | Add-ons to be included with the item | | cancellation\_terms | [CancellationTerm](#7.2.8-cancellationterm) array | Cancellation terms of this item | | refund\_terms | RefundTerm array | Refund terms of this item | | replacement\_terms | [ReplacementTerm](#7.2.45-replacementterm) array | Terms that are applicable be met when this item is replaced Replacement Terms | | return\_terms | [ReturnTerm](#7.2.46-returnterm) array | Terms that are applicable when this item is returned Return Terms | | xinput | [XInput](#7.2.57-xinput) | Additional input required from the customer to purchase / avail this item XInput | | time | [Time](#7.2.54-time) | Temporal attributes of this item. This property is used when the item exists on the catalog only for a limited period of time. | | rateable | boolean | Whether this item can be rated | | rating | [Rating](#7.2.43-rating) | The rating of the item | | matched | boolean | Whether this item is an exact match of the request | | related | boolean | Whether this item is a related item to the exactly matched item | | recommended | boolean | Whether this item is a recommended item to a response | | ttl | string | Time to live in seconds for an instance of this schema | | tags | [TagGroup](#7.2.53-taggroup) array | Grouped list of extended data regarding the item | ### 7.2.32 Location **Description:** The physical location of something. **Fields:** | Name | Type | Description | Notes | Enum | | ---------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------- | ---- | | id | string | | | | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the location | | | | map\_url | string | The url to the map of the location. This can be a globally recognized map url or the one specified by the network policy. | Format: uri | | | gps | [Gps](#7.2.27-gps) | The GPS co-ordinates of this location. | | | | address | [Address](#7.2.3-address) | The address of this location. | | | | city | [City](#7.2.12-city) | The city this location is, or is located within | | | | district | District | The district this location is, or is located within | | | | state | [State](#7.3.49-state) | The state this location is, or is located within | | | | country | [Country](#7.2.15-country) | The country this location is, or is located within | | | | area\_code | string | Area code of the location ex : ZIP code, Pincode etc | | | | circle | [Circle](#7.2.11-circle) | Circle that forms the boundary of the location | | | | polygon | string | The boundary polygon of this location | | | | 3dspace | string | The three dimensional region describing this location | | | | rating | [Rating](#7.2.43-rating) | The rating of this location | | | ### 7.2.33 MediaFile **Description:** This object contains a URL to a media file. **Fields:**
NameTypeDescriptionNotesEnum
mimetypestringindicates the nature and format of the document, file, or assortment of bytes. MIME types are defined and standardized in IETF's RFC 6838
urlstringThe URL of the fileFormat: uri
signaturestringThe digital signature of the file signed by the sender
dsastringThe signing algorithm used by the sender
### 7.2.34 Offer **Description:** An offer associated with a catalog. This is typically used to promote a particular product and enable more purchases. **Fields:** | Name | Type | Description | | ------------- | ---------------------------------- | -------------------------------------------- | | id | string | | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the offer | | location\_ids | array | IDs of the Locations this offer is valid in | | category\_ids | array | IDs of the Categories this offer is valid in | | item\_ids | array | IDs of the items this offer is valid in | | time | [Time](#7.2.54-time) | Time for which this offer is valid | | tags | [TagGroup](#7.2.53-taggroup) array | Additional metadata related to this offer | ### 7.2.35 Option **Description:** Outlines a selectable option. **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | ------------------------- | | id | string | | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the option | ### 7.2.36 Order **Description:** Outlines a legal purchase order. It contains the complete details of the legal contract created between the buyer and the seller. **Fields:**
NameTypeDescriptionNotesEnum
idstringHuman-readable ID of the order. This is generated at the Provider Platform layer. The Provider Platform can either generate order id within its system or forward the order ID created at the provider level.
ref_order_idsarrayA list of order IDs to link this order to previous orders.
statusstringStatus of the order. Allowed values can be defined by the network policyEnum Data Type in C: ACTIVE, COMPLETE, CANCELLEDACTIVE, COMPLETE, CANCELLED
typestringThis is used to indicate the type of order being created to Provider Platforms. Sometimes orders can be linked to previous orders, like a replacement order in a retail domain. A follow-up consultation in healthcare domain. A single order part of a subscription order. The list of order types can be standardized at the network level. Has a default value of "DEFAULT"Enum Data Type in C: DRAFT, DEFAULTDRAFT, DEFAULT
providerProviderDetails of the provider whose catalog items have been selected.
itemsItems arrayThe items purchased / availed in this order
add_onsAddOn arrayThe add-ons purchased / availed in this order
offersOffers arrayThe offers applied in this order
billingBilling arrayThe billing details of this order
fulfillmentsFulfillment arrayThe fulfillments involved in completing this order
cancellationCancellationThe cancellation details of this order
cancellation_termsCancellationTerm arrayCancellation terms of this item
refund_termsRefundTerm arrayRefund terms of this item
replacement_termsReplacementTerm arrayReplacement terms of this item
return_termsReturnTerm arrayReturn terms of this item
quoteQuotationThe mutually agreed upon quotation for this order.
paymentsPayment arrayThe terms of settlement for this order
created_atstringThe date-time of creation of this orderFormat: date-time
updated_atstringThe date-time of updated of this orderFormat: date-time
xinputXInputAdditional input required from the customer to confirm this order
tagsTagGroup arrayGrouped list of extended metadata related to the Order
### 7.2.37 Organization **Description:** An organization. Usually a recognized business entity. **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | ------------------------------------------------------------ | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the organization | | address | [Address](#7.2.3-address) | The postal address of the organization | | state | [State](#7.3.49-state) | The state where the the organization's address is registered | | city | [City](#7.2.12-city) | The city where the the organization's address is registered | | contact | [Contact](#7.2.13-contact) | Contact details of the organization | ### 7.2.38 Payment **Description:** Outlines the terms of settlement between the Application Platform and the Provider Platform for a single transaction. When instantiated, this object contains the amount that has to be settled/The payment destination details/When the settlement should happen/A transaction reference ID. During a transaction, the Provider Platform reserves the right to decide the terms of payment. However, the Application Platform can send its terms to the Provider Platform first. If the Provider Platform does not agree to those terms, it must overwrite the terms and return them to the Application Platform. If overridden, the Application Platform must either agree to the terms set by the Provider Platform in order to preserve the provider's autonomy or abort the transaction. In case of such disagreements, the Application Platform and the Provider Platform can perform offline negotiations on the payment terms. Once an agreement is reached, the Application Platform and Provider Platform can resume transactions. **Fields:**
NameTypeEnumFormatDescription
idstringID of the payment term that can be referred at an item or an order level in a catalog
collected_byThis field indicates who is the collector of payment. The Application Platform can set this value to 'Application Platform' if it wants to collect the payment first and settle it to the Provider Platform. If the Provider Platform agrees to those terms, the Provider Platform should not send the payment url. Alternatively, the Provider Platform can set this field with the value 'Provider Platform' if it wants the payment to be made directly.
urlstringFormat: uriuriA payment url to be called by the Application Platform. If empty, then the payment is to be done offline. The details of payment should be present in the params object. If tl_method = http/get, then the payment details will be sent as url params. Two url param values, $transaction_id and $amount are mandatory.
paramsobject
typestringPRE-ORDER, PRE-FULFILLMENT, ON-FULFILLMENT, POST-FULFILLMENT
statusstringPAID, NOT-PAID
timeTimeTemporal details related to the settlement of the orderTime
tagsTagGroup arrayGrouped list of metadata related to the settlement of the orderTags
### 7.2.39 Person **Description:** Outlines a person as any individual. **Fields:**
NameTypeDescriptionNotesEnum
idstringDescribes the identity of the person
urlstringProfile url of the personFormat: uri
namestringthe name of the person
imageImageImage
ageDurationAge of the person
dobstringDate of birth of the personFormat: date
genderstringGender of something, typically a Person, but possibly also fictional characters, animals, etc. While Male and Female may be used, text strings are also acceptable for people who do not identify as a binary gender.Allowed values for this field can be published in the network policy
credsCredential arrayList of the person's credentials
languagesarray
skillsarray
tagsTagGroup arrayGrouped list containing extended metadata about the person
### 7.2.40 Price **Description:** Outlines the price of an Item **Fields:** | Name | Type | Description | | ---------------- | ------------------------------------ | -------------------------------- | | currency | string | | | value | [DecimalValue](#7.2.18-decimalvalue) | Default value of the Item price | | estimated\_value | [DecimalValue](#7.2.18-decimalvalue) | Estimated value of an Item price | | computed\_value | [DecimalValue](#7.2.18-decimalvalue) | Computed value of an Item price | | listed\_value | [DecimalValue](#7.2.18-decimalvalue) | Listed value of an Item price | | offered\_value | [DecimalValue](#7.2.18-decimalvalue) | Offered value of an Item price | | minimum\_value | [DecimalValue](#7.2.18-decimalvalue) | Minimum value of an Item price | | maximum\_value | [DecimalValue](#7.2.18-decimalvalue) | Maximum value of an Item price | ### 7.2.41 Provider **Description:** Outlines the catalog of a business. **Fields:**
NameTypeDescriptionNotesEnum
idstringId of the provider
descriptorDescriptorDescription of the provider
category_idstringCategory Id of the provider at the Provider Platform-level catalog
ratingRatingRating of the provider
timeTimeTime during which the catalog is available
categoriesCategory arrayCategories in the catalog
fulfillmentsFulfillment arrayList of fulfillment terms of the provider
paymentsPayment arrayList of payment terms of the provider
locationsLocation arrayLocations where the provider can be accessed
offersOffer arrayOffers listed by the provider
itemsItem arrayItems cataloged by the provider
expstringTime after which catalog has to be refreshedFormat: date-time
rateablebooleanWhether this provider can be rated or not
ttlintegerThe time-to-live in seconds, for this object. This can be overriden at deeper levels. A value of -1 indicates that this object is not cacheable.
tagsTagGroup arrayGrouped metadata related to the provider
### 7.2.42 Quotation **Description:** Outlines a quote. It is the estimated price of products or services from the Provider Platform. This has properties like price, breakup, and TTL. **Fields:**
NameTypeDescriptionNotesEnum
idstringID of the quote.Format: uuid
pricePriceThe total quoted price
breakuparraythe breakup of the total quoted price
ttlDurationDuration for which the quotation is valid
### 7.2.43 Rating **Description:** Outlines the rating of an entity. **Fields:**
NameTypeDescriptionNotesNotes
rating_categorystringCategory of the entity being ratedEnum Data Type in C: Item, Order, Fulfillment, Provider, Agent, Support
idstringId of the object being rated
valuestringRating value given to the object. This can be a single value or can also contain an inequality operator like gt, gte, lt, lte. This can also contain an inequality expression containing logical operators like && and.
### 7.2.44 Region **Description:** Outlines an arbitrary region of space. The network policy should contain a published list of supported regions by the network. **Fields:**
NameTypeDescriptionNotesFormat
dimensionsstringThe number of dimensions that are used to describe any point inside that region. The most common dimensionality of a region is 2, that represents an area on a map. There are regions on the map that can be approximated to one-dimensional regions like roads, railway lines, or shipping lines. 3 dimensional regions are rarer, but are gaining popularity as flying drones are being adopted for various fulfillment services.Enum Data Type in C: 1, 2, 3
typestringThe type of region. This is used to specify the granularity of the region represented by this object. Various examples of two-dimensional region types are city, country, state, district, and so on. The network policy should contain a list of all possible region types supported by the network.
namestringName of the region as specified on the map where that region exists.
codestringA standard code representing the region. This should be interpreted in the same way by all network participants.
boundarystringA string representing the boundary of the region. One-dimensional regions are represented by polylines. Two-dimensional regions are represented by polygons, and three-dimensional regions can represented by polyhedra.
map_urlstringThe url to the map of the region. This can be a globally recognized map or the one specified by the network policy.
### 7.2.45 ReplacementTerm **Description:** The replacement policy for an item or an order. **Fields:** | Name | Type | Description | | ------------------ | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | fulfillment\_state | [FulfillmentState](#7.2.26-fulfillmentstate) array | The state of fulfillment during which this term is applicable. | | replace\_within | [Time](#7.2.54-time) | Applicable only for buyer managed returns where the buyer has to replace the item before a certain date-time, failing which they will not be eligible for replacement. | | external\_ref | [MediaFile](#7.2.33-mediafile) | Any file containing info related to the terms | ### 7.2.46 ReturnTerm **Description:** Outlines the return policy of an item or an order. **Fields:**
NameTypeDescriptionNotesxx
fulfillment_stateFulfillmentState arrayThe state of fulfillment during which this term IETF''s applicable.
return_eligiblebooleanIndicates whether the item is eligible for return
return_timeTimeApplicable only for buyer managed returns where the buyer has to return the item to the origin before a certain date-time, failing which they will not be eligible for refund.
return_locationLocationThe location where the item or order must / will be returned to
fulfillment_managed_bystringThe entity that will perform the returnEnum Data Type in C: CONSUMER, PROVIDER
### 7.2.47 Scalar **Description:** Outlines a scalar. **Fields:**
NameTypeDescriptionNotesFormat
typestringEnum Data Type in C: CONSTANT, VARIABLE
valueDecimalValueDefault value
estimated_valueDecimalValueEstimated value
computed_valueDecimalValueComputed value
rangeDecimalValueRange of values
unitstringunit of value
### 7.2.48 Schedule **Description:** Outlines schedule as a repeating time period used to describe a regularly recurring event. At a minimum, a schedule will specify frequency which describes the interval between occurrences of the event. Additional information can be provided to specify the schedule more precisely. This includes identifying the timestamps(s) of when the event will take place. Schedules may also have holidays to exclude a specific day from the schedule. This has properties like frequency, holidays, and times. **Fields:** | Name | Type | Description | | --------- | ---------------------------- | ----------------------- | | frequency | [Duration](#7.2.21-duration) | Frequency of recurrence | | holidays | array | Holidays | | times | [Time](#7.2.54-time) array | Time slots | ### 7.3.49 State **Description:** A bounded geopolitical region of governance inside a country. **Fields:** | Name | Type | Description | | ---- | ------ | ---------------------------------------------------- | | name | string | Name of the state | | code | string | State code as per country or international standards | ### 7.2.50 Stop **Description:** A logical point in space and time during the fulfilment of an order. **Fields:** | Name | Type | Description | | ---------------- | -------------------------------------- | --------------------------------------------------------------------------------------- | | id | string | | | parent\_stop\_id | string | | | location | [Location](#7.2.32-location) | [Location](#7.3.32-location) of the stop | | type | string | The type of stop. Allowed values of this property can be defined by the network policy. | | time | [Time](#7.2.54-time) | Timings applicable at the stop. | | instructions | [Descriptor](#7.2.19-descriptor) array | Instructions that need to be followed at the stop | | contact | [Contact](#7.2.13-contact) | Contact details of the stop | | person | [Person](#7.2.39-person) | The details of the person present at the stop | | authorization | [Authorization](#7.2.5-authorization) | Authorization details required to commence this leg of fulfillment | ### 7.2.51 Support **Description:** Details of customer support. **Fields:**
NameTypeDescriptionNotesEnum
ref_idstring
callback_phonestringFormat: phone
phonestringFormat: phone
emailstringFormat: email
urlstringFormat: uri
### 7.2.52 Tag **Description:** Outlines a tag. This is used to contain extended metadata. This object can be added as a property to any schema to describe extended attributes. For Application Platforms, tags can be sent during search to optimize and filter search results. Provider Platforms can use tags to index their catalog to allow better search functionality. Tags are sent by the Provider Platform as part of the catalog response in the `on_search` callback. Tags are also meant for display purposes. Upon receiving a tag, Application Platforms are meant to render them as name-value pairs. This is particularly useful when rendering tabular information about a product or service. **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the Tag, can be used to store detailed information. | | value | string | The value of the tag. This set by the Provider Platform and rendered as-is by the Application Platform. | | display | boolean | This value indicates if the tag is intended for display purposes. If set to `true`, then this tag must be displayed. If it is set to `false`, it should not be displayed. This value can override the group display value. | ### 7.2.53 TagGroup **Description:** A collection of tag objects with group-level attributes ([Documentation on Tag Groups schema](https://github.com/beckn/protocol-specifications/discussions/316)). **Fields:** | Name | Type | Description | | ---------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | display | boolean | Indicates the display properties of the tag group. If display is set to false, then the group will not be displayed. If it is set to true, it should be displayed. However, group-level display properties can be overriden by individual tag-level display property. As this schema is purely for catalog display purposes, it is not recommended to send this value during search. Has a default value of true. | | descriptor | [Descriptor](#7.2.19-descriptor) | Description of the TagGroup, can be used to store detailed information. | | list | array | An array of Tag objects listed under this group. This property can be set by Application Platforms during search to narrow the `search` and achieve more relevant results. When received during `on_search`, Application Platforms must render this list under the heading described by the `name` property of this schema. | ### 7.2.54 Time **Description:** Outlines time in its various forms. It can be a single point in time/duration or a structured timetable of operations. This has properties like label, timestamp, duration, range, days, and schedule. **Fields:**
NameTypeDescriptionNotesEnum
labelstring
timestampstringFormat: date-time
durationDurationDuration between two instances of time
rangeobject
daysstringcomma separated values representing days of the week
scheduleScheduleschedule
### 7.2.55 Tracking **Description:** Contains tracking information that can be used by the Application Platform to track the fulfillment of an order in real-time. which is useful for knowing the location of time-sensitive deliveries. **Fields:** | Name | Type | Description | Format | Enum | | -------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ---------------- | | id | string | A unique tracking reference number | | | | url | string | A URL to the tracking endpoint. This can be a link to a tracking webpage, a webhook URL created by the Application Platform where Provider Platform can push the tracking data, or a GET url creaed by the Provider Platform which the Application Platform can poll to get the tracking data. It can also be a websocket URL where the Provider Platform can push real-time tracking data. | uri | | | location | [Location](#7.2.32-location) | In case there is no real-time tracking endpoint available, this field will contain the latest location of the entity being tracked. The Provider Platform will update this value everytime the Application Platform calls the track API. | | | | status | string | This value indicates if the tracking is currently active or not. If this value is `active`, then the Application Platform can begin tracking the order. If this value is `inactive`, the tracking URL is considered to be expired and the Application Platform should stop tracking the order. | | active, inactive | ### 7.2.56 Vehicle **Description:** Outlines a vehicle is a device that is designed or used to transport people or cargo over land, water, air, or through space. This has properties like category, capacity, make, model, size, variant, colour,energy\_type, and registration. **Fields:** | Name | Type | Description | | ------------------ | ------- | ----------- | | category | string | | | capacity | integer | | | make | string | | | model | string | | | size | string | | | variant | string | | | color | string | | | energy\_type | string | | | registration | string | | | wheels\_count | string | | | cargo\_volumne | string | | | wheelchair\_access | string | | | code | string | | | emission\_standard | string | | ### 7.2.57 XInput **Description:** Contains any additional or extended inputs required to confirm an order. This is typically a Form Input. Sometimes, the selection of catalog elements is not enough for the Provider Platform to confirm an order. For example, to confirm a flight ticket, the airline requires details of the passengers along with information on baggage, and identity, in addition to the class of ticket. Similarly, a logistics company may require details on the nature of the shipment in order to confirm the shipping. A recruiting firm may require additional details on the applicant in order to confirm a job application. For all such purposes, they can choose to send this object attached to any object in the catalog that is required to be sent while placing the order. This object can typically be sent at an item level or at the order level. The item level XInput will override the Order level XInput as it indicates a special requirement of information for that particular item. Hence the Application Platform must render a separate form for the Item and another form at the Order level before confirmation. **Fields:** | Name | Type | Description | | -------- | -------------------- | ------------------------------------------------------------------------------------------------------ | | form | [Form](#7.2.24-form) | Form details to capture input | | required | boolean | Indicates whether the form data is mandatorily required by the Provider Platform to confirm the order. | | head | object | Form headers | # 8 Service APIs This section provides a reference for APIs that should be implemented by this Building Block. This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block. To develop the E-Marketplace Building Block API, we have referred to various open-source specifications and data standards. The objective is to develop an API specification for this building block that is future-proof to accommodate a broad range of use cases that is agnostic of industry sector, region, and implementation technology. To develop a common data standard, Several sector-specific marketplace specifications were referred to like [NetEx](https://www.transmodel-cen.eu/netex-standard/), [TOMP](https://github.com/TOMP-WG/TOMP-API), (for mobility), [Electronic Data Interchange](https://www.edibasics.com/what-is-edi/) for logistics, [Open Contracting and Data Standards](https://www.open-contracting.org/data-standard/) (OCDS), [Universal Business Language](http://docs.oasis-open.org/ubl/UBL-2.1.html) (UBL) for procurements, [HL7 / FHIR ](https://www.hl7.org/implement/standards/index.cfm?ref=nav)for healthcare. To understand activities involved in administering the e-marketplace, several open-source e-marketplace software APIs like [Magento](https://business.adobe.com/products/magento/magento-commerce.html), [WooCommerce](https://woocommerce.com/), and [OpenCart](https://www.opencart.com/), were also referred. To facilitate interoperability, we have referred to various open-source communication protocols, API and data standards like, [Schema.org](http://schema.org/) , [HTTP/2](https://datatracker.ietf.org/doc/html/rfc9113), and [DNS](https://datatracker.ietf.org/doc/html/rfc1035) and [Beckn protocol](https://becknprotocol.io/). Privacy and Security is especially important to Government E-marketplaces as they usually contain sensitive information about customers and businesses. In such a scenario, it is not recommended to create a “store-of-value” in between the consumer and the marketplace. Instead a more federated approach is needed that transforms a “Store-of-value” into a “Flow-of-value”. Such an architecture will ensure privacy and security of data, minimize concentration risk, and allow for innovation to happen at the edges rather than at the center. The E-Marketplace building block API specification has been *adapted* from Beckn protocol APIs and schema. Currently Beckn protocol is the only open-source specification that enables transaction interoperability in e-marketplaces through a peer-to-peer (flow-of-value) protocol. It is an open-source generic transaction protocol that when implemented, allows any application to perform discovery, ordering, fulfillment, and post-fulfillment activities *without* the need of a central intermediary. It is a widely adopted open-source protocol specification built using design principles and standards from all of the above mentioned technologies and standards. It is agnostic of industry sector, region, or implementation technology. It is highly recommended for any e-marketplace application in GovStack to also implement a Beckn protocol interface to allow any platform inside or outside the GovStack ecosystem to access the e-marketplace without the need of a central platform intermediary. Furthermore, It can be adapted to any existing sector-specific standard like the ones mentioned above. The [GovStack non-functional requirements](https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements/6-onboarding) document provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here. # 8.1 Catalog Management Platform Administration APIs consist of all the endpoints that are used to provide user experience and manage the business workflows like catalog management, cart management, checkout, terms management, content management, etc. These follow REST Standards for the creation, read, update, and deletion of objects in the database. {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/search" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/catalog/{resource}/{id}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/catalog/{resource}/{id}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/catalog/{resource}/{id}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/catalog/{resource}" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/catalog/provider/{providerId}/{resource}/{id}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/catalog/provider/{providerId}/{resource}/{id}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/catalog/provider/{providerId}/{resource}/{id}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/catalog/provider/{providerId}/{resource}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} # 8.2 Inventory Management Since inventory is a provider-centric feature, it does not interface with a customer. However, it is called by other services like quotation management, order management, and fulfillment management services. {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/search" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/inventory/checkAvailability/{resource}/{id}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/inventory/item/add" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/inventory/item/remove" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/inventory/item/block" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/inventory/addOn/unblock" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/inventory/addOn/block" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/inventory/item/unblock" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} # 8.3 Quotation Management {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/quotation" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} # 8.4 Order Terms Management {% openapi src="/files/ERevkKDJxC6BjwQn1IfF" path="/terms/payment" method="post" %} [beckn-e-marketplace-bb-0.2-resolved (2).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-3c5185df582778847d343441ea8deac3fc51b255%2Fbeckn-e-marketplace-bb-0.2-resolved%20\(2\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/ERevkKDJxC6BjwQn1IfF" path="/terms/fulfillment" method="post" %} [beckn-e-marketplace-bb-0.2-resolved (2).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-3c5185df582778847d343441ea8deac3fc51b255%2Fbeckn-e-marketplace-bb-0.2-resolved%20\(2\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/ERevkKDJxC6BjwQn1IfF" path="/terms/cancellation" method="post" %} [beckn-e-marketplace-bb-0.2-resolved (2).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-3c5185df582778847d343441ea8deac3fc51b255%2Fbeckn-e-marketplace-bb-0.2-resolved%20\(2\).yaml?alt=media) {% endopenapi %} # 8.5 Order Management {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/orders" method="post" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/orders/{orderId}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/orders/{orderId}/updatePayment" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/orders/{orderId}/updateFulfillment" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/orders/{orderId}/updateBilling" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/orders/{orderId}/updateItems" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/orders/{orderId}/updateAddOns" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} {% openapi src="/files/QPP5QioCWLhLgza4xBZK" path="/orders/{orderId}/cancel" method="put" %} [beckn-e-marketplace-bb-0.2-swagger.yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger.yaml?alt=media) {% endopenapi %} # 8.6 Order Fulfillment {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/fulfillments" method="post" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/fulfillments/{fulfillmentId}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/fulfillments/{fulfillmentId}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/fulfillments/{fulfillmentId}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/fulfillment/checkServiceability" method="post" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/fulfillment/{fulfillmentId}/agent/allocate" method="put" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/fulfillment/{fulfillmentId}/agent/deallocate" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} # 8.7 Order Tracking {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/tracking/start" method="post" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/tracking/stop" method="post" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/tracking/{order\_id}/update\_location" method="put" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} # 8.9 Rating and Feedback Management {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/forms" method="post" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/forms/{formId}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/forms/{formId}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/forms/{formId}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/generateFeedbackForRating" method="post" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} # 8.12 Support Management These endpoints enables all customer support services to be managed. {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/support/{orderId}" method="get" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/support/{orderId}" method="post" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/support/{orderId}" method="put" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/support/{orderId}" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/support/{orderId}/agent" method="get" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/support/{orderId}/agent" method="put" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} {% openapi src="/files/O8Tol4WTaojeSQEhz975" path="/support/{orderId}/agent" method="delete" %} [beckn-e-marketplace-bb-0.2-swagger (1).yaml](https://380166226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5BgLPnPwdar5sXTI8dPW%2Fuploads%2Fgit-blob-ca59e8fc5828a20ca2f1f223424f027bb08cb00f%2Fbeckn-e-marketplace-bb-0.2-swagger%20\(1\).yaml?alt=media) {% endopenapi %} # 8.13 Order Lifecycle APIs These APIs are implemented as a beckn protocol endpoint to enable the E-Marketplace BB to become accessible by any consumer application inside or outside the GovStack ecosystem. These APIs are implemented as a beckn protocol endpoint to enable the E-Marketplace BB to become accessible by any consumer application inside or outside the GovStack ecosystem. # 8.13.1 Requests {% openapi src="" path="/search" method="post" %} {% endopenapi %} {% openapi src="" path="/select" method="post" %} {% endopenapi %} {% openapi src="" path="/init" method="post" %} {% endopenapi %} {% openapi src="" path="/confirm" method="post" %} {% endopenapi %} {% openapi src="" path="/status" method="post" %} {% endopenapi %} {% openapi src="" path="/update" method="post" %} {% endopenapi %} {% openapi src="" path="/track" method="post" %} {% endopenapi %} {% openapi src="" path="/cancel" method="post" %} {% endopenapi %} {% openapi src="" path="/rating" method="post" %} {% endopenapi %} {% openapi src="" path="/support" method="post" %} {% endopenapi %} {% openapi src="" path="/get\_rating\_categories" method="post" %} {% endopenapi %} {% openapi src="" path="/get\_return\_reasons" method="post" %} {% endopenapi %} {% openapi src="" path="/get\_cancellation\_reasons" method="post" %} {% endopenapi %} # 8.13.2 Callbacks {% openapi src="" path="/on\_search" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_select" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_init" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_confirm" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_status" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_rating" method="post" %} {% endopenapi %} {% openapi src="" path="/on\_support" method="post" %} {% endopenapi %} {% openapi src="" path="/rating\_categories" method="post" %} {% endopenapi %} {% openapi src="" path="/cancellation\_reasons" method="post" %} {% endopenapi %} {% openapi src="" path="/return\_reasons" method="post" %} {% endopenapi %} # 9 Internal Workflows This section provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases. In this section, we identify workflows to manifest some of the main services. These may be enhanced or customized as needed for specific implementation needs. The following common preconditions may need to be met before utilizing these services: Entities are registered and active in the system. Currently, acting entities will be logged in the system and have sufficient roles to act. The Initiator Building Block and the target block must be registered in the system as network participants with status as subscribed and should be active. This section captures the example workflows that may take place between internal functional blocks to orchestrate key functionalities for a minimum viable product as follows. The exact workflows may be decided depending on implementation time considerations. * User search for product/service from a provider platform. * Viewing an item from the provider catalog. * Inventory management. * Selection of the product. * Initiation of the purchase request. * Confirmation of the order. * Checking the status of the order. * Cancellation of the order. * Tracking of an active order. * Feedback for an order. * support for an order. * Catalog management. ## 9 Order Lifecycle Workflows ### 9.1 Searching for Items The search flow allows consumers to search for available products or services. When a consumer initiates a search request, the catalog providers relevant products or services available respond to the search request by sending back detailed information about their offerings. This includes product details such as descriptions, images, specifications, prices, and any applicable offers or promotions. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Catalog Management end consumer-->>consumer interface: search consumer interface->>Catalog Management:declare search intent Catalog Management->>consumer interface:return catalog consumer interface-->>consumer:view search results" %} ### 9.2 Catalog Management This allows the creation of a catalog for a product or a service based on the request made by the user. This allows users to update the catalogs of a product or service. New attributes can be added or removed from a catalog. Users while searching for products can request the catalog of the product or the services, and the platform will fetch and serve back user with the required catalog. {% @mermaid/diagram content="sequenceDiagram UI->>consumer platform interface: catalog consumer platform interface->>provider platform interface: catalog provider platform interface->>Catalog:catalog provider platform interface->>consumer platform interface: on\_catalog consumer platform interface->>UI: catalog Response" %} ### 9.3 Inventory Management This enables users to manage inventory of the products also they can add or remove products from the inventory. {% @mermaid/diagram content="sequenceDiagram Admin UI->>provider interface: fetch inventory list provider interface->>Inventory: fetch inventory list Inventory->>provider interface: return inventory list provider interface->>Admin UI:Return invetory list" %} ### 9.4 Quotation Management The consumer utilizes the internal workflow within the platform to explore and select from a range of available offers and attributes. These choices have an impact on the pricing, as different combinations can result in varying costs. Once the consumer has made their selections, the consumer platform sends a request to the provider platform. The purpose of this request is to validate the chosen offers and attributes against the provider's system. The provider platform conducts the necessary validation checks to ensure the selected offers and attributes are accurate and permissible. If any discrepancies or changes are identified, the provider platform communicates this information back to the consumer. Upon receiving the feedback from the provider platform, the consumer can review the changes and make any necessary adjustments or confirm the modified selections. This internal workflow allows the consumer to have control and flexibility in selecting offers and attributes, while also ensuring that the provider's systems validate the choices for accuracy and feasibility. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Quotation Management participant Inventory Management end consumer-->>consumer interface: select items
from catalog consumer interface->>Quotation Management:request
quote Quotation Management->>Inventory Management: check availability Inventory Management->>Quotation Management: return availability Quotation Management->>consumer interface:return quote
with breakup consumer interface-->>consumer: view quote
with breakup" %} ### 9.5 Initializing an order by providing billing and fulfillment details The consumer carefully reviews the contents of their cart, ensuring that everything selected is accurate and satisfactory. Once satisfied, the consumer initiates a checkout call, indicating their intention to proceed with the payment. This action finalizes the cart, preventing any further modifications. The consumer platform then sends a request to the provider platform to initialize the payment process for the products or services in the cart. In response, the provider platform generates a payment link and presents the consumer with additional terms and conditions related to the payment. The payment link serves as a gateway for the consumer to complete the transaction securely. It directs them to a designated payment page where they can input their payment information and finalize the purchase. Alongside the payment link, the provider platform communicates any specific terms and conditions associated with the payment, ensuring that the consumer is aware of any applicable fees, refund policies, or other relevant details. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Terms Management participant Inventory Management participant Quotation Management participant Fulfillment Management end consumer-->>consumer interface: provide billing
and fulfillment details consumer interface->>Order Management: initialize
draft order Order Management->>Inventory Management: check availability Inventory Management->>Order Management: return availability Order Management->>Inventory Management: lock inventory Inventory Management->>Order Management: return inventory
lock status Order Management->>Quotation Management: fetch quote Quotation Management->>Order Management: return quote Order Management->>Fulfillment Management: check serviceability Fulfillment Management->>Order Management: return serviceability
with fulfillment charges Order Management->>Terms Management: fetch Payment Terms,
Cancellation Terms,
Fulfillment Terms Order Management->>consumer interface: return draft
order with terms consumer interface-->>consumer:view final order
with checkout link " %} ### 9.6 Confirming an Order Once the consumer receives the payment link and reviews the terms and conditions, they proceed to make a payment. Upon a successful transaction, the consumer platform initiates a confirmation call to the provider platform. This call serves as a notification that the payment has been completed and confirms the order placement. The provider platform acknowledges the confirmation call and responds with a success message. Along with the success message, the provider platform shares the details of the order that has been placed. These order details typically include information such as the order ID, items purchased, quantity, price, and any additional relevant data. The consumer can then utilize the order details received from the provider platform to further check the status of their order. This information allows the consumer to track the progress of their order, anticipate the delivery, and stay informed about any updates or changes related to the order. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Fulfillment Management participant Payment BB Interface participant E-Signature BB Interface end consumer-->>consumer interface: checkout consumer interface->>Payment BB Interface: pay for order consumer interface->>E-Signature BB Interface:sign order consumer interface->>Order Management:confirm order Order Management->>E-Signature BB Interface:verify signature Order Management->>Order Management: Create Order Order Management->>Fulfillment Management: check serviceability Order Management->>E-Signature BB Interface:sign order Order Management->>consumer interface: Return Confirmed Order consumer interface->>E-Signature BB Interface:verify signature consumer interface-->>consumer:view confirmed order " %} ### 9.7 Checking the status of an order Once an order is confirmed, the user receives the details of the confirmed order, and they have the option to check the status of their order. The order status typically includes stages such as "placed," "packed," "dispatched," and so on. The "placed" status indicates that the order has been successfully received and recorded. The "packed" status signifies that the items in the order have been gathered and prepared for shipment. The "dispatched" status indicates that the package has been handed over to the delivery service for transportation. #### 9.7.1 User explicitly requests for the fulfillment status of the order {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Fulfillment Management end consumer-->>consumer interface: view order consumer interface->>Order Management:get order status Order Management->>Fulfillment Management:fetch fulfillment state Fulfillment Management->>Order Management: return current status
of fulfillment Order Management->>consumer interface: return latest order state consumer interface-->>consumer: display latest status of order" %} #### 9.7.2 Provider's Agent asynchronously updates the fulfillment status of an order at their end {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Fulfillment Management end participant Agent Interface Actor Agent Agent -->> Agent Interface: update fulfillment status Agent Interface-->>Fulfillment Management: Update fulfillment status Fulfillment Management->>Order Management: update current status
of fulfillment Order Management->>consumer interface: return latest order state consumer interface-->>consumer: display latest status of order" %} ### 9.8 Tracking the fulfillment of an order When a consumer places an order and it is confirmed, they are provided with the option to track the status of their order. This tracking feature allows the consumer to stay informed about the progress of their purchase. The order status typically encompasses various updates related to the delivery process, giving the consumer insights into the whereabouts and estimated arrival time of their package. One of the primary aspects of the order status is the delivery status, which indicates whether the package has been dispatched from the provider's location or the warehouse. It confirms that the order is on its way to the consumer. This status assures the consumer that their purchase is in the process of being delivered. #### 9.8.1 Update Agent's tracking information Users can update the tracking status of an order. {% @mermaid/diagram content="sequenceDiagram box E-Marketplace BB participant Tracking Management end participant Agent interface Actor Agent loop periodically Agent-->>Agent interface: generate tracking data Agent interface->>Tracking Management: push tracking data end" %} #### 9.8.2 Tracking an order Users can request to get the tracking status of an order. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Tracking Management end consumer-->>consumer interface: track order consumer interface->>Order Management: track order Order Management->>Tracking Management: track order Order Management->> Tracking Management: fetch tracking link Order Management->> consumer interface: send tracking link consumer interface-->>consumer: render real-time
tracking screen consumer interface-->>Tracking Management: start tracking Tracking Management-->>consumer interface: stream real-time tracking data consumer interface-->>consumer: view real-time
tracking data " %} ### 9.9 Updating an Order #### 9.9.1 Consumer-initiated update {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Terms Management participant Fulfillment Management participant Payment BB Interface end consumer-->>consumer interface: provide updated information consumer interface->>Order Management:update order Order Management->>Terms Management:validate
update terms Terms Management->>Order Management: return
update charges Order Management->>Fulfillment Management:update fulfillment Order Management->>consumer interface: return updated order consumer interface-->>consumer: display update
order with
update charges Order Management->>Payment BB Interface: Initiate Payment / Refund" %} #### 9.9.2 Provider Initiated Update {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Fulfillment Management participant Payment BB Interface end participant Agent interface Actor Agent Agent-->>Agent interface: update order information Agent interface->>Fulfillment Management:update order state Fulfillment Management->>Order Management:update fulfillment Order Management->>consumer interface: send updated order consumer interface-->>consumer: display updated
order Order Management->>Payment BB Interface: (Optionally) Initiate Refund
to consumer" %} ### 9.10 Cancelling an Order When a consumer places an order and it is confirmed, they are provided with the option to cancel their order. This will allow the user to cancel the order before receiving an order. #### 9.10.1 Consumer initiated cancellation {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Terms Management participant Fulfillment Management participant Payment BB Interface end consumer-->>consumer interface: cancel order consumer interface->>Order Management:cancel order with reason Order Management->>Terms Management:validate
cancellation terms Terms Management->>Order Management: return
cancellation charges Order Management->>Fulfillment Management:cancel fulfillment Order Management->>consumer interface: return cancelled order consumer interface-->>consumer: display cancelled
order with
cancellation fees Order Management->>Payment BB Interface: Initiate Refund" %} #### 9.10.2 Provider Initiated Cancellation {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Order Management participant Terms Management participant Fulfillment Management participant Payment BB Interface end participant Agent interface Actor Agent Agent-->>Agent interface: cancel fulfillment Agent interface->>Fulfillment Management:cancel fulfillment with reason Fulfillment Management->>Order Management:cancel fulfillment Order Management->>consumer interface: return cancelled order consumer interface-->>consumer: display cancelled
order with
cancellation fees Order Management->>Payment BB Interface: Initiate Refund
to consumer " %} ### 9.11 Rating and Feedback Management This allows users to rate any rate-able entity in the system, it can be a product, service, agent, etc. Users can also provide detailed feedback on the entities. #### 9.11.1 Rating an Order (without feedback) {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Rating Management end consumer interface->>Rating Management: fetch rateable entities Rating Management->>consumer interface: Return rateable entities consumer-->>consumer interface: provide rating consumer interface->>Rating Management: rate entity Rating Management->>consumer interface: Acknowledge rating " %} #### 9.11.2 Rating an order with feedback {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Rating Management participant Feedback Management end consumer interface->>Rating Management: fetch rateable entities Rating Management->>consumer interface: Return rateable entities consumer-->>consumer interface: provide rating consumer interface->>Rating Management: rate entity Rating Management->>Feedback Management: fetch form link Rating Management->>consumer interface: Acknowledge rating with
link to feedback form consumer interface-->>consumer: Display feedback form consumer-->>consumer interface: provide feedback consumer interface->>Feedback Management: Submit feedback Feedback Management->>consumer interface: Acknowledge feedback" %} ### 9.12 Support Management Users can request support, this can happen anytime during the lifecycle of an order. {% @mermaid/diagram content="sequenceDiagram Actor consumer participant consumer interface box E-Marketplace BB participant Support Management participant Order Management end participant Customer Support Interface Actor customer support executive consumer-->>consumer interface: contact support consumer interface->>Support Management: fetch support info Support Management->>Order Management: fetch order Order Management->>Support Management: order details Support Management->> consumer interface: send support center info consumer interface-->>consumer: render support
center screen consumer interface->>Support Management: start chat session Support Management->>Support Management: Allocate executive Support Management->>Customer Support Interface: Notify executive Customer Support Interface-->>customer support executive: Open chat session Customer Support Interface-->>consumer interface: stream real-time chat data consumer interface-->>Customer Support Interface: stream real-time chat data " %} # 10 Other Resources This section links to any external documents that may be relevant, such as standards documents or other descriptions of this Building Block that may be useful. ## 10.1 Example Cross-Building Block Workflows Some common workflows that leverage the eMarketplace Building Block can be found here: [https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/em-b2g-uc2-sgp-sporting-goods-purchase](https://github.com/GovStackWorkingGroup/bb-emarketplace/blob/23Q4/spec/broken-reference/README.md) [https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/em-g2p-uc2-online-reservation-system-ors](https://github.com/GovStackWorkingGroup/bb-emarketplace/blob/23Q4/spec/broken-reference/README.md) [https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/em-g2p-uc3-government-auctions-marketplace-gam](https://github.com/GovStackWorkingGroup/bb-emarketplace/blob/23Q4/spec/broken-reference/README.md) ## 10.2 Key Decision Log NA ## 10.3 Future Considerations The E-Marketplace Building Block is agnostic to all forms of economic transactions. It provides a generic framework that standardizes any consumer-provider interaction like discovery, ordering, fulfillment and post-fulfillment. Due to its abstracted nature, it may be adapted to any use case. However, for the sake of simplicity, the use cases covered in this scope, especially in the case of procurements (B2G), assume that the suppliers (businesses) are already vetted and empanelled by the buyer. The actual process of proposal, evaluation, and awarding of contract though adaptable to the generic framework is kept out of scope for the sake of simplicity. These features will be included later in future versions of the specification as and when diverse procurement use cases from across the globe and across domains are considered, abstracted and adapted to this framework. # EM-G2P-UC2-Online Reservation System (ORS) ## eM-G2P-UC2-Online Reservation System (ORS) #### MKT-G2P-UC2-ORS-Online Reservation System **Product Use Case Summary** | ID | MKT | | ------- | ------------------------- | | Name | Online Reservation System | | Sector | Government Marketplace | | Version | 1.0 | | Status | Draft | This use case explain the three broad steps in booking a doctor's appointment by a citizen. The three steps included are (1) Citizen's registration (2) Hospital Staff Registration (3) Booking a doctors appointment by a citizen. The ORS service involves a health application consisting of registered hospitals with various departmental services in it pooled across multiple cities in a state or a country. A citizen can choose to select a service in a particular hospital and book an appointment. Then, the citizen can visit the hospital as per the appointment time and seek medicine receipts/diagnostic services, if any, into his/her registered account. A citizen can avail deemed social benefits as per eligible criterian defined by the government. For example, a citizen can choose to scroll through nearest town/city, select a general or specialized government hospital (for ex. Cancer hospital) and then select a department (oncology) and see who all doctors/slots are available; and then book an appointment as per their convenience. Once the appointment is booked, the citizen receives confirmation details and visits the hospital to consult the doctor. If the doctor suggests any prescription, the same is uploaded into citizen's account by hospital staff-which can be shown across medical shops to get medicine. Nominal fee payments, receiving of medical aid in terms of cash etc. are not considered in this case study. #### **SDG Targets​** 12.7: Promote public procurement practices that are sustainable, in accordance with national policies and priorities 12.7.1: Number of countries implementing Sustainable Public Procurement policies and action plans **3.7 By 2030, ensure universal access to sexual and reproductive health-care services, including for family planning, information and education, and the integration of reproductive health into national strategies and programmes.** **3.8 Achieve universal health coverage, including financial risk protection, access to quality essential health-care services and access to safe, effective, quality and affordable essential medicines and vaccines for all.** #### **Building Blocks​** 1. Consent 2. Identification and Verification 3. Messaging 4. Registration 5. Scheduling 6. Information Mediator 7. Work flow and Algorithm 8. Registries Future building blocks inclusion * Payments * UI/UX * Analytics and Business Intelligence * Artificial Intelligence (AI) * Geographic Information Services (GIS) ​Steps1 - Outreach Communications Staff from the Ministry of Health or another leading agency / organization organizes an information awareness campaign about booking health appointments and its benefits through ORS through various channels of communication via mobile messaging and/or aired on national radio/television, internet, social media. Outreach communication is intensive during the kick-off phase of the new programme, but also requires ongoing touchpoints and additional information sharing, e.g. on grievance redressal, rights and responsibilities, behavioural change communication, etc. Workflows * **Client communication** to facilitate the spreading of programme awareness for target audience and encouraging enrolment via mobile,web, kiosk, media channel(s) * Client education for educating potential target beneficiaries around the approach and objective(s), benefit(s), constraint(s), partner(s), etc. of the programme * **Content management** for the backend Health department and stakeholder staff to populate relevant educational and promotional content that local officers can use during on-the-ground outreach campaigns * **Identification and Registration** (with aid of geographic information services tool for potential use) in mapping and locating households and individuals for outreach target **Example Implementation** To do **Building Blocks​** Messaging ​Scheduling Information Mediation \*\*2 - Registration, \*\***Identification and Verification** Registration is the process of collecting information of stakeholders such as citizens and hospital staff, in this use case. Depending on specific grography context, registration works in very different ways – either through self registration, on-demand at local hospitals (either approach potentially building on interoperability existing data sources) or single admin registration of hospital staff. While the practicalities of data collection differ across the types, with very different implications for data quality, currency and completeness, the underlying digital processes are broadly the same. A self registration involves providing data inputs by the citizen while the on-demand registration will facilitate the same services for the individuals who might not be able to help themselves. Further, an adminstrator of hospital may also choose to enrol/register all the doctors details (for example), on behalf of them. The data registered can be saved into type of registries (for example, citizens, hospital staff registries, hospitals registry, cities registry, departments registry) and can be accessed to collect, organize, store, process, transform, create, and distribute information necessary to support intake and registration of potential beneficiaries (gateway function). **Workflows** **Data Collection and Reporting** for capturing interview responses or observations during registration process **Identification and Registration** for enrolled identified beneficiaries in the system and enabling possible permissions for interaction with the Health Application, and (with aid of geographic information services tool) to potentially locate and track households during the interview process **Client Case Management** for creating beneficiary user records **Example Implementation** [Citizen Registration](#g2p-uc2-ors-s1-citizen-registration) [Hospital Staff Registration](#g2p-uc2-ors-s2-hospitalstaff-registration) **Building Blocks** ​Consent​ Registration​​ Registries Identity and Verification Information Mediation Messaging **3 - Booking a doctor's apointment** This is a key process of the use case where a citizen access the health application (ORS) and books an appointment. The process involves a citizen visiting a catalogue of cities, government hospitals in each city; and selects a department (for example: neurology) in a selected hospitals and books a doctor's appointment at a scheduled slot. Once the citizen visits the hospital, their appointment is reconfirmed and entitlements, if any, are verified by the hospital staff. The doctor, upon completion of diagnosis, can direct the staff to upload the prescriptions, diagnosis results in the same account of the citizen so that the citizen can show case the same to receive medicine and to store the health hisory. **Workflows** **Cross verification** of citizen appointment details when the later visits the hospital **Catalogue of services** The citizen should be able to select a service under a department of a hospital in a city **Client Case Management** for determining and assigning benefit packages and benefit levels to specific user groups **Data Analysis and Business Intelligence** / Decision Support potentially for identifying different benefit levels / types in correlation to target groups’ socioeconomic / demographic information, based on existing eligibility criteria **Document Management** that uploads/stores the prescriptions, diagnosis results by the hospital staff **Scheduling** The time slot shall get updated automatically whenever a slot is booked or when the slot is cancelled. It shall also communicate the appointment details to citizen and to the hospital staff. **Example Implementation** [Booking an appointment](#g2p-uc2-ors-s3-bookingdoctorsappointment) **Building Blocks** ​Identity and Verification Consent Information Mediation Digital Registries Registration Scheduling UI/UX Messaging Client Case Management Analytics and Business Intelligence **Outputs** 1. The citizen is able to successfully register a doctor's appointment in a government hospital **Failure Points** 1. Internet connectivity 2. Lack of awareness 3. Technical failure of the application ## G2P-UC2-ORS-S1-Citizen Registration | Use Case Step | Self-Registration of citizen (how about Mee-Seva channels?) | | --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) |
  • The citizen has already registered in a national identification system (IDBB) and has a unique electronic identity/social protection number to register an account and to avail related benefits/schemes offered by the government.
  • Good internet connectivity, access channels (web/mobile/kiosk) shall be available.
  • Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (consent) and respective REST API services in Information Mediator have been opened to Registration BB.
  • The citizen owns the identity proof (card, QR code, ID number, etc) available together with the required credentials for the healthcare platform that can be verified and authenticated with the national ID system.
| | Data inputs |
  • Name, Age, Gender of the citizen
  • National ID number of the citizen
  • Electronic Health Record(HER) number
  • Registered mobile number
  • Captcha Chat/non-robot verification
  • OTP
  • Permanent address details (Door number, Lane, PIN, City, State, Nation)
| | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) |

Human: CitizenSystem:

  • Healthcare platform application
  • Digital Registries BB/(EHR)
  • Registration BB
  • Identity BB
  • Consent BB
  • Messaging BB
  • Information Mediator BB
  • National Population Registry (Digital Registries BB or Identity BB)
| | Normal Course (what happens if the event is triggered and the preconditions have been met) |

The registration form screen for the Healthcare application provides a list of initial details required to proceed with the registration (eligibility verification, required documents such as national ID/EHR proof).Step 1: The citizen enters the required initial details, including, but not limited to the following:

  1. 1.Citizen’s National ID number
  2. 2.Name of the Citizen
  3. 3.Date of Birth
  4. 4.Gender at Birth
  5. 5.Address details
  6. 6.Mobile number
  7. 7.
  8. 8.The application shall seek the consent of the citizen to retrieve additional data from multiple registries.
  9. 9.

Feature: Get Consent AgreementScenario: Healthcare Application retrieves Consent Agreement for citizenGiven an Agreement citizen registration that exists in Consent BBAnd Healthcare Application has Citizen’s \ and authentication token for the registration sessionWhen Healthcare application fetches a Consent Agreement for Citizen registrationThen Healthcare application gets a valid Draft Consent Agreement associated with Citizen's IDAPI EndpointsStep 2: The health Application introduces to the citizen the Consent Agreement for fetching the relevant details from the Population registry (Should it check with EHR also?) for verification and appropriate use with the health application and captures signature to the Consent Agreement from the citizen.Feature: Sign Consent RecordBackground:Given Health Application has the Draft Consent Agreement associated with Citizen's ID and authentication token for the registration sessionAnd Citizen has read the Draft Consent AgreementAnd Citizen approves to sign the Draft Consent Agreement associated with Citizen's ID (What language and what if the citizen does not agree?)Scenario: Sign Consent Record on PaperGiven Health application has captured the consent in a digital form (for example: scan of a paper form)When Health application sends digital Consent Record payload to Consent BBThen Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Citizen has been successfully signedScenario: Sign Consent Record DigitallyGiven Citizen has capability to sign Consent Record digitallyWhen Health Application sends the Draft Consent Agreement to Consent BBThen Consent BB creates a paired ConsentRecord and Signature objectAnd Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Citizen has been successfully signedAPI EndpointsStep 3: The Health application form submits the national ID number to the Population registry hosted in the IDBB/Digital Registries BB seeking relevant details of the Citizen, by invoking the API “Data read value” on the Govstack Digital Registries BB.This scenario uses a set of features:

  • Verify Consent Record by Consent BB
  • Import data from a registry by Registry BB

Feature: Verify Consent RecordHealth Application verifies if Citizen has signed Consent Record to fetch the needed personal data from Population registry for Health Application user registrationScenario: Retrieve valid Consent RecordGiven Citizen has Signed Consent Record stored in Consent BBWhen Health Application makes the request to population registry API to fetch Citizen's personal dataThen Health Application makes prior request to Consent BB API to retrieve Citizen's Signed Consent RecordAnd Consent BB sends the signed Consent Record to Health ApplicationFeature: Imports client personal data from a registryImport Citizen's personal information from Population Registry to the e-service formGiven Citizen has entered \ in the Registration e-service registration form, national ID number fieldAnd Health Application has received Signed Consent Record from Consent BBWhen the Health Application user pushes a button "Import Citizen's information"Then the Health Application makes a request to Population Registry APIAnd Population Registry returns requested data to Health ApplicationAnd Health Application fills the form on the screen with Citizen’s data \,\, \, \Examples:

| | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) |

If the Citizen does not possess a national ID, the registration application needs to provide an alternate mechanism for <>GetIdentityProfile – elaborate

  1. 1.If the consent record is previously created and available, the registration application should fetch the consent agreement by invoking the API: “serviceListIndividualRecord” on the Govstack Consent BB

“GET /dataconsumer/consent/”

| | Data output | The successful completion of the citizen registration process will result in confirmation and issuance of a program-specific ID that can be used by the citizen for future interactions with the program.Expected data from Registration BB | | Post-Conditions (the success criteria) | The citizen has registered in the Health Application registry. | | Exceptions(error situations) |
  • A citizen can be only registered once in Health Application. The system must prevent multiple registrations.
  • Provide details on exception code and message
  • Mitigation steps: Describe steps to be taken by the actors
  • If the citizen has entered incorrect information then the Health Application inform the citizen to check/validate the same.
  • Provide details on exception code and message
  • Mitigation steps: Describe steps to be taken by the actors
  • If Identity BB or Consent BB is not available (service outage), then …..
  • Mitigation steps: Describe steps to be taken by the actors
  • If no internet, then the system is not available and information must be collected on paper forms or on offline data capturing devices.
  • Mitigation steps: Describe steps to be taken by the actors
| | Related BBs(working groups related to this example implementation) |
  • Identity BB
  • Consent BB
  • Registration BB
  • Digital Registries BB
| ## G2P-UC2-ORS-S2-HospitalStaff Registration USE CASE: Booking a doctor’s appointment on a Government healthcare platform | Use Case Step | Hospital Staff Registration by a system administrator | | --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) | · The staff is an identified and registered person with a hospital; and is registered in a national identification system (IDBB) with a unique electronic identity number.· The role of the staff is clearly pre-defined and is mapped to a department by the hospital. For example, a doctor, a diagnostic officer, radiologist, document uploader, bill clearance officer etc.· Good internet connectivity, access channels (web/mobile/kiosk) shall be available.· Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (consent) and respective REST API services in Information Mediator have been opened to Registration BB. | | Data inputs | · Name, Age, Gender of the Staff· National ID number of the Staff· Registered mobile number· Captcha Chat/non-robot verification· OTP· Permanent address details (Door number, Lane, PIN, City, State, Nation) | | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: Staff membersSystem:· Healthcare platform application· Digital Registries BB (Hospital staff)· Registration BB· Identity BB· Consent BB· Messaging BB· Information Mediator BB· National Population Registry (Digital Registries BB or Identity BB) | | Normal Course (what happens if the event is triggered and the preconditions have been met) | The registration form screen for the Healthcare application provides a list of initial details required to proceed with the registration (eligibility verification, required documents such as national ID/Staff ID).Step 1: The staff enters the required initial details, including, but not limited to the following:1. Staff’s National ID number / Staff’s ID in the hospital2. Name of the Staff3. Date of Birth4. Gender at Birth5. Address details6. Mobile number​The application shall seek the consent of the staff to retrieve additional data from multiple registries.​Feature: Get Consent AgreementScenario: Healthcare Application retrieves Consent Agreement for StaffGiven an Agreement Staff registration that exists in Consent BBAnd Healthcare Application has Staff’s \ and authentication token for the registration sessionWhen Healthcare application fetches a Consent Agreement for Staff registrationThen Healthcare application gets a valid Draft Consent Agreement associated with Staff's IDAPI EndpointsStep 2: The health Application introduces to the Staff the Consent Agreement for fetching the relevant details from the Population/Staff registry for verification and appropriate use with the health application and captures signature to the Consent Agreement from the Staff.Feature: Sign Consent RecordBackground:Given Health Application has the Draft Consent Agreement associated with Staff's ID and authentication token for the registration sessionAnd Staff has read the Draft Consent AgreementAnd Staff approves to sign the Draft Consent Agreement associated with Staff’s IDScenario: Sign Consent Record on PaperGiven Health application has captured the consent in a digital form (for example: scan of a paper form)When Health application sends digital Consent Record payload to Consent BBThen Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Staff has been successfully signedScenario: Sign Consent Record DigitallyGiven Staff has capability to sign Consent Record digitallyWhen Health Application sends the Draft Consent Agreement to Consent BBThen Consent BB creates a paired ConsentRecord and Signature objectAnd Consent BB digitally signs Consent RecordAnd Consent BB confirms to Health Application that Consent Record for Staff has been successfully signedAPI EndpointsStep 3: The Health application form submits the national ID number to the Population registry hosted in the IDBB/Digital Registries BB seeking relevant details of the Staff, by invoking the API “Data read value” on the Govstack Digital Registries BB.This scenario uses a set of features:· Verify Consent Record by Consent BB· Import data from a registry by Registry BB·Feature: Verify Consent RecordHealth Application verifies if Staff has signed Consent Record to fetch the needed personal data from Population registry for Health Application user registrationScenario: Retrieve valid Consent RecordGiven Staff has Signed Consent Record stored in Consent BBWhen Health Application makes the request to population registry API to fetch Staff's personal dataThen Health Application makes prior request to Consent BB API to retrieve Staff's Signed Consent RecordAnd Consent BB sends the signed Consent Record to Health ApplicationFeature: Imports client personal data from a registryImport Staff's personal information from Population Registry to the e-service formGiven Staff has entered \ in the Registration e-service registration form, national ID number fieldAnd Health Application has received Signed Consent Record from Consent BBWhen the Health Application user pushes a button "Import Staff's information"Then the Health Application makes a request to Staff Registry APIAnd StaffRegistry returns requested data to Health ApplicationAnd Health Application fills the form on the screen with Staff’s data \,\, \, \Examples:\|ID\|first\|last\|birth\|\|32\|Aparna\|Vijay\|2023-03-17\|In response, the Govstack IDBB/ Digital Registries BB is expected to return the following:Data returned from Registry | | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | If the Staff does not possess a national ID, the registration application needs to provide an alternate mechanism for \GetIdentityProfile – elaborate1. If the consent record is previously created and available, the registration application should fetch the consent agreement by invoking the API: “serviceListIndividualRecord” on the Govstack Consent BB“GET /dataconsumer/consent/” | | Data output | The successful completion of the Staff registration process will result in confirmation and issuance of a program-specific ID that can be used by the Staff for future interactions with the program.Expected data from Registration BB | | Post-Conditions (the success criteria) | The Staff has registered in the Health Application registry. | | Exceptions(error situations) | · A Staff can be only registered once in Health Application. The system must prevent multiple registrations.o Provide details on exception code and messageo *Mitigation steps:* Describe steps to be taken by the actorso· If the Staff has entered incorrect information then the Health Application inform the Staff to check/validate the same.o Provide details on exception code and messageo *Mitigation steps:* Describe steps to be taken by the actorso· If Identity BB or Consent BB is not available (service outage), then …..o *Mitigation steps:* Describe steps to be taken by the actorso· If no internet, then the system is not available and information must be collected on paper forms or on offline data capturing devices.o *Mitigation steps:* Describe steps to be taken by the actors | | Related BBs(working groups related to this example implementation) | · Identity BB· Consent BB· Registration BB· Digital Registries BB· IM BB | ## G2P-UC2-ORS-S3-BookingDoctorsAppointment | Use Case Step | Booking a doctor’s appointment in the Health Application | | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) |
  • The citizen has already registered/created an account in the health application portal.
  • Good internet connectivity, access channels (web/mobile/kiosk) are available.
  • The citizen owns the identity proof (card, QR code, ID number, etc), mobile phone available together with the required credentials for the healthcare platform that can be verified and authenticated with the Health Application registry.
| | Data inputs |
  • Username, Password
  • National ID number of the citizen
  • Electronic Health Record(EHR) number
  • Registered mobile number
  • Captcha Chat/non-robot verification
  • OTP
| | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) |

Human: CitizenSystem:

  • Healthcare platform application
  • Digital Registries BB/(EHR)
  • Registration BB
  • Identity BB
  • Consent BB
  • Messaging BB
  • Information Mediator BB
  • National Population Registry (Digital Registries BB or Identity BB)
  • Scheduler BB
  • UI/UX BB
| | Normal Course (what happens if the event is triggered and the preconditions have been met) |

Once the user logs-in, the user should be able to search for list of hospitals, different services under each hospital, select the health service, upload documents (if necessary) and get a confirmation of the appointment.Step 1: The citizen enters the required initial details, including, but not limited to the following:

  1. 1.Username, password, Captcha, Mobile number, OTP
  2. 2.The application shall input the entered data, validate, and logs into the Health Application home page.

Feature: Verify and validate the citizen account detailsScenario: Healthcare Application retrieves citizen details from Health Application Registry.Given an Agreement citizen registration that exists in Consent BBAnd Healthcare Application has Citizen’s \ and authentication token for the registration sessionWhen Healthcare application fetches a valid Health Application Account IDThen Healthcare application successfully logs in the citizen​Step 2: The citizen searches for health care providers in a particular cityThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government.The validated citizen ID/session ID fetches the details from \, and \ with multiple filters.Feature: Catalogue Search for identifying cities and healthcare providersBackground:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Search for CitiesGiven Health application account ID/Session ID has been presented with catalogue of citiesWhen Health application account ID/Session ID selects a city from the Cities RegistryThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Cities Registry details are fetched successfullyScenario: Search for Hospital/ClinicGiven Health application account ID/Session ID has been presented with catalogue of citiesWhen Health application account ID/Session ID selects a city from the Cities RegistryAnd the \ fetches all the hospitals and clinics under the selected citiesThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital and Clinics details under Cities Registry are fetched successfully​Step 3: The citizen views a catalogue of hospitals and clinics in the city and selects the department for which the appointment is requiredThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government.The validated citizen ID/session ID fetches the details from \, \, with multiple filters; which are under \ and \.Feature: Catalogue Search for identifying departments and services (for example: Department of Neurology associated with Brain, Spine, Peripheral nerves, muscles related services etc.), with multiple filters.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in session ; and has been presented with details of \ and \Scenario: Search for Departments in a hospitalGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitalsWhen Health application account ID/Session ID selects a hospital from the Hospitals RegistryThen IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Departments Registry details are fetched successfullyScenario: Search for a serviceGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departmentsWhen Health application account ID/Session ID selects a service from the Services RegistryAnd the \ fetches all the services under the Departments in a hospital in a city.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services details in a City are fetched successfully​Step 4: The citizen views available appointment slots in the calendar published by the particular hospitalThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals and clinics approved by the government. The citizen selects a city, health provider, department and a service.The validated citizen ID/session ID fetches the details from \, \, \, \, with multiple filters.Feature: Catalogue Search for appointment slot and its selectionBackground:Given Health Application/Session ID has the Health Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Search for appointment slots in the catalogueGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departmentsWhen Health application account ID/Session ID selects a service from the Services RegistryAnd the \ fetches all the services under the Departments in a hospital in a cityAnd a Catalogue of Appointment slots \ are fetched successfully.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Scheduler BB time slots details in a City are fetched successfullyScenario: Citizen selects and confirms a slot.Given Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, servicesWhen Health application account ID/Session ID selects a service from the Scheduler BBs catalogue/Time capabilityAnd the < Scheduler BB> fetches all the available slots for a service under the Departments in a hospital in a cityAnd a slot is selected, the details are communicated to Messaging BB successfully.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details are communicated to Scheduler BB, “Messaging BB” through IM BB.​Step 5: The citizen receives appointment details and the quoteThe Health Application introduces to the citizen a catalogue with filters/options consisting of cities, list of hospitals, departments, services, appointment slots.The validated citizen ID/session ID fetches the details from \, \, \, \, with multiple filters.Feature: The “Appointment” details are fetched from Scheduler BB and a quote (to submit additional information/time confirmation/pre-validation by citizen) is provided for citizen’s confirmation.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Receive appointment details on Application UI/UXGiven Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, services, appointment/time capabilityWhen Health application account ID/Session ID selects a service time slot from the Scheduler BBsAnd the < Scheduler BBs > is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB.Then IM BB fetches the payload from Messaging BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details from Scheduler BB are communicated to “Messaging BB” and then to UI/UX BB.​Step 6: The citizen accepts the quote and shares the medical information history required for the appointmentThe citizen has been provided with appointment details, a quote to share additional but optional information.Feature: The “Appointment” details are fetched and a quote (to submit additional information/time confirmation/pre-validation by citizen) is provided for citizen’s confirmation.Background:Given Health Application/Session ID has the Application ID details associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Citizen shares additional details and then confirms the appointment.Given Health application account ID/Session ID has been presented with catalogue of cities, hospitals, departments, services, appointment/time capabilityWhen Health application account ID/Session ID selects a service from the Scheduler BBs catalogue of appointment slots.And the \ is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB for validation and to share/affix additional details. Citizen updates the details (optional) and confirms the appointment details.Then IM BB fetches the payload from Messaging BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Health application account ID/Session ID confirms to Health Application that Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details are communicated to “Messaging BB” and then to UI/UX BB. The Registration BB is updated with new data (quotes) through Messaging BB and IM BB. Scheduler BB is updated. Appointment ID is updated in Health Application Account ID. The session is closed.​Step 7: The hospital staff validates the citizen’s appointment and consultation with the doctorThe citizen has been provided with appointment details, a quote to share additional but optional information. The citizen confirms the appointment and receives the appointment details via paper or SMS.Feature: Citizen visits the hospital on the scheduled time and the “Appointment”, received through a paper or SMS, is utilized.Background:The hospital staff members cross checks the Appointment ID, Account ID, Citizen ID using UI/UX BB, Scheduler BB, Registration BB, Registries BB.Scenario: Citizen visits the hospital and hospital staff checks the appointment detailsCitizen shares the appointment details (Paper/SMS) with the hospital staff. The Staff logs-in to the portal and verifies and validates the appointment, citizen details.When Staff ID/Session ID selects an appointment ID from the UI/UX, Scheduler BBsAnd the < Appointment slot> is selected; the appointment and citizen details are communicated to IM BB and Scheduler BB and then to UI/UX BB for validation. Staff confirms the appointment details.Then IM BB fetches the payload from Scheduler BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Staff account ID/Session ID confirms to Staff Account that Citizen Health Application Account details, Hospital, Clinics, Departments, Services, Appointment time slots details in a City are fetched successfully and the selected slot details and citizen details are validated successfully.​Step 8: The Hospital updates the prescriptions, diagnosis to the citizen in the Health ApplicationThe citizen has visited the doctor and was advised some measures, medicines, diagnostics. The prescription and the in-house diagnostic services results are updated by the hospital staff in the patient registry associated with hospital account application ID of the citizen.Feature: The hospital staff uploads the prescriptions and diagnostics results of a citizen.Background:Given Staff ID/Session ID has the Health Application Account ID associated with Citizen's ID and authentication token of the registration/log-in sessionScenario: Citizen shares the prescription with the staff after undergoing in-house diagnostic services with results.Given Staff ID/Session ID has been presented with the Patients RegistriesWhen Staff ID/Session ID selects a Hospital Account ID/Citizen IDAnd the < Patients Registry> is selected; the details are communicated to Messaging BB successfully and then to UI/UX BB. Staff updates/uploads the medicine advise/test result details (optional) associated with patients.Then IM BB fetches the payload from Registries BB (Does Dashboard & Analytics BB involves here? /Future use/scope?)And Staff ID/Session ID confirms to Health Application that Health Account ID associated with Citizen ID are fetched successfully and the test results (optional) and prescriptions are communicated to “IM BB” and then to UI/UX BB. The Registration BB is updated with new data (prescription/test results) through Messaging BB and IM BB. Patients Registry is updated.In response, the Govstack IDBB/ Digital Registries BB is expected to return the following: Data returned from Patients Registry

| | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) |

If the Citizen does not possess a national ID, the registration application needs to provide an alternate mechanism for <>GetIdentityProfile – elaborate

  1. 1.If the consent record is previously created and available, the registration application should fetch the consent agreement by invoking the API: “serviceListIndividualRecord” on the Govstack Consent BB

“GET /dataconsumer/consent/”

| | Data output | The successful completion of the citizen appointment process will result in confirmation and issuance of a Appointment ID that can be used by the citizen for future interactions with the hospital.Expected data from Registration BB | | Post-Conditions (the success criteria) | The citizen has booked an appointment successfully in the Health Application. | | Exceptions(error situations) |
  • A citizen can book multiple appointments (but not at same time) in Health Application. The system must provision this.
  • Provide details on exception code and message
  • Mitigation steps: Describe steps to be taken by the actors
  • If the citizen has entered incorrect information then the Health Application inform the citizen to check/validate the same.
  • Provide details on exception code and message
  • Mitigation steps: Describe steps to be taken by the actors
  • If Identity BB or Consent BB is not available (service outage), then …..
  • Mitigation steps: Describe steps to be taken by the actors
  • If no internet, then the system is not available and information must be collected on paper forms or on offline data capturing devices.
  • Mitigation steps: Describe steps to be taken by the actors

If the citizen does not find a required department/services then either “general physician” or “This service is not available at this hospital” message shall be displayed.If the appointment slots in a day are over the application and or Scheduler BB should make a suggestion such “There are no slots available for today” / “Please book your appointment on the next available day”

| | Related BBs(working groups related to this example implementation) |
  • Identity BB
  • Consent BB
  • Registration BB
  • Digital Registries BB
  • Scheduler BB
  • Messaging BB
  • UI/UX BB
| # EM-G2P-UC3-Government Auctions Marketplace (GAM) ## eM-G2P-UC3-Government Auctions Marketplace (GAM) #### MKT-G2P-UC3-GAM-Government Auctions Marketplace **Product Use Case Summary** | ID | MKT | | ------- | ------------------------------- | | Name | Government Auctions Marketplace | | Sector | Government Marketplace | | Version | 1.0 | | Status | Draft | This use case streamlines the process of selling surplus government property, making it easier for both the government agency to dispose of property it no longer needs and generate revenue, and for buyers to find and purchase a property. This use case involves the process of a government agency identifying property it no longer needs and transferring it to a centralized platform for disposal. The property is listed on the platform and promoted to potential buyers. Interested registered buyers bid on the property and the highest bidder is awarded the property. Finally, the buyer then pays for and takes possession of the property. The use case steps are 1. **Identifying property** Government agency identifies the surplus property it no longer needs 2. **Transferring property** Government agency transfers the property to Surplus Property Management Office (SPMO) 3. **Listing property** Surplus Property Management Office lists the property on the Surplus Property Auctions marketplace 4. **Bidding on property** Registered bidders bid on the property 5. **Awarding property** The highest bidder is awarded the property 6. **Transfer of property** The buyer takes possession of the property #### SDG Targets **Target 8.2** Achieve higher levels of economic productivity through diversification, technological upgrading, and innovation, including through a focus on high-value-added and labour-intensive sectors. **Target 12.5** By 2030, substantially reduce waste generation through prevention, reduction, recycling, and reuse. #### Building Blocks · Identification and authentication · Content Management · Information Mediator · eMarketplace · Digital registries · Messaging · Payment **Future Building Blocks** · Artificial Intelligence · Mobility management #### Steps ***Step 1 - Identifying property*** This step involves the government agency identifying the property that is no longer needed and can be sold to interested buyers. The Property could be any type of item or asset that the government agency has deemed as surplus and is looking to dispose of. **Workflows**: The workflows involved in this step: * The Government Agency identifies surplus property that it no longer needs. * The Property Officer conducts a physical inspection of the property and prepares a condition report. * The Property Officer gets approvals from stakeholders within the government agency. * The agency adds the property to its inventory of surplus property. **Building Blocks for Workflows:** * Identification and authentication * Digital Registeries * Content Management **Example Implementation** Go to G2P-UC3-GAM-S.1 ***Step 2 -***** Transferring property to Surplus Property Management Office** The government agency that owns surplus property initiates the transfer of the property to the Surplus Property Management Office for disposal. This involves preparing the necessary documentation for the property and obtaining the required approvals. **Workflows**: The workflows involved in this step: * Government agency makes the transfer by submitting the description of the property, its condition, and any other relevant details. * The transfer will be reviewed and approved by the relevant stakeholders. * Surplus Property Management Office takes possession of the property and responsibility for its sale. **Building Blocks for Workflows:** * Case Management. * Content Management. * Digital registries. * Identification and authentication. ***Step 3 -***** Listing property** This step involves Surplus Property Management Office listing the Property on the Surplus Property Management Auctions marketplace, which is a platform for selling surplus and unneeded Gov. assets to the public. The website allows buyers to search for and bid on a wide range of Gov. assets, including Property, equipment, real estate, and more. **Workflows**: The workflows involved in this step: * Surplus Property Management Office determines the appropriate listing category for the property based on its type, condition, and other relevant factors. * Surplus Property Management Office sets a starting bid price and bidding period for the property. * Surplus Property Management Office reviews bids as they come in and updates the listing to reflect the current high bid. **Building Blocks for Workflows:** * eMarketplace. * Digital registries. * Content Management. **Example Implementation** Go to G2P-UC3-GAM-S.3 ***Step 4 -***** Bidding on property** This step involves the registered bidders submitting their bids on the property listed for sale by the Surplus Property Management Office on Auctions platform. **Workflows**: The workflows involved in this step: * Bidders view the listing of the property on the Surplus Property Auctions marketplace. * Bidders submit their bid amount and bidder information through the Surplus Property Auctions marketplace. * Surplus Property Management Office receives and records the bid amounts and bidder information. * The bidding period ends. * Surplus Property Management Office reviews the bids and selects the highest bidder. **Building Blocks for Workflows:** * eMarketplace * Authentication & Authorization **Example Implementation** Go to G2P-UC3-GAM-S.4 ***Step 5 -***** Awarding property** The Surplus Property Management Office reviews the highest bid and selects the winning bidder to be awarded the property. **Workflows**: The workflows involved in this step: * Surplus Property Management Office updates its inventory to reflect the transfer of the property. * Surplus Property Management Office verifies the payment and transfer details and authorizes the transfer of the property to the highest bidder. * The highest bidder confirms acceptance of the bid and provides payment and transfer details to the Surplus Property Management Office. * Surplus Property Management Office sends a notification to the highest bidder that their bid has been accepted and requests payment and transfer of the property. * Surplus Property Management Office reviews the bids and selects the highest bidder. **Building Blocks for Workflows:** * Notifications * Payment * eMarketplace * Messaging **Example Implementation** Go to G2P-UC3-GAM-S.5 ***Step 6 -***** Transfer of property** This step involves the highest bidder paying for the property they have won in the auction and taking possession of it from the seller, in this case, the Surplus Property Management Office. It includes the payment validation and transfer of ownership to the buyer. **Workflows**: The workflows involved in this step: * The Surplus Property Management Office confirms receipt of payment and prepares the necessary transfer of ownership and registration documents * The buyer and Surplus Property Management Office coordinate the transfer of the property, including pickup or delivery arrangements * The Surplus Property Management Office transfers ownership and registration documents to the buyer, completing the transaction. **Building Blocks for Workflows:** * Payment * eMarketplace **Example Implementation** ## G2P-UC3-GAM-S.1 | ID | G2P-UC3-GAM-S.1 | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Use Case Step | Identifying property | | Preconditions |
  • The Government agency must have surplus property that it no longer needs.
  • The government agency has identified surplus property that it no longer needs.
| | Data Inputs |
  • Description of the property
  • Property condition report
  • Supporting documentation, such as registration, title, and other certificates
  • Identification of the Government agency that owns the property.
| | Actors |
  • Government Agency: Initiates the process of identifying surplus property that is no longer needed.
  • Property Officer: Conducts a physical inspection of the property and prepares a condition report.
  • Surplus Property Auctions marketplace.
| | Normal Course |
  1. 1.The Government Agency identifies surplus property that it no longer needs.
  2. 2.The Property Officer conducts a physical inspection of the property and prepares a condition report.
  3. 3.The Property Officer gets approvals from stakeholders within government agency.
  4. 4.The agency adds the property to its inventory of surplus property.
| | Alternative Course | If the property is not suitable for sale on the Surplus Property Auctions marketplace, it may be disposed of through other means, such as recycling, donation, or destruction. | | Data Output | Information about the identified surplus property is added to the government agency's inventory. | | Post-Conditions | The surplus property has been successfully identified, inspected, and ready for transfer to the Surplus Property Management Office for listing on the Surplus Property Auctions marketplace. | | Exceptions | NA | | Related BBs |
  • Identification and authentication
  • Digital registries
  • Content Management
| | Sequence Diagram | Surplus Property Identification Process​`Government Agency->Property Officer: Identify surplus property Property Officer->Property Officer: Conduct physical inspection and prepare condition report Property Officer->Government Agency: Get approvals from stakeholders Government Agency->Government Agency: Add property to inventory of surplus property` | ![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FPs03umrTGr2kKZAChFog%2FScreen%20Shot%202023-03-29%20at%207.24.49%20AM.png?alt=media\&token=63ce324e-fbb9-466e-abc6-cf33ffe6a788)\\ ## G2P-UC3-GAM-S.2 | ID | G2P-UC3-GAM-S.2 | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Transferring property | | Preconditions |
  • The Government Agency has identified surplus property that it wishes to transfer to the Surplus Property Management Office.
  • Approval from relevant stakeholders within the Government Agency for the transfer.
| | Data inputs |

Details of the surplus property to be transferred, including

  • Description
  • Condition report
  • Inventory number
| | Actors |
  • Government Agency: Initiates the process of transferring surplus property to the Surplus Property Management Office.
  • Surplus Property Management Office: Receives surplus property from the Government Agency.
| | Normal Course |
  1. 1.The Government Agency initiates the transfer process and provides details of the surplus property to the Surplus Property Management Office.
  2. 2.The Surplus Property Management Office verifies that it is willing and able to accept the property.
  3. 3.The Government Agency provides approval for the transfer from relevant stakeholders within the organization.
  4. 4.The Surplus Property Management Office takes possession of the property and updates its inventory to reflect the new acquisition.
| | Alternative Course |
  • If the Property does not meet the transfer requirements, the Surplus Property Management Office rejects the transfer and sends the Property back to the government agency.
  • If the transfer document is incomplete or contains errors, the government agency must correct them and resubmit the transfer document.
  • If the Surplus Property Management Office is unable to accept the property, the Government Agency may need to identify an alternative recipient.
| | Data output |
  • Legal ownership of the Property is transferred from the government agency to the Surplus Property Management Office.
  • The Surplus Property Management Office updates its inventory to reflect the new acquisition.
  • The Property's status is updated in the centralized database.
| | Post-Conditions |
  • The government agency has successfully transferred the Property to the Surplus Property Management Office.
  • The Surplus Property Management Office assumes responsibility for the Property's sale.
  • Legal ownership of the Property is transferred from the government agency to the Surplus Property Management Office.
| | Exceptions |
  • The Surplus Property Management Office is unable to accept the property.
  • The property is found to be in unacceptable condition.
| | Related BBs |
  • Identification and authentication.
  • Digital registries.
  • Content Management.
  • Case Management.
| | Sequence Diagram | title Transferring Property​`Government Agency->Surplus Property Management Office: Initiate transfer and provide property details Surplus Property Management Office->Government Agency: Verify willingness and ability to accept property Government Agency->Government Agency: Obtain approval from relevant stakeholders Government Agency->Surplus Property Management Office: Provide approval for transfer Surplus Property Management Office->Government Agency: Take possession of property Surplus Property Management Office->Surplus Property Management Office: Update inventory to reflect new acquisition` | ​![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FaIO1C19QbJ0EZamaloft%2FScreen%20Shot%202023-03-29%20at%207.46.17%20AM.png?alt=media\&token=879f3d87-8dfd-4b52-9384-1ba108659eab)\\ ## G2P-UC3-GAM-S.3 | ID | G2P-UC3-GAM-S.3 | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Listing property | | Preconditions |
  • The property must have been successfully transferred to the Surplus Property Management Office.
  • The property must have been inspected and evaluated for condition by the Property Officer.
| | Data inputs |
  • Property information and details (e.g. description, condition, images).
  • Property images or videos for showcasing the property
  • Property Officer's Inspection report
| | Actors |
  • Surplus Property Management Office
  • Property Officer
  • Surplus Property Auctions marketplace.
| | Normal Course |
  1. 1.Surplus Property Management Office receives the property from the government agency.
  2. 2.The Surplus Property Management Office adds the property to its inventory of available surplus property.
  3. 3.The Surplus Property Management Office creates a listing of the property on the Surplus Property Auctions marketplace, including the property details and any images or videos provided.
  4. 4.Surplus Property Management Office publishes the listing to the Surplus Property Auctions marketplace.
| | Alternative Course | If the property does not meet the criteria for listing on the Surplus Property Auctions marketplace, the property may be disposed of through other means (e.g. donated, recycled, or scrapped). | | Data output | Property listing on the Surplus Property Auctions marketplace. | | Post-Conditions | Property is listed for auction on the Surplus Property Auctions marketplace. | | Exceptions |
  • The property does not meet the criteria for listing on the Surplus Property Auctions marketplace.
  • Technical errors or system issues prevent the creation of the property listing
| | Related BBs |
  • eMarketplace.
  • Digital registries.
  • Content Management.
| | Sequence Diagram | title Surplus Property Listing​`Government Agency->Surplus Property Management Office: Transfer property Surplus Property Management Office->Surplus Property Management Office: Add property to inventory Surplus Property Management Office->Surplus Property Management Office: Create property listing Surplus Property Management Office->Surplus Property Auctions marketplace: Publish listing` | ​![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2Fw8pgTUnVmSFWqGnf27jo%2FScreen%20Shot%202023-03-29%20at%207.59.43%20AM.png?alt=media\&token=0f6b51d5-f914-4e90-acd1-82d43bdb7e90)\\ ## G2P-UC3-GAM-S.4 | ID | G2P-UC3-GAM-S.4 | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Bidding on property | | Preconditions |
  • The property has been listed on the Surplus Property Auctions marketplace.
  • Bidders are registered and authenticated on the Surplus Property Auctions marketplace.
| | Data inputs |
  • Bid amount
  • Bidder information
| | Actors |
  • Bidders
  • Surplus Property Management Office
  • Surplus Property Auctions marketplace
| | Normal Course |
  1. 1.Bidders view the listing of the property on the Surplus Property Auctions marketplace.
  2. 2.Bidders submit their bid amount and bidder information through the Surplus Property Auctions marketplace.
  3. 3.Surplus Property Management Office receives and records the bid amounts and bidder information.
  4. 4.The bidding period ends.
  5. 5.Surplus Property Management Office reviews the bids and selects the highest bidder.
| | Alternative Course | If there are no bids, the Surplus Property Management Office may choose to re-list the property for auction. | | Data output |
  • Winning bid amount
  • Bidder information
| | Post-Conditions | The highest bidder is identified and notified of their win. | | Exceptions |
  • Invalid bid amount or information is submitted.
  • Technical issues with the Surplus Property Auctions marketplace.
  • Other unforeseen issues that prevent the auction from being completed.
| | Related BBs |
  • Authentication & Authorization
  • eMarketplace
| | Sequence Diagram | title Bidding on Property`Bidders->Surplus Property Auctions: View property listing Surplus Property Auctions->Bidders: Display property listingBidders->Surplus Property Auctions: Submit bid and bidder information Surplus Property Auctions->Surplus Property Management Office: Record bid and bidder information Note right of Surplus Property Management Office: Bidding period ends Surplus Property Management Office->Surplus Property Auctions: Provide bid results Surplus Property Auctions->Bidders: Display bid resultsSurplus Property Management Office->Bid Winner: Notify bid winner` | ![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FlDfENk6ycmema5RThGXX%2FScreen%20Shot%202023-03-29%20at%208.13.44%20AM.png?alt=media\&token=ef681c31-6f71-4c93-b928-97325c5b80c2)\\ ## G2P-UC3-GAM-S.5 | ID | G2P-UC3-GAM-S.5 | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Awarding property | | Preconditions |
  • The property has been listed on the Surplus Property Auctions marketplace.
  • Registered bidders have placed bids on the property.
  • There is at least one bidder for the property.
  • The bidding period has ended.
| | Data inputs |
  • Bid information for all bidders.
  • Property information.
| | Actors |
  • Surplus Property Management Office
  • Surplus Property Auctions marketplace
| | Normal Course |
  1. 1.Surplus Property Management Office reviews the bids and selects the highest bidder.
  2. 2.Surplus Property Management Office sends a notification to the highest bidder that their bid has been accepted and requests payment and transfer of the property.
  3. 3.The highest bidder confirms acceptance of the bid and provides payment and transfer details to the Surplus Property Management Office.
  4. 4.Surplus Property Management Office verifies the payment and transfer details and authorizes the transfer of the property to the highest bidder.
  5. 5.Surplus Property Management Office updates its inventory to reflect the transfer of the property.
| | Alternative Course | If the highest bidder fails to provide payment or transfer details within a specified timeframe, the Surplus Property Management Office may select the next highest bidder. | | Data output |
  • Notification to the highest bidder that their bid has been accepted.
  • Authorization for the transfer of the property.
| | Post-Conditions |
  • The property has been transferred to the highest bidder.
  • Payment has been received by the Surplus Property Management Office.
| | Exceptions |
  • The highest bidder fails to provide payment or transfer details.
  • The highest bidder provides incorrect payment or transfer details.
  • The property is damaged or not as described in the listing.
  • The Surplus Property Management Office is unable to transfer the property to the highest bidder for legal or other reasons.
| | Related BBs |
  • Messaging
  • eMarketplace
  • Payment
  • Notifications
| | Sequence Diagram | title Awarding Property​`Surplus Property Management Office -> Surplus Property Management Office: Review Bids\nSelect Highest Bidder Surplus Property Management Office -> Highest Bidder: Send Notification\nRequest Payment & Transfer Details Highest Bidder -> Surplus Property Management Office: Confirm Bid\nProvide Payment & Transfer Details Surplus Property Management Office -> Surplus Property Management Office: Verify Payment & Transfer Details\nAuthorize Transfer of Property Surplus Property Management Office -> Surplus Property Management Office: Update Inventory` | ![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2F5M2VW5J5PSBxlkiu4fYp%2FScreen%20Shot%202023-03-29%20at%208.24.47%20AM.png?alt=media\&token=28b07e63-991f-4146-b69a-7d377937cf4f)\\ ## G2P-UC3-GAM-S.6 | ID | G2P-UC3-GAM-S.6 | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Use Case Step | Transfer of property | | Preconditions |
  • The Surplus Property Management Office has selected the highest bidder and sent a notification to them.
  • The highest bidder has confirmed their acceptance of the bid and provided payment and transfer details.
| | Data inputs |
  • Payment details (e.g. payment method, amount, transaction ID)
  • Transfer details (e.g. shipping address, tracking information)
| | Actors |
  • Surplus Property Management Office
  • Highest bidder
| | Normal Course |
  1. 1.The highest bidder provides payment and transfer details to the Surplus Property Management Office.
  2. 2.The Surplus Property Management Office verifies the payment and transfer details.
  3. 3.The Surplus Property Management Office authorizes the transfer of the property to the highest bidder.
  4. 4.The Surplus Property Management Office updates its inventory to reflect the transfer of the property.
  5. 5.The Surplus Property Management Office confirms the transfer of the property with the highest bidder.
| | Alternative Course | If the payment or transfer details provided by the highest bidder are not valid, the Surplus Property Management Office may request corrected information or cancel the transaction. | | Data output |
  • Confirmation of payment and transfer details
  • Confirmation of the transfer of the property
| | Post-Conditions |
  • The highest bidder has paid for and received the property.
  • The Surplus Property Management Office has updated its inventory to reflect the transfer of the property.
| | Exceptions |
  • Invalid payment or transfer details provided by the highest bidder.
  • Errors or delays in the payment or transfer process.
| | Related BBs |
  • Payment
  • eMarketplace
| | Sequence Diagram | title Transfer of Property​`Highest Bidder->Surplus Property Management Office: Provides payment and transfer details Surplus Property Management Office->Highest Bidder: Verifies payment and transfer details Surplus Property Management Office->Highest Bidder: Authorizes transfer of property Surplus Property Management Office->Surplus Property Management Office: Updates inventory Surplus Property Management Office->Highest Bidder: Confirms transfer of propert`y | ![](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPUIGDILlDRSOB6K47k6e%2Fuploads%2FdFdMmPK9Kh79f4WmnrTt%2FScreen%20Shot%202023-03-29%20at%208.35.12%20AM.png?alt=media\&token=763b143e-bb1f-4308-9ec2-a16305c83e9e)\\ # EM-B2G-UC2-SGP-Sporting Goods Procurement ## eM-B2G-UC2-SGP-Sporting Goods Procurement **Product use case summary** | ID | MKT | | ------- | -------------------------- | | Name | Sporting Goods Procurement | | Sector | Government Marketplace | | Version | 1.0 | | Status | Draft | This use case explains the procurement of sporting goods / equipment. The buyer is a registered government sporting authority. The seller is any eligible seller of sporting goods / equipment. Both the buyer and seller are registered as per the rules defined in the eMarketplace. For sake of simplicity, the eMarketplace is this use case is called as Government eMarketplace i.e. GEM. Once a seller is registered in GEM, it should publish its catalogue so that buyers are able to find the items they are searching for. The process of procurement involves 3 steps. 1. Create purchase requisition (PReq) - Buyer creates a PReq 2. Apply for purchase requisition (PReq) - Seller applies to participate in the PReq process 3. Award purchase requisition (PReq) - Buyer awards a purchase contract to a Seller The actual delivery of the items is out of scope of this use case. #### SGD targets **Target 8.2** Achieve higher levels of economic productivity through diversification, technological upgrading, and innovation, including through a focus on high-value-added and labour-intensive sectors. **Target 12.9** Support developing countries to strengthen their scientific and technological capacity to move towards more sustainable patterns of consumption and production. #### Building blocks * Registration * Digital registries * Identification and authentication * Content Management * Information Mediator * eMarketplace * Messaging * Payment #### Steps \ The preconditions for executing a PReq are as follows #### Register a buyer 1. Buyer submits registration information in the government portal 2. Buyer is evaluated (online or offline) 3. Buyer is approved 4. Buyer receives notification for approval #### Register a seller 1. Seller provides mandatory information on on the government portal 2. Seller is evaluated (online or offline) 3. Seller is approved (authorised seller) 4. Seller receives notification for approval #### Publish catalogue (by seller) 1. Seller logs in to the government portal 2. Seller uploads catalogue of products and/or services 3. Seller’s catalogue is evaluated 4. Seller catalogue is published on the government portal Once the preconditions are completed, a PReq can be created in the system. Listed below are the steps for creating a PReq leading to awarding of a purchase contract to the seller. #### Step 1 - Create purchase requisition (PReq) This step involves a formal request (broadcast of intent) by the sporting authority for the procurement of sporting goods. Here the sporting authority is the buyer and Seller is anybody who is registered in the government portal, usually a seller of sports goods. **Workflows** The workflows involved in this step are 1. The sporting authority (Buyer) representative logs in to the government portal. 2. Buyer searches for the sports goods (cricket kit) 3. Buyer views catalogue of matching products 4. Buyer selects the products that matches the requirements 5. Buyer provides the quantity required 6. Buyer provides the shipping / delivery location 7. Buyer provides the preferred vendor or a list of approved vendors 8. Buyer selected the option to create a requisition. 9. Buyer creates PReq and submits it for internal approvals. The sporting authority seeks internal approval before the requisition is published for response. **Building Blocks for Workflows** * Identity * Search **Functional Blocks for Workflows** * Catalogue * Cart * Fulfilment * Quotation #### Step 2 - Apply for purchase requisition (PReq) This step involves a Seller responding to the PReq through the government portal. The Seller is expected to respond in line with the terms and conditions of the PReq. **Workflows** The workflows involved in this step are 1. Seller logs in to the government portal. 2. Seller views the list of open PReqs 3. Seller offers a quote for the PReq 4. Seller is asked to authenticate 5. Seller submits the quote **Building Blocks for Workflows** * Identity * Search **Functional Blocks for Workflows** * Quotation #### Step 3 - Award purchase requisition (PReq) This step involves the Buyers evaluating all the responses from the interested Sellers and awarding a purchase contract to a selected Seller. The Buyers, in order to optimise the purchase contract, may engage in several iterations of negotiations. **Workflows** The workflows involved in this step are 1. Buyer logs in to the government portal. 2. Buyer views the list of quotations from the Sellers 3. Buyer is asked to authenticate before viewing the offer price 4. Buyer reviews the offer quotes and terms & conditions 5. Buyer creates preliminary purchase order for one or more offers 6. Buyer provides payment details 7. Buyer prints final purchase order (or contract) document 8. Buyer is asked to authenticate before the final print 9. Buyer confirms the purchase order to Seller 10. Seller receives notification **Building Blocks for Workflows** * Identity * Payment **Functional Blocks for Workflows** * Quotation * Order ### # eM-B2G-UC1-MoJ-HPMMS Data & Reporting Platform ## eM-B2G-UC1-MoJ-HPMMS Data & Reporting Platform Example Implementation ### MP-01-Registration-Buyer | Use Case Step | Use Case: Ministry of Justice - HMPPS Data & Reporting platform, Step: Registration (Public Sector buyer) | | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) | · The buyer must be employed by, or represent, a public sector organisation.· The buyer has a work email address to create an account OR· The buyer has successfully logged into their government SSO (Registration BB) and has the necessary authorization to complete the registration process.· Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (contract) and respective REST API services in Information Mediator has been opened to Registration BB.· The buyer email address domain is held on, or can be added to, a registry with approved or authenticated public sector domains. | | Data inputs | 1. Email address2. Password3. Name4. Organisation | | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: Public sector worker, System AdministratorSystem:· Digital Registries BB· Identity BB· Consent BB· Messaging BB· Information Mediator BB | | Normal Course (what happens if the event is triggered and the preconditions have been met) | Create a buyer account: Registration page provides a high level explanation of what is needed and process to create an account. “You must be employed by, or represent, a public sector organisation. Use your work email address to create an account. We use this to check that you are part of a public sector organisation. We will send an account activation email to this address. You will then be able to set your password.”Step 1: The public sector worker enters their email address to create an account:1. Enter email address2. Validate email address structure3. Confirm ‘Create account’Step 2: The application submits the email address to the relevant Digital Registries BB to verify it belongs to an authorised public sector organisation.Step 3: The application sends an email to the public sector worker with a URL to complete account creation.Step 4: The public sector worker completes account creation:1. Click on link in email2. Create account password3. Confirm | | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | If the public sector worker does not have an email address recognised by the registry, the registration application needs to provide an alternate mechanism for the worker to request an account.1. System Administrator confirms the domain is valid and adds to the registry.2. Public sector worker is notified and sent a link to create an account (URL to registration page) | | Data output | | | Post-Conditions (the success criteria) | The buyer is registered and can access buyer-only areas of the marketplace. | | Exceptions(error situations) | · A buyer can be only registered once. The system must prevent multiple registrations.o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actors· If the buyer does not have an email address with a domain registered in the Registry, then it is not possible to create an account (no personal emails).o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actors· If Identity BB or Consent BB is not available (service outage), then …..o Mitigation steps: Describe steps to be taken by the actors· If no internet, then the system is not available.o Mitigation steps: Display error page | | Related BBs(working groups related to this example implementation) | Identity BBApproval BBRegistration BBDigital Registries BB | | Sequence Diagram | | ### **MP-02-Registration-Supplier** | Use Case Step | Use Case: Ministry of Justice - HMPPS Data & Reporting platform, Step: Registration (Public Sector buyer) | | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Preconditions(list of conditions that MUST be met in order to be able to successfully execute this process) | · The supplier has an email address to create an account· The supplier must be employed by, and be authorised to represent, an organisation.· The supplier organisation is a legal entity and listed in the relevant registry (or via API to an official source).· Data sharing agreement between Registration BB and respective registries where information is queried from has been signed (contract) and respective REST API services in Information Mediator has been opened to Registration BB. | | Data inputs | 1. Email address2. Password3. Name4. Organisation name5. Organisation address6. Contact phone number (for buyer communications)7. Contact email address (for buyer communications)8. Company ID (e.g.[ DUNS number](https://www.dnb.co.uk/duns-number/lookup/request-a-duns-number.html) in the UK, or registered on[ Companies House](https://find-and-update.company-information.service.gov.uk/)) | | Actors(the people, organizations, computer systems - hardware and software, and building blocks that participate in the activity) | Human: Supplier representativeSystem:· Digital Registries BB· Identity BB· Consent BB· Messaging BB· Information Mediator BB | | Normal Course (what happens if the event is triggered and the preconditions have been met) | Create a supplier account: Registration page provides a high level explanation of what is needed and process to create an account. “You must provide:- a company name and company details that buyers may use to contact you- your own details to create a login- a DUNS number.It will take about 5 minutes to create your account. If your company isn’t registered with Companies House. If your company isn’t registered with Companies House, you may need to apply for a DUNS number before you can create a supplier account. It could take 3 to 5 days to get your DUNS number.”Step 1: The supplier enters their information to create an account:1. Enter company ID (e.g. DUNS) \*note this first step to reduce failing later in the process2. Enter company name3. Enter contact name4. Enter contact email address5. Enter contact phone number6. Confirm ‘Create account’Step 2: Create login details (not visible on the Marketplace)1. Enter work email address (note, can also add other email addresses later)2. Confirm ‘Continue’Step 3: Check your information:1. View ‘Company ID’, ‘Company name’, ‘Contact name’, ‘Contact email’, ‘Contact phone number’, ‘Login email’2. Option to change each field individually3. Confirm ‘Create account’4. Confirmation page with next step “We’ve sent an email to \. Use the link to activate your account and set your password.”Confirm application sends an email to the supplier with a URL to complete account creation.Step 4: The supplier completes account creation:5. Click on link in email6. Create account password7. Confirm | | Alternative Course(links to other use cases in case there are different ways how to solve the same use case) | | | Data output | | | Post-Conditions (the success criteria) | The supplier is registered and can access supplier-only areas of the marketplace. | | Exceptions(error situations) | · A supplier can be only registered once. The system must prevent multiple registrations.o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actors· If the supplier does not have a valid Company ID….o Provide details on exception code and messageo Mitigation steps: Describe steps to be taken by the actors· If Identity BB or Consent BB is not available (service outage), then …..o Mitigation steps: Describe steps to be taken by the actors· If no internet, then the system is not available.o Mitigation steps: Display error page | | Related BBs(working groups related to this example implementation) | Identity BBApproval BBRegistration BBDigital Registries BB | | Sequence Diagram | |