Автоматичний режим блокування неприпустимий в цій транзакції. Переклад конфігурації на керовані блокування. VIII. Розрахунок кількості і суми для списання

Сьогодні мова піде про блокування як на рівні 1С 8.3 і 8.2, так і на рівні СУБД. Блокування даних - обов'язковий елемент будь-якої системи, кількість користувачів в якій більше одного.

Нижче я розпишу, як працюють блокування, і яких типів вони бувають.

Блокування - це інформація про те, що ресурс системи захоплений іншим користувачем. Існує думка, що блокування - це помилка. Ні, блокування - це неминуча міра в багато користувачів для поділу ресурсів.

Шкода системі можуть принести тільки надлишкові ( «зайві») блокування, це ті блокування, які блокують зайву інформацію. Такі блокування необхідно навчитися усувати, вони можуть привести до неоптимальною роботі системи.

Блокування в 1С діляться умовно на об'єктні і транзакційні.

Об'єктні бувають, в свою чергу, оптимістичними і песимістичними. А транзакційні можна розділити на керовані і автоматичні.

Об'єктні блокування 1С

Даний вид блокувань повністю реалізований на рівні платформи 1С і ніяк не впливає на СУБД.

Отримайте 267 відеоуроків по 1С безкоштовно:

песимістичні блокування

Це блокування спрацьовує, коли один користувач щось змінив у формі довідника, а другий намагається так само змінити об'єкт в формі.

оптимістичні блокування

Дана блокування порівнює версії об'єкта: якщо два користувачі відкрили форму, і один з них змінив і записав об'єкт, то другого під час запису система видасть помилку, що версії об'єктів відрізняються.

Транзакційні блокування 1С

Механізм тразакціонних блокувань 1С набагато цікавіше і більш функціональний, ніж механізм об'єктних блокувань. У цьому механізмі беруть активну участь блокування на рівні СУБД.

Невірна робота транзакційних блокувань може привести з наступних проблем:

• проблема втраченого зміни;
• проблема брудного читання;
• неповторяемость читання;
• читання фантомів.

Детально ці проблеми були розглянуті в статті про.

Автоматичні транзакційні блокування 1С та СУБД

В автоматичному режимі роботи за блокування цілком і повністю відповідає СУБД. Розробник в даному випадку абсолютно не бере участі в процесі. Це полегшує працю програміста 1С, однак створення інформаційної системи для великої кількості користувачів на автоматичних блокувань небажано (особливо для СУБД PostgreSQL, Oracle BD - при модифікації даних вони повністю блокують таблицю).

Для різних СУБД в автоматичному режимі використовуються різні ступені ізоляції:

• SERIALIZABLE на всю таблицю - файловий режим 1С, Oracle;
• SERIALIZABLE на записи - MS SQL, IBM DB2 при роботі з не об'єктними сутностями;
• REPEATABLE READ на записи - MS SQL, IBM DB2 при роботі з об'єктними сутностями.

Керовані режим транзакційних блокувань 1С та СУБД

В всю відповідальність на себе бере розробник прикладного рішення на рівні 1С. При цьому СУБД встановлює досить високий рівень ізоляції для транзакцій - READ COMMITED (SERIALIZABLE для файлової СУБД).

При виконанні будь-якої операції з БД менеджер блокувань 1С аналізує можливість блокування (захоплення) ресурсу. Блокування одного і того ж користувача завжди сумісні.

Дві блокування НЕ сумісні, якщо: встановлені різними користувачами, мають несумісні види (виняткова / колективна) і встановлені на один і той же ресурс.

Фізична реалізація блокувань в СУБД

Фізично блокування є таблицю, яка знаходиться в БД під назвою master. Сама таблиця блокувань носить ім'я syslockinfo.

Таблиця умовно має чотири поля:

1. ВД блокує сесії SPID;
2. що саме заблоковано RES ID;
3. тип блокування - S, U або X MODE (Насправді в MS SQL їх 22 типу, проте в зв'язки з 1С використовується тільки три);
4. стан блокування - може приймати значення GRANT(Встановлена) і WAIT(Очікує своєї черги).

Система «1С: Підприємство» дозволяє використовувати два режими роботи з базою даних: режим автоматичних блокувань в транзакції і режим керованих блокувань в транзакції.

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

При роботі в режимі керованих блокувань система «1С: Підприємство» використовує набагато нижчий рівень ізоляції транзакцій в СУБД, що дозволяє значно підвищити паралельність роботи користувачів прикладного рішення. Однак, на відміну від режиму автоматичних блокувань, даний рівень ізоляції транзакцій вже не може сам по собі забезпечити виконання всіх правил роботи з даними в транзакції. Тому при роботі в керованому режимі від розробника потрібно самостійно управляти блокуваннями, що встановлюються в транзакції.

У зведеному вигляді відмінності при роботі в режимі автоматичних блокувань і в режимі керованих блокувань наведені в наступній таблиці:

	вид блокування	Рівень ізоляції транзакцій
автоматичні блокування
файлова БД	таблиць	Serializable
MS SQL Server	записів
IBM DB2	записів	Repetable Read або Serializable
PostgreSQL	таблиць	Serializable
Oracle Database	таблиць	Serializable
керовані блокування
файлова БД	таблиць	Serializable
MS SQL Server	записів	Read Commited
IBM DB2	записів	Read Commited
PostgreSQL	записів	Read Commited
Oracle Database	записів	Read Commited

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

Робота з керованими блокуваннями засобами вбудованої мови
Для управління блокуваннями в транзакції призначений об'єкт вбудованої мови БлокіровкаДанних. Примірник цього об'єкта може бути створений за допомогою конструктора і дозволяє описати необхідні простору блокувань і режими блокувань. Для установки всіх створених блокувань використовується метод Заблокувати () об'єкта БлокіровкаДанних. Якщо цей метод виконується в транзакції (явній або неявній), блокування встановлюються і при закінченні транзакції будуть зняті автоматично. Якщо метод Заблокувати () виконується поза транзакції, то блокування не будуть встановлені.

Умови задаються на рівність значення поля вказаною значенням або на входження значення поля в зазначений діапазон.
Умови можуть бути задані двома способами:

● за допомогою явної вказівки імені поля і значення (метод УстановітьЗначеніе () об'єкта ЕлементБлокіровкіДанних);
● за допомогою вказівки джерела даних, що містить необхідні значення (властивість ІсточнікДанних об'єкта ЕлементБлокіровкіДанних).

Для кожного елемента блокування може бути заданий один з двох режимів блокування:

● розділяється,
● винятковий.

Таблиця сумісності керованих блокувань виглядає наступним чином

Розділяється режим блокування має на увазі, що заблоковані дані не можуть бути змінені інший транзакцією до закінчення поточної транзакції.
Винятковий режим блокування має на увазі, що заблоковані дані не можуть бути змінені інший транзакцією до закінчення поточної транзакції, а також не можуть бути прочитані інший транзакцією, яка встановлює, що розділяється блокування на ці дані.

Особливості роботи в режимі «Автоматичний і керований»

При роботі в режимі управління блокуваннями Автоматичний і керований слід враховувати дві особливості:

● Незалежно від режиму, зазначеного для даної транзакції, система буде встановлювати відповідні керовані
блокування.
● Режим управління блокуваннями визначається транзакцією самого «верхнього» рівня. Іншими словами, якщо до моменту початку транзакції була розпочата інша транзакція, то починає транзакція може бути виконана тільки в тому в режимі, який встановлений для вже виконується транзакції.

Розглянемо ці особливості більш докладно.
перша особливість полягає в тому, що навіть якщо для транзакції використовується автоматичний режим управління блокуваннями, система встановить додатково і відповідні керовані блокування під час запису даних в цій транзакції. З цього випливає, що транзакції, що виконуються в режимі керованих блокувань, можуть конфліктувати з транзакціями,
що виконуються в режимі автоматичного управління блокуваннями.
друга особливість полягає в тому, що режим управління блокуваннями, що вказується для об'єкта метаданих в конфігурації або вказується при початку транзакції в явному вигляді (як параметр методу НачатьТранзакцію ()), Є лише «бажаним» режимом. Фактичний режим управління блокуваннями, в якому буде виконуватися транзакція, залежить від того, чи є даний виклик початку транзакції першим, або до цього моменту вже розпочато інша транзакція в даній сесії системи «1С: Підприємство».
Наприклад, якщо потрібно управляти блокуваннями при записі наборів записів регістра, при проведенні документа, то керований режим блокувань повинен бути встановлений як для самого регістру, так і для документа, оскільки запис наборів записів регістра буде виконуватися в транзакції, відкритої при записі документа.

Прискорити 1С натисканням декількох кнопок 2. Керовані блокування. September 4th, 2011

Якщо прочитати методику переведення конфігурації на керовані блокування від 1С - можна там знайти багато всього цікавого і лякає. Насправді все просто: У властивостях конфігурації міняєте режим блокування даних - "Керований". Усе. Можу вас привітати - ви тільки що перейшли на керовані блокування. Насправді все трохи складніше - але не на багато.

Для початку невеликий теоретичний екскурс - навіщо потрібні блокування: У кого є доступ звичайно можна прочитати тут: http://kb.1c.ru/articleView.jsp?id\u003d30 1С перейнялися написати досить доступну статтю про блокування даних. У кого ж доступу немає в двох словах опишу для чого потрібні блокування:

Приклад 1. Якщо після включення керованих блокувань нічого не робити, і при цьому почати паралельно проводити 2 документа (один з них адже все одно на частку секунди раніше), то отримаємо приблизно таку картину:

транзакція 1	транзакція 2	стан залишків
початок	|	1 шт
|	початок	1 шт
|	|	1 шт
читання залишків	|	1 шт
|	читання залишків	1 шт
|	|	1 шт
Списання з залишків	|	0 шт
|	списання залишків	-1 шт
завершення	|
	завершення

Що тут не так? Контроль залишків дав збій. 2-ий документ встиг прочитати залишки раніше, ніж 1-й встиг їх записати. При цьому побачив, що на залишках 1 штука і спокійно списав їх слідом за першим. Варто зазначити, що за фактом блокування тут все-таки будуть. 2 документа не зможуть списати залишки одночасно, це необхідно для логічної цілісності БД, але для розв'язання прикладної задачі в даному прикладі навряд чи корисно.

Тепер постараємося виправити ситуацію - в коді проведення документа пропишемо установку ексклюзивної керованої блокування безпосередньо перед читанням залишків:

Ну тепер, коли розібралися навіщо блокування потрібні залишається тільки встановити керовані блокування там де це потрібно: а саме - тільки там де проводиться контроль залишків. Якщо у вас в базі менеджер має право провести документ незалежно від того є товар (гроші) на залишках чи ні, навіщо вам тоді блокування? Можете їх просто не встановлювати, чи прописати і закомментировать до кращих часів. Якщо ж у вас проводиться контроль залишків то як правило це 3-4 регістра, ну максимум 10-ок. Контроль можна підвісити як в загальні процедури і функції, так і в модулі набору записів РН. Код гранично простий, відкриваємо синтаксис помічник - дивимося:

Блокування \u003d Новий БлокіровкаДанних;
ЕлементБлокіровкі \u003d Блокування. Додати ( "РегістрНакопленія.ТовариНаСкладах") ;
ЕлементБлокіровкі. УстановітьЗначеніе ( "Якість", Довідники. Якість. НайтіПоКоду ( "1"));
ЕлементБлокіровкі. Режим \u003d РежімБлокіровкіДанних. винятковий;
ЕлементБлокіровкі. ІсточнікДанних \u003d ДокументОб'ект. ВозвратнаяТара;
ЕлементБлокіровкі. ІспользоватьІзІсточнікаДанних ( "Номенклатура", "Номенклатура");
ЕлементБлокіровкі. ІспользоватьІзІсточнікаДанних ( "Склад", "Склад");
Блокування. Заблокувати ();

Власне все відразу зрозуміло - блокуємо "товари на складх", 1 вимір стає в явному вигляді, значення 2-х інших візьмемо з джерела даних - ТЧ документа.

Ті хто читав книжки по 8.2 напевно пам'ятають про "Нової логіці проведення" - коли контроль залишків проводиться після запису рухів документа. Задвалісь питанням навіщо це? А ось цю ж табличку перерісуем так що контоль залишків і блокування будуть після запису рухів:

транзакція 1	транзакція 2	стан залишків
початок	|	1 шт
|	початок	1 шт
|	|	1 шт
Списання з залишків	|	0 шт
|	Списання з залишків	-1 шт
Блокування	|	-1 шт
читання залишків	спроба блокування	-1 шт
|	Очікування на блокування	-1 шт
|	Очікування на блокування	-1 шт
завершення	Очікування на блокування	-1 шт
	Блокування	-1 шт
	читання залишків	-1 шт
	|	-1 шт
	відмова	0 шт

Різниця з увазі не значна - приріст продуктивності отримуємо за рахунок того що на час списання залишків (запис їх в базу, що, власне займає час) блокування ще немає. Блокування виникає пізніше до кінця транзакції, куди винесено контроль негативних залишків, бізнес логіці додатки це цілком задовольняє.

Знаючи для чого блокування потрібні можна дійсно ними управляти виходячи з бізнес завдань які ви вирішуєте. СУБД розробляються виходячи з припущення забезпечення максісальной захисту даних. У разі якщо ви, наприклад, здійснюєте банківські транзакції блокування повинні бути скрізь і на максимальному рівні. Краще заблокувати зайві записи, ніж допустити суперечливість даних.

У разі ж якщо ви продаєте булочки або кулькові ручки, на навряд чи вам потрібно настільки багато блокувань. Браком і пересортом по людської вини ви втрачаєте в сотні разів більше, ніж могли б у разі одночасного проведення двома пользователеямі двох однакових докуметов відвантаження.

Для варіювання між такими різними завданнями в СУБД придумали рівні ізоляції. Встановлюючи рівень ізоляції транзакцій можна сказати СУБД які блокування накладати в різних випадках (при записі і при читанні в транзакції) в різних випадках накладаються S (можна читати не можна писати) або X (не можна ні читати ні писати) блокування.

Так в автоматичному режимі у вас майже завжди буде рівень ізоляції SERIALIZABLE, який буде накладати X блокування де потрібно і де не треба, що буде істотно псувати вам життя

А в керованому у вас буде READ COMMITED, який буде накладати і тут же знімати S блокування при читанні, і X тільки під час запису. Найхитріший рівень. Швидко накладається S блокування якраз дозволяє перевірити не накладена чи де на ці дані X блокування, що і забезпечує читання тільки узгоджених даних, як прийнято для даного рівня ізоляції, а в разі якщо ви прочитали і виконали действя, Рекомендований в попередній статті, щось не буде навіть S блокування при читанні, таким чином на рівні СУБД буде блокуватися тільки запис під час запису - що правильно і необхідно для сограсованності даних.

Як же ви вчините з керованими блокуваннями - тільки ваше рішення. Але я б рекомендував не поспішати їх встановлювати. Я зустрічав компанії в яких був автоматичний режим блокування, при цьому слово "закатували блокування" звучало навіть з вуст генерального директора, і при цьому був відключений контроль негативних залишків ....

При розрахованому на багато користувачів режимі роботи в 1С блокування даних є необхідним механізмом. Саме вони захищають від ситуацій, схожих на одночасний продаж двома менеджерами одного і того ж товару різним клієнтам. У платформі 1С передбачено два види блокувань - керований і автоматичний. Перший з режимів блокувань в 1С є оптимальним для високонавантажених систем з великою кількістю користувачів. Розглянемо його докладніше.

Особливості керованого режиму блокувань

На відміну від автоматичного, керований режим дозволяє системі 1С використовувати власний менеджер блокувань і застосовувати менш жорсткі правила СУБД. Тобто вбудований механізм дозволяє враховувати бізнес-логіку додатка і більш плавно і точно встановлює обмеження на читання і запис даних. Зміна режиму блокувань може дати істотний приріст продуктивності і дозволить скоротити кількість помилок блокувань транзакції. Відбувається це за рахунок додаткової перевірки менеджером блокувань на відповідність обмеженням, встановленим всередині системи перед тим, як передати запит СУБД.

Істотний мінус полягає в тому, що розробнику доводиться самостійно контролювати несуперечність даних при їх введенні і обробці. Цілком ймовірно, що після включення режиму керованих блокувань доведеться написати чимало перевірок, щоб досягти колишнього рівня безпеки. Незважаючи на це, багато компаній вважають за краще перейти на керований режим, якщо можливості це дозволяють.

При розробці програмних перевірок і обмежень важливо пам'ятати про особливість керованих блокувань - будь-яка з них тримається до кінця транзакції. З цього випливає, що програмістам треба встановлювати блокування ближче до кінця транзакції, щоб ймовірність очікування була мінімальна. Якщо вам потрібно зробити розрахунки і записати їх результат, то накладення блокування правильніше прописати після розрахунків.

Ще однією розповсюдженою проблемою блокувань в 1С є імпорт документів. Багато розробники використовують досить просте рішення - при завантаженні не проводити документи, а тільки створювати. А після, за допомогою простого механізму, провести всі завантажені дані в багатопотоковому режимі за ключовими характеристиками - номенклатурі, партнерам або складах.

Алгоритм переходу на керовані блокування 1С виглядає просто, але некваліфікований адміністратор 1С може помилитися, виправити які буде складно. Найчастіше бувають проблеми з надмірним або недостатнім рівнем блокувань. У першому випадку будуть виникати проблеми з швидкодією системи, аж до аварійних зупинок кластера серверів. Недостатні блокування небезпечні помилками в обліку при одночасній роботі користувачів.

Перемикання в керований режим

Незважаючи на те, що нижче буде представлений повний алгоритм переходу на режим керованих блокувань, виконувати його повинен досвідчений фахівець. Якщо не розуміти принципів роботи механізму блокувань в 1С та СУБД, то навряд чи вийде правильно написати обмеження. Але це ставитися до складних конфігурацій. для простих конфігурацій початківці розробники можуть успішно закінчити процес перемикання режиму і набратися досвіду:

• В першу чергу потрібно змінити режим управління блокуванням даних для конфігурації. Для цього в конфігураторі відкрийте дерево конфігурації і у властивостях кореневого елемента в розділі «Сумісність» змініть режим. Виберіть пункт «Автоматичний і керований», щоб не виникало помилок до того, як всі об'єкти будуть переведені на новий режим;

• Тепер настає черга документів. Адже саме з їх допомогою ми реєструємо всі події, які потрібно контролювати. Починати переклад на керовані блокування 1С потрібно з найбільш завантажених документів. На вкладці «Інше» вказуємо режим блокувань «Керований»;
• Знаходимо всі регістри, пов'язані з уже обробленим документом і переводимо їх в керований режим за аналогічним документам методу;
• Наступний етап включає в себе пошук і зміна всіх транзакцій зі зміненими об'єктами. Сюди входять і явні зміни, що включають ключові слова «НачатьТранзакцію ()», так і всі обробники документів і регістрів, що включають транзакції;

НачатьТранзакцію () Для Кожного ДокументНаУдаленіе З СпіскаДокументов Цикл Об'ектДокумента \u003d ДокументНаУдаленіе.ПолучітьОб'ект (); Спроба Об'ектДокумента.УстановітьПометкуУдаленія (Істина); Виняток Відмова \u003d Істина; ОтменітьТранзакцію (); Повідомити ( "Не вдалося видалити документ" + Об'ектДокумента); перервати; КонецПопиткі; КонецЦікла; ЗафіксіроватьТранзакцію ();

• Виключити оператор мови запитів «ДЛЯ ЗМІНИ». Замінити його можна об'єктом «БлокіровкаДанних» з необхідністю змінити запит і алгоритм його виклику і обробки.

Останні два етапи є найбільш складними і вимагають кваліфікації від розробника, але саме вони є гарантами підтримки робочого стану обліку в системі.

Основні причини переходу на керовані блокування:

• Основна причина - рекомендація 1С: Експерта на підставі показань або 1С: ЦУП
• Проблеми з паралельною роботою користувачів ()
• Використання Oracle, PostgreSQL і.

Вартість робіт:

Суть керованих блокувань

При роботі в автоматичному режимі управління блокуванням 1С: Підприємство встановлює високу ступінь ізоляції даних в транзакції на рівні СУБД. Це дозволяє повністю виключити можливість отримання не цілісною або некоректних даних без будь-яких спеціальних зусиль з боку прикладних розробників.

Це зручний і правильний підхід при невеликій кількості активних користувачів. Ціна простоти розробки - деяка кількість надлишкових блокування на рівні СУБД. Ці блокування пов'язані як з особливостями реалізації механізмів блокувань в самій СУБД, так і з тим, що СУБД не може враховувати (і не враховує) фізичний зміст і структуру об'єктів метаданих 1С: Підприємства.

При роботі з високою конкуренцією за ресурси ( велика кількість користувачів) в якийсь момент вплив надмірності блокувань ставати помітним з точки зору продуктивності при паралельному режимі.

Після перекладу конфігурації в керований режим в платформі актівізуруется додатковий функціонал «менеджера блокувань» і контроль за цілісністю даних здійснюється тепер не на стороні СУБД, а на стороні сервера 1С. Це збільшує навантаження на залізо сервера 1С (потрібні швидше процесори і більше пам'яті), і фактично вносить навіть невелике уповільнення (кілька відсотків), проте куди істотніше покращує ситуацію з блокуваннями (менше блокувань за рахунок блокувань на об'єкт, а не на комбінацію таблиць, менше область блокування і в деяких випадках менше час життя блокувань на читання, тобто не до кінця транзакції). За рахунок цього загальна паралельність поліпшується.

Нові конфігурації фірми 1С реалізовані відразу в керованому режимі.

• Питання: Чи можна спочатку зробити аудит, а потім переклад на УБ?

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

• Питання: Для перекладу на УБ, який саме потрібно надати доступ - RDP, TeamViewer? Або можна вам вислати файл-конфігурації?

Відповідь: Ми намагаємося не обмежувати однією конкретною технологією віддаленого доступу, годиться будь-яка технологія віддаленого доступу. Якщо для Вас не має значення, то практичніше RDP.
Ми можемо виконати оптимізацію по висланого файлу конфігурації, але тоді не зможемо налагодити деякі реальні дані і Вам доведеться уважніше тестувати. Якщо ми виконуємо оптимізацію на копії бази, то ми можемо ретельніше протестувати, перш ніж передамо Вам результат роботи.

• Питання: У нас 10-ть штатних програмістів, які кожен день щось змінюють у конфе. Використовується загальне сховище конфігурації ». Як буде організовано взаємодію при перекладі на УБ? Або всіх програмістів потрібно відправляти у відпустку?

Відповідь: Як правило наші зміни робляться протягом пари днів. Решту часу припадає на тестування внесених змін, В тому числі з точки зору необхідної логіки визначається бізнесом а не технічними міркуваннями. ми можемо внести зміни в окремий файл конфігурації cf, а потім Ваш програміст внесе в сховище. У відпустку ні кого відправляти не доведеться. В інших варіантах взаємодії треба просто домовиться які об'єкти планують захопити Ваші розробники, щоб ми вибудували план робіт, зручний обом сторонам. Як правило цілком конфігурацію захопити Вашим розробникам не потрібно, або віддасте на день нам «кермо».