AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.11.2007, 19:55   #1  
kirillss is offline
kirillss
Участник
 
28 / 10 (1) +
Регистрация: 12.09.2007
Заказчик хочет чтобы понятие "клиент" соответствовало не просто ЮЛ клиента, а набору: ЮЛ клиент, ЮЛ заказчика (он - холдинг), сезон и т.п.
Ну и соответсвенно в документы по продаже попадает именно такой "клиент".
Разработка заказная - посему конечно и такой изврат налобаем. Но больно меня это напрягает
Вопросы -
1 Как аргументированно отговорить заказчика от такого подхода к понятию клиент?
2 Как продукты MBS трактуют клиента? Там Клиент = ЮЛКлиента?
Старый 08.11.2007, 08:10   #2  
Harry is offline
Harry
Участник
 
94 / 10 (1) +
Регистрация: 01.10.2007
А можно сделать через список контактов?
Контактное лицо может быть физ. или юр. лицом!
Старый 08.11.2007, 10:17   #3  
UGT is offline
UGT
Участник
 
45 / 10 (1) +
Регистрация: 08.06.2005
У вашего заказчика в базе каждому юр. лицу соответсвует своя фирма, или весь учет ведется в некой консолидирующей фирме?
Вообще, какой смысл всего этого?
В Навижн Клиент=юр. лицо, у него есть адрес, ИНН и т.д. Можно конечно определенный холдинг завести как одного клиента, чтобы видеть его общий баланс, но тогда придется поколдовать над печатью документов, чтобы в них проставлялись правильные реквизиты клиента.
Старый 08.11.2007, 10:18   #4  
kirillss is offline
kirillss
Участник
 
28 / 10 (1) +
Регистрация: 12.09.2007
2Harry : Проблема не в том что физ или юр лицо, а в том что Заказчик считает что ЮрЛицу соответствует несколько клиентов (вернее несколько кодов в системе)
Старый 08.11.2007, 12:21   #5  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от kirillss Посмотреть сообщение
Заказчик хочет чтобы понятие "клиент" соответствовало не просто ЮЛ клиента, а набору: ЮЛ клиент, ЮЛ заказчика (он - холдинг), сезон и т.п.
Ну и соответсвенно в документы по продаже попадает именно такой "клиент".
Разработка заказная - посему конечно и такой изврат налобаем. Но больно меня это напрягает
Вопросы -
1 Как аргументированно отговорить заказчика от такого подхода к понятию клиент?
2 Как продукты MBS трактуют клиента? Там Клиент = ЮЛКлиента?
Делали такое - заводили ВСЕХ клиентов "холдинга" (потому что), а потом связывали по полю "Our Account No." единым значением или признаком.
Старый 08.11.2007, 13:15   #6  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
Да многие это делали ;-)
Собсно проблем две:
1. Печать документов - от кого, кому, зачем ;-) (особенно счета-фактуры)
2. Оценка задолженности (баланс по Клиенту и юрлицам, консолидированно и в разрезе ЮЛ, взаимозачет)

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

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

А как ЮЛ делят по сезонам?!
Старый 08.11.2007, 13:22   #7  
kirillss is offline
kirillss
Участник
 
28 / 10 (1) +
Регистрация: 12.09.2007
"А как ЮЛ делят по сезонам?!"

Тупо делят - разные клиенты на разные сезоны))))))
Старый 08.11.2007, 13:30   #8  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
Цитата:
Сообщение от kirillss Посмотреть сообщение
"А как ЮЛ делят по сезонам?!"

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

Ай, молодцы! А что за бизнес у клиента?
Старый 08.11.2007, 13:30   #9  
kirillss is offline
kirillss
Участник
 
28 / 10 (1) +
Регистрация: 12.09.2007
2UGT "Вообще, какой смысл всего этого? "

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

Но очень хочется его от этого отговорить
Старый 08.11.2007, 13:34   #10  
kirillss is offline
kirillss
Участник
 
28 / 10 (1) +
Регистрация: 12.09.2007
шмотки в основном
Старый 08.11.2007, 13:44   #11  
regent is offline
regent
Участник
 
12 / 10 (1) +
Регистрация: 21.09.2007
Полагаю самый логичный способ (с позиции системы): 1 клиент = 1 ЮЛ. При этом каждому клиенту присвоить стандартное измерение, которое будет его относить к конкретной группе компаний. Далее, если необходимо создаем аналитические отчеты по группе компаний.
Что касаестя "...Типа манагеры всех своих клиентов и так наизусть помнят..." - система, и автоматизация в общем, ИМХО в первую очередь предпологает исключение человеского фактора. Если манагеры хотят работать на память и по бумажке - может им система не нужна.... Это гиперболизировано конечно, но смысл именно в том, что при смене специалистов компания не должна зависнуть от отсутствия информации, которая ушла вместе со специлистом.
Старый 08.11.2007, 14:07   #12  
Fordewind is offline
Fordewind
Участник
 
