Lease

Oracle Property Manager Lease
Conversion
An Oracle White Paper
May 2005
Oracle Property Manager Lease Conversion
Introduction ....................................................................................................... 4
Overview............................................................................................................. 4
Lease Components............................................................................................ 4
Lease Details.................................................................................................. 4
Lease Contacts............................................................................................... 6
Lease Locations............................................................................................. 7
Lease Insurance............................................................................................. 8
Lease Rights................................................................................................... 8
Lease Obligations.......................................................................................... 9
Lease Options.............................................................................................. 10
Lease Terms................................................................................................. 11
Lease Notes ................................................................................................. 12
Lease Milestones ......................................................................................... 13
Conversion Process......................................................................................... 14
Overview...................................................................................................... 14
Conversion Effort....................................................................................... 14
Converting Historical Data................................................................... 15
Tenancy History ..................................................................................... 15
Conversion Sequence ................................................................................. 15
Load Lease Details ................................................................................. 16
Load Lease Tenancy Information........................................................ 18
Load Lease Contacts.............................................................................. 20
Load Lease Insurance Details, Rights, Obligations and Options ... 20
Load Lease Notes................................................................................... 23
Load Lease Terms .................................................................................. 23
Load Lease Milestones .......................................................................... 32
Finalize Leases ........................................................................................ 32
Load Amendments and Edits............................................................... 33
Amending a Lease with a Normalized Term ..................................... 35
Editing a Lease with a Normalized Term........................................... 42
Approve Schedules................................................................................. 46
Reconciliation ......................................................................................... 46
Clean Up Schedules and Items............................................................. 47
Transfer Normalized Distributions ..................................................... 47
Reconciliation with the General Ledger ............................................. 47
Technical Considerations ............................................................................... 49
Setups............................................................................................................ 49
Page 2
Applications ............................................................................................ 49
Target Tables ............................................................................................... 51
Load Leases and Lease Details............................................................. 51
Load Contacts......................................................................................... 52
Load Tenancies....................................................................................... 53
Load Insurance Details.......................................................................... 54
Load Lease Obligations......................................................................... 55
Load Lease Rights .................................................................................. 56
Load Lease Options............................................................................... 57
Load Terms ............................................................................................. 58
Load Notes.............................................................................................. 59
Load Milestones ..................................................................................... 60
Conclusion........................................................................................................ 61
Page 3
INTRODUCTION
Oracle Property Manager is a part of Oracles E-Business suite and the cornerstone
of Oracles Real Estate Management solution, providing the ability to support lease
execution from both the landlord and tenant perspective. This paper addresses the
considerations and provides an outline of the steps required to convert lease data
from a legacy system into the Oracle Property Manager schema.
OVERVIEW
This whitepaper is divided into three sections:
Lease Components
Conversion Process
Technical Considerations
This whitepaper specifically addresses functionality associated with Property

Manager Patchset K. The conversions of Index Rent Agreements and Variable
Rent Agreements will be covered separately in a future whitepaper.
LEASE COMPONENTS
This section discusses the various components of a lease and definitions of data
elements used by Oracle Property Manager to capture the critical elements of a
lease document and other related documents.
Lease Details
Lease details capture key lease elements pertaining to the lease document. These
include the lease name, type, class, lease status, approval status, lease dates,
proration rules, currency, the individual abstracting the lease, the user responsible
for maintaining the lease and account distribution defaults for billing or payment
terms.
Page 4
Name
The lease name uniquely identifies the lease that is the subject of the abstraction
process.
Type
The lease type describes how the rental amount is calculated, though it does not
affect the calculation process. Property Manager comes seeded with several
commonly used industry values; other values may be added as required.
Class
The class of lease refers to the type of relationship between the parties to the lease
depending on which party is abstracting the lease document. If the lease document
is abstracted from the perspective of a tenant, then the class is Direct, while if the
document is from the perspective of a landlord, the class is Third Party.
Where permitted by the terms of the lease, a tenant may sub lease all or part of the
leased premises to another party. This is referred to as a Sub Lease and when
selecting this class of lease, the lease must reference the parent lease agreement.
Lease Status
Lease status determines the current relationship between the lessor and lessee. A
lease may be Active, Terminated, Signed, Ordered, in a Month to Month or
Holdover arrangement. Property Manager comes seeded with several lease status
values; other values may be added as required, though seeded values should not be
disabled.
Approval Status
Approval status determines what actions and changes you may make to the lease. A
lease in Draft approval status allows you to add, modify or delete information
without a change history record being created; however, in this status you are
unable to approve and export terms for either billing or payment.
A lease with a status of Final requires that all changes to the lease must be done
via the Edit or Amend windows. This effectively puts the lease under change
control, with each change generating a history record.
Execution Date
The execution date typically is the date that the parties signed the lease document.
If a lease amendment is required this is the date the ancillary document is signed.
Commencement Date
The commencement date is typically the date that possession of the premises is
acquired by the tenant. If a lease amendment has been executed, then the
commencement date is the effective start date of the change.
Page 5
Termination Date
The termination date is typically the date on which the tenant ceases to have a claim
over the premises.
Proration Rule
The proration rule determines how to allocate a billing or payment term when the
frequency of the term is greater than the period for which the billing or payment
item is being created. Property Manager allows for three different proration rules:
Days in the month
Days in a 365 day calendar
Days in a 360 day calendar
Term Template
Term templates contain common term information and can be used to avoid
entering identical information for multiple payment and billing terms.
Invoice Grouping
Invoice Grouping controls the grouping of payment items within or across leases.
Grouping is controlled at several levels with the system option level being the
highest. The rules and options are considered in the following order:
1.
Payment item grouping rule.
2.
Payment term grouping rule.
3.
Lease grouping rule.
4.
System option grouping rule.
Lease Contacts
Lease contacts are used to record the name, role and site of individuals and entities
which have relationships and business interactions as part of the administration of
the lease. These contacts are maintained separately within the Property Manager
schema, and are not synchronized with either Parties in Oracles Trading
Community Architecture (TCA) or Suppliers in Oracle Purchasing.
Role
The role defines the relationship between the landlord or tenant, and the service
provider. Property Manager comes seeded with several commonly used industry
values; other values may be added as required.
Company Name
The Company Name is the name of the service provider with which the
relationship exists.
Page 6
Site
Site identifies the site or location that is associated with the service provider.
Lease Locations
Lease locations associate a physical location or locations with the lease and capture
details about the occupancy dates. Additionally, in the case of Third Party and Subleases, it records customer information related to occupancy expenses.
Type
Type refers to the type of space associated with the lease. This is defined by the
property hierarchy, and though the descriptions may be altered, the underlying
hierarchy remains.
Code
The location code is a concatenation of the location aliases for each level of the
property hierarchy. This code is generated by the system.
Primary
This checkbox indicates the primary, or main, location associated with the lease.
Only one location can be marked as primary.
Usage
Usage refers to the intended usage of the land or building space.

Share
The percentage of the location covered by the lease. If leasing part of a building,
then the share may be a percentage of the rental space. If leasing an office for a
retail space, then the share may be 100 percent of the space.
Estimated Occupancy Date
The date the location is expected to be occupied.

Actual Occupancy Date
The date the location is occupied. You can associate more than one lease with a
single location provided the occupancy dates do not overlap. To allow overlapping
lease dates for a single location, the Multi-Lease Tenancy system option must be set
to 'Yes'.
Expiration Date
The date the occupancy ends on the location. The Location Expiration Date would
typically be the same as the Lease Expiration Date and by default is set to equal this
value. However, this value may be edited to have the occupancy end before or after
the lease ends.
Page 7
Recovery Type
This field is enabled for billing leases and is a user defined lookup attribute that
describes the usability of a particular space by a certain type of tenant, such as
Major, Specialty, Freestanding, Kiosk, or Food Court.
Recovery Space Standard
This field is enabled for billing leases and is the classification, usually Internal or
External, of a location used in the recovery process.
Financial Obligation End Date
This field is enabled for billing leases and is the date that the obligation to provide
the service ends.
Lease Insurance
Lease insurance records the details of any insurance requirements that may be
attached to the lease. The details of insurance policies may be specified, including
the type, amount and effective dates of the coverage.
Type
Type refers to the type of insurance policy. Property Manager comes seeded with
several commonly used industry values; other values may be added as required.
Insurer Name
This refers to the name of the entity providing the insurance coverage.
Policy Number
This refers to the name or number of the insurance policy.

Active
A checkbox defines whether the insurance policy is currently active. This is

manually maintained by the lease administrator.
Dates
Date refers to the start and expiration dates of the insurance policy.
Coverage
These fields detail the required (minimum) and purchased (held) amounts if
insurance coverage required by the lease.
Lease Rights
Rights are entitlements granted by the landlord to the tenant as a part of the lease.
Examples of lease rights include:
The right to assign or sublease all or a portion of the premises
Page 8
The right of first refusal to adjoining space
Building naming rights
Type
The Type defines the type of right being granted. Property Manager comes seeded
with several commonly used industry values; you may add other values as desired
Grant Code
The Grant Code is used in conjunction with the type to highlight whether the
right is allowed, silent, or referred to consul. Property Manager comes seeded with
several values; other values may be added as required.
Reference
The Reference field allows the user to refer to the clause or paragraph of the lease
that grants or limits the right.
Lease Obligations
A Lease Obligation outlines which of the parties to the lease is responsible for
performance and payment of specific services, taxes, costs, etc.
Type
This refers to the category of the responsibility. Property Manager comes seeded
with several commonly used industry values; other values may be added as
required.
Service Provider Name
This refers to the name of the individual or organization providing the service.
Responsibility Type
This refers to the specific obligation and indicates the person or organization
responsible for a particular task, for example, landlord, tenant, or contractor.
Responsibility Common Area
This field indicates who is responsible for any common area(s) in a rented space.
Responsibility Financial
This identifies the party responsible for the payment of an obligation, where there
is a financial cost associated with the provision of the obligation.
Responsibility Percent
If a cost is associated with any obligation, this refers to the percentage that the
responsible party is obligated to pay. If there is more than one responsible party, a
Page 9
record should be created for each party for the obligation and assigned the
appropriate percentage.
Maintenance
If the obligation is for maintenance, enter the party responsible for supervising or
coordinating work with the service provider. For example, if the landlord schedules
and oversees the work of the landscape service provider, enter Landlord.
Start Date
This date refers to when the obligation to provide the service begins.
End Date
This date refers to when that the obligation to provide the service ends.
Reference
This field allows reference to the paragraph or section in the original lease that
describes the obligation.
Lease Options
Lease options are clauses in the lease that give the tenant preferential rights to the
tenant.
Type
Type identifies and categorizes the type of option. Some examples of option types
are renewal, purchase, and early termination. Property Manager comes seeded with
several values; other values may be added as required.
Start Date
This date refers to the first date the option can be exercised.
End Date
This date refers to the last date the option can be exercised.
Reference
This field provides a reference to the paragraph in the original lease that describes
the option.
Status
This field refers to the current status of the option, for example, Exercised, Not
Exercised, or No Action.
Page 10
Notice Given
If the option requires notice from one party to the other, this check box should be
checked to indicate that the notice was given.
Exercise Begins/Ends
These dates refer to the first and last dates that notifications can be sent to the
landlord indicating that the tenant wishes to exercise the option.
Action Taken Date
This date refers to when an action to exercise or decline was taken on an option.
Option Size
If the option relates to the increase or decrease in the size of the area leased; the
Option Size references the amount of area covered by the option.
Unit of Measure
If the option relates to an increase or decrease in the area lease and an option size is
provided, then the size can be quantified with a unit of measure (UOM).
Cost
Cost refers monetary value associated with an option, should it be exercised.

Examples are $2 per square foot, or 95% of fair market value.
Currency
Refers to the currency in which the option cost is denominated.

Area Change
Similar to the option size, this refers to the area that will be increased or decreased
related to an Expansion, Contraction, or Must Take option right.
Lease Terms
Lease terms capture billing or payment information related to the lease, along with
accounting information. Depending on the lease class, either a billing or payment
term is entered; billing and payment terms cannot be combined on the same lease.
Location
The location field optionally associates a building/land, floor/parcel or

office/section with a term. Only locations that have been previously associated
with the lease, in Lease Locations, may be used.
Page 11
Purpose Code
This field typically identifies the reason for a payment or billing. Property Manager
comes seeded with several commonly used industry values; other values may be
added as required.
Purpose Type
Purpose types classify the origin of the term. For example, for the Rent payment
purpose, the payment type may be base, direct, escalation, prepayment, percentage
rent or abatement.
Frequency
The frequency determines the interval of a recurring term. Property Manager allows
for the following frequencies:
One Time
Monthly
Quarterly
Semi Annual
Annual
Normalize
Normalization is a process where a term is spread out over the entire life of the
lease to facilitate income and expense recognition requirements of FASB13.
Start and End Dates
This refers to the dates between which a term is effective. If the term is not
normalized then the start and end date may be outside the boundaries of the lease
date, if required.
Schedule Day
The Schedule Day determines the day that schedules are created.
Payment Term
Payment terms are used to determine the due date of an invoice or payment. The
Schedule Day and the payment terms combine to create a due date for each
transaction.
Lease Notes
Lease notes provide a capability to store and associate supplementary data with a
lease.
Page 12
Type
This field refers to the Type of note. Oracle Property Manager provides the values
Abstract and Amendment. Other values may be added as required.
Date
This field refers to the date that the note was added to the lease.
User
This field references the user who added the note. The user must have been
defined previously.
Description
The Description field is a free form text field. The field is limited to 240
characters.
Lease Milestones
Lease milestones provides a capability to schedule reminders and notifications for

lease events, such as option exercise dates, insurance policy renewal dates, lease
commencement and termination dates and term dates.
Action Due Date
This field refers to the date by which the required action for the associated
milestone must be completed.
Lead Days
This field estimates the number of days it will take to complete the required action
for the milestone.
Responsible User
The field indicates the user responsible for taking action on the milestone.
Type
This field refers to the type of Milestone. Oracle Property Manager provides
several seeded values; other values may be added as required.
Frequency
This field refers to the number of days between milestone notifications. Entering
1 in this field generates a notification every day. Entering 2 generates a
notification every other day.
Page 13
Begin Date
The field refers to the first date that a notification regarding this milestone will be
generated. Oracle Property Manager calculates the Notification Date as the Action
Due Date minus the number of Lead Days. This field is display only.
CONVERSION PROCESS
This section outlines the steps required to convert legacy data into the Oracle
Property Manager schema.
Overview
An abstracted lease in Property Manager is intended to accurately reflect the

executed lease agreement and any associated ancillary documents. It should detail
key lease dates, tenancy assignments, rights, restrictions, obligations, options,
insurance requirements and financial obligations. Unlike a conversion of general
ledger data where a current balance conversion may suffice, Property Manager
requires that certain contractual data and lease events be converted if the
information presented to the user is to be accurate.
Converting leases presents a series of questions:
Should the conversion be programmatically executed or manually entered?
How much history should be converted?
How should historical records be treated?
In what sequence should data be converted?
What are the prerequisites which must be completed before attempting a data
conversion?
Conversion Effort
The number of leases to be converted is a good measure for determining whether a

programmatic or manual conversion should be effected.
To manually abstract a lease with amendments may require 1 to 1.5 hours per lease.
In some cases this process can be enhanced with the use of a DataLoad script.
Oracle Property Manager currently provides no open interface or import validation
programs to support a programmatic conversion, though it does provide packages
to support the insertion and updating of records. Consequently interface tables,
loader scripts and validation procedures need to be developed. Such an effort
needs to be balanced with the size of the conversion effort, the complexity of the
lease agreements and the reusability of the code for future use by the organization.
Page 14
Converting Historical Data
A common issue that arises when converting any financial system relates to how
much historical data needs to be converted. It is rare that no historical data is
converted; just as rare is the need to convert all historical data. Regardless of the
historical data conversion policy, Property Manager presents some unique
challenges when converting data, which require careful consideration and
appreciation to achieve the right balance between accurate data and conversion
efficiency.
Tenancy History
The life of a lease can vary from a day to many years and during that time it may be
the subject of numerous changes. The inclusion of Date Effectivity on locations
adds a new dimension to a lease when dealing with physical changes to a location.
When dealing with some types of leases, the premises occupied by a tenant may
physically alter due to improvements by the landlord, while the location name (or
code) remains unchanged. Changing the area of a location has an effect on the
calculated annual amount/area value. It is important to match the correct location
code with each term to ensure an accurate calculation.
For example consider a Third Party lease for a retail store in a local shopping mall.
The lease has the following characteristics:
A third party lease is executed on 1 November, 2000 with a commencement

date of 1 January, 2001 and a termination date of 31 December, 2011.
A normalized term of $2,000 per month to start on 1 March, 2001 and end on
31 December, 2004.
Rent is scheduled to be billed on the first day of each year.
The location has a rentable space of 900 square feet.
The annual rent per square foot is calculated as ($2000 x 12) 900 = $26.67 / sft.
The tenant has the opportunity to expand its space in March 2005, and accordingly
the lease is amended to include an additional 300 square feet for another $200 per
month. The name of the location does not change.
The annual rent per square foot is now calculated as ($2200 x 12) 1200 = $22.00
Conversion Sequence
Regardless of whether a manual or programmatic conversion method is chosen, a

staged approach is required to convert lease data:
1
Load Lease Details;
Load Lease Tenancy Information;
Load Contacts, Options, Rights, Insurance, and Notes;
Load Terms;
Page 15
Load Milestone information;
Finalize Lease;
Load Amendments;
Mass Approve Schedules;
Clean up Schedule and Items;
10 Transfer normalized distributions to General Ledger; and

11 Reconcile the Conversion activity.
The conversion process can be illustrated as follows:
Load Interface
Tables from
Legacy
Validate and
Import Lease
Details
Validate and
Import Lease
Tenancies
Finalize Lease
Load
Amendments
Generate
Schedules and
Items
Generate
Schedules and
Items
Reconcile
Reconcile
Approve
Schedules and
Items
Flag Items already

Exported
Transfer
Normalized
Distributions to the
General Ledger
Validate and
Import Lease
Contacts, Options,
Rights, Insurance
& Notes
Validate and
Import Lease
Terms
Reconcile
Validate and
Import Lease
Milestones
Load Lease Details
Load key lease data that identifies the lease, statuses, key dates and default
information.
The lease name should assist in the identification of the lease and follow a
consistent naming standard as defined by the business standards. The lease number
may be automatically generated or manually defined, dependent on the set ups.
While duplication of the lease name is allowed, the lease number must be a unique
value.
The sequence in which leases should be loaded follows their class. Because subleases require a master lease, the following order should be adopted:
1
Direct leases;
Page 16
Third Party leases;
Sub-leases.
Leases should be initially loaded with an approval status of Draft. This allows for
the review of converted data, and the ability to change data prior to placing the
lease under change control procedures.
A default primary location may be optionally supplied. This location will default to
the tenancy information, when adding tenancy data.
If the lease class is either Third Party or Sub-lease, then a default customer can be
optionally supplied. This will default to the tenancy information and billing
information.
The following rules apply to the key lease dates:
1.
The termination date needs to be later than the commencement date of the
lease.
2.
The execution date is not constrained.
3.
The term days are calculated from the commencement and termination dates
and cannot be updated.
Account defaults can be optionally supplied. The account defaults are dynamic
depending on the lease class. The accounting distributions default to
billing/payment terms where distributions have not been provided on the lease
term or by a term template.
The following order is used to determine what distribution defaults to each account
class on a lease term.
1.
The accounting distribution on the lease term.
2.
The accounting distribution on the lease term template.
3.
The accounting distribution on the lease.
The User Responsible is the individual in the organization responsible for the
maintenance of the abstracted lease. The user needs to be defined as a user within
the Oracle E-Business suite.
Optionally a Term Template may be supplied. The Term Template will default to
new billing/payment terms.
The proration rule must be defined based on one of the following rules:
Days in the month;
Days in a 365 day calendar; or
Days in a 360 day calendar.
Page 17
The functional currency defaults to the Set of Books functional currency. It

cannot be updated. If terms are stated in currency other than the functional
currency, the currency code will be defined in the billing and payment information.
Additional descriptive flexfield data may be entered to capture other unique
organizational attributes.
Load Lease Tenancy Information
The information required for tenancy details differs based on the lease class. While
some information is common, data elements related to customer and common area
maintenance are valid only with Third Party and Sub-leases.
Each lease must reference at least one location. This location must be continuously
active during the commencement and termination dates of the lease.
A prerequisite to creating tenancy information is that properties and locations have
been defined.
When assigning a location to a lease, there are several rules that apply:
A lease can only have one primary location for a given period of time.
In general a location can only be assigned to one lease at a time. That is; a
location may not have overlapping effective dates on multiple leases. The
effective dates are defined as the estimated and actual occupancy dates and the
expiration date fields.
When assigning a location such as a building or a floor to a tenant, the sub

locations cannot be assigned to another tenant.
In the case of a sub-lease, a location may also have been assigned to a direct
lease; however, the effective dates must lie within the effective dates of the
master lease. The location must be the same location or lower in the location
hierarchy.
If the System Option Allow Multiple Tenancy is set to Yes, then the same
location may be used on multiple leases without restriction. This option is
useful in cases where a common location, such as a storage room, is assigned
to multiple tenants. If the user enters a lease manually, a warning message will
display that the location effective dates overlap another tenancy record.
The Type refers to the type of space assigned to the tenant; this space may be
defined as a Building, Floor, or Office, or alternatively Land, Section or a Parcel.
Property, office park or suite may not be assigned.
The Location Code is a unique concatenation of the aliases for each level of the
property hierarchy. Defining a property and the subsequent locations generates a
set of permitted location codes. Location codes cannot be dynamically created
through lease entry or conversion.
Page 18
Usage refers to the planned or stated use of the location by the tenant and is a
mandatory field. Usage types must be predefined as lookup values.
The Share refers to the percentage of the location covered and is required. Where
the system option Allow Multiple Tenancy is set to No and the percentage share
of a location is less than 100 percent, the same location cannot be used on another
lease with a balance of the percentage. If the system option is set to Yes, then the
sum of the share each tenant occupies should not exceed 100 percent, though loads
of greater than 100 percent are allowable.
The Estimated Occupancy Date and Expiration Date provide a timeframe for
the tenancy. In addition the Actual Occupancy Date provides a record of the
actual date of occupation of the premises or space. The following attributes apply
to these dates:
All dates must lie within the active dates for the location. Where a lease refers
to a location which has been altered but retains the same location code, the
tenancy records must reflect multiple records detailing the effective dates of
each occupancy.
The estimated occupancy date and the expiration date are mandatory.
The estimated occupancy date may be prior to the lease commencement date.
The expiration date may be after the lease termination date.
The actual occupancy date may be prior to the estimated occupancy date.
If the lease class is either Third Party or sub-lease then information related to
tenant recoveries is required on the primary location and optionally on additional
locations. The information required for tenant recoveries includes:
Tenant. Customer Name and Bill to Site location.
Financial Obligation End Date. The date the tenant ceases to be liable for any
further expenses. This date may differ from the expiration date and lease
termination date. For example in the case of a tenant who defaults on a lease,
the location may be vacant, and available for allocation, however until a new
tenancy on the location is established, the defaulting tenant is still responsible
for common area charges.
Recovery Type. Recovery types must be predefined as lookup values.
Space Standard. Space standards must be predefined as lookup values.
Area measurement attributes have been introduced and give increased flexibility in
cost-per-area measures in lease terms, allowing comparison between areas as
measured and as per stated in the lease document.
Lease Assignable Area. The assignable area as stated in the lease.
Lease Load Factor. The load factor as stated in the lease.
Lease Rentable Area. The rentable area as stated in the lease.
Page 19
Lease Usable Area. The usable area as stated in the lease.
The last four elements need to be numeric values, in order to allow the calculation
of any variances between the location dimensions and lease assertions.
Load Lease Contacts
Lease contacts are optional data elements that associate the lease with entities that
provide services to the lease. New contacts or combinations of lease role and
contact cannot be created from within the lease. In order to associate a contact with
a lease, it must have been defined as a contact, with the assigned lease role and
location.
When associating a contact with a lease the following fields are mandatory:
Role;
Company Name; and
Site
Identify current contacts by the use of the active field.

Load Lease Insurance Details, Rights, Obligations and Options
Insurance Details
Insurance details are optional data elements and a lease may reference multiple
policies. When referencing an insurance policy the following fields are mandatory:
Type;
Policy Number;
Start Date; and
Expiration Date.
The following attributes apply when converting insurance details:
Policy types must be predefined as lookup values.
The insurer name is not validated against contacts, customers or suppliers.
The policy number is not required to be unique.
The expiration date must be later than the start date of the policy.
There are no restrictions on required coverage and purchased coverage.
Amounts are based on the functional currency.
Page 20

Lease Rights
Lease rights are optional data elements and a lease may reference multiple rights.
When referencing a right in a lease the following fields are mandatory:
Type, and
Grant Code.
Both of the above fields require values to be defined as lookups.

Additionally, each right is required to be uniquely sequentially numbered within
each lease.
The reference field and comment field are free form text fields.
Lease Obligations
Lease obligations are optional data elements that detail which parties are
responsible for the provision or performance of services during the term of the
lease. When referencing an obligation to a lease, the following fields are mandatory:
Type;
Start Date; and
End Date.
The type field requires values to be defined as a lookup. There is no validation of

the start and end dates against either lease dates or location effective dates. The end
date must, however, be later than the commencement date. Identify current
obligations by the use of the active field.
Additionally each obligation is required to be uniquely sequentially numbered
within each lease.
Optionally the following information may be provided:
Service Provider Name. The service provider needs to have been defined as a
contact, but need not have been previously referenced as a contact in Lease
Contacts.
Responsibility Type. This value needs to have been previously defined as a

lookup.
Financial Responsibility Type. This value needs to have been previously

defined as a lookup.
Percentage. Must be a number in the range 0 to 100.
Page 21
Common Area. No validation.
Reference. No validation.
Comments. No validation.

Lease Options
Lease options are optional data elements that detail what legal rights each of the
parties associated with the lease, have with respect to each other, and the timeframe
in which the option is available. When referencing an option to a lease, the
following fields are mandatory:
Type; and
Status.
Both fields require values to be previously defined as a lookups.

Additionally, each obligation is required to be uniquely sequentially numbered
within each lease.
Optionally, the following information may also be provided:
Start Date.
End Date. The end date must be later than the start date. If a start and end
date are provided, then a term is calculated, being the number of days between
the start and end date.
Reference. No validation.
Notice given. Checkbox validation.
Exercise Begin Date. No validation
Exercise End Date. This date must be later than Exercise Begin Date.
Action Taken Date. No validation.
Option Size. This value must be a number.
UOM. This code must be defined as a lookup. The only valid options are
square feet (SFT), square yards (SYD), and square meters (SMT)
Cost. No validation.
Currency. This should generally be the same as lease currency.
Area Change. This must be a number
Comments. No validation.

Page 22
Load Lease Notes
Lease Notes are optional data elements that allow detailed comments to be
attached to a lease. When referencing a note to a lease, the following fields are
mandatory:
Type;
Date; and
User.
The Type field requires values to be defined as a lookup. The user should be the
same user, referred to while abstracting, editing or amending the lease.
There is no validation on the description field; however, the length of the note is
limited to 2000 characters.
Load Lease Terms
Lease terms identify the location, frequency, amount, landlord (or tenant), purpose,
type, and effective dates of payments (or billings). It also includes information on
how to handle invoices and the accounting associated with the payment (or billing)
term.
Billing and payment terms are defined with start and end dates, which may differ
from the commencement date and termination date of the lease. When converting
terms, the business is faced with thee options:
1
Load current terms with a start date of each term equal to or greater than the
month in which the conversion occurs.
Load all terms with accurate start and end dates for each term.
Load only current terms with a start date that allows the greatest flexibility
between efficiency and providing the necessary history.
Current Terms
It may be more convenient to load only terms with the conversion date as the start
date for each term; however, by adopting this approach the billing and payment
item history information will not be complete. This may create problems for
determining base rents for Index Rent and Variable Rent. Normalization may also
be affected if any normalized terms do not span the entire life, or the amended life
of the lease.
Historical Terms
Loading all terms from their start date provides the most flexibility and
completeness of data; however, it can be an extremely complex and arduous task.
Page 23
Blended Terms
A blended approach to loading terms, where only those terms that are required for
normalization or base rent calculations are loaded with the original start dates, and
other terms are loaded as of the conversion date.
While this approach reduces the scope of having to load all terms, it does have
some drawbacks, including:
Data history inconsistency on the lease, the user can see some lease term
history, while they may need to refer to the legacy system for other
information.
Missing history may make any retroactive adjustments more difficult.
Proration
Another anomaly that may arise is a discrepancy between items and invoices, due to
proration differences between Oracle Property Manager and the legacy system. If
this is a material matter, then consider loading these partial period items as
individual terms.
Term Templates
The creation of lease terms can be aided by the use of a term template which
defaults information to the term. Term templates need to be defined prior to their
use in a lease conversion. Information defaulted by the template may be overridden
by supplying an alternative value.
When defining a term template, the only required value is a template name. All
other information is optional and may be tailored to suit the users needs. Separate
templates exist for Billing and Payment terms.
Multiple term templates can be used on a lease; however, they cannot be combined
on an individual term on a lease.
Location
It is optional to supply a location to associate the term with a space.

Purpose and Type Codes
The purpose and type codes indicate what a term is for, and where the term
originates from. Both a purpose and type are required for each term.
A user may define as lookups any number of purpose codes to indicate the nature
of the payment. The type codes are restricted and classify terms as to their function.
It is necessary to correctly classify the term as to the type, as this has consequences
as to the functionality and behavior of term.
There is no restriction on the combination of purpose and type codes, though there
are logical combinations.
Page 24
Start and End Dates
Terms are defined by the start and end dates, which may lie outside the boundaries
of the lease commencement and termination dates, if they are not to be normalized.
When entering terms through the forms, a warning message is displayed if the start
or end date is outside the boundaries of the key lease date.
A term may not have an open ended (or null) end date.
Terms may exist outside of the key lease dates for any number of reasons. Some of
the reasons include:
1
Deposits required prior to occupancy;
Prepayments; or
Percentage rent payments after expiration of the lease.
Frequency
The frequency controls the interval at which an invoice is generated. Only the
following values are allowed:
One Time;
Monthly;
Quarterly;
Semi-Annual; or
Annual.
Where a frequency of One Time is selected, the start and end dates must be the
same.
Schedule Day and Schedule Date
Schedule Day determines the Schedule Date on which schedules are created. Valid
values are a number between 1 and 28. The number entered is the day of the
month on which schedules will be created. The schedule date defaults to the
transaction date in Oracle Receivables and the invoice date in Oracle Payables,
which subsequently derives the aging dates of the transaction.
When a lease is finalized and the Schedules and Items concurrent program is
submitted, an item is created for each frequency interval for each term. For
example, a term which is effective for one year and has a monthly frequency will
produce twelve items. Items are grouped together for approval based on their
schedule date. Multiple terms can share the same schedule day and hence the same
schedule date.
Page 25
Term
Items
Schedules
For example a lease is abstracted with a term which requires payment on the first
day of each month with the following terms:
A direct lease is executed on 1 November, 2003 with a commencement date of

1 March, 2004 and a termination date of 28 February, 2005.
A term of $4,000 per month for rent to start on 1 March, 2004 and end on 28
February, 2005. The Schedule Day is 1.
A term of $300 per month for common area maintenance (CAM) to start on 1
March, 2004 and end on 28 February, 2005. The Schedule Day is 1.
A term of $500 semi-annually for taxes to start on 1 August, 2004 and end on
28 February, 2005. The Schedule Day is 1.
The following table illustrates the schedules and items created from the prepayment
term and the normalized term:
Sched
Day
Schedule
Date
1
1
1
1
1
1
1
1
1
1
1
1
1-Mar-04
1-Apr-04
1-May-04
1-Jun-04
1-Jul-04
1-Aug-04
1-Sep-04
1-Oct-04
1-Nov-04
1-Dec-04
1-Jan-05
1-Feb-05
Rent
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
48,000.00
CAM
300.00
300.00
300.00
300.00
300.00
300.00
300.00
300.00
300.00
300.00
300.00
300.00
3,600.00
Taxes
500.00
500.00
1,000.00
Schedule
Amount
4,300.00
4,300.00
4,300.00
4,300.00
4,300.00
4,800.00
4,300.00
4,300.00
4,300.00
4,300.00
4,300.00
4,800.00
52,600.00
If a schedule date has been approved, then additional terms cannot be added to the
schedule date. Where a term needs to be retroactively added, then a different
schedule day will be required.
For example, if a schedule for 1 May, 2005 has been approved and a new term is
added to the lease which also requires scheduling on Day 1, then the earliest start
date for the term will be 1 June, 2005. The May term should be added as a One
Page 26
Time payment with a schedule day of 2, and therefore a schedule date of 2 May,
2005.
Prepaid Terms
Property Manager provides the flexibility to prepay an individual item of a billing or

payment term. This functionality is provided by the creation of an additional term
with similar characteristics to the parent term; however, the prepayment term has a
Purpose Type of Prepayment, a frequency of One Time and the same start and
end date.
When a prepayment term is entered, a future period identified by a target date is
associated with the term, and an offsetting item is created in this future period. The
effect of this offsetting term is to negate the financial consequences of adding the
additional term at the start of the lease.
For example, a lease is abstracted with a term which requires that a full months
rent be paid in advance on the commencement date of the lease.
This example uses the following terms:
A direct lease is executed on 1 November, 2003 with a commencement date of

16 March, 2004 and a termination date of 15 March, 2005.
A normalized term of $4,000 per month to start on 16 March, 2004 and end on
15 March, 2005.
A full monthly payment of $4,000 is required on 16 March, 2004.
Rent is scheduled to be paid on first day of each month.
Terms are prorated based on the number of days in the month.
Since a full monthly payment of $4,000 is required and only $2,064.54 of the
payment relates to March 2004, the balance of the payment can be applied against
the final payment in March 2005. The target date for the payment would be 1
March, 2005.
The following table illustrates the schedules and items created from the prepayment
term and the normalized term:
Schedule
Date
Prepayment
Term
Normalized
Term
Scheduled
Term
Amounts
1-Mar-04
1-Apr-04
1-May-04
1-Jun-04
1-Jul-04
1-Aug-04
1,935.48
2,064.52
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
Page 27
Schedule
Date
Prepayment
Term
Normalized
Term
Scheduled
Term
Amounts
(1,935.48)
0.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
1,935.48
48,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
4,000.00
0.00
48,000.00
1-Sep-04
1-Oct-04
1-Nov-04
1-Dec-04
1-Jan-05
1-Feb-05
1-Mar-05
Note: The March 2004 payment is prorated based on days in the month.
$2,064.52 = ($4,000 x (16 31))
Normalization
The normalization or straight lining of lease terms is required to comply with the
requirements of Statement of Financial Accounting Standards No. 13, Accounting
for Leases. Besides the United States, other international professional accounting
bodies, such as the International Accounting Standards Committee and the
Institute of Chartered Accountants of Australia, have similar provisions within their
standards to comply with this requirement.
Normalization is the process of evenly spreading the sum of the known lease terms
over the entire life of the lease. While the provisions of the standard apply to lessor
and lessee, not all legal entities are obligated to comply with the standard, nor are all
lease terms required to be normalized. The requirements to comply with these
standards, and the terms to be included, are determined by the accounting and legal
requirements for each entity
Oracle Property Manager will normalize terms that:
Have been marked for normalization;
Are actual amounts, and not an estimate; and
Are within the lease commencement and termination dates.
A lease with a lease status of Holdover or Month to Month cannot have

normalized terms during the holdover or carrying period.
Example of Rent Normalization
This example uses the following terms:

Page 28
A normalized term of $12,000 per annum to start on 1 January, 2001 and end
on 31 December, 2004.
Rent abatement of $3000 for the first year, which is also normalized.
Rent is scheduled to be billed on first day of each year.
The following table illustrates the summarized annual rent normalization

calculations. Note that in the table
Schedule
Date
(A)
01-Jan-2001
01-Jan-2002
01-Jan-2003
01-Jan-2004
Base Rent
(B)
Column B plus Column D minus Column C equals Column E. This represents

the cashflow of the terms.
Column F equals the sum of the total billed rent divided by 48 months and
annualized. This is the true Revenue amount that needs to be reported.
Column G equals column F minus column E.
Column H is a running total of Column G. This represents the value of the

Accrued Asset at the end of each year.
Abatement
(C)
Amendment
Rent
(D)
Billed Rent
(E)
Revenue
Account
Balance
(F)
Adjustment
(G)
Accrued
Asset
Balance
(H)
$12,000.00
$12,000.00
$12,000.00
$12,000.00
$3,000.00
$9,000.00
$12,000.00
$12,000.00
$12,000.00
$11,250.00
$11,250.00
$11,250.00
$11,250.00
$2,250.00
($750.00)
($750.00)
($750.00)
$2,250.00
$1,500.00
$750.00
$0.00
$48,000.00
$3,000.00
$45,000.00
$45,000.00
$0.00
$0.00
Amounts
Amounts are entered for the frequency interval defined. That is if the lease specifies
an annual payment of $48,000, paid monthly the frequency would be defined as
Monthly and the amount would be $4,000 ($48,000 12).
Where the payment terms contains a period which is less than a full interval, then
the amount is prorated based on the proration rule defined on the lease. This is
handled by the Schedule and Items concurrent program and does not require user
intervention.
A user may enter either an actual and/or an estimated amount. Estimated amounts
may be updated with an actual amount prior to authorization. Estimated amounts
cannot be normalized.
Where the user provides an actual amount, then an Annual Amount is calculated
based on the actual amount and the frequency. Even where a lease is not for a full
year, an annual amount will be extrapolated.
Page 29
Terms created with an actual amount will also calculate an Annual Rate divided by
the area calculation. The area used in this calculation depends upon the value in the
Area Type field. The Area Type field is defaulted from the System Options, but
may be altered for each term. In some cases the term is described as $X per square
foot.
Currency and Exchange Rates
A term may be entered in a currency other than the currency defined on the lease.
In order to use currencies other than the set of books currency, the currencies need
to be enabled and an conversion rate type defined in the System Options.
If the conversion rate type is User then a conversion rate must be defined when
creating the lease term.
When a term is approved, the accounted amount is calculated based on the
conversion rate and the conversion date.
Payment Terms
Payment Terms are limited to leases where the lease class is Direct. Consequently
only a supplier name and supplier site may be associated with the term.
When defining a payment term the following information is required:
Supplier Name; and
Supplier Site.
Optionally, a Payment Term may be provided. If information is not provided on

the term, then the information defaults from the Supplier Site information.
Where tax is required to be calculated on the invoice, either a Tax Code or Tax
Group may be optionally supplied. Both of these items are required to have been
defined in Oracle Payables. Tax may be calculated based on whether it is included
in, or added to the term amount. For suppliers that have the Calculation Level set
to 'Header' (tax is calculated based on header information) or 'None', the Tax
Inclusive check box is disabled.
Project information may be supplied if the term is not normalized. The Project
Number, Task, Expenditure Type and Expenditure Organization need to have
been previously defined in Oracle Projects. Where Project information is supplied,
there is no requirement to provide accounting distribution information because the
Project rules determine the accounting distributions.
Provide accounting distribution information for the following accounts:
Accounts Payable Liability;
Rent Expense; and
Liability Accrual, required where the term is normalized.
Page 30
Where a term is not normalized a distribution set may be used in lieu of providing
accounting information, however, the distribution set needs to have been
previously defined in Oracle Payables.
Billing Terms
Third Party and Sub-leases require Billing Terms to be defined. Billing and Payment
terms cannot be combined on a lease.
Receivable Terms determine the due date for invoices transferred to Accounts
Receivable. The term needs to have been previously defined in Oracle Receivables.
A Transaction Type is required for all billing terms and needs to have been
previously defined in Oracle Receivables. Property Manager only supports
transaction types with a creation sign of Any, to allow the creation of positive and
negative transactions. If the System Option Accounting Information is set to
None or Normalized and the term is not normalized then accounting distribution
information can be determined by AutoAccounting during the AutoInvoice
process.
The table below illustrates what accounting distributions need to be provided for
each receivable class, depending on the System Option Accounting Information.
All Terms
Receivable
Revenue
Accrued Asset
Normalized
Required
Required
Required
Not
Normalized
Required
Required
Not Required
Normalized Terms Only

Normalized
Required
Required
Required
Not
Normalized
Not Required
Not Required
Not Required
None
Normalized
Not Required
Not Required
Not Required
Not
Normalized
Not Required
Not Required
Not Required
Optionally a Purchase Order Number may be provided to associate a billing term

with a Purchase Order. This is a reference field with no validation.
Accounting and Invoice Rules can be optionally supplied if the term is not
normalized. The Oracle Receivables Revenue Recognition program is not a
substitute for normalization requirements of FASB13.
Optionally a Salesperson may be provided. The salesperson can be used to default
accounting segments during AutoInvoice, depending on the setting of the System
Option Accounting Information. This field is required if the Require Salesperson
check box is checked on the System Options window in Oracle Receivables.
Optionally a Payment Term and Payment Method may be provided. If this
information is not provided on the term, then the information defaults from the
Customer Bill-to Site information.
Page 31
Where required, a tax code should be provided, and whether the term already
includes tax in the amount should be indicated. Tax is calculated, and a tax line is
created on the invoice as part of the AutoInvoice process.
Accounting distribution information should be provided for the following
accounts:
Accounts Receivable;
Rent Revenue; and
Asset Accrual, required where the term is normalized.
Multiple revenue and asset accrual lines may be loaded, but the AutoInvoice
concurrent program and process will allow only one receivable account per invoice.
Load Lease Milestones
Lease milestones can be associated with lease details, insurance details, options and
lease terms. To reference a milestone to a lease event the lease event must first have
been committed or saved to the database. Where the conversion is
programmatically loaded, it will be necessary to refer each milestone back to a
legacy lease event reference.
A milestone can be created with the assistance of a previously defined milestone
template. Where a template has been used, subsequent fields may be updated to
reflect the specific requirements of the milestone.
The following fields are required when defining a milestone:
Type;
Responsible User; and
Action Due Date.
Optionally provide information for the following:
Lead Days;
Frequency; and
Begin Date.

Finalize Leases
The process of finalizing a lease results in the following:

1
The creation of schedules and items; during this process items are created from
terms and then aggregated into schedules.
The lease is placed under change control, and all subsequent changes must be
made through either amendments or edits.
Page 32
Prior to the finalization of any lease, a review of the accuracy of the abstraction or
conversion should be undertaken.
The finalization of each lease can be accomplished by one of two approaches:
1
Manually set the status to Final on each lease in the Lease form; or
Use a PL/SQL procedure to update the PN_LEASES_ALL table and submit

the LEASE_ID to the Schedules and Items concurrent program.
This process is required for each lease and depending on the number of leases,
terms and computing resources may take several hours to execute.
Should the Schedules and Items concurrent program fail, it may be re-submitted
manually with the following parameters:
Lease Number
Context:
ABS - Abstract
Called From:
Main
Load Amendments and Edits
An amendment and an edit to a lease both create a history record highlighting the
data elements that were modified by the change. An amendment differs from an
edit in that the change originates from an ancillary document being executed to
alter the lease, as opposed to an edit, which is a correction to existing information.
Examples of an amendment may include a change to the termination date of the
lease, a change in lease status, a relocation of an assigned space, a change to an
option or right, or an additional billing or payment term. Edits may occur due to
data entry errors, and do not originate from ancillary documents.
The conversion of edits may be handled either by
1
Including the changes as part of the original conversion; this may be a simpler
and more effective approach, as changes in the legacy system that are not
recorded as amendments may not be identified; or
Loading the changes after the finalization of the lease to show the original
abstraction, and then any changes to the lease.
The conversion of amendments is a more complex task as it requires each

amendment on a lease to be sequentially loaded based on the effective date;
committed to the database; and the Schedules and Items program to be submitted.
It also requires the conversion routine to reference a previously load lease event,
when the amendment or edit relates to a change of a record, insert of the insertion
of a new record.
The conversion of edits and amendments requires that the following history tables
be updated as part of the conversion.
PN_LEASE_CHANGES_ALL
Page 33
PN_LEASE_DETAILS_HISTORY
PN_CONTACT_ASSIGN_HISTORY
PN_TENANCIES_HISTORY
PN_INSUR_REQUIRE_HISTORY
PN_LANDLORD_SERVICE_HISTORY
PN_OPTIONS_HISTORY
Lease Details
The following fields cannot be either edited or amended once a lease is finalized:
Approval Status
Class
Proration Rule
Commencement Date
When a lease is amended it is possible to update the Lease Status.

When a lease is amended the following information is required:
Execution Date. The date that the amendment to the lease was agreed to and
signed by both parties to the lease.
Commencement Date. The date from which the lease amendment changes
take effect.
Termination Date. The termination date of the amendment, usually the same
as the lease termination date.
Additionally if the amendment to the lease has a status change to either Holdover
or Month to Month then a lease extension end date is required.
Lease Terms
When either amending or editing a lease term, there currently exists a restriction on
changing the dates on a term if they have been approved. Once a term has been
approved, the Start Date may not be changed. When contracting an End Date,
the earliest date that can be used, is the last Schedule Date plus one day.
A lease term cannot have its normalization state changed after schedules and items
have been generated.
The effect on Normalization
If terms are normalized on a lease agreement, the addition of another term that is
also normalized can affect the normalization process and the result produced.
Additionally, if an existing term which is also normalized is altered, then this may
also affect the results of normalization.
Page 34
If a change is made to a lease with normalized terms, Oracle Property Manager will
renormalize the remaining unapproved items based on the new information.
Factors that will affect the result include the following:
Is the change the result of an edit or an amendment?
If the change is an amendment, what are the new amendment commencement

and lease termination dates?
What is the last approved schedule date?
Amending a Lease with a Normalized Term
When a lease change results from an amendment, the term(s) are renormalized
based on the amendment commencement date and lease termination date. If
schedules have been approved for dates after the new commencement date, then
renormalization occurs over the remaining draft schedules.
Example of Rent Normalization and an Amendment
The original lease has the following terms:

A normalized term of $12,000 per annum to start on 1 January, 2001 and end
on 31 December, 2004.
Rent abatement of $3000 for the first year.

calculations:
Schedule
Date
(A)
01-Jan-2001
01-Jan-2002
01-Jan-2003
01-Jan-2004
Base Rent
(B)
Abatement
(C)
Amendment
Rent
(D)
Billed Rent
(E)
Revenue
Account
Balance
(F)
Accrued
Asset
Balance
(H)
Adjustment
(G)
$12,000.00
$12,000.00
$12,000.00
$12,000.00
$3,000.00
$9,000.00
$12,000.00
$12,000.00
$12,000.00
$11,250.00
$11,250.00
$11,250.00
$11,250.00
$2,250.00
($750.00)
($750.00)
($750.00)
$2,250.00
$1,500.00
$750.00
$0.00
$48,000.00
$3,000.00
$45,000.00
$45,000.00
$0.00
$0.00
The following table illustrates the accounting transactions that result from the
normalization of the terms and the source of the accounting distribution in the
General Ledger:
GL Date
Receivable Invoice
Accrued
Receivable
Asset
Normalization JE
Accrued
Revenue
Asset
Page 35
GL Date
01-Jan-2001
01-Feb-2001
01-Mar-2001
01-Apr-2001
01-May-2001
01-Jun-2001
01-Jul-2001
01-Aug-2001
01-Sep-2001
01-Oct-2001
01-Nov-2001
01-Dec-2001
01-Jan-2002
01-Feb-2002
01-Mar-2002
01-Apr-2002
01-May-2002
01-Jun-2002
01-Jul-2002
01-Aug-2002
01-Sep-2002
01-Oct-2002
01-Nov-2002
01-Dec-2002
01-Jan-2003
01-Feb-2003
01-Mar-2003
01-Apr-2003
01-May-2003
01-Jun-2003
01-Jul-2003
01-Aug-2003
01-Sep-2003
01-Oct-2003
01-Nov-2003
01-Dec-2003
01-Jan-2004
01-Feb-2004
Receivable Invoice
Accrued
Receivable
Asset
9,000.00
(9,000.00)
Normalization JE
Accrued
Revenue
Asset
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
9,000.00
(9,000.00)
(11,250.00)
11,250.00
12,000.00
(12,000.00)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
12,000.00
(12,000.00)
(11,250.00)
11,250.00
12,000.00
(12,000.00)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
(937.50)
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
937.50
12,000.00
(12,000.00)
(11,250.00)
11,250.00
12,000.00
(12,000.00)
(937.50)
(937.50)
937.50
937.50
Page 36
GL Date
01-Mar-2004
01-Apr-2004
01-May-2004
01-Jun-2004
01-Jul-2004
01-Aug-2004
01-Sep-2004
01-Oct-2004
01-Nov-2004
01-Dec-2004
Receivable Invoice
Accrued
Receivable
Asset
12,000.00
(12,000.00)
Normalization JE
Accrued
Revenue
Asset
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(937.50)
937.50
(11,250.00)
11,250.00
Scenario 1
The original lease is modified by an amendment which extends the lease until 30
June, 2005 as follows:
Amendment is executed on 15 December, 2002 with a amendment date of 1

January, 2003 and a new lease termination date of 30 June, 2005.
A normalized term of $5,000 per annum to start on 1 January, 2003 and end on
30 June, 2005 is added.
Terms have been approved until 31 December, 2002.

calculations:
Schedule
Date
(A)
01-Jan-2001
01-Jan-2002
01-Jan-2003
01-Jan-2004
01-Jan-2005
Base Rent
(B)
Abatement
(C)
$12,000.00
$12,000.00
$12,000.00
$12,000.00
$3,000.00
$48,000.00
$3,000.00
Revenue
Account
Balance
(F)
Accrued
Asset
Balance
(H)
Amendment
Rent
(D)
Billed Rent
(E)
$5,000.00
$5,000.00
$2,500.00
$9,000.00
$12,000.00
$17,000.00
$17,000.00
$2,500.00
$11,250.00
$11,250.00
$14,000.00
$14,000.00
$ 7,000.00
$2,250.00
($750.00)
($3,000.00)
($3,000.00)
($4,500.00)
$2,250.00
$1,500.00
($1,500.00)
$4,500.00
$0.00
$12,500.00
$57,500.00
$57,500.00
$0.00
$0.00
Adjustment
(G)
As a result of the amendment, the following changes occur to the accounting

distributions from 1 January, 2003:
Page 37
The original terms are renormalized based on the lease commencement date of 1
January, 2001 and a termination date of 30 June, 2005. Renormalization occurs
over all remaining draft schedules
Normalized Revenue = (45,000 - 22,500) 30
= $750.00 per month
The new term is normalized based on the associated amendment commencement
date of 1 January, 2003 and termination date of 30 June, 2005.
Normalized Revenue = 12,500 30
= $416.67 per month
The sum of these normalized terms is $1,166.67
The following table illustrates the changes to the accounting transactions that result
from the normalization of the terms and the source of the accounting distribution
in the General Ledger:
Receivable Invoice
GL Date
01-Jan-2003
Receivable
17,000.00
Accrued Asset
(17,000.00)
Normalization JE
Revenue
Accrued Asset
(1,166.67)
1,166.67
01-Feb-2003
(1,166.67)
1,166.67
01-Mar-2003
(1,166.67)
1,166.67
01-Apr-2003
(1,166.67)
1,166.67
01-May-2003
(1,166.67)
1,166.67
01-Jun-2003
(1,166.67)
1,166.67
01-Jul-2003
(1,166.67)
1,166.67
01-Aug-2003
(1,166.67)
1,166.67
01-Sep-2003
(1,166.67)
1,166.67
01-Oct-2003
(1,166.67)
1,166.67
01-Nov-2003
(1,166.67)
1,166.67
01-Dec-2003
01-Jan-2004
(1,166.67)
1,166.67
17,000.00
(17,000.00)
(14,000.04)
14,000.04
17,000.00
(17,000.00)
(1,166.67)
1,166.67
01-Feb-2004
(1,166.67)
1,166.67
01-Mar-2004
(1,166.67)
1,166.67
01-Apr-2004
(1,166.67)
1,166.67
01-May-2004
(1,166.67)
1,166.67
01-Jun-2004
(1,166.67)
1,166.67
01-Jul-2004
(1,166.67)
1,166.67
01-Aug-2004
(1,166.67)
1,166.67
01-Sep-2004
(1,166.67)
1,166.67
01-Oct-2004
(1,166.67)
1,166.67
01-Nov-2004
(1,166.67)
1,166.67
01-Dec-2004
17,000.00
(17,000.00)
(1,166.67)
1,166.67
(14,000.04)
14,000.04
Page 38
Receivable Invoice
GL Date
01-Jan-2005
Receivable
2,500.00
Accrued Asset
Normalization JE
Revenue
(2,500.00)
Accrued Asset
(1,166.67)
1,166.67
01-Feb-2005
(1,166.67)
1,166.67
01-Mar-2005
(1,166.67)
1,166.67
01-Apr-2005
(1,166.67)
1,166.67
01-May-2005
(1,166.67)
1,166.67
(1,166.67)
1,166.67
(7,000.02)
7,000.02
01-Jun-2005
2,500.00
(2,500.00)
Scenario 2
Alternatively, the original lease is modified by an amendment as follows:
Amendment is executed on 1 January, 2004 with a commencement date of 1

January, 2003 and a termination date of 31 December, 2004.
31 December, 2005.
Terms have been approved until 31 December, 2003.
Because terms from 2003 have already been approved, a term is retroactively
created in 2003 using schedule day 2.
The amended term in 2004 uses schedule day 1.

calculations:
Schedule
Date
(A)
Base Rent
(B)
01-Jan-2001
$12,000.00
01-Jan-2002
$12,000.00
01-Jan-2003
$12,000.00
Abatement
(C)
$3,000.00
02-Jan-2003
01-Jan-2004
Amendment
Rent
(D)
$9,000.00
$11,250.00
$2,250.00
$2,250.00
$11,250.00
($750.00)
$1,500.00
$12,000.00
$11,250.00
($750.00)
$750.00
$5,000.00
$5,000.00
$0.00
$0.00
$12,000.00
$11,250.00
($750.00)
$0.00
$5,000.00
$5,000.00
$5,000.00
$0.00
$0.00
$10,000.00
$55,000.00
$55,000.00
$0.00
$0.00
$12,000.00
$48,000.00
$3,000.00
Adjustment
(G)
Accrued
Asset
Balance
(H)
$12,000.00
$5,000.00
02-Jan-2004
Billed Rent
(E)
Revenue
Account
Balance
(F)
As a result of the amendment, the following changes occur to the accounting

distributions from 1 January, 2003:
The original terms are renormalized based on a commencement date of 1 January,
2003 and a termination date of 31 December, 2004. The earliest available schedule
date is 1 January, 2003.
Page 39
Normalized Revenue = (45,000 - 22,500) 24

= $937.50 per month
date of 2 January, 2003 and termination date of 31 December, 2004. The earliest
available schedule date is 2 January, 2003.
Normalized Revenue = 5000 24
= $208.33 per month
date of 1 January, 2004 and termination date of 31 December, 2004. The earliest
= $416.67 per month
The sum of these normalized terms is as follows:
Schedule Day 1
Schedule Day 2
Schedule Day 1
Schedule Day 2
2003
2004
$937.50
$208.33
$1,354.17
$208.33
GL Date
01-Jan-2003
02-Jan-2003
01-Feb-2003
02-Feb-2003
01-Mar-2003
02-Mar-2003
01-Apr-2003
02-Apr-2003
01-May-2003
01-May-2003
01-Jun-2003
02-Jun-2003
01-Jul-2003
02-Jul-2003
01-Aug-2003
02-Aug-2003
Receivable Invoice
Accrued
Receivable
Asset
12,000.00
(12,000.00)
5,000.00
(5,000.00)
Normalization JE
Accrued
Revenue
Asset
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
Page 40
GL Date
01-Sep-2003
02-Sep-2003
01-Oct-2003
02-Oct-2003
01-Nov-2003
02-Nov-2003
01-Dec-2003
02-Dec-2003
01-Jan-2004
02-Jan-2004
01-Feb-2004
02-Feb-2004
01-Mar-2004
02-Mar-2004
01-Apr-2004
02-Apr-2004
01-May-2004
02-May-2004
01-Jun-2004
02-Jun-2004
01-Jul-2004
02-Jul-2004
01-Aug-2004
02-Aug-2004
01-Sep-2004
02-Sep-2004
01-Oct-2004
02-Oct-2004
01-Nov-2004
02-Nov-2004
01-Dec-2004
02-Dec-2004
Receivable Invoice
Accrued
Receivable
Asset
Normalization JE
Accrued
Revenue
Asset
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
(937.50)
937.50
(208.33)
208.33
17,000.00
(17,000.00)
(13,749.96)
13,749.96
17,000.00
(17,000.00)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.33)
(1,354.17)
(208.37)
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.33
1,354.17
208.37
17,000.00
(17,000.00)
(18,750.04)
18,750.04
The above table shows accounting transactions with the original General Ledger
Date. The earliest open period in the General Ledger will determine the accounting
General Ledger Date for retro-active adjustments.
Scenario 3
Alternatively, the original lease is modified by an amendment as follows:
Page 41
Amendment is executed on 1 January, 2004 with a commencement date of 1

January, 2003 and a termination date of 31 December, 2004.
An executed amendment to the lease allowing roof rights is granted. There is

no financial consideration
Terms have been approved until 31 December, 2003
Because no changes were made to any financial terms, and the lease was neither
extended nor contracted, the Schedules and Items concurrent program is not
submitted, as the normalized rent would not be altered.
Editing a Lease with a Normalized Term
When editing a lease which has a normalized term, adding an additional term which
is also normalized will result in a renormalization from the original commencement
date.
Additionally, a lease cannot be extended as the result of an edit, nor can the lease
status be altered to Holdover or Month to Month.
Scenario 5
Alternatively the original lease is modified by an edit accordingly:
31 December, 2005.
No Terms have been approved.

calculations:
Schedule
Date
(A)
01-Jan-2001
01-Jan-2002
01-Jan-2003
01-Jan-2004
Base Rent
(B)
Abatement
(C)
$12,000.00
$12,000.00
$12,000.00
$12,000.00
$3,000.00
$48,000.00
$3,000.00
Edit Rent
(D)
Billed Rent
(E)
Revenue
Account
Balance
(F)
Adjustment
(G)
Accrued
Asset
Balance
(H)
$5,000.00
$5,000.00
$9,000.00
$12,000.00
$17,000.00
$17,000.00
$13,750.00
$13,750.00
$13,750.00
$13,750.00
$4,750.00
$1,750.00
($3,250.00)
($3,250.00)
$4,750.00
$6,500.00
$3,250.00
0.00
$10,000.00
$55,000.00
$55,000.00
$0.00
$0.00
As a result of the edit, the following changes occur to the accounting distributions
from 1 January, 2003:
The original term and the new term are renormalized based on a commencement
date of 1 January, 2001 and a termination date of 31 December, 2004. The earliest
Page 42
Normalized Revenue = (55,000 - 0) 48

= $1,145.83 per month
GL Date
01-Jan-2001
01-Feb-2001
01-Mar-2001
01-Apr-2001
01-May-2001
01-Jun-2001
01-Jul-2001
01-Aug-2001
01-Sep-2001
01-Oct-2001
01-Nov-2001
01-Dec-2001
01-Jan-2002
01-Feb-2002
01-Mar-2002
01-Apr-2002
01-May-2002
01-Jun-2002
01-Jul-2002
01-Aug-2002
01-Sep-2002
01-Oct-2002
01-Nov-2002
01-Dec-2002
01-Jan-2003
01-Feb-2003
01-Mar-2003
01-Apr-2003
01-May-2003
01-Jun-2003
01-Jul-2003
01-Aug-2003
01-Sep-2003
01-Oct-2003
Receivable Invoice
Accrued
Receivable
Asset
9,000.00
(9,000.00)
Normalization JE
Accrued
Revenue
Asset
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
(1,145.83)
1,145.83
9,000.00
(9,000.00)
(13,749.96)
13,749.96
12,000.00
(12,000.00)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
12,000.00
(12,000.00)
(13,749.96)
13,749.96
17,000.00
(17,000.00)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
Page 43
GL Date
01-Nov-2003
01-Dec-2003
01-Jan-2004
01-Feb-2004
01-Mar-2004
01-Apr-2004
01-May-2004
01-Jun-2004
01-Jul-2004
01-Aug-2004
01-Sep-2004
01-Oct-2004
01-Nov-2004
01-Dec-2004
Receivable Invoice
Accrued
Receivable
Asset
Normalization JE
Accrued
Revenue
Asset
(1,145.83)
1,145.83
(1,145.83)
1,145.83
17,000.00
(17,000.00)
(13,749.96)
13,749.96
17,000.00
(17,000.00)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.83)
(1,145.99)
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.83
1,145.99
17,000.00
(17,000.00)
(13,750.12)
13,750.12
Scenario 6
Alternatively, the original lease is modified by an edit as follows:
31 December, 2005.
Terms are approved to 31st December 2002.

calculations:
Schedule
Date
(A)
01-Jan-2001
01-Jan-2002
01-Jan-2003
01-Jan-2004
Base Rent
(B)
Abatement
(C)
$12,000.00
$12,000.00
$12,000.00
$12,000.00
$3,000.00
$48,000.00
$3,000.00
Revenue
Account
Balance
(F)
Accrued
Asset
Balance
(H)
Amendment
Rent
(D)
Billed Rent
(E)
$5,000.00
$5,000.00
$9,000.00
$12,000.00
$17,000.00
$17,000.00
$11,250.00
$11,250.00
$16,250.00
$16,250.00
$2,250.00
($750.00)
($750.00)
($750.00)
$2,250.00
$1,500.00
$750.00
0.00
$10,000.00
$55,000.00
$55,000.00
$0.00
$0.00
Adjustment
(G)
The original terms are renormalized based on a commencement date of 1 January,

2001 and a termination date of 31 December, 2004. The earliest available schedule
date is 1 January, 2001.
Page 44
Normalized Revenue = (45,000 - 0) 48

= $937.50 per month
The new term is normalized based on the commencement date of 1 January, 2001
and termination date of 31 December, 2004. However, because the terms have
been approved through 31 December, 2002, only 24 months are available. The
earliest available schedule date is 1 January, 2003.
= $416.67 per month
GL Date
01-Jan-2003
01-Feb-2003
01-Mar-2003
01-Apr-2003
01-May-2003
01-Jun-2003
01-Jul-2003
01-Aug-2003
01-Sep-2003
01-Oct-2003
01-Nov-2003
01-Dec-2003
01-Jan-2004
01-Feb-2004
01-Mar-2004
01-Apr-2004
01-May-2004
01-Jun-2004
01-Jul-2004
01-Aug-2004
01-Sep-2004
01-Oct-2004
01-Nov-2004
01-Dec-2004
Receivable Invoice
Accrued
Receivable
Asset
17,000.00
(17,000.00)
Normalization JE
Accrued
Revenue
Asset
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
(1,354.17)
1,354.17
17,000.00
(17,000.00)
(16,250.04)
16,250.04
17,000.00
(17,000.00)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
(1,354.17)
1,354.17
1,354.17
1,354.17
1,354.17
1,354.17
1,354.17
1,354.17
1,354.17
1,354.17
1,354.17
1,354.17
1,354.17
17,000.00
(17,000.00)
(16,250.04)
16,250.04
Page 45
Approve Schedules
Following the completion of the loading of terms, it is necessary to approve

schedules prior to export. This can be accomplished using the Mass Approval
process.
Approve schedules up to the date of the cutover from the legacy system to Oracle
Property Manager.
Normalized Terms
Cash Terms
Cutover Date
Legacy Sub-Ledger
Oracle Sub-ledgers
Legacy General Ledger
Oracle General Ledger
Reconciliation
The conversion of all historical terms presents a reconciliation problem with the
Account Receivable or Accounts Payable sub-ledger. In most cases the approved
term has already been reflected in the appropriate sub-ledger and an export of
terms would result in a duplication of invoicing. Additionally, where terms have
been normalized, the accrual and relief of the accrual will have also occurred and
does not require replication.
If all terms in the legacy system prior to the cutover date, have been transferred to
the appropriate sub-ledger, there is no requirement to reconcile the receivable and
revenue accounts in the case of a third party or sub-lease, or the liability and
expense accounts where the lease is a direct lease. This is because the new items
transferred after the cutover date are independent to those previously transferred.
An exception to this would occur where billing terms are transferred and the nonnormalized terms have revenue rules where the initial revenue period was prior to
Page 46
cutover, and revenue recognition is still on going. In this case it may be necessary to
create two separate terms on the lease, one for the period prior to the cutover date,
and one subsequent to the cutover date.
In cases where normalized terms exist on the lease, it is necessary to reconcile the
accrued asset or liability with the balance or normalized terms remaining on lease in
Oracle Property Manager.
The reconciliation of the conversion process requires that both schedules and
items, and prior normalized terms are cleaned up.
Clean Up Schedules and Items
Items that have already been exported to a sub-ledger need to be flagged as

exported.
This can be accomplished by one of two approaches:
Use a SQL*Plus script to update the PN_PAYMENT_ITEMS_ALL table; or
Transfer terms to the appropriate sub-ledger and then delete the invoices in the
interface.
Regardless of the approach, it is important to ensure that all legacy terms related to
the lease have been transferred from the legacy system prior to the cut over date;
failure to do so may result in missing invoices.
Transfer Normalized Distributions
After the completion of the Schedules and Items cleanup, a similar process is
required for the normalized items that would have been transferred to the General
Ledger.
This can be accomplished using the Transfer Normalized Expense and Revenue to
GL concurrent program. When using submitting this request, ensure that the
schedule start and end dates cover all schedules up to the cutover date. Also set the
parameter Submit Journal Import to No
After the process completes, delete the journal in the General Ledger prior to
posting.
Reconciliation with the General Ledger
Where a term is normalized there are two separate events that affect the General
Ledger. The first event is an invoice that allows the billing or payment of an
amount to a customer or supplier. The accounting from this event is detailed
below:
Billing Term
Dr
Cr
Receivable Account
Accrued Asset Account
Page 47
Payment Term
Dr
Accrued Liability Account
Cr
Liability Account
The second event occurs on a monthly basis when the revenue or expense is
recognized. This event is triggered by the GL Transfer Normalized Terms process.
The accounting from this event is detailed below:
Billing Term
Dr
Accrued Asset Account
Cr
Revenue Account
Payment Term
Dr
Expense Account
Cr
Accrued Liability Account
The following query details the sum of normalized terms after the cutover date.
This value should equal the value of the accrued asset or liability in the general
ledger at the cutover date.
SELECT
FROM
WHERE
AND
AND
AND
AND
AND
GROUP BY
pla.lease_num
"Lease Number"
,SUM(ppia.actual_amount)
"Accrued Amnt"
pn_payment_items_all
ppia
,pn_payment_schedules_all
ppsa
,pn_payment_terms_all
ppta
,pn_leases_all
pla
ppia.payment_term_id = ppta.payment_term_id
ppta.lease_id = pla.lease_id
ppia.payment_schedule_id = ppsa.payment_schedule_id
ppia.payment_item_type_lookup_code = 'NORMALIZED'
ppsa.schedule_date > to_date('DD-MON-YY') - note 1
pla.lease_class_code = &CLASS_CODE
-- note 2
pla.lease_num
-- Note 1 Replace with cutover date

-- Note 2 &CLASS_CODE = THIRD_PARTY, DIRECT or SUB_LEASE
After determining the variance between the outstanding normalized terms and the
general ledger balance, adjust the general ledger balance by a general journal entry
to the accrual account and either the revenue/expense account or a provision
account. If the variance is of a material amount, investigation should be undertaken
to understand and explain the variance.
Page 48
TECHNICAL CONSIDERATIONS
This section provides a guide to technical considerations to the conversion of

leases.
Setups
Prior to the conversion of lease data, the following setups are required to be
defined:
Applications
Common Application
Users
Common Financials
Tax Codes
Calendar
Currency
General Ledger Code Combinations
Receivables. (Required for Third Party and Sub-Leases.)
Customer Profile Class
Payment Terms
Customers
Invoice Grouping Rules
Invoice and Account Rules
Transaction Types
Salespersons
Accounting Distribution Sets
Payables. (Required for Direct Leases.)
Payment Terms
Suppliers
Accounting Distribution Sets
Projects. (Required for Direct leases using Project information.)
Project Name
Task
Expenditure Type
Project Organization
Page 49
Property Manager
Contacts
Milestone Templates
Term Templates
Locations
Grouping Rules
Descriptive Flexfields and value sets
Property Manager System Options
Accounting Option
Currency Conversion Type
Automatic Space Distribution
Automatic Lease Number
Multiple Tenancy Lease
Location Code Separator
Default Location Area for Leases
Invoice Grouping Name
Property Manager Lookups
Lease Type (PN_LEASE_TYPE)
Lease Status (PN_LEASESTATUS_TYPE)
Payment Purpose Type (PN_PAYMENT_PURPOSE_TYPE)
Payment Term Type (PN_PAYMENT_TERM_TYPE)
Role (PN_LEASE_ROLE_TYPE)
Job Title (PN_JOB_TITLE)
Landlord Services (PN_LANDLORD_SERVICE_TYPE)
Insurance Type (PN_INSURANCE_TYPE)
Lease Option Types (PN_LEASE_OPTION_TYPE)
Lease Option Status (PN_OPTION_STATUS_TYPE)
Milestone Sets (PN_MILESTONES_SET)
Milestone Type (PN_MILESTONES_TYPE)
Note Type (PN_NOTE_TYPE)
Financial Responsible Party (PN_OBLIGATION_FIN_RESP_PARTY)
Page 50
Obligation Responsibility (PN_OBLIGATION_RESP_TYPE)
Recovery Space Standard Type (PN_RECOVERY_SPACE_STD_TYPE)
Recovery Type (PN_RECOVERY_TYPE)
Rights Type (PN_RIGHTS_TYPE)
Rights Status (PN_RIGHT_STATUS_TYPE)
Tenancy Usage Type (PN_TENANCY_USAGE_TYPE)
Target Tables
When loading lease components the following tables are used.

Load Leases and Lease Details
The following tables have records inserted during the abstraction or amendment of
a lease:
PN_LEASES_ALL
PN_LEASE_DETAILS_ALL
PN_LEASE_TRANSACTIONS_ALL
PN_LEASES_ALL stores lease information such as the name, number, type, class,
and status of the lease, and the name of the user who abstracted the lease. After the
lease is finalized, the data elements are protected against updates.
PN_LEASE_DETAILS_ALL stores lease dates and accounting information.
PN_LEASE_TRANSACTIONS_ALL stores transactions performed on a lease.
The type of transaction is either AMEND or EDIT. A row is created in this table
when a lease is amended or edited.
PN_LEASE_CHANGES_ALL stores the changes made to the lease by
amendments and edits. During lease abstraction, a row is created with
LEASE_CHANGE_NUMBER as null to link it with the row in table
PN_LEASES_ALL.
PN_LEASE_DETAILS_HISTORY tracks changes to the lease details data
elements. A row is created in this table when LEASE_TERMINATION_DATE is
altered in a lease by means of an amendment or an edit to the lease.
ENTITY RELATIONSHIP DIAGRAM
Page 51
PN_LEASES_ALL
HZ_CUSTOMER_ACCOUNTS
FND_LOOKUPS
PN_LOCATIONS_ALL
PN_LEASE_DETAILS_ALL
PN_TERM_TEMPLATES_ALL
PN_TRANSACTIONS_ALL
GL_CODE_COMBINATIONS
Load Contacts
a lease:
PN_CONTACT_ASSIGNMENTS_ALL
PN_CONTACT_ASSIGNMENTS_ALL links locations or leases with a service

provider site. There can be multiple contacts associated with a single location or a
lease.
PN_CONTACT_ASSIGN_HISTORY tracks changes in contacts linked to the
lease. A row is created in this table when the contact information is altered by
means of an amendment or an edit to the lease.
Entity Relationship Diagram
Page 52
PN_LEASES_ALL
FND_LOOKUPS
PN_LOCATIONS_ALL
PN_CONTACT_ASSIGNMENTS_ALL
PN_COMPANIES_ALL
PN_CONTACTS_ALL
PN_COMPANY_SITES_ALL
Load Tenancies
a lease:
PN_LEASE_TENANCIES_ALL
PN_LEASE_TENANCIES_HISTORY
PN_TENANCIES_ALL stores information on leased or subleased locations. The

table captures the tenancy occupancy and expiration dates along with additional
lease clauses.
PN_TENANCIES_HISTORY tracks changes in the leased or subleased locations.
A row is created in this table when the tenancy information is altered by means of
an amendment or an edit to the lease.
Page 53
PN_LEASES_ALL
HZ_CUSTOMER_ACCOUNTS
FND_LOOKUPS
PN_LOCATIONS_ALL
PN_LEASE_TENANCY_HISTORY
PN_LEASE_TENANCIES_ALL
PN_TRANSACTIONS_ALL
Load Insurance Details
a lease:
PN_INSURANCE_REQUIREMENTS_ALL
PN_INSURE_REQURE_HISTORY
PN_INSURANCE_REQUIREMENTS_ALL stores insurance details related to a

lease. A single lease can have multiple insurance requirements.
PN_INSUR_REQUIRE_HISTORY tracks changes to insurance details related to
a lease. A row is created in this table when the insurance information in a lease is
altered by means of an amendment or an edit to the lease.
Page 54
PN_LEASES_ALL
PN_INSURE_REQUIRE_HISTORY
FND_LOOKUPS
PN_TRANSACTIONS_ALL
Load Lease Obligations
a lease:
PN_LANDLORD_SERVICES_ALL
PN_LANDLORD_SERVICES_ALL stores information about the services

provided by the landlord to the lessee, such as maintenance, security, and parking.
There can be multiple rows based on the number of services provided by the
landlord.
PN_LANDLORD_SERVICE_HISTORY tracks changes in the services provided
by the landlord to the lessee during a lease. A row is created in this table when the
service information in a lease is altered by means of an amendment or an edit to the
lease.
Page 55
PN_LEASES_ALL
PN_LANDLORD_SERVICES_ALL
FND_LOOKUPS
PN_TRANSACTIONS_ALL
Load Lease Rights
a lease:
PN_RIGHTS_ALL
PN_RIGHTS_HISTORY
PN_RIGHTS_ALL Stores details about rights of the lessee/lessor for the lease.
There can be multiple rows based on the number of rights associated with the lease.
PN_RIGHTS_HISTORY stores details about the history of rights of the
lessee/lessor for the lease. A row is created in this table when the service
information in a lease is altered by means of an amendment or an edit to the lease.
Page 56
PN_LEASES_ALL
PN_RIGHTS_HISTORY
PN_RIGHTS_ALL
PN_LEASE_TRANSACTIONS
_ALL
Load Lease Options
a lease:
PN_OPTIONS_ALL
PN_OPTIONS_HISTORY
PN_OPTIONS_ALL stores the details of specified terms within a specific period

in a lease contract. The purpose of an option can be to purchase or lease a
property, extend the lease term, change payment terms, etc.
PN_OPTIONS_HISTORY tracks changes in option details related to a lease. A
row is created in this table when the options information is altered in a lease, by
means of an amendment or an edit to the lease.
Page 57
PN_LEASES_ALL
PN_OPTIONS_HISTORY
PN_OPTIONS_ALL
Load Terms
a lease:
PN_PAYMENT_TERMS_ALL
PN_DISTRIBUTIONS_ALL
PN_PAYMENT_TERMS_ALL stores the payment and billing terms defined in a

lease. The terms can be for base rent, abatement, escalation, retro adjustment,
direct, etc. The details of a term are used to create payment or billing schedules and
payment or billing items.
PN_DISTRIBUTIONS_ALL stores accounting information for the payment term
amount if the amount is distributed among respective accounts.
The following tables have records inserted or updated during the Schedules and
Items concurrent process:
PN_PAYMENT_ITEMS_ALL
PN_ PAYMENT_SCHEDULES_ALL
PN_PAYMENT_ITEMS_ALL stores payment and billing items associated with a

payment or a billing schedule respectively. The items are generated by the system
through a concurrent batch process for every payment and billing term defined in a
lease. Payment item describes the details of payments to be made to a supplier.
Billing item describes the details of receipts from a customer for a leased or owned
property. An item can be classified as a CASH or NORMALIZED item.
Page 58
PAYMENT_ITEM_TYPE_LOOKUP_CODE column identifies such a

transaction. CASH items are transferred to Accounts Payable and Accounts
Receivable respectively based upon the lease class.
PN_PAYMENT_SCHEDULES_ALL stores rent schedules for both the landlord
and tenant. The schedules are generated by a concurrent batch process when a lease
is finalized or the lease dates are altered by an amendment or an edit. The schedules
are created based on the frequency of a payment term in the lease. For example, if
the term is for a year and the frequency is monthly, twelve schedules are created,
one representing each month.
[to be added]
Load Notes
a lease:
PN_NOTE_HEADERS
PN_ NOTE_DETAILS
PN_NOTE_HEADERS stores the type of a note in a lease. The type defines the
context for note details and is set up as a lookup code in FND_LOOKUPS table.
PN_NOTE_DETAILS stores multiple lines of text associated with a note type.
This table is multi-lingual.
PN_LEASES_ALL
PN_NOTE_HEADERS
PN_HOTE_DETAILS
Page 59
Load Milestones
a lease:
PN_LEASE_MILESTONES_ALL
PN_LEASE_MILESTONES_ALL stores information about important events in a

lease pertaining to options, insurance requirements, payment terms, and the lease
itself. Milestones can be specific to a user and for a specific event, such as lease
creation or amendment, change in rent schedule, change in options and insurance,
etc.
PN_LEASES_ALL
PN_OPTIONS_ALL
PN_PAYMENT_TERMS_ALL
PN_LEASE_MILESTONES_ALL
PN_LEASE_TRANSACTIONS
_ALL
Page 60
CONCLUSION
The aim of this paper has been to detail the necessary steps required to convert
legacy lease data to Oracle Property Manager. The complexities of the lease
conversion require that thorough consideration and planning are undertaken prior
to any activities to develop any interfaces or conversion logic.
The amount of history that is required to be converted will drive the complexity of
this activity. In particular, the conversion of tenancies and terms will require an
accurate timeline of lease events to ensure an accurate abstraction of the lease. The
handling of amendments and edits adds further complexity to the task.
The goal of the conversion is to provide an accurate abstraction of the lease so that
the end user as all the appropriate information necessary to make an informed
decision, and for the system to make any necessary calculations.
Page 61

May 2005
Author: Liam Boyd
Contributing Author: Nitin Katare
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright 2005, Oracle. All rights reserved.
This document is provided for information purposes only
and the contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to
any other warranties or conditions, whether expressed orally
or implied in law, including implied warranties and conditions of
merchantability or fitness for a particular purpose. We specifically
disclaim any liability with respect to this document and no
contractual obligations are formed either directly or indirectly
by this document. This document may not be reproduced or
transmitted in any form or by any means, electronic or mechanical,
for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.

Lease

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lease

Uploaded by

Copyright:

Available Formats

Oracle Property Manager Lease

Oracle Property Manager Lease Conversion

Oracle Property Manager Lease Conversion

Oracle Property Manager Lease Conversion

Oracle Property Manager Lease Conversion

This whitepaper is divided into three sections:

This whitepaper specifically addresses functionality associated with Property

Oracle Property Manager Lease Conversion

Oracle Property Manager Lease Conversion

Days in the month

Days in a 365 day calendar

Days in a 360 day calendar

Payment item grouping rule.

Payment term grouping rule.

Lease grouping rule.

System option grouping rule.

Oracle Property Manager Lease Conversion

Usage refers to the intended usage of the land or building space.

The date the location is expected to be occupied.

Oracle Property Manager Lease Conversion

This refers to the name or number of the insurance policy.

A checkbox defines whether the insurance policy is currently active. This is

The right to assign or sublease all or a portion of the premises

Oracle Property Manager Lease Conversion

The right of first refusal to adjoining space

Building naming rights

Oracle Property Manager Lease Conversion

Oracle Property Manager Lease Conversion

Cost refers monetary value associated with an option, should it be exercised.

Refers to the currency in which the option cost is denominated.

The location field optionally associates a building/land, floor/parcel or

Oracle Property Manager Lease Conversion

Oracle Property Manager Lease Conversion

Lease milestones provides a capability to schedule reminders and notifications for

Oracle Property Manager Lease Conversion

An abstracted lease in Property Manager is intended to accurately reflect the

Should the conversion be programmatically executed or manually entered?

How much history should be converted?

How should historical records be treated?

In what sequence should data be converted?

The number of leases to be converted is a good measure for determining whether a

Oracle Property Manager Lease Conversion

Converting Historical Data

A third party lease is executed on 1 November, 2000 with a commencement

Rent is scheduled to be billed on the first day of each year.

The location has a rentable space of 900 square feet.

Regardless of whether a manual or programmatic conversion method is chosen, a

Load Lease Details;

Load Lease Tenancy Information;

Load Contacts, Options, Rights, Insurance, and Notes;

Oracle Property Manager Lease Conversion

Load Milestone information;

Mass Approve Schedules;

Clean up Schedule and Items;

10 Transfer normalized distributions to General Ledger; and

Flag Items already

Load Lease Details

Oracle Property Manager Lease Conversion

Third Party leases;

The execution date is not constrained.

The accounting distribution on the lease term.

The accounting distribution on the lease term template.