2011 099PRP

MIL
LLENNIIUM CH
HALLENNGE AC
CCOUN
NT
MONNGOLIIA
on behalf
b off:
TH
HE GOV
VERNM
MENT OF MON NGOLIA
A
Funded byy
TH
HE UNIT
TED ST OF AM
TATES O MERICA
A
through
t
TH
HE MILLENNIU
UM CH
HALLEN
NGE CO
ORPOR
RATION
N
Proccurement oof
IT EQQUIPME ENT AN ND SOF FTWAR RE - Supply,
Insttallation
n and Inttegratioon
for Property Registrat
R tion Deppartmen nt of Gen
neral
Authoority for State R
Registrattion
***
CB No:
N CAA/MCA-M
M/MCC/P
PRP/GDS/099/20011
***
Date: 31
1 March, 22011
i
Contents
CONTENTS ................................................................................................................................................. II
A. General ............................................................................................................... 1

1. Scope of Bid ........................................................................................................ 2
2. Source of Funds; Compact Terms and Conditions ............................................. 3
3. Fraud and Corruption .......................................................................................... 3
4. Conflicts of Interest; Eligibility of Bidders, Suppliers, Goods and Related
Services ......................................................................................................................... 4
5. Eligible Goods and Related Services .................................................................. 7
B. Bidding Document ............................................................................................ 7
6. Sections of Bidding Document ........................................................................... 7
7. Clarification of Bidding Document .................................................................... 8
8. Amendment of Bidding Document ..................................................................... 8
C. Preparation of Bids ........................................................................................... 9
9. One Bid per Bidder ............................................................................................. 9
10. Cost of Bidding ................................................................................................... 9
11. Language of Bid .................................................................................................. 9
12. Documents Comprising the Bid .......................................................................... 9
13. Bid Submission Sheet and Price Schedule........................................................ 10
14. Alternative Bids ................................................................................................ 10
15. Bid Prices and Discounts .................................................................................. 10
16. Currencies of Bid .............................................................................................. 12
17. Documents Establishing the Eligibility of the Bidder ...................................... 12
18. Documents Establishing the Eligibility of the Goods and Related Services .... 12
19. Documents Establishing the Conformity of the Goods and Related Services .. 13
20. Documents Establishing the Qualifications of the Bidder ................................ 13
21. Period of Validity of Bids ................................................................................. 13
22. Bid Security ...................................................................................................... 14
23. Format and Signing of Bid ................................................................................ 15
D. Submission of Bids .......................................................................................... 16
24. Bid Submission ................................................................................................. 16
25. Deadline for Submission of Bids ...................................................................... 16
26. Late Bids ........................................................................................................... 17
27. Withdrawal, Substitution, and Modification of Bid.......................................... 17
E. Opening and Evaluation of Bids .................................................................... 17
28. Bid Opening ...................................................................................................... 18
29. Confidentiality .................................................................................................. 19
30. Clarification of Bids .......................................................................................... 19
31. Bid Responsiveness .......................................................................................... 19
32. Arithmetic Corrections...................................................................................... 20
ii
33. Examination of Terms and Conditions, Technical Evaluation ......................... 20
34. Conversion to Single Currency ......................................................................... 21
35. Bid Evaluation .................................................................................................. 21
36. Comparison of Bids .......................................................................................... 22
37. Domestic Preference ......................................................................................... 22
38. Post-Qualification of the Bidder ....................................................................... 22
39. Purchaser’s Right to Accept Any Bid, and to Reject Any of All Bids ............. 23
F. Award of Contract .......................................................................................... 23
40. Award Criteria .................................................................................................. 23
41. Purchaser’s Right to Vary Quantities at Time of Award .................................. 23
42. Notification of Award ....................................................................................... 23
43. Performance Security ........................................................................................ 23
44. Signing of Contract ........................................................................................... 24
45. Publication of Award and Debriefing ............................................................... 24
46. Bid Challenge System ....................................................................................... 24
47. Compact Conditionalities.................................................................................. 25
A. General ............................................................................................................. 26
B. Bidding Document .......................................................................................... 27
C. Preparation of Bids ......................................................................................... 27
D. Submission of Bids .......................................................................................... 28
E. Opening and Evaluation of Bids .................................................................... 29
F. Award of Contact ............................................................................................ 30
QUALIFICATION AND EVALUATION CRITERIA........................................................................... 31
G. General ............................................................................................................. 31

1. Qualification ..................................................................................................... 31
1.2................................................................................................................................ 31
2. Evaluation Criteria ............................................................................................ 33
3. Multiple Contracts ............................................................................................ 33
4. Post Qualification Criteria ................................................................................ 33
BID FORMS ............................................................................................................................................... 37
CONTRACT FORMS ................................................................................................................................ 62
II. Agreement ........................................................................................................ 63

III. General Conditions of Contract .................................................................... 64
1. Definitions......................................................................................................... 64
2. Interpretation and General Matters ................................................................... 67
3. Fraud and Corruption; Measures to be Taken; Commissions and Fees............ 69
4. Law and Language Governing the Contract ..................................................... 70
5. Association........................................................................................................ 70
6. Eligibility .......................................................................................................... 70
7. Notices .............................................................................................................. 71
iii
8. Settlement of Disputes ...................................................................................... 71
9. Scope of Supply ................................................................................................ 71
10. Delivery and Documents................................................................................... 71
11. Supplier’s Responsibilities ............................................................................... 72
12. Contract Price.................................................................................................... 72
13. Terms of Payment ............................................................................................. 72
14. Taxes and Duties ............................................................................................... 73
15. Performance Security ........................................................................................ 74
16. Copyright .......................................................................................................... 74
17. Confidential Information .................................................................................. 74
18. Subcontracting .................................................................................................. 76
19. Specifications and Standards ............................................................................ 76
20. Packing and Documents .................................................................................... 76
21. Insurance ........................................................................................................... 77
22. Transportation ................................................................................................... 77
23. Inspections and Tests ........................................................................................ 77
24. Liquidated Damages ......................................................................................... 78
25. Warranty ........................................................................................................... 79
26. Patent Indemnity ............................................................................................... 79
27. Limitation of Liability....................................................................................... 81
28. Change in Laws and Regulations ...................................................................... 81
29. Force Majeure ................................................................................................... 82
30. Change Orders and Contract Amendments....................................................... 83
31. Extensions of Time ........................................................................................... 84
32. Termination by Purchaser ................................................................................. 84
33. Termination by the Supplier ............................................................................. 87
34. Assignment ....................................................................................................... 88
35. Reimbursable Amounts ..................................................................................... 88
36. Accounting, Inspection and Auditing ............................................................... 88
37. Use of Funds; Compliance with Environmental Guidelines............................. 88
38. MCC Conditionalities ....................................................................................... 89
39. Flow through Provisions ................................................................................... 89
IV. Special Conditions of Contract ...................................................................... 90
V. Appendix A ...................................................................................................... 99
VI. Bank Guarantee for Performance Security ................................................ 105
SCHEDULE OF REQUIREMENTS .......................................................................................................106
iv
Letter of Invitation for Bids
Re: IT EQUIPMENT AND SOFTWARE - Supply, Installation and

Integration
for Property Registration Department of General Authority
for State Registration
Bid Ref: CA/MCA-M/MCC/PRP/GDS/099/2011

1. The Millennium Challenge Corporation (“MCC”) and the Government of
Mongolia (the “Government”) have entered into a Millennium Challenge
Compact for Millennium Challenge Account assistance to help facilitate poverty
reduction through economic growth in Mongolia (the “Compact”) in the amount
of approximately 285 MillionUSD (“MCC Funding”). The Government, acting
through Milliennium Challenge Account, Mongolia (“MCA Entity” or
“Purchaser”), intends to apply a portion of the MCC Funding to eligible payments
under a contract for which this Invitation for Bids (“IFB”) is issued.Any payments
made under the proposed contract will be subject, in all respects, to the terms and
conditions of the Compact and related documents, including restrictions on the
use of MCC funding and conditions to the disbursements of MCC funding. No
party other than the Government and the Purchaser shall derive any rights from
the Compact or have any claim to the proceeds of MCC Funding.
2. The Compact program aims to stimulate economic development and poverty reduction in
Mongolia through investments in six key areas: roads, property rights, vocational
education, health, peri-urban rangeland and clean air.
3. This Invitation for Bids follows the General Procurement Notice that appeared in
dgMarket on 2 February 2011, UNDBOnline on 2 February 2011, the MCA
Entity website www.mca.mn on 2 February 2011, and local newspapers the Daily
News 2 February 2011. The Purchaser now invites sealed bids to provide the
goods and related services referenced above (“Bids”). Procurement of IT
equipment and software – supply, installation and integration for Property
Registry Office system (Servers, PCs, printers, photocopiers, software for
registration and accounting, hubs, routers and other required computer network
and office equipment).
4. More details on the goods and related services are provided in the Schedule of
Requirements.
5. This IFB is open to all eligible entities or persons (“Bidders”) who wish to
respond. Bidders may only associate with each other in the form of a joint
venture or under a sub-contractual agreement to complement their respective
areas of supply to enhance their capacity to carry out the supply of goods and
provision of required services and so long as any association is formed or sub-
contract is entered into in accordance with the bidding document associated with
this IFB.
i
6. A supplier will be selected under the a competitive bidding method, the

evaluation procedure for which is described in sections of the bidding document
associated with this IFB in accordance with the “MCC Program Procurement
Guidelines” which are provided on the MCC website www.mcc.gov.
7. The bidding document associated with this IFB includes the following Sections:
Section 1 Instructions to Bidders

This section provides information to help Bidders prepare their
Bids; it also provides information on the submission, opening, and
evaluation of Bids and on the award of the proposed contract.
Section 2 Bid Data Sheet
This section includes provisions that are specific to this
procurement and that supplement Section 1, Instructions to
Bidders.
Section 3 Qualification and Evaluation Criteria
This section specifies the qualifications required of the Bidder and
the criteria to be used to evaluate the Bids.
Section 4 Bid Forms
This section provides the Bid Submission Form, Price Schedules
for Goods, Bid Security, the Manufacturer’s Authorization (if
required) and other forms which are to be completed by the Bidder
and submitted as part of its Bid.
Section 5 Contract Forms
I Contract Agreement
II General Conditions of Contract
III Special Conditions of Contract
IV Appendices
Appendix A Additional Provisions
V Bank Guarantee for Performance Security
Section 6 Schedule of Requirements
This section includes the detailed list of Goods and Related
Services, the Delivery and Completion Schedules, the Technical
Specifications and the Drawings that describe the Goods and
Related Services to be procured.
8. The bidding documents associated with this IFB will be placed on the Purchaser’s
website at www.mca.mn and prospective Bidders interested in submitting a Bid
should submit an e-mail, giving full contact details of the prospective Bidder, to
mongoliapa@crownagents.com.
9. A pre-Bid meeting will be held at:
Millennium Challenge Account-Mongolia
Academy of Management Building- III, Room 407
ii
Orgil Complex, Chinggis Ave, Khoroo 11, Khan-Uul District

Ulaanbaatar 210136, Mongolia
on the 15 April, 2011 at 11.00 hours Ulaanbaatar time. Attendance is strongly
advised for all prospective Bidders or their representatives but is not mandatory.
10. The closing time for receipt of Bids is 12th May, 2011 at 16.00 hours
Ulaanbaatar time, Mongolia. Bids received after this time and date shall not be
considered and will be returned unopened. Bidders should be aware that distance
and customs formalities may require longer than expected delivery time.
11. All Bids must be accompanied by a bid security (as required) in the manner and
amount specified in the Bid Data Sheet.
12 Bids will be opened in the presence of Bidders’ and/or their representatives who
choose to attend on 12th May, 2011 at 16.00 hours Ulaanbataar time, Mongolia.
Yours sincerely,
S. Bayarbaatar
Chief Executive Officer
Millennium Challenge Account – Mongolia
Academy of Management Building- III,
Orgil Complex, Chinggis Ave, Khoroo 11,
Khan-Uul District
iii
I: Instructions to Bidders CA/MCA-M/MCC/PRP/GDS/099/2011
I Instructions to Bidders
A. General
Definitions “associate” means any entity or person with whom the Bidder
associates in order to provide any part of the Goods and
Related Services.
“BDS” means the Bid Data Sheet in Section 2of this Bidding
Document used to reflect specific requirements and/or
conditions.
“Bid” means a bid for the provision of the Goods and Related
Services submitted by a Bidder in response to this Bidding
Document.
“Bidder” means any eligible entity or person, including any
associate of such eligible entity or person, that submits a
Bid.
“Bidding Document” means this document, including any
amendments that may be made, prepared by the Purchaser
for the selection of the Supplier.
“Compact” means the Millennium Challenge Compact identified
in the BDS.
“confirmation” means confirmation in writing.
“Contract” means the contract proposed to be entered into
between the Purchaser and the Supplier, including all
attachments, appendices, and all documents incorporated by
reference therein, a form of which is included in Section 5
of this Bidding Document.
“day” means a calendar day.
“Final Destination” means the place where the Goods are to be
delivered, or installed, as prescribed in ITB Sub-Clause15.6.
“Fraud and Corruption” means any of those actions defined in the
GCC (including the phrases “coercive practice,” “collusive
practice,” “corrupt practice,” “fraudulent practice,”
“obstructive practice,” and “prohibited practice” as defined
in GCC Sub-Clause 1.1), according to which action may be
taken against the Bidder, the Supplier, the Purchaser, or any
of their respective personnel.
“GCC” means the General Conditions of Contract.
“Goods” means all of the commodities, raw material, machinery
and equipment, and/or other materials that the Supplier is
required to supply to the Purchaser under the Contract.
“Government” means the Government identified in the BDS.
“Instructions to Bidders” or “ITB” means Section 1of this
Bidding Document, including any amendments, which
1
provides Bidders with information needed to prepare their

Bids.
“in writing” means communicated in written form (e.g., by mail,
e-mail or facsimile) delivered with proof of receipt.
“MCC” means the Millennium Challenge Corporation, a United
States Government corporation, acting on behalf of the
United States Government.
“Purchaser” or “MCA Entity” means the entity identified in the
BDS [full legal name of the MCA Entity] the party with
which the Supplier signs the Contract for the supply of the
Goods and Related Services.
“Related Services” means the services incidental to the supply of
the Goods such as, insurance, installation, training and
initial maintenance and other similar obligations of the
Supplier under the Contract.
“SCC” means the Special Conditions of Contract.
“Schedule of Requirements” means the documents included in
this Bidding Document as Section 6, which explains the
details of the Goods and Related Services required and the
technical specifications needed to provide the Goods and
Related Services.
“Subcontractor” means any person or entity with whom a Bidder
intends to subcontract any part of the Goods and Related
Services.
“Supplier” means the entity or person, including any associate
that provides the Goods and Related Services to the
Purchaser under the Contract.
“Taxes” has the meaning given the term in the Compact.
1. Scope of Bid 1.1 The Purchaser named in the BDS invites Bids for the
supply of Goods and Related Services incidental thereto
as described in the BDS and specified in Section 6:
Schedule of Requirements. The name and identification
number of the Contract, and number and description of
the lot(s), are specified in the BDS. The Bid will be the
basis for contract negotiations and ultimately for a
signed Contract with the Supplier should a Contract be
entered into.
1.2 Throughout this Bidding Document except where the

context requires otherwise, words indicating the singular
also include the plural and words indicating the plural
also include the singular; and the feminine means the
masculine and vice versa.
2
2. Source of Funds; 2.1 MCC and the Government have entered into the
Compact Terms Compact. The Government, acting through the
and Conditions Purchaser, intends to apply a portion of the proceeds of
MCC Funding to eligible payments under the Contract.
Payment under the Contract will be subject, in all
respects, to the terms and conditions of the Compact and
related documents, including restrictions on the use of
MCC Funding and conditions to disbursements. No
party other than the Government and the Purchaser shall
derive any rights from the Compact or have any claim to
the proceeds of MCC Funding. The Compact and
related documents are available at www.mcc.gov or at
the website of the Purchaser.
3. Fraud and 3.1 MCC requires that all beneficiaries of MCC funding,
Corruption including the Purchaser, and any bidders, suppliers,
contractors, subcontractors and Bidders under any
MCC-funded contracts, observe the highest standards of
ethics during the procurement and execution of such
contracts. In pursuance of this policy, the Purchaser:
(a) will reject a Bid if it determines that the Bidder
recommended to be selected as Supplier has,
directly or through an agent, engaged in Fraud and
Corruption in competing for the Contract;
(b) has the right to sanction a Bidder or Supplier,
including declaring the Bidder or Supplier
ineligible, either indefinitely or for a stated period
of time, to be awarded an MCC-funded contract if
at any time it determines that the Bidder or Supplier
has, directly or through an agent, engaged in Fraud
and Corruption in competing for, or in executing
such a contract; and
(c) has the right to require that a provision be included
in the Contract requiring the Supplier to permit the
Purchaser, MCC, or any designee of MCC, to
inspect its accounts, records and other documents
relating to the submission of a Bid or performance
of the Contract, and to have such accounts and
records audited by auditors appointed by MCC or
by the Purchaser with the approval of MCC.
In addition, MCC has the right to cancel the portion of
MCC Funding allocated to the Contract if it determines at
any time that representatives of a beneficiary of the MCC
Funding engaged in Fraud and Corruption during the
3
selection process or the execution of the Contract, without

the Purchaser or the beneficiary having taken timely and
appropriate action satisfactory to MCC to remedy the
situation.
MCC may also invoke, on its own behalf, any of the
rights identified for the Purchaser in ITB Sub-Clause
3.1 above.
4. Conflicts of 4.1 The Purchaser requires that Bidders and the Supplier
Interest; Eligibility hold the Purchaser’s interests paramount at all times,
of Bidders, strictly avoid conflicts with other assignments or their
Suppliers, Goods own corporate interests, and act without any
and Related consideration for future work. Without limitation on the
Services generality of the foregoing, a Bidder or Supplier
(including its associates, if any, Subcontractors and any
of their respective personnel and affiliates), may be
considered to have a conflict of interest and (i) in the
case of a Bidder may be disqualified or (ii) in the case of
a Supplier the Contract may be terminated if they:
(a) are, or have been associated in the past, with any
entity or person or any of their affiliates which have
been engaged by the Purchaser to provide
consulting services for the preparation of the
design, specifications, and other documents to be
used for the procurement of the Goods and Related
Services expected to be purchased under this
Bidding Document;
(b) are themselves, or have a business or family
relationship with, a member of the Purchaser’s
board of directors or staff or with the Procurement
Agent or Fiscal Agent (as defined in the Compact
or related agreements) hired by the Purchaser who
is directly or indirectly involved in any part of (i)
the preparation of this Bidding Document, (ii) the
Bid selection process, or (iii) supervision of the
Contract, unless the conflict stemming from this
relationship has been resolved in a manner
acceptable to MCC throughout the process of
preparing the Bidding Document and awarding and
executing the Contract; or
(c) submit more than one Bid in this bidding process,
except for alternative offers permitted under ITB
Clause 14. However, this does not limit the
participation of subcontractors in more than one
4
Bid.
Bidders and Suppliers have an obligation to disclose any
situation of actual or potential conflict that impacts their
capacity to serve the best interest of the Purchaser, or
that may reasonably be perceived as having this effect.
Failure to disclose said situations may lead to the
disqualification of the Bidder or Supplier or the
termination of the Contract.
Eligibility of 4.2 Government-Owned Enterprises (GOEs) are not eligible

Government- to compete for MCC-funded contracts. GOEs (i) may
owned Entities not be party to any MCC-funded contract for goods,
works, or services procured through an open solicitation
process, limited bidding, direct contracting, or sole
source selection; and (ii) may not be pre-qualified or
shortlisted for any MCC-funded contract anticipated to
be procured through these means. This prohibition does
not apply to Government-owned Force Account units
owned by the Government of the MCA Entity’s country,
or Government-owned educational institutions and
research centers, any statistical, mapping or other
technical entities not formed primarily for a commercial
or business purpose, or where a waiver is granted by
MCC in accordance with Part 7 of MCC’s Program
Procurement Guidelines. All Bidders must certify their
status as a part of their submission in form BSF1.
Ineligibility 4.3 Bidders and Suppliers (including their associates, if any,

and Subcontractors, and any of their respective personnel
Debarment and affiliates) shall not be any person or entity under a
declaration of ineligibility for Fraud and Corruption in
accordance with ITB Sub-Clause 3.1 above or that has
been declared ineligible for participation in a
procurement in accordance with the procedures set out
in the MCC Program Procurement Guidance paper
entitled “Excluded Parties Verification Procedures in
MCA Entity Program Procurements” that can be found
on MCC’s website at www.mcc.gov. This would also
remove from eligibility for participation in a
procurement any firm that is organized in or has its
principal place of business or a significant portion of its
operations in any Mongolia that is subject to sanction or
restriction by law or policy of the United States. Those
countries are that are subject to sanction or restriction by
law or policy of the United States as of the date of this
Bidding Document are specified in the BDS. However,
5
the countries subject to these sanctions and restrictions

are subject to change from time to time and it is
necessary to refer to the web sites identified in the
guidance paper referenced above for the most current
listing of sanctioned and restricted countries
4.4 A Bidder or Supplier (including their associates, if any,

Subcontractors, and any of their respective personnel
and affiliates) not otherwise made ineligible for a reason
described in ITB Sub-Clause 4.3 above shall be
excluded if:
(a) as a matter of law or official regulation, the
Government prohibits commercial relations with
the Mongolia of the Bidder, Supplier, their
associates, Subcontractors or their personnel;
(b) by an act of compliance with a decision of the
United Nations Security Council taken under
Chapter VII of the Charter of the United Nations,
the Government prohibits any import of goods from
the Mongolia of the Bidder, Supplier, their
associates, Subcontractors or their personnel or any
payments to persons or entities in such Mongolia;
or
(c) such Bidder, Supplier, associates, Subcontractor or
personnel are otherwise deemed ineligible by MCC
pursuant to any policy or guidance that may, from
time to time, be in effect as posted on the MCC
website at www.mcc.gov.
Joint Ventures; 4.5 Any Bidder may bid independently or in joint venture
Subcontractors confirming joint and several liability, with domestic
firms and/or with foreign firms, but MCC does not
accept conditions of bidding which require mandatory
joint ventures or other forms of mandatory association
between firms.
4.6 Any Bidder may propose to sub-contract a part of the

Contract in accordance with its terms and provided that
the names and details of the sub-contract are clearly
stated in the Bid submitted by the Bidder.
4.7 Qualification requirements for the Bidder in addition to

those set out in these Instructions to Bidders are
specified inSection 3: Qualification and Evaluation
Criteria.
6
4.8 Bidders must also satisfy the eligibility criteria

contained in the MCC Program Procurement Guidelines
governing MCC-funded procurements under the
Compact. In the case where a Bidder intends to join
with an associate or sub-contract part of the Contract,
then such associate or Subcontractor shall also be
subject to the eligibility criteria set forth in this Bidding
Document and the MCC Program Procurement
Guidelines.
4.9 Bidders shall provide such evidence of their continued

eligibility satisfactory to the Purchaser, as the Purchaser
shall reasonably request.
5. Eligible Goods 5.1 The Goods and Related Services to be supplied under
and Related the Contract may have their origin in any Mongolia
Services subject to the same restrictions specified for Bidders and
Suppliers in ITB Clause 4.
5.2 For purposes of ITB Sub-Clause 5.1, the term “origin”

means the place where the Goods have been mined,
grown, cultivated, produced, manufactured or
processed; or through manufacture, processing, or
assembly, another commercially recognized article
results that differs substantially in its basic
characteristics, purposes or utility from its underlying
components. With respect to Related Services, the term
“origin” means the place from which the Related
Services are supplied.
5.3 A Bidder that does not manufacture or produce the

Goods it offers to supply shall submit theManufacturer’s
Authorization using form BSF10 included in Section 4:
Bid Formsto demonstrate that it has been duly
authorized by the manufacturer or producer of the
Goods to supply these goods to/in Purchaser’s
Mongolia.
B. Bidding Document
6. Sections of 6.1 This Bidding Document includes all the sections
Bidding indicated below, and should be read in conjunction with
Document any amendment issued in accordance with ITB Clause 8
Section 1: Instructions to Bidders
Section 2: Bid Data Sheet
Section 3: Qualification and Evaluation Criteria
7
Section 4: Bid Forms

Section 5: Form of Contract, including
I Contract Agreement
II General Conditions of Contract
III Special Conditions of Contract
IV Appendices
Appendix A Additional Provisions
V Bank Guarantee for Performance
Security
Section 6: Schedule of Requirements
6.2 The Invitation for Bids issued by the Purchaser is not
part of the Bidding Document.
6.3 The Purchaser is not responsible for the completeness of

the Bidding Document or any amendment, if they were
not obtained directly from the Purchaser through the
procedure notified in the Bidding Document.
6.4 The Bidder is expected to examine all instructions,

forms, terms, and specifications, inclusive of
environmental, social and health and safety
requirements, in the Bidding Document. Failure to
furnish all information or documentation required by the
Bidding Document may result in the rejection of the
Bid.
7. Clarification of 7.1 A prospective Bidder requiring any clarification of the

Bidding Bidding Document shall contact the Purchaser as
Document specified in the BDS. The Purchaser shall forward
copies of its response to all those who have acquired the
Bidding Document directly from it, including a
description of the inquiry but without identifying its
source.
7.2 If a pre-bid meeting is to be conducted, it will be held at

the time and place stated in the BDS.
7.3 Should the Purchaser deem it necessary to amend the

Bidding Document as a result of a clarification, it shall
do so following the procedure under ITB Clause 8 and
Sub-Clause 25.2.
8. Amendment of 8.1 At any time prior to the deadline for submission of Bids,
Bidding the Purchaser may amend the Bidding Document by
Document issuing an amendment.
8
8.2 Any amendment issued shall (a) become a part of the

Bidding Document and (b) be communicated in writing
to all who have obtained the Bidding Document directly
from the Purchaser.
8.3 To give prospective Bidders reasonable time in which to

take an amendment into account in preparing their Bids,
the Purchaser may, at its discretion, extend the deadline
for the submission of Bids, pursuant to ITB Sub-Clause
25.2.
C. Preparation of Bids
9. One Bid per 9.1 Each Bidder shall submit only one Bid, either
Bidder individually or as a partner in a joint venture. A Bidder
who submits or participates in more than one Bid (other
than as a subcontractor or in cases of alternatives that
have been permitted or requested) shall cause all the
Bids with the Bidder’s participation to be disqualified
10. Cost of Bidding 10.1 The Bidder shall bear all costs associated with the
preparation and submission of its Bid and Contract
negotiations, if any, and the Purchaser shall not be
responsible or liable for those costs, regardless of the
conduct or outcome of the bidding process.
11. Language of Bid 11.1 The Bid, as well as all correspondence and documents
relating to the Bid exchanged by a Bidder and the
Purchaser, shall be written in English language as
specified in the BDS. If Bids are to be submitted in both
English and [local] languages, the English version shall
govern. Supporting documents and printed literature
that are part of the Bid may be in another language
provided they are accompanied by an accurate
translation of the relevant passages into English, in
which case, for purposes of interpretation of the Bid,
such English translation shall govern.
12. Documents 12.1 The Bid submitted by the Bidder shall comprise the
Comprising the following:
Bid (a) Bid Submission Sheet and the applicable Price
Schedules for Goods (using the forms furnished
inSection 4), in accordance with ITB Clauses 13, 15
and 16;
(b) Bid Security, in accordance with ITB Clause22;
9
(c) written confirmation authorizing the signatory of

the Bid to commit the Bidder, in accordance with
ITB Clause 23;
(d) documentary evidence in accordance with ITB
Clause 17 establishing the Bidder’s eligibility to
Bid;
(e) documentary evidence in accordance with ITB
Clause 18, that the Goods and Related Services to
be supplied by the Bidder are of eligible origin;
(f) documentary evidence in accordance with ITB
Clauses 19, that the Goods and Related Services
conform to the Bidding Document;
(g) documentary evidence in accordance with ITB
Clause 20 establishing the Bidder’s qualifications to
perform the contract if its Bid is accepted; and
(h) any other document as specified in the BDS.
13. Bid Submission 13.1 A Bidder shall submit the Bid Submission Form (BSF1)
Sheet and Price furnished in Section 4: Bid Forms. This form must be
Schedule completed without any alterations to its format, and no
substitutes shall be accepted. All blank spaces shall be
filled in with the information requested.
13.2 A Bidder shall submit the Price Schedules for Goods,

according to their origin as appropriate, using the forms
furnished in Section 4: Bid Forms.
14. Alternative Bids 14.1 Unless otherwise specified in the BDS, alternative Bids
shall not be considered.
15. Bid Prices and 15.1 The prices and discounts quoted by a Bidder in the Bid
Discounts Submission Sheet and in the Price Schedules for Goods
shall conform to the requirements specified below.
15.2 All lots and items must be listed and priced separately in
the Price Schedules for Goods. If a Price Schedule for
Goods shows items listed but not priced, their prices
shall be assumed to be included in the prices of other
items. Lots or items not listed in the Price Schedule for
Goods shall be assumed not to be included in the Bid,
and provided that the Bid is substantially responsive, the
corresponding adjustment, as appropriate, shall be
applied in accordance with ITB Clause 32.
15.3 The price to be quoted in the Bid Submission Sheet shall
10
be the total price of the Bid, excluding any discounts

offered.
15.4 The Bidder shall quote any unconditional discounts and

indicate the method for their application in the Bid
Submission Sheet.
15.5 The terms EXW, CIF, CIP, and other similar terms shall
be governed by the rules prescribed in Incoterms 2000,
published by The International Chamber of Commerce.
15.6 Prices shall be quoted as specified in each Price

Schedule for Goods included in Section 4: Bid Forms
and shall be entered in the following manner:
(a) For Goods manufactured in Purchaser’s Mongolia:
(i) the price of the Goods quoted EXW (ex works, ex
factory, ex warehouse, ex showroom, or off-the-
shelf, as applicable); and
(ii) the price for inland transportation, insurance, and
other local services required to convey the Goods
to their Final Destination specified in the BDS.
(b) For Goods manufactured outside Purchaser’s
Mongolia, to be imported:
(i) the price of the Goods, quoted in CIP to their Final
Destination specified in the BDS. In quoting the
price, a Bidder shall be free to use transportation
through carriers registered in any eligible
countries. Similarly, a Bidder may obtain
insurance services from any eligible source
Mongolia;
(c) For Goods manufactured outside Purchaser’s
Mongolia, already imported:
(i) the price of the Goods, including the original
import value of the Goods; plus any mark-up (or
rebate); plus any other related local cost and Taxes
already paid in connection with the importation of
the Goods; and
11
(d) For Related Services, other than inland

transportation and other services required to convey
the goods to their Final Destination, whenever such
Related Services are specified in the Schedule of
Requirements, the price of each item comprising the
Related Services.
15.7 Prices quoted by the Bidder shall be fixed during a

Bidder’s performance of the Contract and not subject to
variation on any account, unless otherwise specified in
the BDS. A Bid submitted with “adjustable prices”
shall be treated as non-responsive and shall be rejected,
pursuant to ITB Clause 31. However, if in accordance
with the BDS, prices quoted by the Bidder shall be
subject to adjustment during the performance of the
Contract, a Bid submitted with a fixed price quotation
shall not be rejected, but the price adjustment shall be
treated as zero.
15.8 If so indicated in the BDS Clause 1.1, Bids shall be

invited for individual contracts (lots) or for any
combination of contracts (packages). Unless otherwise
indicated in the BDS, prices quoted shall correspond to
100% of the items specified for each lot and to 100% of
the quantities specified for each item of a lot. Bidders
wishing to offer any price reduction (discount) for the
award of more than one contract shall specify the
applicable price reduction in accordance with ITB Sub-
Clause 15.4 provided the Bids for all lots are submitted
and opened at the same time.
15.9 GCC Clause 14of the Contract Forms (Section 5) sets

forth the tax provisions of the Contract. Bidders should
review this clause carefully in preparing their Bid.
16. Currencies of Bid 16.1 The Bidder may express the Bid only in US Dollar or in
the local currency of the Purchaser’s Mongolia.
17. Documents 17.1 To establish their eligibility in accordance with ITB

Establishing the Clause4, Bidders shall complete the Bid Submission
Eligibility of the Form (BSF1), included in Section 4: Bid Forms.
Bidder
18. Documents 18.1 To establish the eligibility of the Goods and Related
Establishing the Services in accordance with ITB Clause5, Bidders shall
Eligibility of the complete the Mongolia of origin declarations in the
Goods and Price Schedule for Goods Forms (BSF2, BSF3),
12
Related Services included in Section 4: Bid Forms.
19. Documents 19.1 To establish the conformity of the Goods and Related
Establishing the Services to the Bidding Document, the Bidder shall
Conformity of the furnish as part of its Bid the documentary evidence that
Goods and the Goods conform to the technical specifications,
Related Services including EHS requirements, and standards specified in
Section 6: Schedule of Requirements.
19.2 The documentary evidence may be in the form of

literature, drawings or data, and shall consist of a
detailed item by item description of the essential
technical and performance characteristics of the Goods
and Related Services, demonstrating substantial
responsiveness of the Goods and Related Services to the
technical specification, including EHS requirements,
and if applicable, a statement of deviations and
exceptions to the provisions of the Schedule of
Requirements.
19.3 A Bidder shall also furnish a list giving full particulars,

including available sources and current prices of spare
parts, special tools, etc., necessary for the proper and
continuing functioning of the Goods during the period
specified in the BDS, following commencement of the
use of the Goods by the Purchaser.
19.4 Standards for workmanship, process, material, and

equipment, as well as references to brand names or
catalogue numbers specified by the Purchaser in the
Schedule of Requirements, are intended to be
descriptive only and not restrictive. A Bidder may offer
other standards of quality, brand names, and/or
catalogue numbers, provided that it demonstrates, to
Purchaser’s satisfaction, that the substitutions ensure
substantial equivalence or are superior to those specified
in the Schedule of Requirements.
20. Documents 20.1 The documentary evidence of the Bidder’s

Establishing the qualifications to perform the Contract if its Bid is
Qualifications of accepted shall establish to Purchaser’s satisfaction the
the Bidder criteria specified in Section 3: Qualification and
Evaluation Criteria.
21. Period of Validity 21.1 Bids shall remain valid for one hundred and twenty
of Bids (120) days after the Bid submission date unless
otherwise specified in the BDS. A Bid valid for a
13
shorter period shall be rejected by the Purchaser as non-

responsive.
21.2 In exceptional circumstances, prior to the expiration of

the Bid validity period, the Purchaser may request
Bidders to extend the period of validity of their Bids.
The request and the Bidder’s responses shall be made in
writing. If required, the Bid Security shall also be
extended for a period of twenty-eight (28) days beyond
the deadline of the extended bid validity period. A
Bidder may refuse the request without forfeiting its Bid
security. A Bidder granting the request shall not be
required or permitted to modify its Bid, except as
provided in ITB Clause 27.
22. Bid Security 22.1 The Bid Security shall be in the amount specified in the
BDS and denominated only in US$ or in local currency
of the Purchaser’s Mongolia, and shall:
(a) at the Bidder’s option, be in the form of either
irrevocable letters of credit or a bank guarantees
substantially in the format of Form BSF8: Bid
Security Form (Bank Guarantee)(Section 4: Bid
Forms);
(b) be issued by a reputable institution selected by the
Bidder and located in any eligible Mongolia (as
determined in accordance with ITB Clause4); if the
institution issuing the bank guarantee is located
outside Purchaser’s Mongolia, it shall have a
correspondent financial institution located within
Purchaser’s Mongolia to make it enforceable;
(c) be payable promptly upon written demand by the
Purchaser in case the conditions listed in ITB
Clause 22.2are invoked;
(d) be submitted in its original form; copies will not be
accepted
(e) remain valid for a period of twenty-eight (28) days
beyond the original validity period of Bids, or
beyond any period of extension subsequently
requested under ITB Sub-Clause 21.2.
22.2 Any Bid not accompanied by a substantially responsive

Bid Security (if required) in accordance with ITB
Clause22, shall be rejected by the Purchaser as
nonresponsive. The Bid Security may be forfeited:
14
(a) if a Bidder withdraws its Bid during the period of

Bid validity specified by the Bidder on the Bid
Submission Sheet, except as provided in ITB Sub-
Clause 21.2;
(b) if a Bidder does not accept the correction of its Bid
Price pursuant to ITB Sub-Clause 32.2; or
(c) if the successful Bidder fails within the specified
time to:
(i) furnish the required Performance Security in
accordance with GCC Clause 15 as described in
ITB Clause43; or
(ii) sign the Contract in accordance with ITB Clause
44.
22.3 The Bid Security of a joint venture must be in the name
of the joint venture that submits the Bid. If the joint
venture has not been legally constituted at the time of
bidding, the Bid Security shall be in the names of all
future partners as named in the letter of intent or similar
document in connection with the formation of the joint
venture.
23. Format and 23.1 A Bidder shall prepare ONE (1) original set of the
Signing of Bid documents comprising the Bid pursuant to ITB Clause
12 and clearly mark it “ORIGINAL.” The original shall
be typed or written in indelible ink and shall be signed
by a person duly authorized to sign on behalf of the
Bidder. This authorization shall consist of a written
confirmation as specified in the BDS and shall be
attached to the Bid. The person or persons signing the
Bid shall initial all pages of the Bid where entries and
amendments have been made.
23.2 In addition, the Bidder shall prepare copies of the Bid

(photocopies of the signed original are acceptable), in
the number specified in the BDS and clearly mark them
“COPY.” In the event of discrepancy between the
original and the copies, the original shall prevail.
23.3 The Bid shall contain no alterations or additions, except

those to comply with the instructions issued by the
Purchaser, or as necessary to correct errors made by the
Bidder, in which case such corrections shall be initialled
by the person or persons signing the Bid.
15
23.4 The Bidder shall furnish information as described in the

Bid Submission Form (BSF1) Section 4: Bid Forms on
commissions and gratuities, if any, paid or to be paid to
agents relating to this Bidding Document or its Bid or to
Contract execution if the Bidder is awarded the
Contract.
D. Submission of Bids
24. Bid Submission 24.1 Bidders may always submit their Bids by mail or by
hand. When so specified in the BDS, Bidders shall have
the option of submitting their Bids electronically.
Bidders are reminded that distance and customs
formalities may require longer than expected delivery
times.
(a) For all Bids submitted in hard copy, Bidders shall
enclose the original and each copy of the Bid in
separate sealed envelopes, duly marking the
envelopes as “ORIGINAL” and “COPY.” These
envelopes containing the original and the copies
shall then be enclosed in one single envelope.
(b) Bidders submitting bids electronically shall follow
the electronic bid submission procedures specified
in the BDS.
24.2 The inner and outer envelopes containing Bids shall:

(a) bear the name and address of the Bidder;
(b) be addressed to the Purchaser at the address
specified in the BDS;
(c) bear the specific identification number of the
Contract as indicated in ITB Sub-Clause 1.1 and
any additional identification marks as specified in
the BDS;
(d) provide a warning “not to be opened before the time
and date for Bid opening”; and
(e) be marked “Bid Submission.”
If all envelopes are not sealed and marked as required,
the Purchaser will assume no responsibility for the
misplacement or premature opening of the Bid.
25. Deadline for 25.1 Bids must be received by the Purchaser at the address
Submission of and no later than the date and time specified in the BDS.
16
Bids
25.2 The Purchaser may, at its discretion, extend the deadline

for the submission of Bids by issuing an amendment in
accordance with ITB Clause 8, in which case all rights
and obligations of the Purchaser and the Bidders
previously subject to the original deadline shall then be
subject to the deadline as extended.
26. Late Bids 26.1 The Purchaser shall not consider any Bid that arrives
after the deadline for submission of Bids, in accordance
with ITB Clause 25. Any Bid received by the Purchaser
after the deadline for submission of Bids shall be
declared late, rejected and returned unopened to the
Bidder.
27. Withdrawal, 27.1 A Bidder may withdraw, substitute, or modify its Bid
Substitution, and prior to the deadline for the submission of Bids by
Modification of sending a written notice in accordance with ITB Clause
Bid 23 and this ITB Sub-Clause 27.1, duly signed by an
authorized representative, and shall include a copy of
the authorization of the person signing in accordance
with ITB Sub-Clause 23.1, (except that no copies of the
withdrawal notice are required). The corresponding
substitution or modification of the Bid must accompany
the respective written notice. All notices must be:
(a) submitted in accordance with ITB Clauses 24 and
25 (except that withdrawal notices do not require
copies), and in addition, the respective envelopes
shall be clearly marked “WITHDRAWAL,”
“SUBSITUTION,” or “MODIFICATION” and
(b) received by the Purchaser prior to the deadline
prescribed for submission of bids, in accordance
with ITB Clause 25.
27.2 Bids requested to be withdrawn in accordance with ITB

Sub-Clause 27.1shall be returned unopened to the
Bidders.
27.3 No bid may be withdrawn, substituted, or modified in

the interval between the deadline for submission of bids
and the expiration of the period of bid validity specified
by the Bidder on the Bid Submission Form or any
extension thereof.
E. Opening and Evaluation of Bids
17
28. Bid Opening 28.1 The Purchaser shall open Bids in the presence of
Bidders’ and/or their representatives who choose to
attend at the time and in the place specified in the BDS.
Any specific opening procedures required if electronic
Bidding is permitted in accordance with the BDS, shall
be as specified in the BDS.
28.2 Firstly, e-mail files or envelopes marked

“WITHDRAWAL” shall be opened and read out, and
Bids for which an acceptable notice of withdrawal has
been submitted pursuant to ITB Clause 27 shall not be
opened. No Bid withdrawal shall be permitted unless the
corresponding withdrawal notice contains a valid
authorization to request the withdrawal and is read out at
Bid opening. Next, e-mail files or envelopes marked
“SUBSTITUTION” shall be opened and read out and
exchanged with the corresponding Bid being substituted,
and the substituted Bid shall not be opened, but returned
to the Bidder. No Bid substitution shall be permitted
unless the corresponding substitution notice contains a
valid authorization to request the substitution and is read
out at Bid opening. E-mail files or envelopes marked
“MODIFICATION” shall be opened and read out with
the corresponding Bid. No Bid modification shall be
permitted unless the corresponding modification notice
contains a valid authorization to request the
modification and is read out at Bid opening. Only e-mail
files or envelopes that are opened and read out at Bid
opening shall be considered further.
28.3 The e-mail files or envelopes marked “BID

SUBMISSION” shall be opened at this time. Such e-
mail file or envelope shall be opened one at a time,
reading out: the Bidders’ names, the Bid prices, the total
amount of each Bid and of any alternative Bid (if
alternatives have been requested or permitted), any
discounts, substitutions, or modifications, the presence
or absence of Bid Security and such other details as the
Purchaser may consider appropriate, shall be announced
by the Purchaser at the opening. No Bid shall be
rejected at Bid opening except for the late Bids pursuant
to ITB Clause 26. Substitution Bids and modifications
submitted pursuant to ITB Clause 27 that are not opened
and read out at Bid opening shall not be considered for
further evaluation regardless of the circumstances. Late,
withdrawn and substituted Bids shall be returned un-
18
opened to Bidders.
28.4 The Purchaser shall prepare minutes of the Bid opening,

including the information disclosed to those present in
accordance with ITB Sub-Clause 28.3. A copy of the
record shall be distributed to all Bidders who submitted
bids in time, and posted online when electronic bidding
is permitted.
29. Confidentiality 29.1 Information relating to the examination, clarification,

evaluation, and comparison of Bids and
recommendations for the award of the Contract shall not
be disclosed to the Bidders or any other persons not
officially concerned with such process until publication
of the award to the successful Bidder has been
announced pursuant to ITB Sub-Clause 45.1. The undue
use by any Bidder of confidential information related to
the process may result in the rejection of its Bid and
may subject the Bidder to the provisions of the
Government’s, the Purchaser’s and MCC’s antifraud
and corruption policies.
29.2 Any effort by a Bidder to influence Purchaser’s

processing of Bids or award decisions may result in the
rejection of its Bid.
29.3 Notwithstanding the above, from the time of Bid

opening to the time of Contract award, if any Bidder
wishes to contact the Purchaser on any matter related to
the bidding process, it should do so in writing.
30. Clarification of 30.1 To assist in the examination, evaluation, and comparison

Bids of Bids, the Purchaser may, at its discretion, ask any
Bidder for a clarification of its Bid. The request for
clarification and the response shall be in writing, but no
change in the price or substance of the Bid shall be
sought, offered, or permitted except as required to
confirm the correction of arithmetic errors discovered by
Purchaser in the evaluation of the Bids in accordance
with ITB Clause 32.
31. Bid 31.1 A substantially responsive Bid is one that conforms to

Responsiveness all the terms, conditions, and specifications of the
Bidding Document without material deviation or
reservation. A material deviation or reservation is one
that:
(a) affects in any substantial way the scope, quality, or
19
performance of the Goods; or

(b) limits in any substantial way, inconsistent with the
Bidding Document, the Purchaser’s rights or the
Bidder’s obligations under the Contract; or
(c) if rectified would unfairly affect the competitive
position of other Bidders presenting substantially
responsive Bids.
31.2 If a Bid is not substantially responsive, it shall be

rejected by the Purchaser, and may not subsequently be
made responsive by correction or withdrawal of the non-
conforming deviation or reservation.
32. Arithmetic 32.1 Provided that the Bid is substantially responsive, the
Corrections Purchaser shall correct arithmetical errors on the
following basis:
(a) if there is a discrepancy between the unit price and
the line item total that is obtained by multiplying
the unit price by the quantity, the unit price shall
prevail and the line item total shall be corrected,
unless in the opinion of the Purchaser there is an
obvious misplacement of the decimal point in the
unit price, in which case the line item total as
quoted shall govern and the unit price shall be
corrected;
(b) if there is an error in a total corresponding to the
addition or subtraction of subtotals, the subtotals
shall prevail and the total shall be corrected; and
(c) if there is a discrepancy between words and figures,
the amount in words shall prevail, unless the
amount expressed in words is related to an
arithmetic error, in which case the amount in
figures shall prevail subject to (a) and (b) above.
32.2 If the Bidder that submitted the lowest-evaluated Bid

does not accept the correction of errors, its Bid shall be
rejected and the Bid Security may be forfeited in
accordance with ITB Sub-Clause 22.2(b).
33. Examination of 33.1 The Purchaser shall examine the Bid to confirm that all
Terms and terms and conditions specified in the GCC and the SCC
Conditions, have been accepted by the Bidder without any material
Technical deviation or reservation.
Evaluation
20
33.2 The Purchaser shall evaluate the technical aspects of the

Bid submitted in accordance with ITB Clause 19, to
confirm that all requirements specified in the Schedule
of Requirements of the Bidding Document have been
met without any material deviation or reservation.
33.3 If, after the examination of the terms and conditions and
the technical evaluation, the Purchaser determines that
the Bid is not substantially responsive in accordance
with ITB Clause 31, it shall reject the Bid.
34. Conversion to 34.1 For evaluation and comparison purposes, the Purchaser
Single Currency shall convert all Bid prices expressed in the amounts in
both US Dollars and in the local currency of Purchaser’s
Mongolia into US Dollars, using the selling exchange
rate published by the Central Bank of Purchaser’s
Mongolia or other sources as agreed in the BDS on the
date specified in the BDS.
35. Bid Evaluation 35.1 The Purchaser’s evaluation of a Bid will exclude and not
take into account:
(a) any Taxes other than Taxes already paid in
connection with the importation of Goods
manufactured outside of the Purchaser’s Mongolia
that are already imported to the extent such Taxes
are identified appropriately on form BSF4 (Price
Schedule for Goods Manufactured Outside
Purchaser’s Mongolia, already Imported) set out in
Section 4: Bid Forms; and
(b) any allowance for price adjustment during the
period of execution of the contract, if provided in
the Bid.
(c) any other factors specified as being excluded in
Section 3: Qualification and Evaluation Criteria.
35.2 The Purchaser’s price evaluation of a Bid may require

the consideration of other factors, in addition to the Bid
price quoted in accordance with ITB Clause15. These
factors may be related to the characteristics,
performance, and terms and conditions of purchase of
the Goods and Related Services. The effect of the
factors selected, if any, shall be expressed in monetary
terms to facilitate comparison of Bids, unless otherwise
specified in Section 3: Qualification and Evaluation
Criteria.
21
35.3 If so indicated in the BDS, the Bidding Document shall

allow Bidders to quote separate prices for one or more
lots, and shall allow the Purchaser to award one or
multiple lots to more than one Bidder. The
methodology of evaluation to determine the lowest-
evaluated lot combinations is specified in Section 3:
Qualification and Evaluation Criteria.
35.4 In accordance with the MCC Program Procurement

Guidelines, the Bidder’s past performance on MCC-
funded contracts will be considered as a criterion in the
Purchaser’s evaluation of the Bid.
36. Comparison of 36.1 The Purchaser shall compare all substantially responsive
Bids Bids to determine the lowest-evaluated Bid, in
accordance with ITB Clause 35.
37. Domestic 37.1 Domestic preference shall not be a factor in the Bid
Preference evaluation of any Bid submitted.
38. Post-Qualification 38.1 The Purchaser shall determine to its satisfaction whether
of the Bidder the Bidder that is selected as having submitted the
lowest evaluated and substantially responsive Bid is
qualified to perform the Contract satisfactorily.
38.2 The determination shall be based upon an examination

of the documentary evidence of a Bidder’s qualifications
submitted by a Bidder and the qualification criteria
indicated in Section 3: Qualification and Evaluation
Criteria.
38.3 The Purchaser reserves the right to request additional

information with which to conduct a risk assessment of
legal, technical and financial capacity of the Bidder that
is selected for Contract award. The selected Bidder if
requested shall demonstrate that:
(a) is not involved in any litigation in respect of its
bankruptcy, readjustment or liquidation;
(b) has a record of successful completion of similar
contracts; and
(c) has an average annual turnover, or other evidence of
financial strength reasonably sufficient to perform a
contract in the amount of the Bid.
38.4 An affirmative determination shall be a prerequisite for

award of the Contract to a Bidder. A negative
22
determination shall result in disqualification of the Bid,

in which event the Purchaser shall proceed to the next
lowest evaluated Bid to make a similar determination of
that Bidder’s capabilities to perform satisfactorily.
39. Purchaser’s Right 39.1 The Purchaser reserves the right to accept or reject any
to Accept Any Bid, and to annul the bidding process and reject all Bids
Bid, and to Reject at any time prior to Contract award, without thereby
Any of All Bids incurring any liability to any Bidder.
F. Award of Contract
40. Award Criteria 40.1 The Purchaser will award the Contract to the Bidder
whose offer has been determined to be the lowest
evaluated Bid and is substantially responsive to the
Bidding Document, provided further that the Bidder is
determined to be qualified to perform the Contract
satisfactorily.
41. Purchaser’s Right 41.1 At the time the Contract is awarded, the Purchaser
to Vary Quantities reserves the right to increase or decrease the quantity of
at Time of Award Goods and Related Services originally specified in
Section 6: Schedule of Requirements, provided this does
not exceed the percentages indicated in the BDS, and
without any change in the unit prices or other terms and
conditions of the Bid and the Bidding Document.
42. Notification of 42.1 Prior to the expiration of the period of Bid validity, the
Award Purchaser shall notify the successful Bidder, in writing,
that its Bid has been accepted using a Notification of
Award substantially in the format of form BSF11 set out
in Section 4: Bid Forms.
42.2 Until a formal contract is prepared and executed, the

Notification of Award shall constitute a binding
Contract.
43. Performance 43.1 Within fourteen (14) days of receipt of the Notification
Security of Award from the Purchaser, the successful Bidder
shall furnish a Performance Security in accordance with
GCC Clause 15, using for that purpose the Performance
Security Form included in Section 5: Contract Forms.
43.2 Failure of the successful Bidder to submit the

Performance Security or to sign the Contract in
accordance with ITB Sub-Clauses 43.1 and 44.2
respectively shall constitute sufficient grounds for the
23
annulment of the award and forfeiture of the Bid

Security. In that event the Purchaser may award the
Contract to the next lowest evaluated Bidder, whose
offer is substantially responsive and is determined by
the Purchaser to be qualified to perform the Contract
satisfactorily or call for new Bids or annul the bidding
process.
44. Signing of 44.1 Promptly after notification, the Purchaser shall send the
Contract successful Bidder the Contract based on the forms
included in Section 5.
44.2 Within fourteen (14) days of receipt of the Contract, the

successful Bidder shall sign, date, and return the
Contract to the Purchaser.
44.3 Upon the successful Bidder signing the Contract and

providing the Performance Security, the Purchaser will
promptly notify the name of the winning Bidder to each
unsuccessful Bidder and will discharge the Bid
Securities to all Bidders.
45. Publication of 45.1 After the award of Contract, the Purchaser will publish
Award and on the same venues as it published the General
Debriefing Procurement Notice related to this Bidding Document
the results identifying the procurement, the name of the
winning Bidder and the price, duration, and summary
scope of the Contract. The same information will be sent
to all Bidders who have submitted Bids.
45.2 The Purchaser will promptly respond in writing to any

unsuccessful Bidder who, after publication of the
Contract award in accordance with ITB Sub-Clause
45.1, requests the Purchaser in writing to explain on
which grounds its Bid was not successful.
46. Bid Challenge 46.1 Any Bidder has the right to complaint and appeal, but
System must do so in the manner and format as set down in the
bid challenge system as published on the Purchaser’s
website.
24
47. Compact 47.1 Bidders are advised to examine and consider carefully
Conditionalities the provisions that are set forth in Appendix A to the
Contract as these are a part of the Government’s and the
Purchaser’s obligations under the Compact and related
documents which, under the terms of the Compact and
related documents, are required to be transferred onto
any Bidder, Supplier or Subcontractor who partakes in
procurement or subsequent contracts in which MCC
funding is involved.
47.2 The provisions set forth in Appendix A to the Contract

apply during the bidding procedures as well as
throughout the performance of the Contract.
25
II: Bid Data Sheet CA/MCA-M/MCC/PRP/GDS/099/2011
II Bid Data Sheet

A. General
ITB Definitions “Compact” means the Millennium Challenge Compact between the
United States of America, acting through the Millennium Challenge
Corporation, and the Government, entered into on 22 October 2007, as
may be amended from time to time.
“Government” means the government of Mongolia.
“Purchaser” or “MCA Entity” means “Purchaser” or “MCA Entity”
means: Millennium Challenge Account – Mongolia.
The Purchaser is: Millennium Challenge Account – Mongolia
ITB 1.1
The Goods and Related Services are:
1(a). The supply of goods /hardware and software/ to accomplish
the digitization process and its related services
1(b). The supply of goods /hardware and software/ to roll-out the
ePRS(electronic Property Registry System) /electronic
property rights system/ and its related
services.
2. Services related to digitization and conversion of existing
paper archives and digital data of the Property Rights
Registration Department of General Authority for State
Registration (GASR).
3. Development of ePRS.
The name and identification of the proposed Contract is:
CA/MCA-M/MCC/PRP/GDS/099/2011
Procurement of electronic Property Registry System, IT equipment
(Servers, workstations, high speed sanners, printers, system software,
hubs, routers and other required computer network and office
equipment) The number and description of the lot(s) is: Lot 1; which
comprises:
Pillar I - SR1/I(a) - List of Goods, Services and Delivery Schedule
necessary to accomplish the digitization process
SR2/I(a) - List of related Services for the delivery of the
digitalization and data conversation equipments
SR1/I(b) - List of Goods, Services and Delivery Schedule
necessary to roll-out the ePRS
SR2/I(b) - List of related Services to the delivery of all
equipments related to roll-out of the ePRS
Pillar II - SR1/II – List of Services and Completion Schedule related
to digitization of paper archive and conversion of
existing digital data
Pillar III - SR1/III – List of Services and Completion Schedule related
26
to the development and implementation of the

Electronic Mongolia Registry System /ePRS/
ITB 4.3 As of the date of this Bidding Document, the countries that are subject
to sanction or restriction by law or policy of the United States include
Cuba, Iran, North Korea, Sudan and Syria
B. Bidding Document
ITB 7.1 Clarifications may be requested by e-mail up to 20 days before the date
for submission of Bids, so that responses can be issued to all Bidders
no later than 14 days prior to the date for submission of Bids.
The e-mail address(es) for requesting clarification is:
mongoliapa@crownagents.com
ITB 7.2 A pre-bid meeting will be held on 15th April 2011 at 11.00 hours
Ulaanbaatar time at:
Academy of Management Building- III, 3rd floor, Room 407
Attendance, is strongly advised for all prospective Bidders or their

representatives but is not mandatory.
ITB 11 Bids shall be submitted in English.
C. Preparation of Bids
ITB 12.1(h) A Bidder shall submit with its Bid the following additional documents
which will comprise a part of the Bid:
(a) the associated documentation for related hardware,
software, supplies, and consumable items called ”Equipment”
that the Supplier is required to supply and install under the
Contract
(b) the warranty documentation for the Equipment that
covers the warranty period specified in the Contract.
(c) in the case of a Bidder offering to supply the Equipment
under the Contract that the Bidder did not itself manufacture or
otherwise produce, the Bidder has been duly authorized by the
Manufacturer or producer to supply those components in the
Purchaser’s Mongolia. (This will be accomplished by
submission of Manufacturer’s Authorization Forms)
27
(d) proven experience (references) in project developments

(at least two) of a similar nature and size for the last five years,
and details of services under way or contractually committed;
and names and address of clients who may be contacted for
further information on those contracts
(e) Products delivery list
ITB 14.1 Alternative bids shall not be considered.
ITB15.6(a)(ii) The Final Destinations of Goods are:

& ITB Site Code Site City / Town / Region
15.6(b)(ii)& CO GASR Central Office Ulaanbaatar
ITB 15.6(c)(ii) Ulaanbaatar city district
TO01 OfficesBaganuur, Bayanzurkh,
Chingeltei, Songino-Khairkhan
RO02 Regional Office Darhan-Uul Darhan-Uul
RO03 Regional Office Dornod Dornod
Regional Office Zavhan
RO04 Zavhan
Regional Office Orkhon
RO05 Orkhon
RO06 Regional Office Ovorhangai Ovorhangai
RO07 Regional Office Hovd Hovd
RO08 Regional Office Hentii Hentii
RO09 Regional Office Tov Tov
ITB 15.7 The prices quoted by a Bidder shall be fixed for the duration of the
Contract.
ITB 15.8 Price quoted for each lot shall not be different from the requirements
specified in the ITB.
ITB 19.3 The list of spare parts, special tools, etc., shall cover a period of 2 years
from the date of acceptance of the Goods by the Purchaser.
ITB 21.1 The Bid validity period is 120 days.
ITB 22.1 Bid Security is required to be submitted with a Bid.
ITB 22.2 The Bid Security shall be a minium of 1% of the Bid Price in United
States Dollars or Purchaser’s local currency equivalent only.
ITB 23.1 The written confirmation of authorization to sign on behalf of and bind
the Bidder shall consist of: Notary witnessed Power of Attorney.
ITB 23.2 The number of copies of the Bid submitted shall be 3.
D. Submission of Bids
28
ITB24.1 Bids may not be submitted electronically.
ITB24.1(b) Not Applicable.
ITB24.2(b) For Submission of Bid purposes only, The Purchaser’s address is:
Millennium Challenge Account, Mongolia
Att.: The Procurement Agent of MCA-Mongolia
Crown Agents Inc
Procurement Agent for
For Attn: Procurement Agent Manager
Tel: +976 70120032; Fax: +976 70120031
Email: mongoliapa@crownagents.com
ITB24.2(c) Identification marks on the envelopes shall include:

Property Registry System
ITB25.1 The deadline for submission of Bids is as follows:

12th May, 2011 at 16.00 hours (local time)
E. Opening and Evaluation of Bids

ITB28.1 For Bid opening purposes only, the Purchaser’s address is:
MillenniumChallengeAccount-Mongolia
Source of the exchange rate shall be: Mongolbank (Central Bank)

ITB34.1
Date of the exchange rate shall be: 21 days before the submission date
– 2nd May, 2011.
ITB 35.2 The adjustments shall be determined using the following criteria, from
amongst those set out in Section 3: Qualification and Evaluation
Criteria:
(a) Deviation in delivery schedule: No.
29
(b) the cost of major replacement components, mandatory

spare parts, and service: No
(c) the availability in the Purchaser’s Mongolia of spare parts
and after-sales services for the equipment offered in the
bid: No
(d) the projected operating and maintenance costs during the
life of the equipment:No.
(e) the performance and productivity of the equipment offered:
Yes
ITB 35.3 Bidders shall quote separate prices for the following lots: Not
Applicable
F. Award of Contact
ITB 41.1 The Purchaser reserves the right to increase or decrease the quantities
of each item by up to 10%.
ITB 45.1 The Purchaser’s website where the description of its bid challenge
system may be found is: www.mca.mn
30
Qualification and Evaluation Criteria CA/MCA-M/MCC/PRP/GDS/099/2011
Qualification and Evaluation Criteria

This section contains the factors, methods and criteria that the Purchaser may use to
evaluate a Bid and determine whether a Bidder is qualified.
G. General
1. Qualification 1.1 The information required for qualification of a Bidder
shall be as shown below. Any Bidder failing to provide
Information
all the documentation requested, or providing
documentation subsequently found to be false or untrue
during the evaluation process, shall have that Bid rejected
and it shall no longer be considered during the evaluation
process.The information required is:
(a) demonstration to the satisfaction of the Purchaser
that the Bidder has in place sufficient safety policy
documents and safety awareness to be able to
perform in a safe and workmanlike manner; such
information includes a narrative that the Bidder
possess a high level of health and safety (“H&S”)
management expertise and can successfully manage
the H&S risks related to the delivery of the Goods
and Related Services and is capable of abiding by
H&S procedures similar to those provided inSection
6: Schedule of Requirements.
(b) demonstration to the satisfaction of the Purchaser
that the Bidder has in place sufficient environmental
and social policy documents and awareness to be
able to perform in accordance with MCC
Environmental Guidelines and the Purchaser’s
Mongolia’s environmental legislation; such
information includes a narrative that the Bidder
possess a high level of environmental and social
(“E&S”) management expertise and can successfully
manage the E&S risks associated with the delivery
of the Goods and Related Services and is capable of
abiding by E&S management plans similar to those
provided inSection 6: Schedule of Requirements.
1.2 The information required for qualification of a

Bidder shall be as shown below. Any Bidder
failing to provide all the documentation requested,
31
or providing documentation subsequently found to

be false or untrue during the evaluation process,
shall have that Bid rejected and it shall no longer
be considered during the evaluation process. The
information required is:
1.2 demonstration to the satisfaction of the
Purchaser that the Bidder has in place
sufficient safety policy documents and
safety awareness to be able to perform in a
safe and workmanlike manner; such
information includes a narrative that the
Bidder possess a high level of health and
safety (“H&S”) management expertise and
can successfully manage the H&S risks
related to the delivery of the Goods and
Related Services and is capable of abiding
by H&S procedures similar to those
provided in Section 6: Schedule of
Requirements.
demonstration to the satisfaction of the
Purchaser that the Bidder has in place
sufficient environmental and social policy
documents and awareness to be able to
perform in accordance with MCC
Environmental Guidelines and the
Purchaser’s country’s environmental
legislation; such information includes a
narrative that the Bidder possess a high
level of environmental and social (“E&S”)
management expertise and can successfully
manage the E&S risks associated with the
delivery of the Goods and Related Services
and is capable of abiding by E&S
management plans similar to those provided
in Section 6: Schedule of Requirements.
1.3 To qualify for award if the Contract, Bidders

shall meet the following minimum criteria:
(a) Has performed at least one similar contract
with amount at least equal to 60% of the
pertinent lot amount within last 5 years.
(b) Access to, or availability of, financial

resources such as liquid assets,
32
unencumbered real assets, lines of credit,

and other financial means, other than any
contractual advance payments to meet:
(i) the following cash-flow requirement: cash
flow amount of at least 70% of the pertinent
lot amount outside of its current commitments
2. Evaluation Criteria 2.1 The evaluation of a Bid will take into account,
in addition to the Bid price quoted in
accordance with ITB Clause 15.6, one or more
of the following factors as specified in the ITB
Clause 35, and quantified below:
(a) deviations in payment schedule from that
specified in the SCC;
(b) the performance and productivity of the
equipment offered;
(c) the Bidder’s past performance on MCC-
funded contracts.
Deviation in Payment Bidders shall state their Bid price for the
Schedule payment schedule outlined in the SCC. Bids
will be evaluated on the basis of this base price.
Bidders are, however, permitted to state an
alternative payment schedule and indicate the
reduction in Bid price they wish to offer for
such alternative payment schedule. The
Purchaser may consider the alternative
payment schedule offered by the selected
Bidder.
3. Qualification Criteria 3.1 After determining the lowest-evaluated Bid in

accordance with ITB Clause 35 and Sub-
Clause 36.1, the Purchaser will carry out the
post-qualification of the Bidder in accordance
with ITB Clause 38, using only the factors,
methods and criteria specified in ITB Clause 38
and those listed below. Factors not included in
ITB Clause 38 and this Section (4. Post
Qualification Criteria) shall not be used in the
33
evaluation of a Bidder’s post-qualification.

Financial Capability: The Bidder shall furnish
documentary evidence that it meets the following
financial requirement(s):
Minimum liquid assets of not less than US$
300,000
Annual turnover of not less than US$ 3.0 million
per year over the past 5 years in production
and/or supply/installation of items listed in
Section VI – Schedule of Requirements.
Experience: The Bidder shall furnish documentary

evidence to demonstrate that it meets the following
experience requirement(s):
Evidence of business activity of a similar nature for a

minimum of ten years - in the software development
business area of property registration or property
management, cadastre, etc
Details of past similar experience, including names and

contact information, of supplying and installing similar
sized and natured contracts during the past five years.
The bidder company should have a quality certificate

e.g ISO certification or similar for the activity of
developing IT systems as well as implementation of IT
hardware infrastructure, in case of a Joint Venture (JV)
this is required from all Consortium or JV members.
Technical capacity:The Bidder shall have experience

in all of the following fields of specialization:
 quality assurance management following
international standards Rational Unified
Process (RUP) methodology or similar;
 design, development and deployment of
integrated web-based enterprise level
database(s) and textual/graphical (GIS)
applications (service oriented architecture
preferred) dedicated for large property
registration/management and cadastre
34
organizations(min. 100 current users);

 object-oriented business and system analysis
and design
 software system implementation;
 hardware systems implementation;
 IT technical training organization, provision
and evaluation.
 communications over secure connection in
multi-service TCP/IP network environment.
 strong experience in similar projects for data
conversion between different DBMS (e.g.
Oracle, MS SQL Server, etc)
 extensive proven experience in similar projects
for digitization from paper archive and
developing digital archive / central databases
 The Bidder should clearly demonstrate the use
of internationally recognized software and
database developments methods, guidelines,
standards and tools for development of large IT
system(s).
 Proven experience in ERP and GIS Systems,
especially with focus on large property
management/registration system experience
and references is preferred.
 The Bidder shall have experience as system
and software designer, developer and supplier
in the execution of at least two successful
software developments and implementation
projects within the last five years serving at
least 100 concurrent users.
Nonperforming Contracts and Litigation: The Bidder

shall furnish documentary evidence to demonstrate
that non-performance of a contract did not occur
within the last five (5) years prior to the deadline for
submission of Bids, based on all information on fully
settled disputes or litigation. All pending litigation
shall in total not exceed 10% of the Bidder’s net worth.
Usage Requirements: The Bidder shall furnish
documentary evidence to demonstrate that the Goods it
35
offers meet the requirements as defined in the

Technical Specifications: A detailed commentary on
the Purchaser’s Technical Specifications
demonstrating substantial responsiveness of the goods
and services to those specifications, or a statement of
deviations and exceptions to the provisions of the
Technical Specifications. This commentary should
consider the following:
 Service oriented application architecture with
application layers (components, for example data
access logic, security policy, presentation layer,
technical architecture including hardware and
equipment etc) is preferred and will be evaluated
accordingly.
 Description of components (Pillar I, II, III) will be
evaluated based on how well it meets the business
requirements and interaction with other modules.
36
Bid Forms CA/MCA-M/MCC/PRP/GDS/099/2011
Bid Forms
BSF1 BID SUBMISSION FORM ........................................................................................................ 38
BSF2(a) PRICE SCHEDULE FOR GOODS MANUFACTURED IN PURCHASER’S COUNTRY...47
BSF2(b) PRICE SCHEDULE FOR GOODS MANUFACTURED IN PURCHASER'S COUNTRY. 43
BSF3(a) PRICE SCHEDULE FOR GOODS MANUFACTURED OUTSIDE PURCHASER’S

COUNTRY, TO BE IMPORTED ............................................................................................................. 49
BSF3(b) PRICE SCHEDULE FOR GOODS MANUFACTURED OUTSIDE PURCHASER’S

COUNTRY, TO BE IMPORTED ............................................................................................................. 49
BSF4(a) PRICE SCHEDULE FOR GOODS MANUFACTURED OUTSIDE PURCHASER’S

MONGOLIA, ALREADY IMPORTED .................................................................................................. 51
BSF4(b) PRICE SCHEDULE FOR GOODS MANUFACTURED OUTSIDE PURCHASER’S

MONGOLIA, ALREADY IMPORTED .................................................................................................. 51
BSF5(a) PRICE AND COMPLETION SCHEDULE FOR RELATED SERVICES ............................ 48
BSF5(b) PRICE AND COMPLETION SCHEDULE FOR RELATED SERVICES ............................ 49
BSF6 BIDDER INFORMATION FORM ............................................................................................ 50
BSF7 PARTY TO JOINT VENTURE INFORMATION FORM ...................................................... 51
BSF8 BID SECURITY FORM (BANK GUARANTEE) .................................................................... 52
BSF9 ENVIRONMENTAL, SOCIAL, HEALTH AND SAFETY FORMS ...................................... 54
BSF10 MANUFACTURER’S AUTHORIZATION ......................................................................... 55
BSF11 NOTIFICATION OF AWARD .............................................................................................. 56
37
BSF1 Bid Submission Form

[The Bidder shall complete this form in accordance with the instructions indicated. No
alterations to its format shall be permitted and no substitutions shall be accepted].
Re: IT Equipment & Software - Supply, Installation & Intergration
We, the undersigned, declare that:
(a) We have examined and have no reservations to the Bidding Document, including
Amendment No: [insert the number and issuing date of each amendment].
(b) We offer to supply in conformity with the Bidding Document and in accordance with
the Delivery Schedules specified in Section 6: Schedule of Requirements referenced
above.
(c) The total lump-sum price of our Bid, excluding any discounts offered in item (d) below
is: [insert the total Bid price in words and figures, including the various amounts
and respective currencies].
(d) The discounts offered and the methodology for their application are:
(i) Discounts: If our Bid is accepted, the following discounts shall apply.
[Specify in detail each discount offered and the specific item of Section 6:
Schedule of Requirements to which it applies].
(ii) Methodology of Application of the Discounts: The discounts shall be applied
using the following: [Specify in detail the method that shall be used to apply
the discount]
(e) Our Bid shall be valid from the date fixed for the Bid submission deadline in accordance
with ITB Sub-Clause 25.1 through the period of time established in accordance with
ITB Sub-Clause 21.1, and it shall remain binding upon us and may be accepted at any
time before the expiration of that period.
(f) If our Bid is accepted, we commit to obtain a Performance Security in accordance with
GCC Clause 15 and as described in ITB Clause 43 for the due performance of the
Contract.
(g) We, including any Subcontractors or sub-suppliers for any part of the Contract, have
nationalities from eligible countries [Insert the nationality of the Bidder, including that
of all parties that comprise the Bidder, if the Bidder is a joint venture, and the
nationality of each Subcontractor and supplier].
(h) We have no conflict of interest in accordance with ITB Clause 4.
(i) Our firm, its associates, including any Subcontractors or suppliers for any part of the
Contract, has not been declared ineligible by the Purchaser, or under the laws or official
regulations of the Purchaser’s country, in accordance with ITB Clause 4.
(j) We are aware of, and will comply with, the rules on prohibited activities, restricted
parties and eligibility requirements of prohibited source provisions in accordance with
38
applicable US law, regulations and policy and as summarized in Appendix A to the

Contract shown in Section 5: Contract Forms.
(k) We have certified and signed BSF 1.1 Government-Owned Enterprise Certification.
(l) The following commissions, gratuities, or fees have been paid or are to be paid with
respect to the Bid process or execution of the Contract: [Insert complete name of each
recipient, its full address, the reason for which each commission or gratuity was paid
and the amount and currency of each such commission or gratuity]
Name of Recipient Address Reason Amount
(If none has been paid or is to be paid, indicate “none.”)

(m) We understand that this Bid, together with your written acceptance thereof included in
your Notification of Award, shall constitute a binding contract between us, until a
formal Contract is prepared and executed.
(n) We understand that you are not bound to accept the lowest evaluated Bid or any other
Bid that you may receive.
Signed:
Print Name
In the capacity of:
Duly authorized to sign on behalf of:
Date:
39
BSF1.1Government-Owned Enterprise Certification
Government-Owned Enterprise Certification Form
Government-Owned Enterprises are not eligible to compete for MCC-funded contracts.

Accordingly, GOEs (i) may not be party to any MCC-funded contract for goods, works, or
services procured through an open solicitation process, limited bidding, direct contracting, or sole
source selection; and (ii) may not be pre-qualified or shortlisted for any MCC-funded contract
anticipated to be procured through these means.
This prohibition does not apply to Government-owned Force Account units owned by the
Government of the MCA Entity’s Mongolia, or Government-owned educational institutions and
research centers, or any statistical, mapping or other technical entities not formed primarily for a
commercial or business purpose, or where a waiver is granted by MCC in accordance with Part 7
of MCC’s Program Procurement Guidelines. The full policy is available for your review on the
Compact Procurement Guidelines page at the MCC Website (www.mcc.gov). As part of the
eligibility verification for this procurement, please fill in the form below to indicate the status
of your entity.
For purposes of this form, the term “Government” means one or more governments, including
any agency, instrumentality, subdivision or other unit of government at any level of jurisdiction
(national or subnational).

CERTIFICATION
Full Legal Name of Bidder:
__________________________________________________________________
Full Legal Name of Bidder in Language and Script of Mongolia of Formation (if different
from above):
________________________________________________
Address of Principal Place of Business or Chief Executive Office of Bidder:
________________________________________________
________________________________________________
________________________________________________
40
Full Name of Three (3) Highest Ranking Officials of Bidder (for any Bidder that is an entity):
________________________________________________
________________________________________________
________________________________________________
Full Legal Name(s) of Parent Entity or Entities of Bidder (if applicable; if Bidder has no
parent, please so state):
__________________________________________________________________
Full Legal Name(s) of Parent Entity or Entities of Bidder in Language and Script of
Mongolia of Formation (if applicable and if different from above):
________________________________________________
Address(es) of Principal Place of Business or Chief Executive Office of Parent Entity or

Entities of Bidder (if applicable):
________________________________________________
________________________________________________
________________________________________________
Does a Government own a majority or controlling interest (whether by value or

voting interest) of your shares or other ownership interest (whether directly or
indirectly and whether through fiduciaries, agents or other means)? Yes  No

1) If your answer to question 1 was yes, are you a Government-owned:

a. Force Account unit Yes  No 
b. Educational institution Yes  No 
c. Research center Yes  No 
d. Statistical entity Yes  No 
e. Mapping entity Yes  No 
f. Other technical entities not formed primarily for a commercial or business
purpose Yes  No 
2) Regardless of how you answered question 1, please answer the following:
41
a. Do you receive any subsidy or payment (including any form of subsidized

credit) or any other form of assistance (financial or otherwise) from a
Government?
Yes  No 
If yes, describe:
_________________________________________________________
b. Has a Government granted to you any special or exclusive legal or
economic rights or benefits that may alter the competitiveness of your
goods, works or services or otherwise influence your business decisions?
Yes  No 
If yes, describe:
_________________________________________________________
c. Does a Government have the ability to direct or decide any of the
following with respect to you:
i. any reorganization, merger, or dissolution of you or the
formation or acquisition of any subsidiary or other affiliate by
you Yes  No 
ii. any sale, lease, mortgage, pledge, or other transfer of any of
your principal assets, whether tangible or intangible and
whether or not in the ordinary course of business
Yes  No 
iii. the closing, relocation, or substantial alteration of the
production, operational, or other material activities of your
business Yes  No 
iv. your execution, termination, or non-fulfillment of material
contracts Yes  No 
v. the appointment or dismissal of your managers, directors,
officers or senior personnel or otherwise participate in the
management or control of your business Yes  No 
3) Have you ever been Government-owned or controlled? Yes  No 
4) If your answer to question 4 was yes, please answer the following questions
a. How long were you Government-owned? _________________

b. When were you privatized? ________________________
c. Do you receive any subsidy or payment (including any form of subsidized
credit) or any other form of assistance (financial or otherwise) from a
Government ? Yes  No 
If yes, describe:
_________________________________________________________
d. Even though not majority or controlling, does a Government continue to
hold any ownership interest or decision making authority in you or your
affairs? Yes  No 
If yes, describe:
_________________________________________________________
42
e. Do you send any funds to a Government other than taxes and fees in the
ordinary course of your business in percentages and amounts equivalent to
other non-Government-owned enterprises in your Mongolia that are
engaged in the same sector or industry?Yes  No 
If yes, describe:
_________________________________________________________
Participants are advised that:
1. Prior to announcing the winning bidder or Bidder or any list of pre-qualified

bidders or shortlisted Bidders for this procurement, the MCA Entity will verify the eligibility of
such bidder(s) or Bidder(s) with MCC. MCC will maintain a database (internally, through
subscription services, or both) of known GOEs and each winning or pre-qualified bidder and
winning or shortlisted Bidder subject to this provision will be compared against the database and
subject to such further due diligence as MCC may determine necessary under the circumstances.
2. Any misrepresentation by any entity submitting a bid or proposal for this

procurement may be deemed a “fraudulent practice” for purposes of the MCC Program
Procurement Guidelines and any other applicable MCC policy or guidance, including MCC’s
Policy on Preventing, Detecting and Remediating Fraud and Corruption in MCC Operations.
3. Any entity that is determined by MCC to have organized itself, subcontracted

any part of its MCC-funded contract, or otherwise associated itself with any other entity for the
purpose of, or with the actual or potential effect of, avoiding or otherwise subverting the
provisions of the MCC Program Procurement Guidelines may be deemed to be a GOE for all
purposes of those Guidelines.
4. Any credible accusation that any entity submitting a bid or proposal for this
procurement is a GOE ineligible to submit a bid or proposal in accordance with the MCC
Program Procurement Guidelines will be subject to review in a bid challenge in accordance with
those Guidelines and the MCA Entity’s Bid Challenge System.
I hereby certify that the information provided above is true and correct in all material respects and
understand that any material misstatement, misrepresentation or failure to provide the information
requested in this certification may be deemed a “fraudulent practice” for purposes of the MCC
Program Procurement Guidelines and other applicable MCC policy or guidance, including
MCC’s Policy on Preventing, Detecting and Remediating Fraud and Corruption in MCC
Operations.
Authorized Signature: _________________________________ Date: _________________
Printed Name of Signatory: ____________________________________
43
BSF 1.2 Financial Capacity of the Bidder

The Bidder’s financial capacity to mobilize and sustain the Services is imperative. In the Bid, the
Bidder is required to provide information on its financial status. This requirement can be met by
submission of one of the following: 1) audited financial statements for the last five (5) years,
supported by audit letters, 2) certified financial statements for the last five (5) years, supported by
tax returns, or 3) a copy of the Bidder’s Dun & Bradstreet “Business Information Report” (BIR).
The Dun & Bradstreet report must be either notarized, or accompanied by the following statement
by the Bidder:
“I certify that the attached Business Information Report has been issued by Dun &
Bradstreet within thirty (30) days of the date of this certification, that the report has not
been altered in any way since its issuance, and that it is true and correct to the best of my
knowledge”
The statement must be signed by the authorized representative of the Bidder.
If the Proposal is submitted by a joint venture, all parties of the joint venture are required to
submit their financial statements or Dun & Bradstreet BIRs. The reports should be submitted in
the order of the associate’s significance in the joint venture, greatest to least.
Additionally, the following financial data form shall be filled out for the Bidder and all named
associates. The MCA Entity reserves the right to request additional information about the
financial capacity of the Bidder. A Bidder that fails to demonstrate through its financial records
that it has the financial capacity to perform the required Services may be disqualified.]
Financial Information Historical information for the previous five (5) years
(US$ X,000’s) (most recent to oldest or equivalence in (US$ X,000’s)
Year 1 Year 2 Year 3 Year 4 Year 5

(Year) (Year) (Year)
(year) (year)
Information from Balance Sheet
(1) Total Assets (TA)
(2) Current Assets (CA)
(3) Total Liabilities (TL)
(4) Current Liabilities (CL)
Information from Income Statement
(5) Total Revenue (TR)
44
(6) Profits before Taxes (PBT)
Net Worth (1) – (3)
Current Ratio (2) / (4)
[Provide information on current or past litigation or arbitration over the last five (5) years
as shown in the form below.]
Litigation or arbitration in the last five (5) years: No:_____Yes:______ (See below)
Litigation and Arbitration During Last Five (5) Years
Year Matter in Dispute Value of Award Against

Bidder in US$ Equivalent
Information to Bidders
Bidders should note that MCA Mongolia manages a Contractor Past Performance
Reporting System (CPPRS) evaluation purposes. The following is an extract from the
Program Procurement Guidelines
Part 2. Procurement Planning, Implementation, and Reporting
MCC’s Contractor Past Performance Reporting System (“CPPRS”) mandates regular

reporting on contractor performance, thereby facilitating information sharing and
standardized use of information relating to contractor performance so that better
informed decisions can be made across MCC partner countries regarding awarding new
contracts or maintaining current contracts with specific contractors. To that end, the
MCA Entity shall (a) ensure that, for each procurement resulting in a total contract
awarded that is valued or estimated to be valued in excess of 100,000USD, a past
performance report on the contractor’s performance is submitted at least annually
(quarterly if one or more aspects of performance are problematic) during the period of
contract performance(b) consult the MCC local office in the MCA Entity’s Mongolia at
specific stages in the procurement process to seek relevant CPPRS information on
bidders or potential bidders and use such information in its evaluation and review
panels.
Further information regarding the procedures and forms to be used by the MCA Entity in
performing these tasks is provided in MCC’s “Guidance on Reporting and Considering
Past Performance by Contractors in MCA Entity Program Procurements” posted at:
http://www.mcc.gov/mcc/procurement/ppg/index.shtml.
45
46
PILLAR 1(a) - Required Hardware, Software and Equipment needed for the Digitilization Process
BSF2(a) Price Schedule for Goods Manufactured in Purchaser’s Country
1 2 3 4 5 6 7 8 9 10
Item Description Mongolia Quantity Unit Total Price per item for Cost of local Total price of Total Price per
N of Goods of origin and price EXW inland transportation labor, raw item item
physical EXW price per and other services material and (col. 6+7) (col. 9+10)
unit item required in the components
(col. 45) Purchaser’s Mongolia from within
to convey the goods to Purchaser’s
their Final Destination Mongolia
(% of col. 6)
Refer to
Pillar 1(a) in
Schedule of
Requirements
Total Bid Price
Name of Bidder __________________________Signature of Bidder _________________________ Date ____________________
47
PILLAR 1(b) - Required Hardware, Software and Equipment needed for Establish & Operate the ePRS
BSF2(b) Price Schedule for Goods Manufactured in Purchaser’s Country
1 2 3 4 5 6 7 8 9 10
Item Description Mongolia Quantity Unit Total Price per item for Cost of local Total price of Total Price per
N of Goods of origin and price EXW inland transportation labor, raw item item
physical EXW price per and other services material and (col. 6+7) (col. 9+10)
unit item required in the components
(col. 45) Purchaser’s Mongolia from within
to convey the goods to Purchaser’s
their Final Destination Mongolia
(% of col. 6)
Refer to
Pillar 1(b) in
Schedule of
Requirements
Total Bid Price
Name of Bidder _____________________ Signature of Bidder _____________________ Date_____________
48
PILLAR 1(a) - Required Hardware, Software and Equipment needed for the Digitilization Process
BSF 3(a) Price Schedule for Goods Manufactured Outside Purchaser’s Country, to be Imported
1 2 3 4 5 6 7 8
Item Description of Goods Mongolia Quantity Unit price Total CIF or CIP Price per item for Total price per
N of origin and CIP price per item inland transportation item
physical (col45) and other services (col. 6+7)
unit required in the
Purchaser’s
Mongolia to convey
the goods to their
Final Destination
Refer to Pillar 1(a) in
Schedule of Requirements
Total Bid Price
Name of Bidder ________________________ Signature of Bidder __________________________ Date _____________________
49
PILLAR 1(b) - Required Hardware, Software and Equipment needed for Establish & Operate the ePRS
BSF3(b) Price Schedule for Goods Manufactured Outside Purchaser’s Mongolia, to be Imported
1 2 3 4 5 6 7 8
Item Description of Goods Mongolia Quantity Unit price Total CIF or CIP Price per item for Total price per
N of origin and CIP price per item inland transportation item
physical (col45) and other services (col. 6+7)
unit required in the
Purchaser’s
Mongolia to convey
the goods to their
Final Destination
Refer to Pillar 1(b) in
Total Bid Price
Name of Bidder _________________________ Signature of Bidder ____________________________Date ___________________
50
Pillar 1(a) - Required Hardware, Software and Equipment needed for the Digitilization Process
BSF4(a) Price Schedule for Goods Manufactured Outside Purchaser’s Mongolia, already Imported
1 2 3 5 6 7 8 9 10 12
Line Description of Country Quantity Unit price Taxes paid Unit Price Price CIP Price per line item for Total Price
Item Goods of and including per unit in CIP net of per line item inland transportation and per item
N Origin physical Taxes paid, accordance Taxes Paid net of other services required in (Col. 9+10)
unit in with ITB (Col. 6 Taxes paid the Purchaser’s Mongolia
accordance 15.6(c)(ii), minus (Col. 58) to convey the goods to
with ITB [to be Col.7) their Final Destination, as
15.6(c)(i) supported by specified in BDS in
documents] accordance with
ITB15.6(c)(ii)
Refer to Pillar
1(a) in
Schedule of
Requirements
Total Bid Price:
51
Pillar 1(b) - Required Hardware, Software and Equipment needed for Establish & Operate the ePRS
BSF4(b) Price Schedule for Goods Manufactured Outside Purchaser’s Mongolia, already Imported
1 2 3 5 6 7 8 9 10 12
Line Description of Country Quantity Unit price Taxes paid Unit Price Price CIP Price per line item for Total Price
Item Goods of and including per unit in CIP net of per line item inland transportation and per item
N Origin physical Taxes paid, accordance Taxes Paid net of other services required in (Col. 9+10)
unit in with ITB (Col. 6 Taxes paid the Purchaser’s Mongolia
accordance 15.6(c)(ii), minus (Col. 58) to convey the goods to
with ITB [to be Col.7) their Final Destination, as
15.6(c)(i) supported by specified in BDS in
documents] accordance with
ITB15.6(c)(ii)
Refer to Pillar
1(a) in
Schedule of
Requirements
Total Bid Price:
52
Pillar 2: Services Related to Digitilization of Paper Archive & Conversion of Existing Digital Data
BSF5(a) Price and Completion Schedule for Related Services

1 2 3 4 5 6 7
Item Description of Related Country of origin Delivery Date at Quantity and Unit price Total Price of
Services (excludes Final Destination physical unit item
inland transportation (col. 5 x 6)
and other services
required in the
Purchaser’s country to
convey the Goods to
their Final Destination)
Refer to Pillar 2 in
Schedule of
Requirements
Total Bid Price
53
BSF5(b) Price and Completion Schedule for Related Services

Pillar 3: Development of the Electronic Mongolian Property Registry System/ePRS

1 2 3 4 5 6 7
Item Description of Related Country of origin Delivery Date at Quantity and Unit price Total Price of
Services (excludes Final Destination physical unit item
inland transportation (col. 5 x 6)
and other services
required in the
Purchaser’s country to
convey the Goods to
their Final Destination)
Refer to Pillar 3 in
Schedule of
Requirements
Total Bid Price
54
BSF6 Bidder Information Form

Re: It Equipment & Software - Supply, Installation &
Intergration
1. Constitution or Bidder’s legal status

Place of registration
Principal place of
business
2. Legal name of each party of the joint venture (if applicable)
[insert legal name of each party in joint venture and complete Form BSF7: Party to Joint
Venture Information Form below for each joint venture party]
3. Attached are copies of original documents of:
Articles of incorporation or registration of the Bidder named in 1 above; demonstrating the
Bidder’s eligibility in accordance with ITB Sub-Clause 4.3;
Letter of intent to form joint venture or joint venture agreement, if applicable, in accordance
with ITB Sub-Clause 4.5;
Proper authority of the signatory of the Bidder in accordance with ITB Sub-Clause 23.1;
“Tick” the boxes and attach documents to the Bid.
4. Information on current litigation(s) in which the Bidder is involved
Other party (ies)
Cause of dispute
Amount involved
The information filled in above by Bidders shall be used for purposes of post
qualification as provided for in ITB Clause 38. This information shall not be
incorporated into the Contract. The Bidder is to adapt and extend this form BSF6 as
necessary. Pertinent sections of attached documents should be translated into English.
55
BSF7 Party to Joint Venture Information Form

Re: It Equipment & Software - Supply, Installation &
Intergration
1. Constitution or joint venture member’s legal status
Place of registration
Principal place of
business
2. Attached are copies of original documents of:
Articles of incorporation or registration of the entity named in 1 above;
demonstrating the entity’s eligibility in accordance with ITB Sub-Clauses 4.3;
Letter of intent to form joint venture or joint venture agreement, if applicable, in
accordance with ITB Sub-Clause 4.5;
Proper authority of the signatory of the entity named in 1 above in the same manner
as contemplated for Bidders in ITB Sub-Clause 23.1;
Government-Owned Enterprise Certification Form (attached to Bidders Information
Sheet).
“Tick” the boxes and attach documents to the Bid.
3. Information on current litigation(s) in which the Bidder is involved
Other party (ies)
Cause of dispute
Amount involved
The information listed above shall be provided for each member of a joint venture.
Attach the agreement among all members of the joint venture (and which is legally
binding on all members), which shows that:
1. all members shall be jointly and severally liable for the execution of the
Contract in accordance with the Contract terms;
2. one of the members shall be nominated as being in charge, authorised to
incur liabilities and receive instructions for and on behalf of all members of
the joint venture; and
3. the execution of the entire Contract, including payment, shall be done
exclusively with the member in charge.
56
BSF8 Bid Security Form (Bank Guarantee)

[The bank, as requested by the Bidder, shall fill in the form in accordance with the
instructions indicated]
Re: It Equipment & Software - Supply, Installation & Intergration
Whereas [insert name of Bidder](hereinafter “the Bidder”) has submitted its bid dated
[insert day, month, year]for the above mentioned Bid Reference for the supply of
[insert name of Goods]hereinafter called “the Bid.”
KNOW ALL PEOPLE by these presents that WE [insert name of Bank]having our
registered office at [insert address of bank], are bound unto [insert full legal name of
the Purchaser] (hereinafter “Purchaser”) in the sum of [United States Dollars/other
currency][insert amount in words and figures]for which payment well and truly to be
made to the aforementioned Purchaser, we bind ourself, our successors, or assignees by
these presents. Sealed with the Common Seal of this bank this [insert date, month,
year].
THE CONDITIONS of this obligation are the following:
Section 1 If the Bidder withdraws its Bid during the period of Bid validity specified by
the Bidder in the Bid Submission Sheet, except as provided in ITB Clause 21.2 (it being
understood that all references to “ITB” in this document shall be references to the
Instructions to Bidders section of the bidding document associated with the Bid);
OR
If the Bidder, having been notified that it has submitted the lowest-evaluated Bid does not
accept the correction of errors in its Bid by the Purchaser, pursuant to ITB Clause 32;
OR
If the Bidder, having been notified of the acceptance of its Bid by the Purchaser, fails within
the specified time to:
(i) furnish the Performance Security, in accordance with GCC Clause 15 and as
described in ITB Clause 43,
OR
(ii) execute the Contract, in accordance with ITB Clause 44.
We undertake to pay the Purchaser up to the above amount upon receipt of its first
written demand, without Purchaser having to substantiate its demand, provided that in its
demand the Purchaser states that the amount claimed by it is due to it, owing to the
occurrence of one or more of the above conditions, specifying the occurred conditions.
This security shall remain in force up to and including twenty-eight (28) days after the
period of Bid validity, and any demand in respect thereof should be received by us no
later than the above date.
Signed:
57
In the capacity of:
Print Name
duly authorized to sign the Bid Security

for and on behalf of
Dated on
58
BSF9 Environmental, Social, Health and Safety Forms

We, the undersigned, declare that:
Section 1 The attached health and safety (“H&S”) data sheets, licenses, permits or other
documents as listed below and required bySection 6: Schedule of Requirements are
current and valid.; and,
Section 2 the attached environmental and social permits, licenses or other documents as
listed below and required by Section 6: Schedule of Requirements are current and valid.
Signed:
In the capacity of:
Print Name

Dated on
59
BSF10 Manufacturer’s Authorization

[This letter of authorization should be on the letterhead of the manufacturer of the Goods
and should be signed by a person with the proper authority to sign documents that are
binding on such manufacturer. A Bidder shall include this letter of authorization in its
Bid, if so indicated in the BDS].
WHEREAS
We, [insert name of manufacturer] are reputable manufacturers of [insert type of goods
manufactured] having factories at [insert location(s) of factories].
THEREFORE, we do hereby
Section 1 Authorize [insert name of Bidder] to submit a Bid in response to the
Invitation for Bids indicated above. The purpose of such Bid is to provide the following
Goods: [insert description of Goods] manufactured by us, and to subsequently negotiate
and sign the Contract for the supply of such Goods.
AND
Extend our full guarantee and warranty in accordance with Clause 25 of the General
Conditions of Contract, with respect to the Goods offered in the Bid.
Signed:
In the capacity of:
Print Name

Dated on
60
BSF11 Notification of Award

[The Notification of Award shall be the basis for formation of the Contract as described
in ITB Clause 42. This form of Notification of Award shall be filled in and sent to the
successful Bidder only after evaluation of Bids has been completed, subject to any review
by the MCC as required.]
To: [insert name and address of the Supplier]

This is to notify you that your Bid dated [insert date] for execution of the above
mentioned Bid Reference for the lump-sum contract price of [insert amount in words
and numbers] [insert name of currency], as corrected and modified in accordance with
the Instructions to Bidders is hereby accepted by the Purchaser.
You are hereby instructed to (a) proceed with supply of the said Goods and Related
Services in accordance with the Contract, (b) sign and return the attached Contract, and
(c) forward the Performance Security pursuant to GCC Clause 15 within fourteen (14)
days after receipt of this Notification of Award.
Signed:
In the capacity of:
Print Name
duly authorized to sign the authorization for and on behalf of
Dated on
Attachment: Contract
61
Section 5 Contract Forms CA/MCA-M/MCC/PRP/GDS/099/2011
Contract Forms
Contract No:CA/MCA-M/MCC/PRP/GDS/099/2011
Contract for Procurement of Goods

and Related Services
between
Milleinnium Challenge Account

Mongolia
and
[Full Legal Name of Supplier]
Dated:
62
II. Agreement
This CONTRACT AGREEMENT (this “Contract”) is made as of the [day] of [month],
[year], between, [full legal name of the Purchaser] (the “Purchaser”), on the one part,
and [full legal name of the Supplier] (the “Supplier”), on the other part.
RECITALS
WHEREAS
Section 1 The Millennium Challenge Corporation (“MCC”) and the Government of
Mongolia (the “Government”) have entered into a Millennium Challenge Compact for
Millennium Challenge Account assistance to help facilitate poverty reduction through
economic growth in Mongolia on [insert date] (the “Compact”) in the amount of
approximately 285 Million United States Dollars (“MCC Funding”). The Government,
acting through the Purchaser, intends to apply a portion of the proceeds of MCC
Funding to eligible payments under this Contract. Payments made under this Contract
will be subject, in all respects, to the terms and conditions of the Compact and related
documents, including restrictions on the use, and conditions to disbursement, of MCC
Funding. No party other than the Government, the Purchaser and MCC shall derive any
rights from the Compact or have any claim to the proceeds of MCC Funding; and
Section 2 The Purchaser invited bids for the provision of certain goods and related
services identified in this Contract and has accepted a bid by the Supplier for the supply
of those goods and related services on the terms and conditions set forth in this Contract
NOW THEREFORE, the parties hereto agree as follows:
Section 1 In consideration of the payments to be made by the Purchaser to the Supplier
as set forth in this Contract, the Supplier hereby covenants with the Purchaser to provide
the Goods and Related Services and to remedy defects therein in conformity in all
respects with the provisions of this Contract.
Section 2 Subject to the terms of this Contract, the Purchaser hereby covenants to pay
the Supplier in consideration of the provision of the Goods and Related Services and the
remedying of defects therein, the Contract Price (as defined below) or such other sum as
may become payable under the provisions of this Contract at the times and in the
manner prescribed by this Contract.
IN WITNESS whereof the parties hereto have caused this Contract to be executed in
accordance with the laws of Mongoliaon the day, month and year first indicated above.
For [full legal name of the Purchaser]: For [full legal name of the Supplier]:
Signature Signature
Name Name
63
III. General Conditions of Contract

1. Definitions 1.1 Capitalized terms used in this Contract and not otherwise
defined have the meanings given such terms in the
Compact or related document. Unless the context
otherwise requires, the following words whenever used
in this Contract have the following meanings:
(a) “Applicable Law” means the laws and any other
instruments having the force of law in Mongolia, as
they may be issued and in force from time to time.
(b) “Bid” means the bid for the provision of the Goods
and the Related Services submitted by the Supplier
and accepted by the Purchaser and that forms an
integral part of this Contract.
(c) “Bidding Document” means the bidding documents
for the procurement of the Goods and Related
Services;
issued 31st th March, 2011.
(d) “coercive practice” means impairing or harming or
threatening to impair or harm, directly or indirectly,
persons or their property, to influence their
participation in a procurement process, or affect the
execution of a contract.
(e) “collusive practice” means a scheme or arrangement
between two or more parties, with or without the
knowledge of the Purchaser, designed to establish
prices at artificial, noncompetitive levels or to
otherwise deprive the Purchaser of the benefits of
free and open competition.
(f) “Compact” has the meaning given the term in the
recital clauses to this Contract.
(g) “Completion” means the fulfilment of the Related
Services by the Supplier in accordance with the
terms and conditions set forth in this Contract.
(h) “Contract” means this agreement entered into
between the Purchaser and the Supplier, to provide
the Goods and Related Services and consists of the
documents listed in GCC Sub-Clause 2.7, as the
same may be amended, modified, or supplemented
from time to time in accordance with the terms of
this agreement.
64
(i) “Contract Price” has the meaning given the term in

GCC Sub-Clause 12.1.
(j) “corrupt practice” means the offering, giving,
receiving, or soliciting, directly or indirectly, of
anything of value to influence the actions of a public
official (including Purchaser and MCC staff and
employees of other organizations taking or
reviewing selection decisions) in the selection
process or in contract execution, or the making of
any payment to any third party, in connection with
or in furtherance of a contract, in violation of (i) the
United States Foreign Corrupt Practices Act of 1977,
as amended (15 USC 78a et seq.) (“FCPA”), or any
other actions taken that otherwise would be in
violation of the FCPA if the FCPA were applicable,
or (ii) any Applicable Law.
(k) “day” means a calendar day.
(l) “Delivery” means the transfer of ownership of the
Goods from the Supplier to the Purchaser in
accordance with the terms and conditions set forth in
this Contract.
(m) “EHS” has the meaning given the term in GCC Sub-
Clause 19.1
(n) “Eligible Countries” has the meaning given such
term in GCC Sub-Clause 6.1.
(o) “Final Destination” means the place named in the
SCC.
(p) ”fraudulent practice” means any act or omission,
including any misrepresentation, in order to
influence (or attempt to influence) a selection
process or the execution of a contract to obtain a
financial or other benefit, or to avoid (or attempt to
avoid) an obligation.
(q) “GCC” means these General Conditions of Contract.
(r) “Goods” means all of the commodities, raw material,
machinery and equipment, and/or other materials
that the Supplier is required to supply to the
Purchaser under this Contract.
(s) ”Government” has the meaning given the term in the
recital clauses to this Contract.
(t) “MCC” has the meaning given the term in the recital
65
clauses to this Contract.

(u) “MCC Funding” has the meaning given the term in
the recital clauses to this Contract.
(v) “MCC Program Procurement Guidelines” means the
Millennium Challenge Corporation Program
Procurement Guidelines posted on the MCC
Website, as may be amended from time to time.
(w) “Notification of Award” means the notice sent from
the Purchaser to the Supplier notifying the Supplier
that it was the successful bidder and that its Bid had
been accepted and that forms an integral part of this
Contract.
(x) “obstructive practice” means:
(i) destroying, falsifying, altering or concealing
evidence material to the investigation or making
false statements to investigators in order to impede
an investigation into allegations of a corrupt,
fraudulent, coercive, collusive, or prohibited
practice; and threatening, harassing, or intimidating
any party to prevent it from disclosing its
knowledge of matters relevant to the investigation
or from pursuing the investigation, and
(ii) acts intended to impede materially the exercise of
the inspection and audit rights of MCC provided
under the Compact and related agreements.
(y) “Party” means the Purchaser or the Supplier, as the
case may be, and “Parties” means both of them.
(z) “prohibited practices” means any action that violates
Section E of Appendix Ato this Contract.
(aa) “Purchaser” has the meaning given the term in the
initial paragraph to this Contract.
(bb) “Related Services” means the services incidental to the
supply of the Goods, such as insurance, installation,
training and initial maintenance and other similar
obligations of the Supplier under this Contract.
(cc) “SCC” means the Special Conditions of Contract.
(dd) “Schedule of Requirements” means the Schedule of
Requirements (including the technical requirements)
set forth in Section 6of the Bidding Document.
(ee) “Subcontractor” means any person or entity to whom
any part of the Goods to be supplied or execution of
any part of the Related Services is subcontracted by the
66
Supplier in accordance with the terms of this Contract.

(ff) “Supplier” has the meaning given the term in the initial
paragraph to this Contract.
(gg) “Tax” and “Taxes” have the meanings given the terms
in the Compact or related agreement.
2. Interpretation 2.1 Unless otherwise indicated, throughout this Contract:
and General (a) “confirmation” means confirmation in writing;
Matters
(b) “in writing” means communicated in written form
(e.g., by mail, e-mail, or facsimile) delivered with
proof of receipt;
(c) except where the context requires otherwise, words
indicating the singular also include the plural and
words indicating the plural also include the singular;
(d) the feminine means the masculine and vice versa;
and
(e) the headings are for reference only and shall not
limit, alter or affect the meaning of this Contract
Incoterms 2.2 Unless inconsistent with any provision of this Contract,

the meaning of the terms EXW or CIP, and any other
trade term and the rights and obligations of the Parties
thereunder shall be as prescribed by the rules prescribed
in the current edition of Incoterms, published by the
International Chamber of Commerce at the date of this
Contract.
Entire 2.3 This Contract constitutes the entire agreement between

Agreement the Purchaser and the Supplier and supersedes all
communications, negotiations and agreements (whether
written or oral) of the Parties made prior to the date of
this Contract. No agent or representative of either Party
has the authority to make, and the Parties shall not be
bound by or be liable for, any statement, representation,
promise or agreement not set forth in this Contract.
Amendment 2.4 The following shall apply with respect to any amendment
or other variation of this Contract.
(a) No amendment or other variation of this Contract
shall be valid unless it is in writing, is dated,
expressly refers to this Contract, and is signed by a
duly authorized representative of each Party to this
Contract.
(i) The prior written consent of MCC is required in the
67
case of any amendment or other variation of this

Contract that (i) increases the value of the Contract
or (ii) changes the duration of this Contract, in
either case by more than ten (10)%.
Waivers, 2.5 The following shall apply with respect to any waivers,
Forbearance, forbearance, or similar action taken under this Contract.
Etc. (a) Any waiver of a Party’s or MCC’s rights, powers, or
remedies under this Contract must be in writing,
dated, and signed by an authorized representative of
the Party (or MCC) granting such waiver, and must
specify the terms under which the waiver is being
granted.
(b) No relaxation, forbearance, delay, or indulgence by
either Party or MCC, as the case may be, in
enforcing any of the terms and conditions of this
Contract or the granting of time by either Party or
MCC to the other shall prejudice, affect, or restrict
the rights of that Party or MCC under this Contract,
neither shall any waiver by either Party or MCC of
any breach of Contract operate as waiver of any
subsequent or continuing breach of Contract
Severability 2.6 If any provision or condition of this Contract is

prohibited or rendered invalid or unenforceable, such
prohibition, invalidity or unenforceability shall not affect
the validity or enforceability of any other provisions and
conditions of this Contract
Documents 2.7 The following documents are deemed to form an integral

Making Up part of this Contract and shall be interpreted in the
This Contract following order of priority:
(a) the Agreement consisting of the initial paragraphs,
recitals and other clauses set forth immediately prior
to the GCC and including the signatures of the
Purchaser and the Supplier;
(b) the SCC and Appendix A to this Contract;
(c) the GCC;
(d) the Notification of Award;
(e) the Supplier’s Bid;
(f) the Specifications;
(g) the Drawings;
68
(h) the Schedule of Requirements; and

(i) any other document listed in the SCC as forming
part of this Contract.
3. Fraud and 3.1 MCC requires that the Purchaser and any other
Corruption; beneficiaries of MCC funding, including bidders,
Measures to be suppliers, contractors and subcontractors under any
Taken; MCC-funded contracts, observe the highest standards of
Commissions ethics during the procurement and execution of such
and Fees contracts.
3.2 MCC may cancel the portion of MCC Funding allocated

to this Contract if it determines at any time that
representatives of the Purchaser, the Supplier or any
other beneficiary of the MCC Funding were engaged in
coercive, collusive, corrupt, fraudulent, obstructive, or
prohibited practices during the selection process or the
execution of this Contract, without the Purchaser, the
Supplier or such other beneficiary having taken timely
and appropriate action satisfactory to MCC to remedy the
situation.
3.3 MCC and the Purchaser may pursue sanction of the

Supplier, including declaring the Supplier ineligible,
either indefinitely or for a stated period of time, to be
awarded an MCC-funded contract if it at any time
determines that the Supplier has, directly or through an
agent, engaged in coercive, collusive, corrupt, fraudulent,
obstructive, or prohibited practices in competing for, or
in executing, this or another MCC-funded contract.
3.4 The Purchaser may terminate (and MCC may cause the
Purchaser to terminate) this Contract in accordance with
the terms of GCC Clause 32.1(f) if it determines that the
Supplier has, directly or through an agent, engaged in
coercive, collusive, corrupt, fraudulent,obstructive or
prohibited practices in competing for,or in the
performance of, this Contract or another MCC-funded
contract.
3.5 The Supplier shall disclose any commissions or fees that

may have been paid or are to be paid to agents,
representatives, or commission agents with respect to the
selection process or execution and performance of this
Contract. The information disclosed must include at the
name and address of the agent, representative, or
commission agent, the amount and currency, and the
69
purpose of the commission or fee.
4. Law and 4.1 This Contract, its meaning and interpretation, and the
Language relation between the Parties shall be governed by the
Governing the Applicable Law.
Contract
4.2 This Contract has been executed in the language(s)

specified in the SCC. If the Contract is executed in both
the English and another language, the English language
version shall be the binding and controlling language for
all matters relating to the meaning or interpretation of
this Contract.
5. Association 5.1 Where the Supplier is a joint venture or other association

of more than one person or entity, all of the members of
such joint venture or association shall be jointly and
severally liable to the Purchaser for the fulfilment of the
provisions of this Contract and designate the member
identified in the SCC to act on their behalf in exercising
all the Supplier’s rights and obligations toward the
Purchaser under this Contract, including without
limitation the receiving of instructions and payments
from the Purchaser. The composition or the constitution
of the joint venture or other association shall not be
altered without the prior consent of the Purchaser in
writing.
6. Eligibility 6.1 The Supplier and its Subcontractors shall at all times
during the term of this Contract have the nationality of a
Mongolia or territory eligible, in accordance with the
Compact, the MCC Program Procurement Guidelines
and Appendix A to this Contract (“Eligible Countries”).
The Supplier or a Subcontractor shall be deemed to have
the nationality of a Mongolia if it is a citizen or
constituted, incorporated, or registered, and operates in
conformity with the provisions of the laws of that
Mongolia.
6.2 All Goods and Related Services to be supplied under this

Contract and financed from the Compact shall have their
origin in Eligible Countries.
6.3 For the purpose of this GCC Clause 6, “origin” means

the place where the Goods have been mined, grown,
cultivated, produced, manufactured, or processed; or
through manufacture, processing, or assembly, another
70
commercially recognized article results that differs

substantially in its basic characteristics, purposes or
utility from its underlying components. With respect to
the Related Services, the term “origin” means the place
from which the Related Services are supplied.
7. Notices 7.1 Any notice, request or consent required or permitted to

be given or made pursuant to this Contract shall be in
writing. Any such notice, request or consent shall be
deemed to have been given or made when delivered in
person to an authorized representative of the Party to
whom the communication is addressed, or when sent to
such Party at the address specified in the SCC, or sent by
facsimile or electronic e-mail with confirmation, if sent
during normal business hours of the recipient Party,
unless the giving of notice is otherwise governed by
Applicable Law.
7.2 A Party may change its address for receiving notice

under this Contract by giving the other Party notice in
writing of such change to the address specified in the
SCC.
8. Settlement of 8.1 The Purchaser and the Supplier shall use their best efforts
Disputes to resolve amicably by direct informal negotiation any
disagreement or dispute arising between them under or in
connection with this Contract.
8.2 If the Parties fail to resolve any disagreement or dispute

in accordance with GCC Sub-Clause 8.1 within thirty
(30) days after the receipt by one Party of the other
Party’s request for such resolution, either Party may
submit the disagreement or dispute in accordance with
the provisions specified in the SCC.
9. Scope of Supply 9.1 The Goods and Related Services to be supplied shall be
as specified in the Schedule of Requirements.
9.2 Unless otherwise stipulated in this Contract, the Goods

shall include all such items not specifically mentioned in
this Contract but that can be reasonably inferred from
this Contract as being required for attaining Delivery and
Completion of the Goods and Related Services as if such
items were expressly mentioned in this Contract.
10. Delivery and 10.1 The Delivery of the Goods and Completion of the
Documents Related Services shall be in accordance with the Delivery
71
and Completion Schedule specified in the Schedule of

Requirements. The details of shipping and other
documents to be furnished by the Supplier are specified
in the SCC.
11. Supplier’s 11.1 The Supplier shall supply all the Goods and Related
Responsibilities Services included in the scope of supply in accordance
with GCC Clause 9, and the Delivery and Completion
Schedule, as per GCC Clause 10.
12. Contract Price 12.1 The contract price shall be as specified in the SCC (the
“Contract Price”) subject to any additions and
adjustments thereto, or deductions therefrom, as may be
made pursuant to this Contract.
12.2 Prices charged by the Supplier for the Goods delivered

and the Related Services performed under this Contract
shall not vary from the prices quoted by the Supplier in
its Bid, with the exception of any price adjustments
authorized in the SCC.
13. Terms of 13.1 This Contract Price, including any advance payments, if
Payment applicable, shall be paid as specified in the SCC.
13.2 The Supplier’s request for payment shall be made to the

Purchaser in writing, accompanied by invoices
describing, as appropriate, the Goods delivered and
Related Services performed, and by the documents
submitted pursuant to GCC Clause 10 and upon
fulfillment of all other relevant obligations stipulated in
this Contract.
13.3 Payments shall be made promptly by, or on behalf of, the

Purchaser, no later than thirty (30) days after receipt by
the Purchaser of an invoice or request for payment from
the Supplier in form and substance satisfactory to the
Purchaser.
13.4 The currency in which payments shall be made to the

Supplier under this Contract shall be those in which the
Bid price is expressed.
13.5 In the event that the Purchaser fails to pay the Supplier
any payment by its respective due date or within the
period set forth in the SCC, the Purchaser shall pay to the
Supplier interest on the amount of such delayed payment
at the rate shown in the SCC, for the period of delay until
payment has been made in full, whether before or after
72
judgment or arbitrage award.
14. Taxes and Duties 14.1 Except as may be exempted pursuant to the Compact or
another agreement related to the Compact, available in
English at www.mca.mn, the Supplier, its
Subcontractors and their respective personnel may be
subject to certain Taxes on amounts payable by the
Purchaser under this Contract in accordance with
Applicable Law (now or hereinafter in effect). The
Supplier, each Subcontractor and their respective
personnel shall pay all Taxes levied under Applicable
Law. In no event shall the Purchaser be responsible for
the payment or reimbursement of any Taxes. In the
event that any Taxes are imposed on the Supplier, any
Subcontractor or their respective personnel, the Contract
Price shall not be adjusted to account for such Taxes.
14.2 The Supplier, any Subcontractor and their respective

personnel, and their eligible dependents, shall follow the
usual customs procedures of Mongolia in importing
property into Mongolia.
14.3 If the Supplier, any Subcontractor or any of their

respective personnel, or their eligible dependents, do not
withdraw but dispose of any property in Mongolia upon
which customs duties or other Taxes have been
exempted, the Supplier, the Subcontractor or such
personnel, as the case may be, (a) shall bear such
customs duties and other Taxes in conformity with
Applicable Law, or (b) shall reimburse such customs
duties and Taxes to the Purchaser if such customs duties
and Taxes were paid by the Purchaser at the time the
property in question was brought into [Mongolia].
14.4 Without prejudice to the rights of the Supplier under this

clause, the Supplier, the Subcontractors and their
respective personnel will take reasonable steps as
requested by the Purchaser or the Government with
respect to the determination of the Tax status described
in this GCC Clause 14.
14.5 If the Supplier is required to pay Taxes that are exempt

under the Compact or a related agreement, the Supplier
shall promptly notify the Purchaser (or such agent or
representative designated by the Purchaser) of any Taxes
paid, and the Supplier shall cooperate with, and take such
actions as may be requested by the Purchaser, MCC, or
73
either of their agents or representatives, in seeking the

prompt and proper reimbursement of such Taxes.
14.6 The Purchaser shall use reasonable efforts to ensure that

the Government provides the Supplier, the
Subcontractors, and their respective personnel the
exemptions from taxation applicable to such persons or
entities, in accordance with the terms of the Compact or
related agreements. If the Purchaser fails to comply with
its obligations under this GCC Sub-clause 14.6, the
Supplier shall have the right to terminate this Contract in
accordance with GCC Clause 33.1(d).
15. Performance 15.1 The Supplier shall, within fourteen (14) days of the
Security notification of contract award, provide a performance
security for the due performance of this Contract in the
amount specified in the SCC.
15.2 The proceeds of the performance security shall be

payable to the Purchaser as compensation for any loss
resulting from the Supplier’s failure to complete its
obligations in accordance with the terms of this Contract.
15.3 The performance security shall be denominated in the

currency of this Contract, and shall be in the form of
either a bank guarantee or an irrevocable letter of credit
issued by a reputable bank located in Purchaser’s
Mongolia or in an Eligible Mongolia and in form and
substance satisfactory to the Purchaser, substantially in
the form included in Section 6.
15.4 The performance security shall be discharged by the

Purchaser and returned to the Supplier not later than
twenty-eight (28) days following the date of completion
of the Supplier’s performance obligations under this
Contract, including any warranty obligations.
16. Copyright 16.1 The copyright in all drawings, documents, and other
materials containing data and information furnished to
the Purchaser by the Supplier shall remain vested in the
Supplier, or, if they are furnished to the Purchaser
directly or through the Supplier by any third party,
including suppliers of materials, the copyright in such
materials shall remain vested in such third party.
17. Confidential 17.1 The Purchaser and the Supplier shall keep confidential
Information and shall not, without the prior written consent of the
74
other Party, divulge to any third party any documents,

data, or other information furnished directly or indirectly
by the other Party in connection with this Contract,
whether such information has been furnished prior to,
during or following completion or termination of this
Contract. Notwithstanding the above, the Supplier may
furnish to its Subcontractor such documents, data, and
other information it receives from the Purchaser to the
extent required for the Subcontractor to perform its work
under this Contract, in which event the Supplier shall
obtain from such Subcontractor an undertaking of
confidentiality similar to that imposed on the Supplier
under this GCC Clause 17.
17.2 The Purchaser shall not use documents, data, and other
information received from the Supplier for any purposes
unrelated to this Contract. Similarly, the Supplier shall
not use documents, data, and other information received
from the Purchaser for any purpose other than the design,
procurement, or other work and services required for the
performance of this Contract.
17.3 The obligation of a Party under GCC Sub-Clauses 17.1

and 17.2 above, however, shall not apply to information
that:
(a) the Purchaser or the Supplier needs to share with
MCC or other entities participating in the financing
of this Contract or otherwise in accordance with the
requirements of the Compact or related documents;
(b) now or hereafter enters the public domain through
no fault of that Party;
(c) can be proven to have been possessed by that Party
at the time of disclosure and which information was
not previously obtained, directly or indirectly, from
the other Party;
(d) otherwise lawfully becomes available to that Party
from a third party that has no obligation of
confidentiality; or
(e) is required to be shared to comply with applicable
law
17.4 The provisions of GCC Clause 17 shall survive

completion or termination, for whatever reason, of this
Contract.
75
18. Subcontracting 18.1 The Supplier shall obtain prior approval in writing of the
Purchaser before entering into a subcontract for the
performance of any of its obligations under this Contract.
The Supplier shall notify the Purchaser in writing of all
subcontracts awarded under this Contract if not already
specified in the Bid. Subcontracting shall in no event
relieve the Supplier from any of its obligations, duties,
responsibilities, or liabilities under this Contract.
18.2 Subcontracts shall comply with the provisions of GCC

Clauses 3 and 6.
19. Specifications 19.1 The Goods and Related Services supplied under this
and Standards Contract shall conform to the technical specifications and
standards, including environmental, health and safety
(“EHS”) requirements, specified in the Schedule of
Requirements and, when no applicable standard is
mentioned, the standard shall be equivalent or superior to
the official standards whose application is appropriate to
the Goods’ and Related Services’ Mongolia(ies) of
origin.
19.2 The Supplier shall be entitled to disclaim responsibility

for any design, data, drawing, specification or other
document, or any modification thereof provided or
designed by or on behalf of the Purchaser, by giving a
notice of such disclaimer to the Purchaser.
19.3 Wherever references are made in this Contract to codes

and standards in accordance with which it shall be
executed, the edition or the revised version of such codes
and standards shall be those specified in the Schedule of
Requirements. During Contract execution, any changes
in any such codes and standards shall be applied only
after approval by the Purchaser and shall be treated in
accordance with GCC Clause 30.
20. Packing and 20.1 The Supplier shall provide such packing of the Goods as
Documents is required to prevent their damage or deterioration
during transit to their Final Destination. During transit,
the packing shall be sufficient to withstand, without
limitation, rough handling and exposure to extreme
temperatures, salt and precipitation, and open storage.
Packing case size and weights shall take into
consideration, where appropriate, the remoteness of the
Goods’ Final Destination and the absence of heavy
76
handling facilities at all points in transit.
20.2 The packing, marking, and documentation within and

outside the packages shall comply strictly with such
special requirements as shall be expressly provided for in
this Contract, including additional requirements, if any,
specified in the SCC, and in any other instructions
ordered by the Purchaser.
21. Insurance 21.1 Unless otherwise specified in the SCC, the Goods
supplied under this Contract shall be fully insured, in a
freely convertible currency from an Eligible Mongolia,
against loss or damage incidental to manufacture or
acquisition, transportation, storage, and delivery, in
accordance with the applicable Incoterms.
22. Transportation 22.1 Unless otherwise specified in the SCC, responsibility for
arranging transportation of the Goods shall be in
accordance with the Incoterms and as specified in the
Schedule of Requirements.
23. Inspections and 23.1 The Supplier shall at its own expense and at no cost to
Tests the Purchaser carry out all such tests and/or inspections
of the Goods and Related Services as are specified in the
Schedule of Requirements.
23.2 The inspections and tests may be conducted on the

premises of the Supplier or its Subcontractor, at point of
delivery, and/or at the Goods’ Final Destination, or in
another place in Purchaser’s Mongolia as specified in the
SCC. Subject to GCC Sub-Clause 23.3, if conducted on
the premises of the Supplier or its Subcontractor, all
reasonable facilities and assistance, including access to
drawings and production data, shall be furnished to the
inspectors at no charge to the Purchaser.
23.3 The Purchaser or its designated representative shall be

entitled to attend the tests and/or inspections referred to
in GCC Sub-Clause 23.2, provided that the Purchaser
bear all of its own costs and expenses incurred in
connection with such attendance including, but not
limited to, all traveling and board and lodging expenses.
23.4 Whenever the Supplier is ready to carry out any such test
and inspection, it shall give a reasonable advance notice,
including the place and time, to the Purchaser. The
Supplier shall obtain from any relevant third party or
77
manufacturer any necessary permission or consent to

enable the Purchaser or its designated representative to
attend the test and/or inspection.
23.5 The Purchaser may require the Supplier to carry out any
test and/or inspection not required by this Contract but
deemed necessary to verify that the characteristics and
performance of the Goods comply with the technical
specifications codes and standards under this Contract,
provided that the Supplier’s reasonable costs and
expenses incurred in the carrying out of such test and/or
inspection shall be added to this Contract Price. Further,
if such test and/or inspection impedes the progress of
manufacturing and/or the Supplier’s performance of its
other obligations under this Contract, due allowance will
be made in respect of the delivery dates and completion
dates and the other obligations so affected.
23.6 The Supplier shall provide the Purchaser with a report of

the results of any such test and/or inspection.
23.7 The Purchaser may reject any Goods or any part thereof
that fail to pass any test and/or inspection or do not
conform to the specifications, including EHS
requirements. The Supplier shall either rectify or replace
such rejected Goods or parts thereof or make alterations
necessary to meet the specifications at no cost to the
Purchaser, and shall repeat the test and/or inspection, at
no cost to the Purchaser, upon giving a notice pursuant to
GCC Sub-Clause 23.4.
23.8 The Supplier agrees that neither the execution of a test

and/or inspection of the Goods or any part thereof, nor
the attendance by the Purchaser or its representative, nor
the issue of any report pursuant to GCC Sub-Clause 23.6,
shall release the Supplier from any warranties or other
obligations under this Contract.
24. Liquidated 24.1 Except as provided under GCC Clause 29, if the Supplier
Damages fails to deliver any or all of the Goods or perform the
Related Services within the period specified in this
Contract, the Purchaser may without prejudice to any and
all of its other remedies under this Contract, or applicable
law, deduct from this Contract Price, as liquidated
damages, a sum equivalent to the percentage specified in
the SCC of this Contract Price for each week or part
thereof of delay until actual delivery or performance, up
78
to a maximum deduction of the percentage specified in

the SCC. Once the maximum is reached, the Purchaser
may terminate this Contract pursuant to GCC Clause 32.
25. Warranty 25.1 The Supplier warrants that all the Goods are new,
unused, and of the most recent or current models, and
that they incorporate all recent improvements in design
and materials, unless provided otherwise in this Contract.
25.2 Subject to GCC Sub-Clause 19.2, the Supplier further

warrants that the Goods shall be free from defects arising
from any act or omission of the Supplier or arising from
design, materials, or workmanship that may develop
under normal use in the conditions prevailing in the
Purchaser’s Mongolia.
25.3 Unless otherwise specified in the SCC, the warranty shall

remain valid for twelve (12) months after the Goods, or
any portion thereof as the case may be, have been
delivered to and accepted at the Final Destination, or for
eighteen (18) months after the date of shipment from or
loading in the Mongolia of origin, whichever period
concludes earlier. The warranty period for Goods that
were repaired or replaced during the warranty period
shall be twelve (12) months from the date on which such
Goods were repaired or replaced.
25.4 The Purchaser shall give notice to the Supplier stating the
nature of any defects together with all available evidence
thereof, promptly following the discovery thereof. The
Purchaser shall afford all reasonable opportunity for the
Supplier to inspect such defects.
25.5 Upon receipt of such notice, the Supplier shall, within the
period specified in the SCC, expeditiously repair or
replace the defective Goods or parts thereof, at no cost to
the Purchaser.
25.6 If having been notified, the Supplier fails to remedy the

defect within the period specified in SCC 25.5; the
Purchaser may proceed to take within a reasonable
period such remedial action as may be necessary, at the
Supplier’s risk and expense and without prejudice to any
other rights which the Purchaser may have against the
Supplier under this Contract or applicable law.
26. Patent Indemnity 26.1 The Supplier shall, subject to the Purchaser’s compliance
79
with GCC Sub-Clause 26.2, indemnify and hold harmless

the Purchaser and its employees, officers and directors
from and against any and all suits, actions or
administrative proceedings, claims, demands, losses,
damages, costs, and expenses of any nature, including
attorney’s fees and expenses, which the Purchaser may
suffer as a result of any infringement or alleged
infringement of any patent, utility model, registered
design, trademark, copyright, or other intellectual
property right registered or existing by reason of:
(a) the installation of the Goods by the Supplier or the
use of the Goods in the Purchaser’s Mongolia; and
(b) the sale in any Mongolia of the products produced
by the Goods.
Such indemnity shall not cover any use of the Goods or
any part thereof other than for the purpose indicated by
or to be reasonably inferred from this Contract, neither
any infringement resulting from the use of the Goods or
any part thereof, or any products produced thereby in
association or combination with any other equipment,
plant, or materials not supplied by the Supplier, pursuant
to this Contract.
26.2 If any proceedings are brought or any claim is made

against the Purchaser arising out of the matters referred
to in GCC Sub-Clause 26.1, the Purchaser shall promptly
give the Supplier a notice thereof, and the Supplier may
at its own expense and in the Purchaser’s name conduct
such proceedings or claim and any negotiations for the
settlement of any such proceedings or claim.
26.3 If the Supplier fails to notify the Purchaser within

twenty-eight (28) days after receipt of such notice that it
intends to conduct any such proceedings or claim, then
the Purchaser shall be free to conduct the same on its
own behalf.
26.4 The Purchaser shall, at the Supplier’s request, afford all

reasonably available assistance to the Supplier in
conducting such proceedings or claim, and shall be
reimbursed by the Supplier for all reasonable expenses
incurred in so doing.
26.5 The Purchaser shall indemnify and hold harmless the

Supplier and its employees, officers, and Subcontractors
from and against any and all suits, actions or
80
administrative proceedings, claims, demands, losses,

damages, costs, and expenses of any nature, including
attorney’s fees and expenses, which the Supplier may
suffer as a result of any infringement or alleged
infringement of any patent, utility model, registered
design, trademark, copyright, or other intellectual
property right registered or otherwise existing at the date
of this Contract arising out of or in connection with any
design, data, drawing, specification, or other documents
or materials provided or designed by or on behalf of the
Purchaser.
27. Limitation of 27.1 Except in cases of criminal negligence or willful

Liability misconduct,
(a) the Supplier shall not be liable to the Purchaser,
whether in contract, tort, or otherwise, for any
indirect or consequential loss or damage, loss of use,
loss of production, or loss of profits or interest costs,
provided that this exclusion shall not apply to any
obligation of the Supplier to pay liquidated damages
to the Purchaser; and
(b) the aggregate liability of the Supplier to the
Purchaser, whether under this Contract, in tort or
otherwise, shall not exceed the total Contract Price,
provided that this limitation shall not apply to the
cost of repairing or replacing defective equipment,
or to any obligation of the supplier to indemnify the
Purchaser in accordance with GCC Clause 26.
28. Change in Laws 28.1 Unless otherwise specified in this Contract, if after the
and Regulations date of the Bidding Document, any law, regulation,
ordinance, order or by-law having the force of law is
enacted, promulgated, abrogated, or changed in the
particular area of the Purchaser’s Mongolia where the
Final Destination is located (which shall be deemed to
include any change in interpretation or application by the
competent authorities) that subsequently affects the
delivery date and/or this Contract Price, then such
delivery date and/or Contract Price shall be
correspondingly increased or decreased, to the extent that
the Supplier has thereby been affected in the
performance of any of its obligations under this Contract.
Notwithstanding the foregoing, such additional or
reduced cost shall not be separately paid or credited if the
same has already been accounted for in the price
adjustment provisions where applicable, in accordance
81
with GCC Clause 12.
28.2 Notwithstanding the provisions of GCC Sub-clause 28.1,

if, after the date of this Contract, there is any change in
the Applicable Law with respect to Taxes that increases
or decreases the cost incurred by the Supplier in
performing its obligations under this Contract, payments
to the Supplier shall not be adjusted. However, the
provisions of GCC Sub-Clause 14.6 shall be applicable
in such a situation.
29. Force Majeure 29.1 For the purposes of this Contract, “Force Majeure”
means an event or condition that (a) is not reasonably
foreseeable and is beyond the reasonable control of a
Party, and is not the result of any acts, omissions or
delays of the Party relying on such event of Force
Majeure, (or of any third party over whom such Party has
control, including any Subcontractor), (b) is not an act,
event or condition the risks or consequence of which
such Party has expressly agreed to assume under this
Contract, (c) could not have been prevented, remedied or
cured by such Party’s reasonable diligence, and (d)
makes such Party’s performance of its obligations under
this Contract impossible or so impractical as to be
considered impossible under the circumstances.
29.2 The failure of a Party to fulfill any of its obligations

under this Contract shall not be considered to be a breach
of, or default under, this Contract insofar as such
inability arises from an event of Force Majeure, provided
that the Party affected by such an event (a) has taken all
reasonable precautions, due care and reasonable
alternative measures in order to carry out the terms and
conditions of this Contract, and (b) has informed the
other Party as soon as practicable (and in no event later
than five (5) days after the occurrence) about the
occurrence of an event giving rise to a claim of Force
Majeure.
29.3 A Party affected by an event of Force Majeure shall

continue to perform its obligations under this Contract as
far as is reasonably practical, and shall take all
reasonable measures to minimize and otherwise mitigate
the consequences of any event of Force Majeure.
29.4 A Party affected by an event of Force Majeure shall

provide evidence of the nature and cause of such event,
82
and shall similarly give written notice of the restoration

of normal conditions as soon as possible.
29.5 Any period within which a Party shall, pursuant to this

Contract, complete any action or task, shall be extended
for a period equal to the time during which such Party
was unable to perform such action as a result of Force
Majeure.
29.6 The Supplier shall not be liable for forfeiture of its

performance security, liquidated damages, or termination
for default (other than in accordance with GCC Sub-
Clause 32.1 (d) if and to the extent that its delay in
performance or other failure to perform its obligations
under this Contract is the result of an event of Force
Majeure.
29.7 In the case of disagreement between the Parties as to the

existence or extent of an event of Force Majeure, the
matter shall be settled in accordance with GCC Clause 8.
30. Change Orders 30.1 The Purchaser may at any time order the Supplier
and Contract through notice in accordance GCC Clause 7, to make
Amendments changes within the general scope of this Contract in any
one or more of the following:
(a) drawings, designs, or specifications, where Goods to
be furnished under this Contract are to be
specifically manufactured for the Purchaser;
(b) the method of shipment or packing;
(c) the place of delivery; and
(d) the Related Services to be provided by the Supplier.
30.2 If any such change causes an increase or decrease in the

cost of, or the time required for, the Supplier’s
performance of any provisions under this Contract, an
equitable adjustment shall be made in this Contract Price
or in the delivery/completion schedule, or both, and this
Contract shall accordingly be amended. Any claims by
the Supplier for adjustment under this Clause must be
asserted within twenty-eight (28) days from the date of
the Supplier’s receipt of the Purchaser’s change order.
All claims for adjustment submitted by the Supplier
pursuant to this clause shall include a reasonably detailed
explanation of the increased costs and/or time, including
reasons for such increases.
83
30.3 Prices to be charged by the Supplier for any Related

Services that might be needed but which were not
included in this Contract shall be agreed upon in advance
by the Parties and shall not exceed the prevailing rates
charged to other parties by the Supplier for similar
services
31. Extensions of 31.1 If at any time during performance of this Contract, the
Time Supplier or its Subcontractors should encounter
conditions impeding timely delivery of the Goods or
completion of Related Services pursuant to GCC Clause
10, the Supplier shall promptly notify the Purchaser in
writing of the delay, its likely duration, and its cause. As
soon as practicable after receipt of the Supplier’s notice,
the Purchaser shall evaluate the situation and may at its
sole discretion extend the Supplier’s time for
performance (with or without liquidated damages as
determined by the Purchaser in its sole discretion), in
which case the extension shall be ratified by the Parties
by amendment of this Contract.
31.2 Except in case of Force Majeure, as provided under GCC

Clause 29, a delay by the Supplier in the performance of
its Delivery and Completion obligations shall render the
Supplier liable to the imposition of liquidated damages
pursuant to GCC Clause 24, unless an extension of time
is agreed upon, pursuant to GCC Sub-Clause 31.1.
32. Termination by 32.1 Termination for Default:

Purchaser
Without prejudice to any other remedies that may be
available to it for breach of this Contract, the Purchaser,
upon written notice to the Supplier, may terminate this
Contract, in whole or in part, in case of the occurrence of
any of the events specified in sub-paragraphs (a) through
(f) of this GCC Sub-Clause 32.1.
(a) If the Supplier, in the judgment of the Purchaser or
MCC, fails to perform its obligations relating to the
use of funds set out in Appendix A. Termination
under this provision shall (i) become effective
immediately upon delivery of the notice of
termination and (ii) require that the Supplier repay
any and all funds so misused within a maximum of
thirty (30) days after termination.
(b) If the Supplier fails to deliver or perform any or all
of the Goods or Related Services within the period
84
specified in this Contract, or within any extension

thereof granted by the Purchaser pursuant to GCC
Sub-Clause 31.1. Termination under this provision
shall become effective immediately upon the
expiration of thirty (30) days after delivery of the
notice of termination or such later date as may be
specified by the Purchaser. In the event the
Purchaser terminates this Contract in whole or in
part, pursuant to this sub-paragraph, the Purchaser
may procure, upon such terms and in such manner as
it deems appropriate, Goods or Related Services
similar to those undelivered or not performed, and
the Supplier shall be liable to the Purchaser for any
additional costs for such similar Goods or Related
Services. However, the Supplier shall continue
performance of this Contract to the extent not
terminated.
(c) If the Supplier does not remedy a failure to perform
any of its other obligation under this Contract (other
than a failure contemplated by sub-paragraphs (a) or
(b) immediately preceding this sub-paragraph)
within thirty (30) days after delivery of the notice of
termination or within any further period of time
approved in writing by the Purchaser. Termination
under this provision shall become effective
immediately upon the expiration of the thirty (30)
days or such later date as may be specified by the
Purchaser.
(d) If, as the result of an event of Force Majeure, the
Supplier is unable to perform a material portion of
its obligations for a period of not less than sixty (60)
days. Termination under this provision shall
become effective upon the expiration of thirty (30)
days after delivery of the notice of termination or on
such later date as may be specified by the Purchaser.
(e) If the Supplier fails to comply with any final
decision reached as a result of arbitration
proceedings pursuant to GCC Clause 8. Termination
under this provision shall become effective upon the
expiration of thirty (30) days after deliver of the
notice of termination or on such later date as may be
specified by the Purchaser.
(f) If the Supplier (or any Subcontractor or any of their
respective personnel), in the judgment of the
Purchaser, has, directly or through an agent, engaged
85
in coercive, collusive, corrupt, fraudulent,

obstructive, or prohibited practices in competing for
or in the performance of this Contract. Termination
termination.
32.2 Termination for Insolvency.
The Purchaser may at any time terminate this Contract by

giving notice to the Supplier if the Supplier becomes
insolvent or bankrupt, and/or fails to exist or is dissolved.
Termination under this provision shall become effective
immediately upon delivery of the notice of termination or
on such other date as may be specified by the Purchaser
in such notice of termination. In such event, termination
will be without compensation to the Supplier, provided
that such termination will not prejudice or affect any
right of action or remedy that has accrued or will accrue
thereafter to the Purchaser.
32.3 Termination for Convenience

(a) The Purchaser, by notice sent to the Supplier, may
terminate this Contract, in whole or in part, at any
time in its sole discretion for its convenience. The
notice of termination shall specify that termination is
for the Purchaser’s convenience, the extent to which
performance of the Supplier under this Contract is
terminated, and the date upon which such
termination becomes effective.
(b) In the case of any termination in accordance with
this GCC Sub-Clause 32.3, the Goods that are
complete and ready for shipment within twenty-eight
(28) days after the Supplier’s receipt of notice of
termination shall be accepted by the Purchaser at this
Contract terms and prices. For the remaining Goods,
the Purchaser may elect:
(i) to have any portion completed and delivered at the
terms and prices set forth in this Contract; and/or
(ii) to cancel the remainder and pay to the Supplier an
agreed amount for partially completed Goods and
Related Services and for materials and parts
previously procured by the Supplier.
32.4 Suspension or Termination Related to the Compact or
86
Applicable Law
(a) The Purchaser, by notice sent to the Supplier, may
suspend or terminate this Contract, in whole or in
part, if the Compact expires, is suspended or
terminates in whole or in part in accordance with the
terms of the Compact. Suspension or termination
suspension or termination, as the case may be, in
accordance with the terms of the notice. If this
Contract is suspended pursuant to this GCC Clause
32.4(a), the Supplier has an obligation to mitigate all
expenses, damages and losses to the Purchaser
during the period of the suspension.
(b) The Purchaser, by notice sent to the Supplier, may
suspend or terminate this Contract, in whole or in
part, if suspension or termination is permitted under
Applicable Law. Suspension or termination under
this provision shall become effective immediately
upon delivery of the notice of suspension or
termination, as the case may be, in accordance with
the terms of the notice. If this Contract is suspended
pursuant to this GCC Clause 32.4(b) the Supplier
has an obligation to mitigate all expenses, damages
and losses to the Purchaser during the period of the
suspension.
33. Termination by 33.1 The Supplier may terminate this Contract, by not less
the Supplier than thirty (30) days’ written notice to the Purchaser, in
case of the occurrence of any of the events specified in
paragraphs (a) through (e) of this GCC Sub-Clause 33.1.
(a) If the Purchaser fails to pay any money due to the
Supplier pursuant to this Contract that is not
otherwise subject to dispute pursuant to GCC Clause
8 within forty-five (45) days after receiving written
notice from the Supplier that such payment is
overdue. Termination under this provision shall
become effective upon the expiration of thirty (30)
days after delivery of the notice of termination
unless the payment that is the subject of such notice
of termination is made by the Purchaser to the
Supplier within such thirty (30) days.
(b) If, as the result of an event of Force Majeure, the
Supplier is unable to perform a material portion of
this Contract for a period of not less than sixty (60)
87
days. Termination under this provision shall become

effective upon the expiration of thirty (30) days after
delivery of the notice of termination.
(c) If the Purchaser fails to comply with any final
decision reached as a result of arbitration pursuant to
GCC Clause 8. Termination under this provision
shall become effective upon the expiration of thirty
(30) days after deliver of the notice of termination.
(d) If the Supplier does not receive a reimbursement of
any Taxes that are exempt under the Compact within
one hundred and twenty (120) days after the
Supplier gives notice to the Purchaser that such
reimbursement is due and owing to the Supplier.
Termination under this provision shall become
delivery of the notice of termination unless the
reimbursement that is the subject of such notice of
termination is made to the Supplier within such
thirty (30) days.
(e) If this Contract is suspended in accordance with
GCC Clauses 32.4(a) or 32.4(b)for a period of time
exceeding three (3) consecutive months; provided
that the Supplier has complied with its obligation to
mitigate in accordance with GCC Clauses 32.4(a) or
32.4(b) during the period of the suspension.
Termination under this provision shall become
delivery of the notice of termination.
34. Assignment 34.1 The Supplier shall not assign, in whole or in part, its
obligations under this Contract, except with prior written
consent of the Purchaser.
35. Reimbursable 35.1 If this Contract permits re-imbursement of any costs, the
Amounts re-imbursement amounts shall be limited by and made
only in accordance with applicable MCC cost principles
which are posted at www.mcc.gov.
36. Accounting, 36.1 The Supplier shall keep accurate and systematic accounts
Inspection and and records in respect of the provision of the Goods and
Auditing Related Services under this Contract, in accordance with
the provisions of Appendix A and internationally
accepted accounting principles.
37. Use of Funds; 37.1 The Supplier shall ensure that its activities do not violate
Compliance with provisions relating to use of funds and environmental
88
Environmental guidelines, as set out in Appendix A.

Guidelines
38. MCC 38.1 For the avoidance of doubt, the Parties agree and
Conditionalities understand that the provisions set forth in Appendix A
reflect certain requirements of the Government and the
Purchaser under the terms of the Compact and related
documents that are required to be transferred onto any
supplier, subcontractor or other associate who partakes in
procurement or subsequent contracts in which MCC
funding is involved and that, as with the other clauses of
this Contract, the provisions of Appendix A are binding
obligations under this Contract.
39. Flow through 39.1 In any sub-contract or sub-award entered into by the
Provisions Supplier, as permitted by the terms of this Contract, the
Supplier shall ensure the inclusion of all the provisions
contained in Appendix A in any agreement related to
such sub-contract or sub-award.
89
IV. Special Conditions of Contract

The following Special Conditions of Contract (SCC) shall supplement and/or amend the
General Conditions of Contract (GCC). Whenever there is a conflict, the provisions
herein shall prevail over those in the GCC.
GCC1.1(o) The Final Destination is:

The Supplier is responsible for delivery of Goods in portion to all
final destinations prescribed in Distribution Table or other named
destination as otherwise may agreed with Purchaser.
Site City / Town /
Site
Code Region
General Authority for State

CO Registration( GASR) Central Ulaanbaatar
Office
Ulaanbaatar city district Offices

TO01 Baganuur, Bayanzurkh,
Chingeltei, Songino-Khairkhan

RO04 Zavhan

RO05 Orkhon
GCC 2.7 Other documents forming an integral part of this Contract are:
None
GCC 4.2 This Contract shall be executed in English.
GCC 5.1 The member in charge is [insert name of member]
90
[Note: If the Supplier consists of a joint venture or another

association of more than one entity, the name of the entity
whose address is specified in SCC 7.1 should be inserted here.
If the Supplier consists only of one entity, this SCC 5.1 should
be deleted from the SCC.]
GCC 7.1 For notices that are served on the Purchaser the address shall be:
Att.: The Procurement Agent of MCA-M
Tel: +976 70120032; Fax: +976 70120031

For notices that are served on the Supplier the address shall be:
XXXXXX
GCC 7.2 For changes of address that are served on the Purchaser the
address shall be:
Att.: The Procurement Agent of MCA-M
Tel:+97670120032 Fax:+97670120031
For changes of address that are served on the Supplier the
address shall be:
XXXXXX
GCC 8.2 Disputes arising under this Contract that are not resolved by the
Parties in accordance with GCC Sub-Clause 8.1, shall be settled
by arbitration in accordance with the following provisions:
Unless, any such dispute, controversy or claim between the Parties arising
out of or relating to this Contract or the breach, termination or invalidity
thereof is settled amicably under the preceding paragraph of this Section
within thirty (30) days after receipt by one Party of the other Party's
request for such amicable settlement, such dispute, controversy or claim
shall be referred by either Party to arbitration in accordance with the
UNCITRAL Arbitration Rules then obtaining, including its provisions on
applicable law. The Parties shall be bound by any arbitration award
91
rendered as a result of such arbitration as the final adjudication of any such

controversy, claim or dispute.
MCC Right to Observe
MCC has the right to be an observer to any arbitration
proceeding associated with this Contract, at its sole
discretion, but does not have the obligation to participate
in any arbitration proceeding. Whether or not MCC is an
observer to any arbitration associated with this Contract,
the Parties shall provide MCC with written English
transcripts of any arbitration proceedings or hearings and a
copy of the reasoned written award within ten (10) days
after (a) each such proceeding or hearing or (b) the date on
which any such award is issued. MCC may enforce its
rights under this Contract in an arbitration conducted in
accordance with this provision or by bringing an action in
any court that has jurisdiction. The acceptance by MCC
of the right to be an observer to the arbitration shall not
constitute consent to the jurisdiction of the courts or any
other body of any jurisdiction or to the jurisdiction of any
arbitral panel.
GCC 10.1 Delivery and Documents

For Goods supplied from outside Purchaser’s Mongolia:
Upon shipment, the Supplier shall notify the Purchaser and the
insurance company in writing of the full details of the shipment,
including contract number, description of Goods being shipped,
quantity, the vessel, the bill of lading number and date, port of loading,
date of shipment, port of discharge, etc. The Supplier shall fax or e-mail
and send by courier the following documents to the Purchaser, with a
copy to the insurance company:
- original, three (3) copies of the Supplier’s invoice showing the
shipped Goods’ description, quantity, unit price, and total amount;
- original and three (3) copies of the negotiable, clean, on-board
bill of lading or airway bill or courier bill or way of bill by other forms
of transportation marked “freight prepaid” and three (3) copies of
nonnegotiable bill of lading or similar;
- three (3) copies of the packing list identifying contents of each
package;
- insurance certificate, showing the Purchaser as the beneficiary;
- Manufacturer’s or Supplier’s warranty certificate;
- inspection certificate, issued by the nominated inspection
agency, and the Supplier’s factory inspection report;
- certificate of origin;
- the international or national Certification of Standard Reference
Materials
- any other procurement-specific document required for delivery
92
or payment purposes.
The above documents shall be received by the Purchaser at least one

week before arrival of the Goods at the port or place of arrival and, if
not received, the Supplier will be responsible for any consequent
expenses.
b. For Goods within the Purchaser’s Mongolia:
Upon delivery of the Goods to the transporter, the Supplier shall notify
the Purchaser and send the following documents to the Purchaser:
(a) original and three (3) copies of the Supplier’s invoice showing the
description of the Goods, quantity, unit price, and total amount;
(b) three (3) copies of the packing list identifying contents of each
package
(c) delivery note, railway receipt, or truck receipt;
(d) Manufacturer’s or Supplier’s warranty certificate;
(e) inspection certificate, issued by the nominated inspection agency,
and/or the Supplier’s factory inspection certificate;
(f) the international or national Certification of Standard Reference
Materials; and
(g) certificate of origin
GCC 12.1 The Contract Price is XXXXX United States Dollars.

The accounts are:
For US Dollars: [insert account number]
For Local Currency : [insert account number]
GCC 12.2 The prices charged for the Goods delivered and Related Services
performed shall not be adjustable.
GCC 13.1 The method and conditions of payment to be made to the Supplier
under this Contract shall be as follows:
Payment for Goods and Related Services supplied from
outside Purchaser’s Mongolia:
Pillars I and Ib
- On Signing of the Contract: the Purchaser shall pay the Supplier
10% of the Contract Price of the Goods against bank guarantee for
Advance Payment for the same amount.
- On shipment: The Purchase shall pay the Supplier 70% of the
Contract Price of the Goods shipped via documentary Letter of Credit
against documents specified in SCC Clause 10.1.a
- On Acceptance: 20% of the Contract Price of Goods Received
and with the Related Services completed shall be paid within 30 days
93
upon submission of original invoice supported by the acceptance

certificate issued by the Purchaser and Performance Security in
accordance with SCC Clause 25.3
Payment for Goods and Related Services supplies from within the
Purchaser’s Mongolia:
- On Signing of the Contract: the Purchaser shall pay the Supplier

10% of the Contract Price of the Goods against bank guarantee for
Advance Payment for the same amount.
- On Arrival: The Purchase shall pay the Supplier 70% of the
Contract Price of the Goods shipped within 30 days against documents
specified in SCC Clause 10.1.b.
- On Acceptance: 20% of the Contract Price of Goods Received
and with the Related Serviced completed shall be paid within 30 days
upon submission of original invoice supported by the acceptance
certificate issued by the Purchaser and Performance Security in
accordance with SCC Clause 25.3.
Pillar 2: for the Related Services for Pillar 1(a) payments
will be in accordance with the following Benchmarks
The milestones related to the payment schedule defined for the
project are:
Milestone Description % of Related
Services Bid
Price
Detailed Project Plan
Inception Project Work Plan 7.5%
Accepted Data migration methodology 2.5%
Digitizational Accepted Digitized Data
process 25%
Accepted converted Triada Database
Data Accepted converted and Real databases 10%
Conversion Incorporation of separate databases
Process Data validation and conversion
Accepted Migrated Data 20%
Implementation Accepted implementation of Digital
Archive
Accepted Training Evaluation 20%
Accepted Documentation
Operation Accepted procedures for going live with
the digital archive 10%
Accepted Operation of digital archive
(Warranty Period) 5%
Pillar 3: payments will be in accordance with the following

94
Benchmarks
Milestone Description % of related

Services Bid
Price
Feasibility report
Inception
Detailed Project Plan
Accepted Definition of ePRS 5%
Accepted Analysis & requirements ePRS
Accepted Detailed Design ePRS
Design 8%
Accepted Site Preparation Plan
Accepted Development of Basic System
Development
Components
Accepted development of key 20%
Application modules
Accepted Development of Front-end
10%
Solutions
Accepted ePRS Pilot
Accepted Testing ePRS
Accepted Training Plan 25%
Accepted Implementation ePRS
Implementation 12%
Accepted Training Evaluation
Accepted Documentation including
5%
ePRS Software Code
Accepted procedures for going live with
Operation 10%
the system
Acceted Operation ePRS (warrant

5%
period)
GCC 13.5 The interest rate to be applied in the case of late payments is the
Federal Funds Rate as stated on the website
www.federalreserve.gov/fomc/funds/rate.htm
GCC 15.1 The amount of performance security, as a percentage of the

Contract Price, shall be in the amount of 10% of the Contract
Priceand shall be denominated in the currencies of payment of
this Contract, in accordance with their portions of the Contract
Price.
GCC 20.2 The packing, marking and documentation within and outside the
packages shall be: Property Registration Department of
General Authority for State Registration
The following requirements are minimum and shall not be considered
exhaustive:
- Heavy packages shall be mounted on skids for lifting by forklift or
attachment of slings; where unsafe to apply external slings, attached
95
slings of lifting devices shall be provided. Packages and contents must

be capable of withstanding compression, rain, as well as tough road
conditions in Mongolia when the Goods are transported by truck.
- copies of invoice and packing list shall accompany each package. One
copy of invoice and packing list should be attached to outside of the
corresponding package duly protected against humidity and loss.
Another copy should be put inside clearly visible when the top of the
package is opened.
- Supplier shall show on the packing list quantities, net and gross
weights and cubic measurement.
- all boxes, packages shall also bear the handling information, warnings
and special labels as may be required under the existing rules and
regulations governing the acceptance of cargo transportation by either
sea, rail, road or air freight.
- the consignee shall be marked as follows:
“Consignee:
D.Odonchimeg
Property Right Project Director
Room #414, Government Building -12
Ministry of Road, Transportation, Construction and Urban
Development
Barilcgachdiin talbai, Chingeltei District
Ulaanbaatar , Mongolia
Packaging shall be in the form that shall ensure the maximum
safety of all the items.
GCC 21.1 The insurance coverage shall be as specified in the Incoterms.
GCC 22.1 Responsibility for transportation of the Goods shall be as

specified in the Incoterms.
GCC 23.2 The inspections and tests shall be:

Factory Inspections:
The Bidder MUST prove that all delivered items passed the
factory inspections by providing their certificates of quality
assurance.
Inspections following delivery
Since the custom duties are the Bidder’s responsibility each
delivery will be checked against its packing list. After Site(s)
delivery there will be another delivery integrity checking
performed by the Bidder.
Operational Acceptance Tests
96
Pursuant to GCC Clause 27 and related SCC clauses, the Bidder

(with the assistance of the Supplier) will perform the following
tests on the System and its Subsystems following Installation to
determine whether the System and the Subsystems meet all the
requirements mandated for Operational Acceptance.
For hardware, system software and communications:
In addition to the Supplier’s delivery tests, the Bidder shall
manage the test (supported by the Supplier) and perform
installation tests on each delivered system.
The respective installation test scripts and test schedule MUST be
proposed by the Supplier and approved by the Bidder 15 days
before starting.
The Entire System: after successful installation of each system,
the Bidder MUST perform a complete system installation test,
with the assistance of the Supplier. The Bidder (with the
assistance of the Supplier) MUST perform a Final Installation
Test after all delivered systems, including the Central Processing
Units, will be in place. It must be included in the Project Plan
Note: The complexity of the Operational Acceptance Testing

needed will vary in accordance with the complexity of the System
being procured. For Systems to be procured using the single-
stage bidding process, Operational Acceptance Testing may
simply consist of requiring a specified period of trouble-free
System or Subsystem operation under normal operating
conditions. For more complex Systems, Operational Acceptance
testing will require extensive, clearly defined tests under either
production or mock-production conditions.
Supplier is required to install, commission and calibrate the IT
equipment at nominated Final Destinations.
During this process ongoing visual and electronic tests will be

required to ensure the Supplier and the equipment complies with
MCA-M requirements.
In addition Bidders should ensure they are fimilar with SR5 -

Schedule of Requirements Inspections & Testing
GCC 24.1 The liquidated damage shall be 0.05% per week of the Contract
Price.
The maximum amount of liquidated damages shall be 10% of the
Contract Price.
97
GCC 25.3 After delivery and acceptance of the Goods, the performance
security shall be reduced to 5 percent of the Contract Price to
cover the Supplier’s warranty obligations in accordance with
Clause GCC 25.3.
GCC 25.5 The Supplier shall repair or replace the defective Goods or parts
thereof within 30 days
98
V. Appendix A
Additional Provisions
Capitalized terms that are used but not defined in this Appendix shall have the meaning
given to them in the GCC or in the Compact or related agreements.
The Purchaser is responsible for the oversight and management of the implementation of
the Compact on behalf of the Government, and intends to apply a portion of the
proceeds of the Compact to eligible payments under this Contract, provided that (a) such
payments will only be made at the request of and on behalf of the Purchaser and as
authorized by the Fiscal Agent, (b) MCC shall have no obligations to the Supplier under
the Compact or this Contract, (c) such payments will be subject, in all respects, to the
terms and conditions of the Compact, and (d) no party other than the Government and
the Purchaser shall derive any rights from the Compact or have any claim to MCC
Funding.
A. MCC Status; Reserved Rights; Third-Party Beneficiary

1. MCC Status. MCC is a United States Government corporation acting on
behalf of the United States Government in the implementation of the
Compact. As such, MCC has no liability under this Contract, and is immune
from any action or proceeding arising under or relating to this Contract. In
matters arising under or relating to this Contract, MCC is not subject to the
jurisdiction of the courts or any other juridical or other body of any
jurisdiction.
2. MCC Reserved Rights.
(a) Certain rights are expressly reserved to MCC under this Contract, the
Compact and other related Compact documents, including the right to
approve the terms and conditions of this Contract, as well as any
amendments or modifications hereto, and the right to suspend or
terminate this Contract.
(b) MCC, in reserving such rights under this Contract, the Compact or
other related Compact documents, has acted solely as a funding entity
to assure the proper use of United States Government funds, and any
decision by MCC to exercise or refrain from exercising these rights
shall be made as a funding entity in the course of funding the activity
and shall not be construed as making MCC a party to this Contract.
(c) MCC may, from time to time, exercise its rights, or discuss matters
related to this Contract with the Parties or the Government, as
appropriate, jointly or separately, without thereby incurring any
responsibility or liability to any party.
(d) Any approval (or failure to approve) or exercise of (or failure to
exercise) any rights by MCC shall not bar the Government,the
Purchaser, MCC or any other person or entity from asserting any
99
right against the Supplier, or relieve the Supplier of any liability

which the Supplier might otherwise have to the Government, the
Purchaser, MCC, or any other person or entity. For the purposes of
this clause (d), MCC shall be deemed to include any MCC officer,
director, employee, affiliate, contractor, agent or representative.
3. Third-Party Beneficiary. MCC shall be deemed to be a third party beneficiary
under this Contract.
B. Limitations on the Use or Treatment of MCC Funding
The use and treatment of MCC Funding in connection with this Contract does
not, and shall not, violate any limitations or requirements specified in the
Compact or any other relevant agreement or Implementation Letter or applicable
law or United States Government policy. A summary of the applicable
provisions referenced in this paragraph may be found on the MCC website at
[www.mcc.gov/guidance/compact/funding_limitations.pdf]1.
C. Procurement
The Supplier shall ensure that all procurements of goods, services or works
under, related to or in furtherance of this Contract shall be consistent with the
general principles set forth in the Compact and in the MCC Program
Procurement Guidelines from time to time in effect as posted on the MCC
website at www.mcc.gov. The Supplier shall comply with the eligibility
requirements related to prohibited source or restricted party provisions in
accordance with U.S. law, regulations and policy, applicable World Bank
policies or guidelines and in accordance with other eligibility requirements as
may be specified by MCC or the Purchaser. A summary of the applicable
provisions referenced in this paragraph may be found on the MCC website at
[www.mcc.gov/guidance/compact/procurement_awards_provisions.pdf2].
D. Reports and Information; Access; Audits; Reviews
1. Reports and Information. The Supplier shall maintain such books and records
and provide such reports, documents, data or other information to the
Purchaser in the manner and to the extent required by the Compact or related
documents and as may be reasonably requested by the Purchaser from time
to time in order to comply with its reporting requirements arising under the
Compact or related documents. MCC may freely use any information it
receives in any report or document provided to it in any way that MCC sees
fit. The provisions of the Compact and www.mca.mn that are applicable to
the Government in this regard shall apply, mutatis mutandis, to the Supplier
as if the Supplier were the Government under the Compact. A summary of
the applicable provisions referenced in this paragraph may be found on the
MCC website at
[www.mcc.gov/guidance/compact/audits_reviews_provisions.pdf3].
1
Verify this link prior to publication.
2
3
100
2. Access; Audits and Reviews. Upon MCC’s request, the Supplier shall permit
such access, audits, reviews and evaluations as provided in the Compact or
related documents. The provisions of the Compact and www.mca.mn that
are applicable to the Government with respect to access and audits shall
apply, mutatis mutandis, to the Supplier as if the Supplier were the
Government under the Compact. A summary of the applicable provisions
referenced in this paragraph may be found on the MCC website at
[www.mcc.gov/guidance/compact/audits_reviews_provisions.pdf4].
3. Application to Providers. The Supplier shall ensure the inclusion of the
applicable audit, access and reporting requirements in its contracts or
agreements with other providers in connection with this Contract. A
summary of the applicable requirements may be found on the MCC website
at [www.mcc.gov/guidance/compact/audits_reviews_provisions.pdf5].
E. Compliance with Anti-Corruption, Anti-Money Laundering and Terrorist
Financing Statutes and Other Restrictions
1. The Supplier shall ensure that no payments have been or will be made by the
Supplier to any official of the Government, the Purchaser, or any third party
(including any other government official) in connection with this Contract in
violation of the United States Foreign Corrupt Practices Act of 1977, as
amended (15 U.S.C. 78a et seq.) (the “FCPA”) or that would otherwise be in
violation of the FCPA if the party making such payment were deemed to be a
United States person or entity subject to the FCPA, or similar statute
applicable to this Contract, including any local laws. The Supplier affirms
that no payments have been or will be received by any official, employee,
agent or representative of the Supplier in connection with this Contract in
violation of the FCPA or that would otherwise be in violation of the FCPA if
the party making such payment were deemed to be a United States person or
entity subject to the FCPA, or similar statute applicable to this Contract,
including any local laws.
2. The Supplier shall not provide material support or resources directly or
indirectly to, or knowingly permit MCC Funding to be transferred to, any
individual, corporation or other entity that the Supplier knows, or has reason
to know, commits, attempts to commit, advocates, facilitates, or participates
in any terrorist activity, or has committed, attempted to commit, advocated,
facilitated or participated in any terrorist activity, including, but not limited
to, the individuals and entities (i) on the master list of Specially Designated
Nationals and Blocked Persons maintained by the U.S. Department of
Treasury’s Office of Foreign Assets Control, which list is available at
www.treas.gov/offices/enforcement/ofac, (ii) on the consolidated list of
individuals and entities maintained by the “1267 Committee” of the United
Nations Security Council, (iii) on the list maintained on www.epls.gov or
(iv) on such other list as the Purchaser may request from time to time. For
4
5
101
purposes of this provision, “material support and resources” includes

currency, monetary instruments or other financial securities, financial
services, lodging, training, expert advice or assistance, safe houses, false
documentation or identification, communications equipment, facilities,
weapons, lethal substances, explosives, personnel, transportation, and other
physical assets, except medicine or religious materials.
3. The Supplier shall ensure that its activities under this Contract comply with
all applicable U.S. laws, regulations and executive orders regarding money
laundering, terrorist financing, U.S. sanctions laws, restrictive trade
practices, boycotts, and all other economic sanctions promulgated from time
to time by means of statute, executive order, regulation or as administered by
the Office of Foreign Assets Control of the United States Treasury
Department or any successor governmental authority, including, 18 U.S.C. §
1956, 18 U.S.C. § 1957, 18 U.S.C. § 2339A, 18 U.S.C. § 2339B, 18 U.S.C. §
2339C, 18 U.S.C. § 981, 18 U.S.C. § 982, Executive Order 13224, 15 C.F.R.
Part 760, and those economic sanctions programs enumerated at 31 C.F.R.
Parts 500 through 598 and shall ensure that its activities under this Contract
comply with any policies and procedures for monitoring operations to ensure
compliance, as may be established from time to time by MCC, the Purchaser,
the Fiscal Agent, or the Bank, as may be applicable. The Supplier shall
verify, or cause to be verified, appropriately any individual, corporation or
other entity with access to or recipient of funds, which verification shall be
conducted in accordance with the procedures set out in the MCC Program
Procurement Guidance paper entitled“Excluded Parties Verification
Procedures in Purchaser Program Procurements” that can be found on
MCC’s website at www.mcc.gov. The Supplier shall (A) conduct the
monitoring referred to in this paragraph on at least a quarterly basis, or such
other reasonable period as the Purchaser or MCC may request from time to
time and (B) deliver a report of such periodic monitoring to the Purchaser
with a copy to MCC.
4. Other restrictions on the Supplier shall apply as set forth in the Compact or
related documents with respect to any activities in violation of other
applicable U.S. laws, regulations, executive orders or policies, any
misconduct injurious to MCC or the Purchaser, any activity contrary to the
national security interests of the United States or any other activity that
materially and adversely affects the ability of the Government or any other
party to effectively implement, or ensure the effective implementation of, the
Program or any Project or to otherwise carry out its responsibilities or
obligations under or in furtherance of the Compact or any related document
or that materially and adversely affects the Program assets or any Permitted
Account.
F. Publicity, Information and Marking
1. The Supplier shall cooperate with the Purchaser and the Government to
provide the appropriate publicity to the goods, works and services provided
under this Contract, including identifying Program activity sites and marking
102
Program assets as goods, works and services funded by the United States,
acting through MCC, all in accordance with the MCC Standards for
Corporate Marking and Branding, available on the MCC website at
[http://www.mcc.gov/documents/mcc-marking-corporate-v2.pdf];
provided, however, that any press release or announcement regarding MCC
or the fact that MCC is funding the Program or any other publicity materials
referencing MCC, shall be subject to MCC’s prior written approval and must
be consistent with any instructions provided by MCC from time to time in
relevant Implementation Letters.
2. Upon the termination or expiration of the Compact, the Supplier shall, upon
MCC’s request, cause the removal of any such markings and any references
to MCC in any publicity materials.
G. Insurance
The Supplier shall obtain insurance, performance bonds, guarantees or other
protections appropriate to cover against risks or liabilities associated with
performance of this Contract. The Supplier shall be named as payee on any such
insurance and the beneficiary of any such performance bonds and guarantees.
The Purchaser and, at MCC’s request MCC, shall be named as additional
insureds on any such insurance or other guarantee, to the extent permissible
under applicable laws. The Supplier shall ensure that any proceeds from claims
paid under such insurance or any other form of guarantee shall be used to replace
or repair any loss or to pursue the procurement of the covered goods, works and
services; provided, however, that at MCC’s election, such proceeds shall be
deposited in an account as designated by the Purchaser and acceptable to MCC
or as otherwise directed by MCC.
H. Conflict of Interest
The Supplier shall ensure that no officer, director, employee, affiliate, contractor,
subcontractor, agent, advisor or representative of the Supplier participates in the
selection, award, administration or oversight of a contract, grant or other benefit
or transaction funded in whole or in part (directly or indirectly) by MCC
Funding in connection with this Contract, in which (i) the entity, the person,
members of the person’s immediate family or household or his or her business
partners, or organizations controlled by or substantially involving such person or
entity, has or have a financial or other interest or (ii) the person or entity is
negotiating or has any arrangement concerning prospective employment, unless
such person or entity has first disclosed in writing to the parties under this
Contract and MCC the conflict of interest and, following such disclosure, the
parties to this Contract agree in writing to proceed notwithstanding such conflict.
The Supplier shall ensure that none of its officers, directors, employees,
affiliates, contractors, subcontractors, agents, advisors or representatives
involved in the selection, award, administration, oversight or implementation of
any contract, grant or other benefit or transaction funded in whole or in part
(directly or indirectly) by MCC Funding in connection with this Contract shall
solicit or accept from or offer to a third party or seek or be promised (directly or
indirectly) for itself or for another person or entity any gift, gratuity, favor or
103
benefit, other than items of de minimis value and otherwise consistent with such
guidance as MCC may provide from time to time. The Supplier shall ensure that
none of its officers, directors, employees, affiliates, contractors, subcontractors,
agents, advisors or representatives engage in any activity which is, or gives the
appearance of being, a conflict of interest in connection with this Contract.
Without limiting the foregoing, the Supplier shall comply, and ensure
compliance, with the applicable conflicts of interest and ethics policies of the
Purchaser as provided by the Purchaser to the Supplier
I. Inconsistencies
In the event of any conflict between this Contract and the Compact and/or the
[Disbursement Agreement or the Procurement Agreement/Program
Implementation Agreement], the term(s) of the Compact and/or the
[Disbursement Agreement or the Procurement Agreement/Program
Implementation Agreement] shall prevail.
J. Other Provisions
The Supplier shall abide by such other terms or conditions as may be specified
by the Purchaser or MCC in connection with this Contract.
K. Flow-Through Provisions
In any subcontract or sub-award entered into by the Supplier, as permitted by
this Contract, the Supplier shall ensure the inclusion of all the provisions
contained in paragraphs (A) through (J) above.
104
VI. Bank Guarantee for Performance Security
[The bank, as requested by the Supplier, shall fill in the form in accordance
with the instructions indicated]
Bank’s Branch or Office:[insert complete name of Guarantor]
Beneficiary:[insert complete name of the Purchaser],
PERFORMANCE GUARANTEE No.:[insert Performance Guarantee number]
We have been informed that [insert complete name of Supplier] (hereinafter called the
“Supplier”) has entered into Contract No. [insert number] dated [insert day and month], [insert
year] with you, for the supply of [description of Goods and Related Services] (hereinafter
called the “Contract”).
Furthermore, we understand that, according to the conditions of the Contract, a Performance

Guarantee is required.
At the request of the Supplier, we hereby irrevocably undertake to pay you any sum(s) not
exceeding [insert amount(s) in words and figures]upon receipt by us of your first demand in
writing declaring the Supplier to be in default under the Contract, without cavil or argument, or
your needing to prove or to show grounds or reasons for your demand or the sum specified
therein.
This Guarantee shall expire no later than the [insert number] day of [insert month][insert
year][note- expiration date to be calculated based on the provisions of GCC Sub-Clause 15.4],
and any demand for payment under it must be received by us at this office on or before that date.
For the Bank For the Supplier
Signature Signature
In the capacity of: In the capacity of:
Date: Date:
105
Schedule of Requirements CA/MCA-M/MCC/PRP/GDS/099/2011
SR1/1(a) LIST OF GOODS, SERVICES AND DELIVERY SCHEDULE
NECESSARY TO ACCOMPLISH THE DIGITIZATION PROCESS …. 101
SR2/1(a) LIST OF RELATED SERVICES FOR THE DELIVERY OF THE

DIGITIZATION and DATA CONVERSATION EQUIPMENT..............112
SR1/I(b) LIST OF GOODS, SERVICES AND DELIVERY SCHEDULE

NECESSARY TO ROLL-OUT THE ELECTRONIC
PROPERTY REGISTRATION SYSTEM (ePRS).................................113
SR2/I(b) LIST OF SERVICES AND COMPLETION SCHEDULE RELATED

TO DIGITIZATION OF PAPER ARCHIVE AND CONVERSION OF
EXISTING DIGITAL DATA ........................................................................142
SR1/II LIST OF SERVICES AND COMPLETION SCHEDULE RELATED TO

THE DEVELOPMENT AND IMPLEMENTATION OF THE ELECTRONIC
PROPERTY REGISTRATION SYSTEM /ePRS/ ...........................................143
SRI/III LIST OF SERVICES AND COMPLETION SCHEDULE RELATED TO

THE DEVELOPMENT AND IMPLEMENTATION OF THE
ELECTRONIC PROPERTY REGISTRATION SYSTEM /ePRS/.................. 145
SR4 TECHNICAL/SERVICESPECIFICATIONS………………………….. 147
SR5 DRAWINGS ……………………………………………………… 376
SR6 INSPECTIONS AND TESTS ………………………………………… 377
SR7 ENVIRONMENTAL, HEALTH AND SERVICES PROCEDURES ….. 378
106
LIST OF GOODS AND RELATED SERVICES
List of goods, related services and delivery schedule are divided in three main pillars,
as these technical specifications are described:
- SR1/I – divided in two phases (A and B). Each list contains goods (equipment)
for different purpose:
o SR1/I A contains the list of goods necessary to accomplish the digitization
process;
o SR1/I B provides the list of goods necessary to ensure the roll-out of ePRS
system;
- SR1/II – provides the list of necessary services that need to be performed to
digitize and convert existent paper and digital data in current registration system;
- SR1/III – contains the list of ePRS development related services
ABBREVIATIONS & ACRONYMS

ALACGaC Administration of Land Affairs, Construction, Geodesy and
Cartography
BPM Business Process Management
CORS Continuously Operating Reference Station
ePRS electronic Property Registration System
GASR General Authority for State Registration
GALPA Ger Area Land Plot Activity
ESOC Environmental & Social Oversight Consultant
GNSS Global Navigation Satellite System
GPS Global Positioning System
ITIL Information System Infrastructure Library
MCA-M Millennium Challenge Account, Mongolia
MRTCUD Ministry of Roads, transporatation, Construction & Urban Development
NLIS National Land Information System
PIU Project Implementation Unit
PRP Property Rights Project
SOA Service Oriented Architecture
107
Pillar 1
SR1 List of Goods and Delivery Schedule
SR1/I(a) -List of Goods, Services and Delivery Schedule necessary to accomplish the digitization process
Purchaser’s Required Delivery Date (as per Bidder’s offered Delivery

Line Item
Incoterms) date
Physical Final Destination as
Description of Goods Quantity
N unit specified in BDS
Earliest Delivery
Latest Delivery Date
Date

For supply and delivery 1 workstations for Within 30 days of
quality control and scanning (described in the date of
1 1 piece Baganuur, Mongolia N/A
detail in TechSpecs Part I. Phase I - ch effectiveness this
5.1.1) contract
Within 30 days of
For supply and delivery 1 workstation for
the date of
2 digitization (described in TechSpecs Part I. 1 piece Baganuur, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
For supply and delivery 2 Uninterruptible
the date of
3 Power Supply (UPS) (described in 2 pieces Baganuur, Mongolia N/A
effectiveness this
TechSpecs Part I. Phase I - ch 5.1.3)
contract
Within 30 days of
For supply and delivery 2 External Hard
the date of
4 Drive Storage (described in TechSpecs Part 2 pieces Baganuur, Mongolia N/A
effectiveness this
I. Phase I - ch 5.1.4)
contract
Within 30 days of
For supply and delivery 1 High-Speed
the date of
5 Scanner (described in TechSpecs Part I. 1 piece Baganuur, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
108

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
For supply and delivery 1 Switch 8 ports
the date of
6 (described in Tech Specs Part I. Phase I - 1 piece Baganuur, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
For supply and delivery 1 Database
the date of
7 Software License (described in TechSpecs 1 piece Baganuur, Mongolia N/A
effectiveness this
Part I. Phase I - ch 5.2.4)
contract
Within 30 days of
For supply and delivery 5 workstations for
the date of
8 quality control and scanning (described in 5 pieces Ulaanbaatar,Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
9 digitization (described in TechSpecs Part I. 14 pieces Ulaanbaatar, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
10 Power Supply (UPS) (described in 19 pieces Ulaanbaatar, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
11 Drive Storage (described in TechSpecs Part 2 pieces Ulaanbaatar, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
12 Scanner (described in TechSpecs Part I. 7 pieces Ulaanbaatar, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
109

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
the date of
13 (described in Tech Specs Part I. Phase I - 1 piece Ulaanbaatar, Mongolia N/A
effectiveness this
ch 5.3.1.1. ii))
contract
Within 30 days of
the date of
14 Software License (described in TechSpecs 1 piece Ulaanbaatar, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
15 quality control and scanning (described in 2 pieces Darkhan-Uul,Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
16 digitization (described in TechSpecs Part I. 2 pieces Darkhan-Uul,Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
17 Power Supply (UPS) (described in 4 pieces Darkhan-Uul,Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
18 Drive Storage (described in TechSpecs Part 2 pieces Darkhan-Uul,Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
19 Scanner (described in TechSpecs Part I. 1 piece Darkhan-Uul,Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
110

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
the date of
20 (described in Tech Specs Part I. Phase I - 1 piece Darkhan-Uul, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
the date of
21 Software License (described in TechSpecs 1 piece Darkhan-Uul, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
22 quality control and scanning (described in 1 piece Dornod, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
23 digitization (described in TechSpecs Part I. 2 pieces Dornod, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
24 Power Supply (UPS) (described in 3 pieces Dornod, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
25 Drive Storage (described in TechSpecs Part 2 pieces Dornod, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
26 Scanner (described in TechSpecs Part I. 1 piece Dornod, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
111

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
the date of
27 (described in Tech Specs Part I. Phase I - 1 piece Dornod, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
the date of
28 Software License (described in TechSpecs 1 piece Dornod, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
29 quality control and scanning (described in 1 piece Zavhan, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
30 digitization (described in TechSpecs Part I. 1 piece Zavhan, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
31 Power Supply (UPS) (described in 2 pieces Zavhan, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
32 Drive Storage (described in TechSpecs Part 2 pieces Zavhan, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
33 Scanner (described in TechSpecs Part I. 1 piece Zavhan, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
112

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
the date of
34 (described in Tech Specs Part I. Phase I - 1 piece Zavhan, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
the date of
35 Software License (described in TechSpecs 1 piece Zavhan, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
36 quality control and scanning (described in 1 piece Orkhon, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
37 digitization (described in TechSpecs Part I. 2 pieces Orkhon, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
38 Power Supply (UPS) (described in 3 pieces Orkhon, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
39 Drive Storage (described in TechSpecs Part 2 pieces Orkhon, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
40 Scanner (described in TechSpecs Part I. 1 piece Orkhon, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
113

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
the date of
41 (described in Tech Specs Part I. Phase I - 1 piece Orkhon, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
the date of
42 Software License (described in TechSpecs 1 piece Orkhon, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
43 quality control and scanning (described in 1 piece Ovorhangai, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
44 digitization (described in TechSpecs Part I. 2 pieces Ovorhangai, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
45 Power Supply (UPS) (described in 3 pieces Ovorhangai, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
46 Drive Storage (described in TechSpecs Part 2 pieces Ovorhangai, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
47 Scanner (described in TechSpecs Part I. 1 piece Ovorhangai, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
114

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
the date of
48 (described in Tech Specs Part I. Phase I - 1 piece Ovorhangai, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
the date of
49 Software License (described in TechSpecs 1 piece Ovorhangai, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
50 quality control and scanning (described in 1 piece Hovd, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
51 digitization (described in TechSpecs Part I. 1 piece Hovd, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
52 Power Supply (UPS) (described in 2 pieces Hovd, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
53 Drive Storage (described in TechSpecs Part 2 pieces Hovd, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
54 Scanner (described in TechSpecs Part I. 1 piece Hovd, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
115

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
the date of
55 (described in Tech Specs Part I. Phase I - 1 piece Hovd, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
the date of
56 Software License (described in TechSpecs 1 piece Hovd, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
57 quality control and scanning (described in 1 piece Hentii, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
58 digitization (described in TechSpecs Part I. 1 piece Hentii, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
59 Power Supply (UPS) (described in 2 pieces Hentii, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
60 Drive Storage (described in TechSpecs Part 2 pieces Hentii, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
61 Scanner (described in TechSpecs Part I. 1 piece Hentii, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
116

Line Item
Incoterms) date
Earliest Delivery
Date

Within 30 days of
the date of
62 (described in Tech Specs Part I. Phase I - 1 piece Hentii, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
the date of
63 Software License (described in TechSpecs 1 piece Hentii, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
64 quality control and scanning (described in 1 piece Tov, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
65 digitization (described in TechSpecs Part I. 1 piece Tov, Mongolia N/A
effectiveness this
Phase I - ch 5.1.2)
contract
Within 30 days of
the date of
66 Power Supply (UPS) (described in 2 pieces Tov, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
67 Drive Storage (described in TechSpecs Part 2 pieces Tov, Mongolia N/A
effectiveness this
contract
Within 30 days of
the date of
68 Scanner (described in TechSpecs Part I. 1 piece Tov, Mongolia N/A
effectiveness this
Phase I - ch 5.2.2)
contract
117

Line Item
Incoterms) date
Earliest Delivery
Date

Within30 days of
the date of
69 (described in Tech Specs Part I. Phase I - 1 piece Tov, Mongolia N/A
effectiveness this
ch 5.3.1.1. i))
contract
Within 30 days of
the date of
70 Software License (described in TechSpecs 1 piece Tov, Mongolia N/A
effectiveness this
contract
118
SR2/I(a) -List of related Services for the delivery of the digitalization and data conversation equipments
Place where Services Final Completion Date(s) of

Service Description Quantity Physical Unit
shall be performed Services
Within 30 days of the date of

1 Detailed Project Plan 1 document Ulaanbaatar, Mongolia
effectiveness this contract
2 Supply and Delivery All Equipment All sites
3 Installation and Configuration All Equipment All Sites
4 Testing and commissioning All Equipment All Sites
People involved in Within 45 days of the date of
5 Training All All Sites
digitization effectiveness this contract
After 24 months of the date of

6 Maintenance 24 Months Ulaanbaatar, Mongolia
acceptance of implementation
7 Warranty 24 months Ulaanbaatar, Mongolia
8 User support/hot line 24 months Ulaanbaatar, Mongolia
9 Technical Assistance 24 months Ulaanbaatar, Mongolia
119
Pillar 1(b)
SR1/I(b)- List of Goods, Services and Delivery Schedule necessary to roll-out the ePRS System

Line Item
Incoterms) date
Earliest Delivery Latest Delivery
Date Date

After 60 days of Within 90 days of
For supply and delivery 1 Server Ulaanbaatar,
the date of the date of
1 chassis for blade servers (described in 1 piece Mongolia (Data
effectiveness this effectiveness this
TechSpecs Part I. Phase II - ch 6.1.1) center)
contract contract

For supply and delivery 1 Server Ulaanbaatar,
2 chassis for blade servers (described in 1 piece Mongolia (Disaster
TechSpecs Part I. Phase II - ch 6.1.1) recovery location)
contract contract

For supply and delivery 5 Blade Ulaanbaatar,
3 servers (described in TechSpecs Part 5 pieces Mongolia (Data
I. Phase II - ch 6.1.2) center)
contract contract

For supply and delivery 3 Blade Ulaanbaatar,
4 servers (described in TechSpecs Part 3 pieces Mongolia (Disaster
I. Phase II - ch 6.1.2) recovery location)
contract contract

For supply and delivery 1 SAN Ulaanbaatar,
5 (Storage Area Network) (described in 1 piece Mongolia (Data
TechSpec Part I. Phase II - ch 6.1.3) center)
contract contract
120

Line Item
Incoterms) date
Date Date

For supply and delivery 1 SAN Ulaanbaatar,
6 (Storage Area Network) (described in 1 piece Mongolia (Disaster
TechSpec Part I. Phase II - ch 6.1.3) recovery location)
contract contract

For supply and delivery 1 Rack and Ulaanbaatar,
7 related accessories (described in 1 piece Mongolia (Data
contract contract

For supply and delivery 1 Rack and Ulaanbaatar,
8 related accessories (described in 1 piece Mongolia (Disaster
contract contract

For supply and delivery 1 Backup Ulaanbaatar,
9 solution (tape library) (described in 1 piece Mongolia (Data
TechSpec Part I. Phase II - ch 6.1.5 i)) center)
contract contract

For supply and delivery 1 Backup Ulaanbaatar,
10 solution (tape library) (described in 1 piece Mongolia (Disaster
TechSpec Part I. Phase II - ch 6.1.5 i)) recovery location)
contract contract

For supply and delivery 50 Tapes for Ulaanbaatar,
11 Backup library (described in TechSpec 50 pieces Mongolia (Data
Part I. Phase II - ch 6.1.5. ii)) center)
contract contract

For supply and delivery 50 Tapes for Ulaanbaatar,
12 Backup library (described in TechSpec 50 pieces Mongolia (Disaster
Part I. Phase II - ch 6.1.5. ii)) recovery location)
contract contract
121

Line Item
Incoterms) date
Date Date

For supply and delivery 1 Monitoring After 60 days of Within 90 days of
Ulaanbaatar,
system for Data center physical area the date of the date of
13 1 piece Mongolia (Data
(described in TechSpec Part I. Phase effectiveness this effectiveness this
center)
II - ch 6.1.6) contract contract

For supply and delivery 1 Building Ulaanbaatar,
14 centralized UPS device (described in 1 piece Mongolia (Data
contract contract

For supply and delivery 1 Building Ulaanbaatar,
15 centralized UPS device (described in 1 piece Mongolia (Disaster
contract contract
State Registrar Workstations
For supply and delivery 129 State After 60 days of Within 120 days of
Registrar Workstation inc. Training Ulaanbaatar, the date of the date of
16 129 pieces
center workstations (described in Mongolia effectiveness this effectiveness this
TechSpec Part I. Phase II - ch 6.1.7) contract contract

For supply and delivery 1 State
17 Registrar Workstation (described in 1 piece Baganuur, Mongolia
TechSpec Part I. Phase II - ch 6.1.7)
contract contract

Darkhan-Uul, the date of the date of
18 Registrar Workstation (described in 5 pieces
Mongolia effectiveness this effectiveness this
contract contract
122

Line Item
Incoterms) date
Date Date

19 Registrar Workstation (described in 2 pieces Dornod, Mongolia
contract contract

20 Registrar Workstation (described in 3 pieces Zavhan, Mongolia
contract contract

21 Registrar Workstation (described in 3 pieces Orkhon, Mongolia
contract contract

Ovorhangai, the date of the date of
22 Registrar Workstation (described in 3 pieces
contract contract

23 Registrar Workstation (described in 7 pieces Hovd, Mongolia
contract contract

24 Registrar Workstation (described in 3 pieces Hentii, Mongolia
contract contract
For supply and delivery 4 State After 60 days of Within 120 days of
Registrar Workstation (described in the date of the date of
25 4 pieces Tov, Mongolia
TechSpec Part I. Phase II - ch 6.1.7) effectiveness this effectiveness this
contract contract
123

Line Item
Incoterms) date
Date Date

Accountant Workstations
For supply and delivery 5 Accountant
Ulaanbaatar, the date of the date of
26 Workstation (described in TechSpec 5 pieces
Part I. Phase II - ch 6.2)
contract contract

27 Workstation (described in TechSpec 1 piece Baganuur, Mongolia
contract contract

Darkhan- the date of the date of
28 Workstation (described in TechSpec 1 piece
Uul,Mongolia effectiveness this effectiveness this
contract contract

29 Workstation (described in TechSpec 1 piece Dornod, Mongolia
contract contract

30 Workstation (described in TechSpec 1 piece Zavhan, Mongolia
contract contract

31 Workstation (described in TechSpec 1 piece Orkhon, Mongolia
contract contract
124

Line Item
Incoterms) date
Date Date

32 Workstation (described in TechSpec 1 piece
contract contract

33 Workstation (described in TechSpec 1 piece Hovd, Mongolia
contract contract

34 Workstation (described in TechSpec 1 piece Hentii, Mongolia
contract contract

35 Workstation (described in TechSpec 1 piece Tov, Mongolia
contract contract
Laptops
For supply and delivery 16 Laptops
36 (described in TechSpec Part I. Phase 15 pieces
II - ch 6.2.1)
contract contract

37 (described in TechSpec Part I. Phase 1 piece Baganuur, Mongolia
II - ch 6.2.1)
contract contract
125

Line Item
Incoterms) date
Date Date

Bayanzurkh, the date of the date of
38 (described in TechSpec Part I. Phase 1 piece
II - ch 6.2.1)
contract contract

Chingeltei, Mongolia the date of the date of
II - ch 6.2.1)
contract contract

Songino Khairkhan, the date of the date of
II - ch 6.2.1)
contract contract

II - ch 6.2.1)
contract contract

42 (described in TechSpec Part I. Phase 1 piece Dornod, Mongolia
II - ch 6.2.1)
contract contract

43 (described in TechSpec Part I. Phase 1 piece Zavhan, Mongolia
II - ch 6.2.1)
contract contract

44 (described in TechSpec Part I. Phase 1 piece Orkhon, Mongolia
II - ch 6.2.1)
contract contract
126

Line Item
Incoterms) date
Date Date

II - ch 6.2.1)
contract contract

46 (described in TechSpec Part I. Phase 1 piece Hovd, Mongolia
II - ch 6.2.1)
contract contract

47 (described in TechSpec Part I. Phase 1 piece Hentii, Mongolia
II - ch 6.2.1)
contract contract

48 (described in TechSpec Part I. Phase 1 piece Tov, Mongolia
II - ch 6.2.1)
contract contract
Individual UPS
For supply and delivery 40 After 60 days of Within 120 days of
Uninterruptible Power Supply Ulaanbaatar, the date of the date of
49 40 pieces
(described in TechSpec Part I. Phase Mongolia effectiveness this effectiveness this

Uninterruptible Power Supply the date of the date of
50 2 pieces Baganuur, Mongolia
127

Line Item
Incoterms) date
Date Date

Uninterruptible Power Supply Darkhan-Uul, the date of the date of
51 6 pieces

52 3 pieces Dornod, Mongolia

53 4 pieces Zavhan, Mongolia

54 4 pieces Orkhon, Mongolia

Uninterruptible Power Supply Ovorhangai, the date of the date of
55 4 pieces

56 8 pieces Hovd, Mongolia

57 4 pieces Hentii, Mongolia
128

Line Item
Incoterms) date
Date Date

58 5 pieces Tov, Mongolia
Shared Output and Input devices
Multifunctional A3 b/w printer Ulaanbaatar, the date of the date of
59 9 pieces
II - ch 6.3.1.1 i)) contract contract

Multifunctional A3 b/w printer the date of the date of
60 1 piece Baganuur, Mongolia

Multifunctional A3 b/w printer Darkhan-Uul, the date of the date of
61 1 piece

62 1 piece Dornod, Mongolia

63 1 piece Zavhan, Mongolia
129

Line Item
Incoterms) date
Date Date

64 1 piece Orkhon, Mongolia

Multifunctional A3 b/w printer Ovorhangai, the date of the date of
65 1 piece

66 1 piece Hovd, Mongolia

67 1 piece Hentii, Mongolia

68 1 piece Tov, Mongolia

For supply and delivery 30 Office
69 printer (described in TechSpec Part I. 30 pieces
Phase II - ch 6.3.1.1 ii))
contract contract

For supply and delivery 1 Office printer
70 (described in TechSpec Part I. Phase 1 Piece Baganuur, Mongolia
II - ch 6.3.1.1 ii))
contract contract
130

Line Item
Incoterms) date
Date Date

71 (described in TechSpec Part I. Phase 3 Pieces
II - ch 6.3.1.1 ii))
contract contract

72 (described in TechSpec Part I. Phase 1 Piece Dornod, Mongolia
II - ch 6.3.1.1 ii))
contract contract

73 (described in TechSpec Part I. Phase 2 Pieces Zavhan, Mongolia
II - ch 6.3.1.1 ii))
contract contract

74 (described in TechSpec Part I. Phase 2 Pieces Orkhon, Mongolia
II - ch 6.3.1.1 ii))
contract contract

75 (described in TechSpec Part I. Phase 2 Pieces
II - ch 6.3.1.1 ii))
contract contract

76 (described in TechSpec Part I. Phase 4 Pieces Hovd, Mongolia
II - ch 6.3.1.1 ii))
contract contract

77 (described in TechSpec Part I. Phase 2 pieces Hentii, Mongolia
II - ch 6.3.1.1 ii))
contract contract
131

Line Item
Incoterms) date
Date Date

II - ch 6.3.1.1 ii))
contract contract

79 Scanner (described in TechSpec Part 3 pieces
I. Phase II - ch 6.3.1.2)
contract contract

For supply and delivery 6 Switch 48
80 ports (described in TechSpec Part I. 6 pieces
Phase II - ch 6.4.1.1 i))
contract contract

81 ports (described in TechSpec Part I. 3 piece
contract contract

82 ports (described in TechSpec Part I. 1 piece Baganuur, Mongolia
contract contract
contract contract
84 ports (described in TechSpec Part I. 1 piece Dornod, Mongolia
contract contract
132

Line Item
Incoterms) date
Date Date

85 ports (described in TechSpec Part I. 1 piece Zavhan, Mongolia
contract contract

86 ports (described in TechSpec Part I. 1 piece Orkhon, Mongolia
contract contract

contract contract

88 ports (described in TechSpec Part I. 1 piece Hovd, Mongolia
contract contract

89 ports (described in TechSpec Part I. 1 piece Hentii, Mongolia
contract contract

90 ports (described in TechSpec Part I. 1 piece Tov, Mongolia
contract contract

For supply and delivery 50Smart Card
91 Readers eID (described in TechSpec 50 pieces
Part I. Phase II - ch 6.3.1.2)
contract contract
133

Line Item
Incoterms) date
Date Date

Network and communications equipment
Manufactory molded patch cords (1ft) Ulaanbaatar, the date of the date of
92 500 pieces
II - ch 6.4.1.1 iii)) contract contract
93 100 pieces

94 80 pieces
For supply and delivery 14 Patch After 60 days of Within 120 days of
panel, Category 6 UTP, 24 port Ulaanbaatar, the date of the date of
95 14 pieces
II - ch 6.4.1.1 iv)) contract contract
For supply and delivery 1 Patch panel, After 60 days of Within 120 days of
Category 6 UTP, 24 port (described in the date of the date of
96 1 piece Baganuur, Mongolia
TechSpec Part I. Phase II - ch 6.4.1.1 effectiveness this effectiveness this
iv)) contract contract
Category 6 UTP, 24 port (described in Darkhan-Uul, the date of the date of
97 1 piece
TechSpec Part I. Phase II - ch 6.4.1.1 Mongolia effectiveness this effectiveness this
134

Line Item
Incoterms) date
Date Date

98 1 piece Dornod, Mongolia
99 1 piece Zavhan, Mongolia
100 1 piece Orkhon, Mongolia
Category 6 UTP, 24 port (described in Ovorhangai, the date of the date of
101 1 piece
TechSpec Part I. Phase II - ch 6.4.1.1 Mongolia effectiveness this effectiveness this
102 1 piece Hovd, Mongolia
103 1 piece Hentii, Mongolia
104 1 piece Tov, Mongolia
135

Line Item
Incoterms) date
Date Date

For supply and delivery 14 Patch
105 panel, 24 port (described in TechSpec 14 pieces
Part I. Phase II - ch 6.4.1.1 v))
contract contract

For supply and delivery 1 Patch panel,
106 24 port (described in TechSpec Part I. 1 piece Baganuur, Mongolia
Phase II - ch 6.4.1.1 v))
contract contract

107 24 port (described in TechSpec Part I. 1 piece
contract contract

108 24 port (described in TechSpec Part I. 1 piece Dornod, Mongolia
contract contract

109 24 port (described in TechSpec Part I. 1 piece Zavhan, Mongolia
contract contract

110 24 port (described in TechSpec Part I. 1 piece Orkhon, Mongolia
contract contract

111 24 port (described in TechSpec Part I. 1 piece
contract contract
136

Line Item
Incoterms) date
Date Date

112 24 port (described in TechSpec Part I. 1 piece Hovd, Mongolia
contract contract

113 24 port (described in TechSpec Part I. 1 piece Hentii, Mongolia
contract contract

114 24 port (described in TechSpec Part I. 1 piece Tov, Mongolia
contract contract

For supply and delivery 5 Routers
II - ch 6.4.2.1 i))
contract contract

116 (described in TechSpec Part I. Phase 1 piece Baganuur, Mongolia
II - ch 6.4.2.1 i))
contract contract

II - ch 6.4.2.1 i))
contract contract

118 (described in TechSpec Part I. Phase 1 piece Dornod, Mongolia
II - ch 6.4.2.1 i))
contract contract
137

Line Item
Incoterms) date
Date Date

119 (described in TechSpec Part I. Phase 1 piece Zavhan, Mongolia
II - ch 6.4.2.1 i))
contract contract

120 (described in TechSpec Part I. Phase 1 piece Orkhon, Mongolia
II - ch 6.4.2.1 i))
contract contract

II - ch 6.4.2.1 i))
contract contract

122 (described in TechSpec Part I. Phase 1 piece Hovd, Mongolia
II - ch 6.4.2.1 i))
contract contract

123 (described in TechSpec Part I. Phase 1 piece Hentii, Mongolia
II - ch 6.4.2.1 i))
contract contract

II - ch 6.4.2.1 i))
contract contract

For supply and delivery 5 VOIP/FOIP
125 supporting router (described in 6 pieces
TechSpec Part I. Phase II - ch 6.4.3 i))
contract contract
138

Line Item
Incoterms) date
Date Date

126 supporting router (described in 1 piece Baganuur, Mongolia
contract contract

127 supporting router (described in 1 piece
contract contract

128 supporting router (described in 1 piece Dornod, Mongolia
contract contract

129 supporting router (described in 1 piece Zavhan, Mongolia
contract contract

130 supporting router (described in 1 piece Orkhon, Mongolia
contract contract

131 supporting router (described in 1 piece
contract contract

132 supporting router (described in 1 piece Hovd, Mongolia
contract contract
139

Line Item
Incoterms) date
Date Date

133 supporting router (described in 1 piece Hentii, Mongolia
contract contract

134 supporting router (described in 1 piece Tov, Mongolia
contract contract

For supply and delivery 1 central office
135 PBX (described in TechSpec Part I. 1 piece
Phase II - ch 6.4.3 ii))
contract contract

For supply and delivery 3 local office
136 PBX (described in TechSpec Part I. 66 pieces
Phase II - ch 6.4.3 iii))
contract contract

137 PBX (described in TechSpec Part I. 1 piece Baganuur, Mongolia
contract contract

contract contract
6
3buildings, 3 district offices
140

Line Item
Incoterms) date
Date Date

139 PBX (described in TechSpec Part I. 1 piece Dornod, Mongolia
contract contract

140 PBX (described in TechSpec Part I. 1 piece Zavhan, Mongolia
contract contract

141 PBX (described in TechSpec Part I. 1 piece Orkhon, Mongolia
contract contract

contract contract

143 PBX (described in TechSpec Part I. 1 piece Hovd, Mongolia
contract contract

144 PBX (described in TechSpec Part I. 1 piece Hentii, Mongolia
contract contract

145 PBX (described in TechSpec Part I. 1 piece Tov, Mongolia
contract contract
141

Line Item
Incoterms) date
Date Date

For supply and delivery 3 take-a-ticket
146 machine (described in TechSpec Part 3 pieces
I. Phase II - ch 6.4.4 i))
contract contract
For supply and delivery 1 public After 60 days of Within 120 days of
addressing system for central office Ulaanbaatar, the date of the date of
147 1 piece
II - ch 6.4.4 ii)) contract contract

For supply and delivery 2 digital
148 camera (described in TechSpec Part I. 2 pieces
contract contract

For supply and delivery 2 camcorder
II - ch 6.4.4 iv))
contract contract

For supply and delivery 1 flat Screen
150 TV (described in TechSpec Part I. 1 piece
Phase II - ch 6.4.4 v))
contract contract

For supply and delivery 3 LCD
151 Projector (described in TechSpec Part 3 pieces
I. Phase II - ch 6.4.4 vi))
contract contract

Simultaneous interpretation Equipment Ulaanbaatar, the date of the date of
152 2 pieces
II - ch 6.4.4 vii)) contract contract
142

Line Item
Incoterms) date
Date Date

For supply and delivery 200 wireless
153 headphones (described in TechSpec 200 pieces
Part I. Phase II - ch 6.4.4 vii))
contract contract
will be After 60 days of Within 120 days of

For supply and delivery cabling for 3 buildings,
calculated the date of the date of
154 Local Area Network. (described in N/A Ulaanbaatar,
by the effectiveness this effectiveness this
TechSpec Part I. Phase II - ch 6.4.1.2) Mongolia
contractor contract contract

For supply and delivery cabling for
155 Local Area Network. (described in N/A Baganuur, Mongolia
TechSpec Part I. Phase II - ch 6.4.1.2)

calculated Darkhan-Uul, the date of the date of
156 Local Area Network. (described in N/A
by the Mongolia effectiveness this effectiveness this

157 Local Area Network. (described in N/A Dornod, Mongolia

158 Local Area Network. (described in N/A Zavhan, Mongolia

159 Local Area Network. (described in N/A Orkhon, Mongolia
143

Line Item
Incoterms) date
Date Date

calculated Ovorhangai, the date of the date of
160 Local Area Network. (described in N/A
by the Mongolia effectiveness this effectiveness this

161 Local Area Network. (described in N/A Hovd, Mongolia

162 Local Area Network. (described in N/A Hentii, Mongolia

163 Local Area Network. (described in N/A Tov, Mongolia
For supply and delivery 30 telephones After 60 days of Within 120 days of
30
and 4 fax machines (described in Ulaanbaatar, the date of the date of
164 phones, Pieces
TechSpec Part I. Phase II - ch 6.4.3 Mongolia effectiveness this effectiveness this
4 faxes
iii)) contract contract
and 1 fax machine (described in 2 phones, the date of the date of
165 Pieces Baganuur, Mongolia
TechSpec Part I. Phase II - ch 6.4.3 1 faxes effectiveness this effectiveness this
and 1 fax machine (described in 6 phones, Darkhan-Uul, the date of the date of
166 Pieces
TechSpec Part I. Phase II - ch 6.4.3 1 fax Mongolia effectiveness this effectiveness this
144

Line Item
Incoterms) date
Date Date

167 Pieces Dornod, Mongolia
TechSpec Part I. Phase II - ch 6.4.3 1 fax effectiveness this effectiveness this
168 Pieces Zavhan, Mongolia
169 Pieces Orkhon, Mongolia
and 1 fax machine (described in 4 phones, Ovorhangai, the date of the date of
170 Pieces
TechSpec Part I. Phase II - ch 6.4.3 1 fax Mongolia effectiveness this effectiveness this
171 Pieces Hovd, Mongolia
172 Pieces Hentii, Mongolia
173 Pieces Tov, Mongolia
145

Line Item
Incoterms) date
Date Date

For supply and delivery 1 electricity
174 generator (described in TechSpec Part 1 Piece
I. Phase II - ch 6.4.4 viii)
contract contract

175 generator (described in TechSpec Part 1 Piece Dornod, Mongolia
contract contract

176 generator (described in TechSpec Part 1 Piece Zavhan, Mongolia
contract contract

177 generator (described in TechSpec Part 1 Piece Orkhon, Mongolia
contract contract

178 generator (described in TechSpec Part 1 Piece
contract contract

179 generator (described in TechSpec Part 1 Piece Hovd, Mongolia
contract contract

180 generator (described in TechSpec Part 1 Piece Hentii, Mongolia
contract contract
146

Line Item
Incoterms) date
Date Date

181 generator (described in TechSpec Part 1 Piece Tov, Mongolia
contract contract
Software
For supply and delivery 8 Windows After 60 days of Within 90 days of
Ulaanbaatar,
Server 2008 R2 licenses (described in the date of the date of
182 8 pieces Mongolia
TechSpec Part I. Phase II - ch 6.5.1.1; effectiveness this effectiveness this
(DataCenter)
6.5.1.2; 6.5.1.3) contract contract
For supply and delivery 201 Windows After 60 days of Within 120 days of
Ulaanbaatar,
Profession latest version licenses the date of the date of
(DataCenter)
II - ch 6.5.1.4) contract contract

For supply and delivery 2 Tape library Ulaanbaatar,
184 back-up software (described in 2 pieces Mongolia
TechSpec Part I. Phase II - ch 6.5.1.5) (DataCenter)
contract contract
For supply and delivery 2 Monitoring After 60 days of Within 120 days of
Ulaanbaatar,
software platform for servers the date of the date of
(DataCenter)
II - ch 6.5.1.5) contract contract

For supply and delivery 201 MS Office Ulaanbaatar,
186 Proffesional latest version (described 201 pieces Mongolia
in TechSpec Part I. Phase II - ch 6.5.2) (DataCenter)
contract contract

147

Line Item
Incoterms) date
Date Date

System Management, Administration, and Security Specifications
For supply and delivery 210 Antivirus Ulaanbaatar,
187 software (described in TechSpec Part 210 pieces Mongolia
I. Phase II - ch 6.6.3.1) (DataCenter)
contract contract

For supply and delivery 1 Intrusion Ulaanbaatar,
188 Prevension System (described in 1 piece Mongolia
contract contract

For supply and delivery 1 Web Ulaanbaatar,
189 application firewall (described in 1 piece Mongolia
contract contract
For supply and delivery 2 next After 60 days of Within 90 days of

Ulaanbaatar,
generation network firewall (described the date of the date of
in TechSpec Part I. Phase II - ch effectiveness this effectiveness this
(DataCenter)
6.6.3.2) contract contract
For supply and delivery 1 next After 60 days of Within 90 days of

Ulaanbaatar,
generation network access policy the date of the date of
191 1 piece Mongolia
management server (described in effectiveness this effectiveness this
(DataCenter)
TechSpec Part I. Phase II - ch 6.6.3.2) contract contract
148
SR2/I(b) - List of related Servicesto the delivery of all equipments related to roll-out of the ePRS System


1 Develop detailed Project Plan 1 Document Ulaanbaatar, Mongolia
Within 7 months of the date of
2 Supply and Delivery to all project office All equipment Pieces All Sites
3 Installation and Configuration All equipment Pieces All Sites
4 Testing and commissioning All equipment Pieces All Sites
5 Training All ePRS Users People All Sites

6 Maintenance 24 Months Ulaanbaatar, Mongolia
Warranty (start after acceptance of implementation After 24 months of the date of
7 24 months Ulaanbaatar, Mongolia
of the system) acceptance of implementation
User support/hot line (start after acceptance of After 24 months of the date of
implementation of the system) acceptance of implementation
9 Technical Assistance 24 months Ulaanbaatar, Mongolia
149
Pillar 2
SR1/II – List of Services and Completion Schedule related to digitization of paper archive and conversion of
existing digital data


1 Detailed Project Plan 1 Document Ulaanbaatar, Mongolia
Existing digital
databases and paper
2 Data inspection All archive in All sites
conversion/digitization
sites
estimated archived Within 8 months of the date of
3 Paper digitization 198673 Ulaanbaatar, Mongolia
folders effectiveness this contract
4 Paper digitization 22426 Darkhan-Uul, Mongolia
5 Paper digitization 13268 Dornod, Mongolia
6 Paper digitization 6828 Hentii, Mongolia
7 Paper digitization 6598 Hovd, Mongolia
8 Paper digitization 22588 Orkhon, Mongolia
9 Paper digitization 11275 Ovorhangai, Mongolia
150


10 Paper digitization 10877 Tuv, Mongolia
11 Paper digitization 4476 Zavhan, Mongolia
Incorporation of created digital archive in ePRS estimated digitized Within 8 months of the date of
12 290000 Ulaanbaatar, Mongolia
system documents effectiveness this contract
13 Conversion of existing digital data from REAL 8 databases Ulaanbaatar, Mongolia
14 Conversion of existing digital data from TRIADA 1 database Ulaanbaatar, Mongolia
15 Setup of the digital archive Ulaanbaatar, Mongolia
Transfer all digitized and converted data to the
16 central database (digital archive) and connect the 1 database Ulaanbaatar, Mongolia
central database to the ePRS system
17 Confirm data integration in ePRS Ulaanbaatar, Mongolia
151
Pillar 3
SR1/III – List of Services and Completion Schedule related to the development and implementation of the
Electronic Mongolia Registry System /ePRS/


1 Detailed Project Plan 1 document Ulaanbaatar, Mongolia
2 Analysis and Requirements for ePRS 1 document Ulaanbaatar, Mongolia
Detailed Design of ePRS (Database design,
3 Module design, Testing Procedures, Initial 1 document Ulaanbaatar, Mongolia
Training Materials)
Development of Basic System Components

4 (System management, System Administration and All required Software Modules Ulaanbaatar, Mongolia
Security, Work Flow Operations)
Development of key Application modules

(Inventory, Report Server, Document Within 8 months of the date of
5 All required Software Modules Ulaanbaatar, Mongolia
Management, Property Registration, Property effectiveness this contract
Management)
Development of Front End Solutions Within 8 months of the date of

6 All required Software Modules Ulaanbaatar, Mongolia
(One Stop Shop, Web Publishing) effectiveness this contract
152


7 Site implementation Plan 1 Document Ulaanbaatar, Mongolia
8 Pre-production Testing 1 Testing session Ulaanbaatar, Mongolia
Pilot Implementation Within 10 months of the date of
9 Pilot Site Implementation Test 1 Selected Pilot Site
site effectiveness this contract
Set of Documents
related to the system
(User Guide, User Within 10 months of the date of
10 ePRS System Documentation 1 Ulaanbaatar, Mongolia
References, System effectiveness this contract
Operations Guide
etc.)
11 Development of the Transition Plan 1 Document
12 Development of the Training Plan 1 Document Ulaanbaatar, Mongolia
13 System installation and integration 1 set of documents Ulaanbaatar, Mongolia
Training A) for the system administrators, B) for All ePRS Users and
14 the users and C) for the support engineers of the maintenance People All Sites
system personal

15 Implementation of ePRS system All Sites - All Sites
Operation of ePRS and post-system Support After 24 months of the date of

(Warranty period 2 years) acceptance of implementation
A detailed explanation for services is explained in the chapter below.
153
Service Specifications
The summary of all tasks required from the Supplier, so far identified but not limited to,
are described in 3 pillars based on requirements of technical specifications:
I First Pillar – Delivery of goods and services related to IT equipment and software related
to digitization of paper archive and implementation of ePRS System:
I.1. Detailed Project Plan
I.2. Supply and Delivery
I.3. Installation and commissioning
I.4. Testing and commissioning
I.5. Training
I.6. Maintenance
I.7. Warranty
I.8. User support/hot line
I.9. Technical Assistance
II Second Pillar – Delivery of the services related to digitization of paper archive and
conversion of existing digital data
II.1. Detailed Project Plan
II.2. Data inspection
II.3. Paper Digitization
II.4. Setup of the digital archive
II.5. Transfer digital document into digital archive
II.6. Incorporation of created digital archive in ePRS system
II.7. Conversion of existing digital data from REAL to central database
II.8. Conversion of existing digital data from TRIADA to central database
II.9. Transfer converted data to ePRS system
II.10. Confirm data integration in ePRS
III Third Pillar – Delivery of the ePRS development related services

III.1. Detailed Project Plan
III.2. Analysis and Requirements for ePRS
III.3. Detailed Design of ePRS
III.4. Development of ePRS Components
III.5. Site implementation Plan
III.6. Pre-production testing
III.7. Pilot Site Implementation Test
III.8. ePRS Documentation
III.9. Transition Plan
III.10. Training Plan
III.11. System installation and integration
III.12. Training the system administrators, users and support engineers of the system
III.13. Implementation of ePRS system
III.14. Operation of ePRS and post-system Support
PILLAR I
I.1. Detailed Project Plan
Based on the implementation plan of the ePRS system and digitization process, a project plan
should be provided that must include the following topics for each site: the date for supply
and delivery for each package of equipment, the period for installation and configuration the
site, testing the installed equipment and periods related to the training for the equipmentusage.
I.2 Supply and Delivery
The equipment should be delivery based on approved project plan. The hardware along with
all peripherals should be supplied in full and part shipment is not acceptable unless with prior
permission of MCA. All internal components of the hardware should be valid components of
the brand.
The supplier shall deliver, along with the equipment, a complete set of system
documentation and software manual. In case of critical internal components like Hard disk,
motherboards, controller cards, DVD ROM/Writer drives etc., the manufacturer’s
literature/product system documentation describing the model/make and functionalities,
features etc., shall also be supplied with equipment.
I.3 Installation and Configuration
The Supplier should install and configure all delivered equipment and delivery the site fully
operational.
I.4 Testing and commissioning
The MCA and GASR will accept the goods supplied by the Supplier upon the compliance of
the following acceptance criteria:
 Equipment must comply with technical specifications described in this
document
 The Supplier must demonstrate successful operation of equipment
 Installation of the necessary software with the computer supplied by the
Supplier
 Must demonstrate successful operation of the computers with complete
integration with power system
 Installation of printers, scanners and other peripherals
 Must demonstrate successful operation of printers
 Must demonstrate successful operation of auto feeding scanner
155
 Installation and commissioning of UPS and rack for batteries with wiring and
linkage with servers, computers
 Must demonstrate successful operation of UPS with complete integration with
all necessary hardware
The Supplier should create test plan and according to this should delivery test reports for each
system integration testing.
I.5 Training
The Supplier MUST provide basic technical training courses for allstaff members in each of
the offices. The training must cover the usage of the scanning equipments. Additionally the
Supplier must provide training to selected IT staff of GASR IT department and if applicable
to the local office IT staff. This training must cover basic principles for installation and
maintenance of all equipment provided. The training materials must be in Mongolian and
English languages and will become the property of the Client.
I.6 Maintenance
The Supplier will create a maintenance and support plan for the Warranty Period and the
Post-Warranty Services Period, which will address all aspects of support and maintenance,
such as IT-infrastructure development, operation and maintenance, Application management,
Helpdesk, Training, time for reaction and repair, helpdesk-issue classification, error escalation
procedures, remote and on-site error diagnostics, software and database upgrade techniques,
available (telephonic) assistance (also in relation to helpdesk), training courses.
I.7 Warranty
For all hardware equipment the warranty period should be 2 years unless is different specified
or the manufacturer warranty period cannot be changed from the original.
In the period for warranty the Supplier should respect the following:
 Supplier shall replace or maintain all the hardware supplied, in case of
malfunction without any additional cost to the Purchaser.
 Supplier shall replace any hardware and accessories found with manufacturing
defect.
 The maximum down time for hardware supplied by the Supplier shall not
exceed 2 days.
 Supplier shall perform preventive maintenance of all the equipment supplied
during warranty period.
 Supplier shall ensure that all the software supplied and installed function to the
Purchaser’s satisfaction.
I.8 User support/hot line
156
The Supplier must provide a model for user support activities and help-desk. This model will
be used by the Purchasing Agencies to organize these respective activities.
I.9 Technical Assistance
The Supplier must provide technical assistance if is necessary for GASR IT team that it will
be responsible with the maintenance of the system.
I.10 Reporting
The Supplier’s general reporting requirements, throughout the contracts implementation, to

the MCA-Mongolia and GASR are to be in English and Mongolian.
157
PILLAR II
II.1 Detailed Project Plan
A detailed project plan should be delivered for digitization and data conversion processes.
This plan should include details related to all sites specified in the contract and should be in-
line with the roll-out of the ePRS system. The digitized data should be available as a digital
archive at start of the ePRS implementation. Also the digital data should be migrated before
starting testing the developed ePRS system.
II.2 Data inspection

A detailed data inspection should be made it on digital data from REAL and TRIADA
database and quality report should be created, and assessment must be created for
improvement the quality of the data. The migration process will NOT include a quality
improvement for this data. Data should be migrated as-is and marked in the new system as
migrated data.
II.3 Paper digitization

In order to roll-out the ePRS System existing data on paper records MUST be digitized and
result of this process will create the data for a Digital Archive. A methodology will be
developed by consultancy Blominfo A/S during digitization of a pilot region. Based on the
developed methodology produced consultancy Blominfo A/S will develop a set of
documentation and provide training to supplier in order to start the process in all Mongolia.
The consultancy Blominfo A/S will train the Supplier with regard to the use of the application
developed for digitization and methodology and workflow for digitization, for the so-called
"train-the-trainer" concept.
Sub-Activities in Digitization of paper records, creation and incorporation of Digital
archive
 Digital Archive Requirements
 Digitization Work plan
 Quality Control Manual for Digitized Documents
 Creation of Digital Archive
 Incorporation of Digital Archive into ePRS System
 Test the Digital Archive with ePRS System
To ensure that all folders was entered in the Digital Archive in period of transition for the
implementation of new ePRS system, Supplier will continue to digitize the new documents
that are coming till the ePRS system is in place.
158
II.4 Setup of the digital archive
During the development of ePRS System a format and a structure for digital archive should be
established in order to incorporate digitized documents into archive
II.5 Transfer digital document into digital archive
Digitized documents will be transferred into defined data structure of digital archive, that will
be used by ePRS system
II.6 Incorporation of created digital archive in ePRS system
Supplier must incorporate the resulted digital archive into ePRS system as base component,
and to include in the ePRS system usage and maintenance module for digital archive. Digital
archive must be operational in order to roll-out the ePRS system.
II.7, II.8 Conversion of existing digital data from REAL and TRIADA
The objective of the Data Conversion process realized by the contractor is to migrate, convert
and test all legacy data that is necessary for testing and for the operation of the new
application. The first step of this process is to explicitly define the data that is required to be
converted, along with its sources. This data will be needed for system testing, systems
integration testing, training and acceptance testing as well as production. Following this, the
project team determines an overall strategy to meet those requirements, including both
automated and manual methods. The process includes designing, coding and testing any
conversion modules that are necessary and, of course, performing all actual conversions
themselves.
Sub-Activities in Data Conversion and Loading
 Document Data Conversion Requirements
 Define Data Conversion Strategy
 Define Data Conversion Work plan
 Design Data Conversion Modules
 Code Conversion Modules
 Perform Conversion Module Test
 Convert and Verify Data
Conversion of the Local Databases

In any of the approaches described in this document, the data will be converted from local to
central database(s). In this conversion activity, the differences between the local databases, if
they will occur, with regard to variations in the data models, data categories and
classifications, and the actual data, will have to be resolved. Data conversion and upload
functionality will be developed to assist this resolution of data (model) variations.
During the transition period, the supplier will ensure a full reconciliation with the data stored
in local database till the ePRS system is in place.
159
II.9 Transfer the converted data to ePRS system
Supplier should transfer the data into the new database model and marked as “migrated data”.
These records must be recognized by the ePRS system as incomplete data and the system
should allow the users to be corrected.
II.10 Confirm data integration in ePRS
Supplier should test and confirm that converted data was successfully integrated in digital
archive and connection between ePRS and digital archive was established.
160
PILLAR III
Throughout the ePRS development and implementation the Supplier must consult closely
with GASR and must be compliant with GASR operational and system needs.
III.1 Detailed Project Plan
The project plan for the ePRS system must address the following topics:
 Project Organization and Management Plan with components:
 Progress Reporting
 Risk Management
 Issue Management
 Test and Acceptance Management (Operational Acceptance Testing
Plan)
 Quality Management
 Configuration and Change Management
 Sustainability
 Analysis and Requirements of ePRS system including all necessary
components
 Design of ePRS system
 Build of ePRS system
 Training Plan
 Full Documentation and Manuals
 User Guide (including training manuals)
 User Reference
 Context Sensitive On-line Help text
 System Operations Guide
 Detailed Technical Reference
 Delivery and Installation Plan (including pilot stage)
 Maintenance and Support Plan, addressing:
 Warranty Service
 Help-desk
 Knowledge issue management
III.2 Analysis and Requirements for ePRS
The design, development and implementation can follow several system development
methods but the following (overlapping) activities will have to be addressed and performed in
one or more consecutive project phases, e.g. the definition, analysis, design, build, transition
and production phases of cascading development, or the Inception, Elaboration, Construction,
Transition phases of iterative development.
Existing System Examination
A significant requirement in many custom development projects is to replace the
functionality of an existing system or to work with an existing technical architecture. The
161
Existing System Examination process seeks to meet this need. Part of the input will be
supplied by existing documents and through collaboration with consultancy Blominfo A/S.
Sub-Activities in Existing Systems Examination:
 Obtain Existing Reference Material
 Document Organization Structures
 Create High-level Existing System Data Model
 Create Existing System Process Model
 Document Existing System Interfaces
 Obtain Existing Technical Architecture
 Obtain Existing Capacity Plan
 Produce Revised Existing Technical Architecture
 Produce Existing System Function Description
 Produce Detailed Existing System Data Model
Requirements Definition
The Requirements Definition process defines the business needs of the application
system. The analysis team together with consultancy Blominfo A/S first builds a high-level
Business Process Model that indicates all of the business events and subsequent responses
that the application must support. The team then constructs a high-level Business Data Model
to represent the business’ information needs, and a high-level Business Function Model that
describes the business functions indicated by the process model. Once the business
requirements are defined, the analysis team then adds technological requirements to the
models such as user interface, response time, etc. In this way, the team transforms the
business requirement models into system requirement models.
Sub-Activities in Requirements Definition
 Create High-level Business Process Model
 Obtain High-level Business Descriptions
 Create High-level Business Function Model
 Create High-level Business Data Model
 Create High-level Business Rules Model
 Construct High-level System Data Model
 Construct High-level System Function Model
 Create High-level System Process Model
Part of this activity is the Business Process Reengineering in which special focus is
placed at the current processes and how they need to be transformed to processes,
automatically supported by an IT system, ready for the future. This information will be
provided by consultancy Blominfo A/S.
An overview and a corporate comprehension of the current business processes and
working procedures are crucial for public institutions for planning and reengineering the
processes and organization to meet the requirements of e-Government. A business model
provides a high level view of the processes, duties, functions and information that constitute a
business and describes how these items are interrelated.
162
In IT system development projects, a robust business model is useful to keep the focus
on the business objectives. A business model is in many ways a practical tool to facilitate
business as well as IT system developments:
 Visualize (dependents on the modeling tool) and document the working
processes.
 Identify and explain bottlenecks in the processes.
 Identify duplication of work (same work done twice or more by
different people).
 Identify potential information lacks which might cause bad service to
customers.
 Support the design or redesign of work flows with objective to improve
efficiency by using IT
A business model is helpful to understand the complexity of the business processes
and how the processes are interrelated internally as well as externally. Avoiding business
modeling introduces the risk that the investments are spent on development of an IT-system
that is technologically perfect, but functionally imperfect.
Technical Architecture
The Technical Architecture process specifies elements of the technical foundation of
the development project. This task will be dependent on higher level information system
strategies, such as e-Government. Starting with an Initial Capacity Plan, business analysts
develop an Initial Technical Architecture. As more detailed information becomes available,
the team transforms this deliverable into the hardware and Software Foundation Definition,
and the Distribution Architecture. This process also provides strategies for security and
control, user interface and backup and recovery.
Sub-Activities in Technical Architecture
 Document System Interface Requirements
 Prepare Initial Technical Architecture
 Document System Operational Requirements
 Develop Hardware and Software Foundation Definition
 Develop Distribution Architecture
 Develop Recovery and Fallback Strategy
 Develop Security and Control Strategy
 Develop User Interface Style Definition
 Create Capacity Plan
 Determine Performance Issues.
III.3 III.4Detailed Design of ePRS and Development of ePRS Components
Database Design and Build

The Database Design and Build process begins with the creation of the Conceptual /
Logical Database Design from the System Data Model. After that the physical database
design will be created, using various inputs like the Capacity Plan and the Distribution
163
Architecture deliverables, eventually leading to the creation of the Production Database

Design Language (DDL) to create database objects. The process of designing and building an
object oriented database includes specifying an index design and a scheme for implementing
database object security. The Physical Design and actual build activities will in most cases be
considerably interwoven and will be completed in iterative cycles.
Sub-Activities in Database Design and Build
 Create Conceptual Database Design
 Create Index Design
 Create Database Object Authorization and Security Scheme
 Create Physical Database Design
 Create Production Database Design Language
 Create Prototype Database
Application Design and Build

The Application Design and Build process is the heart of the application development.
Designers use the System Process Model, the System Data Model, and the System Function
Model along with the technical architecture, to first design the system architecture and the
Process Model, and then to specify the functional and technical details of each module (e.g.
report, data entry form, batch procedure). Programmers then use the design documentation
and/or prototypes to construct the Application Code.
The Application Design and Build process has relatively few large tasks. The
management and control strategy of this process can vary greatly, depending upon the overall
project approach. For instance, in a highly iterative development approach, the entire process
may be duplicated for each functional area or build. A very complex application calls for all
design documentation to be completed and approved before any actual programming is done.
Sub-Activities in Application Design and Build
 Define Design Standards
 Define Build Standards
 Create Module Functional Documentation (Conceptual)
 Create Module Technical Documentation (Physical)
 Create Menu Structure
 Design Audit Facilities
 Create Development Environment
 Create Application Code
 Create Prototype Application
III.5 Site implementation Plan
Supplier should provide a site implementation plan for ePRS system. To create this plan the
supplier should work closer with consultancy Blominfo A/S and with the GASR staff. The
Site implementation plan shall include the agreed venue for pilot stage for system
implementation and testing.
164
III.6 Pre-production testing

The Testing process is an integrated approach for testing the quality of all elements of
the application system. It includes functionally-oriented module testing and business-oriented
module integration, system, systems integration and acceptance testing. All business-oriented
testing is driven by the process model to establish firm traceability back to business
requirements. The Testing process emphasizes a common planning approach to all types of
testing. It advocates the re-use of testing scripts to test successively larger and larger portions
of the application system.
Part of the testing strategy may be the conduction of a phase in which a proto-type (in
various levels of completeness) of the application and database will be evaluated.
The bidder MUST implement and execute specified test (and acceptance) process
Sub-Activities in Testing
 Develop Testing Strategy
 Develop System Process Test Model
 Perform Module and Module Integration Test
 Develop System Test Plan
 Prepare System Test Environment
 Perform System Test
 Develop Systems Integration Test Plan
 Develop Systems Integration Test Sequences
 Perform Systems Integration Test
 Prepare Acceptance Test Environment
 Support Acceptance Test
III.7 Pilot Site Implementation Test
Based on later discussion with the MCA and Blominfo A/S a pilot site will be selected for
testing the implementation of ePRS system. At this stage some related processes must be
already finished like: paper digitization and data conversion to create the test integration with
all components and with real data incorporated in the new database model.
III.8 ePRS Documentation
The Documentation process concentrates on producing high quality textual

deliverables. It produces all of the user, technical, and training documentation for the project
that is related with the developed solution in strong collaboration with consultancy Blominfo
A/S. The two primary user-oriented types of documentation are the User Guide and the User
Reference. The User Guide is based on the Module Process Model, and seeks to guide each
user role in using the application to carry out business processes. The User Reference is a
reference guide that specifies the functionality of each module of the application.
Sub-Activities in Documentation
 Prepare Glossary
 Specify Documentation Requirements
 Determine Documentation Standards
165
 Create Documentation Procedures and Environment

 Produce Documentation Prototypes and Templates
 Produce User Reference
 Produce User Guide
 Produce Technical Reference
 Produce System Operations Guide
 Provide Online Help Text (general & context-sensitive)
The Supplier for the ePRS System must provide sufficient documentation at the level of
normal and advanced users, system administrators and application managers, and business
managers both on-line (context sensitive help and hint text) as off-line (manuals).
The Documentation process of the project must center on producing high quality printed and
online help text deliverables. It produces the entire user, technical and training documentation
for the project. The two primary user-oriented types of documentation are the User Guide and
the User Reference. The User Guide is based on the Module Process Model (e.g. use cases),
and seeks to guide each user role in using the application to carry out business processes. The
User Reference is a reference guide that specifies the functionality of each module of the
application. The System Operations Guide and the Detailed Technical Reference describes the
technical aspects of the application. The below mentioned documentation and manuals are
deliverables for the project.
Bidder MUST create specified documentation for ePRS
The following documentation must be prepared:
 User Guide (including training manuals)
 User Reference
 Context Sensitive On-line Help text
 System Operations Guide
 Detailed Technical Reference
User Guide
The User Guide is business oriented and follows the Process Model as described in the
use cases. It contains the procedures by which the users use the application to respond to
business events. It is an instruction manual for the business area. It also is the basis for user
training. New application users use the User Guide.
User Reference
Experienced users take advantage of the User Reference. The User Reference is
organized by system function. Each section of the User Reference explains the details of a
single system function. It includes information on each field and option, data validation, error
messages, etc. Experienced users use the User Reference for information on infrequently used
functions. They also use it to confirm bugs.
Context Sensitive On-line Help text
This is the help text that the user can reference from within the application. In most
cases, you derive the Online Help Text directly from the User Reference.
System Operations Guide
The System Operations Guide is a compilation of all system operations procedures. Its
organization is similar to that of the User Guide (by process, rather than by system function).
166
System operations personnel use the System Operations Guide in learning how to back up the
application system, how to perform recovery operations, audit, etc.
Detailed Technical Reference
The Detailed Technical Reference describes the technical aspects of the application. It
specifies the application system's components, versions and licenses and describes design
decisions and architecture. Future application maintainers use the Technical Reference as a
resource.
The need to develop a Technical Reference depends upon the project requirements.
Two factors determine the extent to which the team has to develop this document. The first
factor is whether the business intends to further develop the application internally. The second
is the extent to which the application maintenance staff is directly involved in the
development process.
For the ePRS a thorough Technical Reference is required, based on the above
mentioned considerations taking into account that the GASR organization will probable in the
future internally upgrade ePRS and/or will engage commissioning staff for it.
III.9 Transition Plan
The Transition and Deployment process begins early in the project by defining the
specific requirements for cut-over to the new application system. It then includes tasks to
carry out the elements of that strategy such as developing the Installation Plan, preparing the
Production Environment, performing the cut-over, and decommissioning any legacy systems.
Sub-Activities in Transition and Deployment
 Define Cut-over Strategy
 Develop Installation Plan
 Prepare Purchaser Maintenance Environment
 Prepare Production Environment
 Go Production
 Shut Down Legacy System
III.10 Training Plan
The objective of the Training process is to create users and administrators and support
engineers that are adequately trained to take on the tasks of running the new application
system. The system administrators also shall be trained how to improve /modify the system,
how to add new features –based on the future needs. The system administrators shall gain full
knowledge of the system coding during the training.
The team shall also train future maintenance personnel and the acceptance test team.
The supplier should take in consideration on creating the training plan to consider
training the following types of trainings:
 ePRS system administrator training
 ePRS user training
 ePRS support engineer training
167
Bidder MUST implement specified necessary training

Sub-Activities in Training
 Define Training Requirements
 Define Training Plan
 Create Training Materials
 Produce Purchaser Maintenance Class Materials
 Create Training Database
 Produce User Class Materials
 Prepare Training Installation
 Train Users
 Train Administrators
 Train Support engineers
 Train Acceptance Test Team
III.11 System installation and integration
Running a high available consolidated DataCenter places more demands on a well-

trained and organized IT team. The teams must be supported with system and service
management tools and processes that provide control over the system landscape. Objective
one is to minimize business disruption by monitoring the key applications and systems with
proactive problem resolution. ITIL is a world standard guide to define the management
processes and to grow to higher levels of maturity. Most organizations start with incident-,
problem- and change management processes, supported by service management tools. Change
management is important because poorly implemented changes are a major cause of
outages/calls to the service desk. Manufacturers provide software agents for monitoring and
administration with their hardware and software products, they are optimally designed to
work with the product with which they are delivered. A central monitor tool consolidates the
management of all managed devices (network, storage, system, database, application, etc.).
Managed devices are polled to check their condition; alerts are received directly from them or
via a log agent, based on thresholds and policies. The central monitor tool react to the
received information by executing one or more actions, such as sending incidents to the
service management tool or notifying administrators.
The responsibility for software development must be separated from exploitation of
the DataCenter. The DataCenter can be run with a small team with external assistance for
training on the job until GASR is ready. The roles in the team must be divided in principle
into two clusters. Helpdesk and Operations, they are responsible for first line user support and
the daily operations like monitoring, job scheduling, and administration of user accounts,
authorization and housekeeping. A service desk system supports first level support, assigns a
priority to each problem, and forwards problem messages to the relevant specialist of the
Technical Support group. The Technical Support group handles the forwarded problems and
is responsible for the maintenance of the whole infrastructure; in this group more in depth
expertise is necessary for terminal server-, system-, and database- and network administration.
Bidder MUST provide written policies and procedures must be available.
168
An emergency plan must be defined by the Supplier, but the planned measures during
a disaster cannot always be covered. Therefore a creative response from well-trained
personnel, as well as the right service partners is most important however based on a kind of
handling procedures that Supplier must prepare.
There is no need for IT staff at the regional level in the chosen consolidated
infrastructure. Management of local devices is the same for copiers, multi-functional printers
and terminals.
Bidder MUST develop IT technical skills for administration and maintenance
development, implementation and revision of ePRS.
Staffing of GASR offices with regard to IT technical skills is and will remain to be
difficult, based on the difficulties of keeping employed increasingly better trained staff, and
the ratio between government and private sector salaries. However it is important to ensure
that core technical IT skills are available inside the organization. These skills are in particular
relevant for handling relations with suppliers, partners, and external experts.
A core team has to be established of a team with skills on the following areas:
 IT architecture and security;
 Application & Database Administration
 User support (Application Enhancement, Errors and Management of trainers).
III.12 Training the users of the system
The GASR needs to upgrade their capacity to a level that enables this institution to perform
their IT related duties professionally. The implementation of the system requires trained users
at both advanced and normal level.
In the context of this project the issue of building capacity for operation and maintenance of
the ICT-systems needs special attention. On various levels at the State Property Management
administration there will be a need for IT skills which for convenience are divided into two
types:
 IT user skills for efficient use and administration and maintenance of existing
applications
 IT technical skills for development, implementation and revision of ICT systems
The physical placement of the system will be the office(s) of GASR in Ulaanbaatar. Thus, IT
professionals there have to be trained as well in the usage and maintenance of the system and
its application(s).
Bidder MUST develop and provide specified training aimed at IT user skills for efficient use
of ePRS system.
Resource-wise there is a great task in building and development of the capacity of IT
user skills as part of sustainability. The challenge is to ensure an efficient use of IT and
simultaneously to be patient enough to see the investment in a broader perspective to avoid
sub-optimizing. A focused development of user capacities will improve the quality of the IT
usage and the need of help desk capacity will be less.
169
All users need to be trained within their role(s) in the use of the ePRS System. The following
training will be provided by the Supplier to train the users to use the system during the
schedule of system development:
 Management training; aimed at (high and middle level) management of GASR,
and their use of the system(s), disaster scenario’s, security, impact on the business
and etc.
 Business administrators training; aimed at the persons responsible for definition of
security credentials, roles and new processes in the system.
 Real Registration Operations training; aimed at the land registry processes and the
support by the system(s) thereof
 IT Training (technical maintenance, programmer, security, network administrator,
database administrator and etc.)
These trainings are role-based and can be further designed, divided and detailed based
on the authorization and role (stakeholder) design of the systems.
The Supplier in strong collaboration with consultancy Blominfo A/S will organize the
trainings based on a common schedule.
The Bidder MUST develop and provide specified training aimed at "train-the-trainer"& 1st
line help-desk skills for ePRS.
The Bidder will train consultancy Blominfo A/S as trainers with regard to the use of the
applications, for the so-called "train-the-trainer" concept. The Bidder will continue the
implementation on training for all employees regarding the use of applications. Also this type
of training should be applied to a fraction of GASR IT department appointed staff members
(up to 15 experts) to accumulate the knowledge that will help them also to perform the 1st line
help-desk support with regard to the use of the applications, and they will need advanced
application administration knowledge for this task. The knowledge that these trainers will
gain is considered to be application specific, and less generic in the sense of general IT skills.
The bidder MUST develop IT technical skills for administration and maintenance
development, implementation and revision of ePRS system
In the current situation all IT tasks in GASR are performed by a team of developers and IT
specialists that are not certified in specific domains of administration or developing. This is a
situation which leads to a lack of specialist knowledge. As at the moment there is insufficient
knowledge on DBA (acronym for?), testing and security. This problem will grow as the
functionality of the system will extend.
Therefore the staffing of GASR offices with regard to IT technical skills is and will remain to
be difficult, based on the difficulties of keeping employed increasingly better trained staff,
and the ratio between government and private sector salaries. However it is important to
ensure that core technical IT skills are available inside the organization of GASR. These skills
are in particular relevant for handling relations with suppliers, partners, and external experts.
By GASR a core team has to be established of a team with skills on the following
areas:
170

 User support (Application Enhancement, Errors, Management of trainers)
In order to get as smooth as possible knowledge transfer and in order to assure the high level
of sustainability of developed system and solutions, the GASR makes his IT team available to
the future ePRS Supplier based on part time participation in various phases of the project.
This means that GASR will be actively involved on the side of the Supplier e.g. providing
detail info on existing system, and as well participating in the system development as
supportive experts. The consultancy Blominfo A/S will be fully involved and helping in
understanding the existing system and providing the vision for the ePRS system. However,
the responsibility for the project, regarding its timely delivery, the completeness and quality
of deliverables, etc. will still be fully on the side of the Supplier.
The ePRS system administrator training (consider 8 selected IT experts from GASR central
IT department) has to include system training, database training, network maintenance
training and system security
The ePRS user training has to explicitly include special part that involves part of the finance
that relates with ePRS system. Estimated number is 100 people, but correct number of
attendants will be establish during discussions and agreement with GASR and Blom in the
inception period of the contract. The training has to be delivered in local offices, and for each
office it has to be at least 10 days. The delivery will be accepted based on the signed
document by each of the office head that staff received the system usage training, and fully
understand the system usage.
Support engineer training is estimated to be for 15 selected IT experts from GASR central IT
department. The duration of the training should be at least 10 days. The training has to include
the following:
 Methodologies to ensure the 1st line-support for the users (online, remote support
etc.)
 1st line-support training for all aspects of the system including operational
hardware issues
III.13 Implementation of ePRS
Based on the approved implementation plan with MCA and consultancy Blominfo A/S, the
supplier will make the implementation on-site of the ePRS system in each location specified
in contract.
III.14 Operation of ePRS and post-system Support
Maintenance and Support

The four objectives of the Maintenance and Support process are to monitor and
respond to system problems via a help desk, to upgrade the application to fix errors and
performance problems, to evaluate the system in production, and to plan enhancements.
Sub-Activities in Maintenance and Support
o Audit System
171
o Measure System Performance

o Agree on Performance Exceptions
o Analyze Problems
o Monitor and Respond to System Problems
o Analyze Performance Exceptions
o Prepare Application Upgrade Strategy and Plan
o Produce Upgrade Scripts and Procedure
o Make Application Changes
o Test Application Upgrade
o Upgrade Application
o Determine Future Functional Enhancements
o Plan Enhancements
The Supplier will create a maintenance and support plan for the Warranty Period and the
Post-Warranty Services Period, which will address all aspects of support and maintenance,
such as IT-infrastructure development, operation and maintenance, Application management,
available (telephonic) assistance (also in relation to helpdesk), training courses. The above
mentioned support and maintenance will be formalized in Service Level Agreements, the
Bidder must propose the contents of such an agreement, for example specify a set of response
times for different degrees of seriousness of the defects and/or categories of IT and/or specific
subsystems.
Bidder MUST create and implement maintenance and support plan
Warranty Period
The "Warranty Period" will commence at the date of the Operational Acceptance
Certificate of the System or Subsystem(s), during which the Supplier is responsible for
defects with respect to the System. To assist these activities a 1st and 2nd line helpdesk
support needs to be set up.
Help Desk
The Supplier must prepare a well trained staff responsible help-desk services. The help-desk
will consist of two lines. The 1st line help-desk supports with regard to the use of the
applications, with help of internal phone number(s) and an issue management system. The
issues will be classified (e.g. urgency, priority, error, wish) and resolved as much as possible
by the internal helpdesk. The issues that cannot be resolved by the 1st line help-desk support
will be transferred to the 2nd line help desk support, which will be provided by the Supplier.
The help desk shall work as a one-point-of-contact. This means that the user with a problem
shall contact one number, only, to present his problem. If the help desk cannot solve the
problem, it is the obligation of the help desk to seek a solution in the second line of support.
In this way the user is not sent from one person to another again and again.
Bidder MUST implement help-desk and knowledge issue management system
Operational running of DataCenter
172
The Bidder must offer of staffing of the DataCenter with own personnel for a period of at
least the 2 years. The goal of it will be keeping the system fully operational with help of own
GASR’s IT staff and the specialists from the bidder’s personnel and the bidder staff will
continuously transfer the knowledge to the GASR staff. The number of Bidder’s staff must be
gradually decreasing within the proposed period of 2 years.
173
SR3 Technical Specifications

The supply of Goods and Related Services shall comply with the following Technical
Specifications and Standards.
Technical specifications are composed from 3 important pillars/components:
 First pillar represent goods and services, and consist in description of technical
specifications for the required hardware, software and the equipment needed to
establish operate the ePRS, establish and operate inter-Office Connectivity, and carry
out other Functions. This pillar should be completed in 2 phases. First phase consist in
supply and delivery the necessary equipment for the digitization process which must
be completed before the implementation of ePRS system. Second phase consist in
delivery the requested hardware, software and equipment in order to roll out the ePRS
system
 Second pillar represent services and should consist in providing the related services
for digitization of paper archive and conversion of existing digital data. The digital
archive produced during this process will be incorporated in ePRS and should be
finish before the roll out the ePRS system.
 Third pillar represents development and describes the functionality and technical
requirements for the modern registry tool, the Electronic Mongolia Property Registry
System (ePRS). The system must support all the reformed business processes of
GASR, including: immovable property rights registration processes for different types
of services; information requesting and delivery processes; reporting processes and
financial accounting processes.
Taking in consideration these facts, the technical specifications are divided in three parts,
each part represent a pillar in the system.
174
PILLARI -TECHNICAL SPECIFICATIONS FOR THE

REQUIRED HARDWARE, SOFTWARE AND THE EQUIPMENT
NEEDED TO ESTABLISH AND OPERATE THE EPRS,
ESTABLISH AND OPERATE INTER-OFFICE CONNECTIVITY,
AND CARRY OUT OTHER FUNCTIONS
175
0Schedule of Requirements
PILLAR I- PHASE 1 – TECHNICAL SPECIFICATIONS FOR

THE REQUIRED HARDWARE, SOFTWARE AND EQUIPMENT
NEEDED FOR THE DIGITIZATION PROCESS
1. INTRODUCTION
This part of technical specifications describes technical requirements and specifications of the
need hardware, software and other equipment for the digitization process.
The main reason for creating a separate technical specification for this service related to the
digitization process is that digital archive must be available before the implementation of the
new property registration system. Digitization will involve participation of the
supplier/Supplier as producer of the digital data, process that it will be observed by the
Blominfo A/S. The timely acquisition of equipment is very important in order to meet the
proposed project plan. Although this process can be done, it is dependent on special
equipment like ADF high-speed scanner being purchased.
The supplier/Supplier for this part should be able to deliver:
 High-speed, A4/A3 size, ADF equipped special scanners;
 Database server software that supports indexing possibility that can be used for
scanned images;
 Computer hardware (workstations) to digitize scanned documents;
 Network equipment to ensure connectivity for each site scanning location;
 Storage for scanned files and backup
177
2. OBJECTIVE
Tender bid for the Digitization process is to supply appropriate equipment and software for
running Digitization pilot and hardware for Archive offices in the scope areas.
2.1 Digitization System Objectives
In order to implement the property registration project current paper archive must be digitized
and information collected must be stored in a digital archive.
In this scope a tender is necessary to get the necessary hardware for an in-house digitization
of archive. The scope for this document is to cover the necessary hardware and software to
complete the digitization of archives for 8 aimags.
2.2 Digitization System required Actions
In order to achieve proposed objectives the following actions need to be undertaken:
 All hardware should be installed, tested and operational at least 2 weeks before the
start of the pilot
 The paper archive should be pre-pared for the pilot operation (the inventory team
should have all documentations prepared and the inventory office ready in order to
start the work immediately)
2.3 Benefits of the Digitization

The provided hardware and software will be used during the digitization period and after this
project will finish, the equipment will be made available to archive department to be used in
archiving process of the new ePRS system.
178
3. PERIOD OF THE PERFORMANCE

In order to fulfill the requirements, the winning bidder should complete following tasks that
have split in to performance periods.
3.1 Planning period

 The winner should prepare its Work plan and Delivery/Installation Plan and have
them accepted by BlomInfo A/S and GASR;
3.2 Delivery and installation period

 The supplier should start delivering and installing goods following its plans, under
coordination of the BlomInfo A/S;
 In this step, the goods shall be tested and prepared for the roll-out.
3.3 Pilot office

 In this step the supplier should cooperate with BlomInfo A/S in order to install the
goods in the Pilot office.
3.4 Operation and monitoring period

 In this step, all the system components shall be running having harmonized with
the ePRS;
 The performance results shall be evaluated and taken required actions;
 Fully operational system shall be received by BlomInfo A/S and GASR;
3.5 Warranty period

 In this period the Supplier shall be responsible for any failure that is not caused by
the users.
179
4. GENERAL TECHNICAL REQUIREMENTS

4.1 Language Support:
All information technologies must provide support in Mongolian language. Specifically, all
display technologies and software must support the ISO 10646 character set.
4.2 Dates:
All information technologies MUST properly display, calculate, and transmit date data,
including, but not restricted to 21st-Century date data.
4.3 Electrical Power:
All active (powered) equipment must operate on the following voltage range, 220V +/- 20V
and frequency range, 50Hz +/- 2Hz. All active equipment must include power plugs standard
in Mongolia.
4.4 Environmental:
Unless otherwise specified, all equipment must operate in environments of 10-30 degrees
centigrade (50° to 95°F) with a maximum temperature gradation of 10 degrees centigrade per
hour, 20-80 percent relative humidity with a maximum humidity gradation of 10% per hour,
altitude range between -16 and 3048 meters (-50 to 10000 feet) and 0-40 grams per cubic
meter of dust.
4.5 Safety:
Unless otherwise specified, all equipment must operate at noise levels no greater than
55dB(A).
180
5. COMPUTING HARDWARE SPECIFICATIONS

5.1 Workstation for Digitization personnel:
The customer will need to use desktop computers for its scanning stations with at least 2 GB
of RAM for image capture and quality control and 1 GB for digitization. The following
minimum requirements should be considered. The customer will need dual monitors with at
least 19-inch display to preview the quality of images to be captured and review them for
completeness. This adheres to the digitization team recommendation and will allow the
customer to have a large enough monitor to properly review images.
5.1.1 Scanning and quality control workstation – minimum requirements:
Processor ‐ At least 2 cores and 2 threads
‐ Clock speed: 2.8 GHz
‐ Instruction set: 64-bit
‐ Memory types: DDR3-1066/1333
‐ Support Virtualization Technology
Memory ‐ 3 GB DDR3-1066/1333
Video card ‐ PCI Express x16 slot

‐ Memory size: 512 MB GDDR3
‐ Memory interface: 128-bit
‐ Support for dual monitor configuration: digital outputs: 1, Analog outputs:
1
‐ Max Display Resolution Digital: 2560x1600@60Hz
Hard drive ‐ 2x500 GB SATA (7200 RPM)
Drive controllers ‐ Integrated SATA 3.0 Gb/s host controller, supports RAID 0,1
Network controller ‐ Gigabit Ethernet controller
Chassis ‐ Mini-tower or desktop orientation

‐ Bays: 2 internal 3.5" HDD bays, 2 external 5.25" optical bays, one external
3.5"flex bay for floppy or media card reader
‐ Slots: Two PCI-e x8 slot wired as x4, one PCI-e x16 Gen 1 graphics slot,
Two PCI slots
‐ Standard I/O ports: 11 USB 2.0 (two on front panel, six on back panel,
three internal (UDOC) on motherboard), 1 eSATA rear, 1 serial, 1 parallel,
2 PS/2, 1 RJ-45, Stereo line-in and headphone line-out on back panel,
Microphone and headphone connector on front panel
Storage Devices ‐ DVD+/-RW, USB Floppy Drive and/or USB media card reader
Sound card ‐ Integrated High Definition Audio
Power ‐ 525 watts Active Power Factor Correcting (PFC) power supply
Monitor ‐ Type: LCD Display / TFT Active matrix

‐ Diagonal size: 22"
‐ Max resolution: 1920x1080@60Hz
‐ Response time: 5 ms
‐ Signal input: HDMI, DVI-D, VGA
181
‐ Energy Star Qualified
Keyboard and mouse ‐ USB wired Keyboard (104 keys)

‐ USB optical mouse, wired, scrolling wheel
Operating system ‐ Microsoft Windows 7 Professional Edition, 32 bit
Warranty ‐ At least 2 years manufacturer warranty
Number of pieces: 15
Recommendation: The Bidder could consider upgrading to 2 GB of RAM to accelerate
image processing. As the 19-inch monitors age, we recommend that over time, the monitors
be upgraded to 21-inch flat-panel high-resolution monitors, which are more readable, have a
smaller footprint, and use less energy than CRT-based monitors.
5.1.2 Digitization workstation - minimum requirements:
The customer will need to use this type of workstation to index the metadata from the image
collection. The data elements specified in the project requirements will be captured using
separator sheets during the document preparation phase and scanning phase. Document meta-
data, such as property registration number, document type, number of pages and date created
earlier in index files will be presented in the indexing web-based module for verification and
correction.
Memory ‐ 3 GB DDR3-1066/1333


‐ Slots: Two PCI-e x8 slot wired as x4, one PCI-e x16 Gen 1 graphics slot,
Two PCI slots
‐ Standard I/O ports: 11 USB 2.0 (two on front panel, six on back panel,
three internal (UDOC) on motherboard), 1 eSATA rear, 1 serial, 1 parallel,
2 PS/2, 1 RJ-45, Stereo line-in and headphone line-out on back panel,
Microphone and headphone connector on front panel
Storage Devices ‐ DVD+/-RW, USB Floppy Drive and USB media card reader
182


Workstation Type
Site Name Scanning & Quality Control
Digitization Workstation
Workstations
Ulaanbaatar 3 12
Baganuur 1 1
Darhan-Uul 2 2
Dornod 1 2
Zavhan 1 1
Orkhon 1 2
Ovorhangai 1 2
Hovd 1 1
Hentii 1 1
Tov 1 1
Additional backup equipment 2 2
Total (Position 1+Position 2) 15 27
5.1.3 Uninterruptible Power Supply (UPS) - the minimum required technical

specifications are:
Topology line-interactive ; pure sine wave
Output Power Capacity 670 Watts / 1000 VA
Max Configurable Power 670 Watts / 1000 VA
Nominal Input Voltage / Input Frequency 230V / 50-60 Hz +/- 3 Hz (auto sensing)
Output Voltage Note Configurable for 220 : 230 or 240 nominal output voltage
Output Connections 8 - IEC 320 C13
Output Voltage Distortion Less than 5% at full load
Autonomy on load 100% / 50% 6,1 minutes / 20,6 minutes
Interface Port(s) DB-9 RS-232, Smart Slot, USB
Input voltage adjustable range for mains 160-286V
operation
Typical recharge time 3 hour(s)
Operating Environment Operating Environment
Warranty 2 years standard warranty: repair or replace
Number of pieces: 42 (one for each workstation)
183
5.1.4 External Hard Drive Storage

Documents will be stored as Tagged Image File Format (TIFF) files or in PDF/A format. The
documents will be stored in external hard-drives that MUST be connected to an interface that
will ensure higher read/write speeds.
The minimum required technical specifications are:
Capacity at least 2TB
Interface Gigabit Ethernet, eSATA/FireWire
System Compatibility Microsoft Windows
Operating Environment Operating Environment
Warranty 2 years standard warranty: repair or replace
Number of pieces: 20 (one for each site location and backup)
5.2 Shared Output and Input Devices:
5.2.1 General Requirements:
Unless otherwise specified, all shared output and input devices must becapable of handling
A4 and A3 standard sized paper.
5.2.2 Scanners:
The scanners MUST have the capability of 400 to 800 dots per inch (dpi). The scanners being
provided by the Bidder MUST scan according to customer needs in bi-tonal (black-and-
white), grey-scale, or color. The scanners MUST also accommodate single- or double-sided
scanning.
scanner provided by contractor MUST support these formats and must include the software
for processing documents in these formats.
The scanner MUST include proprietary scanning software. This software offered by the
contractor should have on-screen displays that will enable the operator to make the image
setting adjustments necessary to optimize the scanner’s output. The scanner operator should
be able to identify and rectify quality issues such as miss-feed pages, poor image contrast, and
incomplete images. If the scanner operator catches errors during this step, he or she can adjust
the scanner’s settings to respond to the changing document conditions and sizes, and then
rescan the documents immediately.
Scanner Type Flatbed/ADF

Daily duty cycle At least 10000 pages
Scan Size Between 2 in x 3 in - 11 in x 17 in
Optical Resolution At least 600 dpi
Output Resolution At least 100/150/200/240/300/400/600 dpi
Scanning Speed letter, color, black and white, grayscale, 200 dpi: at least 50 ppm
color 24-bit duplex: at least 50 ppm
Scan media Paper (plain, inkjet, photo), envelopes, cards (index, greeting),
Scan File Format PDF (formatted Text and Graphics, normal with images, searchable image over text,
MRC, PDF/A), TIFF (single page, multi-page, compressed), JPG, BMP, PNG, DOC,
RTF, TXT, WPD, XLS, HTM, OPF, UNICODE, XML, XPS
Connectivity Standard High-Speed USB 2.0, optional SCSI
Compatible operating Microsoft Windows

system
184
Warranty At least 2 years manufacture warranty

Features Automatic color detection, content-based rotation, blank page deletion, double feed
detection, barcode detection
Additional Document Kodak Capture Pro or Kofax Capture included
Imaging Software Full use license software with at least 1 year maintenance
Follow: The contractor will follow ANSI/AIIM MS44-1998, “Recommended Practice for
Quality Control of Image Scanners,” to ensure scanner quality control and continued
maintenance of an established level of quality; ANSI/AIIM MS53-1993, “Recommend
Practice; File Format for Storage and Ex-change of Image; Bi-Level Image File Format: Part
1,” and ANSI/AIIM TR19-1993, “Electronic Imaging Display Devices,” for selecting imaging
devices; and ANSI/AIIM TR26-1993, “Resolution As It Relates to Photographic and
Electronic Imaging,” for evaluating photographic and electronic imaging products. In
addition, we recommend consulting the NARA and Digital Library Federation websites for
guidelines and best practices regarding document scanning.
Number of pieces: 16 (one for each scanning workstation + 2 as additional backup

equipment)
5.3 Network and Communications Specifications
5.3.1 Local Area Network(S):
5.3.1.1. Equipment and software:
i) Switch 8 ports - minimum required technical specifications:
Port attributes 8 10/100/1000BASE-T auto-sensing Gigabit Ethernet switching ports
Auto-negotiation for speed, duplex mode and flow control
Auto MDI/MDIX
Warranty Minimum 2 years manufacturer warranty

Number of pieces: 9
ii) Switch 24 ports - minimum required technical specifications:

Port attributes 24 10/100/1000BASE-T auto-sensing Gigabit Ethernet switching ports
Auto-negotiation for speed, duplex mode and flow control
Auto MDI/MDIX
Number of pieces: 1
5.3.2 Other communications equipment:
Not applied.
5.4 Software Specifications
5.4.1 Database Software and Development Tools:
To index the metadata from the image collection (such as property registration number,
document type, number of pages in each document, source (hard copy, digital, both),
185
document type, scanning operator, and the scan date and document issued date etc.) and
ensure the process for digitization a software database MUST be provided.
The proposed database software that will cover the requirements for data indexing and
auditing for the digitization process and will ensure compatibility with the digitization
software can be described based on the following features:
Scalability and - Number of CPUs – 4

Performance - Maximum memory utilized = 64GB
- Maximum database size 524PG
High Availability - Online system changes

(Always On) - Log shipping
- Database mirroring
- Automatic Corruption recovery from mirror
- Log stream compression
- Backup Compression
Replication - Snapshot replication

- Merge replication
- Transactional replication
Security - Windows Integrated Authentification

- Data encryption and key management
Management, - Configuration Manager

Development Tools and - Microsoft Visual Studio Integration
Reporting - Version control support
- XML/A support
- Web services (HTTP/SOAP endpoints)
- Report Server, Manager and Designer
Maintenance - Full maintenance for 1 year
Number of licenses: 10 (should ensure a database license per each local processing unit
in digitization process per digitization process duration period)
Note: An alternative solution could be provided to ensure the licensing for digitization
database in a distributed environment (1 archive in Ulaanbaatar + 8 aimags + 1 pilot
region Baganuur) in order to reduce costs, taking in consideration that these database
licenses will not be used after the process finish.
5.5 Service Specifications

5.5.1 System Integration:
All hardware and software to be purchased within the Contract MUST be fully compatible
with the software and hardware from the other contracts within the Project (Mongolian
Property Registration System - ePRS, Uniform Financial Accounting System - UFAS,
Equipment and software for digitization process, WAN connectivity and maintenance)
5.5.2 Training and Training Materials:
186
5.5.2.1. Technical:
The Supplier MUST provide basictechnical training coursesfor IT staff. This training must
cover basic principles for installation of all equipment provided. The training materials must
be in Mongolian and English languages and will become the property of the Client.
5.5.3 Technical Support:
5.5.3.1. Warranty Service:
For all hardware equipment the warranty period should be 2 years unless is different
specified or the manufacturer warranty period cannot be changed from the original. In these
cases a special agreement, to cover the period of 3 years, should be established.
5.5.3.2. User support / hot line:
The Supplier MUST provide a model for user support activities and help-desk. This model
will be used by the Purchasing Agencies to organize these respective activities.
5.5.3.3. Technical Assistance:
The Bidder MUST provide a description of the organization that will provide technical
assistance. This description should include the number and qualification of staff, their
location, the facilities and tools at those locations taking into consideration distances and local
conditions of project sites.
5.6 Documentation Requirements
5.6.1 End-User documents:
All end-user documentation MUST be in Mongolian language. The Supplier MUST provide
Application Users Guides.
5.6.2 Technical Documents:
All the products to be delivered MUST have specific installation and/or technical
documentation. The original documentation MUST be in English and at least the main
manuals (as User Guide, Administration Guide), translated into Mongolian language.
5.7 Consumables and Other Recurrent Cost Items
During warranty period the Supplier MUST provide warranty services and spare parts. After
the warranty period these costs will be presented under the Recurrent Cost section. Only those
consumables necessary for the initial delivery can be added to the investment.
187
6. INSPECTIONS
6.1 Factory Inspections:
The Bidder MUST prove that all delivered items have passed the factory inspections by
providing their certificates of quality assurance.
3.1.2 Inspections following delivery: Since the custom duties are the Bidder’s responsibility
each delivery will be checked against its packing list. After Site(s) delivery there will be
another delivery integrity checking performed by the Bidder.
6.2 Operational Acceptance Tests
Pursuant to GCC Clause 27 and related SCC clauses, the Bidder (with the assistance of the
Supplier) will perform the following tests on the System and its Subsystems following
Installation to determine whether the System and the Subsystems meet all the requirements
mandated for Operational Acceptance.
6.2.1 For hardware, system software and communications:
 In addition to the Supplier’s delivery tests, the Bidder shall manage the test
(supported by the Supplier) and perform installation tests on each delivered
system.
 The respective installation test scripts and test schedule MUST be proposed by the
Supplier and approved by the Bidder 15 days before starting.
 The Entire System: after successful installation of each system, the Bidder MUST
perform a complete system installation test, with the assistance of the Supplier.
The Bidder (with the assistance of the Supplier) MUST perform a Final
Installation Test after all delivered systems, including the Central Processing
Units, will be in place. Must be included in the Project Plan
Note: The complexity of the Operational Acceptance Testing needed will vary in accordance
with the complexity of the System being procured. For Systems to be procured using the
single-stage bidding process, Operational Acceptance Testing may simply consist of requiring
a specified period of trouble-free System or Subsystem operation under normal operating
conditions. For more complex Systems, Operational Acceptance testing will require
extensive, clearly defined tests under either production or mock-production conditions.
188
7. CONTRACT SIGNATURE
It is estimated that the Final Contract between the selected Bidder and the Purchaser will be signed by 15 June 2011.
189
8. IMPLEMENTATION SCHEDULE
8.1 Project Stages
The Gantt Chart below indicates the general Project Stages with allocation of responsibilities between the involved parties.
Hardware for digitization process
Major Project Stages
Calendar Months
Project Stages Result of the stage Responsible 2011 2012
J F M A M J J A S O N D J F M A M J J A S O N D
1.Hardware Delivery HW Supplier
Hardware delivered
+ CO
2. Hardware installation Data center installed
HW supplier
+ CO + RO
4. Testing and Acceptance Acceptance of the HW supplier
system +CO
6. Implementation and System ready for the CO

Operational Tests for Final new productions and
Acceptance daily operations
CO - Central Office; RO – Regional Office; HW –Software
The Bidder can propose its own implementation deviated to it schedule based on his specific approach and methodology, however the deviations
must be well augmented and lead to improved system development efficiency and better project result.
190
8.2 Milestone
The milestones related to the payment schedule defined for the project are:
Milestone Description
Hardware Delivery Plan Work Plan and Delivery/Installation Plan
Accepted Delivery/Installation Plan
Hardware Installation Accepted Delivered Hardware
and Implementation
Operation Operation of Hardware (Warranty period 2 years)
8.3 Implementation Schedule

In the table below, the Implementation Schedule with Deliverables (Working Products and
Milestones) are provided. The Bidder is expected to complete and adjust this table based on the
chosen approach.
No. Description Deliverable Type Delivery Acceptance Liquidated

(from (from Damages
Effectiveness) Effectiveness) Milestone
Work Product: June 2011 July 2011 No

M0 0 Detailed Project Plan
Report
1 Work Plan Work Product: June 2011 July 2011 No
Report
2 Delivery installation Work Product: June 2011 July 2011
M1
Plan Report
Hardware Delivery Milestone June 2011 July 2011 No
Plan
3 Hardware Installation Work Product: June 2011 July 2011 No

Hardware
M2 equipment
Hardware Installation June 2011 July 2011

Milestone Yes
and implementation
4 Operation of hardware Work Product: July 2011 June 2013 No

(warranty period 2 Report
years)
M4
Operation Milestone July 2011 June 2013 No
8.4 System Inventory Table (Supply and Installation Cost Items)

Based on the deliverable implementation schedule, the supply and installation costs items are
described in this section. The Bidder is expected to complete and adjust this table based on the
chosen approach.
No. Description Location
0 Detailed Project Plan CO
1 Data inspection All sites
2 Develop Digitization and Migration Methodology All sites
3 Data Digitization All sites
4 Operation of hardware (warranty period 2 years) CO
8.5 System Inventory Table (Costs of Services)

Not applicable.
8.6 Site Table

The GASR Apparatus has the following offices:
Site Code Site City / Town / Region
PRIMARY SITE
CO GASR Central Office Ulaanbaatar
Ulaanbaatar city district OfficesBaganuur,

TO01
Bayanzurkh, Chingeltei, Songino-Khairkhan

RO04 Zavhan

RO05 Orkhon

SUPPORTING SITES
192
PILLARI - PHASE 2 – TECHNICAL SPECIFICATIONS FOR THE

REQUIRED HARDWARE, SOFTWARE AND EQUIPMENT NEEDED
TO ESTABLISH OPERATE THE EPRS
193
1. INTRODUCTION
This part of technical specifications describes technical requirements and specifications of the
need hardware, software and other equipment for the upgrade.
 The document contains following parts that should distinguished by deliverable type,
special condition and complexity.
 Off-the shelf hardware and software. This part contains technical specification,
amount of the needs, particularly, data center equipment, centralized or individual
UPS systems, workstations, printers, scanners, network equipment, software and
office equipment.
 This part also contains requirements for inter-office connectivity, LAN as well as
Telecommunication network and equipment and the Consultancy has advised to
announce separate Supply and Service Bid these services.
 Required office equipmentare also listed in this document and the supplier has be to
delivering goods with basic installation and some trainings.
194
2. OBJECTIVE
The core element of the technical improvements will be the centralized database hosted by a
modern datacenter build on the latest hardware technologies like blade servers, SAN (Storage
Area Network), back-up libraries and more. Property Registration information will be submitted,
stored and distributed electronically. The national, web-based registry system will be accessible
through virtual registries at aimag levels. Advantages will include the national data center in
Ulaanbaatar and a second data center, as a disaster recovery site, to allow property registrations to
be initiated without regard to location, and to access information concerning property rights at
any location and from any location in Mongolia as well as to assure the full continuity of the
process.
The use of modern IT technology (hardware and software) and in particular web based registry
system will allow Mongolian citizens, companies and local and international investors to
approach the database and obtain reliable information.
195
3. REQUIRED ACTIONS FOR THE SUPPLIER

In order to fulfill the objective and to ensure the technical specification as well as the quality to
fully meet with the requirements, the winning Supplier shall take following (but not limited to)
actions:
 In order to fully understand the requirements and not to cause any misunderstandings
or any mistakes, the supplier should be in close contact with BlomInfo A/S Mongolia,
MCA-M and GASR;
 All software licenses, hardware warrantees, and followed services should be
contracted with GASR. So, in this regard, the contractor should cooperate with GASR;
 BlomInfo A/S’ responsibility will be overseeing the supply process and for doing that
it will need regular progress update from the supplier. So, the supplier should be
reporting to BlomInfo A/S and to MCA-M routinely;
 In order to install the equipment in local offices, the supplier would need to travel to
local offices and test the equipment and software performance on site;
 The detailed installation plan should be developed before the delivery of the goods
and shall be complied with during the installation;
 After installation and testing of all installed software, hardware and office equipment,
the supplier should hand over the deliverables to BlomInfo A/S as well as GASR and
report to MCA-M;
 Also, the supplier should be responsible for all after sale supports (replacing broken
equipment etc.) and this regulation should be contracted between MCA-M and the
supplier;
 The supplier shall provide required trainings after installation and testing the
equipment and software at sites. The training plan and content should be developed by
the supplier after having advised with BlomInfo A/S and MCA-M.
196

In order to fulfill the requirements, the winning bidder should complete following tasks that have
split in to performance periods.
4.1 Planning period
 The winner should prepare its Work plan and Delivery/Installation Plan and have
them accepted by MCA-Mongolia and GASR;
4.2 Delivery and installation period

 The supplier should start delivering and installing goods following its plans, under
coordination of the BlomInfo A/S;
 In this step, the goods shall be tested and prepared for the roll-out.
4.3 Operation and monitoring period by BlomInfo A/S

 In this step, all the system components shall be running having harmonized with the
ePRS;
 The performance results shall be evaluated and taken required actions;
 Fully operational system shall be received by GASR.
4.4 Warranty period

In this period the Supplier shall be responsible for any failures that are not caused by the users.
197
5. GENERAL TECHNICAL REQUIREMENTS

5.1 Language Support:
All information technologies must provide support in Mongolian language. Specifically, all
display technologies and software must support the ISO 10646 character set.
5.2 Dates:
All information technologies MUST properly display, calculate, and transmit date data,
including, but not restricted to 21st-Century date data.
5.3 Electrical Power:
All active (powered) equipment must operate on the following voltage range, 220V +/- 20V and
frequency range, 50Hz +/- 2Hz. All active equipment must include power plugs standard in
Mongolia.
5.4 Environmental:
Unless otherwise specified, all equipment must operate in environments of 10-30 degrees
centigrade (50° to 95°F) with a maximum temperature gradation of 10 degrees centigrade per
hour, 20-80 percent relative humidity with a maximum humidity gradation of 10% per hour,
altitude range between -16 and 3048 meters (-50 to 10000 feet) and 0-40 grams per cubic meter
of dust.
5.5 Safety:
Unless otherwise specified, all equipment must operate at noise levels no greater than 55dB(A).
198
6. COMPUTING HARDWARE SPECIFICATIONS

6.1 Data center hardware:
6.1.1 Server chassis for blade servers

The server chassis (enclosure) MUST meet, at a minimum, the following specifications:
Format Rack-able, maximum 10U, Rack mounting kit included

Blade servers Support for 16 x86 blade servers (half-height) or 8 x86 full-height blade servers with the
possibility to intermix them in any way
Availability Internal modules must be connected thorough a high-availability mid-plane with hot-
swap support for all blade servers, management and I/O modules
Power Sources Minimum 6 2700W, 200-240V, power sources, capable to power the entire chassis filled
with servers with N+N, N+1 or N+0 redundancy levels
Ventilation system Minimum 9 hot pluggable fans installed inside the chassis interleaved with I/O modules,
capable of cooling all its internal components
Chassis I/O modules Support for a minimum of 6 I/O modules and 3 redundant connections accommodating
modules for Ethernet switch/pass-through, Fiber Channel switch/pass-through and QDR
Infiniband connectivity
Storage network 8Gbps Fiber Channel switch modules with the following minimal specifications:
connectivity - a minimum of 16 internal 8Gbps Fiber Channel ports per switch for connecting all the
internal blade servers
- a minimum of 8 external 8Gbps Fiber Channel ports per switch for connecting to the
external Fiber Channel network
Ethernet network 1Gbps or 10Gbps pass-through modules
connectivity
L2/L3 Gigabit Ethernet switch modules, with the following minimal specifications:
- a minimum of 32, 1Gbps internal port per switch for connecting all the internal blade
servers
- a minimum of 16, 1Gbps external ports per switch for external IP network connectivity
- a minimum of 2, 10Gbps external ports per switch for external IP network connectivity
- a minimum of 2 stacking external ports per switch for stacking of up to 12 switches
L2/L3 10Gbps Ethernet switch modules, with the following specifications:
A minimum of 16, 10Gbps internal ports per switch module for connecting all the
internal blade servers
A minimum of 8, 10 Gbps external ports per switch for external IP network connectivity
supporting both SFP+ optical fiber modules and Twinax copper cables
Frontal management Frontal LCD panel for the management of the blade servers, chassis and information and
panel troubleshooting modules
2 USB ports and a video port for the local console, capable to manage the blade servers
infrastructure
Management Dedicated redundant management module with the following specifications:
-secure interface for inventory, configuration, monitoring and alerting for the chassis and
internal components
-power and temperature monitoring with power capping system and per slot
prioritization
Fan speed management for optimal cooling
Secure Web (SSL) and CLI (Telnet/SSH) interfaces
multiple permission levels support and user functions including
199
Microsoft Active Directory Services integration

2 x Ethernet ports + 1 serial port
integrated KVM able to manage all internal blade servers
Network and storage The chassis must provide the following features:
management Replacement (including by repositioning in a different server slot inside the same
chassis) or upgrade of the servers with Ethernet, iSCSI or Fibre Channel controllers
without affecting the LAN/SAN configuration. This must be possible without the need
to reconfigure DHCP servers, MAC based licensing schemes or SAN zoning
Total independecy from the cards on the internal blade servers
ability to assign WWN/MAC values to blade slots in place of factory-assigned
WWN/MAC
ability to provision a unique pool of min 2500 MACs or WWNs (WWNs derived from
MAC addresses)
Web and CLI centralized management
Server management The offering must include a software solution capable of blade servers install, reinstall
and provisioning without administrator intervention on individual servers (rip & replace)
Warranty Up to 2 years on site – 4 hour mission critical SLA
The information access must be provided directly 24x7x365 by the manufacturer
through a global assistance call center with abilities to monitor on-site resolution
activities with concurrent pro-active event and communications management.
Event management will include event escalation for quick resolution through a single
point of contact in manufacturer’s organization for incident management, special event
escalation and status monitoring for events, according to the hardware attached services
description.
Product availability The manufacturer must guarantee the availability of the products for duration of time
equal at least to the warranty period.
Integration with the The server chassis must be fully integrated with the rest of the proposed data center
other hardware hardware (e.g. server blades, SAN system, UPSs, etc)
components from data
center
Number of pieces: 2
6.1.2 Blade servers
The blade server MUST meet, at a minimum, the following specifications:
Processor 2x CPU Quad Core technology (2.66 GHz), Xeon 5000 sequence similar or better
Note: Processor MUST have instruction set on 64 bit, Virtualization technology and
MUST meet the hardware requirements for failover clustering installation
Standard memory 16 GB, ECC DDR3
(RAM) Up to 32 GB
Note: Memory MUST be installed in pair
Internal storage Hot Plug SAS - 292GB SAS (2x 146GB) OR Hot Plug SATA - 1 TB SATA (2x 500 GB)
Controller HDD RAID 0, 1, 10 capable
Communication 2 Gigabit Ethernet NICs with failover and load balancing TOE (TCPIP Offload Engine)
Boot from SAN (iSCSI and FC) supported
I/O Card options 1Gb and 10Gb Ethernet
10 Gb Enhanced Ethernet
Fibre channel: Dual-Port
Infiniband
Video Integrated video controller
Management KVM Virtual
200
Virtual control for "Power" button

LEDs for system state
Remote management
Supported operating Microsoft® Windows® Essential Business Server 2008
system Microsoft Windows® Server 2008 R2, x64 (includes Hyper-VTM v2)2
Microsoft® Windows® HPC Server 2008
Novell® SUSE® Linux Enterprise Server
Red Hat® Enterprise Linux
Sun® SolarisTM
Warranty and support 2 years on site – 4 hour mission critical SLA (Service Level Agreement), 24 hours for
solving the problem
Number of pieces: 8 (5 in live data center - 2 for Web-Server, 2 for Database-Server, 1 for
monitoring and management Server; 3 in disaster recovery location - 1 for Web-Server, 1
for Database-Server, 1 for monitoring and management Server)
6.1.3 SAN (Storage Area Network)
- The SAN MUST meet, at a minimum, the following specifications:
Drives and capacity 3.5-inch SAS or SATA hot-pluggable hard drives, at speeds of 5.4K, 7.2K, 10K or 15K
2.5 inch SAS, SSD (Solid State Drive) and Near-line SAS
Possibility to mix drives to create tiered-storage environment
Total capacity of minimum 20 TB raw installed
Scalable to at least 96 TB RAW (with expansion enclosures)
SAS Drives
15,000 RPM SAS drives available in 73GB, 146GB, 300GB, 450GB and 600GB
10,000 RPM SAS drives available in 300GB, 400GB or 600GB
Nearline SAS (7,200 RPM) drives available in 500GB, 750GB or 1TB
SSD Drives available in 149GB
SATA Drives
7,200 RPM SATA II drives available in 250GB, 500GB, 750GB or 1TB
Energy efficient SATA II (5,400 RPM) drives available in 1TB and 2TB
Connectivity At least four 1 Gb Ethernet ports per controller
Storage Controllers and Dual controller
RAID Levels Support for RAID levels 0, 1, 10, 5, 6
Management Internal (dedicated) storage management that allow a centralized management for
additional similar equipment
Back-Panel Connectors At least the following type of connectors: RJ-45 1Gb Ethernet for host connectivity,
6Gb SAS for drive expansion, RJ-45 1Bb Ethernet for remote management; PS/2 Serial
service, port for connecting to Tape Library (see 2.1.1.5)
Supported Operating Microsoft Windows Server Standard/Enterprise/Data Center/Web/Storage 2008
Systems x86/x64
Microsoft Windows 2003 32-bit Standard Server and Enterprise Edition
Virtualization Hosts (Citrix XenServer Retail Edition, VMware ESX/ESXi, Microsoft
Hyper-V Server R2 2008)
Microsoft Windows 2003 64-bit Edition
Red Hat Linux
SUSE Linux Enterprise Server
Microsoft Windows 2003 32-bit 2 node clusters
Microsoft Windows Storage Server 2003
Protocols Allow application to access stored data using standard protocols: CIFS, NFS, FTP,
201
HTTP
Warranty and support 2 years on site – 4 hour mission critical SLA (Service Level Agreement), 24 hours for
solving the problem
Local replication Support for local volumes (LUN) replication both snapshot and clone
Remote replication Support remote replication between 2 identical storages (or same class storages), for the
whole stored capacity, in synchronous and asynchronous mode. The remote replication
should be realized in native mode directly from equipment.
Monitoring Monitoring, management and maintenance possibility with system state and faulty
issues reporting
Quality of service Support for prioritize for specific application to access the system resources for certain
periods of time
Accessories 2 switches for SAN internal network to cover the connections redundancy
all additional needed accessories to assure the system running on best performances
Availability Firmware, software and hardware upgrades should occur without stopping the system
Full redundancy for hardware components (controllers, power sources and fans - hot
swap technology)
Number of pieces: 2
6.1.4 Rack and accessories
The Rack MUST meet, at a minimum, the following specifications::
Height (Racks Units) 42 U

Pre-installed kits Earthed kit, KVM switch with at least 8 ports (fully equipped), 1U console with
Monitor, Mouse and Keyboard
UPS the needed power supply for all hardware installed in rack (servers, SAN, chassis, etc.),
capable to sustain the whole rack for at least 15 minutes
Number of pieces: 2
6.1.5 Backup solution (tape library)
i) Tape drive.
The minimum requirements MUST be:

Tape Backup ‐ LTO3-060, LTO3, LTO4 and LTO5
Technology
‐ SCSI, SAS, FC, iSCSI
Drive controllers
‐ supported
Partitioning
‐ Up to 4 LTO5 6Gb SAS Drives with 48 Slots
Library configurations ‐ Up to 4 LTO5 FC8 Drives with 48 Slots
‐ Operator Control Panel and Remote Web Management

Management
‐ Standard
Barcode reader
‐ Max 4U form factor
‐ Rack mount standard (desktop conversion kit included)
Chassis
‐ Orientation: horizontal only
202
‐ Backup software included (full use with at least 1 year maintenance included)
Software
Number of pieces: 2
ii) Tapes
Tape Type LTO5

Capacity 2-3 times than SAN size
6.1.6 Monitoring system for Data center physical area
The monitoring system MUST meet the following minimum requirements:
‐ Rack mounted size (up to 2U)

‐ Built-in Uninterruptable Power Supply (UPS)
Hardware
‐ Ethernet port (RJ-45, 10/100 Mbps BaseTX)
‐ Internal and external sensors capability

‐ Wireless sensors capability (wireless sensor hub included)
Sensors ‐ Included sensors: temperature, humidity, flood, smoke, IP camera with motion
sensor, room entry sensor, panic button
‐ Full use license (with at least 1 year maintenance included)

Software
‐ Standalone Capability (No PC Required), Built-In Web Server, Built-In Web
Server Alert Methods (Email, SMS, SNMP, Web)
Connectivity and ‐ Compatible With SNMP Monitoring Applications
management ‐ Real-time digital temperature (Fahrenheit and Celsius), digital humidity (%
relative humidity)
Number of pieces: 1
Workstations:
6.1.7 State registrar workstation
- Minimum requirements MUST be:
Memory ‐ 3 GB DDR3-1066/1333

‐ Support for dual monitor configuration: digital outputs: 1, Analog outputs: 1
203

‐ Slots: Two PCI-e x8 slot wired as x4, one PCI-e x16 Gen 1 graphics slot, Two
PCI slots
‐ Standard I/O ports: 11 USB 2.0 (two on front panel, six on back panel, three
internal (UDOC) on motherboard), 1 eSATA rear, 1 serial, 1 parallel, 2 PS/2, 1
RJ-45, Stereo line-in and headphone line-out on back panel, Microphone and
headphone connector on front panel
Storage Devices ‐ DVD+/-RW, USB Floppy Drive and/or USB media card reader


Col1 Col2 Col3 Col4

Senior Registrars State registrars TrainingCenter
Ulaanbaatar 5 54 70
Baganuur - 1 -
Darhan-Uul - 5 -
Dornod - 2 -
Zavhan - 3 -
Orkhon - 3 -
Ovorhangai - 3 -
Hovd - 7 -
Hentii - 3 -
Tov - 4 -
Total (Col2+Col3) 160
204
6.2 Accountant workstation

Memory ‐ 3 GB DDR3-1066/1333


‐ Slots: Two PCI-e x8 slot wired as x4, one PCI-e x16 Gen 1 graphics slot, Two
PCI slots
‐ Standard I/O ports: 11 USB 2.0 (two on front panel, six on back panel, three
internal (UDOC) on motherboard), 1 eSATA rear, 1 serial, 1 parallel, 2 PS/2, 1
RJ-45, Stereo line-in and headphone line-out on back panel, Microphone and
headphone connector on front panel
Storage Devices ‐ DVD+/-RW, USB Floppy Drive and USB media card reader


205
6.2.1 Laptops
Memory ‐ 4 GB DDR3
Video card ‐ Memory size: 512 MB GDDR3

‐ Dedicated video card (non-shared memory)
Display ‐ 15.6" (1920 x 1080 @ 60Hz)
Hard drive ‐ 500 GB SATA (7200 RPM)
Connectivity ‐ Gigabit Ethernet network adapter

‐ Wireless LAN (802.11a/b/g/n)
‐ Bluetooth
Ports, Slots and Chassis ‐ Ports:

Network connector (RJ-45),
‐ USB 2.0 (4) – 3 USB 2.0 standard, 1 USB/eSATA combo
Microphone jack, Headphone/speaker out
IEEE 1394, 6-in-1 card reader, 34 mm ExpressCard or Type I/II PCMCIA
Docking Connector, VGA, DisplayPort
SmartCard Reader
‐ Slots:
6-in-1 card reader; PCMCIA or ExpressCard 54
‐ BayModular:
‐ 8X DVD+/-RW
Multimedia ‐ High Quality Speakers, Stereo headphone jack, Microphone jack and
integrated, noise reducing microphone
‐ Integrated webcam
Power ‐ Battery Supply: 6-cell (60Wh) Lithium Ion high capacity battery
‐ Power Supply: AC adapter
Mouse ‐ Wireless mouse, scrolling wheel
Carrying Case ‐ 15.6" backpack or case
Col1 Col2 Col3 Col4 Col5

Head of Head of IT Deputy IT IT Specialists
206
GASR(inc.
training center)
Ulaanbaatar 6 1 1 7
Baganuur 1 - - -
Bayanzurkh 1
Chingeltei 1
Songino Khairkhan 1
Darhan-Uul 1 - - -
Dornod 1 - - -
Zavhan 1 - - -
Orkhon 1 - - -
Ovorhangai 1 - - -
Hovd 1 - - -
Hentii 1 - - -
Tov 1 - - -
Total
27
(Col2+Col3+Col4+Col5)
6.2.2 Uninterruptible Power Supply (UPS)

- The minimum required technical specifications MUST be:
Topology ‐ line-interactive ; pure sine wave
Output Power Capacity ‐ 670 Watts / 1000 VA
Max Configurable Power ‐ 670 Watts / 1000 VA
Nominal Input Voltage / Input Frequency ‐ 230V / 50-60 Hz +/- 3 Hz (auto sensing)
Output Voltage Note ‐ Configurable for 220 : 230 or 240 nominal output voltage
Output Connections ‐ 8 - IEC 320 C13
Output Voltage Distortion ‐ Less than 5% at full load
Autonomy on load 100% / 50% ‐ 6,1 minutes / 20,6 minutes
Interface Port(s) ‐ DB-9 RS-232, Smart Slot, USB
Input voltage adjustable range for mains ‐ 160-286V

operation
Typical recharge time ‐ 3 hour(s)
Operating Environment ‐ Operating Environment
Warranty ‐ 2 years standard warranty: repair or replace
Number of pieces: 80 (one for each state registrars wks from the 8 aimags (31 pieces), 1 for
each accountant workstations (9 pieces), 40pcs for district offices;
6.2.3 Building 1 Centralized UPS devices
207
- The minimum required technical specifications MUST be:

Topology ‐ Double conversion or delta conversion
Output Power Capacity ‐ 70KW
Nominal Output voltage, frequency ‐ 380V 3PH, 50Hz
Backup time ‐ 30mins at 70KW load
Battery ‐ Maintenance free VRLA, deep cycle type
Output Voltage THD (Total Harmonic ‐ <3%

Distortion)
Output Power Factor ‐ 0.9
Efficiency ‐ 94%
Waveform type ‐ Sine wave
Input / Output wiring ‐ 3PH + N + PE/G
Input voltage ‐ +/- 20% of the nominal
Dual input ‐ Preferred
Communication ‐ Ethernet, Web interface, SNMP
Static and maintenance bypass: ‐ Required
Generator compatibility: ‐ Required
Compliance ‐ IEC 62040-3
Wall sockets ‐ Should be distinguished by the color
Installation ‐ The Supplier shall deliver full installation of the system
6.2.4 Building 2 Centralized UPS devices

The minimum required technical specifications MUST be:
Topology ‐ Double conversion or delta conversion
Output Power Capacity ‐ 20KW
Nominal Output voltage, frequency ‐ 380V 3PH, 50Hz
Backup time ‐ 30mins at 70KW load
Battery ‐ Maintenance free VRLA, deep cycle type
Output Voltage THD (Total Harmonic ‐ <3%
208
Distortion)
Output Power Factor ‐ 0.9
Efficiency ‐ 94%
Waveform type ‐ Sine wave
Input / Output wiring ‐ 3PH + N + PE/G
Input voltage ‐ +/- 20% of the nominal
Dual input ‐ Preferred
Communication ‐ Ethernet, Web interface, SNMP
Static and maintenance bypass: ‐ Required
Generator compatibility: ‐ Required
Compliance ‐ IEC 62040-3
Wall socket ‐ Should be distinguished by the color
Installation ‐ The Supplier shall deliver full installation of the

system
6.3 Shared Output and Input Devices:

Unless otherwise specified, all shared output and input devices must be capable of handling A4
and A3 standard sized paper.
6.3.1.1. Printers:
i) Multifunctional A3 b/w - the minimum required technical specifications MUST be:
General ‐ Copy/print speed: 40 ppm
‐ Formats supported: A6R-A3+, banner (120cm length) from bypass, A5R-A3
from cassette feeding
‐ Paper capacity: 2 x 550 (trays), 100 by bypass
‐ Duplex (standard), A5R-A3 64-200 g/m2
‐ Paper type: 64 – 200 g/m2 Bypass, 64 – 200 g/m2cassette feeding and
duplex
‐ Duplexing: standard automatic
‐ HDD: 60 GB SATA
‐ Memory: 1 GB
‐ Interface: Ethernet (100Base-TX/10Base-T), USB2.0
Copying ‐ First copy time: 5 sec

‐ Resolution: 600 x 600 dpi 10 bit
‐ Zoom: 25-400%
209
‐ Multiple copies: 1-999
Printing ‐ Standard
‐ Resolution: Data Process: 1200dpi x 1200dpi (Text/Line only), 600dpi x
600dpi
‐ Compatible PCL6, Postscript level 3
Scanning ‐ Scan speed: 70ipm 300dpi (Color/B&W) with ADF

‐ Scan resolution: 100dpi, 150dpi, 200dpi, 300dpi, 400dpi, 600dpi
‐ Destinations: e-mail, PC
‐ File format: Single Page: TIFF, JPEG, PDF
Multi Page: TIFF, PDF
Additional features ‐ ADF included: Paper size - A3, A4, A4R, A5, A5R, max number of originals -
100 Sheets (80g/m2)
‐ Authentication: LDAP, SMTP
Operating system ‐ Windows, Mac OS, Solaris, Linux, Unix
Warranty ‐ Minimum 2 year
ii) Office printer - minimum required technical specifications MUST be:

General ‐ print speed: up to 40 ppm
‐ Formats supported:
‐ Cassette:
A4, B5, A5, A6, LGL, LTR, Executive, 16K, 8.5"×13", Custom sizes:
Width 105.0～215.9mm x Length 148.0～355.6mm
Multi-purpose tray:
A4, B5, A5, A6, LGL, LTR, Executive, 16K, 8.5"×13",Custom sizes:
Width 76.2～215.9mm x Length 127.0～355.6mm
‐ Paper capacity: 500 (input tray), 100 (multi-purpose tray)
‐ Automatic double-sided printing
‐ Duty cycle: up to 100,000 pages per month
‐ Memory: 128 MB
‐ Interface: Ethernet (100Base-TX/10Base-T), USB2.0
‐ Energy efficient
Media Weights ‐ Cassette: 60 to 120 g/m²

‐ Multi-purpose tray: 60 to 199 g/m²
Printing ‐ Standard
‐ Resolution: Up to 600 x 600 dpi
‐ Compatible PCL6, PCL 5e, Postscript level 3
Operating system ‐ Windows, Mac OS, Solaris, Linux, Unix
Warranty ‐ Minimum 2 year
210
6.3.1.2. Scanners
The scanners MUST have the capability of 400 to 800 dots per inch (dpi). The scanners being
provided by the contractor MUST scan according to customer needs in bi-tonal (black-and-
white), grey-scale, or color. The scanners MUST also accommodate single- or double-sided
scanning.
scanner provided by contractor MUST support these formats and must include the software for
processing documents in these formats.
The scanner MUST include proprietary scanning software. This software offered by the
contractor should have on-screen displays that will enable the operator to make the image setting
adjustments necessary to optimize the scanner’s output. The scanner operator should be able to
identify and rectify quality issues such as miss-feed pages, poor image contrast, and incomplete
images. If the scanner operator catches errors during this step, he or she can adjust the scanner’s
settings to respond to the changing document conditions and sizes, and then rescan the
documents immediately.
Scanner Type ‐ Flatbed/ADF
Daily duty cycle ‐ At least 10000 pages
Scan Size ‐ Between 2 in x 3 in - 11 in x 17 in
Optical Resolution ‐ At least 600 dpi
Output Resolution ‐ At least 100/150/200/240/300/400/600 dpi
Scanning Speed ‐ letter, color, black and white, grayscale, 200 dpi: at least 50 ppm
‐ color 24-bit duplex: at least 50 ppm
Scan media ‐ Paper (plain, inkjet, photo), envelopes, cards (index, greeting),
Scan File Format ‐ PDF (formatted Text and Graphics, normal with images, searchable image
over text, MRC, PDF/A), TIFF (single page, multi-page, compressed), JPG,
BMP, PNG, DOC, RTF, TXT, WPD, XLS, HTM, OPF, UNICODE, XML,
XPS
Connectivity ‐ Standard High-Speed USB 2.0, optional SCSI
Compatible operating ‐ Microsoft Windows

system
Warranty ‐ At least 2 years manufacture warranty
Features ‐ Automatic color detection, content-based rotation, blank page deletion, double
feed detection, barcode detection
Additional Document ‐ Kodak Capture Pro or Kofax Capture included

Imaging Software ‐ Full use license software with at least 1 year maintenance
Number of pieces: 3
211
Follow: The contractor will follow ANSI/AIIM MS44-1998, “Recommended Practice for
Quality Control of Image Scanners,” to ensure scanner quality control and continued maintenance
of an established level of quality; ANSI/AIIM MS53-1993, “Recommend Practice; File Format
for Storage and Ex-change of Image; Bi-Level Image File Format: Part 1,” and ANSI/AIIM
TR19-1993, “Electronic Imaging Display Devices,” for selecting imaging devices; and
ANSI/AIIM TR26-1993, “Resolution As It Relates to Photographic and Electronic Imaging,” for
evaluating photographic and electronic imaging products. In addition, we recommend consulting
the NARA and Digital Library Federation websites for guidelines and best practices regarding
document scanning.
6.3.1.3. Smart Card Reader eID

Host Interface ‐ USB 2.0 CCID, also compliant with USB 1.1
‐ Transmission speed 12 Mbps (USB 2.0 full speed)
‐ Power supply: Bus powered
Standards ‐ ISO 7816
‐ EMV2 2000 Level 1
Protocols ‐ T=0, T=1,
‐ 2-wire: SLE 4432/42 (S=10),
‐ 3-wire: SLE 4418/28 (S=9),
‐ I2C (S=8)
Card size ‐ ID-1 full size
‐ 3.370" x 2.125" (85.60mm x 53.98mm)
Smart Card interface ‐ 420Kbps
speed
Smart Card clock ‐ Up to 8MHz
frequency
Supported card types ‐ 5V, 3V and 1.8V Smart Cards
‐ ISO 7816 Class A, AB and C
Power to Smart Card ‐ 60mA
Smart Card detection ‐ Movement detection with auto power-off
‐ Automatic Detection of smart card type
‐ Short circuit and thermal protection
8 Pin handling ‐ C4 / C8 supported
Supported APIs ‐ PC/SC driver (ready for 2.01)
‐ CT-API (on top of PC/SC)
‐ Synchronous-API (on top of PC/SC)
‐ OCF (on top of PC/SC)
6.4 Network and Communications Specifications

6.4.1 Local Area Network(S):
6.4.1.1. Equipment and software:
212
i) Switch 48 ports - minimum required technical specifications:

Port attributes ‐ 48 10/100/1000BASE-T auto-sensing Gigabit Ethernet switching ports
‐ 4 SFP combo ports for fiber media support
‐ 10 Gigabit Ethernet uplink modules
‐ 48Gbps Stacking module
‐ Auto-negotiation for speed, duplex mode and flow control
‐ Auto MDI/MDIX
‐ Port mirroring
‐ Flow-based port mirroring
‐ Broadcast storm control
Performance ‐ Switch Fabric Capacity up to 184 Gb/s

‐ Forwarding Rate up to 95 Mpps (Mega packets per second)
‐ Up to 8,000 MAC Addresses
Management ‐ Web-based management interface

‐ Industry-standard CLI (Command Line Interface) accessible via Telnet or
LocalSerialPort
‐ 4 RMON groups supported (history, statistics, alarms and events)
‐ TFTP transfers of firmware and configuration files
‐ Dual Firmware images on-board
‐ Multiple Configuration file upload/download supported
‐ SNMPv1, SNMP v2c and SNMPv3 supported
‐ Statistics for error monitoring and performance optimization including port
summary tables
‐ BootP/DHCP IP address management supported
‐ Syslog remote logging capabilities
‐ Temperature sensors for environmental monitoring
QoS (Quality of Service) ‐ Layer 2 Trusted Mode (IEEE 802.1p tagging)

‐ Layer 3 Trusted Mode (DSCP)
‐ Layer 4 Trusted Mode (TCP/UDP)
‐ Advanced Mode using Layer 2/3/4 flow-based Policies, including
metering/rate limiting, marking and bandwidth guarantees; up to 100 ACLs
can be used for QoS flow identification via Class-maps
‐ 8 Priority Queues per Port
‐ Adjustable Weighted-Round-Robin (WRR) and Strict Queue Scheduling
‐ Port-based QoS Services Mode
‐ Flow-based QoS Services Mode
Security Options ‐ IEEE 802.1x based edge authentication -- supports single and multiple host
access, guest access, voice authorization, and Microsoft Active Directory
‐ Switch access password protection
‐ User-definable settings for enabling or disabling Web, SSH, Telnet, SSL
management access
‐ Port-based MAC Address alert and lock-down
‐ IP Address filtering for management access via Telnet, HTTP, HTTPS/SSL,
SSH and SNMP
‐ RADIUS and TACACS+ remote authentication for switch management access
‐ Up to 100 Access Control Lists (ACLs) supported; up to 12 Access Control
213
Entries (ACEs) per ACL

‐ SSLv3 and SSHv2 encryption for switch management traffic
‐ Management access filtering via Management Access Profiles
Warranty ‐ Minimum 2 years manufacturer warranty
Number of pieces: 6
ii) Switch 24 ports - minimum required technical specifications:
Port attributes ‐ 24 10/100/1000BASE-T auto-sensing Gigabit Ethernet switching ports
‐ 4 SFP combo ports for fiber media support
‐ 10 Gigabit Ethernet uplink modules
‐ 48Gbps Stacking module
‐ Auto-negotiation for speed, duplex mode and flow control
‐ Auto MDI/MDIX
‐ Port mirroring
‐ Flow-based port mirroring
‐ Broadcast storm control
Performance ‐ Switch Fabric Capacity up to 136 Gb/s

‐ Forwarding Rate up to 95 Mpps (Mega packets per second)
‐ Up to 8,000 MAC Addresses
Management ‐ Web-based management interface

‐ Industry-standard CLI (Command Line Interface) accessible via Telnet or
LocalSerialPort
‐ 4 RMON groups supported (history, statistics, alarms and events)
‐ TFTP transfers of firmware and configuration files
‐ Dual Firmware images on-board
‐ Multiple Configuration file upload/download supported
‐ SNMPv1, SNMP v2c and SNMPv3 supported
‐ Statistics for error monitoring and performance optimization including port
summary tables
‐ BootP/DHCP IP address management supported
‐ Syslog remote logging capabilities
‐ Temperature sensors for environmental monitoring
QoS (Quality of Service) ‐ Layer 2 Trusted Mode (IEEE 802.1p tagging)

‐ Layer 3 Trusted Mode (DSCP)
‐ Layer 4 Trusted Mode (TCP/UDP)
‐ Advanced Mode using Layer 2/3/4 flow-based Policies, including
metering/rate limiting, marking and bandwidth guarantees; up to 100 ACLs
can be used for QoS flow identification via Class-maps
‐ 8 Priority Queues per Port
‐ Adjustable Weighted-Round-Robin (WRR) and Strict Queue Scheduling
‐ Port-based QoS Services Mode
‐ Flow-based QoS Services Mode
Security Options ‐ IEEE 802.1x based edge authentication -- supports single and multiple host
access, guest access, voice authorization, and Microsoft Active Directory
‐ Switch access password protection
‐ User-definable settings for enabling or disabling Web, SSH, Telnet, SSL
214
management access
‐ Port-based MAC Address alert and lock-down
‐ IP Address filtering for management access via Telnet, HTTP, HTTPS/SSL,
SSH and SNMP
‐ RADIUS and TACACS+ remote authentication for switch management access
‐ Up to 100 Access Control Lists (ACLs) supported; up to 12 Access Control
Entries (ACEs) per ACL
‐ SSLv3 and SSHv2 encryption for switch management traffic
‐ Management access filtering via Management Access Profiles
Warranty ‐ Minimum 2 years manufacturer warranty
Number of pieces: 12 (one for each local office)
iii) Manufactory molded patch cords

Features ‐ Description
Shielded CAT 6 ‐ TIA/EIA 568A T568B Wired

550MHz, Patch Cord ‐ STP Shielded Twist Pair
‐ Foil Shield on individual Pair/Braid shield on 4 pair
‐ CM Type PVC Jacket
‐ 26AWG 4pair Stranded Copper Wire
‐ 50 Micron Gold Plated RJ45 Plug
‐ Molded Boot on Each End
Number of pieces:
1 foot – 500pcs
10 feet – 100pcs
15 feet – 80pcs
iv) Patch panel, Category 6 UTP, 24 port

Features Description
Electrical Data
Insulation resistant ≥ 500MΩ

Dielectric strength Contact / contact 1 kVrms, Contact / shield .5kVrms
Current carrying capacity ≥ 1A
Typical plug / jack contact resistance ≤ 20mΩ
Terminations
Typical IDC contact resistance
≤ 1mΩ
Number of re-terminations
≥ 30
Shield connection
Patented 360º shielding†
Conductor diameter
Patented 360º shielding†
Insulation diameter
0.7-1.6mm
Mechanical Data
Plug / jack mating cycles ≥ 750 (IEC / EN 60603-7 series)
Plug / jack insertion / withdrawal Force ≤ 20N (IEC / EN 60603-7 series)
215
Col1 Col2
LAN
Ulaanbaatar 14
Baganuur 1
Darhan-Uul 1
Dornod 1
Zavhan 1
Orkhon 1
Ovorhangai 1
Hovd 1
Hentii 1
Tov 1
v) Patch panel, 24 port

General
‐ Meet or exceed TIA and ISO Category 5 component performance requirements

‐ Provides RJ45 breakouts from 10/100BASE-T switches adn hubs that use the 25-pair "telco"
interface
‐ Compatible with Cisco hubs and switches
‐ Use with 25-pair plug to plug cable assemblies listed
‐ Cable assemblies listed are for use with this patch panel only
‐ 2U (3.5 inches) x 19 inches
Col1 Col2
Telecommunication
Ulaanbaatar 14
Baganuur 1
Darhan-Uul 1
Dornod 1
Zavhan 1
Orkhon 1
Ovorhangai 1
Hovd 1
Hentii 1
Tov 1
216
6.4.1.2. Cabling1:
All LANs (Central office buildings (1, 2 and 3) and districtoffices of UB and 8 aimags) MUST be
re-wired by total reengineering operation that implements structured cabling (based on
international standards - ISO/IEC 11801).
The cable to be used MUST be, at minimum, CAT 6 and MUST be installed for using gigabit
speed. The computer network outlets MUST be CAT 6 (RJ45). All plugs to be used MUST be
RJ45 standard.
The design of the LAN MUST be provided by the Bidder and the number of network outlets for
each room in GASR offices MUST be increased with 25% of the number of workstations to be
installed in that room. The cable length should be average 50 meters for each workstation
connected to the LAN.
All cables MUST be enclosed in PVC cable trays and MUST be lined at a minimum distance of
15 cm from any electric cable or electric source.
i) Category 6 LAN Cable
Cable standards General Entire wiring process shall follow TIA/EIA-568-B.2 standard;
Cable should meet with Category 6 standard;
LAN Topology shall be 1000 Base T;
the cable shall meet with 22 to 24 AWG copper standard which equals to 0.51–
0.65mm of copper diameter;
Wiring requirements Each cable run must be kept to a maximum of 90 meters, so that with patch cords, the
entire channel is no more than 100 meters;
Maintain the twists of the pairs as close as possible to the point of termination, or no
more 1.7centimeters, cm; Do not sharply bent, twist or kink the cable or do not use this
kind of cable. Because, this could cause transmission failure;
All cabling should be sheathed within metal/plastic conduit or trunk; The minimum
bend radius for Category 5e and 6 cable is about four times the cable diameter and it’s
approximately 2.5cms;
Leave at least 2 meters of extra slack at every end of the cables and it should neatly coil
up in the ceiling or nearest concealed place.
Quantity: cable quantity will be calculated by the contractor
ii) Telecommunication cable
Cable standards It’s advised to use Cat 5 cable for the telecommunication.
Quantity: cable quantity will be calculated by the contractor
iii) Jacks
1
For the LAN wiring the Contactor should follow the standards/requirements delivered together
with Architectural recommendations
217
Every node shall have outlets for communication and LAN, and the outlet shall be distinguished
by its different colors. The wall outlets shall be fixed at same level from the floor, particularly
between at 40-50cms from the floor.
a. Cat 6 LAN jack
Standards Meet or exceed ISO/IEC Category 6/Class E electrical performance specifications;
Quantity: jack quantity will be calculated by the contractor
b. Telephone jack
Standards Meet or exceed ISO/IEC Category 5/Class E electrical performance specifications;
Quantity: jack quantity will be calculated by the contractor
6.4.2 Wide-Area Network:

6.4.2.1. Equipment and software
i) Routers
IPsec IPsec standards supported include Digital Encryption Standard (DES), Triple DES
(3DES), and Advanced Encryption Standard; Rivest, Shamir, Aldeman (RSA)
algorithm signatures and Diffie-Hellman for authentication; and Secure Hash Algorithm
1 (SHA-1) or Message Digest Algorithm 5 (MD5) hashing algorithms for data integrity.
With the built-in cryptographic engine in the ESP, the Cisco ASR 1000 Series Routers
can deliver up to 7-Gbps IPsec throughput.
Hardware QoS A dedicated QoS chip within the QuantumFlow Processor facilitates traffic shaping and
policing functions for thousands of VPN spokes, as well as Low Latency Queuing
(LLQ) before and after cryptography, all aimed at preserving quality of voice and real-
time data.
Hardware IP Multicast A powerful multicore cryptography engine with an extensive 2-Gb buffer, along with
handling sophisticated full-circle back-pressure mechanisms between the cryptography engine
and process engine, solve historical burst problems associated with high-scale IP
Multicast.
VPN Features Easy VPN and Enhanced Easy VPN
Dynamic MultipointVPN (DMVPN)
Group Encrypted Transport VPN
Virtual Tunnel Interface (VTI)
VRF-aware IPSec
Integrated Threat IOS Zone-Based Firewall
Control FPM
NetFlow
NBAR
218
ii) Fiber optic service

Provided services 512kbps IP connectivity for local offices in the 8 regional centers and 4 districts;
5Mbps IP connectivity for UB central office;
Support and maintenance for the lines
Equipment Equipment for each site for making above mentioned connectivity
iii) Data centre services

Provided services Domain name for ePRS with at least 2 years’ service agreement;
Rack renting service with full service supports (24/7 maintenance, monitoring);
Connectivity between Data centre and GASR central office;
Equipment Required equipment for each site
6.4.3 Telecommunications Services:

i) VOIP/FOIP supporting router
Call Control Protocols •SIP2 (RFC3261)
Compliance •SIP1 (RFC2543)
Voice Compression •G.711 (A-law and u-law), G.723.1, G.726, G.729a
Analog Voice Ports •Type: Loop-Start FXS interfaces•DTMF tone detection/generation•V.21/V.25
Modem/Fax tone detection•Echo Cancellation: G.168
Ethernet Ports •WAN/LAN: 10/100 Auto MDI/MDI-X Ethernet ports•IEEE 802.3 10BASE-T
Ethernet compliance•IEEE 802.3u 100BASE-TX Fast Ethernet compliant
Device Management • Manage functions through an intuitive Web-based graphical user interface
Number of Ports • One 10/100BASE-T Ethernet port (WAN)
• Four 10/100BASE-TX Fast Ethernet port (LAN)
• Four loop-start FXS RJ-11 ports
Warrantee Minimum 2 years manufacturer warranty
ii) Central office PBX

Co line numbers Should support 8-16 co line inputs
Extension capacity At least 64 extensions should be generated
VOIP support VOIP/FOIP supported
Device Management
Device management software should be installed at the server and trained
Auto answer Automatic answering, addressing feature should be available
219
Number of pieces: 1
iii) Local office PBX

Co line numbers Should support up to 8 co line inputs
Extension capacity Up to 32 extensions should be generated
VOIP support VOIP/FOIP supported
Device Management
Device management software should be installed at the server and trained
Auto answer Automatic answering, addressing feature should be available
iv) Telephone and fax machine

The Supplier also should provide 70pcs of office telephone and 13pcs of fax machines.
6.4.4 Other office equipment:

i) Take-a-ticket machine
Features Requirements
Language Mongolian and English
Customer screen Touch screen LCD
Functions Shall be able to choose service types
Warrantee At least 3 years’ warranty
Number of pieces: 3
ii) Public addressing system for central office

Features Requirements
Paging Messages can be broadcast to one receiving device, or to pre-configured "groups" of
devices, or to all receiving devices for point-to-multipoint paging.
Intercom The "central" device in the security office can communicate over the IP network with
one or multiple devices installed in rooms, or a room could communicate directly with
the security office or even with other rooms or buildings, depending on the
configuration.
Installation The wireless connection is highly preferred
Warrantee At least 3 years’ warrantee
Number of pieces: 1
iii) Digital camera

Body type Point and shoot
Resolution 10.6 Megapixel or higher
Lens and Zoom 24-120mm
220
ISO ratings auto, 80, 100, 200, 400, 800, 1600, 3200
Built-in flash Yes
LCD display size 3” or bigger
Output and connection USB 2.0 Hi-Speed, Video output
ports
Battery type AA
Camera bag Yes
Number of pieces: 2
iv) Camcorder
LENS
Image Sensor (Total) 1/6" MOS
Image Sensor (Effective) 1.17 megapixels [16:9] [Motion Image]
F Value 1.17 megapixels [16:9] [Still Image]
Optical Zoom F1.8(WIDE)/2.8(TELE)
Digital Zoom 16x
Focal Length 40x-1000x
Filter Diameter 35mm 2.95-47.2mm
Film Camera 30.5mm
Equivalent 44.1-706mm [16:9]
MEDIA
Records Onto SD/SDHC Memory Card or DVDR
Recording Format MPEG4-AVC/H.264 (AVCHD standard compliant); JPEG (Still Image) or compatible
DVD formats
CAMERA
Image Stabilizer Advanced O.I.S. (Optical Image Stabilization) with Active Mode
Still Picture 2.1 Megapixel (1920 x 1080)
Recording:16:9
Shutter Speed: Motion 60i Auto Slow Shutter ON: 1/30-1/8000, OFF: 1/60-1/8000, 24P Auto Slow Shutter
Image ON: 1/24-1/8000, OFF: 1/48-1/8000
Shutter Speed: Still 1/2-1/2000, video flash: 1/2-1/500
Image
Minimum Illumination 9 Lux (1/30 Low Light Mode), 1 Lux (Magic Pix)
Focus
White Balance Auto/Manual
Iris Auto/Indoor1/Indoor2/Sunny/Cloudy/White Set
LCD Monitor Auto/Manual
Microphone 2.7" Wide LCD (230,400 pixels) or better
Speaker 2-ch Stereo, Zoom Microphone
On-Screen Display Dynamic type
Language English
Power supply
220V, 50/60Hz
Tripod yes
Camera bag Yes
Number of pieces: 2
v) Flat Screen TV
221
GENERAL
Model type Plasma
Power Supply AC 220V, 50Hz
TV System Multi
Menu Language English
VIDEO
Screen Size 58" Class (58.0" diagonal) or bigger
Contrast Ratio Native: 2,000,000:1
Aspect Ratio 16:9
Resolution (Number of 2,073,600 (1,920 x 1,080)
Pixels)
HDTV Display Yes
Capability (1080p,
1080i, 720p)
AUDIO
Speakers Full-range x 2 (L, R)
Audio output 20 W ( 10% THD ) or higher
INPUTS & JACKS
HDMI Input Yes
Composite Video Input 2
Audio Input (for Video)
PC Input 2
Component Video
Inputs (Y, PB, PR) 1
Audio Input (for 2
Component Video)
Digital Audio Output 2
Analog Audio Input (
for HDMI/DVI) 1
Yes
Number of pieces: 1
vi) LCD Projector

GENERAL
Power Consumption 18W or lower
Stand By
Menu Language
English
OPTICAL
Lamp hours 3000hrs or more
Light Output 2700 ANSI or higher
Screen size 30" to 300"
Projection distance 1.2m to 12.1m (Tele), 1.0m to 10.1m (Wide)
Contrast ratio 400:1
Resolution XGA
CONNECTION
USB port Yes
222
Video composite 1.0Vp-p/ Sync.negative, 75 ohm

Input video 1xRCA/1x S-Video
Networking and Wireless 802.11a/b/g module, ELPAP02, Optional
Wireless Features
Number of pieces: 3
vii) Simultaneous interpretation Equipment

TRANSMISSION SYSTEM
Model type Portable
Input At least 4 microphone inputs
Output More than 200 headphones outputs
Audio channel 4 or more
Frequency 20 Hz to 10 kHz (-3dB) at standard quality;
20 Hz to 20 kHz (-3dB) at perfect quality
Number of pieces: 2
viii) Wireless headphones

WIRELESS HEADPHONES
Model type Portable
Frequency 20 Hz to 10 kHz (-3dB) at standard quality;
20 Hz to 20 kHz (-3dB) at perfect quality
Power Supply Rechargeable battery
ix) Generators for local offices

Main type Self-exciting, 2-pole, field rotating type
Oil type Gasoline
Run time per tank At least 10hrs
Voltage regulation AVR
system
Output power 50Hz, 220-240V, at least 7,000Watt
Sound level 73dB(A)/7m or less
Number of pieces: 8
6.5 Software Specifications

6.5.1 System Software and System-Management Utilities:
6.5.1.1. Webserver-Tier:
Live Data center
Version Windows Server 2008 R2
Number of licenses 2
Mandatory tasks The operating system should be installed on both servers. Both servers should be
223
installed in a failover cluster.

The Internet Information Services should be installed on the failover cluster.
Disaster recovery location
Mandatory tasks The Internet Information Services should be installed on the server.
6.5.1.2. Database-Tier
Live Data center
Mandatory tasks The operating system should be installed on both servers. Both servers should be
installed in a failover cluster.
The database software server (from the ePRS technical specifications bid) should be
installed on the failover cluster.
Mandatory tasks The database software server (from the ePRS technical specifications bid) should be
installed on the server
6.5.1.3. Monitoring and management Tier

Live Data center
Mandatory tasks The operating system should be installed on server.
Mandatory tasks The operating system should be installed on server.
6.5.1.4. Workstations (desktops and laptops):

Unless specified in the hardware technical specifications, the operating system for workstations
should be latest version of Microsoft Windows.
General specifications MS Windows Professional latest version
Maintenance Minimum 2 year full maintenence and support
Number of licenses: 201
6.5.1.5. Tape library back-up software

- the minimum required technical specifications MUST be:
General specifications ‐ Should be available on various OS platforms such as Windows, Linux and
UNIX platforms and be capable of supporting backup / restores from various
platforms including Windows, Unix and Linux. Both Server and Client
224
software should be capable of running on all these platforms.

‐ Backup software must have built-in centralized, policy driven management
feature by which all Backup servers can be managed from central location
without any additional licenses.
‐ Ability to backup data from one platform and restore it from another (limited
to genera of operating systems (Unix to Unix, Windows to Windows) to
eliminate dependence on a particular OS machine and for disaster recovery
purposes.
‐ Software should support cross platform Device & Media sharing in SAN
environment.
‐ Software must have integrated true Disk Staging feature without requiring any
additional agent, wherein the backup continues to take place even when the
disk space allocated is full. The backup software must be intelligent enough to
flush out the data from the disk and migrate the same to the tape automatically
based on the user defined threshold & will not affect the backup operations.
‐ The Backup software must also be capable of reorganizing the data onto tapes
within the library by migrating data from one set of tapes into another, so that
the space available is utilized to the maximum. The software must be capable
of setting this utilization threshold for tapes.
‐ The Backup software must ensure rapid restoration during a recovery need, by
reducing the number of tapes to be mounted onto the drives in the library by
not taking repeated full backups.
‐ The backup software must support SAN based LANFREE Backup. The
migration from a LAN based backup to the LAN-FREE backup must only
effect purchasing/installing additional modules, and not warrant any
installation/licensing charges/changes on the base backup software.
‐ The Backup software should be able to integrate with the Flash copy feature of
the hardware and completely automate the flash copy based backup process.
‐ The licensing for the Backup software must be done in such a way that the
migration of operating systems and/or databases/mail servers of servers/clients
must not warrant a change in license. The licensing must be independent of
the server processor, whether it is RISC based or CISC based processors.
‐ The backup software must allow network-efficient backup of remote users’
data on WAN.
‐ The backup software must include encryption of the backed up data and even
on archived data.
‐ The Backup software must not have any restrictions on the number of drives
that can be attached in the tape library. There should be no additional licensing
if the number of tape drives is increased in order to reduce the backup
window.
‐ Should have cross platform Domain Architecture for User management.
‐ Ability to perform “Hot-Online” backup for different type of Databases such
as Oracle, MS SQL, DB2 etc. on various platforms.
‐ Software should have an inbuilt feature for Tape to tape copy feature (cloning,
within the tape library) to make multiple copies of the tapes without affecting
the clients for sending tapes offsite as part of disaster recovery strategy.
‐ Should support different levels of User access, Administrator, User, Operator,
so that only the authorized personnel can make changes or view the status
based on the rights they have.
‐ Should provide details logs on both the Clients as well as the Server to support
225
in advanced troubleshooting without any performance implications.

‐ Backup software must have inbuilt scheduling feature from centralized
console for automated data backup. Also must have capability like pre-
schedule & post schedule options to run specific job before & after the backup
Maintenance ‐ Minimum 2 year full maintenence and support
Monitoring software platform for servers, network and applications
General specifications ‐ provides the reporting, visualization, and analysis capabilities for the network,
applications and servers
‐ end-to-end monitoring solution that offers reporting, graphing, visualization,
and configuration features
‐ network management options (network discovery, traffic graphing, protocol
analysis, network map)
6.5.2 General-Purpose Software:

General specifications ‐ MS Office Professional latest version
6.6 System Management, Administration, and Security Specifications

In addition to the management, administration and security requirements specified in each section
covering various hardware and software components of the System, the System must also provide
for the following management, administration, and security features at the overall system level.
6.6.2 Technical management and troubleshooting:
6.6.2.1. Support before Acceptance and During Warranty
The Supplier MUST provide appropriate technical management and troubleshooting support
until the system is finally accepted for operation.
The Supplier MUST provide appropriate system management tools and documentation and
prepare the GASR for the respective takeover.
After the Final System Acceptance,the GASR will take over the responsibility for technical
management and troubleshooting announcement. The Supplier MUST have an established
support organization in Mongolia during the first sixty days after system acceptance and will
provide the technical support costs after warranty period within the Recurrent Costs.
In this context, the Supplier MUST state clearly its solution for maintenance and support, both
for the warranty and post-warranty periods.
226
The Supplier MUST demonstrate a spare parts distribution and warehousing system that would
have the capacity to provide continuing availability of necessary Original Equipment
Manufacturer (OEM) parts for use on the equipment being. The Supplier or its sub-contractors
may own, or have contracts for, secured warehouse adequate and suitably located to store parts to
serve the installation sites. The geographical locations of the warehousing capacity must
accommodate the service office structure in order to ensure continuing and timely availability of
required spare parts. The Supplier MUST provide the list of the spare parts and replacement
units, which are expected to be held on-site.
All equipment, software and facilities supplied through the Contract are required to be installed in
a period of six months from Contract commencement and maintained by the Supplier for the
warranty period.
Experienced staff MUST ensure under this Contract the local support for the products provided,
and the appropriate CV for this staff shall be provided.
6.6.2.2. Plan for Service and Maintenance
The Supplier shall submit a plan for having a service organization with adequate capacity to
provide continuing hardware and software warranty maintenance and repair with an
acknowledgment response by telephone within 24 hours in the main centers (UB and districts)
and 2 working days in the remote areas (Aimag Offices). In the plan, qualified service personnel
of the Supplier or sub-contractors must be shown to be stationed within reasonable commuting
distance of each County Site, with due consideration to local conditions.
The maintenance plan shall include identification of procedures for on-site and off-site
maintenance during normal hours of operation, for:
 Average time to arrive on-site at each system site;
 Mean time to repair major system components;
 Maintenance logs and Client official authorization;
User and usage administration:

For the required warranty period, the Supplier MUST provide system administration and user
support (help-desk). After warranty period a maintenance contract for further services may be
signed or the administration will be phased out to another organization.
6.6.3 Security:
6.6.3.1. Antivirus software should meet at least the following specifications:
General ‐ Real time virus detection, cleaning/quarantine.
‐ Heuristic scanning to allow rule-based detection of unknown viruses
‐ Facility of Quarantine Manager
‐ Scanning of compressed file archives in ZIP, ARJ and Microsoft Compressed
formats. Protection from viruses hiding in compressed files, such as internet
downloads and e-mail attachments
‐ Protection against spyware
‐ Proactive protection against zero-day threats.
‐ Facility of Vulnerability analysis tool
‐ Scanning of Removable media and Network Drives automatically in real-time
when accessed
227
‐ Central management console to centrally control desktop configurations,

including scanning and cleaning options.
‐ Centralized Audit trail logging and reporting capability with ability to
communicate the reports using email.
‐ Role based administration of the solution.
‐ Vulnerability Assessment tool to identify AV clients on a network
‐ Real-time lockdown of client configuration – allow or prevent users from
changing setting or unloading/uninstalling the software.
‐ Pattern file roll-back – shall be able to return to past pattern file if there is any
problem with the new pattern file.
‐ Automatic downloads of latest virus signature updates from the Internet to
desktops and servers, across different platform running Windows. The
distribution should happen seamlessly from a single management console
‐ Integration with Windows Active Directory.
‐ Remote deployment of Client software using Web- based
installation/Windows 2003 remote installation/Log-in script/Client Packager.
‐ Support for Windows XP Professional, Windows Vista, Windows 7, Windows
2003 Server, Windows 2008 Server
‐ Ability to force an update (PUSH) to client
‐ Application and Device control.
‐ Support for additional features like Desktop Firewall, Intrusion Prevention
System, etc.
6.6.3.2. Firewalls and intrusion prevention system

The minimum required technical specifications MUST be:
Items Qty. Required features Minimum technical
characteristics
1 Intrusion 1 -Proven in-line threat Ports: 8 RJ-45 auto-sensing
Prevention protection 10/100/1000 ports (IEEE
System -Proven reliability and 802.3 Type 10Base-T, IEEE
redundancy 802.3u Type
-Comprehensive traffic 100Base-TX, IEEE 802.3ab
flow inspection Type 1000Base-T);
-Broad network asset Duplex: 10Base-T/100Base-
protection TX: half or full;
-Traffic management 1000Base-T: full only
-Easy to manage Performance Latency:< 600 μs
IPS/IDS throughput:300Mbps
Network throughtput:300Mbps
Security contexts: 250,000
Connections per second: 18,500
Concurrent sessions: 1,000,000
Electrical Voltage: 100-240 VAC
characteristics Current: 6 / 3 A
Frequency: 50 / 60 Hz
228
Notes • IPS/IDS Throughput

represents the inspection
throughput levels measured
with recommended
security profiles.
• Network Throughput
represents the maximum
throughput levels that can be
achieved with the use
of traffic forwarding.
• Typical Latency is measured
on packet sizes up to
1518 bytes.
• Concurrent Network Sessions
is the maximum
number of concurrent network
sessions that can be
supported by the IPS.
• Security Contexts is the
maximum number of
sessions with security state that
can be supported by
the IPS.
2 Web 1 -Multiple inspection Throughput 1,000 Mbps
application layers Max HTTP
firewall -HTTP Protocol Trans/Sec 36,000
Validation Latency
-Data Leak Prevention
-Network and Platform Interfaces Sub-millisecond
Protection
-Unparalleled Accuracy 6 x 10/100/1000 Mbps
-Web 2.0 and Web (max 4 Fiber interfaces;
Services Protection Interface Types optional 10 Gbps interfaces)
-Automated Application
Learning Max Network Copper/Fiber SX/Fiber LX
-Application User Segments
Tracking
-Capable to protect Hard Drive (2)Bridge; (5)Router,
against many application Non-inline
attacks Power Supply
Web Security
-Dynamic Profile (White AC Power Minimum 250GB SATA
List security)
-Web server & application 350W; FTL Model:
signatures (2) Hot-Swap 750W total
-HTTP RFC compliance
-Normalization of 100-240V, 50-60 Hz
encoded data
HTTPS/SSL Inspection
Web Services Security
229
-XML/SOAP profile
enforcement
-Web services signatures
-XML protocol
conformance
Content Modification
-URL rewriting &
obfuscation
-Cookie signing
-Cookie encryption
-Custom error messages
-Error code handling
Platform Security
-Operating system
intrusion signatures
-Known and zero-day
worm security
Network Security
-Stateful firewall
-DoS prevention
Advanced Application
Protection
Data Leak Prevention
Policy/Signature
Updates
Authentication
-must support all
authentication methods
3 Next 2 • Can Identify and control I/O Minimum (8) 10/100/1000
generation minimum 900 applications
network • SSL decryption
firewall (inbound and outbound)
• Custom HTTP and SSL
applications
• Policy-based control by Management I/O Minimum (1) 10/100/1000 out-
application, application of-band management port, (1)
category, subcategory, RJ-45 console port
technology, risk factor or
characteristic
• Application function
control
Power supply (Avg/max power consumption)
• Fragmented packet
180W (10W/75W)
protection
• Reconnaissance scan
protection
• Denial of Service
230
(DoS)/Distributed Denial Input voltage 100-240Vac (50-60Hz)

of Services (DDoS) (Input frequency)
protection
• Can support till 1000
policies
• Visibility and control by
user, group and IP address Power factor 0.997 to 0.978
• Active Directory,
LDAP, eDirectory, Citrix
and Microsoft Terminal
Services
• XML API
DataFiltering
Max input 110A@230Vac; 1A@115Vac
URL Filtering
current
IPSecVPN
SSL VPN
• Dynamic routing (BGP,
OSPF and RIPv2)
• Tap mode, virtual wire,
layer 2, layer 3 Safety UL, CUL, CB
• Network address
translation (NAT)
- Source and destination
address translation
- Dynamic IP and port
pool: minimum 254 EMI FCC Class A, CE Class A,
- Dynamic IP pool: VCCI Class A, TUV
minimum 16,234
• DHCP server/ DHCP
relay: Up to 3 servers
• 802.1Q VLANs: 4,094
• Policy-based forwarding MTBF Minimum 10 years
• Point-to-Point Protocol
over Ethernet (PPPoE)
• IPv6 application
visibility, control and full
content inspection (Virtual
wire mode only)
Firewall 2 Gbps
• Security zones:
performance
minimum 20
(large packets)
• ThreatPrevention
• With ManagementTools,
Visibility andReporting
Tools
Firewall 1 Gbps
performance
(small packets)
231
Firewall packets 1.5 M PPS

per second (64
byte)
AES256+SHA-1 1 Gbps
VPN
performance
3DES+SHA-1 1 Gbps
VPN
performance
Maximum 500,000
concurrent
sessions
New 20,000
sessions/second
Maximum 10.000
security policies
Maximum users Unrestricted

supported
4 Next 1 Should be designed to Ports ‐ Traffic : Two RJ-45

generation address the network Ethernet - 10/100/1000 full
network security needs or half-duplex (auto-
access policy negotiation)
management Can support from 25 to ‐ Management: N/A
server 5,000 simultaneous ‐ Fast Ethernet: IEEE 802.3u
232
endpoint devices compliant

‐ Gigabit Ethernet: IEEE
Can gather user network 802.3z or IEEE 802.3ab
authentication, endpoint compliant
security state, and device ‐ Console: One RJ-45 serial
location data in order to Power Options console port
implement dynamic
access and security
policies ‐ A/C Power Supply: 100-240
VAC, 50-60 Hz, 2.5 A,
With Microsoft SOH Max, 300 Watts
Licenses, ‐ System Battery: lithium
IF-MAP Licenses, coin cell
Unified Access Control ‐ Efficiency: 80% minimum,
Disaster Recovery (DR) at full load
Licenses, Coordinated
Threat Control Licenses.
5 Web -Should be unified into one
security, e- architecture
mail security, -Streamlining content security
and data loss appliance infrastructure
prevention -Should provide integrated
security secure Web gateway solutions,
software data loss prevention (DLP)
solution, best-in-class email
security
6.7 Service Specifications

6.7.1 System Integration:
All hardware and software to be purchased within the Contract MUST be fully compatible with
the software and hardware from the other contracts within the Bid (Mongolian Property
Registration System - ePRS, Uniform Financial Accounting System - UFAS, Equipment and
software for digitization process, WAN connectivity and maintenance)
6.7.2 Training and Training Materials:

6.7.2.1. Technical:
The Supplier MUST provide basictechnical training coursesfor IT staff. This training must cover
basic principles for installation of all equipment provided. The training materials must be in
Mongolian and English languages and will become the property of the Client.
6.7.3 Technical Support:

6.7.3.1. Warranty Service:
233
For all hardware equipment, the warranty period should be 2 years unless is differently specified
or the manufacturer warranty period cannot be changed from the original. In these cases a special
agreement, to cover the period of 3 years, should be established.
6.7.3.2. User support / hot line:
The Supplier MUST provide a model for user support activities and help-desk. This model will
be used by the Purchasing Agencies to organize these respective activities.
6.7.3.3. Technical Assistance:

The Bidder MUST provide a description of the organization that will provide technical
assistance. This description should include the number and qualification of staff, their location,
the facilities and tools at those locations taking into consideration distances and local conditions
of project sites.
6.8 Documentation Requirements

6.8.1 End-User documents:
All end-user documentations MUST be in Mongolian language. The Supplier MUST provide
Application Users Guides.
6.8.2 Technical Documents:
All products to be delivered MUST have specific installation and/or technical documentation.
The original documentation MUST be in English and at least the main manuals (as User Guide,
Administration Guide), should be translated into Mongolian language.
6.9 Consumables and Other Recurrent Cost Items
During warranty period the Supplier MUST provide warranty services and spare parts. After the
warranty period, these costs will be presented under the Recurrent Cost section. Only those
consumables necessary for the initial delivery can be added to the investment.
234
7. INSPECTIONS
7.1 Factory Inspections:
The Bidder MUST prove that all delivered items passed the factory inspections by providing
their certificates of quality assurance.
7.1.1 Inspections following delivery
Since the custom duties are the Bidder’s responsibility each delivery will be checked against its
packing list. After Site(s) delivery there will be another delivery integrity checking performed by
the Bidder.
Pursuant to GCC Clause 27 and related SCC clauses, the Bidder (with the assistance of the
Supplier) will perform the following tests on the System and its Subsystems following
Installation to determine whether the System and the Subsystems meet all the requirements
mandated for Operational Acceptance.
7.2.1 For hardware, system software and communications:
In addition to the Supplier’s delivery tests, the Bidder shall manage the test (supported by the
Supplier) and perform installation tests on each delivered system.
The respective installation test scripts and test schedule MUST be proposed by the Supplier and
approved by the Bidder 15 days before starting.
The Entire System: after successful installation of each system, the Bidder MUST perform a
complete system installation test, with the assistance of the Supplier. The Bidder (with the
assistance of the Supplier) MUST perform a Final Installation Test after all delivered systems,
including the Central Processing Units, will be in place. It must be included in the Project Plan
Note: The complexity of the Operational Acceptance Testing needed will vary in accordance
with the complexity of the System being procured. For Systems to be procured using the single-
stage bidding process, Operational Acceptance Testing may simply consist of requiring a
specified period of trouble-free System or Subsystem operation under normal operating
conditions. For more complex Systems, Operational Acceptance testing will require extensive,
clearly defined tests under either production or mock-production conditions.
235
It is estimated that the Final Contract between the selected Bidder and the Purchaser will be signed by 15 June 2011.
236
9.1 Project Stages
Hardware for ePRS Property Registration System

Calendar Months
Result of the
Project Stages Responsible 2011 2012
stage
1.Hardware Delivery Hardware
HW Supplier + CO
delivered
2. Hardware installation Data center
installed HW supplier + CO +
RO
3. Setting Backup and Backup HW supplier
Maintenance Strategy procedures +CO
4. Testing and Acceptance Acceptance of the HW supplier +CO

system
6. Implementation and System ready for CO

Operational Tests for the new
Final Acceptance productions and
daily operations
CO - Central Office; RO – Regional Office; HW –Software
237
9.2 Site Table

PRIMARY SITE Site Code Site City / Town / Region

TO01

RO04 Zavhan

RO05 Orkhon

SUPPORTING SITES
9.3 Milestone
The milestones related to the payment schedule defined for the Bid process are:
Periods Deliverables
Planning period Work Plan
Delivery/installation plan
Agreeing
Delivery and Delivery of the Goods
installation period Installation
Testing
Operation and Operate the system
monitoring period Monitor the performance and report;
Warrantee period Cover the failures in the period;
Hand over to GASR after period
9.4 Implementation Schedule

In the table below, the Implementation Schedule with Deliverables are provided. The Bidder
is expected to complete and adjust this table based on the chosen approach.
No. Description Deliverable Delivery Acceptance Liquidated

Type (from (from Damages
Work Product: July 2011 July 2011 No

M0 0 Work Plan
Report
1 Delivery and Installation Work Product: August 2011 August 2011 No
Plan Report
M1 2 Acceptance of the makes, Work Product: August 2011 September 2011
models and spec Report
Complete Plan Milestone September 2011 September 2011 No
3 Delivery of Goods Work Product: November 2011 January 2012 No

Hardware and
M2 software
Installation and testing Milestone February 2012 February 2012 Yes
4 Monitor and report Work Product: March 2012 December 2013 No

M3 Report
Operation Milestone March 2012 December 2013 Yes
9.5 System Inventory Table (Supply and Installation Cost Items)

Based on the deliverable implementation schedule, presented in above section, the supply and
installation costs items are described in this section. The Bidder is expected to complete and
adjust this table based on the chosen approach.
0 Detailed Work Plan CO
1 Installation Plan All sites
2 Delivery of the Goods All sites
3 Installation of the Goods All sites
4 Training Evaluation All sites
5 Documentation All sites
6 Operation of all system components All sites
7 Acceptance CO
9.6 System Inventory Table (Costs of Services)

Not applicable.
239
PILLARII - TECHNICAL SPECIFICATIONS FOR

THESERVICES RELATED TO DIGITIZATION OF PAPER
ARCHIVE AND CONVERSION OF EXISTING DIGITAL DATA
240
1. INTRODUCTION
This section of the Bidding Documents describes the functional and technical requirements
for the data migration and digitization of the existing archived data in Property Registration
System. The winning bidder will provide goods and services for creating and implementing a
digital archive which consist from:
 Provision of digital archive meeting the functional requirements specified in the
sections below;
 Provision of data migration plan to support migration of data in the new ePRS
software system.
In preparing responses to this section, the Bidders are reminded that evaluation of the bids
will be carried out in conformance with the following criteria:
 A bid will be deemed as substantially responsive if it conforms to all the
mandatory requirements, terms, conditions and specifications of the bidding
documents without material deviation. A material deviation is one which affects in
any substantial way the functionality, scope, quality or performance of the
deliverables, or which limits in any substantial way, inconsistent with the bidding
documents, the Purchaser’s rights or the Bidder’s obligations under the Contract,
and the rectification of which deviation would affect unfairly the competitive
position of the other Bidders presenting substantially responsive bids.
 Individual technical solutions will be assessed to ascertain their acceptability in
response to the specifications contained in the bid and alternative solutions will be
evaluated on their own merits after the evaluation of the primary response. Some
of the factors in the evaluation of the bids will include:
o adherence to mandatory and preferred criteria;
o overall completeness and applicability to the business and technical
solution;
o technical solution, expandability, use of new technologies;
o Thoroughness of the response to implementation, integration, and support
requirements.
 Bids which are not substantially responsive, as described above, will be rejected.
241
2. OBJECTIVES
2.1 Digitization and Data Migration Objectives
As the result of this tender bid there will be developed and implemented a new digital archive
to be used in all of its branches nationwide. This digital archive will be used to be
incorporated in the new property registration system (ePRS). The digital archive project must
provide the following goals:
 Creation of a single point of access to archive
 Migration of existing digital data to a common immovable property registration
database
 An electronic archive of certain documents attesting property and other rights
about real estate and describing technical parameters of real estate as a part of
standard work flow management document process and procedure for work with
electronic copies.
 To ensure a strong and robust digital archive that should be available for the new
ePRS
 Provide access to the collection of records so the state registrars and all other
accredited users will have the ability to search and retrieve information and
historical records
 The archive will be stored on Data center main storage ensuring a strong security
for the digital records in an economical and sustainable manner
 The digital records will be available through the ePRS to other stakeholders and
government agencies
 All digital records will be stored in an acceptable file format
 Provide a cost-effective means to retain and maintain, through migration process,
the readability and accessibility of the historical record of GASR
 All historical records (from TRIADA and all other databases) will be centralized in
a unique database. All the records from existing databases (TRIADA, etc.) should
be checked against paper archive prior migration, to assure the correctness of
migrated records.
242

In order to achieve proposed objectives the following actions need to be undertaken:
 The procedure for migration should be defined prior to start the process (like
migrating from a back-up or migrating directly from live databases)
 The Baganuur office archive will be used as a pilot office to establish the
procedure for digitization. The pilot will be digitized by Blominfo A/S, in order to
establish the methodology and to implement the software used for digitizing the
whole archive.
 The Database software for ePRS should be agreed prior to migration process
3.1 Inception period

 1st task for the Winning Bidder will be their Work Plan prepared using Microsoft
Project;
 During Inception period, the Bidder should closely cooperate with BlomInfo A/S
and GASR in order to fully understand current situation of the property registration
database and paper archive. Also, the Bidder should learn about proposed
improved business process and IT system.
 Based on their collected information and below written Technical specifications,
the Supplier shall prepare detailed Methodology on migration and have it accepted
by BlomInfo A/S and GASR. When develop the methodology take the
consideration of combining the data migration and digitization tasks;
 The winner also has to familiarize with the Digitization methodology developed by
BlomInfo A/S and shall agree on the results.
3.2 Implementation period

 In this period, the winner shall start migrating the database using its developed
methodology;
 And this step shall be combined with the digitization of paper archive;
 Quality control shall in place to make sure the data was correct;
 The performance progress shall reported routinely to BlomInfo A/S and GASR;
 Migrated data and digital archive shall be tested and accepted by BlomInfo A/S
and GASR;

3.3 Operation and monitoring period

 The accepted database and digital archive should be tested and prepared for the
operation;
 Make the database and digital archive operational with the ePRS;
 The performance result shall be monitored and reported;
 When the database and digital archive fully operational, it should be handed over
to GASR for their responsibility.
243
4. CURRENT DATA ARCHITECTURE

4.1 Introduction
The existing IT registration system architecture is a de-centralized client-server design, but
the Production (Registration) Center for Ulaanbaatar and GASR local offices act
independently. There are two software systems officially used today that store data in a digital
format for registration purposes: TRIADA in the UB registration office and REAL in local
registration offices. The both systems are not interconnected between each other and it is not
possible to access the registration data for overall Mongolia in the central level.
4.2 Digital data availability situation
4.2.1 TRIADA
4.2.1.1. Software Application Overview
TRIADA is the name of software used for the management of real property objects, subjects,
and rights. This software was delivered by IBS (a Russian company) (9B Dmitrovskoe Sh.,
127434 Moscow, Russia, www.ibs.ru) as part of a World Bank project during 2001.
According to information available on the IBS website, TRIADA refers to the company’s
product which is currently called “Process Oriented System for Property Management—IBS
Register.” The main purpose of this product is to maintain legal, technical, and spatial
information regarding properties of legal importance. The System can be used for:
 Management of state, municipal, departmental and corporate properties;
 Maintenance of registers of natural and legal persons, cadastres of land, rivers,
lakes, mineral deposits and other natural resources, registers of institutions,
enterprises, as well as movable and immovable properties;
 Implementing integration with GIS and ERP systems.
4.2.1.2. TRIADA Data model

A brief analysis on TRIADA data model offers the following information:
 The total amount of data stored in the database is 8.3GB, however only 3.5GB of
that is used to store real data—the remainder is used to store command and record
logs.;
 The database structure is comprised of 134 tables;
 The data model has a strongly vertical structure—there are several tables for
primary data storage and then a lot of cross-referencing tables.
The table structure of the TRIADA Data Model is presented in the Annex II.
On the basis the data structure comprises several main data blocks (see generalized data
model in Picture 7):
 Property objects (tables t3_objects, t3_obj_category and related tables) including:
land (T3_prc_component), properties (T3_reu_component), buildings
(t3_bui_component), apartments (T3_apm_component), banks
(t3_bnk_component);
244
 Subjects (tables t3_subject, t3_subj_category and related tables) including natural

persons (t3_prs_component) and legal entities (t3_cmp_component);
 Relations (table t3_relation, t3_rtn_category and related tables) including: rights
(t3_tit_component), rent/leasing contracts (t3_lea_component), mortgages
(t3_mtg_component) and restrictions of rights or encumbrances
(t3_enc_component);
 Legal documents (table t3_basement and related tables) including: applications
(t3_apl_component), attachments (t3_btr_component), certificates
(t3_cft_component), receipts or payment documents (t3_pyd_component) and
references (t3_rfr_component);
 Processes (tables t3_process and t3_process_type) including: privatization, selling,
changing, leasing, mortgaging as collateral, gifting, inheriting, change owner,
change co-owner, issuing reference, etc.
 Tables for storing additional information: addresses of objects and subjects
(t3_address), notaries (t3_notary), statuses of objects, relations and legal
documents (t3_status);
 A Common system of classification: classifier names (t3_classifier_name),
classification levels (t3_lever_name) and classified values (t3_classifier_value).
 Many cross-referencing tables between objects, subjects, relations, processes and legal
documents to maintain information about registration process and results.
 In general this data model does not correspond with the current structure of the
Mongolian immovable property register, but due to the system’s flexibility it is able to
emulate the necessary registration process.
 Relations and legal documents are split into components according to their type, and are
stored in separate tables instead of being stored together.
 Nevertheless, the data structure of TRIADA is transparent enough to prepare the scripts
necessary for data conversion.
245
0Scheduule of Requuirements
Figure 1 - Generaliized data moodel of TRIIADA
4
4.2.2 REA
AL
4.2.2.1. Softwarre Applicattion Overvview
REAL ssoftware waas developedd by the GA ASR IT diviision at the end of 20099, and was
implem ginning of 2010. The sooftware
mented at all the regionaal registratioon offices frrom the beg
utilizes a local servver solution (Microsoft SQL Serveer) and a graaphical userr interface (GUI),
built onn Microsoft Visual Studdio C#.
The maiin objectivee in developping REAL was to provvide regionaal GASR offfices with a simple
databasee solution for
f storing, searching,
s and
a reportinng immovab ble property registrationn
informaation. Prior tot using REEAL all regiional used Microsoft
M Excel. The so oftware inclludes
documeentation in Mongolian
M t
titled “Manu ual for Propperty Rightss Registratioon REAL Software
and Repport Generaating Appliccation”. As compared
c too TRIADA,, the REAL L software iss
substanttially simpler to use annd does not require
r the duplicationn of registrattion steps.
4.2.2.2. REAL data model
The struucture or RE EAL is veryy simple, in general it follows
f the structure
s ussed to file foor the
state reggistration off properties and titles (““ЭД ХӨРӨ ӨНГИЙН УЛСЫН
У УЛЛСЫН
БҮРТТ ТГЭЛИЙН ХУВИЙН Х Х
ХЭРЭГ”), b in fact the databasee was preparred using thhe
but
structurre of existing MS Excell files. The most imporrtant reason the system was updateed from
Excel wwas to make it easier to keep appliccations for registration
r and referennces.
A descrription of the data tablees which is available
a in Annex III. The generaalized data m model
of REA AL is shown in Error! Reference
R source
s not found..
2
246
Figure 2 - Genera
alized data m
model of REAL
R
44.2.3 Digiital Data Availability

A
Accordiing the staatistics colllected on August
A 31,, there aree a little more
m than 390,000
immovaable properrties registered in the register off immovablee property. About 2000,000 of
them are registered d in the Ulaaanbaatar city registratioon office an
nd 190,000 in
i aimag offffices.
All imm movable prooperties in Ulaanbaataar are recorrded also inn the TRIA ADA databaase – all
togetherr there are a little moree than 207,0000 in the daatabase.
The data conversioon from the manual reg gistration boooks into thee REAL dattabase is onngoing in
all 21 aaimags. At the
t time this documentt was produuced in som me aimags 100% of thee records
are alreeady converrted, in othhers betweeen 50-80% has alreaddy been inpput into thee REAL
databasee. The goal is to have 100% of thee data enterred in all aim mags by falll 2010, andd all data
should be availablle until the project forr digitizatioon will startt. After all the data inn all the
aimags is entered, iti is plannedd to merge the
t aimags’ databases intoi one cenntral database.
The archives of thee registratioon offices coontain only paper docuuments and files currenntly none
of them
m have been converted tto a digital format.
f
4.3 Paper arrchive current situ

uation
Archivee content
Archivee in current Mongoliann property reegistration system
s conttains the folllowing doccuments:
registereed documeents, supporrting docum ments (e.g. payment receipts), maps, m other relevant
documeents, etc. aree all stored in
i the archivve file.
Similar to the Geerman Gruundbuch sysstem and other o East--European systems, thhere are
booklets containingg three maiin sets of simple form ms for listingg property informationn, owner
informaation, and encumbranc
e ces. These forms
f are on
o pre-printted books of o 150 pagges (they
used to be in bookklets of 40 pages
p replacced in 20000 by anotherr booklet off 60 pages anda now
replacedd in 2004 byy the 150 paage pre-prinnted manuall).
2
247
These books mostly are empty and useful information is written in no more than two or three
pages. (See Annex I for a translation of the various pages of the register book pages.)
Each time the property’s ownership changes, the new owner is recorded in the ownership part
of the register, and the previous owner’s name is crossed out. When a new mortgage or lease
is registered, it is recorded in the encumbrance’s part of the register book.
Archive organization
There is a separate archive file for each property. The archive files are stored in plastic
folders, with about three or four files per folder. The folders are stored in compactors or in
wooden shelf units. The archive file also contains the register book for the property, which is
the register.
Each shelf row is labeled with labels representing the range of properties included.
The records are kept in either brown paper bound volumes or blue plastic containers. Each
container holds three or four archive folders. The majority of the folders have multiple
properties inside which are labeled on the spine of the blue folder for reference using the
GASR property numbering. Each property has its own dossier, which contains all the
paperwork submitted for each transaction on that particular property.
Document Format
A folder contains documents in various sizes starting from A5 to A3. Generally the paper is in
good quality and is not required special treatment. Some of them are stapled and must be
opened before scanning.
Volume analysis
The volume of data can be estimated that there are approximately 30 million pagesof property
documents that will need to be scanned.
The following table contains the approximated number of archived folders.
No Aimag/ Approximated number of

GASR Property Registration Office archived folders1
1 Ulaanbaatar 203,590
2 Arkhangai 9,070
3 Bayan-Ölgii 8,012
4 Bayankhongor 6,767
5 Bulgan 6,184
6 Darkhan-Uul 22,426
7 Dornod 13,268
8 Dornogovi 6,345
9 Dundgovi 4,462
10 Govi-Altai 3,932
11 Govisümber 3,025
12 Khentii 6,828
13 Khovd 6,598
1 As of August 31st, 2010

248
14 Khövsgöl 8,264
15 Ömnögovi 4,647
16 Orkhon 22,588
17 Övörkhangai 11,275
18 Selenge 16,066
19 Sükhbaatar 4,825
20 Tuv 10,877
21 Uvs 6,995
22 Zavkhan 4,476
23 Total folders in the Mongolia 390,520
The aimags that are involved digitization for this contract are described in the detailed
proposal (the service provider shall use this estimation) for a plan including each registration
office can be viewed in Annex IV.
There are no digital backups or microfilm backups of the paper records identified which
therefore serve as the only copy of documents attesting to the land ownership rights of
hundreds of thousands of Mongolian citizens.
249
5. INTRODUCTION
The proposed implementation described in present chapter is based on prescriptive
commonly-used industry specifications and standards. The contractor can exceed these
recommendations and can provide a better implementation process in order to fulfill the
assignment for project period.
5.1 Data Migration
Below is a short description of the methodology to be used for the data conversion from one
database structure to another.
Database conversion tools
There are a number of tools available for database conversion ranging from freeware and
shareware products all the way to platform oriented data migration tools. Generally these
tools enable the user to migrate data from one database platform to another database platform
with simple mapping between data types. Sometimes server procedures and user interface
forms can even be migrated from one platform to another. Using these methods means that
the data model remains the same while only the supporting platform is changed.
In our situation our needs are quite different – we need to convert the existing data to another
data model where we are not expecting on-to-one conformity between data records and data
items in the source and target databases. In this particular case, the only way to achieve our
goal is to develop special software for data conversion. The software can be developed using
programming languages for data manipulation such as PL/SQL for Oracle database or
Transact SQL for Microsoft SQL Server database. The conversion can be done in two ways:
 Online - by using connection (link) between old database and the new target
database, and running on side of target database conversion software queries data
in source database, converts it and stores within new structure;
 Offline - by exporting data from old database, importing it into the new database as
separate data store and running conversion software against this copy of data for
converting it to the new data structure
250
Databasse conversiion process

The genneral databaase conversiion process is representted in figuree below.
251
The next table contains a description of the steps in the conversion process.
Step Name in diagram Description Mode
1. Prepare source database for Before conversion the source database Semi-automatic
conversion should be validated for completeness
and consistency. If special data
validation tools are developed for the
current data structure, those tools should
be run and any recognized problems
should be solved.
2. Export content of source database Export the database in its native export Automatic
format or some other transport format.
3. Import content of source database Create a separate database schema with Automatic
into target database the source database structure fit to the
environment of the target database. The
import of the data should be run
according to this schema.
4. Make connection between databases Establish a database link directly or via Manual
an agent (connector) if there are
different database platforms.
5. Prepare target database for Make any necessary changes in the Semi-automatic
conversion target database in order for it to be able
to accept the new data. This can be done
by making a backup copy (strongly
recommended), disabling indexes and
integrity constraints, enlarging data
stores, rollback segments, etc.
6. Set up check point for target Set up a checkpoint where target Automatic
database database will be rolled back to in case of
an unsuccessful conversion. This can be
included in the conversion software.
7. Run conversion software Actually run the conversion software Automatic
8. Rollback target database to Execute a rollback to the checkpoint Automatic
checkpoint command. This can be included in the
conversion software and will be used if
the user does not accept conversion
results.
9. Solve problem Locate and solve problem(s) that Manual
resulted in an unsuccessful conversion.
10. Commit and carry out post Commit to the changes in the database Semi-automatic
conversion tasks and carry out the necessary post-
conversion tasks required to put the
database in a production state. This step
may include: enabling constraints and
indexes, adding some necessary data and
user accounts, setting up rights etc.
11. Validate converted records against Undergo a manual comparison of the Manual
paper file from archive database records against records in the
archived registration books for each
individual immovable property.
12. Correct and supplement records Manually enter any missing data and Manual
edit any incorrect records.
252
Step Name in diagram Description Mode

13. Accept converted file Accept/verify the correctness of the Manual
converted data for each individual
immovable property. Verification should
be marked in the database with an
indication of who accepted the data and
when they did it.
There can be different strategies for converting regional databases to the central database and
the contractor MAY propose a different one. The common practice is to convert office by
office during weekends. If conversion for a particular regional office succeeds then this office
will be connected to the central register and from the following Monday will continue duties
with the new registration system.
Due to the different conditions in which data can be entered into the system during the
creation of the new system (some data is entered manually while other data is converted) all
the records that are converted should clearly be indicated as “converted data.” This can be
taken into account in case of any future disputes about the contents of the records in the
digital register.
If it is decided that all data should be entered completely manually into the new system then
steps 11-13 from above should be executed.
253
6. PAPER ARCHIVE DIGITIZATION
BlomInfo A/S is responsible for the first stage of the digitization process for GASR, namely:
o developing the detailed methodology and work plan for the digitization
process
o developing the software needed to process the digitized files to the
procured database software
o testing the methodology and the process during a pilot stage – in a selected
pilot office
o providing training for GASR staff participating in the digitization process
After the pilot and training phase the majority of the digitization work is outsourced, and this
service is the objective of the digitization BID.
The quality control and supervision of the process will be ensured by BlomInfo A/S.
Description of the software for digitization:
The software will be in responsibility of Blominfo A/S. This software will be developed and
the methodology will be tested together with the software. After approval and of the
methodology the software will be given to supplier to continue the digitization process.
The software consists in a web interface for data entry of the necessary metadata associated
with the scanned file.
Description of the outsourced digitization service:
Considering the content of the archive, where each immovable property has its own dossier,
the Bidder’s proposal is to only scan the papers that are related to the ownership and other
rights described in the register book. This is because the other data contained in the register
books already exists in a digital format in the TRIADA and REAL databases.
During the implementation of the work the selected service provider shall use four different
teams, every team having different purpose in the digitization process. The teams are:
 The inventory team – should consist of a minimum of two people. These people
will be responsible for inventory, preparation, and restoration of the documents to
be scanned;
 The scanning team– should consist of a minimum of two people. This team’s task
is to work with a specialized scanner and do localized quality to control do
determine if rescanning the document is necessary;
 The digitizationteam – should consist of about five people. This team will process
the scanned documents and will digitize the content and create the references for
archived scanned documents based on the registration number of the immovable
property
 The quality control team – should consist of a minimum of two people. Its main
task will be to check the digitization of the documents and ensure the quality of the
data entered.
254
The data should be collected and stored in a relational database or open XML based by a
defined XML Schema that should contain the following structured data:
 The application date and number of the transaction which refer to the document;
 The name and type of the deed that refer to the legal grounds of ownership, pledge,
or other rights on the property as well as other types of documents that refer to the
register book;
 The information the points to the deed or current ownership situation for the
property.
Using this XML data together with the PDF or TIFF file we can offer a digital document. The
XML data collected can be easily imported as a list of bookmarks or table of contents for the
resulting PDF files.
The estimated productivity rates for the digitization of the documents, broken down by the
structure of the teams, are shown in the table below:
Team Name Number of persons Estimated Productivity Rate

involved (documents2/hour/person)
Inventory Team 2 50
Scanning Team 2 50
Digitization Team 5 20
Quality Control Team 2 50
A detailed proposal (the service provider shall use this estimation) for a plan including each
registration office can be viewed in Annex IV.
In order to achieve the proposed plan a simultaneous digitization MUST be made it in all
regions.
Proposal for the Data Digitization Subsystem
The data digitization subsystem consists of two parts: scanning and data extraction.
The application used to collect data SHOULD be creating using a business logic layer (BLL)
at the database level to order to allow for each integration and management. All user interface
windows must be created using the Mongolian language, but should also be optimized for
data entry and optimum quality checking.
Scanning
To collect data in situations like this it is generally most cost-effective to scan the documents
from which the data is to be extracted and then use the scanned images as the basis for the
information extraction. This approach allows the documents to be quickly returned to their
storage archive and allows for easy quality control of the data extraction. Moreover it will
minimize the time that a scanning team (typically 4-5 people) occupies space in an archive.
This flow line has four main stages: an inventory, preparation of the documents, including
disassembling them, checking them into a Document Management System (DMS); scanning
and QC of the scans; restitution of the documents and return to the archive.
2 Document – represents a dossier that contain all papers related to transactions made for an
immovable property that is stored in the archive
255
 The diagram above shows the main processes for document scanning:
 Inventory – identifying all documents to be scanned, normally carried out in the
archive or office where they are stored (this may take place weeks in advance of
scanning);
 Preparation – taking documents from the archive and assembling them into
batches;
 Scanning and quality control, including rescanning if necessary;
 Restitution – reassembling documents into the original state and replacing them in
the archive.
All of this MUST be done by a thoroughly documented, robustly controlled system.

Once the documents are scanned then the information extraction can begin.
Document scanning MUST be carefully organized in order to minimize any impact on the
host office. This may include working out of office hours if possible.
Data management
A key aspect of a production scanning system such as that shown above is to manage the flow
of documents through the system. This MUST ensure that:
 Documents are secure at all times and no document is at risk of being lost or
damaged
256
 Documents are out of normal use for as short a time as possible – typically less
than 48 hours for a document required for frequent use, often less than 12 hours
(possibly overnight) if managed correctly.
 The location of each document is known if it is needed for an official purpose
 Documents are correctly matched to the scanned images
 Documents are returned to the correct archive
In this situation, a good document management line SHOULD be:

1. Acceptance of the document by the Contractor representative, removal from transit
box, recording the document receipt (including box reference);
2. Assessment of the appropriate method of scanning;
3. Preparation – disassembly, separation, etc. if required;
4. Batching into documents with similar characteristics;
5. Batch scanning;
6. Initial check of scan, rescan if necessary;
7. Naming of data file to match document;
8. Reassembly of documents and replacement in the same transit box
9. Notification to the Archivist that the box of documents is complete and ready for
collection.
Loose sheets of printed or typewritten documents will be scanned by automated scanners

capable of tens or hundreds of double-sided copies per minute.
Other special types of document need special handling. Examples include:
 Bound documents in books may be unbound, scanned and then rebound, or a
specialist book scanner can be used. Alternatively, a fixed-focus rostrum camera
might be utilized. While it is preferable to keep a book together, it may be faster to
disassemble, scan and reassemble if the documents are sufficiently robust and a
high quality image is required. Often bindings (stitched or stapled) are worn and
need replacing in any case.
 A document with oversized pages may need to be disassembled, scanned in
different flow lines, and then reassembled. A colored piece of paper can be used as
a place-holder in the document to remind operators to reunite it with other pages.
 Colored pages can also be used to separate documents in the scanning line or to
remind operators to take action (e.g. start a new loading tray)
 Transparent folders with bar codes and reference numbers can be used to keep
loose pages together or to protect fragile documents (some types can be used to
improve scanning)
Separate tables or work areas SHOULD be used for documents received, documents in
preparation, documents waiting to be scanned, completed documents (awaiting QC),
documents waiting to be reassembled, and documents ready for dispatch. Bar code labels
SHOULDbe used to identify documents.
257
In terms of the security, EAN-13 code type SHOULD be printed on the papers, and for
storing information is recommended to be used a QR code or a PDF417 code to store the data
associated with the scanned document.
The scanners SHOULD have a facility for marking each page with a reference number as it
passes through.
Document scanning
Textual documents of up to A3 size SHOULD be scanned as described above using duplex
automatic feed scanners wherever possible.
These scanners scan both sides of a document and convert it to an appropriate format (TIFF,
PDF) as necessary. The actual scanning process is quick – up to 80 sides per minute is
realistic: more problems are experienced in extracting data and in document management than
in the actual scanning process. Very old documents or those with handwriting will be given
particular attention and scanned manually because they are often difficult to read when
scanned and rescans may be necessary.
The proposal is to scan at 300 dpi (2480*3508 for A4 size, ~8.5Mpx) in an 8-bit gray scale
PDF format on the grounds that:
 300 dpi allows more accurate optical character recognition to be used;
 Gray scale is adequate for the majority of legal documents;
 PDF files can be locked by password protection but can be assembled from
separate pages into logical documents and read by any computer system running
the Adobe Acrobat Reader software or equivalent;
 This format is a good compromise between file size and image quality. A typical
18-20 page document occupies about 25 MB.
For faint or otherwise difficult documents the resolution and/or bit depth may be increased.
Contrast and brightness controls will in general be set to use the scanner automatic settings.
Again, difficult documents MAY require manual intervention to ensure an acceptable result.
The image quality of each page will be assessed and where necessary rescans will be carried
out.
258
7. FUNCTIONAL REQUIREMENTS
7.1 Introduction
The following requirements describe the digital archive requirements necessary to be
implemented in Electronic Mongolia Property Registry System for GASR in Mongolia
(ePRS).
The bidder must take into account that these are preliminary high-level requirements and will
be subject to change as the analysis and design phases of the project get underway. It is
estimated that approximately 10% of the currently stated requirements could be subject to
change, and that a number of additional requirements equal to approximately 10% of the total
current requirements could be added.
7.2 Structure
In the following sections, a description of the basic functionality of the respective functional
area will be followed by a list of sub-functional areas within the functional area. For each sub-
functional area, a table of requirements will appear in the following format:
Mandatory
ID Requirement Description Notes
(Y/N)
X10001 Y The requirement goes here Any notes go here
where the individual columns are defined as:
ID Identification of the requirement in the format XSNNNN, where X is the

first letter of the functional area name, S is the number of the sub-
functional area as listed at the beginning of the section, and NNNN is a
sequence number for the requirement. Each requirement should have its
own ID that is unique within this entire document.
Mandatory "Y" if this is a mandatory requirement, "N" if it is not mandatory.
(Y/N) Inclusion of non-mandatory requirements in a proposal will earn the
Supplier extra points in the scoring of bids.
Requirement The text of the requirement.
Description
Notes Further clarification or explanation of the requirement.
259
8. GENERAL REQUIREMENTS
8.1 Introduction
This section details the general requirements of the digital archive.
The Sub-Functional Areas of the General Requirements are:
1. Digital Archive technical specifications
2. Equipment and Software used in digitization process
3. Metadata
4. Quality assurance
5. Storage and backup
6. Migration and preservation
8.2 Digital Archive technical specifications
A large volume of technical standards associated with digitization are available. Such
standards include recommendation on:
 File Formats;
 Resolution;
 Color resolution or bit depth;
 Compression and color management
Specific recommendations on technical specifications for digitization are the least descriptive
commonly-used industry specifications – the supplier can exceed these recommendations,
which are not mandatory but will guide supplier as a minimum requirements:
Document Type Resolution Bit Depth File Format Compression
Text only, black and Minimum 300 dpi 1 bit (bi-tonal) -TIFF Lossless
white -PDF/A3 containing Compression
TIFF or JPEG
20004
Documents with Minimum 600 ppi 8 bit grayscale -TIFF Lossless
watermark, gray -JPEG 2000 Compression
shading, gray -PDF/A containing
graphics TIFF or JPEG 2000
These standards are rapidly evolving, especially in the area of technical capacity of equipment
to accommodate such standards. The primary consideration in adopting the right technical
specification is to ensure the legibility of the digitized image. The following basic criteria
MUST be adhered to when choosing technical standard that will be adopted to achieve this
project:
Mandatory
(Y/N)
3
PDF/A is a constrained version of PDF version 1.4 with various proprietary fonts and
formats remove, issued as ISO 19005-1:2004
4
JPEG 2000 is defined in ISO 15444-1:2000
260
Mandatory
(Y/N)
The highest technical specifications that can be
realistically supported SHOULD be
A1001 N
incorporated into the digitization process.
Format adopted MUST be open source (that is,

non-proprietary), have published technical
A1002 Y
specifications available in the public domain, or
be widely deployed within the relevant sector.
Format adopted MUST not contain embedded
A1003 Y objects, or link out to external objects beyond
the specific version of the format;
Format adopted MUST be supported by many
A1004 Y
software applications and operating systems;
Format adopted MUST be able to be read by
utilizing a readily available viewing plug-in if
A1005 Y
the specific production software is not available
for all users;
Adequate technical support MUST exist to
enable ongoing maintenance and assurance of
A1006 Y
migration capability when necessary;
Master copies SHOULD be created to the

highest technical standards achievable;
A1007 N
Master copies SHOULD be retained inviolable

A1008 N in secure storage;
Derivative copies MAY be made in formats

most convenient to the business requirements
A1009 N
(e.g. thumbnails for distribution over the
internet, etc.)
8.3 Equipment and Software used in digitization process

The quality of equipment and software used in digitizing significantly affect capability to
support appropriate technical standards and, therefore, to ensure longevity of the digital image
produced. Where totally usage of the original source records is contemplated, the client
MUST be able to assert confidence in the long-term viability of those digitized images
requiring on-going retention. In order to do this the following general requirements must be
applied:
Mandatory
(Y/N)
During the digitization process, the use of
techniques that enhance the digitized image to
B1001 Y
make the image have a more exact resemblance
to the original or reproduce the source records
261
Mandatory
(Y/N)
appearance more faithfully, MUST be
documented.
Equipment and software aligned to the

digitization requirements MUST be
B1002 Y
implemented
8.4 Metadata
Metadata attributed to, or associated with, images is an essential component in the
management and retrieval of images. Wherever possible metadata SHOULDbe inherited from
the existing system.
Two types of metadata MUST be captured:
 Metadata specific to the particular image and the imaging process;
 Metadata about the record, the business being transacted and the agents associated
with the business.
The majority of this metadata can be automatically sourced from the software and hardware
used to manage the digitizing process. The manual attribution or application of metadata
SHOULD be minimized.
Metadata can be embedded with the resource in header information, or can be managed in a
separate system, or both, but in either case there has to be a direct relationship or association
between them. That is, while metadata may reside in a separate system, it has to link directly
to the resources. Metadata can also be encapsulated within the image format. Choices for
storage of metadata SHOULD be made according to the principles outlined in ISO 23081 -1
1:2006, Information and documentation – Records management processes – Metadata for
records.
Image-level metadata
Image-level metadata SHOULD be generated automatically at the point of digital capture
direct from the digitization equipment and SHOULD avoid manually-assigned data entry
wherever possible.
In addition to the metadata inherited from recordkeeping capture and processes, or from
indexing and searching metadata, image-level metadata MUST include:
 Unique digital image identifier;
 Date and time of digitization;
 The name of the agent associated with the digitization process (e.g. name of the
outsourced bureau or name of the in-house operator).
 Capture device (hardware and software);
 Calibration settings (resolution, color, dimensions, etc.) and
 Date of last calibration
262
Additional image-level metadata MAY be assigned at the discretion of the public office or
local authority.
File-naming metadata recommendations

A file naming scheme SHOULD be established prior to capture. The development of a file
naming scheme should take into account whether the identifier requires machine or human
indexing (or both – in which case, the image will have multiple identifiers. File names can
either be meaningful (such as the adoption of existing property registration numbering scheme
which correlated the digital file with the source material), or non-descriptive (such a
sequential numerical string). Meaningful file names contain metadata that is self-referencing;
non-descriptive file names are associated with metadata stored elsewhere that serves to
identify the file. In general, taking in consideration that this is a smaller-scale project a design
descriptive file names that facilitate browsing and retrieval SHOULD be implemented,
instead of using machine-generated names and rely on a database for sophisticated searching
and retrieval of associated metadata.
In general, file names SHOULD:
 Be unique;
 Be consistently structured;
 Take into account the maximum number of items to be digitized and reflect that in
the number of digits used (if following a numerical scheme);
 Use leading zeros to facilitate sorting in numerical order (if following a numerical
scheme)
 Avoid using spaces within the file name, using underline character as an
alternative;
 Avoid an overlay complex or lengthy naming scheme that is susceptible to human
error during manual input;
 Restrict the length of file names to under 30 characters to avoid potential problems
with migration between different systems;
 Use lowercase characters and file extensions;
 Use numbers and/or letters but not characters such as symbols or spaces that could
cause complications across operating platforms; and
 Record metadata embedded in file names (such as scan date, page number, etc.) in
another location in addition to the file name. This provides a safety net for moving
files across systems in the future, in the event that they have to be renamed. In
particular, sequencing information and major structural divisions of multi-part
objects SHOULD be explicitly recorded in the structural metadata and not only
embedded in filenames.
Directory structure
Regardless of file name, files will likely be organized in some kind of file directory system
that will link to metadata stored elsewhere in a database. Production master files might be
stored separately from derivative files, or directories MAY have their own organization
263
independent of the image files, such as folders arranged by date or classification structure, or
they MAY replicate the physical or logical organization of the originals being scanned.
The files themselves can also be organized solely by directory structure and folders rather
than embedding meaning in the file name. This approach generally works well for multi-page
items. Images are uniquely identified and aggregated at the level of the logical object (i.e. a
document, a record, a file/folder, etc.), which requires that the folders or directories be named
descriptively. The file names of the individual images themselves are unique only within each
directory, but not across directories. For example, property registration file 0001 contains
image 001.tif, 002.tif, and 003.tif. Property registration file 002 contains image files 001.tif,
002.tif, and 003.tif. The danger with this approach is that if individual images are separated
from their parent directory, they will be indistinguishable from images in a different directory.
Versions
For various reasons, a single scanned object may have multiple but differing versions
associated with it (for example, the same image prepared for different output intents; versions
with additional edits; layers or alpha channels that are worth saving; versions scanned on
different scanners, scanned from different original media, or scanned at different times by
different scanner operators). Ideally, the description and intent of different versions in the file
name will allow for quick identification of a particular image. Like derivative files, this often
implies the application of qualifier to part of the filename. The reason to use qualifiers rather
than entirely new names is to keep all versions associated with a logical object under the same
identifier. An approach to naming versions SHOULD be well thought out; adding 001, 002 to
the base of filename already denote page numbers; a different approach will be required.
Naming derivative files

The file naming scheme should also take into account the creation of derivative image files
made from the production master files. In general, derivative file names are inherited from the
production masters, usually with a qualifier added on to distinguish the role of the derivate
from other files (i.e. “p” for published version, “t” for thumbnail). Derived files usually imply
a change in image dimensions, image resolution, and/or file format from the production
master. Derivative file names do not have to be descriptive as long as they can be linked back
to the production master file.
For derivative files intended primarily for web display, one consideration for naming as that
image may need to be cited by users in order to retrieve other higher-quality versions. If so,
the derivative file name should contain enough descriptive or numerical meaning to allow for
easy retrieval of the original or other digital versions.
Business-process digitization
Wherever possible the metadata controlling the business process and the recordkeeping
functions associated with the business process SHOULD govern, and be inherited by, the
specific digital image. This metadata MUST be incorporated into the organization’s
264
electronic recordkeeping framework and be consistent with ISO 23081 – 1:2006, Information
and documentation – Records management processes – Metadata for records.
Additional metadata describing the process of digitization and specific characteristics of the
digitized image MUST be included, as outlined above.
Based on these facts the following functional requirements are established and MUST be
implemented:
Mandatory
(Y/N)
All digitized images MUST be assigned
metadata to document digitizing processes and
D1001 Y
to support ongoing business processes.
Two types of metadata MUST be captured:

Metadata specific to the particular image and the
imaging process; and
D1002 Y
Metadata about the record, the business being
transacted and the agents associated with the
business
In addition to the metadata inherited from
recordkeeping capture and processes or from
indexing and searching metadata, image-level
metadata MUST include:
Unique image identifier;
D1003 Y Date and time of digitization;
The name of the agent associated with the
digitization process;
Capture device;
Calibration settings; and
Date of last calibration.
In business-process digitization, records
metadata MUST be incorporated into the
D1004 Y organization’s electronic recordkeeping
framework and be consistent with ISO 23081
Metadata for records, Parts 1 and 2.
8.5 Quality assurance

Quality assurance to ensure the digital copy of the source record is a true an accurate copy is
critical to being able to assert that the records possess integrity and are authentic.
Such quality assurance procedures MUST be documented and built into the ongoing operation
of the digitizing process, not considered simply a check on output only.
Quality assurance procedures SHOULD, at minimum address the following issues:
 Any acceptable variations from normal procedures;
 Scanner operation quality control;
 Verification that digital output matches the quality of original record input;
 Extent and frequently of sampling of digitized images;
 Criteria for checking image quality;
 Frequency and criteria for checks on metadata;
265
 Processes for re-digitizing; and

 Operator training.
Quality checking MUST be completed before digitized images are accepted into a business
process, or as a master copy.
The results of quality assurance processes and quality checks MUST be documented.
A review of quality procedures for digitizing SHOULD be undertaken regularly to ensure that
the procedures continue to meet the business requirements.
Appropriate training SHOULD be provided to all staff that create, manage or work with
digitized records. Documentation on the level and the frequency of training provided to those
staff involved with digitization SHOULD be created and maintained.
Taking in consideration these facts the following list of functional requirements MUST be
accomplished by the supplier:
Mandatory
(Y/N)
Quality assurance procedures MUST be
delivered, documented and implemented.
E1001 Y
Quality checking MUST be completed before

the digitized images are accepted into a business
E1002 Y
process or as a master copy.
The results of Quality assurance processes and

quality checks MUST be documented.
E1003 Y
8.6 Storage and back-up

Maintaining technology-dependent records in networked storage is currently the storage
strategy to ensure the continuing accessibility of such records over time. However, digitized
records can occupy significant storage space depending on the quality, resolution and
compression ratios employed. Strategies for storage MAY include:
 A dedicated server or other digitized record storage solution;
 Writing the digitized records to magnetic tape;
 Writing the digitized records to WORM (write once, read many) storage media
(e.g. a CD or DVD)
The requirements for storage include:

 That the digitized records MUST be unalterable in all storage media;
 That security and access controls for storage media MUST be capable of detecting
and logging unauthorized attempts at access;
 That the retrieval times implicit in off-line storage should be acceptable for the
business being conducted;
266
 Wherever possible digitized records sharing similar retention SHOULD be co-

located to enable execution of destruction processes as required.
All digitized records, and their associated metadata, must be included in the organization’s
back-up regime. Back-up procedures are designed to provide sufficient up-to-date copies of
business records to be used in the event of loss or corruption of all or part of the data.
Back-up regimes SHOULD be documented and back-up copies maintained to a level of
security that will ensure the authenticity of the records used in recovery situations.
All system failures MUST be documented, and use of the back-up copies for restoration
purposes MUST be accompanied by verification testing to ensure the integrity of the restored
records.
Information technology professionals often use the term ‘archiving’ to describe back-up
regimes. For recordkeeping purposes conducting back-ups does not constitute an archiving or
preservation strategy, it is a business continuity or disaster recovery precaution.
Summarizing the above, the functional requirements for storage and backup are:
Mandatory
(Y/N)
Storage media and back-up procedures MUST
F1001 Y be defined, documented and implemented
Digitized records MUST be unalterable in all
F1002 Y storage media.
Security and access controls for controlling

storage media MUST be capable of detecting
F1003 Y
and logging unauthorized attempts at access.
All digitized records, and their associated

metadata MUST be included in the
F1004 Y
organization’s back-up regime.
All system failures MUST be documented.

F1005 Y
The use of the back-up copies for restoration

purposes MUST be accompanied by verification
F1006 Y
testing to ensure the integrity of the restored
records.
8.7 Migration and preservation

Technology-dependent electronic records are inherently vulnerable to hardware, software and
media obsolescence.
Digitized records SHOULD be included in the record-keeping framework adopted by the
organization to support the continuing existence of records for as long as they are required.
A migration strategy aims to transfer the record (and its associated metadata) into subsequent
generations of software, hardware and media, in ways that preserver the authenticity and
267
integrity of the record, and enables it to continue to be used as an authorized record of

business.
All migration strategies MUST identify which record objects and associated metadata are
required to enable client to access the authentic digitized record. The original metadata
MUST be migrated into any system replacing the one in which the digital image was
originally managed.
Any decision not to migrate a digitized record into subsequent generations of software and
hardware is a disposal action, and as such MUST be supported by either:
 Authorization of disposal of the record and its associated metadata or,
 Transfer of the record and its associated metadata into a dedicated preservation
environment.
A dedicated preservation environment is one which identifies and documents the content and
context of the record, including its linkages to other records and an event history relevant to
processes applied to and uses made of the record. Typically, such an environmental aims to
extend the existence of the record once it is no longer required for active conduct of the
business which created or managed it. The preservation environment MUST support the
retrieval of the record for as long as required.
Summarized functional requirements that are related to migration and preservation:
Mandatory
(Y/N)
Migration and/or preservation strategies and
processes MUST be delivered, documented and
G1001 Y
implemented
All migration strategies MUST identify which

record objects and associated metadata are
G1002 Y
required to enable GASR to continue to access
the authentic digitized record.
Any decision not to migrate a digitized record
into subsequent generations of
software/hardware is a disposal action and
MUST be supported by either:
G1003 Y Authorization of disposal of the record and is
associated metadata or,
Transfer of the record and its associated
metadata into a dedicated preservation
environment.
The preservation environment MUST support
the retrieval of the record for as long as required.
G1004 Y
268
9. QUALITY ASSURANCE REQUIREMENTS

The Supplier will implement a quality assurance to ensure the digital copy of the source
record is a true and accurate copy.
Scanner Operation Quality Control
Scanners SHOULD be tested periodically to monitor their operational performance and check
that operating performances are within agreed tolerances as set out by existing standards and
benchmarks. Results of previous test SHOULD be used as benchmarks for system
performance over time
Validation of Output
The equipment SHOULD routinely record the number of discrete documents and the number
of documents comprising a record (more than one page bundled) that were scanned during a
session.
Sampling
The frequency of sampling SHOULD be determined according to the system usage and
expected or anticipated deterioration periods. Advice from the system Supplier may assist in
determining the frequency period. Initially, it MAY be appropriate to scan a test target every
few thousand pages. However, once benchmarks have been established and equipment and
processes stabilized, this MAY be reduce to a random sampling od between 5 and 10%.
Sample sets
Assemble a sample set of source documents for the purposes of evaluating scanner results
against agreed quality criteria. These documents SHOULD be representative of the records to
be scanned and SHOULD include examples of source documents whose quality is poor
relative to the majority of the sample documents.
Quality criteria for images
Quality criteria for images SHOULD include consideration of overall legibility:
 smallest detail legibly captured (e.g. smallest type size for text; clarity of
punctuation marks, including decimal points)
 dimensional accuracy compared with the original;
 scanner-generated speckle (i.e. speckle not represent on the original);
 completeness of overall image area (i.e. missing information at the edges of the
image area);
 density of solid black areas.
Metadata
Procedures SHOULD specify the checks to be implemented to assess metadata quality
assigned to images.
Documentation
Quality control data (such as logs, reports, decisions) SHOULD be captured in a formal
system and SHOULD become an integral part of the image metadata at the file or the project
level. This data may have long-term value that could have an impact on future preservation
decisions.
269
Processes for Re-digitization

If more than 10% of the total number of images and associated metadata examined in a
randomly sampling are found to be defective for any of the reasons listed above, the entire
output since the last quality check SHOULD be re-inspected. Any specific errors found in the
random sampling and any additional errors found in the re-inspection SHOULD be corrected.
If less than 10% of the batch is found to be defective, then only the specific defective images
and metadata that are found should be redone.
Common faults
Quality faults can be categorized as ‘implementation faults’, ‘process faults’ or ‘operator
faults’. Implementation faults are those that can be avoided, providing appropriate procedural
controls are in place to guide the digitization. Process faults are normally out of the control of
the operator and need to be addressed by a supervisor to the process. Operator faults are the
day-to-day faults that are made by the operator as they work.
Implementation Faults
There are a number of faults that can be avoided with appropriate specification of procedures
to guide the implementation. These include:
 Dirty originals;
 Incorrect file-size and format where file are made to wrong size or with wrong
choice of file format;
 Compression, where files are made with an inappropriate type or level of
compression.
Process faults
There are a wide variety of process faults that can be caused by many problems within the
workflow. These problems can include:
 Incomplete or inaccurate specifications or process documentation;
 Faulty capture hardware (incorrectly calibrated and characterized devices);
 Faulty software (inaccurate image processing or faulty image links within
database);
 Incorrectly established color management systems;
 Low quality of original data
 Inaccurate source metadata
Operator faults
These faults are usually caused by some form or operator error within the workflow and can
include:
 Basic capture faults;
 Cropping that has cut into the image, is too loose, or is uneven;
 Orientation of the image is the wrong way around or upside down;
 Exposure of the image is too light or too dark
 Focus, where the image is out of focus;
 Daily calibration, where the capture device has not been calibrated;
 Basic image processing faults;
270
 File Optimization Faults, where incorrect adjustments are made to the color,
contrast and brightness of the image during processing;
 Incorrect file-naming, where image file are incorrectly named or use non-unique
names;
 Basic metadata attribution faults;
 Incorrect data entry, where data is incorrectly entered into the management control
system;
271
10. PROJECT STAGES

Hardware for digitization process

Calendar Months
1.Data inspection Workflow and
processes are Supplier + CO
established
2.Inception and pilot period Inception report
Supplier + CO
delivery
3. Digitization process Digital archive
produced Supplier + CO
+ RO
4.Data migration Existent digital data
converted in new
format
5. Testing and Acceptance Acceptance of the Supplier +CO
system
6. Implementation and Digital archive ready CO

Operational Tests for Final for production and
Acceptance usage
CO - Central Office; RO – Regional Office;

272
11. MILESTONE
Inception Project Work Plan
Accepted Digitization and Migration Methodology
Data digitization and Accepted Digitized Data
incorporation Accepted Migrated Data
Implementation Accepted Implementation of Digital Archive
Accepted Documentation
Operation Accepted procedures for going life with the digital archive
Accepted Operation digital Archive (Warranty period)

Milestones) are provided. The Bidder is expected to complete and adjust this table based on
the chosen approach.
No. Description Deliverable Delivery Acceptance Liquidated

Type (from (from Damages

Report
1 Data inspection Work Product: June 2011 July 2011 No
Report
M1 2 Develop Digitization and Work Product: July2011 July 2011
Migration Methodology Report
Inception Milestone July 2011 July 20111 No
3 Data Digitization Work Product: August 2011 January 2012 No

Digital Archive
4 Data Migration Work Product: December 2011 February 2012 No

M2 Incorporated
Database
Data digitization and

Milestone February 2012 February 2012 Yes
incorporation
5 Training Evaluation Work Product: February 2012 February 2012 No

Report
6 Documentation Work Product: February 2012 February 2012 No

Report
7 Implementation of Digital Work Product: February 2012 March 2012 No

M3 Archive and Operational Digital Archive
Tests for Final Acceptance installed and
operational
Implementation Milestone March 2012 March 2012 Yes

(Operational
Acceptance)
8 Accepted procedures for Work Product: March 2012 March 2012 No

going life with the Digital Report
Archive
M4
Operation Milestone March 2012 March 2012 No
274
13. SYSTEM INVENTORY TABLE (SUPPLY AND INSTALLATION

COST ITEMS)
described in this section. The Bidder is expected to complete and adjust this table based on
1 Data inspection All sites
2 Develop Digitization and Migration Methodology All sites
3 Data Digitization All sites
4 Data Migration All sites
7 Implementation of Digital Archive and Operational Tests for Final All sites
Acceptance
8 Accepted procedures for going live with the Digital Archive CO
275
14. SYSTEM INVENTORY TABLE (COSTS OF SERVICES)

Not applicable.
14.1 SITE TABLE

Site Code Site City / Town / Region

PRIMARY SITE

TO01

RO04 Zavhan

RO05 Orkhon

SUPPORTING SITES
276
PILLAR III - DEVELOPMENT OF THE ELECTRONIC

MONGOLIA PROPERTYREGISTRY SYSTEM /EPRS/
277
1. INTRODUCTION
This part of the document describes the functional and technical requirements for the
Electronic Mongolia Property Registration System (ePRS). The winning bidder will provide
goods and services for creating and implementing the ePRS system including:
 Provision of software meeting the functional requirements specified in the sections
below;
 Provision of maintenance and support for ePRS software systems over a period of
five years.
In preparing responses to this section, the Bidders are reminded that evaluation of the bids
will be carried out in conformance with the following criteria:
 A bid will be deemed as substantially responsive if it conforms to all the
mandatory requirements, terms, conditions and specifications of the bidding
documents without material deviation. A material deviation is one which affects in
any substantial way the functionality, scope, quality or performance of the
deliverables, or which limits in any substantial way, inconsistent with the bidding
documents, the Purchaser’s rights or the Bidder’s obligations under the Contract,
and the rectification of which deviation would affect unfairly the competitive
position of the other Bidders presenting substantially responsive bids.
 Individual technical solutions will be assessed to ascertain their acceptability in
response to the specifications contained in the bid and alternative solutions will be
evaluated on their own merits after the evaluation of the primary response. Some
of the factors in the evaluation of the bids will include:
o adherence to mandatory and preferred criteria;
o overall completeness and applicability to the business and technical
solution;
o technical solution, expandability, use of new technologies;
o thoroughness of the response to implementation, integration, and support
requirements.
 Bids which are not substantially responsive, as described above, will be rejected.
278
2. OBJECTIVE
Asresult of this tender bid, there will be developed and rolled outa new property registration
system to be used in all of its branches nationwide. This system will be called asElectronic
Mongolia Property Registry System (ePRS). The system should provide the following
advantages features over the current process:
 Fully supports GASR’s organizational strategy and E-governance using the latest
mature software and hardware technology;
 Fully supports the business processes for all registration types and customer
services by implementation of business process centric approach;
 To be a centralized web-based system built on a flexible enterprise architecture;
 Implements modern IT technologies such as Service Oriented Architecture (SOA),
N-tier applications and web services that allow easy customization and smooth
delivery;
 To be capable of providing services not only for GASR state registrars but for
other stakeholders like banks, notaries, tax authority etc.;
 To be integrated with digital archive system for storage, searching and retrieval
documents on what bases registered rights on immovable property is created,
changed or terminated;
 Supports views on the current legal status of immovable property: current size,
value and address of object; owners and ownership rights; current active
mortgages; current rights and restrictions of rights on this property, as well as
allows review of historical records;
 Performs monitoring of registration processes and producing statistical and other
kinds of reports from the registration database;
 Provides public access of registration information via internet portal and ensures
transparency of registration process;
 Includes a full range of security measures to protect information from losing,
misusage and unauthorized accessing.
279

In order to fulfill the requirements, the winning bidder should complete following tasks that
have split in to performance periods.
3.1 Inception period
 1st task for the Winning Bidder will be their Work Plan prepared using Microsoft
Project;
 During Inception period, the Bidder should closely cooperate with BlomInfo A/S
and GASR in order to fully understand current business process, property
registration system and facing difficulties. Also, the Bidder should learn about
proposed improved business process and IT system.
 Based on their collected information and below written Technical specifications,
the Supplier shall prepare detailed Definition on ePRS;
 Also, Analysis and requirements document should be developed in the Inception
period;
 The deliverable of the inception period will be the Inception report.
3.2 Designing period

 After the Inception report’s been accepted by MCA-M, the supplier should start
preparing Detailed design for the ePRS and the design should be approved having
advices from BlomInfo A/S and GASR;
 The Supplier must communicate with GASR and adjust and develop the
requirements based on current GASR status and requirements.
 The Site Preparation Plan will be the next task and this task also will be developed
having advised with above mentioned parties.
3.3 Development period

 Following sub-tasks shall be done step by step with active cooperation with
BlomInfo A/S and GASR:
 Development of Basic System Components
 Development of key Application modules
 Development of Front-end Solutions
 Next step is to build ePRS Pilot and here the developed system should be tested
with the joint effort of the BlomInfo A/S and GASR. The acceptance of the test
will be approved by GASR, MCA and consultancy Blominfo A/S and all
comments or open issues must be solved prior to implementation in production.
The test result should interactively be applied to the system and improved time-to-
time.
 The Training plan shall be developed and approved.
 Final approved version of the ePRS has to be accepted by the MCA-M.
3.4 Implementation period

 Supplier should start implementing the ePRS in the Consultancy scope areas;
280
 The Trainings should be conducted on the real system and prepare the users for the
roll-out. The following trainings must be conducted: ePRS system administration
training (including hardware, database, network and security training), ePRS users
training, ePRS support engineer training.
 The followed documents (System Administrator manual, User manual, ePRS
software source code etc.) shall be prepared.
3.5 Operation period

 Having done the final test, the ePRS should be started operating and the supplier
has to be monitoring all the steps of the registration and should be ready to fix any
possible errors, malfunctions;
 Also, it’s supplier’s full responsibility to take care of the system within its
Warranty period, along with GASR.
281
4. INTRODUCTION
The proposed architecture described in present chapter is based on an Enterprise Architecture
(EA) model, which consists from:
 Business Architecture (BA), describing:
 business processes;
 service structures;
 organization of activities.
 Information Architecture (IA), describing:
 high level structures of business information;
 data architecture, model and structures.
 Systems Architecture (SA), describing:
 fundamental organization of a system;
 components and applications;
 their relationships and integration;
 human interaction.
 Technology Architecture (TA), describing:
 technical infrastructure;
 security requirements.
282
5. BUSINESS ARCHITECTURE
5.1 Introduction
The implementation of an automated property registration system, especially one with a
centralized database at the national level, provides an opportunity for very many drastic
improvements in the level of service that can be provided to the public by GASR. One of the
main improvements should be building the system by using business process centric
technology. Unlike data (content) centric systems such as existing TRIADA and REAL
systems, the new registration system ePRS should be built to enable a GASR's business
processes, i.e. registration processes and customer services. Two concepts underlie the
emergence of business process centric IT system: service-oriented architecture (SOA), and
business process management (BPM). The present chapter gives brief description of
principles, business processes and services to be implemented by ePRS.
5.2 Principles
The basic principles/constraints for the ePRS from a business architecture viewpoint are:
 Business centric approach or methodology.
The system must support all business processes of GASR including immovable property
rights registration processes for different type of services, information requesting and delivery
processes, reporting processes and financial accounting processes. The system should be
process flow driven not only a data entry driven in means than system should control
sequence, completeness and decision-making from start to the end of overall process.
 Evolution of business operations.
Business operations should move from stove-piped procedural processes to discrete integrated
services that adapt to the needs of the consumers of those services.
 Evolvement of information.
Information should evolve from islands of information to knowledge-centric, interoperable

solutions grounded on a business-driven approach.
 Flexibility.
Technical implementation of business architecture should allow ease to make changes in

business processes by adding new processes, removing and changing existing processes and
their steps according of legislative changes and changes in business rules.
 Interoperability with external information resources and services.
The business architecture should include information exchange with external information
resources and service providers with the same status and functionality as internal business
procedures.
 Transparency of operations
System should provide full auditability to ensure full control on status and fulfillment of
registration steps.
283
5.3 Service structures

There are twenty-nine basic services concerning property registration at GASR offices. These
services are performed by a registrar, usually at the request of a member of the public. These
are:
10. First registration of property ownership rights for apartments which were
privatized.
11. First registration of property ownership rights for non-land immovable property
12. First registration of property ownership rights for movable property
13. First registration of ownership and utilization rights for land which was privatized
free of cost
14. First registration of ownership rights for property bought from the state
15. Buy–sell contract
16. Commercial (trade or barter) contract
17. Gift contract
18. Ownership change by contract or will
19. Change co-owner
20. Register rights to build on land owned by others.
21. Servitude
22. Usufruct
23. Rental Contract
24. Mortgage contract
25. Mortgage contract extension
26. Finalize mortgage contract
27. Extend contract other than mortgage
28. Finalize contract other than mortgage
29. Corrections to state registry
o Change occurs in property size due to re-survey
o Property location address changes
o Change erroneous information provided by owner
30. Re-issue new certificate to replace lost certificate
31. Re-issue new certificate to replace damaged certificate
32. Make preliminary-notice
 Make preliminary notice by inheritor’s request

 Make preliminary notice by the request of owner or buyer.
33. Ownership change through Court decision

34. Changes requested by the owner
35. Generate ownership reference
36. Generate copy
37. Ownership change by forcible auction sale
38. Close file
For each of these services, the procedure is more or less the same.
284
5.4 Business processes

The system should support the two types of business processes for registration of rights on
immovable property and issuing information from register:
 Application for service are received from applicant “in person”;
 Application for service are received electronically from agent who is authorized by
GASR to provide certain type of services to citizens – further called “Licensed
registrar”.
5.4.1 Application “in person”

Citizen comes to the service area of GASR office with documents necessary for registration.
He/she fills an application form manually or by using dedicated and public available access
point (as option there will be also possibility to fill application form in advance by connection
to the internet site of GASR). The applicant pays necessary service fees and delivers
application form together with documents to the clerk accepting applications. The application
is accepted for processing and citizen receives receipt on this. Then the application and
documents are delivered to the state registrar for processing of it. The processing includes
checking the application and the documents, validation of data against external registers,
recording rights into system, producing certificate, scanning documents and adding them to
the electronic archive. After completion of a case clerk distribute certificate and documents to
be returned to the applicant.
The process flow is shown in Figure.
285
Electroonic applicaations
Citizen comes to a licensed reggistrar (notaary, bank cllerk). Licen nsed registraar provides
necessaary service to the citizenn to preparee applicationn (obtains necessary
n innformation,
2
286
prepares agreement etc.). Then licensed registrar connects to the ePRS customer service site
by using his account and fills online application form by entering minimum data. The
documents for registration are prepared electronically or scanned and uploaded to the ePRS
customer service site. The application is registered automatically and licensed registrar
receives application registration number (this number can be used later for requesting tracking
information about status of processing of application), which can be delivered to applicant.
Then the application and electronic documents are delivered to the state registrar for
processing of it. The processing includes check application and documents, validation of data
against external registers, recording rights into system, producing certificate, adding received
electronic documents to the electronic archive. If it is required to inspect original documents
in paper format before completion of case, registrar sends them to GASR. After completion of
case clerk distribute certificate and documents to be returned to the applicant.
The process flow is shown in Figure.
287
288
6. INFORMATION ARCHITECTURE
6.1 Introduction
The requirements for how the data is organized in the immovable property register are set up
in article 17 of the Law of Mongolia designated “On registration of the right to own a
property and of other property rights related to it” from 19.06.2003. The requirement reads
that each immovable property ownership right “…shall be registered separately and shall have
individual file to store information about property, rights connected with it (mortgages,
possession, and other rights) and also all claims, applications and issued references in relation
of this property.” In fact, it is stated that registration should be based on ownership rights. For
needs of ePRS it should be clarified the current approach by stating (including through
legislation) that registration should be strictly based on immovable property i.e. each
registered immovable property (land, buildings, apartments) will have an individual file
within the register. By making this distinction we will have a clear basis on which to base the
data model as well as the principles with which to exchange information between the existing
cadastre and the new system.
6.2 Principles
The basic principles/constraints for the ePRS from an information architecture viewpoint are:
 Immovable property centric data model.
The information architecture should support an immovable property centric approach where
the immovable property objects e.g. land, building, apartment play a role as an asset that
registration rights can be attached to. This approach corresponds to the modern cadastre
concept, serves for good integration with cadastral data, and can easily be spatially referenced
and integrated with NLIS. In the future the principles laid out in this system can be expanded
to create an integrated immovable property registration system which can include information
about all immovable property whether it’s technical, fiscal, or legal.
 The data model to support business processes.
The data architecture should support all business and registration processes as well as be able
to track all changes to the content of the register data. It should be easy to recognize by which
application and upon which legal basis any particular record or rights is created, changed, or
terminated.
 Linkage with external data.
The data should be directly connectable on an entity level with the person’s data in the Civil
Registration System, with the immovable property objects in the cadastral system, as well as
with all documents stored in digital archives.
 View on current legal status of immovable property.
The data model should allow users to easily view the current legal status of immovable
properties, including: current size, value and address of object, which has ownership rights on
it, current active mortgages, and current rights and restrictions of rights on this property. The
reason for this requirement is that there is a provision that register books should register and
store all changes on the creation of new rights as well as changes and termination of existing
289
rights. IIn the case that

t there is an active im mmovable property
p maarket in the future, there is a
risk thatt a large vollume of chaanged and teerminated reecords will make it diffficult to keeep track
of legal data if the informationn is not prop
perly organiized. This iss a commonn problem with
w land
book typpe registration systemss.
 Auditingg of changees.
The data model shoould supporrt the storagge of auditinng informatiion: when were
w the records
created,, who createed the recorrds, when thhe records were
w changeed, who channged the reccords,
when thhe records were
w deletedd, who deletted the records, etc. Ad dditionally the
t system should
s
keep traack of the prrevious conntent for records that are changed or
o deleted——so that histtorical
informaation is neveer completely deleted.
6.3 Data moodel
The Chaairman of GASR
G in Reesolution Noo. 142 proviides detailed information regardinng the
data conntent of the register. Baased on thiss resolution a brief norm
malized dataa model of tthe
proposeed registratioon book is created
c and representedd in Error! Referencee source nott
found..
Descripption of entitties:
 AIMAG GS and SUO OMS shows administraative units of the Mongoolia;
 IMMOV VABLE PR ROPERTIE ES containss basic innformation about imm movable
propertiies and eachh record corrresponds too one individdual file;
 INITIAL L OWNER – owner off property affter first reggistration;
 OWNER RS – ownnership channges (transsferring of ownershipp, adding new n co-
owners, cancelling ownership rights);
 MORTG GAGES – mortgage
m reccords (creattion, modifiications, terrminations);;
 OTHER R RIGHTS – other righ hts (creationn, modificatiion, terminaation);
2
290
 SPECIAL AND PRELIMINARY RECORDS – notes on restriction and restitution

of rights;
 CLOSURE RECORDS – records on closure of registration file in cases foreseen in
law;
 REFERENCES AND COPIES – records on issuing references and copies for file;
 APPLICATIONS – records to store application data;
 DOCUMENTS – references to the copies of documents which show legal ground
of rights;
 REFUSALS – records describing reason and legal ground for refusing the
application.
The main principles included in this data model are:

 The registration data is organized around immovable property. Records of
immovable properties are organized according to administrative divisions of the
Mongolia;
 Records which describe rights are organized according to the current structure of
register books;
 Applications for registration and other claims are stored separately;
 References to the attached documents are stored separately and are referenced to
the application;
 Each record which describes the rights has a reference to the application as well as
to the document(s) concerning the legal grounds of the rights.
Because rights can be described in a similar way, this model can be generalized (de-
normalized) as shown in next figure. In this model the persons (owners, claimants, persons
with interests on immovable property) are extracted as a separate entity labeled PERSONS.
This entity will have a direct connection with the Civil Registration System.
291
Figure 3 - De-norm
malized daata model foor register book (prop
posal)
The models propossed above caan be used as

a the initiaal basis for a more detaiiled data annalysis.
2
292
7. SYSTEMS ARCHITECTURE
7.1 Introduction
The ePRS must be organized as centralized system which provides immovable property
registration and information delivery services in real time with actual data regardless of
circumstances where system should functioning in a distributed environment where
registration offices are located at a great distance one from another.
The ePRS system should be stored in Nation Data Center in Ulaanbaatar to allow property
registrations to be initiated without regard to location, and to access information concerning
property rights at any location and from any location in Mongolia as well as to assure the full
continuity of the process.
Functional Areas and Components

The proposed ePRS application should consist of following functional areas (components):
 Licensed Registrar Account Management;
 Registration Officer Account Management;
 Application processing;
 Registration;
 Searching and displaying;
 Archiving;
 Accounting;
 Reporting;
 Workflow management;
 Internet portal;
 Information services.
The requirements for these functional areas will be further listed in sub-section C, "Functional
Requirements", below. However, a brief description of those areas is given below.
Functional Area Description
Licensed Registrar The functionality which allow Licensed Registrars to be registered as users of the
Account Management system for the purpose of initiating property registration transactions.
Registration Officer The functionality for registration receiving clerks and State Registrars of GASR as
Account Management users of the system...
Application management Comprises functionality for receiving application electronically and “in person”,
entering and processing application data, adding documents to the electronic
archive, notifying applicant or licensed registrar, distributions application to the
state registrar.
Registration Provides functionality for state registrars: receiving application and documents from
electronic archive, reviewing application, providing data checking against register
of immovable properties and external registers, making decision and entering
registered rights into register.
Searching and displaying Provides searching functionality in register of immovable properties and electronic
archive by different search criteria and displaying search results as register records
and electronic documents.
Archiving Comprises functionality for storing and managing electronic documents and their
metadata in digital archive
Accounting Includes accounting functions within the ePRS to show the current financial
293
Functional Area Description

position of the Property Registration system, including: Total assets and liabilities,
Individual bank account balances, Amounts collected and processed by transaction
type, Amounts outstanding in Licensed Registrar accounts, Funds deposited by
citizens for non-Licensed Registrar transactions that have not yet been used
Reporting Management reports, financial reports, statistical reporting, management reporting,
analytical reporting and data mining
Workflow management Functions for maintaining of workflows for business processes implemented in
ePRS and tools for monitoring workflows and their performance.
Internet portal Publication of general information about immovable property registration and allow
accessing of ePRS information to the professional users and general public.
Information services Providing web services to the external organizations such as Administration of
Land Affairs, Construction, Geodesy and Cartography ALACGaC, notaries, Tax
authority, banks, etc., as well as interfaces within General Authority for State
Registration (GASR) (such as to financial accounting systems or the civil
registration system).
General Application-wide concerns such as nationalization, browser requirements, etc.
7.2 Interfaces
The system will need to support interfaces within and with external systems. These interfaces
need to be built to provide data integrity and auditability.
It is expected that some interfaces between systems will be "batch" or flat-file interfaces. In
these types of interfaces, data is exported into a file, which is transported either via physical
media, or electronically via some method such as FTP to the receiving system. Once at the
receiving system, the file is imported using a mechanism of the application.
Other interfaces will be on-line real-time interfaces, such as interfaces to ALACGaC for
property cadastre lookup or to the Civil Registration or Legal Registration systems for
individual or legal entity lookups. These interfaces will ideally be implemented using web
services or some other SOA-like mechanism.
Interface formats vary depending on the type of systems that are interacting. As a general
principle, all interfaces should if possible be based on XML, which provides a powerful
mechanism for ensuring that interface records conform to a pre-defined standard. However,
we do realize that certain existing systems may already have non-XML interface mechanisms.
In those cases it is more expedient to adapt to the existing interface mechanism than to create
a conforming one.
7.2.1 Batch Interfaces
 Banks:
 Recording of Licensed Registrar deposits
 Reconciliation of individual fee deposits
 Financial Accounting System:
 Transactions to reflect, in the Financial Accounting System, current assets and
liabilities incurred via Property Registration.
7.2.2 On-Line Interfaces

The on-line interfaces should be developed as web servicesmostly. They include:
 GASR’s Civil registration system:
294
o Requesting and receiving information about natural persons for checking

and including in ePRS;
o Implementation of reading the bar-code system that will be implemented in
the new Civil registration system
o Implement reading personid card using smart card readers, and request
information in Civil registration system
 GASR’s Register of legal entities:
o Requesting and receiving information about legal entities for checking and
including in ePRS;
 ALACGaC:
o Delivering by search request information from immovable property
register;
o Notifying ALACGaC about changes of cadastral data in ePRS;
o Requesting and receiving cadastral information for checking and including
in ePRS;
o Accepting notifications about changes of cadastral data in ALACGaC
information system.
 Land offices:
register;
o Accepting applications for first registration from licensed registrar;
 Notaries:
register;
o Accepting applications for registration of rights from notary as licensed
registrar.
 Tax office:
register;
o Delivering by request monthly reports about ownership changes;
o Accepting applications for recording of notes about restrictions on
immovable property from licensed registrar.
 Banks:
register;
o Accepting applications for registration and cancellation of mortgages from
licensed registrar.
7.3 Security requirements

Security requirements for ePRS include:
 Use of secured transport technologies wherever necessary
Secure Sockets Layer (SSL) technology should be used at a minimum for the following
processes:
295
 Any data entry functions

 Log in and user registration
 Performing administrative functions
SSL should also be used for transmitting any data between systems over the network, for
instance to/from banks or other government agencies.
 Delegated authentication/authorization model
Rather than a single authority to create users and assign rights within the system, this system
should allow authorized individual users to assign rights to other users within their
organization. This will reduce the number of staff needed for centralized support. A guiding
principle should be that no user can assign rights to another user that are higher than the users
own rights.
 Pervasive logging and auditability
All updates to records within the system should be able to be attributed to a particular user. A
log of all updates to all records should be maintained and easily viewable within the
application.
 Firewalls and other perimeter security
Firewalls should prevent unauthorized access to the application servers, and prevent any
direct access to the database servers from outside the data center.
296
8. VOLUMETRIC ANALYSIS
8.1 Introduction
Volumetric analysis is the process of examining a database and determining the type of data
stored and its expected rate of growth. This information is useful when choosing the hardware
on which the database will be hosted. Volumetric analysis should always take into
consideration the complete database including all indexes, both clustered and un-clustered.
The final projections outlined here are liberal estimates only, which are based on certain
technical and usage assumptions.
While volumetric analysis is an important part in determining the size of the database, many
other factors are needed to be considered to optimize database performance. These include
Processor speed, memory, hard-drive speed and fragmentation, RAID configurations,
transaction logging, table and query design, indexing, network capabilities, memory tuning,
user security and others.
The current volumetric analysis is done for registration database only nor for digital archive
as part of ePRS.
8.2 Technical Assumptions
The projections listed below are based on the usage of an Oracle Database Server or
Microsoft SQL Server database hosting the ePRS database as created according principles of
information architecture described in chapter 6. This database is fully indexed, normalized
and contains full referential integrity constraints.
8.3 Population Assumptions
For estimation of amount of space necessary for storage registration information the existing
TRIADA database is analyzed. The analysis includes obtaining information about sizes data
segments occupied by primary data tables and their indexes, counting number of records and
estimation of average record sizes. The results are represented in table.
Data segment Average space for
Number of
Data table size one record
records
(bytes) (bytes)
Property objects 22151168 200185 111
Land parcels 2818048 25767 109
Buildings 5046272 45657 111
Apartments 10289152 103724 99
Addresses 86835200 232965 373
Subjects 54591488 452847 121
Natural persons 71434240 447164 160
Legal persons 720896 5689 127
Applications 162922496 890176 183
Processes 121962496 873219 140
Basements (documents) 478871552 2777322 172
Relations 48300032 406758 119
Certificates 24772608 200013 124
The following considerations are used for estimation of the size for one record of basic
information units (property objects, subjects, applications and certificates):
297
 The prooperty objecct includes general information, data of onee object typpe (land
parcel, building
b or apartment) and addresss;
 Subject includes general
g info
ormation, daata of one subject typpe (natural or legal
person) and address;
 Applicaation includees applicatio
on record ittself, one prrocess recorrd per appliccation, 3
documeent records per
p applicattion and 0.5 relation reccords per appplication;
 To incluude space for
fo cross refferencing off records av verage recorrd size is multiplied
m
by facto
or 1.2.
The finaal record sizzes are as foollows:

Record siize
Data unit
(bytes)
Property object 714
Subject 785
Applicatiion 899
Certificatte 124
8.4 Usage Assumptio

A ons
All dataabase size annd index caalculations have
h been determined
d using
u the following
informaation of dynnamics of registration reeceived from m TRIADA A database. Taking
T in thhe
accountt that accordding GASR registration n statistics on
o September 1st year 2010
2 the 3990
thousannds immovabble propertyy was registtered Monggolia wide an nd 207 thouusands fromm them
in Ulaannbaatar, thee estimation based on UB
U statisticss are multiplied by 2.
Numberr of registerred immovaable property y objects peer month is shown in diagram beloow.
From thhe diagram, excluding thet exceptioonal registraation rate beetween yearrs 2006-20008 from
consideration, it caan be concluuded that thee average growthrate of
o immovable property objects
will nott exceed 30000 per montth in UB annd 6000 per month the regions.
r
Numberr of registerred subjects (persons) per
p month iss shown in diagram
d bellow.
2
298
The diagram gives estimation of constantt growth of nnew registeered subjects by 4000 per
p
month iin UB and 8000
8 per moonth in Monngolia wide..
Dynamiics of proceessed application or reggistration:
The diagram showss a linear grrowth rate for f number of o processedd applicatioons before thhe
econom mic crisis, bu
ut for simpliification, it can be assuumed that nu umber of appplications in
i UB
cannot exceed
e 120000 per montth and 240000 per montth in regionss.
It is imppossible to obtain
o data about dynam mics of issuued certificaates and be assumed thhat the
growth rate of certiificates is saame as the growth
g rate of property y objects.
8.5 Total Da
atabase Size
Using aassumptionss stated abovve, the projeected size of
o a databasee for currennt state (September
1st 20100) would bee approximaately 2 524 megabytes.
m This includdes both basse table sizee and
indexes, but does not
n include tthe databasee transactionn log.
8.6 Transacction Log Size
Once thhe database table size has
h been estiimated, the transaction log needs to t be considdered.
The sizee and naturee of the trannsaction logg should be sets by the database
d adm
ministrator
accordinng to the neeeds of the business.
b Thhe size of thhe transactioon log is gennerally set as
a a
percentaage of the database
d sizee and is prim
marily based on the exp pected transsaction leveel and
the rate that transacction logs arre saved to either disk or tape storrage.
8.7 Projecteed Futuree Growth
2
299
Based on the assumptions above, and further assuming that the clients, sites and asset metrics
remain unchanged, the only significant growth in the database will be due to the recording
application data, adding new subjects, immovable property objects and issuing certificates.
Based on a registration of further 72000 immovable properties per annum (6000 per month),
recording data on 96000 subjects per annum (8000 per month), data on 288000 applications
per annum (24000 per month) and data about 72000 issued certificates per annum (6000 per
month), the database can be expected to grow by approximately 376 megabytes per year. The
table below displays the database growth over 5 years, with a 30% size transaction log.
30 % transaction log
Processed Table size Total size (in
Year size
applications (in megabytes) megabytes)
(in megabytes)
1st year 288000 2900 (2524+376) 870 3770
2nd year 288000 3276 983 4259
3rd year 288000 3652 1096 4748
4th year 288000 4028 1208 5236
5th year 288000 4404 1321 5725
300
9. FUNCTIONAL REQUIREMENTS
9.1 Introduction
The following requirements describe an Electronic Mongolia Property Registry System for
GASR in Mongolia (ePRS).
The bidder must take into account that these are preliminary high-level requirements and will
be subject to change as the analysis and design phases of the project get underway. It is
estimated that approximately 10% of the currently stated requirements could be subject to
change, and that a number of additional requirements equal to approximately 10% of the total
current requirements could be added.
9.2 Structure
In the following sections, a description of the basic functionality of the respective functional
area will be followed by a list of sub-functional areas within the functional area. For each sub-
functional area, a table of requirements will appear in the following format:
Mandatory
(Y/N)
X10001 Y The requirement goes here Any notes go here
where the individual columns are defined as:
ID Identification of the requirement in the format XSNNNN, where X is the

first letter of the functional area name, S is the number of the sub-
functional area as listed at the beginning of the section, and NNNN is a
sequence number for the requirement. Each requirement should have its
own ID that is unique within this entire document.
Mandatory (Y/N) "Y" if this is a mandatory requirement, "N" if it is not mandatory.
Inclusion of non-mandatory requirements in a proposal will earn the
Supplier extra points in the scoring of bids.
Requirement The text of the requirement.
Description
Notes Further clarification or explanation of the requirement.
301
10. GENERAL REQUIREMENTS

10.1 Introduction
This section details the general requirements of the ePRS system.
The Sub-Functional Areas of the General Requirements are:
1. User Interface and Portal
2. Documentation & Help
3. Security, Authentication, and Authorization
4. Platform
5. Error Handing
6. Licensing
7. System Configuration and Metadata
8. System Administration
9. Toolset
10.2 User Interface and Portal
Mandatory
(Y/N)
The system must provide the user with an interface
in English and Mongolian and support the
Mongolian character set according to ISO standards.
G1001 Y
The system should be developed in such way that
supplementary languages can be added later in the
system.
The coding of Mongolian characters in the database
must be based on UNICODE and UTF-8 encoding.
G1002 Y
The system shall provide for ease of use and

G1003 Y navigation by inexperienced users.
Menus, screens, tabs, and fields should be clear and

G1004 Y
readable and visible by normal users.
Navigation between menus, screens, and tabs must
be logical. The system should allow access to any
G1005 Y related function from any page without forcing the
use of the browser "Back" key. All required links
should be included in each page.
The system shall follow a modular design with
distinct functional sub-systems and components and
G1006 Y
common software layers and services
All searches in the system must provide the

capability for specifying filters (filtering on values
G1007 Y
or ranges of values) and for sorting the output by
any column.
The system must allow the user to work with
G1008 Y multiple windows or tabs into the system
simultaneously.
302
Mandatory
(Y/N)
The system must support the effective use of
G1009 Y multiple monitors if available.
The system will always display dates in

G1010 Y Year/Month/Day format.
The system user interface must contain a gender box

for all input forms that contains such information.
G1011 Y
This information is useful in creating statistical
reports related to property registration
10.3 Documentation and Help

Mandatory
(Y/N)
The system shall provide integrated Help
documentation .There should be an extensive Help
G2001 Y file that is accessible from any point of the system
which will give users of the system information on
how to perform common tasks
Users must be able to access Help documents from
G2002 Y any web page within the system
Help must be available at the page and field level.

G2003 Y
Documentation of all application software must

include full descriptions of all input forms, tables,
G2004 Y files, inquiries, and error messages in Mongolian.
Database technical documents in English must be Database technical

provided. documents in Mongolian
G2005 Y
are also welcome, but not
mandatory.
System installation documents must be provided, in
G2006 Y English and Mongolian.
End-user documentation, including user manuals and

guides, must be provided in both soft copy and hard
G2007 Y copy form, in the Mongolian language.
The bidder must provide a solution for establishing

an end-user training environment such that trainees
G2008 Y can operate the system without introducing
operational data into the system.
The system’s data structure must be represented by
an entity-relationship diagram readily available to
G2009 Y GASR, in English and Mongolian.
Documentation for disaster recovery must be

G2010 Y available in Mongolian.
303
Mandatory
(Y/N)
The Supplier will produce a DVD video disk to train
G2011 Y end users in the operation of the system.
The help functionality must include a search tool to

allow end-users to search for relevant help by
G2012 Y
searching for keywords and phrases within the help
text.
10.4 Security, Authentication, and Authorization

Mandatory
(Y/N)
The system must provide a user access
management function that enables a system
administrator to configure user accessibility to
G3001 Y
system services and information based on
configurable access profiles of individual users,
roles and groups of users
User security groups are divided into different
levels of hierarchy, e.g. System administration,
G3003 Y
functional administration, application
processing, registration, review, end user etc.
Only authorized users at the GASR will be able Must log changes
to update metadata such as codes, types, location including 1) before and
codes, accounts, templates, calendars, after, 2) name of updater,
G3004 Y
workflows, etc. Updates to all metadata must be 3) date of update, 4)
logged in the same manner as register changes comment, 5) IP address
are logged. of updater
The security mechanism must be delegable, such
that a user at a certain level and with certain
G3005 Y
rights may create users at the same or lower
level with a subset of his/her own rights.
The system will enforce the use of a user login For instance, a password
and a moderately strong password. The must not be the reverse
password must contain at a minimum eight of the login name, or
characters, of which at least two must be non- based on a subset of the
G3006 Y alphabetic, and must not be derived from the login name. By
login. alphabetic in this case
we mean to include both
the Mongolian (Cyrillic)
and Latin alphabets.
Audit trails and change logs to all data in the
system must be readily viewable by all users in
G3007 Y
the system.
System security must enable users of all levels

to operate on the system within the restrictions
G3008 Y imposed by the responsible system controllers.
The policy of determining who will operate on
the system and what functions they will perform
304
Mandatory
(Y/N)
must be able to be carried out in the central
office, usually on advice or request from local
managers, or by individuals to whom such
capabilities have been delegated..
The system must provide a system-wide privacy
and security facility such that in no instance is
G3009 Y personally identifiable information available to
anyone except for duly authorized system
administrators and auditors.
The system must force users logging into the
system, registering with the system, or making
G3010 Y any updates within the system to use a secure
mechanism for connecting to the application,
such as SSL for web applications.
The system must allow for detection, reporting,
and investigation of unauthorized access to data.
G3011 Y
As part of the proposed solution the Bidder must

include measures to minimize the possibility of
G3012 Y accidental or malicious destruction/alteration of
data, and measures in the system to reverse and
fully recover from such possible events.
The system must include mechanisms that allow
the System Administrator to define access rights
G3013 Y by users, groups and roles, for categories of
operation, such as define/manage, insert, delete,
update, read and execute.
The system must support single sign-on (single
user identification password) to access all core
G3014 Y
modules for which access is required.
The system must provide the ability for a limit

to be placed on the number of
G3015 Y unsuccessful/unauthorized attempts at a
particular operation, and lock the user session
accordingly.
The system must keep audit trail of
G3016 Y unsuccessful/unauthorized attempts to access the
system.
The system must log a user off automatically
after a period of inactivity. This period should
G3017 Y be definable by a system administrator as a
system option maintained via a user interface in
the system.
The system must provide end-users with a
means of resetting or recovering a lost password,
G3018 Y
such as a password mailing tool.
305
Mandatory
(Y/N)
Unsuccessful login attempts must be logged and
available to a system administrator. The log
must include the number of attempts, login name
G3019 Y attempted, IP addresses of the client making the
request. After a set number of unsuccessful login
attempts, the user's account must be locked and
may only be re-activated by an administrator.
All user logins and logouts must be logged.
Information captured in the log must include
G3020 Y
user id, date, time, duration of session, IP
address
10.5 Platform
Mandatory
(Y/N)
The system must be installable in a server
environment for shared use.
G4001 Y
The system must be able to support up to 500 For purposes of

simultaneous users. performance and capacity
forecasting, a simultaneous
G4002 Y user may be considered an
individual who submits a
page an average of once
every 30 seconds.
It must be possible to use a standard Intel- Linux and Mac
compatible PC with a 32- or 64-bit Windows workstations may also be
G4003 Y
operating system and a web browser as a front-end used...
workstation.
The system must use a standard and readily DBMSs that qualify
available relational database management system, include Oracle, Microsoft
G4004 Y not one which is proprietarily unique to this SQL/Server, Sybase, DB2,
application. Approved database software system PostgreeSQL
MUST be procured together with related hardware.
The database software MUST offer advanced
security features, such as encryption, transparent
auditing, and centralized key management within
G4005 Y the built-in license.
The database software should provide a simple
tiered SKU licensing model to provide lower TCO
over time.
The system must support all commonly used web Microsoft Internet
browsers. Explorer 8 and above;
G4006 Y
Mozilla Firefox 3 and
above; Chrome and Safari
306
Mandatory
(Y/N)
The system must provide following response time:
The simple screen forms without complex business
logic should appear within 3 seconds;
Database query returning up to 100 records at 95%
cases should be performed within 5 seconds;
Database query returning more than 100 records at
G4007 Y
95% cases should be performed within 15 seconds;
Inserting or deleting one record at 95% cases should
be performed within 5 seconds.
The system should display appropriate warning in
cases when response from database is expected to
take more than 3 minutes.
10.6 Error Handling

Mandatory
(Y/N)
The system must provide an exception and error
handling service across all its components. The
service must support meaningful and timely user
G5001 Y messages in Mongolian, an exception notification and
monitoring console for an administrator to monitor
critical server state and write a readable exception
trace
Error and other informational messages must describe
adequately the cause of errors and options available to
G5002 Y continue.
10.7 Licensing
Mandatory
(Y/N)
ePRS shall be developed as a custom application for
this project. The software must be wholly owned by
MCA and not subject to any additional licensing
except for those third-party tools and facilities (such
as the database) that may be required to be licensed
G6001 Y separately.
After September 2013 MCA will transfer to the
Mongolian Government all property rights on the
ePRS and MCA cannot use the ePRS in future
projects. The Mongolian government can not sale for
third parties or use the ePRS outside of the Mongolia.
10.8 System Configuration and Metadata

Mandatory
(Y/N)
307
Mandatory
(Y/N)
The system will provide a user interface for system
administrators to use in configuring all required
G7001 Y system metadata such as code tables, calendars,
location codes, and user security levels and rights.
The system must provide automated functionality to
make fiscal year driven metadata available in
G7002 Y subsequent fiscal years.
The system should be capable of receiving software Extra points for this
updates delivered via the internet. capability
G7003 N
10.9 System Administration

Mandatory
(Y/N)
The system must audit all transactions in a
common audit trail file at the server. The file
G8001 Y
must be accessible to an administrator.
The system must have detailed backup and

G8002 Y
recovery capability.
The system must ensure data integrity in the
G8003 Y event of a hardware or software failure.
The system must allow for recovery of
G8004 Y transactions in progress after a hardware or
software failure.
The system must identify files that have been
G8005 Y changed and those that will be saved for
recovery purposes.
The system must provide facility for backups.
G8007 Y
The system must provide options for on-line

G8008 Y (while the Application Software is up and
running) backup.
Backup and restore operations should be
G8013 N
programmable,
Backup and restore operations should be
G8014 N
remotely operable.
Backup and restore operations should be able to
G8015 N be logged.
The system should provide control features such
as input and update counts, batch totals, update
G8016 N
audit listings, error report generation, etc.
308
Mandatory
(Y/N)
The system will provide a system administrator
G8017 Y the ability to archive a given year's entire set of
data and delete it.
10.10 Toolset
Mandatory
(Y/N)
Facilities and toolsets must be available for the
following:
G9001 Y 1. Tailoring existing update/inquiry transactions
2. Developing custom reports
3. Developing queries
10.11 Training
The GASR needs to upgrade their capacity to a level that enables this institution to perform
their IT related duties professionally. The implementation of the system requires trained users
at both advanced (system administrator and maintenance) and user level. The training
requirements were listedalready in previous chapters. Below are the further details of the
ePRS training requirements.
In the context of this project the issue of building capacity for operation and maintenance of
the ICT-systems needs special attention. On various levels at the State Property Management
administration there will be a need for IT skills which for convenience are divided into two
types:
 IT user skills for efficient use and administration and maintenance of existing
applications
 IT professional skills for development, implementation and revision of ICT
systems
The physical placement of the system will be the office(s) of GASR in Ulaanbaatar. Thus, IT
professionals there have to be trained as well in the usage and maintenance of the system and
its application(s).
Bidder MUST develop and provide specified training aimed at IT user skills for efficient use
of ePRS system.
Resource-wise there is a great task in building and development of the capacity of IT
user skills as part of sustainability. The challenge is to ensure an efficient use of IT and
simultaneously to be patient enough to see the investment in a broader perspective to avoid
sub-optimizing. A focused development of user capacities will improve the quality of the IT
usage and the need of help desk capacity will be less.
All users need to be trained within their role(s) in the use of the ePRS System. The following
training shall be provided by the Supplier to train the users to use the system during the
schedule of system development:
309
 Management training; aimed at (high and middle level) management of GASR,

and their use of the system(s), disaster scenario’s, security, impact on the business
and etc.
 Staff members training; aimed to train all personal involved during the land
registry processes
 IT Administrators Training (technical maintenance, programmer, security, network
administrator, database administrator and etc.)
These trainings are role-based and can be further designed, divided and detailed based
on the authorization and role (stakeholder) design of the systems.
The Supplier in strong collaboration with consultancy Blominfo A/S will organize the
trainings based on a common schedule.
The Bidder MUST develop and provide specified training aimed at "train-the-
trainer"&support engineer (help desk) skills for ePRS.
The Supplier shall train consultancy Blominfo A/S as trainers with regard to the use of the
applications, and provide capacity to further train the Client staff members for process
operation. The consultancy will continue the implementation on training for all employees
regarding the use of applications. Also this type of training should be applied to a fraction of
GASR IT department appointed staff members (up to 15 experts) to accumulate the
knowledge that will help them also to perform the 1st line help-desk support with regard to the
use of the applications, and they will need advanced application administration knowledge for
this task. The knowledge that these trainers will gain is considered to be application specific,
and less generic in the sense of general IT skills.
The bidder MUST develop IT technical skills for administration and maintenance
development, implementation and revision of ePRS system
In the current situation all IT tasks in GASR are performed by a team of developers and IT
specialists that are not certified in specific domains of administration or developing. This is a
situation which leads to a lack of specialist knowledge. As at the moment there is insufficient
knowledge on DBA, testing and security. This problem will grow as the functionality of the
system will extend.
Therefore the staffing of GASR offices with regard to IT technical skills is and will remain to
be difficult, based on the difficulties of keeping employed increasingly better trained staff,
and the ratio between government and private sector salaries. However it is important to
ensure that core technical IT skills are available inside the organization of GASR. These skills
are in particular relevant for handling relations with suppliers, partners, and external experts.
By GASR a core team has to be established of a team with skills on the following
areas:
 User support (Application Enhancement, Errors, Management of trainers)
310
In order to get as smooth as possible knowledge transfer and in order to assure the high level
of sustainability of developed system and solutions, the GASR makes his IT team available to
the future ePRS Supplier based on part time participation in various phases of the project.
This means that GASR will be actively involved on the side of the Supplier e.g. providing
detail info on existing system, and as well participating in the system development as
supportive experts. The consultancy Blominfo A/S will be fully involved and helping in
understanding the existing system and providing the vision for the ePRS system. However,
the responsibility for the project, regarding its timely delivery, the completeness and quality
of deliverables, etc. will still be fully on the side of the Supplier.
The ePRS system administrator training (consider 8 selected IT experts from GASR central
IT department) has to include system training, database training, network maintenance
training and system security
The ePRS user training has to explicitly include special part that involves part of the finance
that relates with ePRS system. Estimated number is 100 people, but correct number of
attendants will be establish during discussions and agreement with GASR and Blom in the
inception period of the contract. The training has to be delivered in local offices, and for each
office it has to be at least 10 days. The delivery will be accepted based on the signed
document by each of the office head that staff received the system usage training, and fully
understand the system usage.
Support engineer training is estimated to be for 15 selected IT experts from GASR central IT
department. The duration of the training should be at least 10 days. The training has to include
the following:
 Methodologies to ensure the 1st line-support for the users (online, remote support
etc.)
 1st line-support training for all aspects of the system including operational
hardware issues
Mandatory
(Y/N)
Develop and provide specified training aimed at
IT user skills for efficient use of ePRS system.
G10001 Y
Develop and provide specified training aimed to

1st line help-desk skills for ePRS as support
G10003 Y
engineer training
Develop IT technical skills for administration

and maintenance development, implementation
G10004 Y and revision of ePRS system, database
administration, network maintenance and
security.
311
11. LICENSED REGISTRAR ACCOUNT MANAGEMENT

REQUIREMENTS
11.1 Introduction
The Sub-Functional Areas of the Licensed Registrar Account Management Requirements are:
1. General
2. Setup
3. Financial
11.2 General
The system will allow Licensed Registrars to be registered as users of the system for the
purpose of initiating property registration transactions. A person wishing to become a
Licensed Registrar will need to apply at the local aimag property registration office, where it
will be determined if the applicant meets the criteria for licensing. Once a Licensed Registrar
is licensed at any aimag, he or she becomes eligible to initiate property registration actions in
any aimag (again, for purposes of this discussion UlaanbaatarCity is treated the same as an
Aimag
Mandatory
(Y/N)
The system will allow Licensed Registrars to be
L1001 Y registered as users of the system.
Each Licensed Registrar will be issued a unique
personal account number when their user
L1002 Y account is set up. This Personal Account
Number (PAN) will be generated automatically
by the system.
Licensed Registrars must be able to initiate
property registrations in any location (aimag,
UB city), regardless of where the registrar
L1003 Y
applied. The system will require the aimag to be
specified with every property registration
transaction.
11.3 Setup
The system will allow persons who wish to become Licensed Registrars to apply online. The
system will collect all the relevant details online and forward the request to the individual in
the Property Registration Office of the relevant aimag who is responsible for processing
Licensed Registrar applications (the “examiner”).
The person processing the Licensed Registrar application may require further documentation
or an in-person meeting with the applicant. Once satisfied that the required criteria have been
met, the examiner will create the Licensed Registrar account in the system, and issue a login
and password to the Licensed Registrar.
312
Mandatory
(Y/N)
The system will allow persons who wish to
become Licensed Registrars to apply online. The
L2001 Y system will send the request to the individual in
the Property Registration Office of the relevant
aimag for approval.
The system will route applications to become
L2002 Y Licensed Registrars to a designated person
(examiner) at an aimag.
The system will allow the applicant to view the
L2003 Y progress of his/her application online.
The system will provide facilities for the
L2004 Y examiner to create a Licensed Registrar user
record and Personal Account Number (PAN).
The system will provide facilities for the
L2005 Y examiner to assign a username and password to
the Licensed Registrar applicant.
The system will provide a facility for an
L2006 Y examiner to suspend or revoke a Licensed
Registrar’s account, provided a reason is given.
The system will provide a facility for an
L2007 Y examiner to reinstate a Licensed Registrar’s
account, upon appeal.
The system will allow an administrator to define
a threshold for funds in a licensed registrar’s
L2008 Y account. If an account’s funds drop below the
defined threshold the system will display a
warning message.
11.4 Financial Functions for ePRS

GASR will maintain a bank account at a bank with nationwide presence that will be used for
Licensed Registrars to pre-deposit fee payments. A Licensed Registrar will deposit funds in
this GASR account, making sure the bank records the Registrar’s PAN number in the memo
field of the deposit. (For convenience, the system will give Licensed Registrars the ability to
print a deposit/transfer slip for the bank with this account information already printed on it.)
At least once a day the bank will be required to provide to GASR a list of transactions that
have been made against the bank account since the last business day. Preferably this list will
be sent electronically, and updates can be made automatically. Otherwise, GASR personnel
will need to process this list. The list will contain all deposits made by Licensed Registrars
since the previous business day, including the amount of the deposit, the receipt number of
the transaction, and the memo field, which should contain the PAN.
This information will be entered into the system, and the system will automatically credit the
individual PAN accounts with the funds.
In the case where a deposit was entered with an invalid PAN or a missing PAN, the amount
will be credited to a special account set up for this purpose. The Licensed Registrar will be
able to contact GASR and correct the account information on the basis of the receipt number
issued by the bank.
313
As Licensed Registrars perform registration transactions, the amount of the transaction is

debited from the Registrar’s account in the Property Registration System. When the account
gets down to a point where the next transaction would cause the balance to go negative, the
transaction will be rejected and the Registrar will be informed that more funds need to be
deposited.
One of the attributes of the transaction will be the location (aimag, UB City Property
Registration Office, etc.) that performed the transaction. This information will be used to
report to interested parties (GASR, Treasury) which location is responsible for generating the
fee revenue.
Mandatory
(Y/N)
Licensed registrars will be able to deposit funds
in the system by depositing money in a special
L3001 Y
bank account maintained for this purpose by
GASR.
Licensed Registrars will be able to view their
current account balance in the system at any
L3002 Y
time while they are logged in to the property
registration system.
When a Licensed Registrar performs a
transaction, the system will debit the Licensed
L3003 Y Registrar’s account by the amount of the fee
associated with the transaction. This operation
will be recorded in an audit trail.
The system will provide a means for approved
GASR personnel to adjust a Licensed
L3004 Y
Registrar’s account, but these adjustments will
be recorded in an audit trail.
The system will provide a means for GASR to
refund the outstanding balance of a Licensed
L3005 Y
Registrar in the event that the Registrar’s
account is permanently revoked.
The system will provide a means for crediting a
Licensed Registrars account when the Registrar
makes a bank deposit. This means may be
manual or automated. The means of matching
L3006 Y
bank deposits to Licensed Registrar accounts
will be the Licensed Registrar’s PAN, which
must be entered by the bank clerk in the memo
field of the deposit transaction.
In the event a computer-readable bank statement
is made available to GASR for the account in
which Licensed Registrars deposit their pre-paid
fees, the system will allow this statement to be
L3007 Y
uploaded for processing. The system will
process each transaction on the statement and
credit each Licensed Registrar appropriately
based on the statement.
The system will provide a facility with which a
L3008 Y designated individual at GASR can manually
314
Mandatory
(Y/N)
enter the information from the bank statement of
the account in which Licensed Registrars deposit
their pre-paid fees. The system will process each
transaction on the statement and credit each
Licensed Registrar appropriately based on the
statement.
If a transaction in the bank statement of the
account in which Licensed Registrars deposit
their pre-paid fees cannot be identified as
L3009 Y
belonging to a Licensed Registrar (e.g., invalid
or missing PAN) the funds will be deposited to a
special reconciliation account.
For each line on the bank statement the system
will capture the following information:
Bank
Bank account
L3010 Y
Date
Receipt No/Transaction ID
Amount
Memo field
The system will provide a facility for a
designated individual at GASR to transfer
L3011 Y money from the special reconciliation account to
a Licensed Registrar’s account, upon provision
of proper documentation.
The system will allow Licensed Registrars to
enter an inquiry or dispute in the system in the
event funds have not been properly credited. The
data for the inquiry or dispute may include:
Amount claimed to be deposited
L3012 Y Date on which deposit was claimed to be made
Receipt number
Bank which received the deposit
Bank account number which received the
deposit
PAN
The system will not allow a Licensed Registrar
to initiate a transaction if the Licensed
L3013 Y
Registrar’s account does not have sufficient
funds to cover the cost of the transaction.
Whenever the Licensed Registrar’s available
funds drop below a pre-set threshold, the system
will display a warning to the licensed registrar
L3014 Y that more funds need to be added to his/her
account. This warning will be continuously
displayed on every page of the system until the
available funds reach or exceed the threshold.
315
12. REGISTRATION OFFICER ACCOUNT MANAGEMENT

REQUIREMENTS
12.1 Introduction
A Registration Officer is anyone in GASR office who will be using the Property Registration
system, including receiving clerks and State Registrars.
The Sub-Functional Areas of the Registration Officer Account Management Requirements
are:
1. General
2. Setup
3. Financial
12.2 General
Mandatory
(Y/N)
The system will allow Registration Officers to be
S1001 Y registered as users of the system.
Each GASR Property Registration office will be
issued a Special Account in the Property
S1002 Y
Registration System (SAPRS) that represents the
office’s bank account.
The system will not restrict Registration Officers
from being able to initiate property registrations in
any location (aimag, UB city), regardless of where
S1003 Y the registrar works, unless management decides to
turn off this capability. The system will require the
aimag to be specified with every property
registration transaction.
12.3 Setup
Mandatory
(Y/N)
The system will allow designated personnel to
create a user account for a Registration Officer.
S2001 Y
Each Registration Officer will be associated with
the SAPRS of his/her location.
The system will provide facilities for designated
S2002 Y personnel to assign a username and password to the
Registration Officer.
The system will provide a facility for designated For instance, if the
S2003 Y personnel to suspend or revoke a Registration Registration Officer retires
Officer’s account, provided a reason is given. or changes jobs
316
12.4 Financial
When citizens submit their property registration applications, part of the documentation they
supply will include the receipt from the bank deposit. As part of the process of initiating the
registration transaction in the system, the receipt number and amount of the bank deposit will
be entered into the Property Registration System. This will automatically credit the Special
Account (SAPRS) with funds, and will allow the Property Registration System to properly
reconcile the bank information. There will be a SAPRS for each location (aimag, UB city).
As Registration Officers perform registration transactions, the amount of the transaction is
debited from the SAPRS account in the Property Registration System. When the account gets
down to a point where the next transaction would cause the balance to go negative, the system
will continue to process transactions, but the negative status of the SAPRS account balance
will be flagged for supervisory attention.
One of the attributes of the transaction will be the location (aimag, UB City Property
Registration Office, etc.) that performed the transaction. This information will be used to
report to interested parties (GASR, Treasury) which location is responsible for generating the
fee revenue.
Mandatory
(Y/N)
If a citizen initiates a property registration action at * Should be able to be pre-
a GASR office, they must first deposit the fee for filled automatically, i.e.,
the transaction in the location’s designated bank we should not require the
account and present the deposit receipt to the clerk to actually enter this
Registration Officer accepting the transaction. The information manually.
Registration Officer will record the details of the
receipt as part of creating the registration
transaction. The financial data that will be captured
S3001 Y will include:
Transaction date
Receipt no/Transaction ID
Amount
Bank*
Bank Account Number*
Location*
The location’s SAPRS account will be credited by
this amount.
When the registration has been completed
S3002 Y successfully, the transaction fee amount will be
debited from the SAPRS for that location.
The system will provide a bank reconciliation
function to ensure that expected deposits match
actual deposits. This will be done on the basis of a
bank statement, entered either automatically through
an electronic interface or manually. In either case
S3003 Y the system will record the date, amount, and
transaction id/receipt number of the transaction,
along with the bank and bank account information.
The system will then match this information to
information collected on an individual transaction
basis, and will automatically mark matching
317
Mandatory
(Y/N)
transactions as reconciled. Transactions which have
been deposited in the bank but not yet processed
will be considered liabilities for accounting
purposes.
If the SAPRS account for a location goes negative, a
notification will be sent to a designated person who
S3004 Y
will be required to investigate the reason for the
negative SAPRS account.
318
13. APPLICATION MANAGEMENT REQUIREMENTS

13.1 Introduction
According to the proposed reform for the Mongolian Immovable property registration system,
three types of users are expected to have access to the application management functionality
of ePRS:
 Application receiving clerks of GASR;
 Licensed Registrars authorized by GASR to access the system and perform
electronic delivery of application;
 Citizens for performing limited functionality – filling application forms.
This process could be initiated as a web transaction, but would likely need to be completed in
person, at least in the initial stages.
The basic processes would be the following:
39. Citizen requesting the service goes to a receiving clerk of GASR or licensed
registrar.
40. Citizen indicates to the state or licensed registrar the type of service he/she
requires, and provides the clerk or registrar with all the necessary documentation.
41. If not already in electronic form, the licensed registrar scans the provided
documents for upload into the property registration system. In case of service “in
person” in GASR office the scanning could be done later to have shorter time for
customer service.
42. The clerk or licensed registrar logs into the web-based registration application for
the aimag or locality in which the property is.
43. The registrar selects the type of transaction to be processed and enters all the
required information. For acceleration the data input the functionality should be
provided to allow for applicant the filling application form as well as paying fees
and duties in advance by accessing web-site of GASR.
44. The registrar uploads all scanned materials as required by the property registration
system.
45. The clerk of registrar submits the registration. This information is logged to
produce a transaction trail for the registrar as well as for applicant.
46. Once the application has been submitted, the transaction enters a workflow queue
for the appropriate jurisdiction, and a reference id is returned to the
registrar/citizen indicating the transaction is in process and requesting the citizen
to return to the registrar at a particular date & time.
All transactions and changes to the system will be logged with the ID of the user or users who
performed the transaction or change.
The Sub-Functional Areas of the Application processing are:
1. Application submitting
2. Documents scanning
13.2 Application submitting
The users of this functionality can be GASR receiving clerk, licensed registrar and citizen
(some functions).
319
Mandatory
(Y/N)
The system must provide web interface for filling The filling
application (declaration) form with necessary application or
information, including: declaration form
Applicants name, national ID number; corresponds existing
Applicants contacts (post address, phone number, e- practice of
mail address); registration and in
State registration number of immovable property; initial stages can be
Cadastral number of immovable property; continued by printing
Immovable property data (location, address, size, and signing the
price, type of property); application form by
Name and national ID number of co-owner(s), if applicant. In
any; perspective this
Required service type (by selection from list); function means the
Service type (normal, urgent); entering of
Service fee and stamp duty (should be calculated application data.
from service type and entered data);
A1001 Y Tax income;
Total pages/number of attached documents.
In case of secondary registration data already
available in register (immovable property data, co-
owners) should appear automatically after entering
the state registration number of immovable
property. In case of application for first registration
the immovable property data should be obtained
automatically from link to the ALACGaC register
(NLIS).
The users of interface for filling application form
will be GASR registrar or clerk, licensed registrar
and citizen. It is assumed that application data after
filling application form will be stored as XML
document. The data entered into application form
should be transferred to the register of immovable
property after accepting application for execution.
The system must accept different payment methods
for payment of service fee and stamp duty:
On-line payment best practices by credit card,
internet banking etc. This method can be used when
A1002 Y citizen prepares web application form.
Extracting payment amount from prepayment
account for licensed registrars.
Payment through bank in case of application “in
person”.
The system must include data and functionality for
checking payment of duties for actual registration.
The checking includes:
Validation of stored in system data about performed
A1003 Y
on-line payment in case of payment with credit card
or using internet banking services;
Validation of presence necessary amount in account
of licensed registrar and reservation of this amount
320
Mandatory
(Y/N)
in case of prepayment;
Entering of unique banks transaction number and
payment amount from banks receipt in case of bank
transfer. The unique banks transaction number
should be validated against presence of same
number in system to prevent of usage one payment
for several cases. The payment amount should be
validated against of fees and duties for current
registration service.
The system must have functionality for receiving
electronically submitted applications and uploading
A1004 Y
documents attached to the applications with
appropriate metadata and security measures.
In case of acceptation of submitted application
system must automatically issue application date (as
“system time”) and generate application number.
The application number should be unique sequence
A1005 Y
number within current registration office and
current year. Thus combination of registration
office ID code, year and application number gives
unique reference to the individual application...
The system must have capability of extracting the
application data necessary for including into
A1006 Y register from submitted filled application forms for
all cases: application form filled by citizen, by state
registrar and by licensed registrar.
The system must have capability to print out receipt
of accepting application from registered application
data showing:
Application registration number
Type of service
Number of documents/pages received together with
A1007 Y application
State registration number of immovable property
Full name of owner/co-owners of immovable
property
Expected date of completion of registration/service.
This function can be used in case of performing “in
person” service at registration office.
The system should have capability to send
electronically (e-mail, SMS) to the contact address
of the licensed registrar and/or applicant receipt of
accepting application from registered application
data showing:
A1008 N Application registration number
Type of service
Number of documents/pages received together with
application
State registration number of immovable property
Full name of owner/co-owners of immovable
321
Mandatory
(Y/N)
property
Expected date of completion of registration/service.
This function should be executed automatically
after submitted application is registered into system,
if it contains appropriate contact information.
13.3 Documents scanning

If the documents attached to the application are not electronic, they should be scanned to be
uploaded into the system and to be included into the electronic archive. Below described
requiresadditional scanning functionalities for GASR customer service providers in the case
when documents should be scanned when received by receiving clerks. Alternative solution is
scanning documents after completion of a registration case.
The scanning solution for licensed registrars is not in the scope of present requirements.
Mandatory
(Y/N)
The system must ensure mechanism for
identifying and separation documents before
scanning them. Possible solutions are:
Using bar code containing information about
application number, which can included in final
printout of application form and attached as first
page to the documents to be scanned;
A2001 Y
Using special separator pages between
documents with bar code which showing
document type;
Printing out labels with bar code showing
application number and document type which
can be stick to the first page of each document;
Other technological solution.
The system must have capability to scan
package of documents attached to the
A2002 Y application, separate scanned pages according
individual documents and convert them into
multipage compressed TIFF and/or PDF files.
The system must have capability to store
scanned documents into digital archive, to add
metadata to the documents and to index them by
A2003 Y application registration number and document
type.
This function should be executed automatically
after scanning of each document.
322
14. REGISTRATION REQUIREMENTS

14.1 Introduction
The registration functionality will be accessible by GASR state registrars receiving
applications “in person” or electronically. This functionality covers following steps of
workflow:
47. At an affiliating GASR office a state registrar accesses the case in the queue or
case can be automatically appointed to the registrar.
I. The state registrar examines the case and renders a decision;

II. The decision is logged into the property record, along with a generated image
(PDF) of specific certificates;
III. A message is sent to the registrar/citizen (via email or SMS) indicating that the
process has finished.
IV. The state registrar contacts the citizen to inform that the process has been
completed, and to pick up any documents that are produced.
48. Documents or certificates are printed-out by state or licensed registrars on plain A4

stock and are turned over to the citizen.
All transactions and changes to the system will be logged with the ID of the user or users who
performed the transaction or change.
49. Making decision;
50. Registration;
51. Completion of a case.
14.2 Making decision

After an application is accepted for an execution, the case should be examined against an
appropriate jurisdiction, including a validation of parties and their power of attorneys, legal
status of immovable propertydocuments attached to the application and etc. State registrar
makes according requested service decision to make changes into the immovable property
register or register of refuse of registration.
Mandatory
(Y/N)
The system should have capability for automatic Instead of automatic
distribution of application to the executive registrar. distribution registrar can
The automatic distribution should fulfill following process the next case in the
requirements: queue
It should be based on randomization;
R1001 N
It should consider equal workload for all executing
registrars of registration office;
It should consider work schedule of state registrars;
It should be separate for applications for first
registration and for secondary registration.
323
Mandatory
(Y/N)
The system must ensure accessing and reviewing
scanned and electronically received application
documents as well as documents from electronic
archive related to the appropriate immovable
R1002 Y property. These documents should be retrieved from
the electronic archive by application registration
number or state registration number of immovable
property and reviewed in parallel with entering data
into register.
The system must allow to user to review existing
rights on immovable property recorded into register
R1003 Y
as well as review necessary historical records and
issued certificates and decisions.
The system must have capability to request and
receive personal data from Civil registration system
R1004 Y by civil ID number. The personal data should be
used for checking purposes and can be used for
registration purposes to avoid manual data entering.
receive legal entities data from Legal entities
registration system by state registration number of
R1005 Y
legal entity. The legal entity data should be used for
checking purposes and can be used for registration
purposes to avoid manual data entering.
receive data about land and buildings from
ALACGaC by parcel number or cadastral ID
R1006 Y
number. The cadastral data should be used for
checking purposes and can be used for registration
purposes to avoid manual data entering.
The system must provide functionality for entering
and storing into system description of grounds and
explanations in case of rejection of application and
R1009 Y
printing out explanatory letter. The system should
provide possibility to store and reuse templates of
description of grounds for most typical cases.
14.3 Registration
In case when application and documents for registration are accepted by state registrars, state
registrars make necessary changes in the registry systemthrough adding new records and
invalidation of existing records. Changes in the registry system should be approved (fixed).
Mandatory
(Y/N)
The system must have capability to create the new
registers entry for the new property in case of
R2001 Y registration of ownership on it. The new state
registration number should be automatically issued
for this property according Regulation of GASR on
324
Mandatory
(Y/N)
numbering and coding of state registration of
property ownership, land ownership, possession and
use rights. The property description and ownership
data should be automatically obtained from
application data and/or received cadastral data
including:
Location (administrative unit) of immovable
property;
Address of immovable property;
Purpose of use;
Size;
Price of immovable property;
Owner or co-owners full name, civil ID number,
address of residence; if owner is legal entity – its
name, address of location, state registration number,
its representatives full name, civil ID number,
address of residence and power of attorney on
property;
A ground for registration of ownership rights.
The system should provide functionality for editing
and saving mentioned above data.
The system must ensure legal data manual entering
into register as well as adding data received from
external registers. The records should contain
description of established, changed or terminated
rights and legal grounds for establishing, changing
and termination of rights, including:
R2001 Y
Type of contract and its subject matter;
Parties of contract;
Object of contract;
Term of contract;
Price agreed by contract;
Grounds for termination of contract.
The system must have functionality of approving
registrar’s decision and finalizing of transaction.
After approving cannot be possible to modify or to
delete entered records. Approving also should
include following sub-functions:
Automatic assigning of registration data and time;
Adding records for audit trails showing approving
R2003 Y
user;
Invalidation of records lost their topicality and
updating view of current legal status of immovable
property;
Making the new records available for public;
Initiation of sending necessary notifications to the
applicant and other recipients.
14.4 Completion of a case
325
After entering and approving new data into the registry, GASR state registrars or clerks
prepare certificate or other proof of performed registrations and provide necessary post-
registration tasks. Functional requirements for these tasks are described in the present chapter.
Mandatory
(Y/N)
The system must have capability to generate
from entered records and to store within system
certificate or other appropriate proof showing
R3001 Y decision of registrar as PDF document. This
document should be generated only after
approving of registrar’s decision and should
correspond the actual records.
The system would have functionality for Implementation of this
automatic sending notification to the ALACGaC functionality depends
R3002 N about registered cadastral changes of property from establishing of
(cadastral ID number, size, administrative information link between
jurisdiction). GASR and ALACGaC
The system would have functionality for sending Implementation of this
notification to the Tax authority about registered functionality depends
ownership changes on request. from establishing of
information link between
GASR and Tax
authority. Instead of
notification about
R3003 N
individual changes
today’s arrangement is to
send monthly report
about ownership changes
to the Tax authority. The
preparing such report is
separate requirement.
The system would have functionality for Implementation of this
automatic sending notification to the Banks functionality depends
about registered mortgages. from establishing of
information link between
GASR and Banks.
Instead of notification
about individual changes
R3004 N
today’s arrangement is to
send monthly report
about registered
mortgages to the banks.
The preparing such
report is separate
requirement.
The system must have functionality for
automatic sending notification to the applicant’s
R3005 Y contact addresses by e-mail or SMS about
performed registration or refusal to perform
registration.
326
Mandatory
(Y/N)
The system must have capability to distribute Implementation of this
generated certificate or other proof of functionality depends
registration to the applicant as electronic from progress of passing
document according Mongolian legislation on e- legislative acts on e-
R3006 Y documents and e-signature. documents and e-
signature and
establishing appropriate
infrastructure in
Mongolia.
The system must ensure recording of manual or
electronic distribution of certificate or other
R3007 Y
proof of registration and closing the application
processing.
327
15. SEARCHING AND DISPLAYING REQUIREMENTS

15.1 Introduction
The search functionality through different search criteria in the registry of immovable
properties and electronic archive to display the results in register records and electronic
documents should be the same in all functional areas of ePRS.
52. Searching;
53. Displaying.
15.2 Searching
The search functionality includes searching for immovable property data in the registry and
document images in the digital archive. This functionality should be same at each system
components where necessary – registration software, information dissemination software and
data exchange software.
Mandato
ry (Y/N)
The system must provide immovable property
D1001 Y search by property state registration number
The system must provide immovable property Due to obstacle of
search by property cadastral number missing the cadastral
numbers for buildings
D1002 Y and apartments this
function could be
initially implemented for
the land parcels
The system must provide immovable property Implementation of this
search by location or address functionality depends
from planned
D1003 Y
establishment of unified
addressing system within
Mongolia
The system must provide immovable property The search functionality
(buildings, apartments) search by property state should provide list of
registration number for land on what these registered buildings and
D1004 Y
properties are built. apartments which are
built on particular land
parcel.
The system must provide immovable property As additional feature
search by owner’s civil registration number. system should allow to
D1005 Y
search also by former
owners.
The system must provide immovable property
D1006 Y search by application number.
The system must provide application search by
D1007 Y application number
328
Mandato
ry (Y/N)
The system must provide application search by
D1008 Y applicant civil registration number and/or
application date
The system must provide document search in digital
D1009 Y archive by property state registration number
D1010 Y archive by application number
D1011 Y archive by document’s metadata
15.3 Displaying
Presentation of information is a vitally important part of an information system as it is a tool
through which information is conveyed to people in visual means. Presentation of legal
information from the database should be rendered in a proper way to avoid any
misunderstandings and misinterpretations. The immovable property registry will contain
records showing current legal status of a property as well as historical records of amended and
terminated rights. In a similar way, the digital archive will contain actual and historical
documents. The system should provide a view on the current legal status of an immovable
property, including its location, size, value of an immovable property,ownership, mortgages
and other rights existing on an immovable property. When requested, the system should be
able to display all historical records associated with an immovable property and documents on
which rights were established.
Mandatory
(Y/N)
The system must provide view on actual
D2001 Y immovable property rights
The system must provide view on all immovable
D2002 Y property rights, including historical
The system must provide view of application
D2003 Y data
The system must provide view of documents
D2004 Y from archive
The system must ensure printing of displayed
D2005 Y information in convenient format
329
16. ARCHIVING REQUIREMENTS

16.1 Introduction
An electronic archive of certain documents attesting property and other rights about a real
estate and describing technical parameters of the estate must be established as a part of
standard work flow management document process and the work procedure to handle the
electronic copies of documents need to be established.
Current situation
According to the statistics provided by GASR on August 31, 2010, there are a little more than
390,000 immovable properties registered in the registry of immovable property. About
200,000 of them are registered in the Ulaanbaatar city registration office and 190,000 in
aimag offices.
All immovable properties in Ulaanbaatar are also recorded in the TRIADA database – all
together there are a little more than 207,000 in the database.
The data conversion from manual registration books into the REAL database is currently
ongoing in all 21 aimags. In some aimags records are converted 100%, in others, the process
status is between 50-80%. The goal is to accomplish data entry 100% in all aimags by Fall,
2010. After all data in all aimags is entered, it is planned to merge aimags’ databases into one
central database. There is no information about the quality of the data in REAL database.
The archives of the registration offices contain only paper documents and files, and currently
none of them have been converted to a digital format.
For this purpose, the digitalization project was scheduled to start in mid-2011, and the
primary goal is to digitize all contents of the archive and store them in the digital library
before the implementation of the ePRS system starts.
The archive will consist of digital documents with an additional XML-based metadata that
will comprise of: Application Registration Number; Property Registration Number; Type,
Name, Date of the document and other relevant information that will be required to easily
identify a property object, application or documents that are related to a registration.
16.2 General
Mandatory
(Y/N)
Electronic archive of all registered objects with all
data has to be created with clearly organized
H1001 Y
hierarchical structured order system and search/find
functions.
All old and new data have to be stored in an easy to
H1002 Y use archive, with clear order system and search/find
functions
16.3 Input and maintenance

Mandatory
(Y/N)
330
Mandatory
(Y/N)
The archiving solution must offer the capability
to user can create, delete, modify, and cut and
H2001 Y
paste metadata records through a web-based
interface.
Maintenance of values and codes for select-for
H2002 Y standard values.
Preview of data.
H2003 Y
16.4 Retrieval
Mandatory
(Y/N)
The archiving solution must offer the capability
H3001 Y to do simple and advanced search options in
order to offer required information for the user.
Maintenance of values and codes for select-for
H3002 Y standard values.
16.5 Interoperability
Mandatory
(Y/N)
The solution must provide an XML-based
mechanism for metadata import and export. In
H4001 Y
addition to XML-based approach, other text files
can also be imported and exported
The metadata system should have possibility to
H4002 Y be linked to external systems.
16.6 Management
Mandatory
(Y/N)
The digital archiving system must track
H5001 Y transaction of record activities, such as creator,
modifier, verifier, and related data and time.
Must verify the accurateness of metadata records
H5002 Y based on standard requirements, and to offer
related messages for record modification
Should offer the function to de-duplicate a
H5003 Y record based on specified criteria, for the
process of record creation and modification.
Must offer different levels of authorization, such
H5004 Y as criteria based on task or job responsibility
331
16.7 Automation of Operational Activities

Mandatory
(Y/N)
Must offer inventory functions in order to
H6001 Y perform routine tasks related do decoration,
repair, checking, and so on.
Should provide a circulation function to conduct
H6002 Y tasks related to check-out/in, claim and so on.
Must provide the function of a report generator
in order to generate related reports or statistic
H6003 Y
data based on specified criteria from metadata
elements.
332
17. ACCOUNTING REQUIREMENTS

17.1 Introduction
The various bank accounts will be “swept” into Treasury accounts each day. These Treasury
accounts belong to various GASR offices, such as the local offices at aimags/UB City, as well
as a national-level account used for collecting fees from Licensed Registrars.
At the end of each month it is necessary to transfer the proper amount of fee revenue from the
entity Treasury account into the State Budget revenue account. Further, reports must be
provided to inform interested counterparties (e.g., Treasury) where certain funds came from.
For instance, funds deposited into the national-level account may end up being used to
process transaction in multiple aimags. Reporting should indicate how many transactions
were processed at each aimag, independently from how much money was actually collected
by a particular aimag’s local bank account.
Further, at the end of the month certain balances may not actually have been used yet. This
money should not be swept into the State Budget until it has been used for transactions, since
otherwise there is no way to allocate the funds by aimag.
The above specific feature shall be clarified with the GASR – after the decision will be made
on the topic..
Accounting functions within the ePRS must show the current financial position of the
Property Registration system, including:
 Total assets and liabilities related to the property registry;
 Individual bank account balances;
 Amounts collected and processed by transaction type;
 Amounts outstanding in Licensed Registrar accounts;
 Funds deposited by citizens for non-Licensed Registrar transactions that have not
yet been used.
On a periodic basis, the basic financial picture of the Property Registration system must be
reflected in the Financial Accounting System or Systems (as these are distributed).
The following are basic requirements for the financemodule of the ePRS.
Mandatory
(Y/N)
All financial transactions will be handled according
F1001 Y to standard Mongolian accounting rules.
The system will provide allow for a financial status
to be displayed at any time, showing the total assets
and liabilities, total transaction counts and fees
collected by transaction type for a specified period
F1002 Y (prior year, year-to-date, prior month, month-to-
date, prior-week, week-to-date, prior day, current
day), bank account balances related to property
registration, treasury account balances related to
property registration
The system will generate all transactions necessary
F1003 Y for posting property registration financial
information into the financial accounting system(s)
333
Mandatory
(Y/N)
The system will track the amounts transferred from
F1004 Y bank accounts to treasury accounts
The system will compute and track the amounts to
F1005 Y be transferred from GASR treasury accounts into
the State Budget Revenue Account.
The system will generate the transfer vouchers used
to transfer funds from the GASR treasury account
into the State Budget revenue account and allow the
F1006 Y
user to print it out, to be used at the Treasury
window. The voucher will need to be printed in the
approved Treasury format for such vouchers.
The system will generate all the reports needed by
F1007 Y Treasury to correctly account for fee revenue
collection by location.
The system will maintain a list of property
F1008 Y registration transaction types and the fee associated
with each one.
No property registration transaction will be able to
F1009 Y be recorded in the system unless it has a valid
property registration transaction type.
As part of the property registration transaction the
F1010 Y system will record the property registration
transaction type and the fee paid.
334
18. REPORTING REQUIREMENTS

18.1 Introduction
The system must be able to produce a comprehensive set of reports for many different uses.
The Sub-Functional Areas of the Reporting Requirements are:
1. General Reporting
2. Management Reporting
3. Financial Reporting
4. Statistical Reporting
5. Ad-Hoc Reporting
6. On-line Analytical Processing (OLAP)
18.2 General Reporting
Mandatory
(Y/N)
Reports must be produced in HTML format for
on-screen display and printing as well as plain
P1001 Y
text, Microsoft Excel, Microsoft Word, RTF and
PDF formats
The system must allow the definition of other e.g., Crystal Reports,
P1002 Y
additional reports using a reporting tool. Jasper, Pentaho
The system must give users the ability to edit

P1003 Y
report templates according to their own needs
The system must provide the ability to define
P1004 Y report Headers and Footers separately and allow
users to change them.
The system must allow users to select columns,
P1005 Y
when a report is printed.
The system must automatically adjust the size
P1006 Y and fonts of columns in the case in which a
report does not fit on a page.
The system must allow users to sort report
P1007 Y
output by any column.
The system must provide the ability to select
P1008 Y and/or sort report output by date or range of
dates.
The system must allow users to specify selection
criteria for any row of a report, including
P1009 Y
specific column values, greater than/less than
column values, or ranges of column values.
18.3 Management Reporting

The internal regulations of GASR determine the principles of preparing different periodical
reports, in English and Mongolian, on registration services provided at each aimags and of
submitting to the GASR central office and other state institutions. According to these
regulations, the bidder should offer a mechanism for preparing reports centrally and directly
335
from the registration database. These reports should be able to be run for any periods desired
(day, month, quarter, year, from date – to date).
Mandatory
(Y/N)
System must prepare report on statistics of the
registrations provided by the city or aimag
registration office per month including: number
of registered properties at the beginning of
P2001 Y month, number of performed registrations by
registration type, number of registered properties
at the end of month.
The user should be able run this report also for
other time period.
System must prepare report on Statistics of
registered mortgages (pledges) on immovable
property by registration office of city or aimag
per month showing: number of registration per
P2002 Y property type, pledges totals per property type
and overall number of registrations and total
sum.
other time period.
System must prepare monthly report to banks
about registered mortgages showing: immovable
property cadastral number, address, registration
P2003 Y number, registration date, debtor name, property
type, bank or creditor name, sum of loan.
other time period.
System must prepare monthly report to Tax
authority showing: immovable property
cadastral number, owner name, registration
number, registration date, area of property,
P2004 Y
transaction amount, property type, property
address.
other time period.
18.4 Financial Reporting

Mandatory
(Y/N)
The system must have capability to produce
P3001 Y
financial reports
336
The system must provide reporting to comply

with various international conventions. The
mandatory one of these is the International
Public Sector Accounting System (IPSAS). This
P3002 Y
is a set of economic and statistical concepts,
accounting rules and guidelines for the
preparation of data on general government
operations in a systematic way.
The system must be able to automatically
P3003 Y generate Bank/Cash reconciliation statements
relating to property registration activities.
The system must be able to produce an Income
P3004 Y and Expenditure Statement for the property
registration activities.
The system must be able to produce the above
P3005 Y statements by project, location, or other chart of
account elements.
18.5 Statistical Reporting

Statistical reporting should represent current status and the dynamics of registration of
immovable properties for professional users and the general public.
Mandatory
(Y/N)
At present for these
The system must provide automatic daily
purposes the separate
registration reports for presentation them on
P4001 Y software (called MD-
public screens in GASR offices and in GASR
Records) is used in
internet portal.
GASR central office.
The system must provide automatic monthly
statistical reports showing number of processed
applications per service type, per registration
P4002 Y
office and per territorial unit. These reports
should be stored in the system and be accessed
from GASR internet portal.
The system should have possibility to provide
simple tools for customization of statistical
P4003 N
reports by choosing time intervals, appropriate
aggregation and splitting.
18.6 Ad-Hoc Reporting

Mandatory
(Y/N)
From time to time, users have specific needs to
have access to reporting that may reflect a once-
only need, or may indicate an emerging
requirement. As these requirements cannot be
P5001 Y predicted in advance, the system must be
provided with a user-friendly report writer or
executive information system that will permit
the majority of users to extract information form
the database without recourse to programming.
337
19. Workflow management requirements

The Functional Area is responsible for handling immovable property registration processes /
transactions by providing full automated support to the registrars performing the processes
and their tasks.
The Sub-Functional Areas of the Workflow Management Requirements are:
54. Workflow Definition;
55. Workflow Running;
56. Workflow Monitoring.
19.1 Workflow Definition Requirements

The workflow definition component must provide enough flexibility with regard to adapting
changes in the law, processes, rules and regulations.
Mandatory
(Y/N)
The system must have facilities for graphical
W1001 Y and user-friendly way to build and edit
workflows for business processes.
As examples of standards
can be: XML, BPMN,
The workflow definitions must be based on
W1002 Y BPEL, WSDL, Web-
existing and widely used standards.
Services, XSLT, XPATH,
etc.
The system must be able to set up simple and
complex human workflow steps, configure
W1003 Y
adapters, and define complex transformation
maps.
The system must provide enough flexibility for
workflow definition with regard to adapt
W1004 Y
changes in the law, processes, rules and
regulations.
19.2 Workflow Running Requirements

The workflow running component is responsible for execution of defined workflow in server
environment.
Mandatory
(Y/N)
The system must have runtime engine to execute
W2001 Y human business workflows within SOA
environment.
The system must have possibility integrate
W2002 Y execution of internal and external processes
within one workflow.
The system must support user’s notifications via
W2003 Y various channels like email, SMS, or instant
message.
The system should support definition of business
W2004 Y rules and dynamic decision making during
execution of business workflow.
338
The system must provide capability of storage of

process states into database so that the state of
W2004 Y
long-running workflows is automatically
maintained in a database.
The system must have ability to implement
designed workflows in the production system
W2005 Y
without tampering in the original source code of
the application(s).
19.3 Workflow Monitoring Requirements

This sub-functional area comprises of functions for real-time monitoring business processes
and services provided by ePRS. They give timely information for managers to make better
decisions to improve Key Performance Indicators (PKI) which are set up to the system.
Mandatory
(Y/N)
The system must have different mechanisms to
W3001 Y collect real time business events: database,
messaging system, web services.
The system must allow users to define necessary
W3002 Y Key Performance Indicators (KPI) what should be
monitored.
The system must provide real time events analysis
W3003 Y based on standard and users extended
computational logic.
The system must allow users to define real-time
W3004 Y
alerts based on expected business conditions
The system should provide simple and intuitive
W3005 Y user interface to display events, processes, results
of analyses and PKI in real-time.
19.4 Internet portal requirements

In order to fulfill requirements of article 15.1 of the “General Law on State Registration” with
respect to having an open access to all information related to state registration, the internet
portal for information distribution must be developed. The current chapter describes
functional requirements for mentioned above portal.
Mandatory
(Y/N)
The information portal must provide general
information about:
Current legislation on immovable property
rights registration;
Description of registration procedures;
List of documents necessary for each type of
E1001 Y
registration;
Information on fees and duties to be paid for
registration;
Locations and working hours of registration
offices;
List of contacts of licensed registrars;
339
Mandatory
(Y/N)
General statistics about processed applications
and registered properties;
Other information relevant to the registration of
immovable property rights.
The information portal should have functionality Filling application in
for on-line filling application form for internet in advance does
registration described in requirement P1001. The not raise any obligations
filled application form should be stored in the neither priority rights of
system for certain period of time and can be applicant. This can be
printed out and signed when applicant arrives to done in order to
E1002 N
the registration office or licensed registrar. If accelerate customer
application isn’t processed within this period of service in registration
time, it can be deleted automatically. offices.
After filling the on-line application form system
automatically provide information about fees
and duties to be paid to process this application.
The information portal must provide searching
and showing immovable property data from
register. The search can be performed by:
E1003 Y
Property state registration number;
Cadastral ID number;
Location (address).
The information portal must ensure displaying
early warnings during reviewing immovable
property data. Early warning contains
E1004 Y
notification about accepted application on
registration of rights on present immovable
property processing of which is not finished.
The information portal must provide displaying
of application tracking information shoving
status of application (accepted, in process,
E1005 Y decision made, and type of decision). The
application tracking information should be
provided by entering application registration
number.
19.5 Information services requirements

The data exchange requirements are intended to support interactions of immovable property
registration system with following external information systems:
1. Land administration system within Land offices;
2. Cadastral information system (incl. NLIS) of ALACGaC;
3. Information system for notaries;
4. Information systems of banks;
5. Information system of Tax authority.
Currently, most of these systems are only ideas and development stages and data exchange
functionality offered by the Immovable property register will facilitate the development of
necessary interfaces for these systems.
340
For the systems (e.g. ALACGaC), for which data is required to fulfill the registration process,
an offline alternative SHOULD be taken in consideration (storage of necessary data in the
ePRS database using replication of data), if connections to those systems cannot be made
(because of problems from external information systems that cannot be connected).
The Sub-Functional Areas of the Information services requirements are:
6. General;
7. Land Offices
8. ALACGaC
9. Notaries
10. Banks
11. Tax authority
In order to roll-out the system a connection-test with specified external information system
MUST be made it and information exchange MUST be established.
19.6 General Requirements

Mandatory
(Y/N)
The data exchange with heterogeneous systems
As example for protocol can
must be based implementation of web services and
I1001 Y be Simple Object Access
appropriate data exchange standards and
Protocol (SOAP).
protocols.
The system must maintain data integrity and audit
I1002 Y history when requesting, receiving and delivering
data.
The system must allow the formats for the
I1003 Y interfaces to be customized/ changed without
requiring a programming effort.
The system must allow for the development of
I1004 Y
totally new import interfaces.
All import interfaces will operate according to the

I1005 Y
applicable Mongolian standards, if any.
For general purposes the system must have web
services for searching and delivery immovable
property data from register. The search can be
performed by:
Property state registration number;
Cadastral ID number;
I1006 N
Location (address).
Received information from register should contain
also early warnings. Early warning contains
notification about accepted application on
registration of rights on present immovable
property processing of which is not finished.
The system must have web service for requesting
I1007 Y and delivery application tracking information by
application registration number.
19.7 Land Offices

341
The primary duty of the land office is to perform the first (initial) registration on immovable
property. To do this, the land offices need to be able to check the ownership of the property-
that is whether or not other ownership or possession rights are already associated with the
particular property. In the future, in order to simplify the initial registration process, the land
offices (as a licensed registrar) should be able to apply for registration of property rights. The
data exchange comprises two services: one that allows the land offices to receive the
ownership and possession data in the immovable property register and then allow the land
officer to use a web service to deliver the application for registration.
Mandatory
(Y/N)
and receiving immovable property ownership
I2001 Y information necessary for Land offices. The
information can be requested by parcel ID number
or location (address) of immovable property.
The system must have web service for electronic
delivery of application for first registration prepared
by Land offices. The web service should include
operations for:
I1002 Y Authorization of responsible registrar/clerk;
Sending application data;
Uploading documents for registration;
Supplying upon request tracking information about
status and processing of application.
19.8 ALACGaC
ALACGaC should be able to receive information necessary for the maintenance of the
cadastral data from the ePRS. In the future, in order to simplify the registration process, the
land offices (as a licensed registrar) should be able to apply for registration of cadastral
changes – change parcel number, property size or address. The data exchange comprises two
services: one that allows the ALACGaC officer to receive property data from the immovable
property register and then allow the ALACGaC officer to use a web service to deliver the
application for registration.
Mandatory
(Y/N)
and receiving immovable property information
I3001 Y necessary for ALACGaC. The information can be
requested by parcel ID number, building ID number
and receiving the GIS map of the immovable
I3002 Y property from NLIS system. The information can be
requested by parcel ID number, building ID number
I3003 Y delivery of application for registration of cadastral
changes by ALACGaC. The web service should
342
Mandatory
(Y/N)
include operations for:
Authorization of responsible registrar/clerk;
19.9 Notaries
In the case of a secondary registration, notaries will be the main partner working with GASR
on the immovable properties registration process. Each notary should have an access to the
system services in order to:
 Get information about the rights on immovable property for the validation or
preparation of documents;
 Electronically submit the application and documents for registration.
Mandatory
(Y/N)
and receiving immovable property information
necessary for notaries. The information can be
I3001 Y requested by: state registration number of property,
parcel ID number, building ID number, apartment
ID number, or location (address) of immovable
property.
delivery of application for registration of rights on
immovable property by notaries. The web service
should include operations for:
I3002 Y Authorization of notary;
19.10 Banks
Banks should be able to access the property information system in order to check ownership
and mortgage information on a property before concluding a new mortgage contract. There
will no longer be any need for the client to bring a printed reference from GASR. This can be
achieved by creating a web service that is linked to the bank’s internal IT system. After this,
bank clerks would be able to act as licensed registrars in the case of registration and
cancellation of mortgages.
Mandatory
(Y/N)
I4001 Y and receiving information on mortgages on request
of banks. The information can be requested by: state
343
Mandatory
(Y/N)
registration number of property, parcel ID number,
building ID number, apartment ID number, or
location (address) of immovable property.
delivery of application for registration of mortgages
and termination mortgages by banks. The web
service should include operations for:
Authorization of notary;
I4002 Y
Uploading documents for registration or termination
of rights;
and receiving monthly reports on registered and
I4003 Y
canceled mortgages and pledges for particular bank
as creditor.
19.11 Tax authority

There is a required web service on ePRS that allows quick and efficient preparation and
delivery of reports requested by the tax authority. This application can also deliver other
necessary legal information contained within the register directly to the taxation controlling
application.
The tax department should be allowed to register tax liens in the ePRS. The purpose of this
function will be to improve tax collection by providing public notice about taxpayers in
default.
Mandatory
(Y/N)
and receiving information on ownership on request
of Tax authority. The information can be requested
I5001 Y
by: state registration number of property, parcel ID
number, building ID number, apartment ID number,
delivery of application for registration of tax liens
by Tax authority. The web service should include
operations for:
Authorization of notary;
I5002 Y
Uploading documents for registration or termination
of tax lien;
and receiving monthly reports on ownership
I5003 Y
changes in particular administrative territory for tax
inspector who is responsible on this territory.
344
20. TESTING REQUIREMENTS

Generally, the project management and the quality assurance (QA) management has to follow
international standards RUP methodology or similar in the testing process.
The Testing process is an integrated approach to testing the quality of all elements of the
System. It can include functionally oriented module testing and business-oriented module
integration, system, systems integration and acceptance testing. All business oriented testing
is driven by the Business Architecture requirements to establish firm traceability back to
business requirements.
The process emphasizes a common planning approach to all types of testing. It advocates the
re-use of testing scripts in successively larger and larger portions of the application system.
Testing must contain module testing, but surely other forms of testing, such as module
integration, and systems integration testing.
The Testing process approach first identifies testing requirements and maintains and enhances
them through the end of the project. For example, business scenarios / uses cases are
identified while developing the Business Process Model, and they contribute to module,
module integration, and systems integration testing.
Functional module requirement produce testing requirements that are specific to an
elementary business function (EBF). These testing requirements also contribute to module test
plans, when EBFs are mapped to modules. Development Standards for the User Interface
Style Definition produce a QA checklist of behavioral tests that are performed during module
testing.
The Testing process must be based on a useful and representative dataset to be able to
perform all different kinds of tests. The dataset should be obtained by conversion of data from
existing TRIADA and REAL databases.
The testing process contributes to the development of integrated test plans, fully tested
software, and independently confirmed software tests and results. It defines a defect tracking,
resolution, and regression test infrastructure to provide dependable fault correction and trend
analysis.
20.1 Test Preparation
Part of the Testing and Acceptance Management is the preparation for testing. The following
must be included when preparing for integration and testing:
 Develop detailed test material
This includes defining scenarios, scripts, timelines, checklists, processes, test sets, and test
cases.
 Establish procedures
Write test procedures (steps to actually perform tests). Specific procedures are described
within each test case or test script. These procedures include descriptions of how to set up the
test, the sequence of tests, what is being tested, the conditions needed for a specific test, and
the test’s expected results. Ensure that procedures are executed properly.
 Generate and validate test data
 Use/modify existing data (data mining)
 Verify data quality (data scrubbing)
345
 Create new data requirements

 Create procedures to refresh data once testing begins.
 Establish verification criteria.
 Identify resources
Coordinate and review detailed test material for this review, use a variety of techniques,
including readiness review, procedure walk-troughs or reviews and dry runs.
 Test stations that test multiple users
Debug and test their synchronization before the actual test takes place.
 Establish a detailed test schedule
 Install and set up the test environment
 Train all participants
Train them in testing in general tools, applications, and hardware, software, and test-support
processes.
The Purchaser (with the assistance of the Supplier) and involvement of consultancy Blominfo
A/S will perform the following tests on the System and its Subsystems following Installation
to determine whether the System and the Subsystems meet all the requirements mandated for
Operational Acceptance:
 Module / Function test for each specified System function in isolation
 Module Integration Test for a group of System Functions
 System test per Subsystem
 System Integration test for all Subsystems
The subsystems are described before, and the details on System Functions and their coherence
will be provided by the requirements phase.
The acceptance will consist also of an acceptance of the complete Software Code for ePRS
that should be fully commented/described, line by line.
346
21. QUALITY ASSURANCE REQUIREMENTS

The Supplier will implement a software quality assurance program covering all software
delivered as part of the ePRS. The quality assurance effort will document all testing and
maintain records of design reviews, code walkthroughs, tests, faults, resolutions, and
regression tests. These records will be available to Purchaser at any time.
347
22. MAINTENANCE
The supplier will create a maintenance and support plan for the Warranty Period and the Post-
Warranty Services Period, which will address all aspects of support and maintenance, such as
IT-infrastructure development, operation and maintenance, Application management,
available (telephonic) assistance (also in relation to helpdesk), training courses. The above
mentioned support and maintenance will be formalized in Service Level Agreements, the
Bidder MUST propose the contents of such agreement, for example specify a set of response
times for different degrees of seriousness of the defects and/or categories of IT and/or specific
subsystems.
22.1 Warranty Period
The “Warranty Period” will commence at the date of the Operational Acceptance Certificate
of the ePRS System, during which the Supplier is responsible for defects with respect to the
system or relevant subsystems. To assist these activities a 1st and 2nd line helpdesk support
needs to be set up.
22.2 Help desk
The Supplier must prepare a well trained staff responsible help-desk services. The help-desk
will consist of two lines. The 1st line help-desk MUST support with regard to the use of the
applications, with help of internal phone number(s) and an issue management system. The
issues will be classified (e.g. urgency, priority, error, wish) and resolved as much possible by
internal help-desk support. The issues that cannot be resolved by the 1st line help-desk support
will be transferred to the 2nd line help desk support, which will be provided by the supplier.
The help desk shall work as a one point-of-contact. This means that the user with a problem
shall contact one number, only, to present his problem. If the help desk cannot solve the
problem, it is the obligation of the help desk to seek the solution in the second line of support.
In this way the user is not sent from one person to another again and again.
Mandatory
(Y/N)
Create and implement maintenance and support plan
W1001 Y for a period of 2 years guarantee.
Implement help-desk and knowledge issue system.
W1002 Y Help-desk must offer support in Mongolian
language.
348

It is estimated that the Final Contract between the selected Bidder and the Purchaser shall be signed by the 15 of June 2011.
349

24.1 Project Stages

Calendar Months
1.System (Software) development
System prototype SW Supplier
(various stages) (See Application
developed + CO
Development Plan)
2. System Training Staff identified and
(various target groups according to mobilized for training. SW supplier +
Training Strategy and Training Plan) Staff trained and CO + RO
ready for
implementation.
3. New System Piloting Pilot selected, new SW supplier
(Pilot in one office, Comments, system evaluated, +CO
Improvement) system improved and
ready for installation.
4. Testing and Acceptance Acceptance of the SW supplier
(according to Test Plan) system +CO
5. System implementation (Rollout) System Implemented SW supplier

Software and installed +CO
6. Implementation and Operational System ready for the CO + RO

Tests for Final Acceptance new productions and
daily operations
CO - Central Office; RO – Regional Office; SW –Software
The Bidder can propose its own implementation deviated from the schedule based on its specific approach and methodology; however the
deviations must be well augmented and must lead to improved system development efficiency and a better project result.
350
Annexes
25. MILESTONE
Inception Project Work Plan
Accepted Definition ePRS
Requirements Accepted Analysis and Requirements ePRS
Design Accepted Detailed Design ePRS
Accepted Site Preparation Plan
Development Accepted Development of Basic System Components
Accepted Development of key Application modules
Accepted Development of Front-end Solutions
Accepted ePRS Pilot
Accepted Tested ePRS
Accepted Training Plan
Implementation Accepted Implementation ePRS
Accepted Documentation incl. ePRS Software Code
Operation Accepted procedures for going life with the system
Accepted Operation ePRS (Warranty period)
351
Annexes

Milestones) are provided. The Bidder is expected to complete and adjust this table based on
Delivery Acceptance Liquidated

Deliverable
No. Description (from (from Damages
Type

Report
1 Definition of ePRS Work Product: July 2011 August 2011 No
M1 Report
Inception Milestone August 2011 August 2011 No
2 Analysis and Work Product: July 2011 August 2011 No

Requirements for Report
M2 ePRS
Requirements Milestone August 2011 August 2011 Yes
4 Site Preparation Plan Work Product: July 2011 August 2011 No

Report
M3 5 Detailed Design of Work Product: July 2011 September 2011 No
ePRS Report
Design Milestone September 2011 September 2011 Yes
6 Development of Basic Work Product: September 2011 February 2012 No

System Components Software
(System management, packages
System Administration
and Security, Work Flow
Operations)
7 Development of key Work Product: September 2011 February 2012 No
Application modules Software
(Inventory, Report packages
M4 Server, Document
Management, Property
Registration, Property
Management)
8 Development of Front Work Product: September 2011 February 2012 No
End Solutions Software
(One Stop Shop, Web packages
Publishing)
9 Training Plan Work Product: February 2012 March 2012 No
Report
352
Annexes
10 Pilot Implementation of Work Product: March 2012 March 2012 No

ePRS Software
packages
installed and
tested in Pilot
environment
11 Tested ePRS (for Roll Work Product: March 2012 April 2012 No
out) Software
packages
installed and
tested
Development Milestone April 2012 April 2012 Yes
12 Training Evaluation Work Product: April 2012 April 2012 No

Report
13 Documentation Work Product: April 2012 April 2012 No
Report
14 Implementation of Work Product: May 2012 October 2012 No
M5 ePRS and Operational Software
Tests for Final packages
Acceptance installed, tested
and implemented
Implementation Milestone October 2012 October 2012 Yes
(Operational
Acceptance)
15 Accepted procedures Work Product: May 2012 May 2012 No

for going life with the Report
system
16 Operation of ePRS Work Product: May 2012 March 2014 No
(Warranty period 2years) Services
M6
Operation Milestone March 2014 March 2014 No
353
Annexes
27. SYSTEM INVENTORY TABLE (SUPPLY AND INSTALLATION

COST ITEMS)
described in this section. The Bidder is expected to complete and adjust this table based on the
chosen approach.
1 Definition of ePRS All sites
2 Analysis and Requirements for ePRS All sites
3 Hardware and Network infrastructure and tools minimum requirements All sites
4 Site Preparation Plan All sites
5 Detailed Design of ePRS CO
6 Development of Basic System Components All sites
(System management, System Administration and Security, Work Flow
Operations)
7 Development of key Application modules All sites
(Inventory, Report Server, Document Management, Property
Registration, Property Management)
8 Development of Front End Solutions All sites
(One Stop Shop, Web Publishing)
9 Training Plan CO
10 Pilot Implementation ofePRS CO, one RO
11 TestedePRS (for Roll out) CO, one RO
14 Accepted procedures for going life with the system
15 Implementation of ePRS and Operational Tests for Final Acceptance All sites
16 Operation of ePRS (Warranty period 3 years) All sites
17 Running Operational Data Centre (Option) CO
354
Annexes
28. SYSTEM INVENTORY TABLE (COSTS OF SERVICES)

Besides the deliverable implementation schedule, and System Inventory Table (Supply and
Installation Cost Items), the costs of services items are described in this section. Cost of
services required for the post-warranty period is not included in the price of bid. The Bidder is
expected to complete and adjust this table based on the chosen approach and to include it to
the technical bid (Preliminary Project Plan).
Service Level Agreement for warranty period to be completed for the post-warranty
period
No. Warranty Period

Description Location
Quantities/Requirements
Y1 Y2
118 Service Level Agreement for Warranty Period
18.1 Standard Software Licenses and Updates for Ulaanbaatar,
all items all items
Standard Software Mongolia
18.2 Bug-fixing of Custom Developed Software (under Ulaanbaatar,
all items all items
Warranty) Mongolia
18.3 Maintenance, Helpdesk and Support with regard to Ulaanbaatar,
all items all items
the Operational Environment for ePRS Mongolia
18.4 Technical Services with regard to Change Requests
based on rates for:
Senior Systems Analyst Ulaanbaatar,
all items all items
Junior Systems Analyst Mongolia
Senior Programmer
Junior Programmer
Similar cost indication must be presented by the Bidder regarding the costs for optional
request for Operation Running (staffing) of the DataCenter. The necessary staff monthly fee’s
assuming 2 years support must be proposed by the Bidder.
Running Operational DataCenter

No. Support Period
Description Location
Quantities/Requirements
Y1 Y2
119 Running Operational Data Centre
19.1 Ulaanbaatar,
Competent Staffing and running of DataCenter all items all items
Mongolia
19.2 Ulaanbaatar,
Management of all software issues all items all items
Mongolia
19.3 Management of all hardware and infrastructure Ulaanbaatar,
all items all items
issues Mongolia
19.4 Technical Support with regard to Change Requests
based on rates for:
Manager Data Centre
Ulaanbaatar,
Software Engineer all items all items
Mongolia
Hardware Engineer
Network Engineer
Database Administrator
355
Annexes
29. SITE TABLE

PRIMARY SITE Site Code Site City / Town / Region

TO01

RO04 Zavhan

RO05 Orkhon

SUPPORTING SITES
356
Annexes
Annex I – Structure of Register Book
Book Cover
Key …. Annex 1 of Resolution No. 142 of the
Chairman of GASR, 2010
MONGOLIA
GENERAL AUTHORITY FOR STATE REGISTRATION
State registration number ………………………………….

FILE OF STATE REGISTRATION OF PROPERTIES AND TITLES
Date opened:
Date closed:
………………………………………… aimag/capital city
Table of Contents
Special sheet for file

Property identification
On Owner /possessor, user/
Pledge, hypothec
Other rights
Special notes and preliminary records
Reference and copies
Closure of file
1. Special sheet for file (pages 1-6)
State registration number …………………………
Special sheet for file

Of the State registrar who
Number of
Of the added evidences added evidence
pages of the Total page Evidence
No. documents
first evidence number added date
Content Number of
documents Name Signature
pages
1 2 3 4 5 6 7 8
357
Annexes
2. Property identification (pages 7-10)
State registration number ………………………….

Property identification
Location, territory …………………………………………………

Khoroo: ………………………………………………………………..
Street/Microdistrict…………………………………………………
Number, door number……………………………………………
Designated use ………………………………………………………
Size: ……………………………………………………………………
Price: ……………………………………………………………………
Number of rooms …………………………………………………
Parcel number …………………………………………………………
Other ………………………………………………………………………..
State registrar,
Amendments and Number of
Application date and signature, private
No. modifications to the property certificate Fee
number number and date
/provide detailed grounds/ issued
registered
1 2 3 4 5 7
3. On Owner /possessor, user/ (pages 11-18)

3. On Owner /possessor, user/ (page 11)
Initial owner’s /initial possessor’s, or initial user’s/

family name, father/mother’s name, ID card number,
register number, /legal entity’s title, state registration
number and register number, representative body’s
name, ID card number and register number/
Grounds on which ownership rights are created
Certificate number
Applied date and number
Fee
Name, signature and private number of the State
registrar and registered date
358
Annexes
Changing, adding and excluding owner /possessor, user/ (pages 12-18)
New owner’s /possessor, user/ family name,

father/mother’s name, ID card number, Name, signature
Applied register number, /legal entity’s title, state Issued and private number
No. date and registration number and register number/, certificate Fee of the State
number address of residence, legal grounds on number registrar and
which ownership, /possession, use/ rights registered date
are created and amendments
1 2 3 4 5 6
4. Pledge and hypothec (pages 19-28)

4. Pledge and hypothec
Legal grounds on which Name, signature

Application date and pledging rights are created, and private number
No. Fee
number modifications, records on of the State registrar
termination of rights and registered date
1 2 3 4 5
5. Other rights (pages 29-32)

5. Other rights
Application Legal grounds on which rights are Name, signature and private
No. date and created, modifications, records on Fee number of the State registrar and
number termination of rights registered date
1 2 3 4 5
359
Annexes
6. Special notes and preliminary record (pages 33-36)

6. Special notes and preliminary records
Application Name, signature and private

Grounds for suspension or restoration of
No. date and Fee number of the State registrar and
rights
number registered date
1 2 3 4 5
7. References and copies (pages 37-42)

7. References and copies
No. Application Records on Reference Fee Name, signature and

date and issuance of number private number of the
number references and State registrar and
copies registered date
1 2 3 4 5 6
8. Closure of file (page 43`t)

8. Closure of file
Application date and Legal grounds for Service fee Name, signature and private number
number closing the file shall be of the State registrar who closed the
in detail file and date
360
Annexes
Annex II - List of Tables for TRIADA software
Number of
Table name Columns Precision Nulls
records
T3_ADD_OBJ T3ADO_ADD_OBJ_ID Number(38,0) N 198379
Addresses of objects T3OBJ_OBJECT_ID Number(38,0) N
T3ADD_ADDRESS_ID Number(38,0) N
T3ADO_MAIN Number(22,0) Y
T3_ADDRESS T3ADD_ADDRESS_ID Number(38,0) N 232965
Addresses T3ADD_ADDRESS Varchar2(255) N
T3ADD_X Number(20,6) Y
T3ADD_Y Number(20,6) Y
T3PLN_PLAN_ID Number(38,0) Y
T3CFV_REGION_ID Number(38,0) Y
T3_ADD_SBJ T3ADS_ADD_SBJ_ID Number(38,0) N 84090
Addresses of subjects T3SBJ_SUBJECT_ID Number(38,0) N
T3ADD_ADDRESS_ID Number(38,0) N
T3ADS_MAIN Number(22,0) Y
T3_APL_COMPONENT T3BST_BASEMENT_ID Number(38,0) N 890176
Applications T3SCO_PRS_COMPONENT_ID Number(38,0) N
T3BCO_BST_COMPONENT_ID Number(38,0) N
T3SCO_CMP_COMPONENT_ID Number(38,0) Y
T3OBJ_OBJECT_ID Number(38,0) N
T3APL_TYPE Number(22,0) N
T3APL_REFUSE_INFO Varchar2(512) Y
T3APL_END_DATE Date Y
T3PST_PROCESS_TYPE_ID Number(38,0) N
T3APL_EXPRESS Varchar2(1) N
T3APL_RECIEVE_DATE Date N
T3_APM_COMPONENT T3OBJ_OBJECT_ID Number(38,0) N 103724
Apartments T3OCO_OBJ_COMPONENT_ID Number(38,0) N
T3CFV_PURPOSE_ID Number(38,0) N
T3APM_DIMENSION Float N
T3APM_ADDITIONAL Varchar2(512) Y
T3APM_ROOM_AMOUNT Number(22,0) Y
T3APM_ROOM_LOCATION Varchar2(512) Y
T3APM_ASSESSMENT Number(38,6) N
T3_ASSESSMENT T3ASS_ASSESSMENT_ID Number(38,0) N 1
T3BST_BASEMENT_ID Number(38,0) N
T3SBJ_SUBJECT_ID Number(38,0) N
T3CFV_ASSESSMENT_TYPE_ID Number(38,0) N
T3ASS_REF_ID Number(38,0) N
T3ASS_DATE Date N
T3ASS_VALUE Number(20,2) N
T3ASS_DESCRIPTION Varchar2(255) Y
T3ASS_REG_DATE Date N
T3ASS_ACTUAL Varchar2(1) Y
T3_AUX_APL_VAL T3BCO_BST_COMPONENT_ID Number(38,0) N 0
T3ABV_AUX_BST_VAL_ID Number(38,0) N
T3AXB_AUXILARY_BST_ID Number(38,0) N
T3ABV_STRING Char(255) Y
T3ABV_OLE Long Raw Y
361
Annexes
Number of
records
T3ABV_REFERENCE_ID Number(38,0) Y
T3_AUX_APM_VAL T3AXO_AUXILARY_OBJ_ID Number(38,0) N 0
T3OCO_OBJ_COMPONENT_ID Number(38,0) N
T3AOV_AUX_OBJ_VAL_ID Number(38,0) N
T3AOV_STRING Varchar2(255) Y
T3AOV_OLE Long Raw Y
T3AOV_REFERENCE_ID Number(38,0) Y
T3_AUX_BNK_VAL T3AOV_AUX_OBJ_VAL_ID Number(38,0) N 0
T3AXO_AUXILARY_OBJ_ID Number(38,0) N
T3_AUX_BST_VAL T3ABV_AUX_BST_VAL_ID Number(38,0) N 0
T3ABV_STRING Varchar2(255) Y
T3_AUX_BTR_VAL T3ABV_AUX_BST_VAL_ID Number(38,0) N 0
T3_AUX_BUI_VAL T3AXO_AUXILARY_OBJ_ID Number(38,0) N 0
T3AOV_AUX_OBJ_VAL_ID Number(38,0) N
T3_AUX_CFT_VAL T3AXB_AUXILARY_BST_ID Number(38,0) N 0
T3_AUX_CMP_VAL T3ASV_AUX_SBJ_VAL_ID Number(38,0) N 0
T3AXS_AUXILARY_SBJ_ID Number(38,0) N
T3SCO_SBJ_COMPONENT_ID Number(38,0) N
T3ASV_STRING Varchar2(255) Y
T3ASV_OLE Long Raw Y
T3ASV_REFERENCE_ID Number(38,0) Y
T3_AUX_CONSTRAINT T3AUC_AUX_CONSTRAINT_ID Number(38,0) N 2
T3AUC_REFERENCE Varchar2(255) Y
T3AUC_NAME Varchar2(255) N
T3AUC_MANDATORY Varchar2(1) Y
T3AUC_CHECK Varchar2(255) Y
T3_AUX_ENC_VAL T3AXR_AUXILARY_RTN_ID Number(38,0) N 0
T3ARV_AUX_RTN_VAL_ID Number(38,0) N
362
Annexes
Number of
records
T3RCO_RTN_COMPONENT_ID Number(38,0) N
T3ARV_OLE Long Raw Y
T3ARV_REFERENCE_ID Number(38,0) Y
T3ARV_STRING Varchar2(255) Y
T3_AUXILARY_BST T3AXB_AUXILARY_BST_ID Number(38,0) N 0
T3AUC_AUX_CONSTRAINT_ID Number(38,0) Y
T3AXB_NAME Varchar2(255) N
T3AXB_TYPE Number(38,0) N
T3BSC_BST_CATEGORY_ID Number(38,0) N
T3_AUXILARY_OBJ T3AXO_AUXILARY_OBJ_ID Number(38,0) N 0
T3AXO_NAME Varchar2(255) Y
T3AXO_TYPE Number(38,0) Y
T3OBC_OBJ_CATEGORY_ID Number(38,0) Y
T3_AUXILARY_RTN T3AXR_AUXILARY_RTN_ID Number(38,0) Y 0
T3AXR_NAME Varchar2(255) N
T3AXR_TYPE Number(38,0) N
T3RNC_RTN_CATEGORY_ID Number(38,0) N
T3_AUXILARY_SBJ T3AXS_AUXILARY_SBJ_ID Number(38,0) N 0
T3AXS_NAME Varchar2(255) N
T3AXS_TYPE Number(38,0) N
T3SBC_SBJ_CATEGORY_ID Number(38,0) N
T3_AUX_LEA_VAL T3AXR_AUXILARY_RTN_ID Number(38,0) N 0
T3_AUX_MTG_VAL T3RCO_RTN_COMPONENT_ID Number(38,0) N 0
T3AXR_AUXILARY_RTN_ID Number(38,0) N
T3_AUX_OBJ_VAL T3AOV_AUX_OBJ_VAL_ID Number(38,0) N 0
T3_AUX_PYD_VAL T3AXB_AUXILARY_BST_ID Number(38,0) N 0
T3_AUX_PRC_VAL T3AOV_AUX_OBJ_VAL_ID Number(38,0) N 0
363
Annexes
Number of
records
T3_AUX_PRS_VAL T3ASV_AUX_SBJ_VAL_ID Number(22,0) N 0
T3ASV_STRING Char(255) Y
T3_AUX_REA_VAL T3ARV_AUX_RTN_VAL_ID Number(38,0) N 0
T3_AUX_REU_VAL T3AOV_AUX_OBJ_VAL_ID Number(38,0) N 0
T3_AUX_RFR_VAL T3BCO_BST_COMPONENT_ID Number(38,0) N 0
T3_AUX_RTN_VAL T3ARV_AUX_RTN_VAL_ID Number(38,0) N 0
T3_AUX_SBJ_VAL T3ASV_AUX_SBJ_VAL_ID Number(38,0) N 0
T3ASV_STRING Varchar2(255) Y
T3_AUX_TIT_VAL T3ARV_AUX_RTN_VAL_ID Number(38,0) N 0
T3AXR_AUXILARY_RTN_ID Number(38,0) Y
T3RCO_RTN_COMPONENT_ID Number(38,0) Y
T3_AUX_TYPE T3AUT_AUX_TYPE_ID Number(38,0) N 8
T3AUT_RUS_NAME Varchar2(255) Y
T3AUT_BASE_TYPE Number(22,0) N
T3AUT_MASK Varchar2(255) Y
364
Annexes
Number of
records
T3_BASEMENT T3BST_BASEMENT_ID Number(38,0) N 2777322
Legal documents T3BST_NUMBER Varchar2(255) N
T3BST_DESCRIPTION Varchar2(255) Y
T3BST_DATE Date Y
T3BSC_BST_CATEGORY_ID Number(38,0) N
T3CFV_TYPE_ID Number(38,0) N
T3STS_STATUS_ID Number(38,0) Y
T3BST_PAGE_COUNT Number(22) Y
T3_BNK_ACCOUNT T3BNA_BNK_ACCOUNT_ID Number(38,0) N 0
T3BNA_ACCOUNT Varchar2(255) N
T3_BNK_COMPONENT T3OCO_OBJ_COMPONENT_ID Number(38,0) N 0
Banks T3OBJ_OBJECT_ID Number(38,0) N
T3BNK_CORRESPONDENT_ACC Varchar2(255) Y
OUNT
T3_BST_BST T3BSB_BST_BST_ID Number(38,0) N 1527185
T3BSB_CHILD_ID Number(38,0) N
T3BSB_PARENT_ID Number(38,0) N
T3BSB_TYPE Number(22) N
T3_BST_CATEGORY T3BSC_BST_CATEGORY_ID Number(38,0) N 5
T3BSC_NAME Varchar2(255) N
T3BSC_COMPONENT_TABLE Varchar2(255) N
T3BSC_AUX_VAL_TABLE Varchar2(255) N
T3BSC_TYPE Varchar2(10) N
T3_BST_COMPONENT T3BCO_BST_COMPONENT_ID Number(38,0) N 0
T3_BST_PROCESS T3PBT_BST_PROCESS_ID Number(38,0) N 2661331
T3PCS_PROCESS_ID Number(38,0) N
T3RQI_REQUIRED_INCLUSION_I Number(38,0) N
D
T3_BST_VISUAL T3BVS_BST_VISUAL_ID Number(38,0) N 1
T3BVS_CLASS Varchar2(255) Y
T3BVS_VISUAL Long Raw Y
T3BVS_DEFINITION Varchar2(255) N
T3_BTR_COMPONENT T3BCO_BST_COMPONENT_ID Number(38,0) N 797156
Attachments to applications T3BST_BASEMENT_ID Number(38,0) N
T3BTR_TOPIC_ID Number(38,0) Y
T3BTR_INPUT_DATE Date N
T3BTR_OUT_NUMBER Varchar2(255) Y
T3_BUI_COMPONENT T3OBJ_OBJECT_ID Number(38,0) N 45657
Buildings T3OCO_OBJ_COMPONENT_ID Number(38,0) N
T3CFV_PURPOSE_ID Number(38,0) N
T3BUI_DIMENSION Float N
T3BUI_ADDITIONAL Varchar2(512) Y
T3BUI_ASSESSMENT Number(38,6) N
T3_CFT_COMPONENT T3BCO_BST_COMPONENT_ID Number(38,0) N 200013
Certificates T3BST_BASEMENT_ID Number(38,0) N
365
Annexes
Number of
records
T3CFT_REG_PLACE Varchar2(255) Y
T3CFT_CERTIFICATE_NUMBER Varchar2(255) N
T3CFT_END_DATE Date Y
T3_CHECK_DESCRIPTIO T3CHD_CHECK_DESCRIPTION_I Number(38,0) N 231
N D
T3CHR_CHECK_RULE_ID Number(38,0) Y
T3CHD_LANGUAGE Number(22,0) N
T3CHD_DESCRIPTION Varchar2(512) N
T3_CHECKED_OBJECT T3CHO_CHECKED_OBJECT_ID Number(38,0) N 18
T3CHO_CODE Varchar2(50) N
T3CHO_DESCRIPTION Varchar2(512) Y
T3_CHECK_RULE T3CHR_CHECK_RULE_ID Number(38,0) N 77
T3CHT_CHECK_RULE_TYPE_ID Number(38,0) N
T3CHO_CHECKED_OBJECT_ID Number(38,0) N
T3CHR_NAME Varchar2(255) N
T3CHR_SQL Varchar2(4000) N
T3CHR_AVAILABLE Varchar2(1) N
T3CHR_ACTION Varchar2(1) N
T3_CHECK_RULE_TYPE T3CHT_CHECK_RULE_TYPE_ID Number(38,0) N 11
T3CHT_CODE Varchar2(50) N
T3CHT_DESCRIPTION Varchar2(512) Y
T3_CLASSIFIER_NAME T3CFN_CLASSIFIER_NAME_ID Number(38,0) N 17
Classifiers T3CFN_NAME Varchar2(255) N
T3CFN_CODE Varchar2(50) N
T3CFN_ACCESS_CODE Varchar2(50) Y
T3CFV_CLASSIFIER_VALUE_ID Number(38,0) Y
T3LVN_LEVEL_NAME_ID Number(38,0) Y
T3CFV_VALUE Varchar2(255) Y
T3CFV_PARENT_LEVEL_ID Number(38,0) Y
T3CFV_CODE Varchar2(50) Y
T3_CLASSIFIER_VALUE T3CFV_CLASSIFIER_VALUE_ID Number(38,0) N 489
Classifier values T3LVN_LEVEL_NAME_ID Number(38,0) N
T3CFV_VALUE Varchar2(255) N
T3CFV_PARENT_LEVEL_ID Number(38,0) Y
T3CFV_CODE Varchar2(50) Y
T3_CMP_COMPONENT T3SBJ_SUBJECT_ID Number(38,0) N 5689
Legal entities T3SCO_SBJ_COMPONENT_ID Number(38,0) N
T3SCO_LEGAL_PERSON_TYPE_I Number(38,0) Y
D
T3_COMMAND_LOG T3CML_COMMAND_LOG_ID Number(38,0) N 6141702
Log of commands T3USR_USER_ID Number(38,0) N (445091)
T3CML_DATE Date N
T3CML_CODE Varchar2(50) N
T3CML_DESCRIPTION Varchar2(512) Y
T3CML_BASE_CATEGORY Number(38,0) N
T3CML_COMP_CODE Varchar2(50) N
T3CML_COMP_NAME Varchar2(512) N
T3CML_COMMENTS Varchar2(1024) Y
T3_COMMUNICATION T3COM_COMMUNICATION_ID Number(38,0) N 4236
366
Annexes
Number of
records
T3CFV_CLASSIFIER_VALUE_ID Number(38,0) Y
T3COM_DESCRIPTION Varchar2(512) Y
T3_CONTOUR T3CNT_CONTOUR_ID Number(38,0) N 0
T3MSM_MEASURE_ID Number(38,0) N
T3CNT_CLOSED Varchar2(1) Y
T3CNT_POLYGON Varchar2(1) Y
T3CNT_EXTERIOR Varchar2(1) Y
T3CNT_LENGTH Number(20,6) Y
T3CNT_ORDER Number(38,0) Y
T3_CONTOUR_POINT T3CPT_CONTOUR_POINT_ID Number(38,0) N 0
T3CNT_CONTOUR_ID Number(38,0) N
T3GPT_GEODETIC_POINT_ID Number(38,0) Y
T3CPT_ORDER Number(38,0) Y
T3CPT_X Number(20,6) N
T3CPT_Y Number(20,6) N
T3CPT_ANALITIC Varchar2(1) Y
T3_ENC_COMPONENT T3RCO_RTN_COMPONENT_ID Number(38,0) N 3
T3RTN_RELATION_ID Number(38,0) N
T3CFV_ENC_TYPE_ID Number(38,0) N
T3_ENTITY T3ENT_ENTITY_ID Number(38,0) N 0
T3ENT_PK_NAME Varchar2(100) Y
T3ENT_NAME Varchar2(100) N
T3ENT_LAST_KEY Number(22,0) N
T3_FORM T3FRM_FORM_ID Number(38,0) N 24
T3FML_FORM_LIBRARY_ID Number(38,0) N
T3FRM_FORM Varchar2(255) N
T3FRM_DESCRIPTION Varchar2(1024) Y
T3FRM_MODIFIED_DATE Date N
T3FRM_ANALISYS Varchar2(1) N
T3_FORM_BLOCK T3FMB_BLOCK_ID Number(38,0) N 11
T3FMC_FORM_COMPONENT_ID Number(38,0) N
T3FMB_BLOCK Varchar2(255) N
T3_FORM_COMPONENT T3FMC_FORM_COMPONENT_ID Number(38,0) N 8
T3FMC_BASE_CATEGORY Varchar2(100) N
T3FMC_CATEGORY Varchar2(100) Y
T3_FORM_LIBRARY T3FML_FORM_LIBRARY_ID Number(38,0) N 2
T3FML_LIBRARY Varchar2(255) N
T3FML_PATH Varchar2(1024) N
T3_FRM_FMB T3FRB_FRM_FMB_ID Number(38,0) N 21
T3FRM_FORM_ID Number(38,0) N
T3FMB_BLOCK_ID Number(38,0) Y
T3FMC_FORM_COMPONENT_ID Number(38,0) Y
T3_GEODETIC_POINT T3GPT_GEODETIC_POINT_ID Number(38,0) N 0
T3CFV_GEONET_TYPE_ID Number(38,0) N
T3GPT_NAME Varchar2(255) N
T3GPT_X Number(20,6) N
T3GPT_Y Number(20,6) N
T3GPT_DESCRIPTION Varchar2(255) Y
T3_GEOMETRY T3GMT_GEOMETRY_ID Number(38,0) N 0
367
Annexes
Number of
records
T3PLN_PLAN_ID Number(38,0) N
T3GMT_DESCRIPTION Varchar2(512) Y
T3GMT_AREA Number(20,6) Y
T3GMT_PERIMETER Number(20,6) Y
T3_GRANTED_ROLE T3GRO_GRANTED_ROLE_ID Number(38,0) N 69
T3USR_USER_ID Number(38,0) N
T3ROL_ROLE_ID Number(38,0) N
T3_ID_REF T3_DB_ID Number(22) N 0
T3_REF_ID Number(22) N
T3_INCLUSION_STRUCT T3INS_INCLUSION_STRUCT_ID Number(38,0) N 348
T3RQI_PARENT_ID Number(38,0) N
T3RQI_CHILD_ID Number(38,0) N
T3_LEA_COMPONENT T3RTN_RELATION_ID Number(38,0) N 614
T3LEA_RENT Float N
T3LEA_END_DATE Date N
T3LEA_START_DATE Date N
T3_LEVEL_NAME T3LVN_LEVEL_NAME_ID Number(38,0) N 29
Classifier levels T3LVN_NAME Varchar2(255) N
T3LVN_CODE Varchar2(50) N
T3LVN_PARENT_LEVEL_ID Number(38,0) Y
T3CFN_CLASSIFIER_NAME_ID Number(38,0) N
T3_LOCK T3LCK_LOCK_ID Number(38,0) N 218
T3LCK_RECORD_ID Number(38,0) N
T3LCK_TABLE_NAME Varchar2(255) N
T3LCK_DW_CLASS Varchar2(255) Y
T3LCK_COMPONENT_CODE Varchar2(255) Y
T3LCK_LONG_TRANSACTION Varchar2(1) N
T3LCK_DATE Date N
T3_MASK T3MSK_MASK_ID Number(38,0) N 13
T3MST_MASK_TYPE_ID Number(38,0) N
T3MSK_MASK Varchar2(255) N
T3MSK_CODE Varchar2(50) N
T3MSK_DESCRIPTION Varchar2(512) Y
T3_MASKED_FIELD T3MSF_MASKED_FIELD_ID Number(38,0) N 15
T3MSK_MASK_ID Number(38,0) N
T3MSF_MODULE_CODE Varchar2(100) N
T3MSF_DW Varchar2(100) N
T3MSF_FIELD Varchar2(100) N
T3MSF_URL Varchar2(1024) N
T3_MASK_SEQ T3MSQ_MSK_SEQ_ID Number(38,0) N 15
T3MSQ_URL Varchar2(512) N
T3MSQ_VALUE Number(38,0) N
T3_MASK_TYPE T3MST_MASK_TYPE_ID Number(38,0) N 3
T3MST_DESCRIPTION Varchar2(512) N
T3MST_CODE Varchar2(50) N
T3_MEASUREMENT T3MSM_MEASURE_ID Number(38,0) N 0
368
Annexes
Number of
records
T3MSM_DATE Date Y
T3MSM_ACTUAL Varchar2(1) N
T3_MTG_COMPONENT T3RTN_RELATION_ID Number(38,0) N 137059
Mortgages T3RCO_RTN_COMPONENT_ID Number(38,0) N
T3MTG_END_DATE Date Y
T3MTG_CREDIT_VALUE Number(20,6) N
T3MTG_CREDIT_PERCENT Number(20,6) Y
T3_NOTARY T3NTR_NOTARY_ID Number(38,0) N 58
Notaries T3SBJ_SUBJECT_ID Number(38,0) Y
T3NTR_NUMBER Varchar2(50) N
T3_NOTARY_CERTIFIC T3NTC_NOTARY_CERTIFICATE_ Number(38,0) N 32873
ATE ID
Notary certificates T3BST_BASEMENT_ID Number(38,0) N
T3NTC_DATE Date N
T3NTC_NUMBER Varchar2(50) N
T3NTC_DESCRIPTION Varchar2(1024) Y
T3NTR_NOTARY_ID Number(38,0) N
T3_OBJ_BST T3OBB_OBJ_BST_ID Number(38,0) N 11038
T3OBB_TYPE Number(22) N
T3_OBJ_CATEGORY T3OBC_OBJ_CATEGORY_ID Number(38,0) N 5
Object categories T3OBC_NAME Varchar2(255) N
T3OBC_COMPONENT_TABLE Varchar2(255) N
T3OBC_AUX_VAL_TABLE Varchar2(255) N
T3OBC_TYPE Varchar2(10) N
T3_OBJ_COMPONENT T3OCO_OBJ_COMPONENT_ID Number(38,0) N 0
T3_OBJECT T3OBJ_OBJECT_ID Number(38,0) N 200185
Objects T3OBJ_NUMBER Varchar2(255) N
T3OBJ_DESCRIPTION Varchar2(255) Y
T3OBJ_DATE Date Y
T3OBC_OBJ_CATEGORY_ID Number(38,0) N
T3STS_STATUS_ID Number(38,0) N
T3_OBJ_OBJ T3OBB_OBJ_OBJ_ID Number(38,0) N 2
T3OBB_CHILD_ID Number(38,0) N
T3OBB_PARENT_ID Number(38,0) N
T3_OBJ_OVS T3OBV_OBJ_OVS_ID Number(38,0) N 0
T3OVS_OBJ_VISUAL_ID Number(38,0) N
T3_OBJ_PROCESS T3PBJ_OBJ_PROCESS_ID Number(38,0) N 886014
D
T3_OBJ_RTN T3OBR_OBJ_RTN_ID Number(38,0) N 406758
369
Annexes
Number of
records
T3OBR_TYPE Number(22) N
T3_OBJ_VISUAL T3OVS_OBJ_VISUAL_ID Number(38,0) N 0
T3OVS_CLASS Varchar2(255) Y
T3OVS_VISUAL Long Raw Y
T3OVS_DEFINITION Varchar2(255) N
T3_PCS_ACTION_SETTI T3PAS_PCS_ACTION_SETTING_I Number(38,0) N 122
NG D
T3PCI_PROCESS_INCLUSION_ID Number(38,0) N
T3PCA_PROCESS_ACTION_ID Number(38,0) N
T3POA_PCS_OBJECT_ACTION_I Number(38,0) N
D
T3_PCS_OBJECT_ACTIO T3POA_PCS_OBJECT_ACTION_I Number(38,0) N 20
N D
T3STS_SRC_STATUS_ID Number(38,0) N
T3STS_DST_STATUS_ID Number(38,0) N
T3POA_CODE Varchar2(100) N
T3_PYD_COMPONENT T3BST_BASEMENT_ID Number(38,0) N 772248
Payment documents T3BCO_BST_COMPONENT_ID Number(38,0) N
T3PYD_PERIOD Date Y
T3PYD_SERVICE_FEE Float N
T3_PLAN T3PLN_PLAN_ID Number(38,0) N 0
T3PLN_NAME Varchar2(255) N
T3PLN_FILE Varchar2(1024) Y
T3PLN_MODULE Varchar2(50) Y
T3PLN_ORDER Number(38,0) Y
T3PLN_GEOCODE Varchar2(1) N
T3PLN_READONLY Varchar2(1) N
T3PLN_NAMEFIELD Varchar2(255) Y
T3_PRC_COMPONENT T3OCO_OBJ_COMPONENT_ID Number(38,0) N 25767
Land parcels T3OBJ_OBJECT_ID Number(38,0) N
T3PRC_LAND_USE_ID Number(38,0) N
T3PRC_AREA Float N
T3PRC_ADDITIONAL Varchar2(512) Y
T3PRC_ASSESSMENT Number(38,6) N
T3_PROCESS T3PCS_PROCESS_ID Number(38,0) N 873219
Processes T3PSS_PROCESS_STATUS_ID Number(38,0) N
T3PCS_NAME Varchar2(255) Y
T3PCS_CREATE_DATE Date N
T3PCS_FINISH_DATE Date Y
T3PCS_NUMBER Varchar2(255) N
T3_PROCESS_ACTION T3PCA_PROCESS_ACTION_ID Number(38,0) N 5
T3PSS_SRC_STATUS_ID Number(38,0) N
T3PSS_DST_STATUS_ID Number(38,0) N
T3PCA_CODE Varchar2(100) N
T3_PROCESS_INCLUSIO T3PCI_PROCESS_INCLUSION_ID Number(38,0) N 121
N
T3PCI_NAME Varchar2(255) N
T3PCI_COMPONENT_CODE Varchar2(50) N
T3_PROCESS_STATUS T3PSS_PROCESS_STATUS_ID Number(38,0) N 4
370
Annexes
Number of
records
T3PSS_NAME Varchar2(255) N
T3_PROCESS_TYPE T3PST_PROCESS_TYPE_ID Number(38,0) N 42
T3PST_NAME Varchar2(255) N
T3PST_TERM Number(22) Y
T3PST_CODE Varchar2(50) Y
T3_PROCESS_USER T3PSU_PROCESS_USER_ID Number(38,0) N 209241
T3PSU_ACTIVE Varchar2(1) N
T3PSU_ASSIGN Varchar2(1) N
T3_PRO_COMPONENT T3OCO_OBJ_COMPONENT_ID Number(38,0) N 0
T3PRO_PROPERTY_TYPE_ID Number(38,0) N
T3_PRO_OBJ T3POB_PRO_OBJ_ID Number(38,0) N 0
T3PRO_PROPERTY_ID Number(38,0) N
T3_PROPS T3PRP_PROPS_ID Number(38,0) N 0
T3PRP_NAME Varchar2(255) N
T3PRP_VALUE Varchar2(1024) N
T3PRP_PROTECTED Varchar2(1) N
T3PRP_DESCRIPTION Varchar2(255) N
T3_PROP_TYPE T3PPT_PROP_TYPE_ID N N 1
T3PPT_CODE N N
T3_PROP_VALUE T3PRV_PROP_VALUE_ID Number(38,0) N 1235
T3USR_USER_ID Number(38,0) Y
T3ROL_ROLE_ID Number(38,0) Y
T3RES_RESOURCE_ID Number(38,0) N
T3REP_RESOURCE_PROP_ID Number(38,0) N
T3PRV_VALUE Varchar2(255) N
T3_PRS_COMPONENT T3SCO_SBJ_COMPONENT_ID Number(38,0) N 447164
Natural persons T3SBJ_SUBJECT_ID Number(38,0) N
T3PRS_FIRST_NAME Varchar2(255) N
T3PRS_LAST_NAME Varchar2(255) N
T3PRS_BIRTHDAY Date Y
T3PRS_BIRTHPLACE Varchar2(512) Y
T3PRS_SEX Varchar2(1) N
T3PRS_PASSPORT Varchar2(255) Y
T3CFV_CITIZENSHIP_ID Number(38,0) N
T3_REA_COMPONENT T3RCO_RTN_COMPONENT_ID Number(38,0) N 0
Immovable properties T3RTN_RELATION_ID Number(38,0) N
T3REA_START_DATE Date N
T3REA_END_DATE Date Y
T3REA_DEAL_VALUE Float Y
T3_REA_SBJ T3RAS_REA_SBJ_ID Number(38,0) N 0
T3_RECORD_LOG T3RCL_RECORD_LOG_ID Number(38,0) N >5313789
Log of records T3CML_COMMAND_LOG_ID Number(38,0) N
T3RCL_RECORD_ID Number(38,0) N
T3RCL_DESCRIPTION Varchar2(1024) Y
371
Annexes
Number of
records
T3RCL_MODIFIED_FIELD Varchar2(1024) Y
T3RCL_DW_CLASSNAME Varchar2(50) N
T3RCL_DW_NAME Varchar2(512) N
T3_REG_BOOK T3RBK_REG_BOOK_ID Number(38,0) N 50
T3RBK_STATE_LINK_ID Number(38,0) Y
T3RBK_DATE Date N
T3RBK_CURRENT Varchar2(1) N
T3RBK_DESCRIPTION Varchar2(1024) Y
T3RBK_PAGE_COUNT Number(22) Y
T3_RELATION T3RTN_RELATION_ID Number(38,0) N 406758
Relations T3RNC_RTN_CATEGORY_ID Number(38,0) N
T3RTN_DATE Date N
T3RTN_DESCRIPTION Varchar2(255) Y
T3RTN_NUMBER Varchar2(255) N
T3_REQUIRED_INCLUSI T3RQI_REQUIRED_INCLUSION_I Number(38,0) N 259
ON D
T3PCI_PROCESS_INCLUSION_ID Number(38,0) N
T3RQI_CLASSIFER_ID Number(38,0) N
T3RQI_MANDATORY Varchar2(1) N
T3_RESOURCE T3RES_RESOURCE_ID Number(38,0) N 301
T3RET_RESOURCE_TYPE_ID Number(38,0) N
T3RES_URL Varchar2(255) N
T3RES_LOCALIZE_NAME Varchar2(255) N
T3_RESOURCE_PROP T3REP_RESOURCE_PROP_ID Number(38,0) N 10
T3RET_RESOURCE_TYPE_ID Number(38,0) N
T3PPT_PROP_TYPE_ID Number(38,0) Y
T3REP_NAME Varchar2(255) N
T3REP_CODE Varchar2(10) Y
T3REP_DEFAULT Varchar2(255) Y
T3_RESOURCE_TYPE T3RET_RESOURCE_TYPE_ID Number(38,0) N 5
T3RET_CODE Varchar2(10) N
T3_REU_COMPONENT T3OCO_OBJ_COMPONENT_ID Number(38,0) N 0
T3REU_AREA Float N
T3REU_COST Float N
T3_REU_EXTRA T3REE_REU_EXTRA_ID Number(38,0) N 0
T3REE_DESCRIPTION Varchar2(255) N
T3REE_TYPE Number(22,0) N
T3REE_VALUE Float N
T3_RFR_COMPONENT T3BCO_BST_COMPONENT_ID Number(38,0) N 117519
References T3BST_BASEMENT_ID Number(38,0) N
T3SBJ_SUBJECT_ID Number(38,0) Y
T3RFR_CONTENT Varchar2(4000) N
T3_ROLE T3ROL_ROLE_ID Number(38,0) N 13
372
Annexes
Number of
records
T3ROL_NAME Varchar2(255) N
T3ROL_CODE Varchar2(10) N
T3ROL_ACCESS Varchar2(10) Y
T3_RTN_BST T3RBS_RTN_BST_ID Number(38,0) N 738717
T3RBS_TYPE Number(22) N
T3_RTN_CATEGORY T3RNC_RTN_CATEGORY_ID Number(38,0) N 4
Relation categories T3RNC_NAME Varchar2(255) N
T3RNC_COMPONENT_TABLE Varchar2(255) N
T3RNC_AUX_VAL_TABLE Varchar2(255) N
T3RNC_TYPE Varchar2(10) N
T3_RTN_COMPONENT T3RCO_RTN_COMPONENT_ID Number(38,0) N 0
T3_RTN_PROCESS T3PRT_RTN_PROCESS_ID Number(38,0) N 699113
D
T3_RTN_RTN T3RTR_RTN_RTN_ID Number(38,0) N 137673
T3RTR_CHILD_ID Number(38,0) N
T3RTR_PARENT_ID Number(38,0) N
T3RTR_TYPE Number(22) Y
T3_SBJ_BST T3SBB_SBJ_BST_ID Number(38,0) N 403167
T3SBB_TYPE Number(22) N
T3_SBJ_CATEGORY T3SBC_SBJ_CATEGORY_ID Number(38,0) N 2
Subject categories T3SBC_NAME Varchar2(255) N
T3SBC_COMPONENT_TABLE Varchar2(255) N
T3SBC_AUX_VAL_TABLE Varchar2(255) N
T3SBC_TYPE Varchar2(10) N
T3_SBJ_COMPONENT T3SCO_SBJ_COMPONENT_ID Number(38,0) N 0
T3_SBJ_PROCESS T3PSJ_SBJ_PROCESS_ID Number(38,0) N 1840208
D
T3_SBJ_RTN T3SBR_SBJ_RTN_ID Number(38,0) N 595367
T3SBR_TYPE Number(22) N
T3_SBJ_SBJ T3SBB_SBJ_SBJ_ID Number(38,0) N 0
T3SBB_CHILD_ID Number(38,0) N
T3SBB_PARENT_ID Number(38,0) N
T3_SBJ_VISUAL T3SVS_SBJ_VISUAL_ID Number(38,0) N 7
T3SVS_CLASS Varchar2(255) Y
T3SVS_VISUAL Long Raw Y
373
Annexes
Number of
records
T3SVS_DEFINITION Varchar2(255) N
T3_STATUS T3STS_STATUS_ID Number(38,0) N 15
Statuses T3STS_NAME Varchar2(255) N
T3STS_CODE Varchar2(10) N
T3_SUBJECT T3SBJ_SUBJECT_ID Number(38,0) N 452847
Subjects T3SBJ_NUMBER Varchar2(255) N
T3SBJ_DESCRIPTION Varchar2(255) Y
T3SBJ_DATE Date Y
T3SBC_SBJ_CATEGORY_ID Number(38,0) N
T3_TIT_COMPONENT T3RCO_RTN_COMPONENT_ID Number(38,0) N 269082
Rights T3RTN_RELATION_ID Number(38,0) N
T3TIT_NUMERATOR Number(22,0) Y
T3TIT_DENOMINATOR Number(22,0) Y
T3_USER T3USR_USER_ID Number(38,0) N 87
System users T3USR_NAME Varchar2(255) N
T3USR_LOGIN Varchar2(255) N
T3USR_DISABLE Varchar2(1) N
T3_USER_REGION T3URR_USER_REGION_ID Number(38,0) N 0
T3CFV_REGION_ID Number(38,0) N
374
Annexes
A
TRIADA
T data model (draft)
375
3
Annexes
Annex III - List of Tables for REAL software
Default
Table name Columns Data type Nulls Description
value
Aimag_code a_code varchar(1) Y Letter code of
aymag
Aymags a_name varchar(15) Y Name of
aymag
Bank ID unique identifier N New id() Record ID
Banks Name marcher(500) N Name of bank
Intend into N ID code of
IDENTITY(1,1) bank(?)
Owner ID unique identifier N New id() Record ID
Owners MiddleName nvarchar(150) Y Middle name
LastName nvarchar(150) Y Last name
FirstName nvarchar(150) N First name
RegisterNumber nvarchar(50) N Register
number
Tuluv nvarchar(50) Y Ownership
status (current
owner, former
owner)
Date datetime Y Getdate() Date (depends
of application
type)
USER_Name nvarchar(50) Y User name,
who registered
WHICH bigint Y ?
UserRegister nvarchar(50) Y User register
number
IsDeleted int Y Mark (1) if
record is
deleted
DeletedUser nvarchar(50) Y User name,
who deleted
record
UBDOWNER nvarchar(50) Y State
registration
number*
Subject ID unique identifier N New id() Record ID
Applicant types Name nvarchar(50) Y Applicant type
(citizen, legal
entity, public
entity)
sum_code a_code varchar(1) N Letter code of
aymag
Soums s_name varchar(30) N Soum name
s_code varchar(1) N 2-nd letter
376
Annexes
Default
value
code of soum
(unique
together with
aymag code)
tailan ID unique identifier Y New id() Record ID
Applications UlHudluhToUilchil unique identifier Y Reference to
geeID the property
and
application
type
meduuleg_name nvarchar(50) Y Applicant
meduuleg_register nvarchar(50) Y Applicant
register
tolbor bigint Y Payment
temdegt bigint Y Stamp duty
tatvar bigint Y Tax
baritsaa_zeel bigint Y Pledge
bank_ID unique identifier Y Reference to
the bank
hudaldah_geree bit Y Sales contract
UserName nvarchar(50) Y User name,
who registered
Date datetime Y Getdate() Registration
date (cannot
be changed)
SubjectID unique identifier Y Reference to
the applicant
type
UilchilgeeID unique identifier Y Reference to
the application
type
UBD_tailan nvarchar(50) Y State
registration
number*
TuluV NAME nvarchar(50) Y Ownership
Ownership statuses status name
Uilchilgee ID unique identifier N New id() Record ID
Application types Name nvarchar(500) Y Name of
application
type
UlTURUL bigint Y Type of
property (2 –
land, 1 –
other)
INTID int Y Sorting index
Change bigint Y Ownership
377
Annexes
Default
value
change (1 –
Yes, 0 – No)
UlHudluh ID unique identifier N New id() Record ID
Immovable properties CreatedDate datetime N Getdate() Creation date
(?)
UBD nvarchar(50) N State
registration
number
GNTD nvarchar(50) Y Parcel ID
Horoo nvarchar(500) N Khoroo name
Address nvarchar(500) N Address
Square nvarchar(500) N Property size
Price money N Price
UlTurulID unique identifier N Reference to
the property
type(?)
ZoriulaltID unique identifier N Reference to
the designated
use type
USER nvarchar(50) Y User name,
who registered
IsDeleted int Y Mark if record
is deleted
DeletedUser nvarchar(50) Y User name,
who deleted
record
UserRegister nvarchar(50) Y User register
number
Aimag_code nvarchar(50) Y Letter code of
aymag
Sum_code nvarchar(50) Y Letter code of
soum
add_xoroolol bigint Y District
number in
address
add_baishin bigint Y House number
in address
add_haalga bigint Y Apartment
number in
address
bag_code bigint Y Smallest
administrative
unit
UlHudluhToOwner ID unique identifier N New id() Record ID
Property-owner cross CreatedDate datetime N Getdate() Registration
references date
378
Annexes
Default
value
UlhudluhID unique identifier N Reference to
the property
OwnerID unique identifier N Reference to
the owner
UBD_OWNER nvarchar(50) Y State
registration
number*
UILCHILGEE_ID unique identifier Y Reference to
the application
type
UlHudluhToUilchilge ID unique identifier N New id() Record ID
e
Application-property CreatedDate datetime N Getdate() Registration
references date
UlhudluhID unique identifier N Reference to
the immovable
property
UilchilgeeID unique identifier N Reference to
the type of
application
User_Name nvarchar(50) Y User name,
who registered
UBD_UILCHILGE nvarchar(50) N State
E registration
number(?)
UITurul ID unique identifier New id() Record ID
Property types Name nvarchar(100) Property type
name
User ID unique identifier N New id() Record ID
Users UserName nvarchar(50) N User name
FirstName nvarchar(50) Y User first
name
LastName nvarchar(50) Y User last name
Password nvarchar(50) N Password
Role bigint N Reference to
the user role
register_number nvarchar(50) Y User register
number
UserRole id int Y Role ID
User roles Name nvarchar(50) Y Name of role
Zoriulalt ID unique identifier N New id() Record ID
Intended use of Name nvarchar(150) N Use type name
property
379
Anneexes
REAL
L data modeel
380
Annex IV - Proposed digitization Plan
Aimag/GASR Approximated Number

Number Estimated Estimated Estimated Proposed Estimated
Property number of Digitization Unit of of
No Quantity of hours for Work Start of End of End of
Registration archived process Measure people
Teams completion Days digitization Process Location
Office folders involved
Inventory documentations 4,917 1 2 49 6 2011-07-01 2011-07-11
Scanning documentations 4,917 1 2 49 6 2011-07-02 2011-07-11

Pilot Baganuur 4,917 2011-07-25
Digitization documentations 4,917 1 5 49 6 2011-07-08 2011-07-18
Quality control documentations 4,917 1 2 49 6 2011-07-15 2011-07-25

1 Ulaanbaatar 198,673 2011-12-21

2 Darkhan-Uul 22,426 2011-10-06

3 Dornod 13,268 2011-09-20

4 Khentii 6,828 2011-09-08
5 Khovd 6,598 Scanning documentations 6,598 1 2 65 8 2011-08-16 2011-08-26 2011-09-08
381

6 Orkhon 22,588 2011-10-06

7 Övörkhangai 11,275 2011-09-16

8 Töv 10,877 2011-09-15

9 Zavkhan 4,476 2011-09-05

Total folders in
297,009 - - - - 6560 - -
the Mongolia
Minimum Human Resources Required per Digitization Location

Team Name Number of people involved Estimated Productivity Rate (Documents/hour/people)
Inventory Team 2 50
Scanning Team 2 50
Digitization Team 5 20
Quality Control Team 2 50
382
SR5 Drawings
Not applicable
383
SR6 Inspections & Tests
Generally, the project management and the quality assurance (QA) management has to
follow international standards RUP methodology or similar in the testing process.
The Testing process is an integrated approach to testing the quality of all elements of the
System. It can include functionally oriented module testing and business-oriented module
integration, system, systems integration and acceptance testing. All business oriented
testing is driven by the Business Architecture requirements to establish firm traceability
back to business requirements.
The process emphasizes a common planning approach to all types of testing. It advocates
the re-use of testing scripts in successively larger and larger portions of the application
system. Testing must contain module testing, but surely other forms of testing, such as
module integration, and systems integration testing.
The Testing process approach first identifies testing requirements and maintains and
enhances them through the end of the project. For example, business scenarios / uses
cases are identified while developing the Business Process Model, and they contribute to
module, module integration, and systems integration testing.
Functional module requirement produce testing requirements that are specific to an
elementary business function (EBF). These testing requirements also contribute to
module test plans, when EBFs are mapped to modules. Development Standards for the
User Interface Style Definition produce a QA checklist of behavioral tests that are
performed during module testing.
The Testing process must be based on a useful and representative dataset to be able to
perform all different kinds of tests. The dataset should be obtained by conversion of data
from existing TRIADA and REAL databases.
The testing process contributes to the development of integrated test plans, fully tested
software, and independently confirmed software tests and results. It defines a defect
tracking, resolution, and regression test infrastructure to provide dependable fault
correction and trend analysis.
Test Preparation
Part of the Testing and Acceptance Management is the preparation for testing. The
following must be included when preparing for integration and testing:
 Develop detailed test material
This includes defining scenarios, scripts, timelines, checklists, processes, test sets, and
test cases.
 Establish procedures
Write test procedures (steps to actually perform tests). Specific procedures are described
within each test case or test script. These procedures include descriptions of how to set up
384
the test, the sequence of tests, what is being tested, the conditions needed for a specific
test, and the test’s expected results. Ensure that procedures are executed properly.
 Generate and validate test data
 Use/modify existing data (data mining)
 Verify data quality (data scrubbing)
 Create new data requirements
 Create procedures to refresh data once testing begins.
 Establish verification criteria.
 Identify resources
Coordinate and review detailed test material for this review, use a variety of techniques,
including readiness review, procedure walk-troughs or reviews and dry runs.
 Test stations that test multiple users
Debug and test their synchronization before the actual test takes place.
 Establish a detailed test schedule
 Install and set up the test environment
 Train all participants
Train them in testing in general tools, applications, and hardware, software, and test-
support processes.
Operational Acceptance Tests
The Purchaser (with the assistance of the Supplier) and involvement of consultancy
Blominfo A/S will perform the following tests on the System and its Subsystems
following Installation to determine whether the System and the Subsystems meet all the
requirements mandated for Operational Acceptance:
 Module / Function test for each specified System function in isolation
 Module Integration Test for a group of System Functions
 System test per Subsystem
 System Integration test for all Subsystems
The subsystems are described before, and the details on System Functions and their
coherence will be provided by the requirements phase.
The acceptance will consist also of an acceptance of the complete Software Code for
ePRS that should be fully commented/described, line by line
385
SR7 Environmental, Health and Safety Procedures

The Supplier shall abide by the following environmental, health and safety requirements:
This Contract falls under Category C. Please refer to “Guidelines for Environmental and
Social Assessment” by MCC for the environmental, health and safety requirements at:
http://www.mcc.gov/documents/guidance/20-enviroandsocialassessment.pdf
386

2011 099PRP

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2011 099PRP

Hochgeladen von

Copyright:

Verfügbare Formate

MIL

CONTENTS ................................................................................................................................................. II

A. General ............................................................................................................... 1

G. General ............................................................................................................. 31

BID FORMS ............................................................................................................................................... 37

CONTRACT FORMS ................................................................................................................................ 62

II. Agreement ........................................................................................................ 63

Letter of Invitation for Bids

Re: IT EQUIPMENT AND SOFTWARE - Supply, Installation and

Bid Ref: CA/MCA-M/MCC/PRP/GDS/099/2011

6. A supplier will be selected under the a competitive bidding method, the

Section 1 Instructions to Bidders

Orgil Complex, Chinggis Ave, Khoroo 11, Khan-Uul District

provides Bidders with information needed to prepare their

1.2 Throughout this Bidding Document except where the

selection process or the execution of the Contract, without

Eligibility of 4.2 Government-Owned Enterprises (GOEs) are not eligible

Ineligibility 4.3 Bidders and Suppliers (including their associates, if any,

the countries subject to these sanctions and restrictions

4.4 A Bidder or Supplier (including their associates, if any,

4.6 Any Bidder may propose to sub-contract a part of the

4.7 Qualification requirements for the Bidder in addition to

4.8 Bidders must also satisfy the eligibility criteria

4.9 Bidders shall provide such evidence of their continued

5.2 For purposes of ITB Sub-Clause 5.1, the term “origin”

5.3 A Bidder that does not manufacture or produce the

Section 4: Bid Forms

6.3 The Purchaser is not responsible for the completeness of

6.4 The Bidder is expected to examine all instructions,

7. Clarification of 7.1 A prospective Bidder requiring any clarification of the

7.2 If a pre-bid meeting is to be conducted, it will be held at

7.3 Should the Purchaser deem it necessary to amend the

8.2 Any amendment issued shall (a) become a part of the

8.3 To give prospective Bidders reasonable time in which to

(c) written confirmation authorizing the signatory of

13.2 A Bidder shall submit the Price Schedules for Goods,

15.3 The price to be quoted in the Bid Submission Sheet shall

be the total price of the Bid, excluding any discounts

15.4 The Bidder shall quote any unconditional discounts and

15.6 Prices shall be quoted as specified in each Price

(d) For Related Services, other than inland

15.7 Prices quoted by the Bidder shall be fixed during a

15.8 If so indicated in the BDS Clause 1.1, Bids shall be

15.9 GCC Clause 14of the Contract Forms (Section 5) sets

17. Documents 17.1 To establish their eligibility in accordance with ITB

Related Services included in Section 4: Bid Forms.

19.2 The documentary evidence may be in the form of

19.3 A Bidder shall also furnish a list giving full particulars,

19.4 Standards for workmanship, process, material, and

20. Documents 20.1 The documentary evidence of the Bidder’s

shorter period shall be rejected by the Purchaser as non-

21.2 In exceptional circumstances, prior to the expiration of

22.2 Any Bid not accompanied by a substantially responsive

(a) if a Bidder withdraws its Bid during the period of

23.2 In addition, the Bidder shall prepare copies of the Bid

23.3 The Bid shall contain no alterations or additions, except

23.4 The Bidder shall furnish information as described in the

24.2 The inner and outer envelopes containing Bids shall:

25.2 The Purchaser may, at its discretion, extend the deadline

27.2 Bids requested to be withdrawn in accordance with ITB

27.3 No bid may be withdrawn, substituted, or modified in

E. Opening and Evaluation of Bids

28.2 Firstly, e-mail files or envelopes marked