Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
--> If LOV is editable by the user, provide a significant name to List Name under object properties. --> All the measure objects should use aggregate functions. This will ensure that the aggregation happens at the database for the selected dimensions. --> Avoid having dupicate Object names (in different classes). --> Format for objects of type Numeric, Currency & Date should be defined. Predefined Conditions --> Give description for the use of each pre-defined condition. --> If Condition is resulting in a Prompt, make sure associated Dimension Object has LOV. --> Time dimension related predefined conditions such as Current year, Current month,Previous year,Last (x) weeks, etc can be defined to make it easy for scheduling daily/weekly/period based reports. Tables --> Alias Tables should be named with proper functional use. --> Arrange the tables in the Structure as per Business/Functional logic. This helps other Universe users in understanding. --> It is always best to bring the tables without joins and build them manually. It helps the designer to understand the intricacies of the model. Joins & Context --> AVOID keeping hanging (not joined) tables in the structure. --> AVOID having joins that are not part of any context. --> Give proper functional naming to the context for easy identification. --> AVOID having 1:1 joins. Import/Export --> Make sure of the path for Import, which usually is always in the Business Objects' Universe folder. --> LOCK the universe if Administrator/Designer does not want any user to Import/Export. --> DO "Integrity Check" before Exporting the Universe. --> Good to have correct folder structure , so that you can have a secured environment. --> Once exported, never delete any objects from the universe without doing an impact analysis on the object usage Migration --> Better take a backup of the repository and then proceed with the migration in BO5.X and BO6.X Version
report tab explaining the report --> Use the Report properties to give more information about the report Dataproviders --> Each Dataprovider should be given a name that reflects the usage of the data its going to fetch. --> Select Objects in such a fashion that the resulting SQL gives a hierarchial order of Tables. This helps to achieve SQL Optimisation. --> Avoid bringing lot of data into the report which will unnecessarily slow down the report performance. Report Variables --> Follow the naming convention of "var_" as prefix to each report level variable. This helps to identify Report Variables different from Universe Objects. --> Each variable that carries a calculation involving division should have IF <Denominator> <> 0 THEN <Object>. This avoids display of #DIV/0 errors in the report. --> Avoid having deep nested calculations which will slow down the performance of the report. Report Structure --> Make use of Report Templates when having most of the report with similar structures. This makes the work to move faster and consistant across. Report Formats --> All the reports should have page layout set in a printable manner. (Landscape/Portrait, Fit in 1 page wide or/and 1 page tall are different options). --> All the reports should have page numbers in the footer. --> All the reports should have Last Refreshed Timestamp in the header or footer. --> All the above can be standardized by using templates Report CELL Formats --> All Numeric should be given Number format as per the language Eg. For German #.##00 for English #,##00. --> Number cells should have a Right Alignment while Text cells should have Left Alignment. --> Cell showing Percentage should carry the % text (either Column Header or in each cell). --> Indenting should ALWAYS be done using the Indenting Tool and NOT by using " ".