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