При створенні регламентного завдання в конфігураторі можна вказати кілька параметрів, давайте розберемо кожен з параметрів окремо:
- ім'я методу - процедура, яка зголоситься при активації регламентного завдання
- Найменування - назва регламентного завдання, яке буде, виводяться користувачеві
- Ключ - специфічне реквізит основне его призначення не допустити одночасного виконання регламентних завдань з однаковим ключем. В один момент часу в базі може виконуватися тільки одне регламентне завдання з таким ключем.
- Розклад - задаємо розклад для завдання, що коли і з якою періодичністю буде запускатися.
- Використання - тут все просто стоїть галочка - завдання буде виконуватися, чи не стоїть не буде
- Зумовлене - завдання, у яких немає цієї галочки, виникають програмно тоді коли настає момент часу вказаний в розкладі, а зумовлені завдання створюються в момент запуску програми
- Кількість повторів - тут все ясно, як і з останньої вкладкою
До речі варто звернути вашу увагу на те, що в типових конфігураціях зумовленими регламентними завданнями, як правило, є лише кілька завдань таких як «Оновлення конфігурації».
Крім моніторингу завдань ми може за допомогою даної обробки ми можемо провести зміну параметрів завдань, наприклад зміна розкладу, користувача від імені якого будуть виконуватися завдання, або взагалі відключити виконання того чи іншого регламентного завдання. Особисто я при створенні завдань вважаю за краще створювати спеціального користувача і вказую, що завдання виконуються від його імені.
Потрібно пам'ятати, що регламентні завдання виконуються без участі людини, і в зв'язку з цим можуть виникати різні неприємні ситуації. Так хорошим тоном вважається будь-які зміни в алгоритмах роботи програми робити на копії бази, наприклад автоматизація завантаження довідників номенклатури з прайсів постачальника. На одній фірмі було кілька баз, які автоматично обмінювалися даними, налаштовуючи автоматичне завантаження в копії бази, напарник забув відключити автоматичний обмін, в результаті в усі бази фірми потрапило безліч сміття з прайсу, оскільки в копію спочатку затягнулася номенклатура, а потім через автоматичний обмін розповзлася по інших баз. Для того щоб такого не відбувалося бажано в консолі управління сервером відключати для копій баз виконання регламентних завдань.