Всем доброго времени суток! Подскажите плиз, как мне навести порядок в мастер-данных по клиентам.

Ситуация следующая: исторически для большинства клиентов существовала только одна запись шип-ту (кастомер Х / получатель Х); для меньшей части было несколько шип-ту (кастомер X / получатель X, получатель Y), клиентская служба при создании заказов выбирала нужного получателя.

Сейчас мы переходим на новую конвенцию номеров получателей, таким образом к каждому клиенту будет приписано минимум два получателя (1 старый и 1 новый), при этом использоваться должны только новые номера. Старая конвенция номеров получателей (если упрощенно): 4хххххх; новая конвенция - 5хххххх

Задача: при создании заказов / контрактов сотрудник отдела по работе с клиентами не должен иметь возможности выбрать старый номер получателя. Есть ли какая-нибудь возможность заблокировать конкретные записи партнерских функций кастомера?..

если у вас это разные группы счетов, то настройте допустимые роли партнеров для групп счетов (уберите просто SHIP-TO для группы счетов дебиторов на 4xxxxx). Должно помочь...

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

Либо блокировка старых и создание всех заново; либо экзит при выборе партнера; либо новая группа счетов (см. совет waverzzzа); либо массовое удаление из ОЗД ненужных ролей. Везде свои недостатки. Вообще, какой смысл дублировать ОЗД для разных ролей партнеров?

MNV, спасибо за ответ! Я сейчас смотрю в сторону модификации экзита; похоже, это единственный реалистичный вариант: старые кастомеры все равно будут использоваться для прозрачности кредитного контроля; новая группа счетов - слишком много переделывать придется; старые роли должны остаться для правильности ретроспективной отчетности




К сожалению, одновременно с моим приходом в компании пошел в продуктив проект (внедрили внешнюю систему прогнозирования продаж), для которого экспорт данных делается по шип-ту, и для корректности этого экспорта ряд настроек должен отличаться (например: одно и то же поле для названия юридического лица контрагента теперь регулируется разными конвенциями в зависимости от роли)