Як внести значні зміни до типової конфігурації 1С, зберігши можливість її оновлення з

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

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

Загальні правила внесення змін до об'єктів конфігурації:

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

Особливості зміни ролей (ролі в 1С мають пріоритет доступу над забороною і доступ до об'єктів і реквізитів формується через складання набору ролей, що надаються):

По можливості не потрібно змінювати типові ролі, а краще додавати нові: або на основі типової і відобразити це в імені ролі, або як додаткову до вже наявної типової роліролі, але «роздаючу» права на додані нами об'єкти конфігурації;
При налаштуванні новостворених ролей краще дотримуватися правил створення ролей для типових конфігурацій – це встановлення галочок для ролі «Встановлювати права для реквізитів та табличних частин за умовчанням» та «Незалежні права підлеглих об'єктів», якщо у вас, звичайно, немає якихось ДУЖЕ вагомих аргументів простив установки цих галочок. Якщо ви раптом створюєте свою роль з повними правами, то зручно встановити галочку «Встановлювати права для нових об'єктів», але слід пам'ятати, що інтерактивна роль «Інтерактивне видалення» також буде встановлюватися для нових об'єктів за умовчанням (!) і її потрібно буде зняти вручну .
Буває, що потрібно забрати права на деякі об'єкти у типової ролі, наприклад, «Користувач» - такі дії повинні мати серйозне обґрунтування та слід розуміти, що це значно збільшить час оновлення ролей – потрібно буде щоразу порівнювати цю роль та вручну налаштовувати доступ до об'єктів. . Як альтернатива запропонованого рішення можна розглянути створення, наприклад, регістру відомостей, за записами якого ми будемо визначати доступ до об'єктів конфігурації того чи іншого користувача, але це вимагає значного написання коду.

Особливості зміни інтерфейсів:

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

Є ще один спосіб вирішення для роботи користувачів з обмеженим інтерфейсом без зміни типових – створення спеціалізованих робочих столів та панелей, але розробка такого робочого місця може тривати не один місяць.

Зміна форм:

Зміна макетів:

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

Зміна підсистем:

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

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

Зміна коду модулів:

//@@@ Код до зміни:

Обробники подій змінити не завжди вдасться, але можна організувати перехоплення обробників подій форм з використанням оператора Виконати (приблизно як опсано тут: http://kb.mista.ru/article.php? >

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

Буде приємно отримати відгуки спільноти, і сподіваюся на цінні зауваження, можливо, щось ще можна оптимізувати, про що ми не здогадалися.