gifts2017

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

Опубликовал Александр Тарасинский (axxell) в раздел Администрирование - Распределенная БД (УРИБ, УРБД)

Предлагается схема закрытия месяца на предприятии с круглосуточной работой в 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. А как Вы справляетесь с такого рода задачей? Поделитесь своим опытом!

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Kom-off (Kom-off) 24.02.13 13:17
Идея хороша, у самого такая схема в ходу уже несколько лет. Однако, несколько замечаний. Пункт 4, совсем не обязательно гнать документы из рабочей в резервную и далее проводить их дополнительную обработку. Как вариант, в моей схеме просто делается копия базы средствами SQL, после чего в копии базы делается очистка всех зарегестрированных на узел плана обмена "Полный", предназначенный для схемы обмена, данных. Т.е. с точки зрения этого специального узла, предназначенного для схемы обмена база становится девственно чиста. А когда приходит время переливать данные обратно, то на этот узел плана обмена будут зарегестрированы только измененные данные. Их то и заливаем обратно в рабочую. При этом, у меня нет необходимости останавливать рабочую базу даже на пару часов, поскольку была реализована собственная обработка загрузки, при помощи которой это можно было организовать.
2. Александр Тарасинский (axxell) 24.02.13 14:58
Добрый день!
По поводу копии - действительно, все просто. Правда у меня для копии есть еще 1 функция - быть резервной базой в случае сбоя и проверки корректности данных. Причем база работает на другом сервере 1С.
Если не секрет, что за обработка по переносу данных?
3. Kom-off (Kom-off) 24.02.13 16:39
(2) Сам написал, на основе стандартной, только облегчил ее, и, самое главное, по сравнению со стандартной, в свою обработку вставил обработчик ошибок. У меня камнем преткновения работы этой схемы было то, что загрузка готовых данных в рабочую производится в момент работы пользователей и зачастую загрузка "вылетает" с ошибкой, чаще всего "конфликт блокировок транзакций". Так вот, моя обработка, во-первых, обрабатывает не один файл, а несколько (это задается при выгрузке данных из копии, тоже своей обработкой, и тоже на основе стандартной), это позволяет при возникновении ошибки, не грузить данные с самого начала, а начинать загрузку с файла, при загрузке которого произошел сбой. Это раз. А, во-вторых, в саму обработку загрузки добавлен обработчик ошибок, который отрабатывает при записи объекта. Если при записи произошла ошибка, то обработка сначала ждет, а потом делает еще одну попытку и так несколько раз. При этом интервал ожидания между попытками записи и количество самих попыток настраиваются при запуске обработки. Как то так...
4. Kom-off (Kom-off) 24.02.13 16:42
(3)+ Да, чуть не забыл. Чтобы пользователи могли бы по-человечески работать в процессе загрузки данных, то в обработку загрузки я еще добавил механизм пауз между определенным количеством объектов. Т.е., например, можно настроить так, что между каждой сотней записанных объектов обработка будет делать паузу 3 секунды, а потом следующая сотня и так далее. Ну, как бы количество жалоб на низкое быстродействие информационной базы в моменты загрузки данных, резко снизилось, я бы сказал, практически исчезло.
5. Gandalf (Gandalf Белый) 26.02.13 10:38
Что-то слабовато для названия "Закрытие месяца...", открывая статью думал здесь увидеть, что-то наподобие: какие регистры выравнивать, с чем сверять, какие счета закрывать, что проверять при закрытии и т.д.
а сколько пользователей у вас в базе?
неужели так критично запустить перепроведение документов в рабочей базе, хотя бы с вечера, к полуночи они бы и провелись, а утром можно было бы посмотреть ошибки.
Кстати есть обработка которая перепроводит документы и если возникает блокировка, то она несколько раз пытается его провести...
мы так и делаем, только единственное последовательность не востанавливаем и не устанавливаем и вообще не трогаем ))
6. Павел Силуянов (padlik07) 26.02.13 11:13
(5) Gandalf Белый, Особенности завода:
Применяется Партионный учёт (не РАУЗ) и ордерная схема движения запасов, необходимое время для закрытия месяца - 18 часов.
А в ночь можно выкраить часов 14 которых не достаточно. Посему скорее всего и была придумана эта хитрая схема.