etender.uzex.uz — taklif hujjatlarini avtomatlashtirish

01Qisqacha xulosa

Bir kunlik chuqur teskari tahlildan keyin holat aniq: tayyorlash jarayonini 100% avtomatlashtirish mumkin, yakuniy imzo esa har doim operator kompyuterida qoladi. Bu bizning cheklovimiz emas — platformaning o'zi shunday qurilgan, va buni chetlab o'tishga urinish qonuniy jihatdan ham, texnik jihatdan ham noto'g'ri yo'l.

Nima isbotlandi

• Jonli  Platformaning barcha ro'yxat va detal API'lari server tomondan chaqirila oladi — anti-bot Validation headeri to'liq ochildi va takrorlandi.
• Jonli  Lot detali ichida taklif uchun talab qilinadigan hamma narsa bor: mezonlar, kvalifikatsiya talablari, mahsulot qatorlari, zakalat foizi, texnik topshiriq fayllari.
• Kodda  Platformada qoralama (Draft) mexanizmi bor va u ERI imzosini talab qilmaydi — biz taklifni to'liq tayyorlab, qoralama sifatida kabinetga joylashtira olamiz.
• Tanlov  Yakuniy yuborish (AddBid) PKCS#7 ERI imzosini talab qiladi. Brauzerdagi oddiy yo'llar yopiq — lekin serverimizda ishlab turgan sertifikatlangan E-IMZO imzolovchisi bor (SIGN markazi). Demak to'liq avtomat yuborish ham ochiq; bu texnik emas, siyosat qarori.

Tavsiya qilinadigan yechim

Yagona poydevor: serverdagi Tender Studio — kuzatuv, tahlil, narx, hujjat generatsiyasi, PDF muhr/imzo va tayyor paket. Yuborish esa ikki xil bo'lishi mumkin: operator brauzeri orqali (ko'prik) yoki to'liq serverda (SIGN markazi imzosi bilan). Bu tanlovni hozir qilish shart emas — birinchi uch faza ikkalasida ham bir xil. Konvert oqimida esa server chop etishga tayyor to'liq papka beradi.

02Ikki oqim — bir-biridan tubdan farq qiladi

Farq shunchaki "yuborish usuli"da emas. Elektron oqimda platforma bizga tuzilmali mezonlar beradi — har bir mezon uchun alohida fayl biriktiriladi. Konvert oqimida esa hech qanday onlayn taklif shakli yo'q: e'londa faqat manzil, muddat va texnik hujjatlar bo'ladi, qolgani qog'ozda. Shuning uchun ikkinchi oqim uchun tizimning yakuniy mahsuloti — chop etishga tayyor, tartiblangan, raqamlangan hujjatlar papkasi.

03Platforma texnik tahlili

3.1 Sayt qanday qurilgan

etender.uzex.uz — bu Angular SPA. Sahifani oddiy curl bilan olsangiz, atigi 748 baytlik bo'sh qobiq keladi; barcha mazmun JavaScript orqali API'dan yuklanadi. Demak sahifani "o'qib olish" (scraping) mantiqsiz — to'g'ridan-to'g'ri API bilan ishlash kerak. Ilova konfiguratsiyasi main.js ichidan to'liq chiqarildi:

version:        "1.5.2"
authUrl:        https://id.uzex.uz          ← ERI bilan kirish
authApiUrl:     https://idapi.uzex.uz
newId:          https://id-api.uzex.uz
serverUrl:      https://apietender.uzex.uz  ← asosiy API
serverUrlNew:   https://api-etender-new.uzex.uz
tradeUrl:       https://xarid-api-trade.uzex.uz  ← umumiy lug'atlar
fileServiceUrl: https://etender-fileservice.uzex.uz
minioUrl:       minio-cdn.uzex.uz
requiredEsi:    true                        ← ERI imzosi majburiy
domain:         "etender.uzex.uz"

E'tiborli jihat: tradeUrl — bu bizga allaqachon tanish xarid-api-trade.uzex.uz, ya'ni Zetron'dagi UZEX integratsiyasida ishlatiladigan lug'atlar (viloyatlar, tumanlar, toifalar, mahsulotlar) shu yerda ham bir xil. Bu lug'atlarni qaytadan qurish shart emas.

3.2 Validation headeri — ochildi

Platformaning har bir API so'rovida Validation nomli sirli header bor. Bu — anti-bot himoyasi. main.js ichidagi interceptor'dan uning to'liq algoritmi topildi va u oddiy, kalitsiz va to'liq takrorlanadigan ekan:

Validation = base64( RSA_encrypt_PKCS1( PUBLIC_KEY, "<api-yo'li>~dd.MM.yyyy" ) )

Ochiq kalit ham main.js ichida ochiq turibdi (1023-bitli RSA). Ya'ni: har bir so'rov uchun "yo'l + bugungi sana" satri ochiq kalit bilan shifrlanadi. Sana kunlik almashadi, kalit statik.

Amalda buni PHP'da takrorlash ham bir necha qator:

$payload = $path . '~' . date('d.m.Y');
openssl_public_encrypt($payload, $enc, $publicKey, OPENSSL_PKCS1_PADDING);
$header = 'Validation: ' . base64_encode($enc);

3.3 So'rov sarlavhalari

04API xaritasi

main.js dan 378 ta endpoint yo'li ajratib olindi. Bizga tegishlilari quyida. To'liq ro'yxat /root/etender-auto/research/api_paths.txt faylida saqlandi.

4.1 Kuzatuv va o'qish — avtorizatsiyasiz ishlaydi

TradeList so'rov tanasi (localStorage'dagi tradeListFilter ob'ekti bilan bir xil): From, To (yozuv-offset diapazoni, sahifa raqami emas), TypeId, RegionId, District_Id, CurrencyId, System_Id: 0 va qidiruv/narx filtrlari. Javobning birinchi elementidagi total_count — umumiy soni.

4.2 Kabinet amallari — Bearer token talab qiladi

05Lot va taklif ma'lumot modeli

Bitta jonli lot (id=506376, "25 yillik yubiley uchun kristal shisha suvenirlar", "SHURTAN GAZ KIMYO MAJMUASI" MCHJ, 76 800 000 so'm) to'liq yuklab olindi va tuzilmasi ochildi. Taklif tayyorlash uchun kerak bo'lgan hamma narsa shu bitta javobda bor.

5.1 Mezon (fields) tuzilmasi — avtomatlashtirishning yuragi

Har bir mezon quyidagicha keladi (qisqartirilgan):

{
  "Type_Name": "BINARY_VALUE",
  "Label": "Товарнинг зарур техник тавсифига қўйиладиган талаблар…",
  "Is_Required": true,
  "Is_File_Required": true,            ← fayl biriktirish MAJBURIY
  "File_Name": "3-sonli shakl hamda 1 va 2-ilovasiga muvofiq shakllantiriladi",
  "Gravity": 100.0,                    ← mezon vazni (ball usulida)
  "Description": "Texnik taklif / Техническое предложение",
  "Form_Name": "Texnik taklif / Техническое предложение",
  "Control": { "Yes_text": "Согласен", "No_text": "Не согласен" }
}

Ya'ni platformaning o'zi bizga aytadi: qaysi shakl kerak (File_Name ichida "3-sonli shakl", "1 va 2-ilova" deb yozilgan), fayl majburiymi, vazni qancha. Demak hujjat generatori uchun kirish ma'lumoti tayyor — buni qo'lda kiritish shart emas. Aynan shu sabab avtomatlashtirish real.

5.2 Taklif (Bid) modeli

AddBid ga multipart/form-data ko'rinishida yuboriladigan ob'ekt:

TradeId, Old_Id, Cost, Currency_Id, Currency_Code, Currency_Curs,
DeliveringDays, Is_local_manufacturs, Is_Agree_To_Show_Files,
pledge_type_id, isLocalFile, guaranteesFile,
Products[]              ← har bir mahsulot qatori: narx, QQS, miqdor
Fields[]                ← mezon javoblari + fayllar
QualificationFields[]   ← kvalifikatsiya javoblari + fayllar
Requirements[]          ← talablar bo'yicha fayllar
Additional[], EditBankFile[]
── rasmiy yuborishda qo'shiladi ──
signed_data             ← taklifning JSON nusxasi
signature               ← shu JSON ning PKCS#7 ERI imzosi

E'tibor bering: imzo fayllarga emas, taklif ob'ektining JSON ko'rinishiga qo'yiladi. Fayllar esa oldindan UploadFile orqali yuklanadi. Bu bizga qulay: server hamma faylni oldindan joylashtirib, faqat yakuniy JSON ni imzolashga qoldiradi.

5.3 Konvert e'loni modeli

Konvert oqimidagi e'lon ancha sodda — chunki unda onlayn taklif shakli umuman yo'q:

id, display_id, name, cost, currency_name,
customer_name, customer_inn, phone, js_contacts[],
publish_term (5 kun), delivery_term (7 kun),
provision_address     ← hujjat topshiriladigan manzil
venue_address         ← konvert ochiladigan joy
delivery_address      ← mahsulot yetkaziladigan manzil
js_products[]         ← toifa, miqdor, o'lchov
js_files[]            ← xaridorning texnik hujjatlari
start_date / end_date ← taklif qabul qilish oynasi

Demak tizim bu yerda platformaga hech narsa yubormaydi. U operatorga chop etishga tayyor papka beradi: ariza, narx jadvali, texnik taklif, kvalifikatsiya hujjatlari, ilovalar ro'yxati va konvert yorlig'i — ustida xaridor nomi, manzili (provision_address), lot raqami va muddati bosilgan holda.

06ERI imzosi — to'siq emas, tanlov

Bu bo'lim loyihaning chegarasini belgilaydi va u dastlabki taxminimdan ancha yaxshi chiqdi. Qisqacha: brauzerdan tashqarida imzolashning oddiy yo'llari yopiq, lekin serverimizda allaqachon ishlaydigan, sertifikatlangan E-IMZO imzolovchisi bor. Demak to'liq avtomat yuborish ham texnik jihatdan ochiq — bu endi imkoniyat masalasi emas, siyosat masalasi.

6.1 Platforma imzoni qanday oladi

scripts.js bundle ichida E-IMZO ning rasmiy brauzer klienti (EIMZOClient, CAPIWS) turibdi. Imzolash zanjiri:

esi.sign(JSON.stringify(bid), cb)
   └─ EIMZOClient.loadKey(...)          ← operator kompyuteridagi kalit
      └─ CAPIWS → wss://127.0.0.1:64443 ← lokal E-IMZO dasturi
         └─ createPkcs7(...)            ← PKCS#7 imzo qaytadi
            └─ FormData.append("signature", pkcs7)

Ya'ni Provider/AddBid ga taklifning JSON nusxasi (signed_data) va uning PKCS#7 imzosi (signature) qo'shiladi. Imzo fayllarga emas, aynan shu JSON ga qo'yiladi — bu bizga qulay.

6.2 Nima uchun brauzerdagi oddiy yo'llar yopiq

6.3 Lekin bizda ishlaydigan imzolovchi bor — SIGN markazi

6.4 Demak ikki variant bor

Muhimi: ikkalasi ham bir xil poydevorga tayanadi — kuzatuv, tahlil, narx, hujjat generatsiyasi va qoralama. Faza 0–3 ikkala variantda ham bir xil. Tanlov faqat 4-fazada kerak bo'ladi, ya'ni hozir qaror qabul qilish shart emas.

6.5 A varianti uchun ochilishi kerak bo'lgan bitta noma'lum

Serverda imzolash uchun avval id.uzex.uz orqali ERI bilan kirish oqimini ochish kerak — ya'ni tizim Bearer tokenni o'zi olishi lozim. Bu cooperation.uz va xarid.uzex.uz uchun allaqachon qilingan ish bilan bir xil naqsh, lekin id.uzex.uz uchun alohida o'rganish talab qiladi: challenge qanday olinadi, PKCS#7 qaysi formatda kutiladi, token muddati qancha.

Bu — yarim kunlik tadqiqot ishi. Uni Faza 1 bilan parallel bajaraman va natijaga qarab A varianti realmi yoki yo'qmi, aniq javob beraman. Agar ochilmasa, B varianti to'siqsiz ishlaydi va biz hech narsa yo'qotmaymiz.

07Tavsiya etilgan arxitektura

Uch qatlam. Har birining mas'uliyati aniq ajratilgan.

7.1 Elektron oqim — to'liq zanjir

[Server]  TradeList so'rovi ────────────────► yangi lot topildi
[Server]  GetTrade → mezonlar, kvalifikatsiya, mahsulotlar
[Server]  texnik topshiriq fayli yuklandi va tahlil qilindi
[Server]  katalogga moslashtirish → narx → marja → zakalat
[Studio]  Shakl №1..№4 + texnik taklif + kvalifikatsiya PDF
[Studio]  har bir PDF ga muhr + imzo tasviri joylandi
[Operator] ko'rib chiqish ekrani → tasdiqlash
[Bridge]  UploadFile × N  →  Draft/AddBid  →  kabinetda qoralama
[Operator] etender kabinetida ochadi → ERI paroli → YUBORILDI

7.2 Konvert oqimi — to'liq zanjir

[Server]  CivilContracts/GetList ─────────► yangi e'lon topildi
[Server]  Get/{id} → mahsulotlar, manzillar, muddat, fayllar
[Server]  narx → marja → yetkazib berish shartlari
[Studio]  hujjatlar to'plami + ilovalar ro'yxati + konvert yorlig'i
[Studio]  imzo/muhr uchun BO'SH joy qoldiriladi (qo'lda bosiladi)
[Operator] bitta tugma → butun papka bitta PDF bo'lib chiqadi
[Operator] chop etish → muhr → imzo → konvert → yetkazish
[Studio]  "yuborildi" belgisi + yetkazish tasdig'i qaydnomasi

08Hujjat generatsiyasi

Tizimning eng qimmatli qismi shu. Lot detali bizga qaysi shakl kerakligini o'zi aytadi (fields[].File_Name ichida "3-sonli shakl", "1 va 2-ilova" kabi ko'rsatmalar bo'ladi), demak generator qo'lda sozlashsiz ishlay oladi.

8.1 Standart shakllar

8.2 Doimiy hujjatlar kutubxonasi

Kompaniyaning o'zgarmas hujjatlari bir marta yuklanadi va har bir taklifga avtomatik biriktiriladi: davlat ro'yxatidan o'tganlik guvohnomasi, ustav, litsenziyalar va sertifikatlar, soliq qarzi yo'qligi ma'lumotnomasi, moliyaviy hisobot, bank rekvizitlari, rahbar buyrug'i, ishonchnoma. Har biriga amal qilish muddati qo'yiladi — muddati o'tayotgan hujjat haqida tizim oldindan ogohlantiradi. Bu juda muhim: eng ko'p uchraydigan rad etish sababi — muddati o'tgan ma'lumotnoma.

8.3 Muhr va imzo

Elektron oqimda hujjatlar PDF ko'rinishida tayyorlanadi va ularga kompaniya muhri hamda rahbar imzosining tasviri joylashtiriladi. Bu — huquqiy imzo emas, balki hujjatning ko'rinishi; huquqiy kuchni esa taklifning ERI imzosi beradi (6-bo'limga qarang). Muhr tasviri xavfsiz saqlanadi va faqat generator jarayoniga beriladi.

09Ma'lumotlar bazasi

10Fazalar va vazifalar ro'yxati

Sakkiz faza, 58 vazifa. Har faza mustaqil qiymat beradi — birinchi faza tugagach tizim allaqachon foydali bo'ladi (lotlarni o'tkazib yubormaslik). Muddatlar taxminiy, bir kishilik ish sur'atida.

Jami taxminiy: 27 ish kuni. Faza 1 tugashi bilan tizim allaqachon kunlik foyda bera boshlaydi.

11Xatarlar va ularni qanday yopamiz

Huquqiy jihat

