Клиент = ЮрЛицо?

[kirillss]

Заказчик хочет чтобы понятие "клиент" соответствовало не просто ЮЛ клиента, а набору: ЮЛ клиент, ЮЛ заказчика (он - холдинг), сезон и т.п.
Ну и соответсвенно в документы по продаже попадает именно такой "клиент".
Разработка заказная - посему конечно и такой изврат налобаем. Но больно меня это напрягает
Вопросы -
1 Как аргументированно отговорить заказчика от такого подхода к понятию клиент?
2 Как продукты MBS трактуют клиента? Там Клиент = ЮЛКлиента?

[Harry]

А можно сделать через список контактов?
Контактное лицо может быть физ. или юр. лицом!

[UGT]

У вашего заказчика в базе каждому юр. лицу соответсвует своя фирма, или весь учет ведется в некой консолидирующей фирме?
Вообще, какой смысл всего этого?
В Навижн Клиент=юр. лицо, у него есть адрес, ИНН и т.д. Можно конечно определенный холдинг завести как одного клиента, чтобы видеть его общий баланс, но тогда придется поколдовать над печатью документов, чтобы в них проставлялись правильные реквизиты клиента.

[kirillss]

2Harry : Проблема не в том что физ или юр лицо, а в том что Заказчик считает что ЮрЛицу соответствует несколько клиентов (вернее несколько кодов в системе)

[RedFox]

Цитата:

Сообщение от kirillss

Заказчик хочет чтобы понятие "клиент" соответствовало не просто ЮЛ клиента, а набору: ЮЛ клиент, ЮЛ заказчика (он - холдинг), сезон и т.п.
Ну и соответсвенно в документы по продаже попадает именно такой "клиент".
Разработка заказная - посему конечно и такой изврат налобаем. Но больно меня это напрягает
Вопросы -
1 Как аргументированно отговорить заказчика от такого подхода к понятию клиент?
2 Как продукты MBS трактуют клиента? Там Клиент = ЮЛКлиента?

Делали такое - заводили ВСЕХ клиентов "холдинга" (потому что), а потом связывали по полю "Our Account No." единым значением или признаком.

[Dzemon]

Да многие это делали ;-)
Собсно проблем две:
1. Печать документов - от кого, кому, зачем ;-) (особенно счета-фактуры)
2. Оценка задолженности (баланс по Клиенту и юрлицам, консолидированно и в разрезе ЮЛ, взаимозачет)

Ну потом еще вылезет Анализ по измерениям, если им пользуетесь.

Самый примитивный вариант реализации - через Клиент Банковский Счет.

А как ЮЛ делят по сезонам?!

[kirillss]

"А как ЮЛ делят по сезонам?!"

Тупо делят - разные клиенты на разные сезоны))))))

[Dzemon]

Цитата:

Сообщение от kirillss

"А как ЮЛ делят по сезонам?!"

Тупо делят - разные клиенты на разные сезоны))))))

Ай, молодцы! А что за бизнес у клиента?

[kirillss]

2UGT "Вообще, какой смысл всего этого? "

Вопрос конечно интересный!!!!
У заказчика несколько доводов
1 так работали на старой системе - посему привычно
2 При его схеме работы получается такая цепочка
Документ >-- Клиент --< (ЮЛ, ЮЛ Заказчика, Сезон, ....)
То есть клиент как бы задает допустимые сочетания параметров (ЮЛ, ЮЛ Заказчика, Сезон, ....)
3 Ну и типа быстрота ввода - вместо всех параметров ввода один - клиент. Типа манагеры всех своих клиентов и так наизусть помнят

Но очень хочется его от этого отговорить

[kirillss]

шмотки в основном

[regent]

Полагаю самый логичный способ (с позиции системы): 1 клиент = 1 ЮЛ. При этом каждому клиенту присвоить стандартное измерение, которое будет его относить к конкретной группе компаний. Далее, если необходимо создаем аналитические отчеты по группе компаний.
Что касаестя "...Типа манагеры всех своих клиентов и так наизусть помнят..." - система, и автоматизация в общем, ИМХО в первую очередь предпологает исключение человеского фактора. Если манагеры хотят работать на память и по бумажке - может им система не нужна.... Это гиперболизировано конечно, но смысл именно в том, что при смене специалистов компания не должна зависнуть от отсутствия информации, которая ушла вместе со специлистом.

[Fordewind]

Цитата:

Сообщение от kirillss

2UGT "Вообще, какой смысл всего этого? "

Вопрос конечно интересный!!!!
У заказчика несколько доводов
1 так работали на старой системе - посему привычно
...
3 Ну и типа быстрота ввода - вместо всех параметров ввода один - клиент. Типа манагеры всех своих клиентов и так наизусть помнят

Но очень хочется его от этого отговорить

к вопросу "Как отговорить"

1. Если их все устраивало, то зачем менять систему?
3. А вот это вообще бред, ИМХО. Или каждый новый менеджер сначала сдает экзамен по знанию названий клиентов?
Чем база менее прозрачна, тем дороже стоит получить из нее сведенья для анализа и отчетности.

P.S. Разбивка клиентов по сезонам думаю это ноухау!

[Fordewind]

тут был дубль

[RedFox]

Цитата:

Сообщение от regent

Полагаю самый логичный способ (с позиции системы): 1 клиент = 1 ЮЛ. При этом каждому клиенту присвоить стандартное измерение, которое будет его относить к конкретной группе компаний. Далее, если необходимо создаем аналитические отчеты по группе компаний.

Вот это очень хороший совет, если используете анализ по измерениям. Только нужно сделать обязательным для заполнения данноое измерение и зачести чел-ка\роль\пункт в штатном расписаним (не знаю что вам больше подходит и нужно - Вам виднее), который будет заводить сразу новые измерения в системе.

ИМХО А память человека такая ошибочная и хрупкая... не надо на нее надеяться.

[kirillss]

2Fordewind
"1. Если их все устраивало, то зачем менять систему? " Ну, во-первых, заказчикам такое не говорят)))))))). Во-вторых, им платформу надо менять - старая уж больно устарела и не соответсвует выросшему бизнесу.

Весь прикол состоит в том, что их понятие Клиента совершенно противоречит общепринятому (Клиент=ЮЛ), но вот реальных доводов (управленческих доводов) почему так не стОит делать немного

[regent]

"...Весь прикол состоит в том, что их понятие Клиента совершенно противоречит общепринятому (Клиент=ЮЛ), но вот реальных доводов (управленческих доводов) почему так не стОит делать немного..."
Собственно, подобное понятие - это и есть их собственная управленческая (!) классификация. Им так удобнее контролировать бизнесс. Мало ли таких "глюков" у руководителей. Поэтому должно быть разделение:
1) реализация в системе (заказчик здесь только ставится в известность как это будет, решение - за системным интегратором)
2) получение информации о нужных для управленцев разрезах.
Во втором случае (по очередности он более важный) - нужно определить четко цели (!): что нужно знать и для чего, чтобы понять как это реализовать. Фиксируйте все цели, чтобы в конце реализации решения показать что они достигнуты. Это оч. важно.

[Fordewind]

Цитата:

Сообщение от kirillss

2Fordewind
"1. Если их все устраивало, то зачем менять систему? " Ну, во-первых, заказчикам такое не говорят)))))))). Во-вторых, им платформу надо менять - старая уж больно устарела и не соответсвует выросшему бизнесу.

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

Кстати, regent дело говорит про цели. +1

[kirillss]

Господа, еще подскажите, если плясать от измерений, то необходимо обеспечить непротиворечивость их значений в документе. То есть не всякое сочетание значений измерений допустимо. Задание возможных сочетаний - это базовый функционал Navision или докрутки нужны?

[RedFox]

Цитата:

Сообщение от kirillss

Господа, еще подскажите, если плясать от измерений, то необходимо обеспечить непротиворечивость их значений в документе. То есть не всякое сочетание значений измерений допустимо. Задание возможных сочетаний - это базовый функционал Navision или докрутки нужны?

Для групировки можно использовать 1 измерение и кучу значений. И естественно нужно описать это в доках (типа концепция).
И это стандарный функционал.