Learning to work with registers (1C: Accounting 8.3, edition 3.0)

2016-12-08T13:50:45+00:00

Dear readers, in this lesson I want to touch on an extremely important topic when working in 1C: Accounting 8.3 - Registers.

I’ll immediately show you with a small example why this is so important.

Let us have a payroll for January:

At the beginning of February, we create a payroll slip from the cash register and click the “Fill” button:

And we get the following:

But for January:

• Accrual of 50,000 rubles
• Personal income tax 6,500 rubles
• Total payable 43,500 rubles

Where did the error creep in? Something went wrong? Is it really possible to always enter the amount to be paid manually now?

An experienced accountant will immediately make a balance sheet for account 70:

And he will be even more bewildered, because according to the report, the same 43,500 are still due for payment! And where did the extra 5,000 rubles come from?

Moreover, such a situation (with any calculations) can happen both in the “troika” and in the “two”.

Today I will try to lift the veil of secrecy - why sometimes the program behaves so strangely. I will tell you how to find and fix the error in such cases. Towards the end of the article we will figure out where these 5,000 rubles came from.

So, let's go!

Learning to see registers

When posting documents, 1C:Accounting 8 makes entries to accounting accounts (DtKt button for any document):

It is on the basis of these transactions that all accounting reports are built: Account analysis, Account card, Balance sheet...

But there is a huge layer of data that is written by the program in parallel with the postings and is used for everything else: filling out KUDIR, a book of purchases and sales, regulated reporting... wages payable, finally

As you probably already guessed, this layer is called registers, here he is:

Now I will not go into details of the description of the registers themselves, so as not to confuse you even more.

Let me just say that it is simply vital for us to gradually learn to “see” movements in these registers in order to better understand and, when necessary, correct the behavior of the program.

Let's take a closer look at the "Salaries payable" register - it is this that makes sense for solving our problem with the extra 5,000:

We see two entries in this register made in the arrival, that is, in plus. If we scroll the screen to the right, we will see in the first line the amount to be paid “-6,500”, and in the second “50,000”.

The balance in this register -6,500 + 50,000 is equal to 43,500, which should be included in the document “Statement for payment from the cash register” when we click on the “Fill” button.

I repeat once again - the payment statement determines our wage arrears to the employee not according to account 70, but according to the “Salaries payable” register.

It turns out that we know that the salary to be paid is filled out based on this register, but even seeing the register entries we cannot understand what is wrong.

Most likely, we do not see the whole picture (maybe there are other records for this register) and some tool for analyzing the register, similar to accounting reports, suggests itself.

Learning to analyze registers

And there is such a tool, it's called " Universal report".

Go to the "Reports" section and select "Universal report":

Select the register type “Accumulation Register”, the “Salary Payable” register and click the “Generate” button:

It turned out not very informative:

This is because preliminary setup of the report is required, click the “Show settings” button and on the “Grouping” tab add the “Employee” field:

On the “Selections” tab we make a selection for our organization:

Click the "Generate" button:

Now this is more interesting. We see the balance to be paid to our employee is the same 48,500 rubles!

Go to the report settings again and add a new field “Recorder” to the “Indicators” tab:

We generate the report again:

Now we can clearly see that 5,000 appeared as a result of the operation (apparently entering balances) on December 31, 2014.

And we need to either change this operation or manually adjust the “Salaries payable” register and close these 5,000 rubles, for example, on December 31, 2015.

Let's go the second way. So, our task is to make sure that at the beginning of 2016 there is no debt to the employee in the “Salaries Payable” register.

This is done by manual operation.

Learning to adjust registers

Go to the "Operations" section and select "Operations entered manually":

We create a new operation at the end of 2015:

From the "More" menu, select "Select registers...":

Specify the "Salary to be paid" register and click OK:

Go to the register tab that appears and make an expense of 5,000 rubles:

By doing this, we are subtracting 5,000 rubles from the register per employee in order to reach zero by the beginning of 2016.

We carry out the operation and regenerate the universal report:

Everything worked out! We see that our manual operation dated December 31, 2015 brought the balance to zero and the salary payable after accrual is equal to the expected 43,500.

Amazing. And now we will check this in the payment statement.

But first I want to draw your attention to another important point:

Please note that the balances at the beginning and at the end for the “Employee” group show nonsense. This is not a mistake, it is a nuance that needs to be taken into account related to the architectural features of 1c.

Remember. In the event that a universal report is displayed with detail down to the document (registrar), the balances by grouping will show nonsense.

If we require balances by employee grouping, we must first remove the “Registrar” indicator we added from the settings.

We decided to somehow restore order in the configuration of UT version 11. And there... The balances of goods do not match the balances of organizations (several organizations are used), and with consignments of goods they are not at all close, and even commission trade is used along with regular trade. In short, everything is so neglected that it’s easier to start from scratch, BUT... You can’t start from scratch - there’s a connection with enterprise accounting 3.0 (directories, documents), and there the reporting has already been submitted. We decided to put things in order in the accounting department separately, and separately in the accounting department. Specifically for UT, we decided: we zero everything related to goods (goods in the warehouse, goods of organizations, consignments of goods of organizations, plus registers associated with the commission), then we make a fictitious receipt (including for the commission), and we correct mutual settlements by adjusting mutual settlements. At first I started writing processing for specific registers, while I was writing, I thought about writing a universal one in about the same amount of time, but it would be suitable for all registers, so as not to have to rewrite it ten times later. It should also be suitable for Retail 2, Complex and other configurations for managed forms. Tested on UT11.

How to use. First, we manually create an empty “register adjustment” document, set the date and time (I set 23:59:59 at the end of the quarter), the register balances will be taken exactly to this position (document position), in general, from the document we only need the position and needed. Then we select which registers we need to zero and click “Generate”. We open the adjustment, look, check the registers using reports and/or a universal report. Balances are closed for all dimensions and for all resources. Also in the form there is a selection by organization and warehouse (a throwback from the original version, but it works), I didn’t add other selections (since I didn’t need it at all), whoever needs it, you can add it yourself, everything is clearly written in the module, and not I started using it because, for example, if you make a selection by organization, then for the register “Goods of organizations” the selection will work, but for the register “Goods in warehouses” it will not (there is no such measurement), so I zeroed it without selection.

Some time has passed...

A new version has been released, now processing has learned (previously it gave an error - that is, it actually worked only with balance registers) to reverse movements in the circulating accumulation register. Moreover, the movements are reversed, i.e. if you look at the register, say, “Sales” in UT11, then after reversal the sales will not be shown at all, i.e. as if there were no sales at all - the turnover as a whole for the period will be empty. Once again - it turns out, for example, we had sales for the period January 1-30, on the 31st I make a reversal, after that if I look at the report from 1 to 30 - I will see sales, from 31 to 31 - I will see reversal movements, from 1- 31 - will show empty. For example, I reversed the movements of the “Cash” register in UT11 and Retail 2.2 when I had to put the “Cash Office” in order (50 account, who knows).

Yes, I forgot to say, the “Start Date” field has appeared - it is used to set the start date of the period for turnover registers (for balances, of course, it does not apply), the document position “Register Adjustment” is used as the end date of the period (for turnover registers) - i.e. . as for the balance register (balances are removed to the document position). For turnover registers, the “Start Date” may remain empty - in this case, it is perceived as the earliest date that can exist, and for the turnover register it will mean that all movements from the beginning of accounting to the position of the “Register Adjustment” document are reversed.

Good news - the cost in points has decreased.

There are situations when, when calculating a service using the “According to meter readings” calculation method, one reading is entered, and when the service is charged, the expense turns out to be completely different. Such situations may arise in cases where the user manually changes data in the “Entering meter readings” and “Charging services” documents. Let's look at an example.

• Let’s enter the meter readings for the “Hot water supply” service for January:

• Let's charge the service:

In this case, the calculation was correct.

To store consumption by metering devices, the accumulation register “Calculation of metering devices” is used. Let’s open this register using the menu “Operations – Accumulation registers – Calculation of metering devices”. The register can also be opened from the documents “Entering meter readings” or “Accruing services” by clicking the “Go – Calculation of metering devices” button.

Let’s set up a selection by personal account and service in the accumulation register:

The register shows that the expense in the “Accrual of Services” document for the month of January corresponds to the reading entered in the “Entering Meter Readings” document for the same month. For correct calculation, the consumption must correspond to the entered readings in each month.

• Let’s open the document “Entering meter readings” for January and change the manually entered reading:

At the same time, we will not refill the “Accrual of Services” document for January.

• Let's enter the meter readings for February:

• Let's charge the service for February:

It can be seen that the document included an incorrect expense. Let’s open the accumulation register “Calculation of metering devices” and set the selection by personal account and service:

The register shows that the entered readings and expenses do not correspond to each other.

In this example, you can, of course, refill and re-post the “Accrual of Services” documents, but this is a simple example, in reality there can be a lot of documents, refilling can only worsen the situation.

In this case, it is necessary to use the “AOB_Resetting the Balances of Accumulation Registers” processing.

NOTE: Before using processing, it is recommended to make a backup copy of the infobase.

To correct this situation, we will perform the following steps:

1. In the “1C:Enterprise” mode, open the processing “AOB_Resetting the Balances of Accumulation Registers” using the menu “File – Open”;

2. In the “Movement document” field, select the document “Accrual of services” for January.

NOTE: the document that precedes the document in which you need to obtain the correct data is selected. In this case, we will correct the document “Accrual of services” for February, therefore, the document “Accrual of services” for January is selected as the movement document.

3. In the “Reset register” field, select the “Calculation of metering devices” register:

NOTE: Residues may be selected during processing. Selection criteria are configured in the table.

4. Click the “Run” button.
When you press this button, the data in the accumulation register “Calculation of metering devices” will not change visually, but the balances will be reset to zero.

5. Let’s refill the document “Accrual of services” for February:

It can be seen that after using the processing, the calculation became correct.

Incorrect values ​​in the accumulation register “Calculation of metering devices” can also be formed as a result of manual changes in data in the “Accrual of services” document, or the entry of several documents “Entering meter readings” or “Accrual of services” for the period.