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

Все началось с того что у клиента был большой штат сотрудников и документооборот в разных городах. У клиента уже были базы Бухгалтерия ПРОФ, ЗУП и УТ 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 месяцев пока без сбоев…. дай бог и дальше 🙂