Модуль 1С

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

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

Головне. Модуль 1С — це місце, де написана логіка системи. Якщо довідники і документи зберігають дані, то модулі визначають, що система робить із цими даними: перевіряє, рахує, проводить, друкує, вивантажує, імпортує або змінює.

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

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

Вступ

У 1С є не тільки довідники, документи, регістри, звіти й обробки. За цими об’єктами часто стоїть програмний код.

Цей код зберігається в модулях.

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

Наприклад, користувач бачить документ “Реалізація товарів”.

Але за цим документом може бути код, який:

перевіряє залишки;
підставляє ціни;
перевіряє ліміт боргу;
формує проводки;
створює рухи по складах;
перевіряє ПДВ;
формує друковану накладну;
вивантажує дані на сайт;
відправляє повідомлення менеджеру;
блокує проведення при помилках.

Усе це може бути реалізовано в модулях.

Що таке модуль у 1С

Модуль у 1С — це текстова частина конфігурації, у якій зберігається код вбудованою мовою 1С.

Модуль може містити:

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

Простий приклад процедури:

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    
    Если Не ЗначениеЗаполнено(Контрагент) Тогда
        Сообщить("Не заповнено контрагента.");
        Отказ = Истина;
    КонецЕсли;
    
КонецПроцедуры

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

Простими словами. Модуль 1С — це місце, де програміст описує поведінку системи: що робити, коли користувач відкриває форму, записує документ, натискає кнопку або запускає обмін.

Вбудована мова 1С

Код у модулях пишеться вбудованою мовою платформи 1С. Її часто називають:

вбудована мова 1С;
мова 1С;
BSL;
1C:Enterprise script;
мова конфігурації.

Приклад функції:

Функция РассчитатьСумму(Количество, Цена)
    
    Возврат Количество * Цена;
    
КонецФункции

Ця функція приймає кількість і ціну, а повертає суму.

Для чого потрібні модулі

Модулі потрібні для реалізації логіки системи.

Вони використовуються для:

перевірки реквізитів;
проведення документів;
формування рухів по регістрах;
підстановки значень;
розрахунку сум;
розрахунку цін;
розрахунку знижок;
розрахунку собівартості;
формування друкованих форм;
виконання запитів;
роботи з файлами;
інтеграції з сайтами;
інтеграції з банками;
інтеграції з API;
роботи з XML, JSON, CSV;
обробки подій форми;
створення звітів;
автоматичних регламентних дій.

Основні типи модулів 1С

У 1С є кілька типів модулів.

Тип модуля	Для чого використовується	Приклад
Модуль об’єкта	Логіка конкретного об’єкта	Проведення документа
Модуль форми	Логіка форми користувача	Натискання кнопки
Модуль менеджера	Загальна логіка роботи з типом об’єкта	Створення документа або пошук елемента
Загальний модуль	Повторно використовувані функції	Розрахунок ціни, перевірка прав
Модуль команди	Логіка окремої команди	Запуск обробки
Модуль сеансу	Дії при старті сеансу	Початкова ініціалізація
Модуль керованого додатка	Глобальна логіка клієнтського застосунку	Початкові налаштування інтерфейсу

Модуль об’єкта

Модуль об’єкта містить код, який належить конкретному об’єкту: документу, довіднику, обробці або іншому елементу конфігурації.

Наприклад, у документа “Реалізація товарів” модуль об’єкта може містити:

перевірку заповнення;
обробку запису;
проведення документа;
формування рухів;
контроль залишків;
контроль взаєморозрахунків;
розрахунок ПДВ;
роботу з табличною частиною.

Приклад:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
    
    Для Каждого СтрокаТовары Из Товары Цикл
        
        Движение = Движения.ТоварыНаСкладах.Добавить();
        Движение.ВидДвижения = ВидДвиженияНакопления.Расход;
        Движение.Период = Дата;
        Движение.Номенклатура = СтрокаТовары.Номенклатура;
        Движение.Склад = Склад;
        Движение.Количество = СтрокаТовары.Количество;
        
    КонецЦикла;
    
КонецПроцедуры

Це спрощений приклад логіки проведення документа.

Модуль форми

Модуль форми відповідає за поведінку форми, яку бачить користувач.

У модулі форми можуть бути:

обробники кнопок;
реакція на зміну поля;
відкриття допоміжних форм;
підказки;
перевірки перед записом;
оновлення табличних частин;
розрахунок підсумків на екрані;
виклик серверних процедур.

Приклад кнопки:

