Сложно сказать в чем причина конкретно в вашем случае, причин может быть масса. Нужно анализировать состав отправляемых данных, менеджер конкретного плана обмена. У нас на нескольких проектах были случаи, когда в подчиненные узлы тащили совсем ненужную там информацию о версионировании объектов (типовой функционал) или распухшие нечищенные логи каких-то регламентных заданий (кастомные). Если хотите, можем быстро помочь разобраться
Если имеется в виду всем работать в одной базе, в центре - это хороший вариант, когда подходит под условия работы компании. В случае с нашим заказчиком не подходил. Было доп. условие оставить архитектуру РИБ, т.к. некоторые новые точки открываются в локациях с нестабильным интернетом (остались еще такие) и у них должна быть возможность работать автономно.
С ЦБ были свои сложности, это был отдельный проект. Дорабатывали правила регистрации, модули обмена. Оптимизировали в части запуска постобработок после сессии обмена с каждым узлом (поведение в типовых) - заменили на общее регламентное с учётом специфики работы клиента. Бухгалтера никуда не сбегали - конфигурация торговая, УТ.
Сложность с том, что есть общий состав данных, источником которого является центральная база. Это общие справочники, документы ценообразования, независимые регистры сведений. И есть часть данных, которая должна оставаться только в самом узле и в центральном, на случай необходимости восстановления узла. Так, например, в каждом узле разрешено заводить свою номенклатуру, которая не должна разойтись по остальным узлам.
Т.е. на старте (открытии) точки вся НСИ в узле общая. Этот состав и поддерживается в эталонной базе.
Клиенты не знали, что они получат что-то бесплатное за выбор этого бургера. Оценивался интерес не к внешнему виду, а к новому рецепту, который был указан на фото (как и для других позиций меню).
Данная статья это ответ на реальный запрос одного из наших клиентов. Он уже год работает в 1С: КА, и мы помогли ему выстроить основные процессы продаж, закупок и склада, а теперь он планирует развивать блок CRM.
Суть статьи – не прямое сравнение 1C:CRM с 1С:ERP (КА, УТ), что, как Вы правильно заметили, не имеет смысла, а помощь в ответе на вопрос «Стоит ли внедрять модуль 1С:CRM?»
В 1С:CRM в настройках прав есть функциональная опция «Уровни доступа» и соответствующий ей одноименный справочник, в котором задается иерархия доступа. Уровень доступа присваивается Пользователям и Клиентам. Чем выше в иерархии справочника указанный у пользователя уровень, тем больше прав имеет этот пользователь, т.к. доступ предоставляется ко всем клиентам и их документам, уровни доступа которых ниже.
В 1С:ERP (КА, УТ) такой функциональности нет.
Подробнее: https://youtu.be/TWpdkBJZqKA
Сложно сказать в чем причина конкретно в вашем случае, причин может быть масса. Нужно анализировать состав отправляемых данных, менеджер конкретного плана обмена. У нас на нескольких проектах были случаи, когда в подчиненные узлы тащили совсем ненужную там информацию о версионировании объектов (типовой функционал) или распухшие нечищенные логи каких-то регламентных заданий (кастомные).
Если хотите, можем быстро помочь разобраться
Если имеется в виду всем работать в одной базе, в центре - это хороший вариант, когда подходит под условия работы компании. В случае с нашим заказчиком не подходил. Было доп. условие оставить архитектуру РИБ, т.к. некоторые новые точки открываются в локациях с нестабильным интернетом (остались еще такие) и у них должна быть возможность работать автономно.
С ЦБ были свои сложности, это был отдельный проект. Дорабатывали правила регистрации, модули обмена. Оптимизировали в части запуска постобработок после сессии обмена с каждым узлом (поведение в типовых) - заменили на общее регламентное с учётом специфики работы клиента. Бухгалтера никуда не сбегали - конфигурация торговая, УТ.
Сложность с том, что есть общий состав данных, источником которого является центральная база. Это общие справочники, документы ценообразования, независимые регистры сведений. И есть часть данных, которая должна оставаться только в самом узле и в центральном, на случай необходимости восстановления узла. Так, например, в каждом узле разрешено заводить свою номенклатуру, которая не должна разойтись по остальным узлам.
Т.е. на старте (открытии) точки вся НСИ в узле общая. Этот состав и поддерживается в эталонной базе.
Клиенты не знали, что они получат что-то бесплатное за выбор этого бургера. Оценивался интерес не к внешнему виду, а к новому рецепту, который был указан на фото (как и для других позиций меню).
«Жизнь – это череда выборов»
Данная статья это ответ на реальный запрос одного из наших клиентов. Он уже год работает в 1С: КА, и мы помогли ему выстроить основные процессы продаж, закупок и склада, а теперь он планирует развивать блок CRM.
Суть статьи – не прямое сравнение 1C:CRM с 1С:ERP (КА, УТ), что, как Вы правильно заметили, не имеет смысла, а помощь в ответе на вопрос «Стоит ли внедрять модуль 1С:CRM?»
В 1С:CRM в настройках прав есть функциональная опция «Уровни доступа» и соответствующий ей одноименный справочник, в котором задается иерархия доступа. Уровень доступа присваивается Пользователям и Клиентам. Чем выше в иерархии справочника указанный у пользователя уровень, тем больше прав имеет этот пользователь, т.к. доступ предоставляется ко всем клиентам и их документам, уровни доступа которых ниже.
В 1С:ERP (КА, УТ) такой функциональности нет.
Подробнее: https://youtu.be/TWpdkBJZqKA