Для пользователя:
Последовательность документов есть в УПП, УТ (8), ТиС, ПУБ (7).
Операции – Проведение документов, на закладке «Восстановление последовательностей» приведены все имеющиеся в программе последовательности и указана дата актуальности каждой из них. То есть если в июне 2010 года мы видим такое:

То это плохо. Партионный учет давно неактуален, значит – все значения себестоимости, которые появляются в отчетах, врут. (Учет кадров и налоговый учет УСН в данной базе не ведется).

Что значит последовательность? Строго говоря, одним из правил учета является его оперативность, т.е. отражение хозяйственных операций по мере их возникновения. 1 июня на склад поступило 10 штук товара А, потом 10 июня продано 8 штук. Если проводить эти документы (Поступление товаров и услуг, Реализация товаров и услуг) строго в хронологическом порядке, то последовательность установится сначала на 1 июня, потом на 10 июня. Т.е. ее граница будет сдвигаться вперед каждым документом, и итоги (количество, сумма, себестоимость) будут актуальными на каждый момент времени. Если же потом, задним числом, провести еще один документ (Реализация товаров и услуг) от 8 июня, которым будет оформлена реализация 7 штук товара А, программа дает это сделать беспрепятственно. Граница последовательности при этом установится на 8 июня, на этот документ. То есть информация ДО ввода этого документа верна, а ПОСЛЕ – уже нет. При восстановлении последовательности (перепроведении документов, входящих в последовательность), документ от 10 июня проведен не будет, потому что нет необходимого количества товара А. Далее пользователь должен искать причину этой ошибки, устранять и восстанавливать последовательность заново.

Как часто восстанавливать последовательность? Как минимум – перед выполнением регламентных операций, формированием значимых отчетов и т.п. Поскольку любое перепроведение документа (относящегося к последовательности) сдвигает ее границу, имеет смысл закрывать для редактирования прошлые периоды (Сервис – Установка даты запрета изменения данных ).

В Бухгалтерии последовательности нет (за исключением кадровых приказов – в 8.1), но есть возможность автоматического перепроведения документов за период.
Перед закрытием месяца это делать необходимо (Операции – Проведение документов).

Для программиста:
Последовательность – объект метаданных 1С – предназначена для упорядоченного хранения множества документов согласно дате и времени.

Граница последовательности (ГП) – позиция, последнего введённого документа в последовательность. Если после ГП есть другие документы в последовательности, то последовательность считается нарушенной и её необходимо восстановить.

Логически - последовательность можно условно представить как «Общий» журнал документов входящих в эту последовательность. Условно, потому, что на последовательностях строится логика учета.

У некоторых последовательностей, для дополнительного контроля автоматически при движении регистров, отслеживается связь: регистр – последовательность. Если изменился регистр, должна измениться и последовательность.

Физически – последовательность состоит из двух таблиц:
1. Таблица регистрации;
2. Таблица границ.

Таблица регистрации (ТР) – коллекция зарегистрированных в последовательности документов в разрезе измерений. В случае повторной записи документа сначала удаляется старая запись, затем записывается новая.

Таблица границ (ТГ) – хранит границу последовательности в разрезе измерений, одно измерение – одна запись если измерений нет, то у ТГ одна запись. Запись ТГ показывает, какой документ в ТР является последним правильно проведённым, т.е. не нарушившим правильное ведение учёта.

Обе таблицы идентичны по составу колонок: «Период», «Регистратор», «Измерение».

Восстановить последовательность возможно путём простого программного переноса ГП (если вы уверены, что итоги не нарушены) на последний документ в последовательности или повторным, последовательным проведением всех документов от ГП до последнего по времени документа в последовательности. Для исправления последовательности существует штатная обработка «Проведение документов».

Механизм «последовательность» имеет подчинённые объекты, свойство – измерения.

Измерения – это разрезы последовательности. Измерения, условно разбивают последовательность на несколько логически целых частей.

Измерение позволяет, в случае необходимости, перепроводить не все документы, входящие в последовательность, а только те которые содержат данное измерение, что ускоряет скорость работы при восстановлении последовательности.

Измерения повышают производительность системы в целом, так как при записи и проведении захватывается не вся таблица целиком, а только те её строки, которые соответствуют данному измерению.

Регистрация документа в последовательности, т.е. в ТР, производится в момент его записи.

Регистрация документа в последовательности может осуществляться автоматически, под руководством системы, если свойство «Заполнение последовательностей» документа будет установлено в «Заполнять автоматически» если иначе, то сам разработчик описывает правила регистрации.

Запись в ТГ происходит при проведении документа.

При проведении документа, его движения учитываются в:
· «Оперативном учёте» - записывает движения документа в регистрах;
· «Бухгалтерском учёте» - запись проводок.

ПоследовательностьМенеджер.< ИмяПоследовательности > - Данный менеджер предназначен для управления последовательностью:
Последовательность.«ИмяПоследовательности».Восстановить
Последовательность.«ИмяПоследовательности».ПолучитьГраницу
Последовательность.«ИмяПоследовательности».ПолучитьГраницы
Последовательность.«ИмяПоследовательности».Принадлежит
Последовательность.«ИмяПоследовательности».Проверить
Последовательность.«ИмяПоследовательности».СоздатьНаборЗаписей
Последовательность.«ИмяПоследовательности».УстановитьГраницу

Вся работа «ПоследовательностьМенеджер» складывается из анализа и работы с ТР и ТГ. Например, метод «Проверить» - если документ в ТГ, есть последний в ТР, значит, последовательность не нарушена и наоборот и т.д.

Многие помнят о проблеме медленного проведения и перепроведения документов в связке 1С 7.7 - MS SQL.

С этой же проблемой и я столкнулся когда-то, после того, как перевел торговую базу своего предприятия с DBF на SQL.

Тогда же и была реализована эта технология. Хотя сама идея появилась у меня несколько раньше.

Дано: партионный учет товаров, FIFO, списание себестоимости в момент перепроведения документа. До 2500 документов с движениями по регистрам товарного и денежного учета в день, что составляло около 60000 в месяц. В среднем, 22 строки на документ Реализации ТМЦ. Частые корректировки в товарных документах текущего месяца "задним" числом. Продажи в разрезе ТП. Контроль директором себестоимости/наценки on-line. Среднее время проведения документов Реализация ТМЦ (как самых "тяжелых") 2-2,5 секунды.

Надо: быстро, желательно в пределах 4-5 часов восстанавливать всю последовательность перед закрытием месяца. Причем жизнь показала, что процесс может повториться 2-3 раза. При этом - не внося никаких изменений в структуру и кодинг конфигурации.

Посмотрим на движения по регистру "Партии Наличие" документа Реализация ТМЦ:

Мы знаем, что при списании Партий ТМЦ списывается остаток с той партии, что пришла первой. Если количество списываемого товара более количества на остатке данной партии, происходит списание с последующих партий.

Посмотрим в "Ведомость по партиям ТМЦ":

Есть пересписание по партии. А какие условия могут привести к этому?

1. "Переползание" документов из предыдущей партии;

2. Уменьшение количества/стоимости в документе поступления/оприходования;

3. Увеличение количества в документах списания;

4. Возможно, был удален возврат товара с этой партии;

5. Возможно перемещен документ по времени журнала документов - из конца дня в начало, или более того - из одного дня в другой.

Нас уже не волнует кто, когда, что, где и зачем. Наша цель - убрать "красноту".

Если это делать "руками" что для этого надо? Правильно, перепровести последовательно документы под номерами 3845 и 3846. После этого они "соскользнут" на следующую партию. Затем обновляем отчет, и смотрим, нет ли "красноты" на следующей партии.

При этом для всех остальных документов перепроведение не сыграет никакой роли! Все товары так и останутся в пределах своих "родных" партий.

Ну а что нам мешает написать аналитический модуль, который будет проверять это соответсвие партий? Ничего.

Анализ показал, что подобные подвижки в общей массе движений составляют не более 10% от общего числа документов в месяц. А перепровести 6000 все же проще, чем 60000.

Значит, последовательно, для каждого документа из обрабатываемого периода, строим таблицу соотношения количества товаров в документе, остатков по партиям и движений по регистру партий данного документа:

Расхождения в остатках и партиях выделены цветом.

Собственно, сам факт хотя бы одного расхождения в подобной таблице - уже сигнал, что данный документ должен быть перепроведен.

Кстати, в прямом SQL-запросе возможно реализовать вариант полного анализа подобных ситуаций, что нам и удалось в результате сделать: запрос возвращал нам только строки с недостатком товара. Для данного примера, это были бы строки товаров №№ 3, 6, 8.

Нашли расхождения - перепровели. Потом следующий.

По аналогии был организован анализ оплаты.

Подобный подход позволил производить предварительный анализ со скоростью до 5 документов в секунду. А учитывая тот факт, что сам анализ уже не требовал блокировать базу переходом в монопольный режим и не мешал процессам создания и проведения текущих документов, в дальнейшем восстановление последовательности часто происходило не только по ночам, но и в рабочее время без особых помех для сотрудников.

23/10/2015

Параллельное восстановление партий

Современные учетные задачи производственных предприятий остаются достаточно сложными для любых систем, особенно работающих под высокой нагрузкой - большой документооборот или количество пользователей. И одними из самых сложных задач остаются задачи расчета себестоимости выпуска продукции.

Типовые конфигурации 1С, например, "1С:Управление производственным предприятием" (УПП) давно предлагают множество механизмов для упрощения данных расчетов, например, инструментарий механизма РАУЗ (расширенной аналитики учета затрат). Данный механизм действительно позволяет в некоторых случаях существенно упростить технически, а значит - ускорить функции расчета себестоимости. Проблема только в том, что использовать данный подход можно не всегда, и предприятиям приходится использовать старый добрый партионный учет, а вместе с ним - использовать процедуру восстановления партинного учета.

В большинстве случаев при существенном документообороте именно задача "восстановления партий" является самой трудоемкой и длительной в процессе закрытия месяца и расчета себестоимости. Давайте рассмотрим ее подробнее со всех сторон и разберем, какие здесь имеются пути для оптимизации и сокращения времени.

Первое, с чем приходится сталкиваться при выполнении проектов по оптимизации производительности процедуры восстановления партий - это устаревшие методы выполнения этой процедуры, а именно - полное перепроведение документов. Иногда это только определенные виды документов, участвующие в «партиях», иногда вообще все без разбора. Нам кажется, что данный подход идет с тех времен, когда действительно других альтернатив и не было, либо с тех конфигураций, в которых это единственный способ. Однако, сейчас для рассматриваемой нами конфигурации УПП это не так. В УПП есть более аккуратные и производительные механизмы для выполнения этих задач, а именно:

• Процедура восстановления последовательности партионного учета (отдельно УУ, БУ, организациям)
• Процедура восстановления взаиморасчетов (определения авансов)

Каждый из этих пунктов реализован отдельными обработками, которые вместо полного перепроведения документов выполняют только корректировку движений очень ограниченного числа регистров, за счет чего процесс выполняется несравнимо быстрее. Примерно так же поступает вторая обработка для восстановления взаиморасчетов. Кроме этого, если сравнивать работу этих механизмов с обычным перепроведением документов можно столкнуться со следующей проблемой, искажающей учетные данные: сортировка по дате документов, необходимая для расположения документов "в хронологическом порядке" работает с точностью до секунд, а в рамках одной секунды в системе могут присутствовать несколько разных документов (например, поступление и списание), от последовательности обработки которых будет зависеть сформированная стоимость. При обычном проведении нет никакой возможности обеспечить такой порядок и подобный расчет от раза к разу может давать разные результаты. Для решения этой проблемы в платформе предусмотрен специальный объект, "последовательность", который решает эту задачу и всегда гарантированно одинаково располагает документы по хронологии, и обработки восстановления последовательности всегда опираются именно на этот порядок.

Хорошо, но что если мы используем именно эти обработки и все равно процесс восстановления партий занимает длительное время, например, не успевает выполниться за ночь? При этом серверные мощности, чаще всего, простаивают (не имеют даже 30% загрузки).

По нашему опыту, время обработки одного документа не превышает 0,2 - 0,8 секунд и сам код по корректировке движений написан достаточно хорошо. Чтобы получить существенный прирост, нужно сократить это время, например, с 0,2 сек до 0,05, что кажется практически невыполнимой задачей, даже если рассматривать возможность изменения не только кода конфигурации, но и тотальной замены оборудования на последние поколения процессоров и систем хранения данных на Flash/SSD. Неужели нет выхода?

Оказывается, он есть! Тут нам на помощь приходит наш опыт олимпиадного программирования и пытливый ум, который шепчет, казалось бы, абсурдную фразу - давайте сделаем процесс восстановления "последовательности" - "параллельным"! Казалось бы, это невозможно, ведь мы намеренно "расставляем" документы строго друг за другом и именно так их и обрабатываем. Это и объясняет медлительность процесса - он идет в один поток, ограничен производительностью одного ядра процессора серверов, которые, как правило, имеют достаточно много простаивающих в это время других ядер.

На самом деле, расположение документов друг за другом - это некоторое упрощение, которое намеренно используется и гарантирует корректность учета, но не является единственно возможным решением. Каждый документ в последовательности зависит не от всех предыдущих документов, а только от некоторых, например, от тех документов, в которых есть та же самая номенклатура. При этом все другие документы не требуется проводить «до» нашего выбранного документа, и их можно проводить параллельно!

Откровенно говоря, подобная идея и подход конечно не новы, например, в базе знаний фирмы "1С"по технологическим вопросам есть статья (http://kb.1c.ru/articleView.jsp?id=72), которая описывала подобные подходы. В интернете также можно найти и другие подобные темы, в том числе различные интерпретации таких подходов (например, "блокировочный механизм" http://www.softpoint.ru/article_id375.htm и т.д.). Однако, проблемами всех указанных подходов является то, что они основываются на некоторых допущениях или искусственно формируемых "блоках" обработки данных, и не имеют четкой последовательности обработки. Мы захотели устранить эти недостатки, используя максимально «академический» подход, и считаем, нам это удалось.

Реализованный нами процесс параллельного восстановления партий состоит из двух важных этапов. Первый и ключевой этап - это расчет зависимостей документов друг от друга по специальным алгоритмам, в том числе с учетом общих прикладных допущений. Например, можно заметить, что все поступления образуют новые партии и ни от кого "до" себя не зависят, в отличие от списаний. Все такие зависимости представляются в виде графа, точками которого являются документы, а ребрами - их зависимости. Строго говоря, это ориентированный граф, но способ его обхода отличается от классических приемов и алгоритмов, поэтому нам пришлось написать свой, для которого это не важно.

Второй этап - это непосредственное восстановление (корректировка движений), только уже не по последовательности, в которой регистрируются документы платформой, а по нашему графу. При этом вот что важно - собственно код и алгоритмы формирования движений остаются полностью типовыми, а значит, конфигурация сохраняет возможность обновления. Все наши доработки находятся в отдельной подсистеме и только используют функции общих модулей, которые используются и в типовых обработках. Это гарантирует также и корректность результата - он всегда будет совпадать с типовым, последовательным восстановлением. Более того, это справедливо и для отраслевых решений (например, "1С:Управление птицефабрикой"), где в последовательности могут присутствовать специфические документы. Наличие первого этапа и дальнейший классический обход графа в глубину позволяют даже спрогнозировать и время выполнения обработки, и степень "параллельности" процесса, которая, очевидно, зависит от конкретных данных в базе. С помощью данных механизмов мы можем понять необходимые ресурсы сервера, а также эффективно управлять ими.

Собственно обработка очереди документов по такому графу не представляет собой каких-то сложностей и достаточно типовая - есть управляющее фоновое задание, которое определяет доступные для обработки документы в нужном порядке и запускает необходимое количество рабочих фоновых заданий, каждое из которых занимается обработкой конкретного документа. Весь процесс происходит асинхронно, это значит, что для оператора нет необходимости держать открытым сеанс УПП, в котором был произведен запуск - все будет работать само, динамически отображая процесс на специальной диаграмме. Здесь же можно регулировать нагрузку - максимальное количество потоков (рабочих фоновых), которые будут запущенны одновременно. И здесь же можно даже приостановить этот процесс, поставив обработку на паузу, а также и продолжить его, без необходимости повторного расчет и запуска. Так как на первом этапе мы проводим специальные расчеты для того, чтобы быть уверенными в возможности параллельной обработки документов, в процессе обработки взаимоблокировки и таймауты блокировок практически исключены. Помешать процессу могут только параллельно работающие пользователи, которые могут только немного затормозить его, но от этого ничего не сломается и результат окажется верным в любом случае. Да, вы правильно поняли - восстанавливать последовательность можно достаточно эффективно и при работающих пользователях, главное исключить изменения данных в периоде восстановления.

Итак, проблема, казалось бы, решена, алгоритм написан, проверен и оттестирован в мельчайших деталях, однако запуск на реальной рабочей базе, начав работать в штатном режиме, стал существенно деградировать по производительности к середине обработки графа. Время обработки одного документа стало превышать 10 секунд (вместо плановых - не более секунды), и тут уже были применены стандартные подходы к оптимизации - анализ планов запросов и их оптимизация. В результате этих работ мы нашли типовой запрос в УПП, слегка переписав который можно устранить такую деградацию, при этом его результаты остаются точно такими же, как в типовом виде. Данный "патч" можно применять и при последовательном восстановлении последовательности, и при полном перепроведении документов. Можем предоставить его абсолютно бесплатно, по запросу на нашу электронную почту: .

Вот теперь мы получили именно то, что планировали: многократное сокращение времени восстановления последовательности (более чем в 16 раз!), эффективная загрузка оборудования, удобные и гибкие инструменты для управления процессом. Но самое главное - это наш довольный заказчик, что для нас всегда является главной целью и наивысшей ценностью.

С отзывом совсем скоро Вы сможете ознакомиться на нашем сайте.

И напоследок, небольшой чек-лист для Вас.

Основные приемы восстановления последовательности, от самых простых, до самых инновационных:

• Перепроведение документов для восстановления последовательности вы выполняете только в части тех документов, что используются в последовательности партионного учета и с сортировкой по моменту времени, а не по дате?
• Вместо перепроведения используете специализированный механизм восстановления партий и взаиморасчетов (в УПП и аналогичных конфигурациях)?
• Используете наше фирменное многопоточное, параллельное восстановление партий? J

В данной статье будут рассмотрены основные особенности выполнения регламентных операций месяца с учетом настроек параметров учета, а также описание и практическое устранение основных ошибок возникающих при завершении периода.

Начнем с детального рассмотрения бизнес-процесса закрытия месяца.

Все хозяйственные операции уже введены в информационную базу, и необходимо выполнить ряд регламентных процедур. Регламентные операции могут делиться на корректирующие, расчетные и обеспечивающие правильное ведение бухгалтерского и налогового учета.

К первым относятся, например, процедуры восстановления хронологической последовательности. В течение месяца при введении в информационную базу хозяйственных операций могла быть нарушена правильная последовательность отражения документов учета, что могло исказить финансовый результат. Для того, чтобы такого не случилось, существует специальная регламентная процедура по восстановлению правильной последовательности отражения операций.

Расчетные процедуры обеспечивают правильный расчет показателей в бухгалтерском и управленческом учете, например, расчет себестоимости.

Другие процедуры отвечают за соблюдение правил бухгалтерского и налогового учета, например, формирование записей книги покупок и продаж. Все операции выполняются отдельно регламентными документами и строго в определенной последовательности.

Настройка процедуры закрытия месяца

Рассмотрим схему закрытия периода. Она представлена в виде бизнес-процесса. Механизм закрытия месяца доступен из интерфейсов «Бухгалтерский и налоговый учет» и «Заведующий учетом».

Перед тем, как запускать процедуру, необходимо сделать настройку. Настройки процедуры закрытия месяца можно найти в справочнике Настройки закрытия месяца. Указываем период и выбираем вариант системы налогообложения. Все настройки указываются независимо от организации.

На первой вкладке флажками отмечаются те операции, которые будут выполняться (). Например, если ни в одной организации не производятся расчеты в иностранной валюте, тогда нет смысла проводить операцию переоценки валютных средств.

Рис. 1

Отметив флажками нужные операции, перейдем на вторую вкладку Схема. Тут указана схема бизнес-процесса, последовательность выполняемых операций, а также активные и неактивные, пользователи ответственные за эти процедуры. Назначить ответственного можно на вкладке Ответственные или щелкнув в схеме правой кнопкой мыши на блоке операции и выбрать пользователя.

Отдельно указана схема расчета НДС.

На закладке Распределение затрат указываются способы распределение затрат для расчета себестоимости. Для правильного распределения указывается также соответствие Подразделений Подразделениям Организации в справочнике «Подразделения».

Запуск процедуры

Настройка закрытия месяца создана, теперь можно приступить к запуску самой процедуры. Перейдем к пункту меню «Регламентные операции» и выберем пункт «Процедура закрытия месяца». Здесь укажем «Организацию» и «Настройку». Признаки отражать в бухгалтерском, налоговом и управленческом учете будут установлены сами в зависимости от настройки закрытия месяца, если щелкнуть по кнопке «Загрузить настройки».

Итак, все готово для запуска. Нажимаем кнопку «Запустить процедуру» и перейдя по кнопке «Регламентные операции» увидим, что пользователю автоматически сформировалась задача, в соответствии с которой он должен оформить регламентные документы необходимые на данном этапе.

После выполнения этапа, программа автоматически переходит к следующему. Некоторые этапы могут выполняться параллельно.

После того как все задания будут выполнены процедура считается завершенной.

Этапы выполнения регламентных операций

После запуска процедуры закрытия месяца система назначит ответственному первую задачу. Он сможет увидеть ее из пункта меню Регламентные, переключившись на интерфейс «Бухгалтерский и налоговый учет».

Для ее выполнения пользователю необходимо создать и провести документы, которые ему предложит программа на данном этапе ().

Рис. 2

После того как документы сформированы и проверены, можно отметить операцию как выполненную, чтобы система перешла к следующей задаче. Все необходимые документы по окончании периода можно создавать и вручную отдельно от бизнес-процесса, но целесообразнее и удобнее формировать и проверять сразу из формы регламентных операций, ведь очень легко сбиться в последовательности, что впоследствии может привести к искажению результата.

Рассмотрим основные операции, входящие в процедуру закрытия месяца.

Допроведение документов

Если в программе используется механизм отложенного проведения, то при завершении месяца будет запущена обработка «Допроведение документов», чтобы документы были проведены по всем регистрам. При большом документообороте данная обработка запускается регулярно.

В журнале «Отложенное проведение документов» можно увидеть те документы, которые подчиняются механизму допроведения. С помощью операции «Действия -> Провести полностью» документ проводится по всем регистрам.

Восстановление состояния расчетов

Если в учетной политике предприятия обозначено, что зачет авансов производится обработкой «Восстановление последовательности расчетов», то по завершении периода запускается данная обработка. Ее можно найти, переключившись на интерфейс «Заведующий учетом» пункт меню «Регламентные операции -> Восстановление последовательности расчетов». Обработка восстанавливает правильную последовательность документов по зачету авансов. После ее использования документы поступления и реализации не перепроводят, иначе проводка по зачету аванса исчезнет.

Восстановить последовательность партионного учета

Если в программе используется партионный учет, то при списании партий можно облегчить работу прикладного решения, отложив списание в управленческом и регламентированном учете и запустив специальную обработку в конце месяца, которая проведет документы по регистрам партионного учета. Для этого снимаются галочки в «Настройках параметров учета -> Списывать партии при отражении документов» и запускается обработка «Проведение по партиям». Даже если документы вводились задним числом, то запускать эту обработку тоже полезно, потому как она восстанавливается последовательность партионного учета.

Скорректировать стоимость списания МПЗ

Используется при партионном учете. При проведении документа выполняется корректировка стоимостных движений по партионному учету за месяц. Корректировка необходима для: расчета средневзвешенной стоимости списания партий при использовании способа оценки МПЗ «По средней», а также учета дополнительных расходов на приобретение товаров, оприходованных после списания товаров.

Начислить амортизацию ОС

Из формы регламентной операции, нажав на кнопку «Создать документы» последним днем месяца автоматически создается документ «Амортизация ОС». Далее следует провести и посмотреть результат проведения.

Если для каких-то ОС используется способ амортизации пропорционально объему продукции или по единым нормам амортизационных отчислений, то сначала заполняется документ «Выработка ОС».

Начислить амортизацию НМА

Суммы амортизации и списания расходов на НИОКР рассчитываются при проведении документа «Амортизация НМА». Аналогично если амортизация начисляется пропорционально объему произведенной продукции, то следует указать объем продукции, произведенной в этом месяце.

Погасить стоимость спецодежды

На этом этапе будет создан документ «Погашение стоимости (спецодежда, спецоснастка, инвентарь)», при проведении списывается часть стоимости спецодежды и спецостнастки, которая была не полностью погашена при вводе в эксплуатацию.

Списать РБП

При проведении документа «Списание расходов будущих периодов» часть расходов будущих расходов переносится на текущие. Суммы и счета, на которые эта часть будет списываться, указывается в справочнике «РБП».

Рассчитать расходы по страхованию

Документ предназначен для списания расходов будущих периодов по добровольному страхованию работников в бухгалтерском (76.01.2 «Платежи (взносы) по добровольному страхованию работников») и налоговом учете (97.02 «Расходы будущих периодов на добровольное страхование работников»).

Переоценить валютные средства

С помощью документа «Переоценка валютных средств» производится переоценка сумм в валюте управленческого учета по регистрам денежных средств и взаиморасчетов с контрагентами и подотчетными лицами.

Для расчета НДС существует отдельная схема. На вкладке «Схема расчета НДС» отмечаются те операции, которые следует выполнить. Программа сама создаст необходимые документы, предложит их заполнить и провести. Прикладное решение автоматически формирует формы отчетности: книга покупок, книга продаж, декларация по НДС. Все регламентные операции хранятся в журнале (интерфейс «Бухгалтерский и налоговый учет», меню «НДС –> Регламентные документы НДС»).

Документ «Расчет себестоимости» формируется для каждого вида учета отдельно, если необходимо рассчитать себестоимость по всем видам учета, то проводим несколько документов (по управленческому учету и бухгалтерскому и налоговому учету). Данный документ производит расчет фактической стоимости списания запасов на расходы, списывает материалы из незавершенного производства, распределяет общепроизводственные и общехозяйственные расходы на выпуск () Используется только при расширенной аналитике учета затрат.

Рис. 3

Расчет себестоимости состоит из следующих операций:

• Если учет ТЗР ведется на отдельном счете, тогда выполняется «Распределение ТЗР».
• Определяется список услуг по документам «Реализация товаров и услуг», себестоимость которых будет рассчитана.
• Расчет базы распределения расходов – способы распределения задаются в регистре сведений «Способы распределения статей затрат» или из справочника «Статьи затрат» для каждой статьи отдельно. Выполняется расчет всех баз, по которым будут распределены расходы. Рассчитанные базы записываются в регистры сведений «База распределения затрат» и «База распределения затрат (бухгалтерский учет)»
• Распределение расходов по базе – после расчета базы выполняется распределение расходов на стоимость готовой продукции и услуг.
• Расчет фактической себестоимости - выполняется суммовая оценка стоимости МПЗ.
• Формирование движений по регистрам бухгалтерии (для регламентированного учета) и стоимости основных средств (для управленческого учета).

Сформировать финансовый результат

Документ «Определение финансовых результатов» делает проводки по закрытию счетов 90 и 91. Документ может быть отражен в бухгалтерском и налоговом учетах. При отражении документа в налоговом учете может быть выполнена операция списания убытков прошлых лет.

При закрытии 90 счета будет сформирована проводка, отражающая прибыль или убыток. При закрытии 91счета будет рассчитан финансовый результат по прочим видам деятельности.

Рассчитать налог на прибыль

С помощью документа «Расчеты по налогу на прибыль» можно выполнить расчет постоянных и отложенных налоговых активов и обязательств в соответствии с нормами ПБУ 18/02 «Учет расчетов по налогу на прибыль» и расчет налога на прибыль. Этот документ можно использовать для ввода остатков по отложенным налоговым активам и обязательствам.

Закрыть год

Документ «Закрытие года» проводится только в декабре каждого года. В результате проведения все сальдо субсчетов счетов 90 и 91 бухгалтерского учета списываются на соответствующие субсчета с кодом 99. Все сальдо субсчетов счета 99 "Прочие доходы и расходы" списываются на счет 99.01.1 (2), а сальдо этого счета списывается на счет 84 "Нераспределенная прибыль (непокрытый убыток)".

Операцией Закрытие счетов налогового учета все остатки счетов налогового учета, не предназначенных для отражения стоимости активов, списываются.