&НаКлиенте
Процедура РассчитатьСуммуКоманда(Команда)
    
    Объект.Сумма = Объект.Количество * Объект.Цена;
    
КонецПроцедуры

Цей код може виконуватися при натисканні кнопки на формі.

Модуль менеджера

Модуль менеджера належить типу об’єкта загалом, а не конкретному екземпляру.

Він може використовуватися для:

пошуку елементів довідника;
створення документів;
загальних методів об’єкта;
службової логіки;
запитів по цьому типу об’єкта;
інтеграційних дій.

Наприклад, у модулі менеджера довідника “Номенклатура” може бути функція пошуку товару за артикулом:

Функция НайтиПоАртикулу(Артикул) Экспорт
    
    Запрос = Новый Запрос;
    Запрос.Текст =
    "ВЫБРАТЬ
    |   Номенклатура.Ссылка
    |ИЗ
    |   Справочник.Номенклатура КАК Номенклатура
    |ГДЕ
    |   Номенклатура.Артикул = &Артикул";
    
    Запрос.УстановитьПараметр("Артикул", Артикул);
    Результат = Запрос.Выполнить().Выбрать();
    
    Если Результат.Следующий() Тогда
        Возврат Результат.Ссылка;
    КонецЕсли;
    
    Возврат Неопределено;
    
КонецФункции

Загальний модуль

Загальний модуль — це модуль, який може використовуватися з різних місць конфігурації.

У загальних модулях часто зберігають:

спільні функції;
розрахунки;
перевірки;
обмін даними;
роботу з файлами;
роботу з API;
сервісні процедури;
правила заповнення;
функції для звітів;
функції для друкованих форм.

Приклад:

Функция РассчитатьПДВ(СуммаБезПДВ, СтавкаПДВ) Экспорт
    
    Возврат СуммаБезПДВ * СтавкаПДВ / 100;
    
КонецФункции

Позначка `Экспорт` означає, що функцію можна викликати з інших модулів.

Модуль команди

Модуль команди містить код, який виконується при запуску певної команди.

Наприклад:

сформувати звіт;
вивантажити файл;
запустити обробку;
оновити ціни;
створити документи;
відправити дані;
виконати перевірку.

Приклад:

&НаКлиенте
Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды)
    
    Сообщить("Команду виконано.");
    
КонецПроцедуры

Модуль сеансу

Модуль сеансу може виконуватися при старті сеансу користувача.

Він може використовуватися для:

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

Такий код потрібно аналізувати обережно, бо він може впливати на всіх користувачів.

Клієнтський і серверний код

У керованих формах 1С код може виконуватися на клієнті або на сервері.

Позначки:

`&НаКлиенте`;
`&НаСервере`;
`&НаСервереБезКонтекста`;
`&НаКлиентеНаСервереБезКонтекста`.

Приклад:

&НаКлиенте
Процедура ПриИзмененииКоличество(Элемент)
    
    РассчитатьСуммуНаСервере();
    
КонецПроцедуры

&НаСервере
Процедура РассчитатьСуммуНаСервере()
    
    Объект.Сумма = Объект.Количество * Объект.Цена;
    
КонецПроцедуры

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

Процедури і функції

У модулях використовуються процедури і функції.

Процедура виконує дію, але не повертає значення.

Процедура ЗаписатьСообщение(Текст)
    
    Сообщить(Текст);
    
КонецПроцедуры

Функція повертає значення.

Функция ПолучитьСумму(Количество, Цена)
    
    Возврат Количество * Цена;
    
КонецФункции

Експортні процедури і функції

Якщо процедура або функція має слово `Экспорт`, її можна викликати з інших модулів.

Приклад:

Функция ПолучитьОсновнуюЦену(Номенклатура) Экспорт
    
    // Логіка отримання ціни
    
КонецФункции

Експортні функції часто є важливою частиною архітектури конфігурації.

Перед міграцією потрібно знайти такі функції, бо вони можуть використовуватися в багатьох місцях.

Обробники подій

Модулі часто містять обробники подій.

Приклади подій:

ПередЗаписью;
ПриЗаписи;
ОбработкаПроведения;
ПередУдалением;
ПриОткрытии;
ПриИзменении;
ПриСозданииНаСервере;
ПередЗакрытием;
ОбработкаЗаполнения.

Приклад:

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    
    Если СуммаДокумента <= 0 Тогда
        Сообщить("Сума документа має бути більшою за нуль.");
        Отказ = Истина;
    КонецЕсли;
    
КонецПроцедуры

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

Модуль проведення документа

Один із найважливіших модулів — модуль проведення документа.

Під час проведення документ може:

формувати рухи по регістрах;
формувати бухгалтерські проводки;
списувати товари;
оприбутковувати товари;
змінювати взаєморозрахунки;
змінювати залишки грошей;
розраховувати ПДВ;
контролювати залишки;
створювати пов’язані документи.

Приклад логіки:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
    
    Если Товары.Количество() = 0 Тогда
        Сообщить("Документ не містить товарів.");
        Отказ = Истина;
        Возврат;
    КонецЕсли;
    
    // Далі формуються рухи
    
КонецПроцедуры

Модулі і регістри

Модулі часто записують дані в регістри.

Наприклад:

залишки товарів;
взаєморозрахунки;
ціни;
курси валют;
касові залишки;
ПДВ;
бухгалтерські проводки;
табельний час;
собівартість;
виробничі витрати.

Приклад руху по регістру:

Движение = Движения.Взаиморасчеты.Добавить();
Движение.Период = Дата;
Движение.Контрагент = Контрагент;
Движение.Договор = Договор;
Движение.Сумма = СуммаДокумента;

Якщо модуль неправильно формує рухи, облік буде неправильним.

Модулі і запити

Модулі часто виконують запити.

Приклад:

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|   Остатки.Номенклатура,
|   Остатки.КоличествоОстаток
|ИЗ
|   РегистрНакопления.ТоварыНаСкладах.Остатки(&Дата) КАК Остатки
|ГДЕ
|   Остатки.Склад = &Склад";

Запрос.УстановитьПараметр("Дата", Дата);
Запрос.УстановитьПараметр("Склад", Склад);

Результат = Запрос.Выполнить();

Такий код може перевіряти залишки перед продажем.

Модулі і друковані форми

Друковані форми часто формуються через модулі.

Наприклад:

рахунок;
видаткова накладна;
акт;
ТТН;
податкова накладна;
касовий ордер;
авансовий звіт;
внутрішній бланк;
етикетка;
штрихкод.

У модулі може бути код, який:

отримує дані документа;
заповнює макет;
розраховує підсумки;
формує табличний документ;
виводить форму на друк.

Модулі і інтеграції

У старих базах 1С інтеграції часто реалізовані саме в модулях або зовнішніх обробках.

Приклади інтеграцій:

сайт;
інтернет-магазин;
маркетплейс;
банк;
CRM;
WMS;
касова система;
M.E.Doc або інший сервіс звітності;
API постачальника;
Excel-файли;
XML-обмін;
JSON-обмін;
FTP;
email;
вебсервіси.

Приклад читання JSON або XML може бути прихований у загальному модулі, зовнішній обробці або регламентному завданні.

Модулі і API

Якщо 1С інтегрувалася із зовнішніми системами, у модулях може бути код роботи з HTTP.

Приклад логіки:

HTTPСоединение = Новый HTTPСоединение("api.example.com", 443,,,,, Новый ЗащищенноеСоединениеOpenSSL);
ЗапросHTTP = Новый HTTPЗапрос("/products");
Ответ = HTTPСоединение.Получить(ЗапросHTTP);

Перед міграцією потрібно знайти всі такі місця, бо вони показують, з якими зовнішніми системами пов’язана стара база.

Модулі і файли

Модулі можуть працювати з файлами:

CSV;
XML;
JSON;
TXT;
Excel;
DBF;
ZIP;
зображеннями;
PDF;
файлами банку;
файлами обміну.

Приклад сценаріїв:

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

Модулі і регламентні завдання

Код модулів може виконуватися автоматично за розкладом.

Наприклад:

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

Перед переходом у K2 ERP потрібно знайти такі автоматичні сценарії.

Нестандартні доробки в модулях

У багатьох компаніях 1С роками доробляли.

Доробки можуть бути:

у модулі документа;
у модулі форми;
у загальному модулі;
у зовнішній обробці;
у підписках на події;
у регламентних завданнях;
у розширеннях;
у друкованих формах;
у звітах.

Приклади нестандартної логіки:

заборона продажу нижче мінімальної ціни;
автоматична знижка для VIP-клієнта;
спеціальний розрахунок собівартості;
унікальний алгоритм бонусів;
автоматичне створення замовлення постачальнику;
обмін із сайтом у нестандартному форматі;
контроль боргу контрагента;
особливий друк документів;
правила заповнення податкових реквізитів.

Чому модулі важливі для міграції

Під час міграції недостатньо перенести тільки дані.

Потрібно зрозуміти, яка логіка працювала в старій системі.

Наприклад, у 1С може бути доробка:

якщо клієнт має борг понад 50 000 грн, документ продажу не проводиться;
якщо товар має серію з простроченим терміном, продаж заборонений;
якщо ціна нижча мінімальної, потрібне погодження;
якщо покупець не платник ПДВ, формується інший тип документа;
якщо склад — “Резерв”, товар не вивантажується на сайт.

Якщо цю логіку не знайти й не перенести в K2 ERP, бізнес-процеси можуть змінитися несподівано.

Аналіз модулів перед міграцією

Перед переходом у K2 ERP потрібно проаналізувати модулі.

Потрібно знайти:

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

Карта модулів

Для міграції корисно створити карту модулів.

Модуль	Що робить	Важливість	Рішення для K2 ERP
Документ.Реализация.МодульОбъекта	Перевірка залишків, проведення продажу	Висока	Перенести правила проведення
ОбщийМодуль.ОбменССайтом	Вивантаження товарів і цін	Висока	Замінити API-інтеграцією K2 ERP
ОбщийМодуль.РасчетСкидок	Розрахунок знижок	Середня	Описати бізнес-правила
Обработка.ЗагрузкаПрайса	Імпорт цін із Excel	Середня	Реалізувати імпорт у K2 ERP
ПечатнаяФорма.Счет	Друк рахунку	Низька	Переробити шаблон

Типові проблеми модулів 1С

У старих базах часто зустрічаються проблеми:

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

Жорстко прописані значення

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

Наприклад:

Если Контрагент.Код = "000123" Тогда
    Скидка = 15;
КонецЕсли;

Або:

ПутьКФайлу = "C:\Exchange\prices.csv";

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

Паролі і токени в модулях

Іноді в старих модулях зберігаються паролі, ключі доступу або токени API.

Це погана практика.

Приклади ризикових даних:

пароль FTP;
токен API;
логін банку;
ключ сервісу;
email-пароль;
шлях до мережевої папки;
секретний ключ інтеграції.

Під час міграції такі дані потрібно не просто переносити, а переоформлювати безпечно.

Ризик безпеки. Якщо в модулях 1С є паролі, токени або ключі доступу, їх не можна переносити в нову систему без перегляду. Потрібно замінити їх на безпечне зберігання секретів і оновити доступи.

Модулі і продуктивність

Поганий код у модулях може сповільнювати систему.

Проблеми:

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

Приклад поганого підходу:

Для Каждого Строка Из Товары Цикл
    // Для кожного рядка виконується окремий запит
КонецЦикла;

Краще отримувати дані одним запитом і обробляти результат.

Модулі і помилки користувачів

Модулі можуть як захищати від помилок, так і створювати нові.

Добрий модуль:

перевіряє обов’язкові поля;
показує зрозуміле повідомлення;
не дозволяє провести неправильний документ;
логіює помилки;
не змінює дані мовчки.

Поганий модуль:

автоматично виправляє дані без пояснення;
блокує роботу незрозумілим повідомленням;
змінює документи заднім числом;
не показує причину помилки;
приховує винятки;
створює дублікати.

Модулі і права доступу

У модулях можуть бути перевірки прав.

Наприклад:

Если Не РольДоступна("ПолныеПрава") Тогда
    Сообщить("Недостатньо прав.");
    Отказ = Истина;
КонецЕсли;

Перед міграцією потрібно зрозуміти:

які перевірки прав були в коді;
які ролі використовувались;
які обмеження були не в ролях, а саме в модулях;
чи потрібно перенести ці правила в K2 ERP.

Модулі і персональні дані

Модулі можуть обробляти персональні дані:

фізичних осіб;
працівників;
табелів;
зарплати;
паспортних даних;
ІПН;
банківських реквізитів;
контактної інформації.

Під час аналізу модулів потрібно перевірити:

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

Модулі і зовнішні обробки

Частина коду може бути не в конфігурації, а в зовнішніх обробках.

Зовнішні обробки можуть:

імпортувати дані;
експортувати дані;
масово змінювати документи;
оновлювати ціни;
формувати звіти;
проводити документи;
виправляти помилки;
обмінюватися з сайтом;
працювати з банком.

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

Модулі і розширення

У деяких базах логіка винесена в розширення.

Розширення можуть містити:

додаткові реквізити;
змінені форми;
нові команди;
обробники подій;
загальні модулі;
інтеграційний код;
перевизначену логіку.

Якщо не проаналізувати розширення, можна пропустити важливі доробки.

Модулі і технічний борг

Старі модулі часто накопичують технічний борг.

Ознаки:

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

Під час переходу в K2 ERP не потрібно переносити технічний борг механічно. Потрібно переносити бізнес-сенс.

Документування модулів

Перед міграцією потрібно описати важливу логіку.

Приклад таблиці опису:

Бізнес-правило	Де знайдено	Що робить	Рішення
Контроль боргу клієнта	Модуль документа Реалізація	Забороняє проведення при боргу понад ліміт	Реалізувати в K2 ERP
Розрахунок знижки	Загальний модуль Знижки	Дає знижку за сегментом клієнта	Описати як правило цін
Обмін із сайтом	Загальний модуль ОбмінССайтом	Вивантажує товари, ціни, залишки	Замінити API

Міграція логіки з модулів у K2 ERP

Під час міграції потрібно вирішити, що робити з логікою модулів.

Можливі варіанти:

Варіант	Коли застосовується	Коментар
Перенести як бізнес-правило	Логіка актуальна і потрібна	Реалізується засобами K2 ERP
Замінити стандартним механізмом K2 ERP	У K2 ERP вже є така функція	Не потрібно копіювати старий код
Переробити	Старий код поганий, але ідея потрібна	Описується новий процес
Не переносити	Логіка застаріла	Фіксується в протоколі
Залишити в архіві	Потрібна тільки історія	Стара база використовується для перегляду

Приклад: перенесення правила контролю залишків

У 1С у модулі документа може бути правило:

Если Остаток < Количество Тогда
    Сообщить("Недостатньо товару на складі.");
    Отказ = Истина;
КонецЕсли;

У K2 ERP це потрібно описати як бізнес-правило:

Правило	Опис
Контроль залишків	Заборонити продаж, якщо доступний залишок менший за кількість у документі
Винятки	Дозволити тільки користувачам із роллю керівника складу або адміністратора
Повідомлення	Показати товар, склад, доступний залишок і потрібну кількість

Приклад: перенесення обміну з сайтом

У 1С може бути загальний модуль, який формує XML для сайту.

Наприклад:

товари;
ціни;
залишки;
характеристики;
зображення;
категорії;
статуси.

У K2 ERP краще не копіювати старий XML-код без аналізу, а описати обмін заново:

які дані потрібні сайту;
хто є джерелом істини;
як часто оновлювати;
який формат використовувати;
які помилки логіювати;
як перевіряти результат;
чи потрібен API замість файлового обміну.

Приклад: перенесення розрахунку знижок

У старому модулі може бути логіка:

якщо клієнт VIP — 10%;
якщо сума замовлення понад 100 000 грн — 5%;
якщо товар акційний — окрема ціна;
якщо менеджер має право — ручна знижка.

Перед перенесенням потрібно зробити таблицю правил:

Умова	Знижка	Пріоритет	Погодження
VIP-клієнт	10%	Високий	Не потрібно
Замовлення понад 100 000 грн	5%	Середній	Не потрібно
Нижче мінімальної ціни	Заборонено	Критичний	Потрібне погодження

Модулі і тестування після міграції

Після перенесення логіки в K2 ERP потрібно тестувати не тільки дані, а й поведінку системи.

Потрібно перевірити:

проведення документів;
контроль залишків;
розрахунок цін;
розрахунок знижок;
друковані форми;
обміни;
права доступу;
повідомлення про помилки;
інтеграції;
регламентні дії;
API;
BI-звіти;
бухгалтерські проводки;
складські рухи.

Контрольний список аналізу модулів

Перед міграцією варто перевірити:

Що перевірити	Навіщо
Модулі документів	Знайти правила проведення
Модулі форм	Знайти логіку інтерфейсу і кнопок
Загальні модулі	Знайти спільні бізнес-правила
Модулі менеджерів	Знайти службові функції
Зовнішні обробки	Знайти імпорт, експорт, масові зміни
Регламентні завдання	Знайти автоматичні процеси
Інтеграційний код	Знайти зовнішні системи
Жорсткі значення	Знайти приховані залежності
Паролі й токени	Усунути ризики безпеки

Типові помилки при аналізі модулів

Найчастіші помилки:

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

Як не треба робити

Погані підходи:

просто скопіювати старі модулі в нову систему;
переписати весь код без аналізу користі;
не питати бізнес, чи правила ще актуальні;
не шукати приховані інтеграції;
ігнорувати модулі зовнішніх обробок;
не аналізувати права доступу;
не перевіряти безпеку секретів;
не документувати знайдену логіку;
залишити 1С активною як “тимчасове джерело логіки” після запуску K2 ERP.

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

Як правильно працювати з модулями перед міграцією

Правильний порядок:

Зібрати список змінених модулів.
Зібрати всі зовнішні обробки.
Перевірити розширення.
Перевірити регламентні завдання.
Знайти інтеграційний код.
Знайти правила проведення документів.
Знайти розрахунки цін, знижок, собівартості.
Знайти контроль залишків і боргів.
Знайти роботу з файлами, XML, JSON, API.
Знайти паролі, токени й небезпечні секрети.
Описати бізнес-правила людською мовою.
Розділити актуальну й застарілу логіку.
Визначити, що реалізувати в K2 ERP.
Протестувати нові сценарії.
Зафіксувати результат у протоколі міграції.

Модулі і K2 ERP

У K2 ERP стару логіку модулів 1С потрібно переносити не як копію коду, а як зрозумілі бізнес-правила.

У новій системі це може бути реалізовано через:

налаштування процесів;
правила проведення;
перевірки;
API;
інтеграційні сценарії;
права доступу;
логіювання;
шаблони документів;
імпорт і експорт;
BI-аналітику;
регламентні задачі;
окремі модулі K2 ERP;
стандартні механізми системи.

Модулі і BI-аналітика

Модулі можуть впливати на BI непрямо.

Наприклад, якщо модуль:

змінює ціну;
розраховує знижку;
формує собівартість;
присвоює сегмент клієнта;
змінює статус документа;
розподіляє витрати;
формує рухи по складах;
змінює дату обліку.

Тоді BI-звіти залежать від цієї логіки.

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

Модулі і цифрова незалежність

Аналіз модулів 1С — це частина підготовки до виходу зі старої ризикової системи.

Компанія повинна:

знайти приховану бізнес-логіку;
описати правила;
відмовитися від застарілого коду;
прибрати небезпечні секрети;
замінити старі інтеграції;
перенести потрібні процеси в українську ERP;
не переносити технічний борг;
зменшити залежність від 1С і BAS.

Цифрова незалежність. Модулі 1С — це не просто код. Це накопичена логіка бізнесу. Під час переходу важливо забрати з них цінні правила, але не переносити стару залежність, хаос і технічний борг.

Коротко

Питання	Відповідь
Що таке модуль 1С?	Це частина конфігурації, де зберігається програмний код вбудованою мовою 1С.
Для чого потрібні модулі?	Для перевірок, проведення документів, форм, обробок, запитів, інтеграцій, друку, розрахунків і автоматичних дій.
Які бувають модулі?	Модуль об’єкта, модуль форми, модуль менеджера, загальний модуль, модуль команди, модуль сеансу та інші.
Чому модулі важливі при міграції?	У них часто зберігається нестандартна бізнес-логіка, яку потрібно знайти й перенести в K2 ERP.
Чи потрібно копіювати старий код у нову ERP?	Ні. Потрібно переносити бізнес-правила, а не технічний борг старої системи.
Що перевірити перед міграцією?	Модулі документів, загальні модулі, форми, зовнішні обробки, розширення, інтеграції, регламентні завдання, права доступу й секрети.
Яка головна помилка?	Перенести дані без аналізу модулів і потім втратити важливу логіку роботи бізнесу.
Чи є санкційні ризики у 1С і BAS?	Так. Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.

Висновок

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

Під час переходу на K2 ERP модулі потрібно аналізувати так само уважно, як довідники, документи, регістри й залишки.

Потрібно:

знайти важливу логіку;
описати бізнес-правила;
відокремити актуальні доробки від застарілих;
перевірити інтеграції;
знайти зовнішні обробки;
перевірити регламентні завдання;
прибрати небезпечні паролі й токени;
не переносити технічний борг;
реалізувати потрібні правила в K2 ERP;
протестувати сценарії після запуску.

Правильний підхід. Модулі 1С потрібно розглядати не як код для копіювання, а як джерело бізнес-знань, які потрібно зрозуміти, очистити, описати і перенести в сучасну архітектуру K2 ERP.

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

K2 ERP у цьому процесі може стати новою платформою для контрольованих бізнес-правил, зрозумілих процесів, безпечних інтеграцій, API, BI-аналітики, логіювання, прав доступу і подальшого розвитку автоматизації бізнесу без залежності від старої екосистеми 1С.

Див. також

Зовнішні посилання