У попередній статті ми додали загальний реквізит до всіх довідників нашої конфігурації, для того щоб знати хто створив цей об'єкт довідника. Тепер ми створимо підписку на подію і вкажемо, якою інформацією заповнити цей реквізит.
Таким чином кожен раз перед записом об'єкта у нас буде переписуватися автор об'єкта, бажано звичайно вказати і коли це сталося, додамо до автора ще й дату запису.
Процедура АвтоматічнеЗбереженняАвтораПередЗапісью (Джерело, Відмова) Експорт // Вставити вміст обробніка.Джерело. АвторОбєкту = ім'я користувача () + " ; "+ Рядок (текущаядата ()); КонецПроцедуриПрекрасно. Тепер подумаємо де ще можна використовувати загально реквізити?
По-перше за допомогою загальних реквізитів можна до всіх документів в конфігурації додати реквізит «Коментар», реквізит «автор» а також інші реквізити, які вам треба.
У загальних реквізитів є ще один цікавий параметр « Поділ даних ».Даний механізм дозволяє визначити дані, які ми хочемо показати користувачу. Наприклад, щоб жоден з менеджерів не знав усіх клієнтів компанії, ми будемо показувати йому тільки тих клієнтів, яких він вніс в базу, з якими він працює. Давайте спробуємо додати даний функціонал в базу. Для початку нам потрібно буде вказати, що ми будемо використовувати поділ даних, система автоматично запропонує створити параметри сеансу за умовчанням.
Після цього нам залишається тільки встановити параметри сеансу в модулі сеансу:
Наведемо приклад, як виглядає довідник контрагентів без використання «Підрозділи даних» і з ним:
без поділу
З поділом
Зверніть увагу що Реквізит «Відповідальний» в першому контрагента не знайдений, оскільки автором даного реквізиту був хтось інший.
Класичний приклад поділу обліку - по організаціям, показувати користувачам тільки ті документи, які ставитися до відповідної організації.
Ми з вами скористалися механізмом «Параметри сеансу», давайте коротко розберемося, що це таке. По суті справи параметри сеансу це глобальні змінні, які встановлюються при початку роботи системи. Як правило, це відбувається в «Модулі сеансу», зверніть увагу, що параметри сеансу створюються виключно програмними методами.
Після того як ми встановили «Параметри сеансу» ми можемо звернутися до даному параметруз будь-якого модуля системи простим
Відповідно щоб поміняти параметри сеансу користувач повинен вийти і зайти в програму за новою.
Одного разу ми обговорювали механізми обмеження доступу користувачів в 1С і зокрема.
Він дозволяє вирішити користувачеві працювати не з усіма документами, а тільки з тими, в яких вказана певна організація або склад. Відбори проводяться динамічно, тому накладають певне навантаження на роботу бази даних.
Властивість загального реквізиту-роздільник - Поділ користувачів 1С - дозволяє встановити доступність списку користувачів в залежності від використання роздільників.
Якщо роздільник включений для користувача, то він буде видно в списку користувачів в режимі 1С Підприємство - інакше не видно.
Таким чином можна організувати різні списки користувачів для різних частин бази.
Властивість загального реквізиту-роздільник - Поділ аутентифікації 1С - дозволяє заводити користувачів з однаковими іменами користувача для різних частин бази.
Умовний поділ 1С
Умовний поділ 1С дозволяє вмикати або вимикати роздільник на підставі даних бази. Таким чином можна створювати ланцюжка залежних один від одного роздільників динамічно діючих в тому чи іншому випадку.
Щоб включити умовний поділ 1С - потрібно вказати у властивості загального реквізиту-роздільник - Умовний поділ 1С -, який буде відповідати за визначення факту включення поділу 1С.
Можливо використовувати константу з типом булево або реквізит довідника з типом булево.
Важливо - у цій константи / цього довідника потрібно відключити використання (вибрати Чи не використовувати) в складі роздільників, тільки тоді його можна буде вибрати.
1.Преамбула.
Виникла необхідність організувати облік по двом організаціям в одній ІБ. Ситуація не унікальна, але так склалося, що наша сильно не типова 250 гігобайтная УППшка працювала досить повільно, тому замість RLS вирішили спробувати поділ даних. Що це таке, описано, наприклад, або. Якщо коротко, якщо RLS доповнює умовами запити SQL, То роздільник даних - це додатковий стовпець в таблицях на рівні СУБД, за рахунок чого механізм поділу повинен працювати спритніші RLS.
Отже, в базу, де вівся облік по ТОВ №1, необхідно перенести інформацію з окремою бази ТОВ №2 і організувати спільну роботу. Прямо як на зображенні:
Прості смертні працюють тільки зі своєю ТОВ, а головбух іноді дивиться дані по двом юридичним особам. Режим доступу до обох ТОВ можна тільки читати дані, тому головбух повинен мати можливість інтерактивно перемикатися між режимами "все читати" / "писати тільки по одній організації" і вибирати ТОВ (тобто встановлювати значення загального реквізиту) для проведення, наприклад, розрахунку собівартості.
2. Реалізація
Платформа 8.2.19.90, без режиму сумісності. СУБД - MSSQL Server 2008 R2 Standart.
Створили загальний реквізит ОрганізаціяРазделітель типу "число", погодилися з пропозицією створити параметри сеансу, заповнили склад реквізиту (включили кілька довідників, всі документи, регістри накопичення, бухгалтерії і розрахунку). Поділ даних - "Незалежно і спільно". Значення параметра сеансу встановлюється з стандартних налаштуванькористувача в процедурі УстановкаПараметровСеанса в модулі сеансу:
Організація = УправленіеПользователямі.ПолучітьЗначеніеПоУмолчанію (глТекущійПользователь, "ОсновнаяОрганізація");
ПараметриСеанса.ОрганізаціяРазделітельЗначеніе = Організація.ЗначеніеРазделітеля;
В інтерфейсі головбуха зробили формочку з можливістю перемикання між організаціями і включення / вимикання режиму поділу:
При відключеному поділі, коли ПараметриСеанса.ОрганізаціяРазделітельІспользованіе = Брехня, платформа відмовляється записувати документи, вивалюючись з помилками типу "ОшібкаSDBL: очікується вираз (pos = 12)", тому давати користувачеві записувати документи в такому варіанті не можна. Для надійності, створили підписки на подію "Перед записом" для об'єктів, що входять до складу загального реквізиту:
Якщо ПараметриСеанса.ОрганізаціяРазделітельІспользованіе = Брехня Тоді
# Якщо Клієнт Тоді
Попередження ( "Не можна записати, тому що поділ даних відключено!");
# КонецЕсли
Відмова = Істина;
КонецЕсли;
План дій у нас був такий: готуємо конфігурацію-приймач ІБ №1, проставляємо значення загального реквізиту = 1, завантажуємо дані з ІБ №2, після завантаження для всіх об'єктів з порожнім (дорівнює 0) значенням роздільник встановлюємо ОрганізаціяРазделітель = 2.
Конфігурацію підготували, виникло питання, як встановити значення загального реквізиту для документів і їх рухів в закритих періодах, причому швидко і без ризику того, що полетять цифри в балансі? Через об'єктну модель 1С записувати роздільник окремо від об'єкта неможливо, тому довелося порушити ліцензійну угодувикручуватися і писати запит для MS SQL. Оскільки в складі загального реквізиту багато об'єктів, а таблиць в вилиці першого удару ще більше, написали обробку, яка генерує запит для SQL (для кожного об'єкта метаданих, що входить до складу роздільник, писали "update" + Імя_БД + ".dbo._" + ІмяТабліци + "set _" + ПолеОбщійРеквізіт + "= 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 = T1._RecorderTRef and
_CRgRecalc1399. [_ RecorderRRef] = T1. [_ RecorderRRef] and
_CRgRecalc1399. [_ CalcKindRRef] = T1. [_ CalcKindRRef] and
_CRgRecalc1399. [_ Fld1400RRef] = T1. [_ Fld1400RRef] and
_CRgRecalc1399. [_ Fld1401RRef] = T1. [_ Fld1401RRef] and
_CRgRecalc1399. [_ Fld1402RRef] = T1. [_ Fld1402RRef]
);
GO
ALTER TABLE _CRgRecalc1399
DROP COLUMN id;
І тільки після чистки кількох десятків таблиць вдається вимкнути поділ даних. Після виключення поділу ніяких проблем немає.
3. Висновки.
Жевріла надія, що на 8.3 проблеми вирішені. Чи не полінувалися, перевірили на 8.3.4.482 (з відключеним режимом сумісності). Дивились на практично типовий УПП-шке, зі змінами в конфігурації тільки за загальним реквізиту. На цій тестовій базі поділ включили до введення інформації, тобто платформа повинна була коректно записувати значення роздільник в усі таблиці, самостійно безпосередньо в MS SQL нічого не писали.
результат:
Проблема із запитами до віртуальних таблиць "Обороти" і "ОборотиДтКт" відтворюється.
Проблема з витісненням відтворюється.
Проблема з записом в незалежні регістри відомостей відтворюється.
Проблема з виключенням поділу - одним натисканням кнопки від нього позбудеться не вийде!
Таким чином, замінити RLS новим механізмом у нас не вийшло. Замислювався цей механізм, по всій видимості, для хмарних сервісів, І в варіанті використання поділюваних даних "незалежно", може бути, поділ запрацює, але нам потрібна загальна НДІ. Залишається чекати, коли 1С виправить помилки, а ще краще, реалізує типовий механізм поділу по організаціям в типових конфігураціях.
Загальний реквізит в 1С 8.3 - це об'єкт метаданих платформи, що дозволяє використовувати один реквізит для багатьох об'єктів конфігурації (довідників, документів, планів рахунків і т.д). Об'єкт створений в основному для полегшення праці розробника і розділення даних.
Загальні реквізити були спочатку реалізовані у версії 1С 7.7, але відразу в платформу 8 версії розробники його не включили. Механізм загальних реквізитів був введений розробниками 1С тільки в релізі 8.2.14.
Загальні реквізити дуже зручно додавати, щоб не змінювати стандартні об'єкти в конфігурації, я часто їх використовую поряд с.
Після додавання загального реквізиту його можна використовувати і в запитах і виводити на форму об'єктів - зовні він нічим не відрізняється від звичайного реквізиту.
Єдине обмеження загальних реквізитів - неможливість використання їх в.
Розглянемо основні настройки і властивості загальних реквізитів, відмінні від інших об'єктів конфігурації:
склад- список об'єктів, до яких буде використаний загальний реквізит, настройка нагадує настройку плану обміну.
Отримайте 267 відеоуроків по 1С безкоштовно:
Автоіспользованіе- настройка визначає, чи буде використовуватися загальний реквізит для тих об'єктів, у яких в складі вказано режим використання «Автоматичний».
поділ даних- це налаштування розглянемо окремо.
Поділ даних в 1С за допомогою загального реквізиту
поділ даних- механізм, аналогічний механізму. Однак продуктивність даного механізму більш ефективна, і він налаштовується простіше.
Механізм дозволяє налаштувати відображення тільки елементів, які може бачити користувач. Наприклад, можна розмежувати всі об'єкти (документи, довідники і т.д.), де встановлена певна організація.
Налаштування поділу даних за допомогою загальних реквізитів 1С
Для настройки в загальному реквізиті необхідно вказати поділ даних - розділяти. Відразу після натискання система запропонує створити параметри обліку за замовчуванням:
При цьому необхідно буде при старті системи вказати параметри сеансу, як це зробити, до прикладу було описано в статті.
На цьому настройка закінчена - користувачеві буде доступна тільки та інформація, яка вказана в обраних параметрах сеансу.
Приклад використання загального реквізиту
Розберемо настройку загального реквізиту в 1С 8.3 на прикладі каркасної конфігурації і реквізиту організація:
У системі є 3 документа, де необхідно вказівку реквізиту Організація: це Прибуткова Накладна, Видаткова накладна, Нарахування Зарплати.
Налаштування проста:
- Створюємо новий Загальний реквізит, вказуємо тип - СправочнікСсилка.Організація.
- У складі розставляємо для наших документів - використовувати.
Все, настройка закінчена!
Дивимося результат:
Система відображає загальний реквізит «як свій»: і в запитах, і в реквізитах форми, і в інших місцях. Ось таке диво! 🙂
