Добрый день!
Помогите, пожалуйста, разобраться и найти аргументы)
Есть задача, перейти на "Управление торговлей для Украины", редакция 2.3.
За предыдущее время работы в старой системе накопилась информация о нескольких миллионах покупателей (правда, хранится она как информации о Карте лояльности в которых уже указана информация о покупателе).
Сейчас встал вопрос, в каком справочнике хранить эту информацию.
Я настаиваю на том, что первичный покупатель, т.е. физическое лицо. Следовательно, нам нужно хранить информацию в разрезе Клиент, у которого есть одна или несколько карт лояльности. При этом использовать максимально стандартную функциональность 1С, без необходимости переделывать "Заказ покупателя", например или какие-либо отчеты.
Программисты же всячески этому сопротивляются, аргументирую это тем, что создание такого количества клиентов создаст множество ненужных реквизитов, которые не будут использовать, но будут перегружать базу.
Подскажите, пожалуйста, кто прав в нашем споре.
И если моё предположение верное, какие найти аргументы для того, чтобы убедить программистов.
Заранее благодарю за советы и помощь.
Помогите, пожалуйста, разобраться и найти аргументы)
Есть задача, перейти на "Управление торговлей для Украины", редакция 2.3.
За предыдущее время работы в старой системе накопилась информация о нескольких миллионах покупателей (правда, хранится она как информации о Карте лояльности в которых уже указана информация о покупателе).
Сейчас встал вопрос, в каком справочнике хранить эту информацию.
Я настаиваю на том, что первичный покупатель, т.е. физическое лицо. Следовательно, нам нужно хранить информацию в разрезе Клиент, у которого есть одна или несколько карт лояльности. При этом использовать максимально стандартную функциональность 1С, без необходимости переделывать "Заказ покупателя", например или какие-либо отчеты.
Программисты же всячески этому сопротивляются, аргументирую это тем, что создание такого количества клиентов создаст множество ненужных реквизитов, которые не будут использовать, но будут перегружать базу.
Подскажите, пожалуйста, кто прав в нашем споре.
И если моё предположение верное, какие найти аргументы для того, чтобы убедить программистов.
Заранее благодарю за советы и помощь.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)если УТ2.3 для Украины - это аналог УТ11.4 для РФ, то покупатель - это контрагент+партнер. Карты лояльности - это отдельный справочник со ссылкой на контрагент+партнер.
Не вижу проблемы загрузить n миллионов контрагентов и m миллионов карт лояльности для них, при условии m >= n.
Не вижу проблемы загрузить n миллионов контрагентов и m миллионов карт лояльности для них, при условии m >= n.
(4) спасибо)
доказать нужно то, что "правильный" подход работать со справочником "Клиенты", к каждому из которых можно привязать любое количество карт лояльности. При этом можно использовать всю стандартную функциональность.
А не наоборот, когда все продажи регистрируются условно на одного контрагента и только в документе продажи указывается номер карты лояльности. И потом уже все отчеты нужно строить по этому полю
доказать нужно то, что "правильный" подход работать со справочником "Клиенты", к каждому из которых можно привязать любое количество карт лояльности. При этом можно использовать всю стандартную функциональность.
А не наоборот, когда все продажи регистрируются условно на одного контрагента и только в документе продажи указывается номер карты лояльности. И потом уже все отчеты нужно строить по этому полю
(5)Так объясните это программистам, что вешать все на одного контрагента - вообще не вариант.
Как минимум по той причине, что есть контактная информация, адреса доставок, всякие там дни рождения, к которым можно всякие скидки приурочить и прочие плюшки от использования множество контрагентов вместо одного.
Как минимум по той причине, что есть контактная информация, адреса доставок, всякие там дни рождения, к которым можно всякие скидки приурочить и прочие плюшки от использования множество контрагентов вместо одного.
Пытаюсь) говорят, что все это можно сделать и для карты лояльности.
пока выглядит как-то так
Говорят. Что чего нет, то добавим(((
Я перепробовал все аргументы, решил сам себя проверить здесь. Возможно, я что-то не так понимаю и это нормально учитывать клиентов через карты лояльности. а не так как задумано, учитывать клиентов, у которых есть карты лояльности.
Думаю, что основная проблема, это то, что функциональность "учет по картам лояльности" готова процентов на 80-90 и некто не хочет заморачиваться.
Но, я подозреваю, что если сейчас это так оставить, то потом оно аукнется.
пока выглядит как-то так
Говорят. Что чего нет, то добавим(((
Я перепробовал все аргументы, решил сам себя проверить здесь. Возможно, я что-то не так понимаю и это нормально учитывать клиентов через карты лояльности. а не так как задумано, учитывать клиентов, у которых есть карты лояльности.
Думаю, что основная проблема, это то, что функциональность "учет по картам лояльности" готова процентов на 80-90 и некто не хочет заморачиваться.
Но, я подозреваю, что если сейчас это так оставить, то потом оно аукнется.
Если это розница, то я вообще не понимаю, зачем нужны контрагенты - взаиморасчетов нет, дебиторки-кредиторки нет, EDI нет, вообще ничего нет. Действительно, все что есть - это номер карты с идентифицирующей информацией (пол, ДР, телефон, электронка).
Надо ли в этом случае именно в УТ под каждую карту заводить контрагента с партнером - ну я хз, тут действительно есть над чем задуматься...
Надо ли в этом случае именно в УТ под каждую карту заводить контрагента с партнером - ну я хз, тут действительно есть над чем задуматься...
(14)привязка дней рождений и телефонов - слишком много чего придется изменить, чтобы эти данные брались из карты лояльности, а не из клиента, привязанного к карте при использовании типового функционала.
Так же и с заказами, адрес в нем заполняется по данным владельца карты.
Что делать в случае, когда клиенту еще не положена карта или он от нее отказался по какой-то причине, но при этом является постоянным покупателем?
Далее это все нужно будет поддерживать - в итоге шибко дорого получится иметь одного клиента вместо множества
Так же и с заказами, адрес в нем заполняется по данным владельца карты.
Что делать в случае, когда клиенту еще не положена карта или он от нее отказался по какой-то причине, но при этом является постоянным покупателем?
Далее это все нужно будет поддерживать - в итоге шибко дорого получится иметь одного клиента вместо множества
Еще раз повторюсь. Я исхожу из того, что у ТС - розничная торговля в магазине! Он не ведет сейчас базу клиентов в своей текущей системе. Для торговли в магазине - не нужны адреса доставки, не нужны контактные данные клиентов. Да даже заказы не нужны!
А вот если у него есть сайт для онлайн-заказов - то такие клиенты конечно должны быть авторизованы! Со всем вытекающими адресами доставки, резервированием по заказам, и прочие прелести.
В отличие от неопознанных розничных клиентов...
А вот если у него есть сайт для онлайн-заказов - то такие клиенты конечно должны быть авторизованы! Со всем вытекающими адресами доставки, резервированием по заказам, и прочие прелести.
В отличие от неопознанных розничных клиентов...
(15)
Что делать в случае, когда клиенту еще не положена карта или он от нее отказался по какой-то причине, но при этом является постоянным покупателем?
Опять же - если это розничный оффлайновый магазин - то он не может являться постоянным покупателем. Покупатель на кассе никак себя не авторизует.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот