3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications

AboutOracleApps

13July2007
Howtomigratedataintooracleapplications
Purpose:

ThePurposeofthisdocumentistoarriveataDatamigrationStrategyforZTL.Data
Migrationistheprocessoftransferofdatafromthecurrentsystemsinusetothe
proposedOracleFinancialsSystem.CurrentlymostAccountingDataismaintainedin
TallyandExcelandDatafromthesesystemswillbeconvertedtoOracleApplications
data.HenceforthinthisdocumentthetermsMigrationandConversionwillbeused
interchangeably

TheStrategywillbecoveringthefollowingaspects:

1.CutOffDate
2.Typeofdatatobemigrated
3.MigrationProcessinGeneral
4.ModulewiseMigrationStrategy

5.DataformatsrequiredExcelformat

6.ManDayestimatesofdevelopmentofinterfaces.

TheMigrationstrategygivenbelowiswiththefollowingmodulesinmindGeneral
Ledger(GL),AccountsPayable(AP),AccountsReceivable(AR),OracleProjects(PA)
andOraclePurchasing(PO).FixedAssetsandCashManagementwillbeundertaken
inPhase2oftheimplementation.

1.CutoffDate:

Theselectionofcutoffdateispredicatedonthefollowingreasons:

a)ClearIdentificationoftransactionsfromearliersystem
b)Auditability
c)Continuity

TheCutoffdateisnormallytakenastheclosestdateforwhichStatutoryAudithas
beencompletedsothattherearenoauditcomplicationsandispreferablyatthe
beginningofamonth.Wethereforehavetwooptionsviz1stApr01or30thJune01.

Westronglyrecommendedhavingcutoffdatefordatamigrationas30thJune01.To
enablethistwothingshavetobeachieved:

a)StatutoryAuditshouldbecompletetillthe30thJune2001.
b)AllVendorbalancesandCustomerbalanceswillhavetobeconfirmedforthecutoff
date.

TheAuditshouldmadewithaclearunderstandingwiththeAuditorsthatthereisno
questionofrevisitingtheearliersystemastheearliersystemwillbediscontinued.We
preferthissystembecauseitreducestheamountofdatathatneedstobemigrated
asthiswouldmeantakingtransactionfrom1stofJulyintoOracleApplications.This
reducesthetimethatwillbetakenformigrationsignificantlyandtheobjectives
underlinedabovecanstillbeachieved.

ObtainingcustomerandVendorconfirmationsisnecessarybecauseitmeansthe
balancesthatareenteringthenewsystemthroughsubledgersarecorrectandthere
arelessreasonsforrevisitingtheearliersystems.

2.Typeofdatatobemigrated

Thereareessentiallytwokindsofdatathatneedstobemigrated:

a)AllMasterdatainallthemodules.
b)AllOpenTransactionsinvariousmodules.

InthemodulesthatarebeingimplementedthefollowingaretheMastersand
http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 1/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications
Transactionsthatwillbemigrated:

Masters:

Module
NameofMaster
InterfaceExists?
ProcessofEntry
GL
ChartofAccounts
No
ManualorADIifavailable
AR,PA
Customers
Yes
ManualasthenumberofCustomersarefew
AP,PO
Vendors
No
Manual
PA
Projects
No
Manual
Common
Employees
No
InterfacefromHRIS
AP,AR
BankMasters
No
Manual

Transactions:

Module
NameofMaster
InterfaceExists?
ProcessofEntry
GL
TrialBalance
Yes
Interface
AR
OpenCustomerInvoices
Yes
Interface

CustomerReceiptsforclosedInvoices
Yes
Interfaceifthereisvolumeotherwisemanual.
AP
OpenVendorInvoices
Yes
Interface

InvoicePayments
No
Manual
PA
CurrentProjectsCost
Yes
Interface

CurrentProjectsRevenue
Yes
Interface
PO
OpenPurchaseorders
No
Manual

3.MigrationProcessinGeneral

TheMigrationprocessisatwostepsequentialprocess

Step

Responsibility
1
DataPreparation
FinanceandAccountsDept
2
DataMigration
F&ADepartment&ImplementationTeam

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 2/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications

DataPreparation:

DatapreparationessentiallyistheprocessofcullingoutdatafromTallyandthe
currentExcelSheetsandgivingthemintherequiredformats.SinceOracle
ApplicationsrequirescertainMandatorydataforsettinguptheapplicationandthese
datamaynotbecapturedintheexistingsystemsthereisanelementofdata
preparationthatwillberequired.ForEg.IfVendorAddressisnotcapturedinTallyit
willhavetobeobtainedformigrationtoOracleApps.

ExcelformatswillbeprovidedtotheF&Adepartmentinwhichthedatawillhavetobe
provided.TheseformatswillbasicallycontaindatathatismandatoryforOracleApps
andsomedatathatthoughnotmandatorywillberequiredbecauseofthewaythe
SystemwillbesetupforZensar.

OncetheCutoffdatehasbeenidentifiedthefollowingprocesswillbefollowed:

a)Atrialbalancewillbetakenforthecutoffdate.ThisTrialbalancewillhavetobe
mappedtothenewproposed8segmentchartofAccounts.
b)Oncethemappingisdonethemappingwillbecleanedfordefectsthatmayarise
betweenthemappingandtheSetupdataprovided.
c)Afterthecorrectmappedtrialbalanceisreadyindividualaccountswillbebroken
downintowhatwillflowfromrespectivesubledgersandwhatwillbeentereddirectly
intoGeneralLedger.
d)Forallthosetransactionsthatcomefromsubledgersdetailedbreakupwillhaveto
beprovidedforthebalanceinGeneralLedger.Foreg.TheBalanceoftheVendor
ControlAccountinGLshouldbethesumtotalofalltheinvoicesthatareenteredin
AP.
e)DummyAccountswillbeusedwherevernecessaryforsmootheningtheprocessof
migration.

DataMigration:

ThisstepessentiallyinvolvesrunningtheinterfacetogetthedatamigratedintoOracle
AppsfromtheExcelSheets.Wherevertherearenointerfacesprovidedthiswillhave
tobedonemanually.Thiscanbedonebyhireddataentryoperatorsbutthereisan
elementoftraininginthewholestepandifthecurrentusersareapartofthedata
entryprocesstheywillalsogettrained.

ExampleofHowMigrationwillbecarriedout:

ExistingTrialBalance:

Account
MappedAccount
Module
Debit
Credit
ShareCapital
01.00.000.31101
GeneralLedger

100000
SecuredLoans
01.00.000.21101
AccountsPayable

150000
VendorA
01.00.000.22101
AccountsPayable

25000
VendorB
01.00.000.22101
AccountsPayable

40000
VendorC
01.00.000.22101
AccountsPayable
5000

CustomerA
01.00.000.12101
AccountReceivable
15000

CustomerB
01.00.000.12101
AccountReceivable
35000

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 3/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications

FixedAssets
01.00.000.11101
GeneralLedger
240000

Travelling
01.00.000.71101
GeneralLedger
34000

CostofGoodsSold
01.00.000.51101
GeneralLedger
55000

Entertainment
01.00.000.72101
GeneralLedger
16000

Revenue
01.00.000.41101
GeneralLedger

85000
Total

400000
400000

AdummyAccountwillbedefinedforMigration:01.00.000.99999

GeneralLedger:

TheFollowingEntryJVwillbepassed

Description
GLAccount
Debit
Credit
ShareCapital
01.00.000.31101

100000
FixedAssets
01.00.000.11101
240000

Travelling
01.00.000.71101
34000

CostofGoodsSold
01.00.000.51101
55000

Entertainment
01.00.000.72101
16000

Revenue
01.00.000.41101

85000
MigrationClearingAccount
01.00.000.99999

160000

AccountsPayable:

TheFollowingInvoiceswillbeentered:

VendorName
InvoiceNo
Debit
CreditAmount
InvoiceAmount
VendorA
I23
01.00.000.99999

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 4/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications
01.00.000.22101
(25000)
VendorB
4546
01.00.000.99999
01.00.000.22101
(40000)
VendorC
568(DebitMemo)
01.00.000.99999
01.00.000.22101
5000
InstitutionA
111
01.00.000.99999
01.00.000.21101
150000

OnpostingtoGeneralLedgerthefollowingentrywillbepassedinGL:

Debit01.00.000.99999210000
Credit01.00.000.2210160000
Credit01.00.000.21101150000

AccountsReceivable:

TheFollowingInvoiceswillbeentered:

CustomerName
InvoiceNo
Debit
CreditAmount
InvoiceAmount
CustomerA
I23
01.00.000.12101
01.00.000.99999
15000
CustomerB
4546
01.00.000.12101
01.00.000.99999
35000

OnpostingtoGeneralLedgerthefollowingentrywillbepassedinGL:

Debit01.00.000.1210150000
Credit01.00.000.9999950000

TheNewMigratedTrialBalancefromOracleApplicationswillthereforelookas
follows:

Account
MappedAccount
Module
Debit
Credit
ShareCapital
01.00.000.31101
GeneralLedger

100000
SecuredLoans
01.00.000.21101
AccountsPayable

150000
APControlAccount
01.00.000.22101
AccountsPayable

60000
ARControlAccount
01.00.000.12101
AccountReceivable
50000

FixedAssets
01.00.000.11101
GeneralLedger
240000

Travelling
01.00.000.71101
GeneralLedger

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 5/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications
34000

CostofGoodsSold
01.00.000.51101
GeneralLedger
55000

Entertainment
01.00.000.72101
GeneralLedger
16000

Revenue
01.00.000.41101
GeneralLedger

85000
MigrationClearingAccount

210000
210000
Total

605000
605000

4.ModulewiseMigrationStrategy

Themigrationofdataforindividualmodulescouldbedifferentfromtheoverallplanfor
migration.Individualmodulesarecoveredasgivenbelow:

GeneralLedger:

AsexplainedintheexampleearliertheTrialBalancewillbebrokendownintoentries
thatwillflowintoGeneralLedger.Thiswillbebroughtintothesystemeithermanually
orbyrunninganinterface.

ForthepurposeofMonthlycomparisonstheGLmodulemigrationisproposedas
followsifthecutoffdateischosenas30thJune2001:

a)TheTrialbalanceforthemonthofAprilandMaywillbeuploadeddirectlyinGeneral
Ledger.Therewontbeanysubledgerbreakupforthesetransactions.Thisisbeing
doneonlyforthepurposeofgettingmonthlyreportsfromGeneralLedger.
b)Dependingupontheopentransactionsthatareflowingfromsubledgersnecessary
adjustmentswillbemadeforthosetransactionsthatareenteredinGeneralLedger
directlyifthesetransactionsareimpactingAprilandMaybalances.

IftheCutoffis1stAprilthenalltransactionswillbebroughtintothesystemsono
suchbreakupwillberequired.

Budgetsarenotconsideredforuploadinthisphase.

AccountsPayable:

BasedontheTrialBalanceMappingalltheAPtransactionswillberoutedthroughAP
asinvoicesandpayments.Therearetwooptionsthatareavailableformigrating
invoices:

a)WithActualaccounting:InordertodothistheF&Adeptwillhavetoprovidethe
actualdebitaccountsforeachandeveryinvoicethatwillbeenteredinthesystem.
b)WithDummyaccounting:Thismethodhelpsustosavetimeaswewillbringinall
theinvoiceswithdummyaccountsandalltheactualaccountingwillbetakendirectly
toGeneralLedgerbutsubledgerbreakupofGLbalanceislostandbecomes
availableonlyfromthedatetransactionsareenteredlive.Thismethodis
recommendedonlyforauditedtransactions.

ThefollowingkindsoftransactionswillbeimportedintoAP:

a)Invoices:AllcreditbalanceswillbemigratedasInvoices.TheF&Adepartmentwill
havetoprovideInvoicewisebreakupofcreditbalancesinthespecifiedformats.
b)Debitbalances:Alldebitbalanceswillbebroughtintothesystemascredit
memos.TheF&Adepartmentwillhavetodecidewhetherthedebitbalancesagainst
eachvendoraretobetreatedasAdvancesorasDebitmemos.Weprefertotreat
themasadvancesasthesystempromptstheuserthatsuchaprepaymentexists
whentheuserisenteringafreshinvoiceagainstthatvendorbuttheyhavedifferent
accountingimpacts.HencethisdecisionwillhavetobetakenbytheF&A
department.
c)Alldeposits:AlldepositsintheTB,whichareofrefundablenature,willhavetobe
broughtinasPrepaymentsinAP.
d)AllLoans:AllloanswithapaymentschedulewillhavetobebroughtinthroughAP
asinvoices.

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 6/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications

OracleApplicationsdoesnotprovideforaninterfaceforPaymentsinAPhenceall
invoicepaymentswillhavetobemademanually.F&Adepartmentwillhavetokeep
recordofchecknumbersforthecutoffdatechosen.

AccountsReceivable:

BasedontheTrialBalanceMappingalltheARtransactionswillberoutedthroughAR
asInvoicesandreceipts.Therearetwooptionsthatareavailableformigrating
invoices:

c)WithActualaccounting:InordertodothistheF&Adeptwillhavetoprovidethe
actualcreditaccountsforeachandeveryinvoicethatwillbeenteredinthesystem.
d)WithDummyaccounting:Thismethodhelpsustosavetimeaswewillbringinall
theinvoiceswithdummyaccountsandalltheactualaccountingwillbetakendirectly
toGeneralLedgerbutsubledgerbreakupofGLbalanceislostandbecomes
availableonlyfromthedatetransactionsareenteredlive.Thismethodis
recommendedonlyforauditedtransactions.

ThefollowingkindsoftransactionswillbeimportedintoAR:

e)Invoices:AlldebitbalanceswillbemigratedasInvoices.TheF&Adepartmentwill
havetoprovideInvoicewisebreakupofdebitbalancesinthespecifiedformats.This
formatwillincludedetailsofthesalespersonforeachinvoiceandtheCustomerPO
number.ThisinvoicewillbeentereddirectlyinARandwillnotberoutedthroughthe
ProjectsModule.
f)Debitbalances:Allcreditbalanceswillbebroughtintothesystemascredit
memos.TheF&Adepartmentwillhavetodecidewhetherthecreditbalancesagainst
eachcustomeraretobetreatedasdepositsorascreditmemos.
g)Alldeposits:AllcustomerdepositsintheTB,whichareofrefundablenature,will
havetobebroughtinasdepositsinAR.

Purchasing:

PurchaseOrders:
PurchasingisanoncriticalfunctioninZensarandthereforewedonotseethemeritin
bringingclosedPO'sintothesystem.InthecaseofopenPOsthefollowingoptions
areavailable:

1.BringonlynewPOsintoOracleApps
2.BringexistingPOsintoOracleApps.

Option1requiresnomigration.

Inoption2onlyopenPurchaseOrdersasonthe10thofAugust2001(Asclosetothe
golivedateaspossible)willbemigratedintothenewsystem.Forthisthefollowing
canbeconsideredasopenPurchaseorders:

a)POsopenforreceiving
b)POsopenforinvoicing

OnlyPOsopenforreceivingwillbeconsideredforMigration.Inthecaseofpartially
receivedPOs,boththePOanditsreceiptwillberecordedinthesystem.Allthe
invoices,whicharereceivedforPOsnotcreatedinOracleApps,willbematched
outsidethesystem.SinceinthecreationofnewPOstherewillbenewPOnumbers
generatedbythesystemitisnecessarythatthenewPOsaresenttothevarious
vendorsinformingthemaboutthechangeinPOnumbers.

Requisitionsandotherdocuments:

Fortransactionsason10/08/2001,wheretheStandardPOhasnotyetbeencreated
thefollowingwillhavetobeenteredmanually:

a)ApprovedPurchaseRequisitions
b)RequestsforQuotationsifany
c)ReceivedQuotationsifany

Alltypesofvalidcontracts,agreementsandAMCsason10/08/2001havetobe
enteredasPOs,oftypeBlanketPurchaseAgreement,ContractPurchase
AgreementorPlannedPurchaseOrderwhicheverapplicable.

AllthereleasesmadeagainstBlanketPurchaseAgreementandPlannedPurchase
Orderforwhichmaterialorservicehasnotbeenreceivedorhasbeenreceived
partiallywillbetreatedsimilartoanopenPO.

Projects:

ConversionProjects:

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 7/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications

Fewissuestobeconsideredonmigrationofprojectsdata:

ShouldwemigrateonlyNewProjectsortheOldProjectsalsoneedstobeentered?

Wecanentertheonlyopenprojects,whicharesupportedbyprojectswisetime
sheets

CostingofProjectsStandardorAverageCosting?

ConversionPurchasing:

AllStandardPurchaseOrdersason10/08/2001,againstwhichmaterialorservice
hasnotbeenreceivedorhasbeenreceivedpartially.

Belowisthewaythedatawillbemigrated:

AllthePurchasingrelatedtransactionswillbetransferredtothesystemmanually.

Reports:

PurchaseOrderDetailReportReportwilllistallthedetailsoftheP.Oenteredduring
theconversionprocess.

ConversionPayables:

AllVendorsandEmployeeswouldbedefinedintoOraclePayablesalongwiththe
relevantinformation,priortotheentryoftransactionrelateddata.

ThevendorbalancesintheLegacySystemason30/6/2001tobe100%reconciled
witheachcustomeracceptanceofaccountbalance.

Thecheckbookstockshouldbepreparedason30thJune01wehavetoenterit
intothesystemtogeneratethechecksfromOraclePayables.

Alloutstandingtransactionsi.e.Invoices,CreditMemo,DebitMemoetcand
unadjustedDeposits/Advancesasoncutoffdatewillbetransferredindetaili.e.on
transactionbytransactionbasis.

Invoiceswillbeenteredfortheoutstandingamount.

Alltheoutstandingcreditbalanceasonthecutoffdateagainstindividualemployees
tobeenteredasastandardinvoiceatdetaillevel.Thevarioustypesofoutstanding
creditbalanceagainsttheemployeescouldbeoneandallamongthefollowing:

TravelClaims
MedicalReimbursements
LTAReimbursementsetc.

Documentsequenceswouldbecreatedtoreflectthetransactionsenteredinthe
variousBatches.

Belowisthewaythedatawillbemigrated:

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 8/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications
AlltheoutstandingInvoices,CreditMemosandDebitMemoswillbeuploaded.

AlltheoutstandingPrepaymentswillthenbemanuallyentered.

AlltheclearingBankPaymentsasdiscussedearlierwillbethenmanuallyentered.

PostinginGL:

GLPostwillberunaftereverybatchisuploaded/manuallyenteredandapproved.The
respectiveaccountingentrieswouldbegeneratedonlyonGLpost.

Reports

InvoiceRegisterReportOnApprovingandrunningtheGLpostInvoiceRegister
reportforindividualBatchesasmentionedabovewillbegeneratedwhichwilldetailall
thetransactionsenteredduringtheconversionprocess.

PaymentRegisterReportOnmakingthePaymentaPaymentRegisterreport
wouldbegeneratedtoreflectthepaymentmadetoduringtheconversionprocess.

ConversionFixedAssets:

AllthecapitalisedAssetsason30/6/2001wouldbeenteredinOracleAssetsalong
withtheAccumulatedDepreciationReserveBalance.ThiscreationofAssetsinthe
FixedAssetsmodulewouldbedoneusingtheMassAdditionsfunctionality.

Whetherassetsretiredbefore30thJune01shouldwetake/uploaditintothe
system?tobeconfirmedwithVaijayanti.

Belowisthewaythedatawillbemigrated:

AllthecapitalisedAssetswouldbeuploadedintoFixedAssetswiththeCapitalised
andPostastheflag.

InoneuploadtheentireFixedAssetsregisterwouldbeuploadedintothemodulefor
furtherprocessing.Onthecompletionoftheuploadprocess,alltheAssetsuploaded
wouldbePosted.

OnpostingthesystemwillassignNewAssetNos.toalltheAssetslyingin
MassAdditions.

AlltheAssetswouldbeuploadedwiththeCurrentGrossValueoftheAssetalong
withtheLifetodateDepreciationReservebalanceandtheYeartodateDepreciation
ReserveBalance.

Forconversionpurpose,theDepreciationReserveshouldbesegregatedasfollows:

LifetodateDepreciationDepreciationReservefromthedateofcapitalisationtill
30/6/2001.

YeartodateDepreciationDepreciationReservefrom01042001till30062001.

TheSystemwillnotgenerateanyAccountingentryforDepreciationReserveasthe
samehasbeenmanuallyentered.Forfuturedepreciationrun,thesystemwill
generatetheDepreciationReserveaftertakingintocognizancealreadyentered
DepreciationReserveandpostthesametoGL.

Report:

ConversionAssetsReport:ThisreportwilllistalltheAssetsenteredduringthe
conversionprocessalongwiththeDepreciationreserve.

ConversionGeneralLedger:

AllmonthwiseTrialBalancesfromApril01toJune01tobeenteredinGLthisis
basicallywithaviewtofacilitateMISreporting.

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 9/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications

Allbudgetbalancesasonthecutoffdate.

OnpostingtheactualbalancesinGL,thesystemwillcomparetheActualBalance
againsttheBudgetedBalanceandwillreflecttheFundsavailable.Encumbrance
BudgetbalancefromthePurchasingmodulewillbetransferredtoGLwherethe
availablefundswillbecomparedafterdeductingtheactualbalanceandthe
encumberedamountfromthebudgetedbalance.

AlltheaccountbalancesenteredinGLwillbecomparedwiththevariousreports
availableinGL.Oncomparisonofthevariousaccountbalances,aTBfromOracle
GeneralLedgerwillbegeneratedandcomparedwiththeexistingTallyTBandon
reconcilingthesametheconversionexercisewillgetcompleted.

Reports:

AccountAnalysisReportThisreportwillreflectthebalanceagainstanyaccount
code.ThisreportwillbeusedtocomparetheTallyTBaccountbalancewiththeGL
AccountBalance.

TrialBalanceAdetailedTBwillbegeneratedtodothefinalcomparisonwiththeTB
fromtheexistingsystem.

6.DataformatsrequiredExcelformat

AllthedatatobeuploadedinthesystemshouldbeinMSExcelformatsonly.The
dataforindividualmodulesshouldbeinconformitywithInterfaceTablesinrespective
modules.

7.ManDayestimatesofdevelopmentofinterfaces

Wemayhavetodevelopsomeoftheinterfacesinhouseasitmaynotbeavailablein
theAppsormaybewehavetodevelopsomethecustomizedinterfaces.Wehaveto
estimatethemandaysrequiredforthispurposetherespectivepersonsresponsible
fordevelopingtheinterfacestogiveinputinthisregard.

8.Modulewiselistofstandardinterfacetablesinvariousmodules.

GeneralLedger:

GL_INTERFACE

Receivables:

LISTOFCUSTOMERINTERFACES:

RA_CUSTOMERS_INTERFACE
RA_CUSTOMER_PROFILES_INTERFACE
RA_CONTACT_PHONES_INTERFACE
RA_CUSTOMER_BANKS_INTERFACE
RA_CUST_PAY_METHOD_INTERFACE
AR_PAYMENTS_INTERFACE_ALL

LISTOFAUTOINVOICESINTERFACE:

RA_INTERFACE_LINES_ALL
RA_INTERFACE_DISTRIBUTIONS_ALL
RA_INTERFACE_SALESCREDITS_ALL

Payables:

LISTOFINVOICESINTERFACE:

AP_INVOICES_INTERFACE
AP_INVOICE_LINES_INTERFACE

LISTOFEXPENSEREPORTSINTERFACE:

AP_EXPENSE_REPORT_HEADERS_ALL
AP_EXPENSE_REPORT_LINES_ALL

FixedAssets:

FA_MASS_ADDITIONS

Purchasing:

Therearenostandardinterfacesavailableinthismodule.

RelatedArticlestoRead

Tutorial

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 10/11
3/11/2017 AboutOracleApps:Howtomigratedataintooracleapplications

le)

2008 AboutOracleApps ACompleteGuidetoOracleApplicationsProfessionals.| Contact|Aboutus.

AllarticlesarecopyrightedtoAboutOracleApps.

http://www.aboutoracleapps.com/2007/07/migrationstrategy.html 11/11