В системі 1С: Підприємство існує можливість ведення в одній інформаційній базі обліку по декількох підприємствах. Для цього використовується роздільник обліку.
Використання роздільник обліку задається в конфігурації. Якщо в конфігурації визначено використання роздільника обліку, то в табло рахунків існує можливість вибору конкретного значення роздільник обліку, за яким будуть видаватися бухгалтерські підсумки.
Для установки значення роздільник обліку слід скористатися пунктом "Роздільник обліку" меню "Дії" або відповідною кнопкою панелі інструментів. При цьому на екран видається діалог для установки значення роздільник обліку.
У полі "Значення роздільника обліку" можна вказати конкретне значення роздільник обліку. Спосіб введення значення залежить від типу роздільник обліку, визначеного в конфігурації. Як правило, це довідник. В цьому випадку для вибору значення слід скористатися кнопкою вибору і вибрати потрібне значення зі списку значень довідника.
кнопка "Пусте значення" дозволяє стерти введене значення роздільник обліку, тобто задати порожнє значення. Це має сенс в тому випадку, якщо, поряд з конкретними значеннями роздільник обліку, в проводках використовувалося і пусте значення.
прапорець "По всім" дозволяє встановити режим виведення підсумків за всіма значеннями роздільник обліку в сумі.
Для установки обраних значень слід натиснути кнопку "ОК". Для відмови від установки значень - кнопку "Скасування".
Після установки обраних значень табло рахунків буде виводити підсумки за конкретним значенням роздільник обліку або по порожньому значенням або за всіма значеннями в сумі, в залежності від обраного в діалозі варіанту.
1.Преамбула.
Виникла необхідність організувати облік по двом організаціям в одній ІБ. Ситуація не унікальна, але так склалося, що наша сильно не типова 250 гігобайтная УППшка працювала досить повільно, тому замість RLS вирішили спробувати поділ даних. Що це таке, описано, наприклад, або. Якщо коротко, якщо RLS доповнює умовами запити SQL, то роздільник даних - це додатковий стовпець в таблицях на рівні СУБД, за рахунок чого механізм поділу повинен працювати спритніші RLS.
Отже, в базу, де вівся облік по ТОВ №1, необхідно перенести інформацію з окремою бази ТОВ №2 і організувати спільну роботу. Прямо як на зображенні:
Прості смертні працюють тільки зі своєю ТОВ, а головбух іноді дивиться дані по двом юридичним особам. Режим доступу до обох ТОВ можна тільки читати дані, тому головбух повинен мати можливість інтерактивно перемикатися між режимами "все читати" / "писати тільки по одній організації" і вибирати ТОВ (тобто встановлювати значення загального реквізиту) для проведення, наприклад, розрахунку собівартості.
2. Реалізація
Платформа 8.2.19.90, без режиму сумісності. СУБД - MSSQL Server 2008 R2 Standart.
Створили загальний реквізит ОрганізаціяРазделітель типу "число", погодилися з пропозицією створити параметри сеансу, заповнили склад реквізиту (включили кілька довідників, всі документи, регістри накопичення, бухгалтерії і розрахунку). Поділ даних - "Незалежно і спільно". Значення параметра сеансу встановлюється зі стандартних налаштувань користувача в процедурі УстановкаПараметровСеанса в модулі сеансу:
Організація \u003d УправленіеПользователямі.ПолучітьЗначеніеПоУмолчанію (глТекущійПользователь, "ОсновнаяОрганізація");
ПараметриСеанса.ОрганізаціяРазделітельЗначеніе \u003d Організація.ЗначеніеРазделітеля;
В інтерфейсі головбуха зробили формочку з можливістю перемикання між організаціями і включення / вимикання режиму поділу:
При відключеному поділі, коли ПараметриСеанса.ОрганізаціяРазделітельІспользованіе \u003d Брехня, платформа відмовляється записувати документи, вивалюючись з помилками типу "ОшібкаSDBL: очікується вираз (pos \u003d 12)", тому давати користувачеві записувати документи в такому варіанті не можна. Для надійності, створили підписки на подію "Перед записом" для об'єктів, що входять до складу загального реквізиту:
Якщо ПараметриСеанса.ОрганізаціяРазделітельІспользованіе \u003d Брехня Тоді
# Якщо Клієнт Тоді
Попередження ( "Не можна записати, тому що поділ даних відключено!");
# КонецЕсли
Відмова \u003d Істина;
КонецЕсли;
План дій у нас був такий: готуємо конфігурацію-приймач ІБ №1, проставляємо значення загального реквізиту \u003d 1, завантажуємо дані з ІБ №2, після завантаження для всіх об'єктів з порожнім (дорівнює 0) значенням роздільник встановлюємо ОрганізаціяРазделітель \u003d 2.
Конфігурацію підготували, виникло питання, як встановити значення загального реквізиту для документів і їх рухів в закритих періодах, причому швидко і без ризику того, що полетять цифри в балансі? Через об'єктну модель 1С записувати роздільник окремо від об'єкта неможливо, тому довелося порушити ліцензійну угоду викручуватися і писати запит для MS SQL. Оскільки в складі загального реквізиту багато об'єктів, а таблиць в вилиці першого удару ще більше, написали обробку, яка генерує запит для SQL (для кожного об'єкта метаданих, що входить до складу роздільник, писали "update" + Імя_БД + ".dbo._" + ІмяТабліци + "set _" + ПолеОбщійРеквізіт + "\u003d 1";)
Значення проставили, перенесли частину даних з ІБ №2, почали тестувати.
Результат розчарував. По-перше, проблеми з регістром бухгалтерії. При включеному поділі не видно аналітику:
Пов'язано це з тим, що регістр бухгалтерії на рівні СУБД зберігається як кілька таблиць, і не у всіх таблицях було проставлено значення загального реквізиту (для перегляду структури використовували обробку).
Добре, проставляємо значення роздільник через MS SQL, аналітику бачимо. Тепер не працюють звіти. Виявляється, проблеми із запитами до віртуальних таблиць регістра бухгалтерії "Обороти" і "ОборотиДтКт":
(Fld27033 - це як раз загальний реквізит в таблиці регістра бухгалтерії)
Роздільник встановлений у всіх таблицях, це видно на рівні СУБД, в чому може бути помилка, не зрозуміло. Розгортаємо типову порожню УПП, робимо описані вище зміни в конфігурації, вводимо пару документів (в цьому варіанті платформа сама проставляє значення роздільник у всіх таблицях регістру бухгалтерії), але помилки відтворюються. Погано, але виключаємо регістри бухгалтерії зі складу загального реквізиту, продовжуємо тестування.
Далі, з'ясовується що перестав працювати механізм витіснення у регістрів розрахунку. Плани видів розрахунку ми не поділяли, пробуємо шукати проблему в таблицях регістру розрахунків і в перерахунках. Перевіряємо, проставляємо значення основного реквізиту, робимо тії - безрезультатно.
Попутно, діагностуємо проблему під час запису в незалежні регістри відомостей з форми списку. При цьому дані записуються, їх можна побачити після перезапуску. Проблема відтворюється і на тестовій базі:
Регістри відомостей "полагодити" шляхом маніпуляцій з SQL не вийшло (значення роздільник у всіх таблицях встановлено), тому просто виключили їх зі складу загального реквізиту. Після кількох днів експериментів, невдалими виявляються і спроби відновити працездатність витіснення.
На цей момент приймаємо рішення вимкнути поділ даних і використовувати-таки RLS. При установці поділу в "не використовувати" натикаємося на помилки "Microsoft OLE DB Provider forSQL Server: CREATE UNIQUE INDEX terminated because a duplicate keywas found for index ...". Тобто, повернутися в стан до поділу так запросто не виходить. Проблема з індексами таблиць перерахунків, налаштувань зберігання підсумків та інших. Справа в тому, що в таблицях зберігаються ідентичні рядки, що відрізняються тільки значенням загального реквізиту. При видаленні загального реквізиту з'являються неунікальні записи. Доведеться видалити непотрібні записи безпосередньо в MS SQL, приблизно так (для таблиці перерахунків):
Use base;
ALTER TABLE _CRgRecalc1399
ADD id INT IDENTITY (1,1);
GO
DELETE FROM _CRgRecalc1399
WHERE id< (SELECT MAX(id)
FROM _CRgRecalc1399 AS T1
WHERE _CRgRecalc1399._RecorderTRef \u003d T1._RecorderTRef and
_CRgRecalc1399. [_ RecorderRRef] \u003d T1. [_ RecorderRRef] and
_CRgRecalc1399. [_ CalcKindRRef] \u003d T1. [_ CalcKindRRef] and
_CRgRecalc1399. [_ Fld1400RRef] \u003d T1. [_ Fld1400RRef] and
_CRgRecalc1399. [_ Fld1401RRef] \u003d T1. [_ Fld1401RRef] and
_CRgRecalc1399. [_ Fld1402RRef] \u003d T1. [_ Fld1402RRef]
);
GO
ALTER TABLE _CRgRecalc1399
DROP COLUMN id;
І тільки після чистки кількох десятків таблиць вдається вимкнути поділ даних. Після виключення поділу ніяких проблем немає.
3. Висновки.
Жевріла надія, що на 8.3 проблеми вирішені. Чи не полінувалися, перевірили на 8.3.4.482 (з відключеним режимом сумісності). Дивились на практично типовий УПП-шке, зі змінами в конфігурації тільки за загальним реквізиту. На цій тестовій базі поділ включили до введення інформації, тобто платформа повинна була коректно записувати значення роздільник в усі таблиці, самостійно безпосередньо в MS SQL нічого не писали.
результат:
Проблема із запитами до віртуальних таблиць "Обороти" і "ОборотиДтКт" відтворюється.
Проблема з витісненням відтворюється.
Проблема з записом в незалежні регістри відомостей відтворюється.
Проблема з виключенням поділу - одним натисканням кнопки від нього позбудеться не вийде!
Таким чином, замінити RLS новим механізмом у нас не вийшло. Замислювався цей механізм, по всій видимості, для хмарних сервісів, і в варіанті використання поділюваних даних "незалежно", може бути, поділ запрацює, але нам потрібна загальна НДІ. Залишається чекати, коли 1С виправить помилки, а ще краще, реалізує типовий механізм поділу по організаціям в типових конфігураціях.
Одного разу ми обговорювали механізми обмеження доступу користувачів в 1С і зокрема.
Він дозволяє вирішити користувачеві працювати не з усіма документами, а тільки з тими, в яких вказана певна організація або склад. Відбори проводяться динамічно, тому накладають певне навантаження на роботу бази даних.
Властивість загального реквізиту-роздільник - Поділ користувачів 1С - дозволяє встановити доступність списку користувачів в залежності від використання роздільників.
Якщо роздільник включений для користувача, то він буде видно в списку користувачів в режимі 1С Підприємство - інакше не видно.
Таким чином можна організувати різні списки користувачів для різних частин бази.
Властивість загального реквізиту-роздільник - Поділ аутентифікації 1С - дозволяє заводити користувачів з однаковими іменами користувача для різних частин бази.
Умовний поділ 1С
Умовний поділ 1С дозволяє вмикати або вимикати роздільник на підставі даних бази. Таким чином можна створювати ланцюжка залежних один від одного роздільників динамічно діючих в тому чи іншому випадку.
Щоб включити умовний поділ 1С - потрібно вказати у властивості загального реквізиту-роздільник - Умовний поділ 1С -, який буде відповідати за визначення факту включення поділу 1С.
Можливо використовувати константу з типом булево або реквізит довідника з типом булево.
Важливо - у цій константи / цього довідника потрібно відключити використання (вибрати Чи не використовувати) в складі роздільників, тільки тоді його можна буде вибрати.
Що Ви дізнаєтеся з цієї статті?
- У статті розглядається призначення режиму поділу підсумків
- Розбирається поведінку системи «1С: Підприємство 8» при паралельній роботі великої кількості користувачів
- Показуються мінуси режиму поділу підсумків
- Видаються рекомендації щодо коректного використання поділу підсумків регістра
Платформа «1С: Підприємство 8» містить можливості і механізми, про роботу яких не всі мають повне уявлення, як і про способи їх ефективного використання. Таким є режим поділу підсумків.
Механізм поділу підсумків виконує дуже важливу і корисну функцію: його використання уможливлює здійснювати паралельний запис в регістри бухгалтерії і регістри накопичення.
Покажемо ефективність даного режиму за допомогою прикладу. Для цього розглянемо ситуацію до і після включення режиму поділу підсумків.
До включення режиму поділу підсумків
Ми маємо в наявності два однакових документа з номерами 001 і 002:
Обидва документи здійснюють рух по регістру накопичення. Контролю залишків немає. Структура регістра накопичення:
Два користувача, працюючи в своїх документах, починають одночасне проведення. Виникає ситуація, при якій два документа одного типу намагаються зробити руху одночасно.
При цьому на рівні СУБД виникає наступна картина:
Ось що відбувається в системі:
- Документи намагаються внести запис в регістр накопичення
- На рівні СУБД регістр накопичення представлений двома таблицями: таблицею рухів і таблицею залишків (таблиця підсумків).
- У таблиці рухів можлива запис документами своїх даних паралельно. Це забезпечується різними значеннями поля «Реєстратор», і, відповідно, робота йде з різними рядками таблиці.
- А ось в таблиці залишків немає поля «Реєстратор», дані в цій таблиці зберігаються в розрізі вимірювань самого регістру.
- Тут спостерігається ситуація, при якій двома документами необхідно змінити одну запис, але один запис одночасно міняти не можна.
- Для того щоб не втратити записуються дані, будь-якої з документів повинен чекати своєї черги на запис, поки інший документ не запише свої рухи. І, після того як перший з документів внесе свої рухи, другий зможе внести вже свої.
В результаті ми спостерігаємо втрату часу - другий користувач змушений чекати закінчення проведення документа у першого. З одного боку, все правильно і логічно, з іншого - страждає паралельність роботи користувачів в системі.
Для вирішення цієї проблеми і створений механізм поділу підсумків.
Його використання передбачено лише для регістрів накопичення і регістрів бухгалтерії.
Функція переходу в режим поділу підсумків
Включення даного режиму виконується досить просто:
Зауважимо, що режим поділу підсумків включений за замовчуванням для всіх створюваних регістрів накопичення і бухгалтерії. Крім Конфігуратора в призначеному для користувача режимі ми можемо подивитися, для яких регістрів включено використання режиму:
Що відбувається після включення режиму поділу підсумків?
У таблиці підсумків регістра накопичення / бухгалтерії з'являється новий стовпець «Роздільник». У самій СУБД він названий «Splitter».
При цьому таблиця рухів залишається незмінною, роздільником в ній виступає «Реєстратор». Зміна ми бачимо в таблиці підсумків.
Це поле заповнюється тільки в тому випадку, коли дві (або більше) транзакції намагаються змінити один рядок в таблиці підсумків. При виникненні такого випадку поле «Роздільник» зберігає різні значення для кожної з транзакцій.
Така реалізація режиму поділу підсумків уможливлює виконувати паралельну запис всіх транзакціях.
У нашому прикладі з двома документами при включенні режиму спостерігається наступне:
Обидва наших документа виконали паралельний запис своїх даних завдяки новому полю «Роздільник». В результаті не виникають очікування при блокування і підвищена паралельність роботи користувачів.
Мінуси режиму поділу підсумків
При включенні даного режиму збільшується розмір таблиці підсумків регістра через те, що було додано нове поле, і з'являється кілька рядків по набору вимірів замість однієї.
При отриманні залишків по регістру виникає потреба згортки даних, що призводить до витрат часу, нехай і незначним.
У нашому випадку з двома документами для отримання залишку товару «Стіл» за складом «Основний» виникає необхідність складання двох рядків для отримання підсумкового значення «7». При вимкненому роздільник угруповання рядків (додавання) не потрібно.
Коли слід використовувати режим поділу підсумків?
Для цього необхідно виконати умови:
- За регістру немає контролю залишків - немає читання даних в транзакції. У регістрах бухгалтерії контроль залишків, як правило, відсутня. Але якщо контроль залишків присутній, то ми не отримаємо ніякого виграшу в продуктивності. До того ж, при контролі залишків потрібно використовувати властивість набору записів «БлокіроватьДляІзмененія», так як виникає ймовірність взаимоблокировки.
- З регістром виконується паралельна робота користувачів, причому активна.
При послідовній роботі з регістром або роботі з малим числом користувачів немає сенсу включати режим поділу підсумків: відсутність конкуруючих транзакцій не призводить до очікуванням на блокування, і, відповідно, не спостерігається ефекту від використання режиму поділу підсумків.
Бурмістров Андрій