v8: Несколько менеджеров работают с одним контрагентом #458561

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

[можно ли не переделывая серьезно типовую конфигу реализовать анализ продаж в разрезе нескольких менеджеров] добавь реквизит Менеджер в РТиУ и получишь анализ продаж при развороте по регистратору если мало - сделай дубль Рг Продажи по менеджеру и пиши в него в измерение

То есть по любому отход от типовой по структуре ригистров и переделка всех документов по работе к клиентом . А в чем смысл тогда иметь возможность иметь несколько менеджеров в карточке клиентов , и не имет возможности их выбрать ? Просто не понимаю внутренней логики.

[можно ли не переделывая серьезно типовую конфигу] используй Проекты

у нас разделение по договорам. Добавил реквизит Менеджер в договор

Насчет Проектов покопаю , я вообще предварительно через договора думал сделать

Или в документах или в РН Продажи должен быть реквизит/измерение.

если один договор - один менеджер, то юзай в договоре Вид взаиморасчетов - останешься с типовой

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

[по крайней мере не переписывать ядро] ошибочная позиция, переписывать УТ придётся, а уж реквизитов новых через пол года будут десятки

Сейчас изучаю логику конфы "Управление торговлей" , и в принципе наш учет ложится на неё практически без проблем за исключением работы с агентами. Увидел возможность иметь несколько агентов у клиента , сначала обрадовался , а потом - опс , выбрать нельзя , данные на регистрах не  хранятся , в документе не хранятся , поманили миражом :)

Основная задача перехода на восьмерку - интеграция с АСУМТ Оптимум , изучив по нему документацию понял , что нашу самописку с ним не увязать (даже структура роботы с торговыми точками у нас принципиально другая - в типовых продажа в точку которая кому то принадлежит , у нас продажа клиенту с последующей доставкой в точку , задолженности по точкам не рассчитываются специально , и справочник контрагентов очень компактен , в четыре примерно раза меньше чем в типовой), начнешь изменять ядро - прощай интеграция

[начнешь изменять ядро - прощай интеграция] в УТ нет ядра интеграции с реквизиты любого справочника по барабану

Есть базовая структура данных , на кторую заточена структура обмена с Оптимум , например обязательное требование  - привязка торгового представителя к торговой точке для того чтобы серверной частью Оптимума на кокретный КПК отправлялалсь только информация касающаяся конкретного агента , переписывать Оптимум под нас никто не будет , а если и будут то за очень серьезные денюжки , следовательно мы должны подстроится под него

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

А потом начинаются проблемы с обменом между торговлей и бухгалтерией :(

+11 - постучи в аську 201216890. Оптимум не так страшен как кажется. Подскажу - думаю что и на вашу конфу его вполне реально внедрить. Я на двух клиентах внедрял не их модуль обмена, а свой - по сути своей все уложилось в 2 обработки и чуть чуть доп. реквизитов.

А если протсо сделать учет по разным договорам? Договор назвать именем манагера, а учет ведется в их разрез. (дубово, но без изменений конфы)

По договорам - это вариант , но надо посмотреть можно ли увязать договара с конкретным агентом , нюанс в том что договора так сказать не свозные а каждому клиенту свои , например если у одного клиента есть договор через агента сидорова  то у другого договор через агента Сидорофа , и получаться формально разные агенты. Очень низкая дуракозащищеность в условиях когда клиентская база пара тысяч клиентов

разные менеджеры - не значит выделенный налоговый учет. в части детализации и управления торговыми процесами - УТ нифига не "управление" - так только "наброски" и понты....

за то рег. для взм. не мерянное количество расчеты, взм, взм по расч. документам - :(

Налоговый учет как раз абсолютно не нужен , налоговикам пофигу вообще через кого продажа осуществлялась. А насчет наброска - ценовые политики напромер отлично сделаны , а детализация по менеджерам таки да , такое ощущение что начали делать и бросили на пол пути

механика ценообразования - давно использовали такие принципы. + у нас есть "волны цен" по свойствам номенглатуры - аналога в УТ нет...

А у меня матрица цен , тип цены товара - тип цены клиента , с дополнительными фишками , но в принципе в методологию  УТ укладывается

С проектами та же шняга , слишком они предопределенны что ли , значить либо договорами , либо перписывать :(