МиниКейс "Закрытие месяца в УПП без остановки работы системы (Партионный учёт)"

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

Предистория:

Запускал УПП на большом заводе с переходом с конфигурации 1С 7.7 «Производство+Услуги+Бухгалтерия». И на предприятии была принята такая практика, когда в период закрытия базы останавливали работу системы. Соответственно пользователи системы не могли ничего делать. Остановка нужна для для выполнения необходимых регламентных процедур: перепроведение базы, расчет себестоимости и т.п. С приходом УПП, были охвачены все участки учёта на заводе, а это значит, что и 1С должно работать круглосуточно. И остановить работу пользователей из-за необходимости закрытия базы на полдня-день теперь стало просто нереально.

Проверялось на релизе:

1С 8.2.17.157, УПП 1.3.31.1

Особенности завода:

Применяется Партионный учёт (не РАУЗ) и ордерная схема движения запасов, необходимое время для закрытия месяца — 18 часов.

Предлагаемая схема:

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

Последовательность действий:

  1. В основной базе закрывается доступ к документам закрываемого периода. Необходимо, чтобы не было коллизий при обратой загрузке данных в основную базу
  2. Выгрузка данных из основной базы и загрузка в резервную по плану обмена «Полный»
  3. Установка границы последовательности для всех последовательностей, которые будут задействованы при закрытии. Выполняется с помощью обработки Установка границы последовательности.Установка границы последовательности
  4. Регистрация документов в резервной базе в восстанавливаемых последовательностях. Проблема в том, что при загрузке документов в резервную базу, эти документы не регистрируются в последовательностях резервной базы. И при запуске процедуры восстановления последовательности они будут попросту пропущены. Используется обработка Регистрация документов в последовательности. Правда мне пришлось её незначительно модифицировать под особенности ордерной схемы в УПП.Регистрация документов в последовательности
  5. Восстановление последовательностей. Можно воспользоваться стандартной процедурой восстановления, но я предпочитаю использовать обработку Восстановление последовательностей интервалами, которая восстанавливает последовательность с шагом 15 минут. И при возникновении ошибки в оформлении документов, граница последовательности не будет сбрасываться — максимальный сброс будет на 15 минут.
    Восстановление документов в последовательности
  6. Выполнение остальных регламентных процедур описанных в бизнес-процессе «Закрытие месяца».
  7. Выгрузка данных из резервной базы в основную по плану обмену «Полный».
  8. Установка границ последовательностей на начало следующего месяца.

 P.S. А как Вы справляетесь с такого рода задачей? Поделитесь своим опытом!

6 Comments

  1. Kom-off

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

    Reply ↓
  2. axxell

    Добрый день!

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

    Если не секрет, что за обработка по переносу данных?

    Reply ↓
  3. Kom-off

    (2) Сам написал, на основе стандартной, только облегчил ее, и, самое главное, по сравнению со стандартной, в свою обработку вставил обработчик ошибок. У меня камнем преткновения работы этой схемы было то, что загрузка готовых данных в рабочую производится в момент работы пользователей и зачастую загрузка «вылетает» с ошибкой, чаще всего «конфликт блокировок транзакций». Так вот, моя обработка, во-первых, обрабатывает не один файл, а несколько (это задается при выгрузке данных из копии, тоже своей обработкой, и тоже на основе стандартной), это позволяет при возникновении ошибки, не грузить данные с самого начала, а начинать загрузку с файла, при загрузке которого произошел сбой. Это раз. А, во-вторых, в саму обработку загрузки добавлен обработчик ошибок, который отрабатывает при записи объекта. Если при записи произошла ошибка, то обработка сначала ждет, а потом делает еще одну попытку и так несколько раз. При этом интервал ожидания между попытками записи и количество самих попыток настраиваются при запуске обработки. Как то так…

    Reply ↓
  4. Kom-off

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

    Reply ↓
  5. Gandalf Белый

    Что-то слабовато для названия «Закрытие месяца…», открывая статью думал здесь увидеть, что-то наподобие: какие регистры выравнивать, с чем сверять, какие счета закрывать, что проверять при закрытии и т.д.

    а сколько пользователей у вас в базе?

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

    Кстати есть обработка которая перепроводит документы и если возникает блокировка, то она несколько раз пытается его провести…

    мы так и делаем, только единственное последовательность не востанавливаем и не устанавливаем и вообще не трогаем ))

    Reply ↓
  6. padlik07

    (5) Gandalf Белый, Особенности завода:

    Применяется Партионный учёт (не РАУЗ) и ордерная схема движения запасов, необходимое время для закрытия месяца — 18 часов.

    А в ночь можно выкраить часов 14 которых не достаточно. Посему скорее всего и была придумана эта хитрая схема.

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *