Implementation Standards

This page gives some suggested standards for implementing FDC applications. Please feel free to adapt them for your own circumstances.

Software Standard Justification
Installation FDC software should be installed locally on client PCs. The Workstation Setup program makes it easy to install software on clients PCs. This also follows the general practice of installing software such as MS Office locally. It would be possible to install the software on a server but some client configuration would still be required and this would not be automated by the Workstation Setup program.
Databases
Database Names Database names should be 8 characters or less. Even some very recent versions of FDC have problems with database names longer than 8 characters.
Database Folder Names Database names and databases folder names and should be the same e.g. a database called MODEL should have a path like C:\Comshare\FDC\Model. Makes it easy to related databases and folders.
User folders User folders should be on client PCs. Clearly separates data for different users and saves cluttering your server with RPT files.
General Application Setup
Transmit in Base Currency Off (Unchecked) Transmitting in local currencies allows exchanges rates to be changed at head office after subsidiaries have transmitted data.
Decimal Precision Exchanges Rates 8 FDC stores exchange rates as multipliers so the more decimal places the smaller any rounding errors. These can be noticeable with currencies such as Italian Lira where 3000 ITL/GBP would be saved as 0.00033333. You may want to enter large exchange rates in thousands e.g. input 3000 ITL/GBP as 3.000.
Unit ID and Schedule Line ID Widths 4 In the absence of existing codes short numeric ids for are easier to remember and work with.
Schedule Versions The following basic schedule versions are suggested:
B  Budget
F  Forecast
M  Management Actuals
P  Plan
S  Statutory Actuals
Not to using A for actuals helps clearly differentiate management and statutory actuals.
Avoid version letters that can be confused with numbers e.g. I, O, Q and Z. If the version letter can be confused with a number it makes the schedule id more difficult to read e.g. I1119.
Accounting Periods
Period 14 Do not use period 14 Period 14 is generally used for final adjustments. However, we find that using it is generally more trouble than it is worth.
Currencies
Currency Codes Use SWIFT currency codes. Using standard codes make systems easier to understand and quicker to use. See the Design Guide for a list of common SWIFT codes.
Rate Codes Delete K  Historical/Auto Prior Mo. The K rates code is intended to pull forward balance from the prior month. However, FDC works best with YTD values and it is best to avoid using this code.
Delete M  Fixed Historical Rate The M rates code can be used for translating historic data however it generally does not meet companies accounting requirements for historic data.
Schedules
Schedules Id Use the following ranges for schedule ids:
v1xxx Profit and Loss schedules
v2xxx Balance Sheet schedules
v3xxx Cash Flow schedules
v4xxx Statistical schedules
Make it easy to identity the type of data in a schedule from its id. These ranges fairly standard among people implementing FDC.
Number schedules in the order they are consolidated/input. Make it easier for users to input data and makes building schedule packages simpler.
Schedules with same number should have exactly the same layout. Makes it easier to understand applications and is required by some Comshare Programs e.g. General View Builder.
Schedule Descriptions Schedule descriptions should be title case. The first letter of every word should be a capital except for short words such as and, in and of. e.g. Profit and Loss Account
Lines Ids If there are no existing codes start at line 20 and increment line numbers by 20. This convention allows enough lines (10,000 / 20 = 500 the maximum lines per schedules is about 400) and gives plenty of room for inserting new lines.
Number lines in ascending order FDC does not require this but it makes it a lot easier to find a line on a long schedule if the line ids are numbered in ascending order.
Only use numeric ids. Alpha lines ids seem like a great ideal but in reality are incredibly irritating because they are generally longer and more difficult to structure than numeric line ids.
Never reuse any existing ids. Mark unused ids as redundant and use a completely new code. Reusing exist codes in any system always causes confusion and should be avoided at all costs.
Line Description Data line descriptions should start with a capital letter and then be lower case. The only exceptions to this are acronyms such as ACT, GST and VAT which should be upper case.
Abbreviate descriptions by removing sylabuls and not vowels. Make abbreviations easier to recognise and use as they can be pronounced. e.g Tot not Ttl.
Use the following standard abbreviations in line descriptions e.g.:
Exp  Expense
Inc Income
Tot  Total
Any standard is better than no standard.
Formula Numbers Use the following ranges for schedule formula:
100-149 P&L Cross check formula
150-199 P&L Generate formula
200-249 BS Cross check formula
250-299 BS Generate formula
300-349 CF Cross check formula
350-999 Other formula
This numbering system makes to easier to find the formula which relate to schedules.
Leave gaps between Schedule Formula numbers e.g. number formulas 2, 4, 6 etc. Schedule formula are calculated in number order and therefore you may need to insert formula in a specific places so its results can be used by higher numbered formula.
Categories Try not to use Categories. See the Design Guide for a detailed discussion of categories.
Structures
Unit Ids Use a standard for numbering units e.g.:
1000-2999 Reporting units
3000-3999 Product consolidation units
4000-4999 Geographic consolidation units
Makes it easy to distingush different types of units.
Use only numeric ids. See Unit ID and Schedule Line ID Widths standard.
Never reuse any existing unit ids. Mark unused ids as shut and use a completely new code. Reusing unit ids always causes problems in the long run.