1,134 / 10 (3) +
Регистрация: 01.12.2005
Цитата:
Сообщение от kirillss Посмотреть сообщение
2UGT "Вообще, какой смысл всего этого? "

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

Но очень хочется его от этого отговорить
к вопросу "Как отговорить"

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

P.S. Разбивка клиентов по сезонам думаю это ноухау!
Старый 08.11.2007, 14:12   #13  
Fordewind is offline
Fordewind
Участник
 
1,134 / 10 (3) +
Регистрация: 01.12.2005
тут был дубль
Старый 08.11.2007, 14:22   #14  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от regent Посмотреть сообщение
Полагаю самый логичный способ (с позиции системы): 1 клиент = 1 ЮЛ. При этом каждому клиенту присвоить стандартное измерение, которое будет его относить к конкретной группе компаний. Далее, если необходимо создаем аналитические отчеты по группе компаний.
Вот это очень хороший совет, если используете анализ по измерениям. Только нужно сделать обязательным для заполнения данноое измерение и зачести чел-ка\роль\пункт в штатном расписаним (не знаю что вам больше подходит и нужно - Вам виднее), который будет заводить сразу новые измерения в системе.

ИМХО А память человека такая ошибочная и хрупкая... не надо на нее надеяться.
Старый 08.11.2007, 14:30   #15  
kirillss is offline
kirillss
Участник
 
28 / 10 (1) +
Регистрация: 12.09.2007
2Fordewind
"1. Если их все устраивало, то зачем менять систему? " Ну, во-первых, заказчикам такое не говорят)))))))). Во-вторых, им платформу надо менять - старая уж больно устарела и не соответсвует выросшему бизнесу.

Весь прикол состоит в том, что их понятие Клиента совершенно противоречит общепринятому (Клиент=ЮЛ), но вот реальных доводов (управленческих доводов) почему так не стОит делать немного
Старый 08.11.2007, 14:45   #16  
regent is offline
regent
Участник
 
12 / 10 (1) +
Регистрация: 21.09.2007
"...Весь прикол состоит в том, что их понятие Клиента совершенно противоречит общепринятому (Клиент=ЮЛ), но вот реальных доводов (управленческих доводов) почему так не стОит делать немного..."
Собственно, подобное понятие - это и есть их собственная управленческая (!) классификация. Им так удобнее контролировать бизнесс. Мало ли таких "глюков" у руководителей. Поэтому должно быть разделение:
1) реализация в системе (заказчик здесь только ставится в известность как это будет, решение - за системным интегратором)
2) получение информации о нужных для управленцев разрезах.
Во втором случае (по очередности он более важный) - нужно определить четко цели (!): что нужно знать и для чего, чтобы понять как это реализовать. Фиксируйте все цели, чтобы в конце реализации решения показать что они достигнуты. Это оч. важно.
Старый 08.11.2007, 15:09   #17  
Fordewind is offline
Fordewind
Участник
 
1,134 / 10 (3) +
Регистрация: 01.12.2005
Цитата:
Сообщение от kirillss Посмотреть сообщение
2Fordewind
"1. Если их все устраивало, то зачем менять систему? " Ну, во-первых, заказчикам такое не говорят)))))))). Во-вторых, им платформу надо менять - старая уж больно устарела и не соответсвует выросшему бизнесу.
Я сказал суть. Вложение ее в витееватую фразу на пару абзацев я оставил. Ведь это Вам нужно подвести клиента к правильным мыслям
А к устаревшей платформе подходит тема для разговора о том, что когда бизнес растет некоторые устоявшиеся процессы стоит менять, так как бизнес в какой-то момент качественно меняется.

Кстати, regent дело говорит про цели. +1
Старый 08.11.2007, 15:15   #18  
kirillss is offline
kirillss
Участник
 
28 / 10 (1) +
Регистрация: 12.09.2007
Господа, еще подскажите, если плясать от измерений, то необходимо обеспечить непротиворечивость их значений в документе. То есть не всякое сочетание значений измерений допустимо. Задание возможных сочетаний - это базовый функционал Navision или докрутки нужны?
Старый 08.11.2007, 15:39   #19  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от kirillss Посмотреть сообщение
Господа, еще подскажите, если плясать от измерений, то необходимо обеспечить непротиворечивость их значений в документе. То есть не всякое сочетание значений измерений допустимо. Задание возможных сочетаний - это базовый функционал Navision или докрутки нужны?
Для групировки можно использовать 1 измерение и кучу значений. И естественно нужно описать это в доках (типа концепция).
И это стандарный функционал.
 


Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 23:56.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.