1с упп зависает расчет себестоимости

Обновлено: 05.07.2024

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

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

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

Для этого необходимо сначала построить отчет «Ведомость по учету затрат» (в полном интерфейсе - Меню «Отчеты» - «Расширенная аналитика учета» - «Ведомость по учету затрат»).

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

В данном случае счет важнее всех остальных группировок, поэтому мы ставим его вверх группировки отчета.

Для этого идет в Настройки – Настройка структуры (как показано на рисунке ниже)

Из доступных полей выбираем счет и переносим его в группировку строк (как показано на рисунке ниже)

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

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

Можно назвать вариант, например, «Учет затрат по счету затрат БУ»

Далее строим отчет по учету затрат в регламентированном учете: по определенной организации, по определенному периоду отчета и, самое главное, по счету учета затрат бухгалтерского учета (в нашем случае это счет 20.01.1 «Основное производство (по деятельности, не облагаемой ЕНВД)»).

Теперь нам надо построить оборотно-сальдовую ведомость по счету 20.01.1 «Основное производство (по деятельности, не облагаемой ЕНВД)» по этой же организации, за этот же период отчета.

Для этого заходим в полном интерфейсе в меню «Отчеты» - «Бухгалтерский и налоговый учет» - «Оборотно-сальдовая ведомость по счету (бух.)» и строим отчет.

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

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

Далее, формируем отчет по учету МПЗ в регламентированном учете: по определенной организации, по определенному периоду отчета и, самое главное, по счетам БУ материально-производственных затрат, те которые отразились при формировании отчета «Ведомость учета по МПЗ». Проверяем остатки и обороты по каждому из счетов по оборотно-сальдовой ведомости бухгалтерского учета, и, если все верно, как в нашем случае, то можно приступать к расчету себестоимости в бухгалтерском и налоговом учете.

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

Сейчас, на примере, мы убедимся, что даже правильно сделанные ручные проводки по счету затрат БУ 26 с указанием всех аналитик приведут к тому, что сумма, отраженная ручной операцией не будет автоматически закрыта при расчете себестоимости. Как ранее было показано, перед закрытием месяца необходимо сделать сверку по регистрам учета затрат и «МПЗ» с данными бухгалтерского (налогового) учета.

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

Но при расчете себестоимости затраты, введенные ручной операцией не распределились на выпущенную продукцию, что видно из оборотно-сальдовой ведомости по счету 20.01.1, и сумма затрат «зависла» на этом счете.

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

Для того, чтобы затраты отразились по регистрам учета МПЗ и затрат необходимо отменить проведение ручной операции и провести списание специализированным документом (в нашем случае это документ «Требование-накладная»).

Операцию, введенную ручным способом, можно или пометить на удаление, или в самом документе ручного ввода отключить активность. И проводки будут отключены.

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

После этого, перепроводим документ «Расчет себестоимости» и проверяем отражение затрат в регистрах учета МПЗ и затрат. Видно, что затраты попали в регистр учета МПЗ и увеличили количество и сумму материально-производственных затрат.

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

И наконец, проверяем оборотно-сальдовую ведомость по счету 20.01.1. Видим, что затраты отражены и полностью закрыты расчетом себестоимости.

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

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

Статьи затрат закрываются в соответствии с настройкой их при закрытии месяца, а также в соответствии с записями в регистре сведений «Способы распределения статей затрат организаций».

Разберем пример на производственном предприятии, когда субсчета бухгалтерского счета 20 закрываются способом распределения «По объему выпуска».

Для выявления ошибки, по причине которой не закрываются субсчета бухгалтерского счета 20, необходимо сверить отчет «Оборотно-сальдовая ведомость (бух.)» по субсчетам бухгалтерского счета 20 (детализация по подразделениям организаций и номенклатурным группам) с отчетом «Выпуск продукции и услуг» с такой же детализацией по подразделениям организаций и номенклатурным группам, выявить и устранить ошибки такого несоответствия.

Формируем отчет «Оборотно-сальдовая ведомость по счету (бух.)» по счету 20.01.1 (в Полном интерфейсе – меню «Отчеты» - «Бухгалтерский и налоговый учет» - «Оборотно-сальдовая ведомость по счету (бух.)».

В детализации аналитики указываем Подразделение организации, Номенклатурную группу и Статьи затрат. Видим, что за август 2018 года в подразделении «Цех 1» по номенклатурной группе «Столы компьютерные» начислены и отражены затраты, но которые не закрылись при расчете себестоимости.

В нашем примере распределение затрат организации происходит по методу распределения «По объему выпуска», поэтому нам необходимо сформировать отчет «Выпуск продукции и услуг» и проверить правильно ли в августе 2018 года был отражен выпуск продукции и услуг» (в Полном интерфейсе – меню «Отчеты» - «Расширенная аналитика учета» - «Выпуск продукции и услуг»).

Формируем отчет, указывая в качестве группировок Подразделение, Номенклатурную группу и Продукцию. Из сформированного отчета, мы видим, что выпуск продукции в августе месяце ошибочно был указан по неправильной номенклатурной группе.

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

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

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

После проверки выпуска продукции, необходимо провести повторный расчет себестоимости в регламентном документе «Расчет себестоимости» (в Полном интерфейсе – меню «Документы» - «Управление производством» - «Расчет себестоимости».

Как мы видим из отчета, расчетом себестоимости счет 20.01.1 по номенклатурной группе «Столы компьютерные» закрыт. То есть мы в процессе проверки и анализа установили несоответствие номенклатурной группы выпуска продукции и затрат, а также исправили это несоответствие и как результат, счет 20.01.1 закрылся правильно.

3. При расчете себестоимости не закрываются затратные счета

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

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

Это может быть сделано или вследствие ошибки, либо умышленно, но в любом случае субсчета счета 20 при таком обрезанном расчете себестоимости не закроются.

1. Либо пометить на удаление «старый» документ расчета себестоимости, и создать новый и провести его, или

2. В самом проведенном документе расчета себестоимости восстановить автоматически весь перечень необходимых операций.

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

Тогда проверив отчеты «Ведомость учета затрат» и «Оборотно-сальдовую ведомость (бух.) по счету 20.01.1 мы обнаружим, что себестоимость затрат не закрылась и не перенеслась на выпуск продукции.

Точно также в оборотно-сальдовой ведомости по счету 20.01.1 видно, что затраты не закрылись

Для исправления ситуации переходим в документ «Расчет себестоимости» и по кнопке «Заполнить» - «Список действий», восстанавливаем все действия документа.

После этого перепроводим документ расчет себестоимости.

Далее производим проверку по отчетам: «Ведомость по учету затрат»

Видно, что затраты распределены на выпуск продукции.

Оборотно-сальдовая ведомость по счету 20.01.1

Видно, что затраты закрылись

4. При расчете себестоимости 20 счет полностью закрывается, но себестоимость рассчиталась с ошибками в документе «Расчет себестоимости» по регистру учета затрат

Часто сверки Оборотно-сальдовой ведомости по счету 20 бывает недостаточно, например, счет 20 закрывается полностью, но в самом расчете себестоимости выдаются ошибки в разделе по регистру учета затрат, тогда на помощь приходит отчет «Ведомость по учету затрат».

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

Рассмотрим указанные действия в программе на примере.

В регламентном документе «Расчет себестоимости» возникла ошибка после проведения по регистру учета затрат.

При формировании оборотно-сальдовой стоимости видно, что затраты по счету 20.01.1 закрылись полностью, но в данном случае, только одного отчета «Оборотно-сальдовая ведомость» недостаточно для понимания ошибки и ее устранения.

Для анализа ошибки необходимо сформировать отчет «Ведомость по учету затрат»

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

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

Для этого в структуре отчета выберем показатель регистратор и оставим в группировке только статью затрат, код статьи затрат и регистратор

И наконец, сформировать ОСВ по счету 20.01.1 и отчет «Ведомость по учету затрат».

(6) подожди.. ты конкретизируй.. тут или "вылет по ошибке приложения" или же расчёт "уходит в туман". Это разные проблемы.

Если большое время расчёта - нужно смотреть вначале что тормозит.. какая загрузка процессора, ОЗУ, дисковой подсистемы, сетевой подсистемы. А вот вылет по "ошибка приложения" - это другая песня

(9) (скромно потупясь и шаркая ножкой)
Если через столько лет отсутствия меня помнят - то да, это я :-))))
90 % случаев просто в туман уходит. Вылетало тока на 1 серванте, но больше на нем не запускаем, там возможно чего то и с самой 1с.
Самое интересное что где то на последних циклах итераций виснет. Хорошо, ещё 1 момент - восстанавливаем базу из бэка, двухдневной давности - расчет проходит. документов влияющих на расчет в этот период времени не вводилось
(14) если на файловой проходит, то тогда сразу вопрос "что за сиквел" и что с настройками СУБД (какой уровень восстановления)?
sql 2008 утилита SQL Server 2008 R2 BPA проблем не показала
модель восстановления - полная
(17) а смысл в "полной"? Попробуй тоже самое на Simple
как вариант у тебя трабла с транзат-логами
нет - не в этом дело. базу подняли с полного бэкапа - а там нормально зафиксированные тразакт логи.

(19) так посмотрите в профайлере на чём висит 1с-ка. На какой транзакции.

Но если в файловом считается, то я бы в первую очередь бы попробовал в Simple mode режима восстановления

Но если в файловом считается, то я бы в первую очередь бы попробовал в Simple mode режима восстановления - можно попробовать. но тогда не работает это правило, тогда как бэк 2 х дневной давности рассчитывается замечательно. Щас попробуем базу перенести на другой скуль сервер и там просчитать.

Восстановили из бэкапа, модель рековери - симпл.
Последнии строки в профайлере sql перед тем как повиснуть (они имеют статус успешно выполеных):

exec sp_executesql N'SELECT DISTINCT
_AccumRg20843_Q_000_T_001._Fld20845RRef AS f_1,
_AccumRg20843_Q_000_T_001._Fld20848_TYPE AS f_2,
_AccumRg20843_Q_000_T_001._Fld20848_RTRef AS f_3,
_AccumRg20843_Q_000_T_001._Fld20848_RRRef AS f_4
FROM
_AccumRg20843 _AccumRg20843_Q_000_T_001 WITH(SERIALIZABLE)
WHERE
_AccumRg20843_Q_000_T_001._Period >= P1 AND _AccumRg20843_Q_000_T_001._Period <= @P2 AND _AccumRg20843_Q_000_T_001._RecordKind = CAST(@P3 AS NUMERIC(1,0)) AND _AccumRg20843_Q_000_T_001._Fld20861RRef = @P4 AND _AccumRg20843_Q_000_T_001._Fld20844RRef = @P5',N'P1 datetime,@P2 datetime,@P3 numeric(1),@P4 varbinary(16),@P5 varbinary(16)','4010-07-01 00:00:00','4010-07-31 23:59:59',1,0xB1C1B65F81E8332F47A5049E67485A6C,0x912F0030849E083511DEA8C4B41FBBBD

Что имеем: платформа 8.3.16.1359, УПП 1.3 (1.3.152.3), PostgreSQL (тестировалось и на MS SQL), производственная организация, партионный учет, многопередельное производство.

Если вы столкнулись с такой же или похожей проблемой, то эта статья может натолкнуть на решение и сэкономить вам время.

Первым делом, следует выполнить пересчет итогов регистров - правда в контексте этой задачи, у меня ничего не изменилось.

Далее заходим в конфигуратор, запускаем режим отладки (F5) - запускается режим предприятия - находим нужный документ расчета себестоимости - возвращаемся в конфигуратор - активируем режим замера производительности:

возвращаемся в предприятие - запускаем проведение расчета себестоимости - ждем окончания.

После того, как расчет себестоимости завершен, возвращаемся в конфигуратор и останавливаем замер производительности:

Итак, мой результат:

В глаза сразу бросается первая строка, мы видим, что данная строка кода выполняется 32 раза, 2 268,979787 секунд (

38 минут) и занимает 85,61% всего времени выполнения проведения расчета себестоимости.

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

Ставим точку останова на данной строке кода:

Снова возвращаемся в предприятие и еще раз проводим расчет себестоимости, пока выполнение кода не остановится на нашей точке:

Выделяем ЗапросПоЗатратамНаВыпуск нажимаем Shift + F9:

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

У меня уже встроена эта подсистема и чтобы получить запрос из отладки со всеми параметрами в пользовательском режиме, мне достаточно нажать SHIFT + F9 и написать Отладить() , указав в качестве параметра свой запрос, далее нажать вычислить:

В режиме предприятия открывается консоль запросов, уже с заполненным текстом и параметрами, остается только выполнить:

Запрос возвращает 285 строк, за 195 секунд. Я решил проанализировать прошлые месяцы, меняя параметры периода в запросе и увидел, что действительно в прошлых месяцах количество строк было примерно в 3.5 раза меньше, (вспоминаем постановку задачи, выполнялось за 10 минут, стало за 40) действительно, пропорционально увеличению записей в регистре, увеличилось и время расчета себестоимости, к слову, записи увеличились обоснованно, из-за включения серий.

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

Это не устраивает.

Возвращаемся к нашему запросу и анализируем его:

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

Фирма 1С не рекомендует использовать вложенные запросы без особой потребности и предлагает заменять их временными таблицами или соединениями таблиц, замечая при этом, что результат такого изменения может быть другим. Такая рекомендация объясняется тем, что при использовании вложенных запросов оптимизатор СУБД не всегда может правильно определить размер выборки вложенного запроса и построить оптимальный план обращений к физическим таблицам базы данных, что сильно (иногда в десятки раз) может замедлить выполнение запроса.

Прислушаемся к совету, модернизируем запрос, заменив все вложенные запросы на временные таблицы, проиндексировав их по полях соединений(ниже будет итоговый текст запроса):

выполняем запрос в консоли:

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

проводим расчет себестоимости, смотрим результаты замера:

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

так же выполняется 32 раза, но теперь за 26 секунд вместо 2 268,979787! и занимает всего 6.43% от общего расчета себестоимости, вместо 85,61%

Время выполнения этой строки увеличилось в 87 раз!

В заключении, еще хочется обратить ваше внимание на эти статьи по ускорению расчета себестоимости, возможно в вашем случае они будут более подходящими: