home » Production » Accumulation register, sales calculations. Scheme for filling out the purchase book and sales book

Accumulation register, sales calculations. Scheme for filling out the purchase book and sales book

a) The type of value Goods is formed by Sales, the Contract dimension is empty.
1) receipt – goes into the sales book, tab “On sales”
2) consumption
b) Type of value Advance
1) receipt – is formed by an invoice for advance payment
2) expense – formed by the sales book, “Advance” tab

Accumulation register “VAT on advances”

1) receipt – generated by the document “Invoice” for advance payment, or “Entering initial VAT balances”,
2) expense – generated by the document “Creating a purchase book”, tab “Advances”.

Buyer's advance document

for example, Payment order incoming
generates income according to the accumulation register “Calculation on sales (accounting)” indicating the payment account (62.01, 62.02)

Document "Invoice" for advance payment

generates income according to the accumulation register “VAT accrued”, the “Type of value” dimension is Advance, the “Contract” dimension is filled in. The amount is equal to the amount of the document including VAT.
forms, incl. posting BU 76.AV – 68.02 for the amount of VAT.

Document “Sales of goods and services”

generates expenses according to the register "Calculation on sales (accounting)" and the accumulation register "VAT accrued", the dimension "Type of value" - Product, the dimension "Contract" is not filled in. For the amount of the document, which may be less than the advance payment.

Document “Receipt of goods and services”

generates income according to the “VAT presented” register and the “Acquisition settlement (accounting)” register.

Document “Creating a purchase book”

The “VAT deduction on purchased valuables” tab is filled in with the balances from the “VAT presented” register, without selecting according to the contract.
tab “Deduction of VAT from advances received” - is filled in with the balances as of the date of the document in the register “VAT from advances”, “Type of value” - advances received, in terms of closing (!) the register “Calculation on sales (accounting)”, i.e. e. turnover on arrival. This is where errors often occur.
generates the “VAT claimed” expense
generates turnover according to the “VAT Purchases” register
generates the expense for “VAT on advances”

Document “Creating a sales book”

The “On Sales” tab is filled in with the “VAT accrued” balances, where the type of value is Product. No contract selection.
tab “From advances” - filled in with the balance “VAT accrued”, where the type of value is Advances.
The “Recovery for advances” tab is filled in according to the balances of the “VAT on advances” register and the balances of “Purchase settlements (AC)”. In terms of the positive difference of the second minus the first register. In terms of analytics Invoice (in the VAT register on advances)<->Document (accounts for acquisition in the register).
generates the expense for “VAT accrued”, type of value Product
generates turnover according to the “VAT Sales” register
generates the expense for “VAT accrued”, type of value Advance

By comparing the request to 62.02. and 62.32 (analytics Subconto1, Subconto2), DO for the period and all posted documents “Creating a purchase book”, tab “Advance” (analytics Counterparty, Agreement), amount with VAT - you can identify errors in the purchase book.

To use this report correctly and understand why it is needed, it is recommended that you read its continuation.

In the configurations “Complex Automation 1.1”, “Manufacturing Enterprise Management 1.3”, actual accounting of mutual settlements with suppliers and customers is carried out not on the “Cost Accounting” accounting register (roughly speaking, on the chart of accounts), but on special accumulation registers that provide deeper detail and optimized access.

Almost all automation of document processing for settlements with suppliers and customers is based on data from these registers, and the accounting register only reflects the final synthetic results in the form of postings. For this reason, it is advisable to close control activities related to checking the correctness of mutual settlements to these registers, and not to the accounting and posting register.

However, if there is a standard set of accounting reports for the accounting register (turnover balance sheet, account analysis, etc.), then there is not a single standard report that deciphers the accumulation registers in question in the configurations.

For this purpose, you can use standard universal reports, but for a number of reasons this is inconvenient:

lack of connection of the name of the report (item in the menu) to the nature of the actions performed;
problems with setting access rights;
In the register "Calculations for sales" balances and turnovers are entered "inside out", with a "minus" sign.
lack of support for properties and categories in a universal report based on SKD, lack of composite groupings in a report based on the “report builder”;
forced separate settings for checking settlements with suppliers and customers (since different registers).

In connection with the above circumstances, using the universal report engine on the access control system, this report was developed, devoid of the above-described shortcomings.

The report is built in the form of a simple statement that collects balances and turnover from both registers. The location of data in a particular register can be determined/selected by the value of the “Type of settlements” field - “By acquisition” or “By sale”. The initial balance, income, expense, and final balance of the amount in the currency of regulated accounting and in the currency of mutual settlements are displayed. Income corresponds to debit, expense to credit. An example of the generated report is shown in the figure.

Taking into account Section 4 of this report, a number of control measures are proposed. Before executing them, it is necessary to restore the sequence of mutual settlements.

1. Checking the compliance of the register used with the type of agreement.

Set the selection to the position according to the figures, leave the rest of the settings at default. Generate a report first for option a), then for b).

The report should show an empty result. Any settlement node displayed with these settings is incorrect in that the contract type does not correspond to the register. For example, an agreement with a supplier, and a register for settlements with customers.

The transcript from the recorder will show the documents that generated erroneous movements. There are probably incorrectly executed adjustments to register entries, or there is a result of incorrect automated filling of documents during exchanges and downloads (during the process, the data was not verified by document forms).

2. Checking the presence of contracts of a certain type on the appropriate accounts for mutual settlements.

This is done by setting up selections approximately as follows:

Counterparty agreement. Type of agreement = "With buyer". Score not in a group from the list: 62, 76.06

Counterparty agreement. Type of agreement = "With supplier". Score not in a group from the list: 60, 76.05

As a result, the generated report will show which settlement nodes have a form that does not correspond to the purpose of the accounting account. The transcript from the recorder will show the documents that generated erroneous movements. However, it is more expedient to perform this check using the accounting report “Analysis of subconto” (for the subconto Counterparties, Contracts), setting it up by analogy.

3. Checking the equality of the currency of mutual settlements and the currency of regulated accounting for contracts for which settlements are made in rubles.

Set the selection to the state as shown in the figure. The rest of the settings are default. Generate a report.

The report should show an empty result. Any node displayed with these settings is erroneous in that when making ruble payments under an agreement, its total turnover in the currency of mutual settlements is not equal to the turnover in the currency of regulated accounting.

The transcript from the recorder will show the documents that generated erroneous movements. Probably:

in payment documents in the amount by currency reg. accounting and the currency of mutual settlements (in the form of a document - on the left and on the right) there are different values, or the exchange rate is not equal;
debt adjustments were made incorrectly (with the same problem - in the tabular parts there are 3 columns with amounts, for ruble contracts they should be equal);
with manual accounting using settlement documents, an attempt to repay a debt / offset an advance payment, the balance of which is not available at the time of the document.
There are incorrectly executed adjustments to register entries.

Unfortunately, balances under currency contracts and contracts in conventional units cannot be checked in this way, due to the fact that the reconciled amounts, by definition, are in different currencies.

4. Checking the balances of mutual settlements for the correct choice of the debt/advance subaccount and the presence of a counter balance on them.

Set the settings according to the following plan:

Cross table, Row groupings: Contract of the counterparty, Column groupings: Check, Fields: Any remainder (con.) (remove groups and extra fields). Selection: Score in the group from the list: 60, 62.

The report should display data that needs to be visually inspected for the following:

a) The balances for each subaccount must have the corresponding sign (60.01, 60.21, 60.31, 62.02, 62.22, 62.32 - negative, 60.02, 60.22, 60.32, 62.01, 62.21, 62.32 - positive). It is highly recommended to color this conditional design in order to quickly identify errors.

b) Under one agreement there should not be counter balances on different subaccounts of the same group account (60.01 / 60.02), which means that there is both an advance and a debt.

The figure shows error options a) and b)

If accounting for transactions is enabled on the contract, then carry out exactly the same check in the private transcript of the contract in the “Transaction” field (double click - decrypt - Transaction): for each transaction there should only be either an advance or a debt, while on the contract itself in In general, a counter balance may be present.

In the mass case of accounting for transactions, you can apply an improved setting: set the “Transaction” field in the line groupings, and the “Counterparty Agreement” condition in the selection.

You can also decipher any line up to the document in the context of which the advance and debt are included, which can be useful if manual accounting is carried out on the agreement based on settlement documents with any logic that does not comply with the FIFO principle.

5. Checking the correctness of automatic accounting based on settlement documents (according to the FIFO principle).

It is advisable to carry out this control event selectively, because otherwise, the amount of data that needs to be analyzed visually may be too large.

As a selection, you can use a counterparty (agreement) for which errors were identified in control measure No. 3, or a selection of the type Agreement.News on settlement documents = Yes. It is also advisable to select only one account group (60 or 62, or 76.05, or 76.06)

Set the remaining settings according to the figure:

Check the received reporting data visually for the following:

a) Within each grouping of an account, all initial balances must be on the first documents (or absent), and ending balances must be on the last ones (or absent). That is, compliance with the FIFO principle is visually verified.

b) The balances in the context of documents under one agreement must have the same sign (plus or minus) and be either in the debt account or in the advance account (for 76.xx - simply have the same sign). With the exception if accounting is carried out in the context of transactions, or with special logic - manually according to settlement documents.

If accounting under the agreement is carried out in the context of transactions, then add “Transaction” to the settings, in the grouping of lines, above “Document”. If manual accounting is carried out using settlement documents, then check according to the logic that is accepted in your organization for this agreement.

Each document in this report is not a registrar, but an analytics for storing balances. You can decipher any of them to the registrar in order to check which documents and when the advance was read out (the debt was repaid) by group.

Regular implementation of these control measures will minimize methodological and technical errors in accounting for mutual settlements with suppliers and customers, and ensure compliance of the accounting register data with the accumulation registers.

Description of the mechanism.

The following registers are involved in recording data on mutual settlements with suppliers:

Accounting register

Self-supporting

Accumulation registers

Mutual settlements with counterparties
Mutual settlements with counterparties using settlement documents
Acquisition calculations (accounting)

To be able to control the payment of each specific invoice, the contract card contains the requisite - " According to documents of settlements with counterparties".Maintaining mutual settlements according to settlement documents allows you to control the timing of payments and payment for specific supplies, track receivables by debt terms. Setting this flag indicates that in the documents involved in accounting for mutual settlements with the counterparty, you will be given the opportunity to select a settlement document:

In payment documents in the tabular section " Payment decryption"in addition to the agreement and transaction (order), you can specify information about the settlement document (shipment document, receipt) for which payment should be recorded. If the settlement document is not specified, the program will consider this payment as an advance payment.
A tabular section has been added to all procurement documents that affect mutual settlements ("Receipt of goods and services", etc.) Prepayment" ("Documents of settlements with counterparties") to indicate information about the payment document with which the payment was made, the amount of mutual settlements and the amount in the currency of regulated accounting. If the settlement document is not specified, the program considers that a debt is being formed to the counterparty under this agreement.

There is no “settlement document” analytics in the accounting journal of transactions, however, when posting a delivery or payment document, the system will generate transactions taking into account the settlement documents and based on information about balances in management registers.

Settlement documents are determined by the register "Mutual settlements according to settlement documents" if the contract has the "According to settlement documents with the counterparty" attribute, if this checkbox is not checked, the settlement documents will be determined by the register "Settlements for acquisition (accounting)".

OPTION 1: The “According to documents of settlements with the counterparty” attribute is not set

Payment documents will be determined by the register "Acquisition settlements (accounting)"

When posting a payment document:

If the register balances are negative(settlement documents are receipt documents - there is a debt to the counterparty) - then the system will select as settlement documents - receipts available on balances.

If you look at SALT - the loan balance is 60.01 - 8000 rubles

Payment is made in the amount of 9,000 rubles

Direction of movement	Registrar	Calculation document		Payment account
	Payment 1	Admission 1	Treaty 1
	Payment 1	Admission 2	Treaty 1
	Payment 1	Payment 1	Treaty 1

According to the accounting system - debit balance 60.02 - 1000 rubles

If the residuals are positive- i.e. under this agreement there is an advance

If you look at SALT - the balance on Dt is 60.02

Then the payment document itself will become a settlement document - for the entire amount paid.

It became - after payment for 9000

2. When conducting admission

If the register balances are positive(settlement documents are payment documents - there is an advance payment under the contract)

If you look at SALT - the debit balance is 60.02 - 8000 rubles

Materials arrived in the amount of 9,000 rubles

In ex. The movement register will be as follows:

Direction of movement	Registrar	Calculation document		Payment account
	Admission 1	Payment 1	Treaty 1
	Admission 1	Payment 2	Treaty 1
	Admission 1	Admission 1	Treaty 1

And the remainder will already look like this:

According to the accounting system - the balance according to Kt 60.01 is 1000 rubles

If the balances are negative- i.e. there is a debt under this agreement

If you look at SALT - the balance according to Kt 60.01

Then the delivery document itself will become a settlement document - for the entire amount of receipt.

It became - after delivery of 9000

OPTION 2: The “According to documents of settlements with the counterparty” checkbox is selected.

Calculation documents are entered manually. However, when posting a document, the system will still search for the settlement document - based on the register "Mutual settlements with counterparties according to settlement documents" and if the settlement document is specified incorrectly, it will generate an error.

Rules for selecting settlement documents

When filling out the “Settlement Document” details in mutual settlement documents, the following rules must be taken into account:

The date of the settlement document (registrar) must be later than the date of the settlement document - although the system allows you to select any document as a settlement document, including the date of which is significantly greater than the date of the registrar - the system will generate an error when done.
In mutual settlement documents, it is mandatory to fill out accounting accounts. Otherwise, the system will not be able to correctly close the calculation document.
The registrar and the settlement document must be carried out according to accounting.

To check the correctness of the calculation documents, you can look at the movements in the “Purchase settlements (accounting)” register. In particular, the value of the resource "Accounting amount" must be equal to the value of the resource "Amount of mutual settlements" taking into account the document exchange rate. If the amount is accounting accounting is less than the amount of mutual settlements - this means that according to this settlement document, the unclosed balance is less than the amount allocated to it. You must specify another settlement document, or split the amount into several settlement documents.

“Double” balances under the agreement are also unacceptable - if mutual settlements are carried out “under the agreement as a whole.” Those. It is unacceptable for delivery and payment settlement documents to be open at the same time. If the contract is carried out “according to orders” - within the framework of the contract there can be both an advance and a debt - but for different orders - there should not be “double” balances within the same order.

The task of any accounting system is to store and promptly display information for the user, i.e. The goal of any system design is to promptly provide the user with a report. With the help of the data obtained, as a rule, management decisions are made at enterprises.

Let's assume that we have 1000 different documents: receipt of goods, write-off, return, sale, etc. And each of the documents changes the quantity of a certain product in the warehouse. To get information about the current quantity in the warehouse, you need to go through everything: some increase the quantity of goods, some decrease, some can increase or decrease. And if it is also necessary to take into account the warehouse, the organization?.. Such a system is very resource-intensive.

To simplify this process, 1C developers came up with special configuration objects. They are used for the convenience of storing and retrieving information; in 1C 8.3 and 8.2 all kinds of registers are used; in this article we will talk specifically about Accumulation registers.

The accumulation register itself is a table with information that collects all movements (receipts/write-offs or turnover) of certain documents. Let's look at what the movement table looks like using the example of a typical accumulation register “Goods in warehouses” in the “Trade Management 10.3” configuration:

Here we see that 1C “Sales” documents reduce the quantity of a certain product in a certain storage location, and receipt documents, on the contrary, increase the quantity. As a result, we get an overall picture in which we can clearly see what, when and in what quantity was received (written off) according to accounting. It is much more convenient to build a report using such a table.

Accumulation register in the configurator

What is an accumulation register from the point of view of configuration development? Let's start by looking at the fields of the accumulation register in:

Get 267 video lessons on 1C for free:

The accumulation register has Dimensions, Resources, Details and Standard details.

Let's first consider the standard details of the accumulation register:

period— the date of movement does not have to coincide with the date of the document;
registrar- a document that makes an entry in the register;
line number— serial number of the line in the record set, unique within the registrar;
activity— is responsible for getting records into virtual tables (more about them below);
viewmovement- income or expense.

Accumulation register measurements

A dimension is a section in which records are kept. In the above example, the accounting section is: warehouse, nomenclature, product characteristics, product series, quality. That is, by specifying the measurements we are interested in, we can obtain the quantity—resource—at any time. In the context of different dimensions, in the future, for example, you can obtain balances for a specific date.

Accumulation register resource

A resource is a numeric field in which information is stored in the context of the dimensions described above.

Otherwise, the interactions of dimensions/resources can be schematically depicted as a coordinate system:

Two dimensions - abscissa and ordinate of the coordinate system, i.e. in this example, the dimensions are warehouse and item. At the intersection of dimensions we can get a quantity - a resource. For example, at the “main” warehouse of the product “pencil” there is 1 piece in stock.

Details of the accumulation register 1C

Accumulation register details serve as a “comment” or additional information; in terms of measurements, balances/turnovers cannot be obtained. Used quite rarely.

Types of accumulation register

There are two types of accumulation register − turnovers and balances.

If the purpose of the accumulation register is not to obtain balances, it is necessary to use the type of accumulation register - rpm. A typical example of using a turnover register is recording sales volumes. In this case, we only need to know what sales were over a certain period of time; balances in this case do not make sense.

If the purpose of using the accumulation register is to obtain balances for a certain period, we need a register with the form leftovers. This type allows you to receive both balances and turnover. For such a register, the system automatically calculates balances. An example of a “residual” register is goods in warehouses, money in the cash register.

Using a register type leftovers where you can get by rpm, is considered a blunder in the design of the accumulation register from a system performance perspective.

Depending on the type of register, the system will create different virtual tables for the accumulation register. A virtual table is a quick way to obtain profile information from registers.

For the accumulation register it is:

Leftovers;
Revolutions;
Remains and turnovers.

For the solution developer, the data is taken from one (virtual) table, but in fact the 1C platform takes it from many tables, transforming them into the required form.

Proper design of accumulation registers

Accumulation registers must be designed from the required reports. The most difficult thing in the 1C 8.3 system is storing information correctly so that it can be easily retrieved at any time.

Among the features of register design, it should be noted the need to correctly arrange the dimensions in the register. Above all, you need to put the measurements that will be requested most often in the system.

Indexing accumulation register dimensions

Accumulation register measurements have the property of “indexing”. This property must be set to measurements in cases where it is planned to frequently apply selections to the measurement when receiving data and this measurement can have a large number of value options.

For example, the register is “ProductsInWarehouses”, the dimensions are “Warehouse, Nomenclature”, the resource is “Quantity”.

It is more correct to index the “Nomenclature”, but the “Warehouse” field should not be indexed, because the number of warehouses in the system, as a rule, is not significant.

Untitled Document

Preparation for 1C: Professional and Specialist in SCP for dummies.

Lesson 15. We study movements by registers. VAT Presented.

In order to understand well how to work with SCP, you need to understand what movements the documents make and why. So let's do this. We will consider registers in two modes: normal and RAUSE (Advanced Cost Accounting Analytics). You probably have a question: “How does RAUZ differ from the usual SCP mode?” The main difference is that RAUZ uses the method of solving systems of linear equations when calculating production costs and adjusting the movements of inventories, and also does not keep batch records of inventories. There are other differences that we will look at in future lessons.

And so, let's begin, perhaps. Let's check what mode our UPP is in. To do this, switch to the “Accounting Manager” interface:

Then, through the menu "Accounting settings" -> "Accounting settings settings" we will call the settings window:

In it, let's go to the "Costs and Cost" tab and make sure that our SCP is working as usual. If not, disable RAUZ:

Now you can start learning about registers. And so, we create a new document “Receipts of goods and services” or post the one that you have already created in previous levels (for example, and): we look at which registers the document was posted in:

And so, as we could see, the invoice is posted in the following registers:

Accumulation register "VAT presented"

Accumulation register "Consignments of goods in warehouses (accounting)"

Accumulation register "Consignments of goods in warehouses (management accounting)"

Accounting register "Journal of transactions (accounting)"

Accumulation register "Purchase settlements (accounting)"

Accumulation register "Purchases"

Accumulation register "Mutual settlements with counterparties"

Accumulation register "Consignments of goods in warehouses (tax accounting)"

Accumulation register "Settlements with counterparties"

Accumulation register "Goods in warehouses"

Accounting register "Journal of transactions (tax accounting)"

Accumulation register "Goods of organizations"

Now let's look at them in detail. And so, the “VAT presented” register. This is a subsidiary register that takes into account input VAT on purchased goods or materials. This accumulation register is used in the Incoming VAT Analysis report. It can be opened from the Accounting and Tax Accounting Interface.

through the menu "VAT" -> "Reports" -> "Analysis of incoming VAT":

This report will show us comparisons of VAT paid and credited:

Another report, called “Statement of VAT presented by the supplier” will show us the contents of the same register, but in arbitrary groupings (this is set in the report settings). His path is “VAT” -> “Reports” -> “Statement of VAT presented by the supplier”:

Well, you say, where else is this register used, except for reports? It is clear that it was not invented only for them, because reports can also be constructed based on the accounting entries of account 19.

I will answer:

It is used to create a purchase book.

Let's see how it's all done. First, let's enter an invoice based on our invoice. This can be done either by using the "2Water on base" button:

Or in the document itself, click on the inscription: “Enter invoice”:

At the same time, we will have an invoice entry form open, in which we must enter the number and date of the incoming invoice, since they do not coincide with the internal number and date assigned by the system:

After entering the invoice, the inscription “Enter invoice” will turn into information about the entered invoice, and when you click on it, the form described above will open: