Using their ETL tool, Yardi has the ability to natively go into several software packages and extract data. Generally speaking, Yardi can electronically convert from any system that has the ability to produce certain source reports directly to Excel. The Excel files are an intermediate step between the initial data extract from the source system and the import of the file into Yardi. Once the data has been saved as .xls file, then the user can manipulate the extract further. Manipulation examples would include tasks like formatting dates a certain way, adding constants, and deleting NULL values. Once the .xls file is formatted, it will be saved as a .csv file and imported into Yardi.
.CSV stands for comma separated value. If viewed in a text editor, such as Notepad or Wordpad, the information comes across as a string of data separated by commas. This is relevant to Yardi, because the Yardi scripting engine was originally written to only import .csv files. Although Yardi was later updated to include .xml files as well, most companies still use .csv, because it is easy to save and view the data in Excel.
Firstly, it’s important to realize that the old system will store data differently than the new: they are different systems. So, in order to electronically convert the data, the fields in the old system must be mapped to the fields in new system. Most users are going to need help doing this, because they are familiar with the old system’s schemaystem, but not necessarily with Yardi’s. It’s best to work backwards from Yardi’s schema to the source system’s schema. This is due to Yardi being the ‘catcher’ of the data - the source system being the ‘pitcher.’ The new software schema and data rules are what will dictate during the mapping process. Begin with the mandatory columns for a table in Yardi and work backwards to an equivalent column in the source database. If a column is in Yardi but not in the source database, then this is considered a ‘gap’. Gaps can be ignored, or the relevant data can be compiled outside of the source database and entered/imported into Yardi.
Yes - because there is no validation of the tenant balance or importing of transactions that needs to occur. The data is actually now residing both inside and outside of the system. It’s inside as an attachment, so there is link to the particular object that for which history is being stored. It’s outside in that it does not hit the Trans table; therefore, it is not technically a transaction. One down side to the data not hitting the Trans table is there’s no drill down available on this stored history; it’s just sitting there as a text object.
Yes. The ability does exist, but you must be able to create custom import scripts. To do this, you need knowledge of:
After you have written the custom import scripts once or twice, you will be able to adapt that knowledge into importing into any Yardi table.