gifts2017

Настройка филиальных баз данных

Опубликовал donfsk@yandex.ru A (evgant) в раздел Администрирование - Распределенная БД (УРИБ, УРБД)

Клиент поставил задачу реализации работы филиалов в конфигурациях "Бухгалтерия предприятия" и "Зарплата и Управление Персоналом", в которых уже давно работает центральное отделение. Главная загвоздка в том, что, несмотря на автономную работу филиалов, отчетность нужно было продолжать сдавать от юридического лица в центральном филиале. Начали продумывать варианты реализации...

Все началось с того что у клиента был большой штат сотрудников и документооборот в разных городах. У клиента уже были базы Бухгалтерия ПРОФ, ЗУП и УТ CRM. Причем УТ CRM имел РИБ в другом регионе. Работали обмены ЗУП - БУХ (переносились новые физические лица и связанная с ними информация в бухгалтерию), двухсторонний типовой регламентный обмен УТ CRM-БУХ и типовой обмен РИБ между базами в УТ CRM.

Поначалу они решили, что в центральном филиале будут вести учет и выплачивать зарплату по всем филиалам сами. Но видимо у бухгалтеров кончилось терпение и силы и нам поставили задачу...

ЗАДАЧА: 

Реализовать возможность работы бухгалтеров (наняли в каждом городе) таким образом, чтобы они сами могли подготавливать все отчеты и делать необходимые расчеты, но все налоги, как и прежде, должны были сдаваться в центре. Вся справочная информация, необходимая для работы филиалов, должна быть им доступна. Нужно закрыть доступ ко всем документам и отчетам о деятельности  между офисами - филиалами и разрешить видеть и использовать центру все, что происходит во всех филиалах.  

РЕШЕНИЕ :

У нас имеется 2 конфигурации в которой уже работает Центр это ЗУП и БУХ Проф. В этих конфигурациях уже занесены данные о сотрудниках офиса - зарплаты, отпуска, отчисления и тп. Нужно теперь разделить эту информацию пофилиально предварительно создав возможность бухгалтеров работать в базах. 

Первым делом начали продумывать, как реализовать задачу для Бухгалтерии. Самые первые мысли были из серии создать каждому филиалу по одной базе и перенести туда все необходимые справочные материалы и сведения, которые ранее велись в центральной базе (документы реализаций, заказов, поступлений и т.п.). Так как эта идея пришла  первая в голову, она оказалась не шибко умной, учитывая, что количество филиалов постоянно будет расти и усложнится поддержка огромного числа баз, которые еще будут периодически сбрасывать созданные там документы и элементы справочников в центр (отчетность сдается там) и получать новые справочные данные из центра. Еще нужно учесть возможность возникновения дублей, коллизий при обмене и тому подобную ерунду...

Следующим пришел на ум вариант сделать Распределенную Информационную Базу (РИБ) - всего одну. В этот РИБ поместить все филиалы, ограничив при первоначальном создании базы "дочки" перенос информации, которая не должна попасть в филиалы согласно ТЗ. Это решается буквально в пару строчек в модуле объекта плана обмена "Полный" - дописать какие элементы мы игнорируем при загрузке\выгрузке. Но разделение по работе разных организаций в одной конфигурации Бухгалтерии есть только в версии КОРП. Значит перед созданием РИБ нужно еще обновить Бухгалтерию до версии КОРП.

Красота РИБ в нашем случае очевидна - занеся один раз в Центр справочную информацию, она передастся в Дочернюю базу и наоборот и сразу отпадает вопрос дублей.  Разграничение между филиалами будет работать согласно типовому разграничению версии КОРП. Организации не будут видеть друг друга, а Центр будет получать все документы, созданные в филиалах за счет стандартного обмена РИБ. Но тут есть жирный минус - нам нужно как то обзывать филиалы и заводить их как организации в Бухгалтерии КОРП и тогда средствами РИБ эти все организации и соответственно все документы со ссылкой на эти организации перенесутся в Центр, а нам нужно сдавать консолидировано всю отчетность от Юр лица в Центре. Выход есть: поправить сам обмен РИБ и добавить правила, которые бы подменивали название организаций при переносе из РИБ Дочерней базы в Центр. Тогда резонный вопрос - а зачем нам РИБ и так ли он нам необходим? Ведь помимо всех плюсов у этого механизма есть и существенные минусы, например, такие как идентичность ИБ (дочерняя база изначально зависима от Центра и все изменения в конфигурации, которые произошли в Центре, просто необходимо подтвердить в Дочерней базе, чтобы начать работать - а это значит, что невозможно разделить явно работу Центра и филиалов и может попасться информация, которая просочится в филиал). 

