Подчинение справочника "Структура предприятия" (Подразделения) справочнику "Организации"
Внедряем 1С:ДО 2.0. Выгружаем данные в ДО 2.0 из БП КОРП 3.0. В БП данные по 3 юр лицам и в справочнике "Подразделения" есть элементы с одинаковыми наименованиями, например, "Бухгалтерия" есть и в головной фирме и в ее дочках. Проблема в том, что когда выгрузили подразделения в 1С:ДО, то поскольку они там не связанны со справочником "Организации", то пользователи путаются и не могут отличить одну "Бухгалтерию" от другой. И таких подразделений много.
Наши аутсорсеры-консультанты советуют сделать 3 группы в справочнике с названиями организаций. Но такое решение нам не нравится, т.к.: а) пользователи могут отключить иерархический просмотр справочника; б) при вводе с клавиатуры в реквизит опять будет отображаться несколько одинаковых элементов в списке выбора; в) у нас есть политика СБ, которая предполагает разграничение прав по организациям; г) хотелось бы иметь простой обмен ДО с БП КОРП, а не допиливать его с учетом новых папок в ДО.
Мы склоняемся, чтобы в ДО подчинить справочник "Структура предприятия" (Подразделения) справочнику "Организации" - так сделано в БП КОРП 3.0 , в ЗУПе 2.5 и др.
ВНИМАНИЕ ВОПРОС!!!
1. Чем нам может грозить включение подчиненности справочника «Структура предприятия» справочнику "Организации" в 1С:Документооборот 2.0?
Как это повлияет на типовой учет в 1С:ДО?
2. Нужно ли в этом случае включать учет по организациям в настройках и заполнять реквизит «Организация» в документах, если мы просто хотим подчинить справочник «Структура предприятия»?
Наши аутсорсеры-консультанты советуют сделать 3 группы в справочнике с названиями организаций. Но такое решение нам не нравится, т.к.: а) пользователи могут отключить иерархический просмотр справочника; б) при вводе с клавиатуры в реквизит опять будет отображаться несколько одинаковых элементов в списке выбора; в) у нас есть политика СБ, которая предполагает разграничение прав по организациям; г) хотелось бы иметь простой обмен ДО с БП КОРП, а не допиливать его с учетом новых папок в ДО.
Мы склоняемся, чтобы в ДО подчинить справочник "Структура предприятия" (Подразделения) справочнику "Организации" - так сделано в БП КОРП 3.0 , в ЗУПе 2.5 и др.
ВНИМАНИЕ ВОПРОС!!!
1. Чем нам может грозить включение подчиненности справочника «Структура предприятия» справочнику "Организации" в 1С:Документооборот 2.0?
Как это повлияет на типовой учет в 1С:ДО?
2. Нужно ли в этом случае включать учет по организациям в настройках и заполнять реквизит «Организация» в документах, если мы просто хотим подчинить справочник «Структура предприятия»?
По теме из базы знаний
- Подсистема «Алкогольное декларирование». 1С:Предприятие 7.7, любые конфигурации
- Учет затрат в программе «1С:ERP Управление предприятием 2.0»
- Организация работы внешних табельщиков с ограничением видимости сотрудников по подразделениям в ЗУП 3.1
- Замена кадровых подразделений на затратные в ЗУП 3.1 при отражении в бухгалтерском учете зарплаты и резервов
- 1С:Предприятие 8. Планово-финансовое управление для государственных учреждений КОРП
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) RailMen, в ДО КОРП тоже нет подчинения нужных справочников?
Что касается обмена.
Синхронизацию настроить по UID.
В конце наименования добавлять признак принадлежности к организации (как предложено в (8)).
Настроить доступ к элементам справочника через группы доступа.
Что касается обмена.
Синхронизацию настроить по UID.
В конце наименования добавлять признак принадлежности к организации (как предложено в (8)).
Настроить доступ к элементам справочника через группы доступа.
(2) Зеленоград, какие объекты вы предлагаете переименовать? Элементы подразделений "дочек" ? Убедить бухгалтеров разных юр лиц переименовать 600 элементов подразделений сложновато, т.к. они есть во всех отчетах за прошлые периоды, в первичке и пр. Или я не так понял?
Пока я все таки подчинил "Структуру предприятия" справочнику "Организации" - по аналогии как сделано в БП КОРП 3.0/2.0/1.6, ЗУП 2.5, ERP 2.0 и пр. Наши соисполнители четко не смогли ответить на вопрос, чем нам может грозить такое переподчинение, либо специально уклонились от ответа, постаравшись не брать такую ответственность. РП с их стороны тут же использовал наше вмешательство в конфигуратор как возможную причину сдвигов сроков проекта и его бюджета. Он перестраховался и формально прав.
В результате изменил справочник "Структура предприятия" и две его формы: списка и выбора (код в них одинаковый). Добавил на форме 2 элемента: ОтборОрганизация и ОтборОрганизацияЗначение (нет под рукой конфигуратора, по памяти пишу) - все точно так же как в БП КОРП 3.0. подводный камень тут - нельзя реквизит формы ОтборОрганизацияЗначение делать типом "СправочникСсылка.Организации", т.к. отрабатывают внутренние зашитые в 1С:ДО настройки формы, которые скрывают все реквизиты с таким типом по причине наличия функциональных опций (опять же по памяти) "ВестиУчетПорганизации" и еще 2 или 3 аналогичных. Все элементы с типом "СправочникСсылка.Организации" скрываются до тех пор, пока в настройках не включить ведение учета по организациям, а нам это пока не нужно. Выход найден простой - реквизиту "ОтборОрганизацияЗначение" установлен Произвольный тип, он размещен на форме и создано событие ПриСозданииНаСервере у формы, где заполняется список выбора для этого элемента значениями справочника "Организации". Обработчики событий в точности такие же как в 1С: БП КОРП. Благо БСП в 1С:ДО точно такая же.
В результате изменил справочник "Структура предприятия" и две его формы: списка и выбора (код в них одинаковый). Добавил на форме 2 элемента: ОтборОрганизация и ОтборОрганизацияЗначение (нет под рукой конфигуратора, по памяти пишу) - все точно так же как в БП КОРП 3.0. подводный камень тут - нельзя реквизит формы ОтборОрганизацияЗначение делать типом "СправочникСсылка.Организации", т.к. отрабатывают внутренние зашитые в 1С:ДО настройки формы, которые скрывают все реквизиты с таким типом по причине наличия функциональных опций (опять же по памяти) "ВестиУчетПорганизации" и еще 2 или 3 аналогичных. Все элементы с типом "СправочникСсылка.Организации" скрываются до тех пор, пока в настройках не включить ведение учета по организациям, а нам это пока не нужно. Выход найден простой - реквизиту "ОтборОрганизацияЗначение" установлен Произвольный тип, он размещен на форме и создано событие ПриСозданииНаСервере у формы, где заполняется список выбора для этого элемента значениями справочника "Организации". Обработчики событий в точности такие же как в 1С: БП КОРП. Благо БСП в 1С:ДО точно такая же.
Советую Вам воздержаться от указанной задумки.
Как по мне задача решается очень просто:
В результате получаем подразделения с названиями вида "Бухгалтерия - ООО Рога и копыта", "Бухгалтерия - ОАО Не ищем лёгких путей" и т.д.
Подразделения переименовываются автоматически, будь их хоть 600, хоть миллион.
Как по мне задача решается очень просто:
Выборка = Справочники.ПодразделенияОрганизаций.Выбрать();
Пока Выборка.Следующий() Цикл
Попытка
оПодразделение = Выборка.Ссылка.ПолучитьОбъект();
оПодразделение.ОбменДанными.Загрузка = Истина;
оПодразделение.Наименование = СокрЛП(оПодразделение.Наименование) + " - " + оПодразделение.Владелец;
оПодразделение.Записать();
Исключение
Сообщить(ОписаниеОшибки());
КонецПопытки;
КонецЦикла; ПоказатьВ результате получаем подразделения с названиями вида "Бухгалтерия - ООО Рога и копыта", "Бухгалтерия - ОАО Не ищем лёгких путей" и т.д.
Подразделения переименовываются автоматически, будь их хоть 600, хоть миллион.
obsfromekb, благодарю за интерес к теме.
Полагаю, вы советуете добавить в наименование подразделений наименование организации для правил конвертации данных данных из БП КОРП в ДО.
Листинг будет конечно другой, но идея в целом понятна.
Да, это вполне рабочий вариант, заслуживающий внимания и имеющий свои недостатки.
Недостатки вполне очевидные:
1) необоснованный рост длины наименований справочника "Структура предприятия". Не знаю в курсе Вы или нет, но наименование имеет максимальную длину 150 символов и в очень большом % случаев наши названия подразделений укладываются ровно в нее (даже некоторые слова сокращаем). Т.е. что бы мы ни дописали, это все равно отсечется платформой. Предупрежу предложение сделать доп реквизит "Организация" или что хуже "Наименование с организацией" - пока без обоснования (попробуйте сами догадаться почему этот выход не лучше).
2) если мы захотим фильтровать подразделения по организациям - нам придется это делать через ПОДОБНО на строковые поля большой длины - что крайне не производительно
3) ваше предложение не укладываются в архитектуру тех типовых решений с которыми настраивается обмен данными - это влечет за собой потери на допил синхронизаций структур данных и прочее.
4) если пользователь захочет создать новое подразделение в ДО и затем нужно будет его выгрузить в БП КОРП? в вашем случае придется парсить строку, затем искать в базе приемнике Организацию по наименованию (по УИДу то уже будет нельзя) - это вообще плохое решение.
Главный вопрос я повторю: почему разработчики 1С:ДО отошли от архитектуры большинства типовых решений? В ЧЕМ МЕТОДОЛОГИЧЕСКАЯ ЛОГИКА ТАКОГО РЕШЕНИЯ - отказа от подчинения справочника???
Полагаю, вы советуете добавить в наименование подразделений наименование организации для правил конвертации данных данных из БП КОРП в ДО.
Листинг будет конечно другой, но идея в целом понятна.
Да, это вполне рабочий вариант, заслуживающий внимания и имеющий свои недостатки.
Недостатки вполне очевидные:
1) необоснованный рост длины наименований справочника "Структура предприятия". Не знаю в курсе Вы или нет, но наименование имеет максимальную длину 150 символов и в очень большом % случаев наши названия подразделений укладываются ровно в нее (даже некоторые слова сокращаем). Т.е. что бы мы ни дописали, это все равно отсечется платформой. Предупрежу предложение сделать доп реквизит "Организация" или что хуже "Наименование с организацией" - пока без обоснования (попробуйте сами догадаться почему этот выход не лучше).
2) если мы захотим фильтровать подразделения по организациям - нам придется это делать через ПОДОБНО на строковые поля большой длины - что крайне не производительно
3) ваше предложение не укладываются в архитектуру тех типовых решений с которыми настраивается обмен данными - это влечет за собой потери на допил синхронизаций структур данных и прочее.
4) если пользователь захочет создать новое подразделение в ДО и затем нужно будет его выгрузить в БП КОРП? в вашем случае придется парсить строку, затем искать в базе приемнике Организацию по наименованию (по УИДу то уже будет нельзя) - это вообще плохое решение.
Главный вопрос я повторю: почему разработчики 1С:ДО отошли от архитектуры большинства типовых решений? В ЧЕМ МЕТОДОЛОГИЧЕСКАЯ ЛОГИКА ТАКОГО РЕШЕНИЯ - отказа от подчинения справочника???
(10) RailMen, если Вы четко решили для себя, что Вы сделаете из не подчиненного справочника подчиненный, то делайте. Потом ищите подводные камни, допиливайте конфигурацию, находите косяки в процессе эксплуатации, вновь допиливайте конфигурацию... Потом делайте публикацию на инфостарте с описанием всего пути. Не понятно тогда к чему этот вопрос. Хотите много бессмысленной работы? Работайте!)
1) с трудом представляю себе наименование подразделений длиной в 150 символов. Если такая проблема действительно существует на практике, в чем я сомневаюсь, то можно попробовать решить и эту проблему: увеличением длины наименования, использованием префикса организации вместо наименования (менее информативно для пользователя), организационным решением по образованию наименований для подразделений (оптимально);
2) изменение наименований не мешает добавить реквизит "Организация", либо создать папки организаций, как Вам было предложено ранее (фильтровать соответственно по ним); Опять же вопрос в данный момент существует ли потребность в таком фильтре?
3) можете допиливать синхронизацию во всех базах, а можете переименовать во всех базах и использовать стандартную синхронизацию;
4) вновь элементарное решение - ограничить пользователю права на создание подразделений, хочешь новое подразделение - пиши служебную записку в бухгалтерию. Это правильный алгоритм работы.
1) с трудом представляю себе наименование подразделений длиной в 150 символов. Если такая проблема действительно существует на практике, в чем я сомневаюсь, то можно попробовать решить и эту проблему: увеличением длины наименования, использованием префикса организации вместо наименования (менее информативно для пользователя), организационным решением по образованию наименований для подразделений (оптимально);
2) изменение наименований не мешает добавить реквизит "Организация", либо создать папки организаций, как Вам было предложено ранее (фильтровать соответственно по ним); Опять же вопрос в данный момент существует ли потребность в таком фильтре?
3) можете допиливать синхронизацию во всех базах, а можете переименовать во всех базах и использовать стандартную синхронизацию;
4) вновь элементарное решение - ограничить пользователю права на создание подразделений, хочешь новое подразделение - пиши служебную записку в бухгалтерию. Это правильный алгоритм работы.
(11) obsfromekb, ваши предложения ведут как раз бОльшему объему работ, чем мои. Я это же прямо описал. Перечитайте ветку еще раз.
(12) obsfromekb, у нас много чего есть из типовых, но нет УТ. В этом смысле НАМ проще сделать по аналогии с ERP, чем УТ. Кстати, если не трудно, раскройте методологический смысл "универсальности" решения отказа от подчиненности в УТ.
(12) obsfromekb, у нас много чего есть из типовых, но нет УТ. В этом смысле НАМ проще сделать по аналогии с ERP, чем УТ. Кстати, если не трудно, раскройте методологический смысл "универсальности" решения отказа от подчиненности в УТ.
(13) RailMen,
Я с Вами не согласен. С одной стороны - переименовать подразделения, ограничить права пользователей, дать им инструкцию по образованию наименований новых подразделений, с другой стороны - переписать внушительную часть конфигурации, т.к. Подразделения используются практически везде. Выбор конечно за Вами.
По поводу не подчиненности подразделений (мои личные мысли/догадки, как было задумано 1С я не знаю):
УТ позиционируется, как конфигурация для работы менеджеров (продажи/закупки) и управленцев. Современные реалии России таковы, что любая контора купи-продай имеет несколько юр. лиц, дело тут не только в уходе от налогов, но также в особенностях налогообложения (одна организация без НДС, другая с НДС). Соответственно от того, что менеджер Вася торгует от 5 различных юр. лиц, он не стал числится в 5 подразделениях 5 различных организаций. Он просто менеджер Вася из отдела продаж и это удобно видеть в отчетности: отдел продаж продал на 100 миллионов, отдел VIP клиентов продал на 80 миллионов. С каких юр. лиц отгрузили - вопрос вторичный.
Я с Вами не согласен. С одной стороны - переименовать подразделения, ограничить права пользователей, дать им инструкцию по образованию наименований новых подразделений, с другой стороны - переписать внушительную часть конфигурации, т.к. Подразделения используются практически везде. Выбор конечно за Вами.
По поводу не подчиненности подразделений (мои личные мысли/догадки, как было задумано 1С я не знаю):
УТ позиционируется, как конфигурация для работы менеджеров (продажи/закупки) и управленцев. Современные реалии России таковы, что любая контора купи-продай имеет несколько юр. лиц, дело тут не только в уходе от налогов, но также в особенностях налогообложения (одна организация без НДС, другая с НДС). Соответственно от того, что менеджер Вася торгует от 5 различных юр. лиц, он не стал числится в 5 подразделениях 5 различных организаций. Он просто менеджер Вася из отдела продаж и это удобно видеть в отчетности: отдел продаж продал на 100 миллионов, отдел VIP клиентов продал на 80 миллионов. С каких юр. лиц отгрузили - вопрос вторичный.
(14) obsfromekb, попробую вас все таки убедить в своей правоте)))
Мое предложение: просто подчинить справочник "Структура предприятия" справочнику "Организации". И БОЛЬШЕ НИЧЕГО НЕ ДЕЛАТЬ ("переписать внушительную часть конфигурации"-это вы сами выдумали непонятно откуда). Не нужно включать учет по организациям. Не нужно выдумывать НОВЫЙ порядок ввода/именования подразделений, писать и согласовывать новые регламенты. Не нужно допиливать ОБМЕНЫ данными с другими конфигурациями (это ой какая не простая проблема). Для пользователей работа НЕ ИЗМЕНИТЬСЯ, они будут работать так, как привыкли в БП КОРП 3.0 с подчиненным справочником.
Вы предлагаете: изменить наименования подразделений, согласовать и утвердить новые порядки ввода/изменений подразделений, проделать работы по созданию новых правил обмена данными между ДО и БП КОРП (тут оооочень много подводных камней о которых я писал выше), а самое главное, один и тот же пользователь должен будет СОВЕРШАТЬ разные действия одном и том же справочнике в БП КОРП и в ДО.
Чей вариант лучше пусть каждый выберет для себя сам.
Я понимаю, что "Структура предприятия" - это в чистом виде управленческий справочник, в котором должны аккумулироваться подразделения разных юр лиц. И я не хочу переделывать его в регламентированный справочник ни в коем случае. Моя задача сделать работу с этим справочником комфортной для пользователя и интуитивно понятной.
Мое предложение: просто подчинить справочник "Структура предприятия" справочнику "Организации". И БОЛЬШЕ НИЧЕГО НЕ ДЕЛАТЬ ("переписать внушительную часть конфигурации"-это вы сами выдумали непонятно откуда). Не нужно включать учет по организациям. Не нужно выдумывать НОВЫЙ порядок ввода/именования подразделений, писать и согласовывать новые регламенты. Не нужно допиливать ОБМЕНЫ данными с другими конфигурациями (это ой какая не простая проблема). Для пользователей работа НЕ ИЗМЕНИТЬСЯ, они будут работать так, как привыкли в БП КОРП 3.0 с подчиненным справочником.
Вы предлагаете: изменить наименования подразделений, согласовать и утвердить новые порядки ввода/изменений подразделений, проделать работы по созданию новых правил обмена данными между ДО и БП КОРП (тут оооочень много подводных камней о которых я писал выше), а самое главное, один и тот же пользователь должен будет СОВЕРШАТЬ разные действия одном и том же справочнике в БП КОРП и в ДО.
Чей вариант лучше пусть каждый выберет для себя сам.
Я понимаю, что "Структура предприятия" - это в чистом виде управленческий справочник, в котором должны аккумулироваться подразделения разных юр лиц. И я не хочу переделывать его в регламентированный справочник ни в коем случае. Моя задача сделать работу с этим справочником комфортной для пользователя и интуитивно понятной.
(16) RailMen, Ну если Вы думаете, что можно "просто подчинить справочник "Структура предприятия" справочнику "Организации". И БОЛЬШЕ НИЧЕГО НЕ ДЕЛАТЬ", то удачи Вам. Я в такое не верю. Полагаю, что ошибки начнут вываливаться в самых неожиданных местах, т.к. разработчики в своем коде не закладывались на подчиненность справочника. Если я не прав и всё будет работать как часы, то я буду только рад.
Думаю что самая большая проблема тут в том, что никто, даже тот кто лично писал ДО, не сможет взять и гарантировать полную работоспособность программы после такого изменения. Хорошо, если Вы не встретитесь с ошибками, но дать гарантию, что их не будет вовсе, Вы полагаю не можете. В этом и кроется вся опасность Вашего предложения - нет гарантий, и никто Вам их не даст. Надо тестировать.
Думаю что самая большая проблема тут в том, что никто, даже тот кто лично писал ДО, не сможет взять и гарантировать полную работоспособность программы после такого изменения. Хорошо, если Вы не встретитесь с ошибками, но дать гарантию, что их не будет вовсе, Вы полагаю не можете. В этом и кроется вся опасность Вашего предложения - нет гарантий, и никто Вам их не даст. Надо тестировать.
(17) obsfromekb, сегодня первый день после доработки. Люди работают. Полет нормальный. Все, что было сделано в коде я описал выше. По факту - почти ничего. Результат тот, какой нужно. Обмены работают на ура (были изменения, но тоже очень скромные). Ответственность на мне, т.к. накопил опыт и не испугался )))
Если возникнут коллапсы - я о них тут напишу. Но скорее всего ничего страшного не случится.
Если возникнут коллапсы - я о них тут напишу. Но скорее всего ничего страшного не случится.
(19) obsfromekb, так ведь и не предлагал его включать. Почему-то как только люди узнают про подчинение Организациям, то сразу пытаются включить учет по организациям. А этого делать не нужно.
P.S. Только что поставил обновление 1С:ДО 2.0.6.5. Легко. Летим дальше.
P.S. Только что поставил обновление 1С:ДО 2.0.6.5. Легко. Летим дальше.
(21) progr-2008, строго говоря, любое изменение любой типовой конфигурации, любые попытки кастомизации - это действия с плохо прогнозируемыми последствиями. Пока я пишу этот текст сотни программистов как фикси, так и франчайзи, лопатят типовой код. Плохо это или хорошо? Это всего лишь обычная жизнь )))
(22) RailMen, не совсем так.
Доработка типовой конфигурации на уровне подписок на события, добавления реквизитов объектов, модулей и аналогичные действия без изменения именно типового функционала, т.е. именно добавление, а не изменение имеющегося типового функционала, дает возможность как обновлений без проблем, так и не создает проблем для использования типовых возможностей.
Намного серьезнее, когда идет доработка, затрагивающая имеющийся типовой функционал, особенно по конфигурациям, по которым обновления очень часто выпускаются.
Доработка типовой конфигурации на уровне подписок на события, добавления реквизитов объектов, модулей и аналогичные действия без изменения именно типового функционала, т.е. именно добавление, а не изменение имеющегося типового функционала, дает возможность как обновлений без проблем, так и не создает проблем для использования типовых возможностей.
Намного серьезнее, когда идет доработка, затрагивающая имеющийся типовой функционал, особенно по конфигурациям, по которым обновления очень часто выпускаются.
(23) progr-2008, согласен со всем, что вы написали. Мы скатываемся к озвучке банальностей и софистике, отвлекаясь от главного вопроса этой ветки. Однако, вопрос не в том КАК ЛУЧШЕ вносить изменения в типовые конфигурации.
У нас возникли проблемы, изложенные в 1 посте. Я предложил вариант решения проблемы при внедрении ДО в конкретном немаленьком предприятии - подчинение справочника "Структура предприятия" справочнику "Организации". Услышал другие варианты решения задачи, сравнил их между собой. Показал, что другие варианты не лучше, а в чем то сильно уступают моему варианту.
Остается вопрос МЕТОДИЧЕСКИЙ и АРХИТЕКТУРНЫЙ: на что повлияет включение подчиненности справочника «Структура предприятия» справочнику "Организации" в 1С:Документооборот 2.0 ?
Ответы типа: "а вот риски повышаются и обновление будет на 10 минут дольше" - пожалуйста, не предлагайте. Мне нужна КОНКРЕТИКА: какой блок учета [может] пострадать, какие бизнес процессы [могут] перестать работать и т.п. Без учета фактора выпуска новых обновлений 1С:ДО.
У нас возникли проблемы, изложенные в 1 посте. Я предложил вариант решения проблемы при внедрении ДО в конкретном немаленьком предприятии - подчинение справочника "Структура предприятия" справочнику "Организации". Услышал другие варианты решения задачи, сравнил их между собой. Показал, что другие варианты не лучше, а в чем то сильно уступают моему варианту.
Остается вопрос МЕТОДИЧЕСКИЙ и АРХИТЕКТУРНЫЙ: на что повлияет включение подчиненности справочника «Структура предприятия» справочнику "Организации" в 1С:Документооборот 2.0 ?
Ответы типа: "а вот риски повышаются и обновление будет на 10 минут дольше" - пожалуйста, не предлагайте. Мне нужна КОНКРЕТИКА: какой блок учета [может] пострадать, какие бизнес процессы [могут] перестать работать и т.п. Без учета фактора выпуска новых обновлений 1С:ДО.
(24) RailMen,
Вроде бы и не повлияет, если бы не ограничения прав доступа по организациям, интеграции с другими системами и нумерация документов.
Проблемы могут начаться, когда вам понадобиться пользователю из одного подразделения, которое вы сделали подчиненным организации, дать доступ к документам другой организации либо ограничить доступ к "родительской" организации. В т.ч. возможны проблемы при ограничении прав доступа и работе с документом с которым должны работать сотрудники разных подразделений и разных организаций.
Другая проблема с нумерацией - если вам вдруг понадобиться сделать сквозную нумерацию документов по всем однотипным отделам - ранее вы могли бы сделать например нумерацию по подразделению бухгалтерия, а сейчас у вас есть "цать" подразделений "бухгалтерия".
Третья проблема - вы соберетесь делать интеграцию ДО с другими конфигурациями 1С - вам придется помнить о том, что подразделения у вас теперь подчиненный справочник организациям, и вполне вероятна ситуация, когда организация будет одна, а подразделение другое, не связанное с этой организацией
Четвертая проблема - связана с правами доступа. Рано и поздно возникнет ситуация, когда сотрудникам одной организации надо будет запретить доступ к документам другой организации, но при этом оставить доступ к третьей, а отдельным личностям надо будет сделать все наоборот, и не дай бог, кто-то из сотрудников перейдет в другую организацию. В ДО и без ваших изменений раздача прав тот еще квест, а с ними "веселья" добавится.
если же вам надо одобрение - правильно ли сделали сделав справочник "структура предприятия" подчиненным справочнику "организации", то в рамках озвученной вами проблемы - правильно, если вам и вашим пользователям так будет удобней.
Остается вопрос МЕТОДИЧЕСКИЙ и АРХИТЕКТУРНЫЙ: на что повлияет включение подчиненности справочника «Структура предприятия» справочнику "Организации" в 1С:Документооборот 2.0 ?
Вроде бы и не повлияет, если бы не ограничения прав доступа по организациям, интеграции с другими системами и нумерация документов.
Проблемы могут начаться, когда вам понадобиться пользователю из одного подразделения, которое вы сделали подчиненным организации, дать доступ к документам другой организации либо ограничить доступ к "родительской" организации. В т.ч. возможны проблемы при ограничении прав доступа и работе с документом с которым должны работать сотрудники разных подразделений и разных организаций.
Другая проблема с нумерацией - если вам вдруг понадобиться сделать сквозную нумерацию документов по всем однотипным отделам - ранее вы могли бы сделать например нумерацию по подразделению бухгалтерия, а сейчас у вас есть "цать" подразделений "бухгалтерия".
Третья проблема - вы соберетесь делать интеграцию ДО с другими конфигурациями 1С - вам придется помнить о том, что подразделения у вас теперь подчиненный справочник организациям, и вполне вероятна ситуация, когда организация будет одна, а подразделение другое, не связанное с этой организацией
Четвертая проблема - связана с правами доступа. Рано и поздно возникнет ситуация, когда сотрудникам одной организации надо будет запретить доступ к документам другой организации, но при этом оставить доступ к третьей, а отдельным личностям надо будет сделать все наоборот, и не дай бог, кто-то из сотрудников перейдет в другую организацию. В ДО и без ваших изменений раздача прав тот еще квест, а с ними "веселья" добавится.
если же вам надо одобрение - правильно ли сделали сделав справочник "структура предприятия" подчиненным справочнику "организации", то в рамках озвученной вами проблемы - правильно, если вам и вашим пользователям так будет удобней.
(28) Africa, спасибо за профессиональный комментарий.
Кратко повторю, что сделано в "1С:ДО 2.0": справочник "Структура предприятия" подчинен справочнику "Организации", но при этом в настройках НЕ ВКЛЮЧЕН учет по организациям. Изменен код в 2 формах справочника "Структура предприятия", там вызываются процедуры из типовых общих модулей 1С:ДО (спасибо есть БСП). Обновление занимает на 5 минут дольше, чем в полностью авто режиме.
Попробую развеять озвученные проблемы:
1) настройка прав и их делегирование в разрезе элементов справочника "Структура предприятия" полностью типовой; в настройке прав "организации" не участвуют; в регистре сведений "СоставСубъектовПравДоступа" и "УчастникиПроцессов" подсистемы "УправлениеДоступом" нет измерений с типом "СправочникСсылка.Организации"; в этой связи проблем с ролевой моделью быть не должно;
2) проблемы с нумерацией не возникнет: все одноименные подразделения отличаются по значению "владелец" и можно разделить нумерацию таких подразделений как в типовых БП КОРП или ERP, хуже если их никак друг от друга не отличить, возможно придется допилить пару общих модулей - но это в самом плохом случае;
3) про интеграцию с другими конфигурациями: дык мы специально это все и затеяли для интеграции! попробуйте интегрироваться с типовой БП КОРП 3.0 или ERP 2.0 или ЗУП 2.5, если там есть подразделения с одинаковыми наименованиями - вы будете делать как мы!
Africa, еще раз спасибо за участие.
Кратко повторю, что сделано в "1С:ДО 2.0": справочник "Структура предприятия" подчинен справочнику "Организации", но при этом в настройках НЕ ВКЛЮЧЕН учет по организациям. Изменен код в 2 формах справочника "Структура предприятия", там вызываются процедуры из типовых общих модулей 1С:ДО (спасибо есть БСП). Обновление занимает на 5 минут дольше, чем в полностью авто режиме.
Попробую развеять озвученные проблемы:
1) настройка прав и их делегирование в разрезе элементов справочника "Структура предприятия" полностью типовой; в настройке прав "организации" не участвуют; в регистре сведений "СоставСубъектовПравДоступа" и "УчастникиПроцессов" подсистемы "УправлениеДоступом" нет измерений с типом "СправочникСсылка.Организации"; в этой связи проблем с ролевой моделью быть не должно;
2) проблемы с нумерацией не возникнет: все одноименные подразделения отличаются по значению "владелец" и можно разделить нумерацию таких подразделений как в типовых БП КОРП или ERP, хуже если их никак друг от друга не отличить, возможно придется допилить пару общих модулей - но это в самом плохом случае;
3) про интеграцию с другими конфигурациями: дык мы специально это все и затеяли для интеграции! попробуйте интегрироваться с типовой БП КОРП 3.0 или ERP 2.0 или ЗУП 2.5, если там есть подразделения с одинаковыми наименованиями - вы будете делать как мы!
Africa, еще раз спасибо за участие.
(31) RailMen,
По поводу первых двух пунктов, важно чтобы у вас или ваших последователей позже не возникло желания "внезапно" включить ограничение доступа по организациям. Тогда, как я и написал, все будет работать.
Что касается интерграций ДО. C ERP 2.0 он уже интегрирован, и эта интеграция даже работает. Под интеграцией я понимаю использование функционала ДО непосредственно из ERP 2.0 когда из документа в ERP запускается бизнес-процесс в ДО, прикладываются файлы и печатные формы, и создаются документы ДО.Но в ERP есть два справочника - "Структура предприятия" (такой же как и в типовом ДО) и "подразделения организаций" - аналогичный справочникам в БП и ЗУП. В ДО методологически при интеграции справочник "структура Предприятия" использует аналогичный справочник из ERP. В вашем случае придется изменить эту интеграцию.
БП 3.0 Корп и Зуп 2.5 - с этими конфигурациями нет типовой интеграции с ДО - с БП есть обмен справочниками контрагентов, организаций и контактных лиц
С ЗУП ДО вообще на сегодня данными не обменивается. Поэтому тут все карты вам в руки :)
По поводу первых двух пунктов, важно чтобы у вас или ваших последователей позже не возникло желания "внезапно" включить ограничение доступа по организациям. Тогда, как я и написал, все будет работать.
Что касается интерграций ДО. C ERP 2.0 он уже интегрирован, и эта интеграция даже работает. Под интеграцией я понимаю использование функционала ДО непосредственно из ERP 2.0 когда из документа в ERP запускается бизнес-процесс в ДО, прикладываются файлы и печатные формы, и создаются документы ДО.Но в ERP есть два справочника - "Структура предприятия" (такой же как и в типовом ДО) и "подразделения организаций" - аналогичный справочникам в БП и ЗУП. В ДО методологически при интеграции справочник "структура Предприятия" использует аналогичный справочник из ERP. В вашем случае придется изменить эту интеграцию.
БП 3.0 Корп и Зуп 2.5 - с этими конфигурациями нет типовой интеграции с ДО - с БП есть обмен справочниками контрагентов, организаций и контактных лиц
С ЗУП ДО вообще на сегодня данными не обменивается. Поэтому тут все карты вам в руки :)
(32) Africa, спасибо за предупреждение не включать ограничение доступа по организациям, т.к. наша ролевая модель как раз это подразумевает.
У нас интеграция с БП КОРП 3.0. Есть далеко идущие планы по переходу на ERP 2.0. В этой связи ваш предыдущий пост является лично для меня очень ценным - пазл что называется сложился. Наверно самым полезным в этой ветке, ради него я сюда и писал. Спасибо.
P.S. Написал неплохие правила обмена данными БП КОРП 3.0 -> ДО 2.0 (типовые по ряду причин не подошли). Будет настроение напишу тут статью. Там оказалось довольно много интересного, с чем может столкнуться любой внедренец.
У нас интеграция с БП КОРП 3.0. Есть далеко идущие планы по переходу на ERP 2.0. В этой связи ваш предыдущий пост является лично для меня очень ценным - пазл что называется сложился. Наверно самым полезным в этой ветке, ради него я сюда и писал. Спасибо.
P.S. Написал неплохие правила обмена данными БП КОРП 3.0 -> ДО 2.0 (типовые по ряду причин не подошли). Будет настроение напишу тут статью. Там оказалось довольно много интересного, с чем может столкнуться любой внедренец.
(10) RailMen,
По поводу ГЛАВНОГО вопроса:
Почему "отказ" от подчиненного справочника? Подразделения подчинены Организациям в конфигурациях семейства Бухгалтерии преимущественно. В 1С Торговле справочник "Подразделения" - самостоятельный, например. Вот и ответ на Ваш вопрос. Никакого отказа не было, просто ДО попытались сделать универсально.
По поводу ГЛАВНОГО вопроса:
Почему "отказ" от подчиненного справочника? Подразделения подчинены Организациям в конфигурациях семейства Бухгалтерии преимущественно. В 1С Торговле справочник "Подразделения" - самостоятельный, например. Вот и ответ на Ваш вопрос. Никакого отказа не было, просто ДО попытались сделать универсально.
Работаю А головной компании главным бухгалтером. В регионах имеем обособленные подразделения и филиалы. В итоге ушли от деления на отделы, как то бухгалтерия или др. Есть Головная компания в г. Москве и Обособленные подразделения в других городах. Проблемы исчезли.
Деление осталось только в ЗУП. И то после выгрузки стали править аналогично Бухгалтерии.
Деление осталось только в ЗУП. И то после выгрузки стали править аналогично Бухгалтерии.
я вот одного понять не могу, что мешает во всех организациях заиметь одинаковые подразделения, тогда и проблема отпадет
В ДО учет по подразделениям ведется всегда, организациям подключаемый. В отчетах и отборах сможете выбирать нужную организацию и подразделение
PS Внедрение это не только перепилка конфы, а еще и оптимизация и перестроение учета.
В ДО учет по подразделениям ведется всегда, организациям подключаемый. В отчетах и отборах сможете выбирать нужную организацию и подразделение
PS Внедрение это не только перепилка конфы, а еще и оптимизация и перестроение учета.
(29) reznic, что мешает переименовать - читайте выше. Если кратко - наименования элементов подразделений (и не только) в холдинге из нескольких юр лиц жестко "забетонировано". Любая смена наименований - и бухгалтер/экономист/аудитор не сформирует в точности такой же отчет, какой он формировал вчера/неделю/месяц назад. Предложения "просто переименовать" - для некрупных частных контор. И потом конфигурации 1С ЗУП, БП КОРП, ERP, УПП изначально не запрещают одинаковые наименования подразделений. Просто разработчики 1С:ДО плохо проработали как 1С:ДО будет синхронизироваться с другими учетными системами на базе 1С. Или проработали на примере очень маленьких компаний.
В версии 8.3 появилась возможность управлять представлением. Можно не меняя наименование изменить представление, которое увидят пользователи при выборе соответствующих элементов справочника. Соответственно будет решена проблема путаницы пользователей при выборе подразделений.
Более подробно, например, здесь -
Более подробно, например, здесь -
(34), я изучил новые возможности. Только вот, чтобы сложить представление элемента для пользователя надо знать к какой организации привязан элемент справочника "Структура предприятия". Так, что от подчиненности не уйти никак.
(35) reznic, сейчас готовлю небольшую статью по правилам выгрузки данных их БП КОРП в ДО. Правила созданы КД 2.1. Да, это не модная КД 3.0, и даже не бесшовный обмен на web сервисе. Но тоже прекрасно работает. Пиши в личку, если хочешь.
(35) reznic, сейчас готовлю небольшую статью по правилам выгрузки данных их БП КОРП в ДО. Правила созданы КД 2.1. Да, это не модная КД 3.0, и даже не бесшовный обмен на web сервисе. Но тоже прекрасно работает. Пиши в личку, если хочешь.
Вся глобальность проблемы с подразделениями в решениях 1С заключена в концептуальной комплексности этого понятия.
Есть три разновидности структуры:
- Управленческая (собственно, подразделения)
- Юридическая (организации и подразделения организаций)
- Финансовая (цфо)
Между ними может быть много механизмов связи. Например, если есть штатное расписание, то позиции штатного расписания могут достаточно произвольным образом связывать подразделение и подразделение организации.
Поэтому в разных конфигурациях унаследованы разные способы связей между этими тремя структурами. Самая жесткая ситуация это использовать связку ERP 2.0, отдельного ЗУП 3.0, Документооборота и какого-нибудь решения для бюджетирования, к примеру БИТ:Финанс. Всего получится более 20 механизмов, где могут быть отражены связи между сходными по смыслу, но различными по концептуальному проектированию сущностями.
А если система сложно-интергрированная (например казначейство ERP, часть подразделений считается в ERP, часть в ЗУП, бюджетирование в ERP, согласование заявок в документообороте, да еще взаимодействие с какой-нибудь старой системой документооборота, а еще, не дай бог, какая-нибудь внешняя CRM система) и мы имеем до 200 вариантов мэппинга разных структур компании друг на друга. Ну и давайте еще возьмем перманентные процессы реструктуризации, с одновременным использованием до трех-четырех версий каждой структуры (устаревшая, но еще не окончательно удаленная, действующая сейчас как основная, новая, на которую уже начали переходить и перспективная, которая сейчас в разработке), то число мэппингов легко уходит за 1000.
И попробуйте управлять всеми этими процессами. Это если управлять. А в большинстве предприятий это все брошено на самотек и происходит стихийно.
Есть три разновидности структуры:
- Управленческая (собственно, подразделения)
- Юридическая (организации и подразделения организаций)
- Финансовая (цфо)
Между ними может быть много механизмов связи. Например, если есть штатное расписание, то позиции штатного расписания могут достаточно произвольным образом связывать подразделение и подразделение организации.
Поэтому в разных конфигурациях унаследованы разные способы связей между этими тремя структурами. Самая жесткая ситуация это использовать связку ERP 2.0, отдельного ЗУП 3.0, Документооборота и какого-нибудь решения для бюджетирования, к примеру БИТ:Финанс. Всего получится более 20 механизмов, где могут быть отражены связи между сходными по смыслу, но различными по концептуальному проектированию сущностями.
А если система сложно-интергрированная (например казначейство ERP, часть подразделений считается в ERP, часть в ЗУП, бюджетирование в ERP, согласование заявок в документообороте, да еще взаимодействие с какой-нибудь старой системой документооборота, а еще, не дай бог, какая-нибудь внешняя CRM система) и мы имеем до 200 вариантов мэппинга разных структур компании друг на друга. Ну и давайте еще возьмем перманентные процессы реструктуризации, с одновременным использованием до трех-четырех версий каждой структуры (устаревшая, но еще не окончательно удаленная, действующая сейчас как основная, новая, на которую уже начали переходить и перспективная, которая сейчас в разработке), то число мэппингов легко уходит за 1000.
И попробуйте управлять всеми этими процессами. Это если управлять. А в большинстве предприятий это все брошено на самотек и происходит стихийно.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот