Ошибки закрытия месяца 1с erp

• 

  Александрова Анна
  Специалист отдела сопровождения 1С

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

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

Рис. 1

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

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

Во-вторых, через «Все функции» открываем из списка регистр сведений Задания к закрытию месяца (Рис. 2).

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

Рис. 2

В записях этого регистра сведений находим нужную нам дату (ориентируемся на дату «слетевшей» регламентной операции и её наименование). В нашем случае это Формирование финансового результата за декабрь 2017 года. Нажимаем правой кнопкой мыши на нужную запись и удаляем её по кнопке «Удалить» (Рис. 3).

Рис. 3

А теперь смотрим регламентные операции по закрытию месяца (Рис. 4). Ничего заново выполнять не нужно!

Рис. 4

Для предотвращения таких ситуаций в будущем рекомендую своевременно устанавливать Дату запрета изменения данных для пользователей программ Комплексная автоматизация 2.4 и ERP 2.4.

Надеюсь, данная статья помогла Вам! Если у вас еще есть вопросы по работе в программе, или вы не знаете, как она настроена — предлагаю Вам провести аудит программы 1С и наладить учет без ошибок.

_______________________________________

Автор статьи: Специалист отдела сопровождения Александрова Анна. Дата обновления статьи 07.12.2018

Подпишитесь на нашу рассылку
и получите еще больше статей от экспертов по 1С!

Необходимые знания для оценки производительности операции «Закрытия месяца» в 1С:ERP

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

Статья предназначена для читателей, которые знают основы теории графов и раздел линейной алгебры, который посвящен решению систем алгебраических линейных уравнений (СЛАУ) с вещественными коэффициентами. Также потребуется знакомство с концептуальным устройством регистров ERP, в том числе с расширенной аналитикой учета. Перед прочтением статьи хорошо будет ознакомиться с материалом из ИТС https://its.1c.ru/db/v8319doc
#bookmark:dev:TI000002121 по решению систем линейных алгебраических уравнений.

Итак, первая статья цикла об оптимизации 1С:ERP представлена вашему вниманию.

Проводим отладку для оценки скорости «Закрытия месяца»

Параметры отладки

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

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

Далее, при выборе операции «Распределение затрат и расчет себестоимости», появляется окно настройки параметров:

Опишем каждый из параметров более подробно.

Параметр «Перед расчётом очищать старые расчетные движения»

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

Стандартное поведение системы следующее:

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

Почему важна именно такая математика? Это прежде всего позволяет экономить время этапа записи сформированных движений.

Давайте осознаем написанный алгоритм на примере.

Пусть после первого закрытия сформировались такие движения в регистре себестоимость

Далее провели приобретение услуг «Доставки»:

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

Таким образом первые две записи не изменились и поэтому не были перезаписаны.

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

• ВидЗапасов,
• Партия,
• АналитикаУчетаПартий,
• АналитикаФинансовогоУчета,
• ВидДеятельностиНДС,
• ДокументИсточник,
• РасчетНеЗавершен.

А также может значительно усложнять попытки расследования причин неправильного закрытия.

Предположим, в предыдущем примере ВидДеятельностиНДС в ВидеЗапасов стоял неправильно — «Продажа не облагается НДС».

Суммы изменены намеренно в приобретении, чтобы показать результат до «Закрытия»:

И после:

Как видим, даже после «Закрытия» ВидЗапасов стоит неправильный, при том, что во всех строках регистра стоит «Продажа облагается НДС».

Поэтому для целей отладки в сложных случаях рекомендуется все-таки очищать старые расчетные движения.

Параметр «При проведении документа не сохранять старые расчётные движения»

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

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

Для демонстрации изменена «Сумма» в регистре «Себестоимость», без перепроведения документа. Получилось, что «Сумма» и «СуммаНДС» совпадают:

После «Закрытия» получили:

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

Параметр «Контролировать корректность разбиения на порции»

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

При этом может случиться ситуация, когда не все сформированные движения по одному документу попадут в одно фоновое задание. Это можно продемонстрировать строчками кода из процедуры РасчетСебестоимостиПрикладные
Алгоритмы.РазделитьВременную
ТаблицуНаПорции:

Видно, что разделение на порции происходит просто циклом по всей таблице, без какой-либо проверки на «Регистраторы».

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

Проверка же добавляет следующий код:

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

Параметр «Игнорировать некорректные первичные движение документов»

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

Но иногда хочется посмотреть, а что же дальше:

• Возникают ли ошибки на следующих этапах?
• Корректно ли распределяются затраты по базам?
• Корректно ли формируется себестоимость (с допуском на ошибки)?

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

Параметр «Не выполнять оптимизацию данных при расчёте партий»

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

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

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

Параметр «Не выполнять оптимизацию цепочек при расчёте партий»

Стандартное поведение системы предполагает оптимизацию нумерации узлов подграфа. Если не сильно вдаваться в математику, то нумерация вершин должна быть «правильной» (наличие дуги (vi,vj) означает, что i<j). При этом абсолютная правильность возможно только для ациклических графов.

Алгоритм, который в оптимизированном виде применяется в ERP представлен на следующем рисунке:

Топологическая сортировка вершин ориентированного графа без циклов

Эффективный алгоритм нумерации вершин:

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

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

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

Правильная нумерация важна для нахождения критического пути в графе, а это в свою очередь важно для правильного формирования матрицы для решения СЛАУ при расчете себестоимости.

К сожалению, это так же довольно трудоемкий этап, поэтому для целей отладки можно пропускать данный пункт.

Параметр «Не выполнять расчёт себестоимости»

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

Этап расчета предварительной себестоимости по трудоемкости сопоставим с расчетом фактической себестоимости (на самом деле он использует тот же механизм).

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

Параметр «Не сдвигать период расчёта по окончании расчёта»

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

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

Параметр «Исправлять пустой регистратор в сформированных движениях»

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

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

Параметр «Отключение выполнения этапа „Распределение затрат и расчет себестоимости“ в прошлых периодах»

Стандартное поведение системы предполагает ошибку и остановку расчета себестоимости, если расчет в предыдущих периодах выполнен не был.

Иногда (в очень редких случаях) требуется расчет только конкретного периода невзирая на некорректный расчет в предыдущих периодах. Задания к расчету себестоимости за прошлые периоды при этом не удаляются.

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

Параметр «Отключение записи сформированных движений»

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

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

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

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

Параметр «Формировать промежуточный протокол расчёта после выполнения каждого этапа»

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

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

Чтение протокола расчета

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

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

Опишем рекомендуемый алгоритм работы с данным отчетом:

1. Если в расчете были диагностированы ошибки их необходимо найти в тексте по символу «!».

Например, рассмотрим картинку:

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

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

2. Опускаемся в самый низ отчета и смотрим список «ТОП-10 самых длительных этапов».

Посмотрим на следующую картинку:

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

3. Далее смотрим на первый (самый длительный) этап в предыдущем списке и ищем его описание выше в «Протоколе».

Какие важные блоки в описании шага мы можем использовать?

3.1. Сформированы движения по регистрам:

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

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

3.2. Сформированы временные таблицы:

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

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

3.3. Дополнительная информация об этапе:

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

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

Например, если данных по «Остаткам» на этом этапе 1 млн, при этом у вас количество различной номенклатуры вместе с партиями не превышает 100 тысяч (можно взять КонсольЗапросов или «Универсальный отчет» и проверить запросом к РегистрНакопления.ТоварыОрганизаций).

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

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

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

• Большая глубина обхода (более 30).
• Ненулевое количество не рассчитанных записей (выдаются соответствующие ошибки).

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

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

Принципы обработки этапов «Закрытия месяца» в 1С:ERP

«Погружаемся» в код соответствующего блока. Точка входа в алгоритм расчета себестоимости находится (для актуального на текущий момент партионного учета версии 2.2) в общем модуле РасчетСебестоимости.РасчитатьВсе():

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

1. Подготовка данных:

• Получение данных (формирует временную таблицу Данные).
• Получение цепочек из исходных данных (формирует временные таблицы Источники и Приемники).
• Заполнение партий в цепочках (заполняет таблицу ПараметрыРасчета.Распределение
  Партий.РасчетныеПартии).
• Помещение данных в таблицу-приемник и очистка вспомогательных временных таблиц.

2. Распределение партий по прямым расходам:

• Выборка данных из заранее подготовленных ВТ в п. 1.
• Распределение по себестоимости:
  • Подготавливаются таблицы УзлыКорректировкиСебестоимости и СвязиУзловКорректировкиСебестоимости.
  • Подготавливаются таблица ДанныеДляНумерации для исходных данных.
  • Происходит нумерация узлов графа (узлами графа выступают партии).
  • Подготавливаются таблица СтоимостьПартий (к узлам графа добавляется исходная стоимость).
  • Распределение партий (ДвиженияБезСтоимости).
  • Подготавливаются таблица ДанныеДляНумерации для распределенных партий (ВТУзлыСПолямиРаспределения).
  • Происходит нумерация узлов нового графа.
  • Подготавливаются таблица ВТРезультатРасчета
    Предварительный (к узлам графа добавляется исходная стоимость).
  • Решение системы линейных уравнений для расчета фактической стоимости.
  • Загрузка решения во временную таблицу ТаблицаРешений.
  • Подготавливаются таблица ВТЦеныУзлов.
  • Сохранение движений.
• Сохранение движений и очистка вспомогательных временных таблиц.

Несколько более подробно (но для релиза ERP 2.4.10):

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

4. Распределение партий по партиям прочих расходов происходит по алгоритму, аналогичному п. 1. Однако для постатейных затрат также происходит расчет фактической себестоимости. по алгоритму аналогичному для прямых расходов.

Практические случаи долгого «Закрытия месяца» в 1С:ERP

Экспоненциальный рост времени расчета себестоимости при закрытии месяца

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

Дальше погружаемся в код еще глубже и обращаем внимание на строку в протоколе расчета «РасчетСебестоимостиПрикладные
Алгоритмы.ПостроитьЦепочкиДвижений». Отметим, что модуль ПостроитьЦепочкиДвижений вызывается практически для всех этапов расчета себестоимости и является одним из ключевых узких мест расчета. Выше мы описали, как можно было добраться до этой строчки кода.

Для понимания причин сложности рассмотрим следующий запрос:

Проблемой данного запроса является «Внутреннее соединение» таблицы «Данные» с собой.

Далее по тексту модуля идет двойной цикл:

Как видим, шаблон &Условия формируется динамически в зависимости от «Приемника» и «Источника».

Пример таблицы типов приемника и типов источника приведен ниже:

Проблемы возникают в случае, если эти условия получаются слишком общими, например, для ТипаПриемника = «Возврат без документа источника» и ТипаИсточника = «Потребление» условие выглядит:

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

В одном из наших проектов в ВТЦепочки32 попало 75 млн данных, при том, что строк с ТипомПриемника = «Возврат без документа источника» было 3 тысячи записей, а строк с типом = «Потребление» было 34 тысячи записей. И т. к. направления деятельности и ВидДеятельностиНДС везде совпадали, мы получили почти полное произведение этих записей.

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

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

Заметим, что в релизе 2.5.7 проблема остается актуальной.

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

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

Рост времени «Закрытия месяца» из-за раздельного учета НДС

Рассмотрим РасчетСебестоимостиНДС.
РаспределитьНДСПоСебестоимости.

Еще один пример потенциально проблемного запроса выглядит так:

Вновь мы видим «Внутреннее соединение». Проблема заключается в части кода, в которой этот запрос размещен (для экономии места запрос выше заменен на троеточие):

Запрос в цикле — это уже сама по себе проблема для производительности, но еще большую проблему может вызывать «Внутреннее соединение» по узкому условию «НомерУзлаИсточник = УзелПриемник».

Например, на одном из наших проектов, 1,4 млн записей превращались в 48 млн записей к 23й итерации:

Сам по себе этот цикл, как видим, выполнялся сравнительно быстро, зато следующий за этим шагом этап РассчитатьСистемы
ЛинейныхУравнений длился 1 час и 12 минут. Это важно для понимания того факта, что, естественно, существует прямая зависимость от количества входных данных и времени расчета СЛАУ.

Напомним, из курса вычислительной математики: трудоемкость точных методов решения СЛАУ в общем случае кубическая. Трудоемкость же итерационных методов в общем случае квадратическая, но сильно зависит от собственных чисел исходных матриц и получаемого из них числа обусловленности вплоть до невозможности сходимости метода.

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

В нашем конкретном случае нам повезло, что Заказчик смог обойтись без установки данного флага. Это решило проблему. Однако отметим два момента:

1. Еще более сложной и трудозатратной для расчёта, а значит и критически сложной для анализа является следующая настройка — «Раздельный учет постатейных производственных затрат по налогообложению НДС».
   Если ваша Организация не может обойтись без этого флага, имеет широкую номенклатуру постатейных производственных затрат и различные виды деятельности по НДС, то готовьтесь, что этап распределения НДС по себестоимости будет занимать львиную долю времени расчета себестоимости.
2. Если снять данный флаг нельзя, то отметим куда же нужно копать далее. Важными таблицами для понимая являются две таблицы:
   • ДанныеДляНумерации,
   • СтоимостьПартийНДС.

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

Вторая таблица является немного урезанной копией таблицы ПриходыТоваровНДС2_4_
ДляРешенияСЛУ. Эта таблица ограничена приходами товаров только за текущий месяц, но также у конкретных клиентов может быть весьма большой (считаем большими все таблицы, у которых больше 1 млн записей). Накладываясь, таблицы ДанныеДляНумерации и СтоимостьПартийНДС могут приводить к бесконечному количеству комбинаций, и если с СтоимостьПартийНДС бороться практически нельзя, т. к. это конкретные приходы, то остается минимизировать ДанныеДляНумерации. Как? Это уже другая история, которая зависит от конкретного случая.

Длительное «Закрытие месяца» из-за отнесения на себестоимость общехозяйственных расходов

Рассмотрим РасчетСебестоимостиПрикладные
Алгоритмы.РассчитатьПартии
ПоГруппамПодграфов.

Как же не упомянуть проблемы в рекурсии?

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

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

Можно попытаться решить эту проблему, увеличив значение по умолчанию 650 (помните, мы обещали показать случай, когда даже такого уровня вложенности может не хватить) на 1000, либо даже 2000, но это не решение задачи, а «заметание мусора под ковер». И, конечно, это может привести к росту времени выполнения процедуры расчета. Но, к сожалению, в большинстве случаев это не помогает, поэтому обычно необходимо погружаться в проблему глубже.

Для понимания процесса попробуем разобрать его с помощью примера:

На данной схеме представлен упрощенный пример расчёта графа себестоимости. Если упрощенно мы имеем три цеха:

• прачечная,
• котельная,
• ремонтный цех.

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

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

Крайне рекомендуем сделать этот пример своими руками в 1С:ERP и посмотреть (в том числе в отладчике) что происходит.

В конкретном случае (у реального заказчика) эта проблема привела к такой ситуации:

Видно, что одна и та же продукция имеет разницу в себестоимости в 3 раза (списанные прямые расходы на партии при этом не отличаются).

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

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

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

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

Важное замечание по анализу данных

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