После всех этих размышлений было принято решение сделать одну обычную (не РИБ) базу для всех филиалов. Значит, нам в любом случае нужна бухгалтерия версии КОРП. Перенести первоначальную справочную информацию и документы из центра в филиальную базу. Далее настроить планы обмена - о них поподробнее...

Обновить версию до КОРП - это совсем просто - скачать специальный дистрибутив с сайта 1С и простым обновлением (релиз ПРОФ должен соответствовать релизу обновления до КОРП) с помощью этого дистрибутива наша Бухгалтерия становится КОРП. 

Перенести справочную информацию без ссылок на, например справочник Организации и документы, тоже не сильно сложно - расставить пару галочек в конфигурации "Менеджер обмена данными" и с помощью универсальной обработки обмена форматом XML, подгрузив файлик правил, перенести всю выбранную информацию. 

Далее нужен план обмена, который выгружал бы всю новую справочную информацию из Центра в филиалы, а обратно загружал бы документы и справочную информацию, созданную в филиалах, с подменой и переносом ссылок организаций - филиалов на единственную организацию в конфигурации Центра. Было принято решение сделать 2 плана обмена, первый отправлял бы справочную информацию из центра в филиал, второй отправлял бы документы и связанные с этими документами новые справочные объекты обратно в Центр. Центральная база бухгалтерии довольно нагружена, в ней работает порядка 30 человек, а так же происходит регламентный типовой обмен с конфигурацией УТ CRM (каждые 10 минут). Сама УТ CRM насчитывает 100 параллельных подключений менеджеров и имеет РИБ, который является базой для колл-центра в другом регионе России. В УТ CRM генерируется огромное количество справочной информации, которая средствами типового обмена отправляется в Бухгалтерию Центральную, а далее добирается до филиальной бухгалтерии с помощью нашего нетипового обмена. Так как УТ CRM обменивается с Центральной бухгалтерией каждые 10 минут, то для поддержания актуальности информации в филиалах мы должны реализовать обмен с филиальной базой хотя бы раз в 20 минут, что и было сделано.

Второй обмен должен был переносить документы и связанную с ними справочную информацию из филиалов в Центр - этот обмен был проще, включал в себя 5 документов и обменивался с Центром раз в 4 часа - так как в конце концов эти документы были нужны, только в период консолидированной сдачи отчетности. 

После создания и тестирования правил и баз бухгалтерии запустили их в рабочем режиме и ..... Обрушилась  вся контактная информация (удалился весь Регистр сведений "Контактная информация") на стороне УТ CRM. В итоге мы быстренько подгрузили контактную информацию в базу из бэкапа, остановили обмен и начали разбираться. 

Ошибка оказалась очень интересной : Когда в базе бухгалтерии создается Контактное лицо со свойством "личный контакт" (такого нет в УТ CRM) и осуществляется обмен через подключение к ИБ (не через папку обмена) на новое контактное лицо со свойством "личный" не накладывается никаких отборов при записи в конфигурацию выгрузки - УТ CRM и за счет пустого отбора и записи регистра успешно затирается весь регистр сведений. При обмене через промежуточный файл такого не происходит.

Вопрос возник другой - почему раньше такого не происходило, а произошло только сейчас, как утверждает клиент, они вообще не пользуются контактным лицом со свойством "Личный". Действительно в справочнике Контактных лиц со свойством "личный" было всего несколько штук и заведены они были очень давно, еще до реализации типового обмена между Центральной бухгалтерией и УТ CRM. Как оказалась - тут моя огромная ошибка - я создал план обмена до переноса первоначальной информации, и совсем забыл удалить все, что план обмена зарегистрировал как модифицированные объекты для обмена, в число которых и попали эти несчастные контактные лица. Когда запустили обмен из филиалов в Центр, он перенес измененные объекты, включая и контактные лица обратно в центр, где они уже и так есть, а план обмена с УТ CRM уже перенес эти зарегистрированные для своего обмена элементы в УТ CRM и благополучно все затер. 

Ошибку исправили - закрыли обмен справочником Контактные лица и запустили обмен. 

Написали об ошибке в фирму 1С , она воспроизвелась на типовых версиях Бухгалтерии ПРОФ, КОРП и УТ 10.3 - хочется сказать что служба по регистрации ошибок в 1С оставляет желать лучшего.... Они 2 недели только вникали как воспроизвести ошибку и потом так и не воспроизведя ее у себя заявили что проблема у нас, хотя еще раз повторю обмен мы воспроизводили на типовых версиях УТ  и БУХ и описали как эта ошибка появляется у нас (стандартная форма регистрации ошибок в 1С). В итоге мы нашли в интернете, что проблема возникала и у других людей, но так до сих пор и не решена фирмой 1С...

Далее нужно было реализовать те же требования в конфигурации "Зарплата и Управление Персоналом" (ЗУП) - тут оказалось, что в ЗУП уже заложены механизмы ограничения данных по физическим лицам - что нас вполне устраивало. В каждом филиале работали свои физ. лица и они не пересекались в разных филиалах. Ограничение реализовано так, что каждому пользователю видны те документы, которые относятся к группе доступа физических лиц, присвоенной ему. 

Нужно было всего лишь сделать группы доступа физ лиц - занести туда пофилиально порции физ лиц и назначить на каждую группу доступа группы пользователей, которые имеют право видеть документы по своим физ лицам. Если же нужно видеть все документы (Центр) то им создали группу пользователей в которую не входит не одна группа доступа физ лиц - т.е. они видят всех. Очень красиво реализовано и все это в одной конфигурации, где работают и Центр и Филиалы. 

Так была решена наша задача, представленная пользователем,  и работает уже порядка 4-5 месяцев пока без сбоев.... дай бог и дальше :)

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Владимир Родионов (Балабас) 30.01.13 16:50
Скажите, а у вас не было ситуации, когда человек переходил из одного филиала в другой или в головной офис? Ведь в этом случае ему необходимо будет установить другую группу доступности физ лиц. И, следовательно, ответственный за филиал уже не сможет видетть документы, в которых присуствует данное физ лицо. Как вы обойдете это ограничение?
2. donfsk@yandex.ru A (evgant) 30.01.13 19:41
(1) Балабас, Да при переходе физ лицо и соответственно все связанные с ним документы переходят на другой филиал - и его данные может видеть уже ответственный за филиал, куда физ лицо перенесено. Прошлому же ответственному, за филиал из которого он переведен данные становятся недоступны, в этом и логика разделения.
Так же именно в нашем случае, центральному офису нужен был полный контроль за всеми филиалами - поэтому мы создали им отдельную группу пользователей, но не назначили группы доступа и тогда все сотрудники центра, включенные в созданную группу пользователей имели представление о работе филиалов.
3. Petr (sevipa) 31.01.13 06:45
Спасибо за информацию. Просто и красиво. +
4. Владимир Родионов (Балабас) 31.01.13 15:43
(2) evgant, я понял про центральный офис, но как же, к примеру, вы будете осуществлять сдачу отчетности по ПФР за тот период когда физ лицо еще работал в филиале из которого перевелся?
5. donfsk@yandex.ru A (evgant) 31.01.13 16:05
(4) Балабас, У нас такой проблемы не стояло так как всю отчетность сдавал Центральный офис - это и было обязательным условием - не разводить отдельные юридические лица. А документы автоматически будут видны в другом филиале, в том числе и за прошлый период работ в другом филиале(так как фактического разделения на организации в программе нет, у всех одна организация - различия только по группам пользователей и группам доступа физ. лиц).
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа