Development of Open Procurement system
Так. Комплекс OpenProcurement був розроблений спеціально для закупівель товарів і послуг органами державної влади. Державні закупівлі мають особливі вимоги до відкритості та прозорості процедур. Це рішення забезпечує дотримання визнаних найкращих практик протягом усього процесу торгів. OpenProcurement застосовує електронні документи, стандарти Open Contracting, строгі кваліфікаційні вимоги, прозору систему оцінки пропозицій, ефективний аукціон і відкритий доступ до інформації про закупівлі.
Так. Безкоштовне програмне забезпечення OpenProcurement можна застосовувати для розробки комерційних рішень, як для окремих закупівель у приватному секторі, так і для більш масштабних проектів. Частини комплексу OpenProcurement (наприклад, Центральна база даних чи модуль Аукціонів) можна використовувати разом або окремо для будь-яких комерційних проектів.
Комплекс OpenProcurement поширюється під ліцензією на вільне програмне забезпечення Apache.
OpenProcurement зараз використовується українським проектом державних закупівель Prozorro. Основна мета Prozorro це забезпечення прозорого та ефективного витрачання державних коштів та запобігання корупції шляхом громадського контролю та розширення кола постачальників. Конкуренція між електронними майданчиками призведе до покращення роботи закупівель. Шість майданчиків вже надають доступ до системи. Що ще більш важливо, проект відкритий, так що будь-який майданчик може приєднатися, якщо він забезпечує необхідну функціональність. Серед замовників, які користуються Prozorro, є Міністерство інфраструктури, Міністерство оборони, Міністерство юстиції, Міністерство економіки, Державне управління справами, Міністерство екології і багато інших. Це рішення отримало позитивні відгуки від користувачів.
Електронний майданчик це апаратно-програмний комплекс, який реалізує функціонал системи електронних закупівель та надає доступ до неї замовникам, постачальникам та постійним відвідувачам.
OpenProcurement використовує саме такий тип аукціонів, тому що він економить час та гроші. Особливістю реверсивного аукціону є те, що учасники знижують свої ставки з кожним раундом. Тобто, постачальники змагаються за те, щоб продати свій товар замовнику за найнижчою ціною. Цей механізм значно знижує вартість продуктів/послуг і дозволяє замовнику легко і швидко порівняти ціни, кваліфікації та інші фактори.
Аукціон запускається автоматично у заданий час. Ніхто не знає точну кількість учасників та їх пропозиції. Всі користувачі, включаючи замовника, можуть стежити за ходом аукціону онлайн. Сторінка аукціону відображає учасників (анонімно), їх попередньо зареєстровані ставки і час до початку аукціону та/або ходу учасника. Електронний майданчик надає учасникам індивідуальні URL-адреси сторінки аукціону. Там, крім вищезазначеної інформації, є поле, де вони можуть зробити свої ставки.
Після початку аукціону система робить паузу на 5 хвилин, щоб учасники змогли ознайомитися зі ставками анонімних конкурентів. Після п’ятихвилинного періоду система автоматично оголошує перший раунд.
Аукціон складається з трьох раундів з однаковими правилами. У кожному раунді протягом 2 хвилин кожен учасник (в порядку від більших до менших, а при співпадінні пропозицій - від пізніших до більш ранніх пропозицій) має право зробити ставку на пониження своєї попередньої пропозиції. Якщо учасник зробив вибір раніше, система дасть йому можливість внести зміни до кінця відведеного часу. Якщо учасник не вніс змін протягом 2 хвилин, система прийме його ставку і передасть хід наступному учаснику. Коли всі учасники зроблять свої ставки в раунді, система робить паузу на 2 хвилини і оголошує наступний раунд.
Після третього раунду система автоматично рангує всі подані ставки, створюючи рейтинг позицій кандидатів. Ця інформація публікується одразу ж після завершення електронного аукціону. Тоді користувачі можуть отримати повну інформацію про пропозиції та учасників, які їх подали.
Аукціон складається з трьох раундів. Кожен учасник має 2 хвилини, щоб змінити (або залишити без змін) свою пропозицію і є двохвилинна пауза між раундами.
Кваліфікація відбувається після закінчення аукціону. Замовник або призначений ним комітет розглядає комерційні та кваліфікаційні частини пропозиції і має право вимагати кваліфікаційні документи кандидата, що не були обов’язковими під час реєстрації пропозиції.
Бізнес-логіка цього комплексу реалізована на Python. Ця мова програмування високого рівня забезпечує максимальну продуктивність, високу якість і зручну роботу. Поєднання з іншими програмними інструментами, такими як Pyramid, Angular.js, Bootstrap, Flask, CouchDB, та PouchDB допомогло розробити потужне рішення для електронних закупівель.
Центральна база даних використовує нереляційну базу даних CouchDB для зберігання записів аукціонів, пропозицій і т.п.
Центральна база даних не зберігає ніяких авторизаційних даних про зареєстрованих користувачів. ЦБД зберігає всі документи, дані та іншу інформацію, пов’язану з організацією та проведенням закупівель. Авторизаційні дані є ідентифікаційними даними користувачів системи, що дозволяють їм брати участь у закупівлях або їх оскарженні, тому дуже важливо зберігати їх у таємниці. Електронний майданчик/оператор несе відповідальність за захист від несанкціонованого доступу та ненавмисного знищення та/або спотворення облікових даних, що містяться в системі.
Незалежно від мови програмування або інших технічних характеристик будь-який майданчик може легко взаємодіяти з центральною базою даних за допомогою API. API є частиною комплексу OpenProcurement, через яку майданчик може надати постачальникам тимчасові авторизаційні дані для участі в аукціоні.
Центральна база даних та модуль Аукціону можуть хоститись за допомогою хмарного сервісу, наприклад, на Amazon. Однією з вимог є S3-сумісний репозиторій документів, наприклад, Apache Swift.
Комплекс OpenProcurement був розроблений так, щоб уникнути накладання обмежень на розмір бази даних та/або кількість проведених закупівель.
Пошук по базі даних поки що не реалізований, але планується його додати як частину функціональності OpenProcurement.
Так, майданчик повинен розробити свою базу даних по моделі даних описаній в документації по API. Необхідний мінімум це механізм зберігання access token-ів тендерів та цінових пропозицій, які з ЦБД можна отримати тільки в момент створення відповідного об’єкту (наприклад, закупівлі). ЦБД не забезпечує жодних механізмів пошуку інформації (див. обговорення), тому майданчики ведуть свою копію бази даних і застосовують механізми синхронізації.
Кожен майданчик має свою копію бази даних і застосовує механізми синхронізації з ЦБД. Є два відносно незалежні компоненти:
синхронізатор, який всі зміни, що відбуваються в ЦБД, синхронізує в базу майданчика, включно з активацією реакції на події (повідомлення користувачів і т.п.). Детальніше в документації по API.
механізм, який реєструє дії користувачів в ЦБД. Тут є два підходи:
синхронний, коли при діях користувача відбуваються дії в ЦБД, і користувач очікує, щоб отримати підтвердження про успішність чи неуспішність дії.
асинхронний, коли дії користувачів складаються в чергу і синхронізатором змін відправляються в ЦБД, результат окремим механізмом повідомляється своєму користувачу.
Щоб дізнатись детальніше про особливості синхронізації з продутивною (кластерною) базою з рознесеними точками читання і запису, прочитайте наступні нитки розмов: https://groups.google.com/d/topic/open-procurement-api/XjurUed0r8Q/discussion https://groups.google.com/d/topic/open-procurement-api/JjB5F5lvO14/discussion
Користувач не має потреби реєструватися на іншому майданчику. Всі події, необхідні йому в процесі проведення тендера, має забезпечити “рідний” майданчик. Всі зміни, які відбуваються на майданчику, потрапляють в ЦБД, і звідти синхронізацією “розлітаються” по майданчиках. Час синхронізації інформації між майданчиками зараз не перевищує 10 хвилин. Коли постачальник на одному майданчику задає запитання, то воно через майданчик потрапляє в ЦБД, а з ЦБД “розлітається” по всіх інших майданчиках. Замовник на своєму майданчику надає відповідь, відповідь потрапляє в ЦБД, а з ЦБД “розлітається” по всіх майданчиках.
API ключ необхідний для операцій, які недоступні анонімному користувачу, а саме, для створення та редагування тендерів, для подачі цінових пропозицій, для отримання секретних посилань на участь в аукціоні і т.п. Для синхронізації даних з ЦБД на свій майданчик не потрібно використовувати API ключ. Правила використання API ключа і access token-ів доступні в документації.
Для розробки драйвера тестування власного майданчика варто зібрати тестове середовище в себе на комп’ютері за інструкціями. Проміжні (чи кінцеві варіанти) драйвери відправляються в github (кожен майданчик має свій драйвер), див. https://github.com/openprocurement/?utf8=✓&query=robot_tests.broker. Драйвер, що доступний на github, використовується для тестування на центральному сервері тестування: http://testing.openprocurement.org. Підпишіться на цю розсилку по тестуванню, там можна почерпнути більше інформації.