Biz platformaning ochiq API'sidan yetkazib beruvchi sifatida o'z ishimiz uchun foydalanamiz: o'z takliflarimizni tayyorlaymiz va o'z kabinetimizga joylashtiramiz. Har bir taklif vakolatli shaxs tomonidan shaxsan ERI bilan imzolanadi. Boshqa ishtirokchilarning ma'lumotlariga aralashish, imzoni chetlab o'tish yoki platformaga ortiqcha yuk berish — bularning hech biri rejaga kirmaydi va kirmaydi ham.

12Sizdan qaror kutayotgan savollar

Quyidagi ettita savolga javob bersangiz, ish darhol boshlanadi. Javob bo'lmaguncha men eng mantiqiy variantni tanlab, uni aniq belgilab qo'yaman — keyin o'zgartirish oson.

13To'liq tadqiqot logi

18.08.2026, Toshkent vaqti bilan 10:29–11:05. Har bir qadam va uning natijasi — hech narsa taxmin qilinmagan, hammasi tekshirilgan.

1. 10:31

   Server holatini o'rganish

   Avval mavjud ishlarni ko'rdim: /var/www/UZEX_SESSION_HANDOFF.md (Zetron v3 dagi UZEX shartnomalari moduli — 1,7 mln yozuv, PDF xizmati), cooperation-autofill-modern (cooperation.uz uchun avto-to'ldirish), xarid_uzex_analysis (xarid.uzex.uz API'sining oldingi teskari tahlili). Bu — bizga tayyor tajriba: lug'atlar, sur'at intizomi va PDF ishlash allaqachon sinovdan o'tgan.

2. 10:32

   Ikkala sahifa yuklab olindi

   /lots/1/0 va /civil-list — ikkalasi ham bir xil 748 baytlik HTML qaytardi. Bu Angular SPA ekanini darhol ko'rsatdi: sahifada mazmun yo'q, hammasi JavaScript orqali keladi. Demak sahifani o'qish emas, API bilan ishlash kerak.

3. 10:33

   Bundle fayllar olindi

   main.js — 9,3 MB, scripts.js — 671 KB. Ilovaning butun mantiqi shu ikki faylda.

4. 10:34

   Konfiguratsiya topildi

   main.js ichidan ilova sozlamalari to'liq chiqarildi: 9 ta domen, versiya 1.5.2 va eng muhimi — requiredEsi: true. Shu daqiqada ERI masalasi loyihaning markaziy savoliga aylanishi ma'lum bo'ldi.

5. 10:35

   Validation headeri ochildi

   HTTP interceptor kodida sirli headerning manbasi topildi: base64(RSA(ochiq_kalit, "yo'l~sana")). Ochiq kalit ham shu yerda ochiq turibdi. Ya'ni bu himoya emas, formallik — kalitsiz takrorlash mumkin.

6. 10:37

   378 endpoint ajratildi

   Controller bo'yicha guruhlandi: Customer 63, AddressList 99, Organization 26, Common 35, Provider 22, CivilContracts 12, Trade 14, Draft 7. Bizga kerakli uchtasi — Common (o'qish), Provider (yuborish), CivilContracts (konvert).

7. 10:39

   Marshrutlar va tur kodlari

   Angular marshrutlaridan lots/:typeId/:regId ning ma'nosi ochildi: typeId=1 — aynan "tanlov" (competitive). Shu bilan siz bergan havolaning nimani anglatishi aniqlandi.

8. 10:41

   Jonli sinov — header ishladi

   Python bilan header qayta yasaldi va GetTopStats chaqirildi → HTTP 200. Platformada 41 543 yetkazib beruvchi, 675 faol taklif. Bu — butun kuzatuv qismining texnik isboti.

9. 10:43

   Ikkala ro'yxat olindi

   TradeList → 626 faol tanlov loti. CivilContracts/GetList → 213 faol konvert e'loni. Ikkala oqim ham jonli va o'qiladigan holatda.

