Now add a building block that may not be obvious from the first sight. It will be the Financial transactions accumulation register.

Questions, "What is a register? What is its purpose?" immediately arise.

Below you will find a simple explanation.

According to project requirements, the application should not only be capable of storing a list of friends and tracking events. It also should be capable of keeping records of financial transactions. At a minimum, it should keep records of cash flow and provide simple financial reports.

Registration of various events related to money income and outcome will be implemented by using configuration objects, named Documents. Later, you will add a couple of documents to the applied solution. 

Together with registering money incomes and outcomes, it is required to create some reports, demonstratively displaying what happens to finances. These reports can be created using data that is contained in user input documents. These documents reflect actual receipts and expenditures of money. However, imagine that in a month (or a year), for example, you decide to supplement your financial records with new documents or functionally expand existing ones. 

Making configuration changes, as you have already seen, is a simple task. However, what will happen with reports in this case? It might turn out that financial reports that you created previously will not work properly, because they use only income and outgoing records from the old documents as the data source. This means that you might have to rebuild all related to these data reports. Live applied solutions usually contain a large number of reports. 

To avoid this work, and a large number of errors that may become a result of this alteration, 1C:Enterprise uses the following development methodology: 

To store data regarding the activity of accounting subjects, finances, for example, configuration objects named Registers are used. Documents that reflect business activities, record data in these registers. Reports, then, use these registers as data sources.

As a result, you have a separated structure. On one hand, once there is a complete set of registers, it is easy to create required reports that will demonstratively display information contained in these registers. On the other hand, when a new type of document appears in the applied solution, you only need to add the correct algorithm to place data in registers. This methodology guarantees that previously created reports will not require any alterations and will display correct data.

Figure 5-1. The DocumentsRegistersReports schema

So, for meeting the project requirements of this tutorial, it is enough to create only one accumulation register, name it Financial transactions. Where the application will store data on how much and how often a user receives and spends money.

Accumulation registers are located in the Accumulation registers branch of the Configuration object tree. Add a new accumulation register.

Figure 5-2. Adding an accumulation register

Name this register Financial transactions and include it to Finances subsystem. Then click the Data tab.

Figure 5-3. The Financial transactions accumulation register

Now add dimensions, resources, and attributes to this register.

Figure 5-4. The Data tab of the accumulation register

Resources are the data that you are going to obtain from the register. For Financial transactions, you need to know the number of transactions. Hence, only one resource of Number type named Amount is required.

Dimensions refer to slices of information that is required to be obtained from the register. It is unlikely that you will be interested only in the overall balance. For example, to create a finance flowchart you may be interested in which events or people bring you most of the money, or which consume the most. To track this, you will need to have two dimensions Event and Person

Attributes keep additional information that accompanies each record in the register. For Financial transactions, you will not use attributes. However, nothing prevents you from adding them to the register in the future and then keeping any auxiliary information there.

Add mentioned above dimension and resources. To add them, right-click the Dimensions and the Resources groups of the accumulation register, and in the context menu click Add  (Ins).

Now, add a dimension.

Figure 5-5. Adding a dimension

In the Properties window, define that the Name of the new dimension is Event, and its Type is CatalogRef.Events.

Figure 5-6. The Event dimension properties

Add a second dimension, named Person. Type is CatalogRef.People.

Figure 5-7. The Person dimension properties

Now add the Amount resource. Accept default values of Type and Length, and adjust only Precision, increase it from 0 to 2.

Figure 5-8. The Amount resource properties

As a result, the Financial transactions accumulation register will look as follows:

Figure 5-9. The Financial transactions register

Next page: Documents