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 data source. This means that you might have to rebuild all related to this 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 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 1-54. The Documents–Registers–Reports schema
So, for meeting 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 1-55. Adding an accumulation register
Name this register Financial transactions and include it to Finances subsystem. Then click the Data tab.
Figure 1-56. The Financial transactions accumulation register
Now add dimensions, resources, and attributes to this register.
Figure 1-57. 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 amount 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 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 1-58. Adding a dimension
In the Properties window, define that the Name of the new dimension is Event, and its Type is CatalogRef.Events.
Figure 1-59. The Event dimension properties
Add a second dimension, named Person. Type is CatalogRef.People.
Figure 1-60. 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 1-61. The Amount resource properties
As a result, the Financial transactions accumulation register will look as follows:
Figure 1-62. The Financial transactions register