OpenProcurement application

What technologies do you use in OpenProcurement?

The toolkit has been developed with Python, Pyramid, Angular.js, Bootstrap, Flask, CouchDB, PouchDB and other powerful open source web technologies. All these technologies were chosen to achieve reliable functionality and secure workflow.

Can I use this solution for public procurements?

Primarily, Open Procurement has been designed specifically for the procurements on behalf of public authorities. The system holding public procurements requires them to be accessible and transparent.

The toolkit has been developed to meet these demands. It uses electronic documents, strict qualification requirements, transparent system of proposals evaluation and awarding, effective auctions, with four types of them, and open access to the procurement data.

Can I use OpenProcurement for commercial solutions?

Yes, free OpenProcurement software can be used for development of custom commercial solution and even its sale. Parts of the OpenProcurement toolkit (e.g. Central database or Auction module) can be used together or separately for any commercial project.

Where have you applied the OpenProcurement toolkit?

OpenProcurement has been used both in Ukrainian and foreign projects, such as ProZorro, ProZorro.sale, Rialto and MTender (Moldova).

Procurement Workflow

Why is a reverse auction used in ProZorro and MTender?

Reverse auction is used because it is time and cost effective. In a reverse auction suppliers compete to sell goods or services to the procuring entity at the lowest price. This mechanism considerably reduces the cost of the product/service and allows buyer to compare prices, qualifications, and other factors at a glance.

When are suppliers’ qualifications evaluated?

It depends on the procurement procedure. In most cases the qualification stage is performed after the auction is finished. The procurement entity or an assigned committee reviews commercial and qualification parts of the bid and has a right to request a candidate’s qualification documents that were not mandatory at the time of the bid registration. In some cases, such as Open European procedure, bid proposals are qualified before the auction.

Technical background

Does the database store information about users, such as their logins/passwords?

The Central Database does not store any authorization data about registered users. The Central Database stores all documents, data, and other information related to the organization and conduction of procurement. Authorization data is an identificational data of system users that allows them to participate in the procurement processes or their appeal, so it is very important to keep it secret. The web platform/operator is responsible for protection against unauthorized access and accidental destruction and/or distortion of account data contained in the system.

What programming language does the Open Procurement toolkit use?

The business logic of this toolkit is implemented in Python. This high-level programming language ensures maximum productivity, top quality, and user-friendly maintainability. A combination of other software tools like Pyramid, Angular.js, Bootstrap, Flask, CouchDB, and PouchDB helps to deliver a powerful back-end solution.

If my web platform is written in X programming language, can it work with this toolkit?

The Open Procurement toolkit was designed to be quite flexible. Thus, web platforms can interoperate with the Central Database via an API regardless the programming language or any other technology specifications they have. The API is one of the toolkit’s components that allows web platform to provide suppliers with temporary credentials to access the Auction module for participation in the auction.

Where can I host the Central Database and the Auction module?

These elements of the toolkit can be hosted on the Amazon Web Services (AWS) cloud. One of the requirements is SS3-compatible object storage, for example, OpenStack Swift.

Are there any restrictions concerning database size or amount of procurements?

The toolkit has been developed to avoid imposing restrictions on the size of database and/or number of conducted procurements.

What is an eMall?

eMall is an online platform that implements frontend e-Procurement system features and provides access for procuring entities, suppliers and regular visitors, where they can announce a procurement, register for participation or view procurements list respectively.

For eMalls (marketplaces/private markets/commercial platforms)

Does eMall need its own database?

Yes, eMalll (broker) should develop a database according to the data model described in the API documentation. Minimum requirement is a mechanism for tender and bid access tokens storage. Access tokens are received from CDB at the moment of object creation (e.g. tender creation). CDB does not provide any data search mechanism, so eMalls have their own database copy and use synchronization mechanism.

How does synchronization mechanism work?

Each eMall has its own database copy and uses synchronization mechanism to synchronize data with CDB. There are two relatively independent components:

• synchronizer that synchronizes all changes occurring in CDB with the eMall’s database, including the activation reaction to events (users notifications, etc.). Details can be found here.
• mechanism that registers actions of users in CDB. There are two approaches:
• synchronous: when user makes an action this action is made in CDB and user waits for the confirmation of success/failure of the action;
• asynchronous: when user actions are enqueued and changing synchronizer sends them to CDB, user is notified of the results by a separate mechanism.

To know more about the peculiarities of synchronization with productive (cluster) basis with separated reading and writing points, read the following threads: https://groups.google.com/d/topic/open-procurement-api/XjurUed0r8Q/discussion https://groups.google.com/d/topic/open-procurement-api/JjB5F5lvO14/discussion

How can a user of eMall access a procurement, announced on eMall B?

User does not need to register on another eMall. All events needed during tender conduction should be provided by “native” eMall. All changes that occur at the eMall are sent to the CDB and via synchronization become known to other eMalls. Data synchronization time between eMalls is less than 10 minutes. When supplier on one eMall asks question, it goes to the CDB via eMall and from CDB it “spreads” to all other platforms. Procuring entity provides answer on their eMall, this answer goes to the CDB and from the CDB it “spreads” to all platforms.

What is an API key?

API key is required for operations that are not available for anonymous user, such as creating and editing of tenders, submission of bid proposals, secret links for auction participation, etc. There is no need to use API key for data synchronization between the CDB and eMall. Details on how to use API key and access tokens are available at API documentation.

How should you begin testing your own eMall?

To develop testing driver for your own eMall you should build a test environment on your computer acccording to the instructions here. Transitional drivers (or final versions) should be kept at github (each eMall has its own driver), see https://github.com/openprocurement/?utf8=✓&q=robot_tests.broker. Driver that is available on github is used for testing at the central testing server: http://testing.openprocurement.org. Subscribe to the discussion, where you can learn more information.