10. 10:45

    Lot detali to'liq ochildi

    GetTrade/506376/0 → mezonlar, 9 ta kvalifikatsiya talabi, mahsulot qatorlari, zakalat 3%, texnik topshiriq va shartnoma loyihasi fayllari. Muhimi: mezon ichida qaysi shakl kerakligi matn bilan yozilgan — demak hujjat generatori uchun kirish ma'lumoti tayyor.

11. 10:47

    Taklif yuborish zanjiri

    Provider/AddBid topildi va uning oldida esi.sign(...) chaqirilishi ko'rindi: taklifning JSON nusxasi imzolanadi va signature maydoniga qo'shiladi. Ya'ni imzosiz yuborish yo'q.

12. 10:49

    ERI mexanizmi tekshirildi

    scripts.js ichida EIMZOClient va CAPIWS topildi — imzo wss://127.0.0.1:64443 orqali operator kompyuteridagi dasturda yasaladi. etender'ning o'z domen kaliti ham shu faylda ochiq turibdi, lekin u boshqa domenda ishlamaydi. Oldingi loyihada isbotlangan fakt bilan birlashtirilganda (kalitlar O'zDSt kriptografiyasida, RSA emas) xulosa qat'iy: serverdan mustaqil imzo mumkin emas.

13. 10:52

    Yechim topildi — qoralama

    addOfferToDraft funksiyasi ochib ko'rildi: POST /api/Draft/AddBid?name=... — faqat Authorization va Validation headerlari bilan, imzosiz. Demak biz taklifni to'liq tayyorlab, fayllari bilan birga kabinetga qoralama qilib joylashimiz mumkin. Operatorga faqat ochish va imzolash qoladi. Bu — butun arxitektura shu topilma ustiga qurildi.

14. 10:55

    Konvert oqimi tekshirildi

    CivilContracts/Get/16141 → manzillar, muddatlar, mahsulotlar, xaridor fayllari. Onlayn taklif shakli yo'q — bu haqiqatan ham qog'oz oqimi. Demak tizimning mahsuloti — chop etishga tayyor papka.

15. 11:00

    Rasmiy integratsiya yo'li bormi

    Ochiq manbalarda qidirildi: UZEX'ning yetkazib beruvchilar uchun rasmiy hujjatlangan API'si topilmadi. Shakl №1–№4 tizimi va baholash usullari ("Ball usuli" — texnika 70 / narx 30, yoki "Eng past narx usuli") tasdiqlandi.

16. 11:05

    Tadqiqot fayllari saqlandi

    /root/etender-auto/research/ — endpointlar ro'yxati, ochiq kalit, lot va konvert namunalari, sinov skriptlari. Kod yozish boshlanganda hammasi qo'l ostida bo'ladi.

17. 11:10

    Poddomen ko'tarildi

    Siz DNS yozuvini qo'shdingiz — tender.onetech.uz uchun alohida nginx bloki yaratildi, SSL sertifikati olindi va sahifa jonli. Mavjud saytlarga tegilmadi; parallel sessiyaga nginx reload haqida oldindan xabar berildi.

18. 11:15

    Burilish nuqtasi — SIGN markazi topildi

    Siz "v3 dagi sign centr orqali ishlatamiz" deb eslatganingizdan keyin v3 ni o'qib chiqdim (faqat o'qish). Topilgan narsa dastlabki xulosamni o'zgartirdi: app/Services/SignCenter/ ichida HeadlessPkcs7Signer, EncryptedPfxVault, PfxCertificateInspector va portal autentifikatorlari bor. /opt/zetron-sign-center/lib/ da esa E-IMZO ning rasmiy sertifikatlangan kutubxonalari: yt-crypt-lib-1.5-certified, yt-crypt2-lib-1.0-certified, yt-jce-lib, cams-common-pki, e-imzo-pkcs12-reader.

    Ya'ni serverda O'zDSt imzo allaqachon ishlaydi va har kuni cooperation.uz hamda xarid.uzex.uz uchun ishlatilyapti. Demak 6-bo'limdagi "to'liq avtomat mumkin emas" degan xulosam noto'g'ri edi — u brauzer uchun to'g'ri, server uchun emas. Bo'lim to'liq qayta yozildi va rejaga A varianti qo'shildi.