• Глобальные, использующиеся на многих этапах, часть из которых сильно видоизменяется от этапа к этапу.
• Локальные, использующиеся в рамках данного этапа и удаляющиеся при его завершении.

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

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

Запрос.МенеджерВременныхТаблиц.Таблицы["ИмяВременнойТаблицы"].ПолучитьДанные().Выгрузить()

Основная проблема отладки заключается в том, что в «Закрытии месяца» ВТ могут быть очень объемными, поэтому прежде, чем выполнить предыдущий код, можно проверить количество данных, если добавить к предыдущему запросу «Количество()».

Если данных в ВТ не очень много — примерно 40-50 тысяч строк (от 10 столбцов) полученную временную таблицу еще вполне возможно выгрузить стандартным способом в таблицу в конфигураторе и сохранить ее далее в Excel.

Если данных в ВТ больше 50 тысяч, но меньше 200 тысяч строк (от 10 столбцов), выгрузку таблицы в конфигураторе еще можно дождаться (ждать придется очень долго), но сохранить в Excel скорее всего уже не получится.

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

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

Дополнительные примеры ситуаций с долгим «Закрытием месяца» в 1С:ERP

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

1. Возвраты от клиентов/организаций/…, не привязанные к партии. Т. е. не привязанные к реализации или заказу. Любой такой возврат пытается восстановить НДС и без партионной принадлежности делает это просто со всей имеющейся номенклатуры. А ее может быть много…
2. Документы с отрицательным количеством. По той же причине, что в п. 1, с разницей в том, что для них никогда не подбираются партии, что автоматически приводит к проблемам.
3. Статьи затрат, распределяемые на себестоимость, у которых аналитика не обязательна. Такую аналитику зачастую забывают поставить, что естественно приводит к распределению затрат на всю имеющуюся номенклатуру на складе/в подразделении.
4. Возвратная тара, если она передается и принимается с какой-то ценностью. Мало того, что при возврате тары возникает п. 1, так еще и дополнительно тара может в периоде реализовываться и возвращаться несколько раз, с различной номенклатурой. Что в итоге может приводить к неразрешимым циклам в расчете.
5. Выпуск продукции или работ, потребляемых непосредственно в этом подразделении, без изменения аналитики учета затрат. Это вызывает проблему «выпуска на самого себя» (или «змеи, пожирающей свой хвост»), что при закрытии периода может вызвать построение СЛУ, не имеющей решения.
6. Использование опции «Распределение дополнительных расходов по выбывшим товарам» (НСИ и администрирование — Финансовый результат и контроллинг — Учет товаров). Выбывших товаров может быть много, ограничения на период нигде не устанавливается, выводы можете сделать сами.

Ну и, конечно, нужно отметить «сервисные» функции и особенности, которые следует учитывать при «Закрытии месяца». К ним можно отнести следующее:

1. Должны быть рассчитаны итоги по всем регистрам на нужный месяц.
2. Закрытие месяца — тяжелая процедура, которая нагружает систему саму по себе. Требовать от нее быстроты во время полноценной работы большого количества пользователей бесполезно. Поэтому «Закрытие месяца» обычно ставят либо на ночь, либо на выходные, когда активность пользователей минимальна.
3. Изменение в документах/регистрах в момент «Закрытия месяца» в целевом периоде приводит к остановке процедуры закрытия, а если оно происходит довольно долго (> суток), то это весьма неприятно для всех участников процесса. При этом дату запрета установить на следующий период нельзя, т. к. это приведет к невозможности самого закрытия. Поэтому, если п. 2 не выполним, то необходимо решать проблему организационными методами (регламент «Закрытия», в котором предусмотрены наказания за вмешательство в процесс закрытия)
4. «Закрытие месяца» — именно та процедура, в которой сильно помогает параллелизм запросов на уровне SQL. Поэтому если в «обычной» жизни у вас max degree of parallelism = 1(2/3), то для «Закрытия» рекомендуется ставить его в 0(4/5/…). Более подробно этот кейс будет рассмотрен в следующей статье по проблемам «Закрытия месяца».

Продолжение в статье: Расследование и оптимизация расчета операции «Закрытие месяца» в 1С:ERP. Часть II.

Часто бывает так, что регламентная операция «Закрытие месяца» становится одним из наиболее трудоёмких процессов в организации. Сегодня рассмотрим одни из самых частых ошибок пользователей при выполнении операции «Закрытие месяца» на примере конфигурации 1С: Управление торговлей ред. 11.5. В конце статьи подведём итог, какие правила нужно соблюдать чтобы свести ошибки к минимуму.

Ошибка №1:

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

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

Исправить наличие дублей можно типовой обработкой «Поиск и удаление дублей».

Ошибка №2:

При оформлении передач товаров между организациями документ зависает в обработке закрытия месяца:

Сколько бы раз не создавался документ, каждый раз программа просит создать новый. В чём проблема? В первую очередь необходимо проверить аналитику номенклатуры. По разным причинам программа не всегда может подставить верную аналитику/ключ номенклатуры. Для выяснения причины некорректной подстановки реквизитов может потребоваться достаточно много времени. Как вариант можно рассмотреть одно из решений. В приведённом примере воспроизведена ошибка по номерам ГТД на тестовой базе.

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

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

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

Ошибка №3:

При оформлении оприходования документ зависает в обработке закрытия месяца. Решение аналогично ошибке №2. В документ поставляется не та аналитика, не тот номер ГТД.

Ошибка №4:

Обнаружены не распределенные на себестоимость остатки расходов по организации. Рекомендация: проверить организацию в документах (должна совпадать) или исправить статью затрат. Пример:

Обратим внимание, что организация разная. Исправляем организацию, и ошибка исчезнет.

Ошибка №5:

Обнаружены отрицательные остатки партий в регистре себестоимости по организации. Рекомендация: сформировать универсальный отчёт по регистру «Себестоимость товаров» и «Товары организаций». Найти расхождения по количеству. Восстановить цепочку, при необходимости оформить «Оприходования».

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

Основные рекомендации для сведения ошибок в закрытии месяца к минимуму:

1) Включенный контроль остатков товаров как в организациях, так и на складах.

2) Минимизировать работу с документами в закрытом периоде.

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

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

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

Примеры:

• Заказ клиента – Расходный ордер на товары (если отгрузка с ордерного склада) – Реализация товаров и услуг –Поступление денег (Приходный кассовый ордер или поступление на расчётный счёт)

• Заказ поставщику – Приобретение товаров и услуг – Приходный ордер на товары (если приход на ордерный склад) – Расход денег (Расходный кассовый ордер или расход с расчётного счёта)

• Таможенная декларация должна быть оформлена позднее документа поступления товаров, т.к. сперва мы покупаем товар, а потом оформляем его на таможне. Порядок будет следующий: Заказ поставщику – Приобретение товаров и услуг – Таможенная декларация – Приходный ордер на товары.

5) Отсутствие дублей справочников.

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

Освойте программы 1С:УТ и торговый функционал в 1С:КА 2 за 40 часов!

На курсе “1С:Управление торговлей 8″, ред. 11.4 и торговый функционал в «1С:Комплексная автоматизация 2” вы научитесь эффективно вести торговый и управленческий учет.

Ошибки при закрытии месяца.

Я

   TanyaERP

21.12.21 — 17:19

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

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

   DrShad

1 — 21.12.21 — 17:23

продолжайте наблюдения и держите нас в курсе

   Kassern

2 — 21.12.21 — 17:26

(0) а что отладка говорит? Ловите событие, когда идет сообщение об ошибке и смотрите какую проверку делает система, там же смотрите какой запрос выполняется. Анализируете его, при желании в консоли запросов тестите. На основании полученных данных определяете, что вам нужно сделать, чтобы условие ошибки не выполнялось

   FIXXXL

3 — 21.12.21 — 18:11

(0) аналитики какие-то разъезжаются, если не «схлопывается»

смотреть надо конкретно две записи и думать почему не «схопнулось»

   Krendel

4 — 21.12.21 — 18:28

Таня ЕРП с полом мужским, кто-нить ведь клюнет

   d_monah

5 — 21.12.21 — 18:55

(4) Спасибо Крендель,я чуть не повелся,хотел уже предложить ей ЕРП настроить

   Krendel

6 — 21.12.21 — 19:16

   d_monah

7 — 21.12.21 — 20:09

(6) Внедрение процесс довольно интересный,творческий.Тут нужен специалист.Интересно,вот зачем ты в профиль то полез?Видать уже попадался?)))

   Krendel

8 — 21.12.21 — 20:15

(7) ну подкати, мы не заметим

   rozer76

9 — 21.12.21 — 20:20

   rozer76

10 — 21.12.21 — 21:23

Предположение что под полными правами РЛС добавляет к запросам…

   Гений 1С

11 — 21.12.21 — 21:58

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

   d_monah

12 — 21.12.21 — 22:40

(10) Победил?

   TanyaERP

13 — 22.12.21 — 09:20

(0) аналитики какие-то разъезжаются, если не «схлопывается»

смотреть надо конкретно две записи и думать почему не «схопнулось»

А почему они не схлопываются, какие частые причины?

Я понимаю, что это форум для специалистов, но как быть простому пользователю, которому надо решить эту проблему?((

   TanyaERP

14 — 22.12.21 — 09:20

Таня ЕРП с полом мужским, кто-нить ведь клюнет

При регистрации нет «окна» пол, только потом в профиле. Было не отредактировано.

   Kassern

15 — 22.12.21 — 09:25

(13) «но как быть простому пользователю?» — это не тривиальная задача «Закрытие месяца», особенно в ЕРП. Простой пользователь пишет заявку в хелпдеск с проблематикой, далее уже она распределяется на компетентных сотрудников ИТ отдела. Если этого у вас нет и своей 1с программиста тоже нет, то аутсорс вам в помощь. Желательно, чтобы вам объяснили в чем причина таких ошибок и как правильно вести учет.

   Krendel

16 — 22.12.21 — 09:28

(15) причина их ошибок в 90% случаев это специалист, который их обслуживает

   Фрэнки

17 — 22.12.21 — 09:28

   FIXXXL

18 — 22.12.21 — 09:37

(16) но есть ведь Гений

   Kassern

19 — 22.12.21 — 09:42

(16) либо отсутствие оного

   Krendel

20 — 22.12.21 — 09:43

(19) отсутствие оного не может быть, ибо откуда-то брали обработки

   Krendel

21 — 22.12.21 — 09:44

Или спецом перенастраивали базу, чтобы ее убить

   TanyaERP

22 — 22.12.21 — 09:49

(13) «но как быть простому пользователю?» — это не тривиальная задача «Закрытие месяца», особенно в ЕРП. Простой пользователь пишет заявку в хелпдеск с проблематикой, далее уже она распределяется на компетентных сотрудников ИТ отдела. Если этого у вас нет и своей 1с программиста тоже нет, то аутсорс вам в помощь. Желательно, чтобы вам объяснили в чем причина таких ошибок и как правильно вести учет.

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

   FIXXXL

23 — 22.12.21 — 09:51

   TanyaERP

24 — 22.12.21 — 09:51

   Фрэнки

25 — 22.12.21 — 10:20

(24) Скриншоты прилагать можно,не скрепочкой,но ссылкой на файлопомойку)).Закрытие месяца действительно  вопрос сурьезный,не на 5 минут,лучше пригласить специалиста.А так да,смотреть регистры.Пол то вы поправили,а дату рождения нет,и фото нет))),это 10+20% успешного закрытия месяца.Времени у Вас много,целых 3 месяца.