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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.05.2009, 14:13   #1  
skof is offline
skof
NavAx
NavAx Club
 
100 / 12 (1) ++
Регистрация: 09.01.2002
Адрес: РБ, Минск
Клиенты - точки продаж и точки доставки, как организовать?
Ситуация:
1. Клиенты компании – магазины и частные предприниматели.
2. У каждого клиента есть одна или несколько точек продаж. А также одна или несколько точек доставки товара. Иногда точки продажи совпадают с точками доставки товара, иногда нет.
3. Продажи товаров осуществляются торговыми агентами в полях. В некоторых случаях в маршрут агента входит посещение каждой конкретной торговой точки клиента, а иногда он делает заказ из головного офиса клиента не указывая для какой конкретно торговой точки сделан заказ.
4. В некоторых случаях товар для нескольких точек продаж доставляется в одну точку, иногда в сами точки продаж. Иногда в рамках клиента товар доставляется в несколько точек доставки и каждая точка доставки привязана к нескольким конкретным точкам продаж.
5. У клиента может измениться юрлицо, но точки продаж и останутся.
6. В будущем будет эксплуатироваться программа планирования доставки заказов, которая потребует уникальный идентификатор для точек доставки.
Проблема:
Ведущий консультант предлагает сделать и юрлицо и точки продаж клиентами в Аксапте. В точках продаж указать основного клиента в поле «Платеж на». При сопоставлении поступившего на основного клиента платежа продажи сделанные на клиентов-точек продаж видны и их можно сопоставлять. Точки доставки он предлагает сделать альтернативными адресами в клиентах. Я же считаю что и точки продаж и точки доставки «достойны» отдельных таблиц или таблицы. В данном случае необходимо добавлять некоторый функционал.
__________________
Начать что-либо, никогда не поздно - просто начни сейчас.
Старый 10.05.2009, 14:51   #2  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Вполне возможно, у консультанта есть причины.

Я как-то сталкивался с сетью при обследовании заказчика. Там и регионы были, и население (продажи на душу, что ли, считались), и учет реализации по точкам (у юрлица могло быть несколько точек), и торговое оборудование, и мерчендайзинг (ассортиментная матрица, частота посещений, анализ полноты ассортимента), и еще куча всего. Счел оптимальным деловые отношения из CRM под это приспособить с потенциальными доработками. И адреса в клиентах.

Но и за клиентов могут быть аргументы за.

Опять же. Структура данных должна быть заточена под получение отчетности и анализ данных. Не все консультанты, которые пишут спецификаци разработчикам, об этом помнят. Но это самое важное на самом деле. С этого нужно начинать думать.
__________________
С уважением,
glibs®
Старый 10.05.2009, 15:07   #3  
skof is offline
skof
NavAx
NavAx Club
 
100 / 12 (1) ++
Регистрация: 09.01.2002
Адрес: РБ, Минск
Цитата:
Сообщение от glibs Посмотреть сообщение
Вполне возможно, у консультанта есть причины.

Я как-то сталкивался с сетью при обследовании заказчика. Там и регионы были, и население (продажи на душу, что ли, считались), и учет реализации по точкам (у юрлица могло быть несколько точек), и торговое оборудование, и мерчендайзинг (ассортиментная матрица, частота посещений, анализ полноты ассортимента), и еще куча всего. Счел оптимальным деловые отношения из CRM под это приспособить с потенциальными доработками. И адреса в клиентах.

Но и за клиентов могут быть аргументы за.
Весь комплект есть и у нас. Только на душу населения продаж не считаем.
__________________
Начать что-либо, никогда не поздно - просто начни сейчас.
Старый 11.05.2009, 14:40   #4  
Zodiak is offline
Zodiak
Участник
 
61 / 22 (1) +++
Регистрация: 16.01.2004
Адрес: СПб
согласен с glibs в том, что структура данных должна быть изначально заточена под отчетность, и из этого надо исходить в реализации задачи. т.е., у меня после прочтения возникли следующие вопросы:
1. Если один (фактически) клиент будет разбит на несколько клиентов - точек продаж, то как они будут связаны при построении отчетности? "Платеж на" будет очень сложно использовать при получении сводной цифры продаж по клиенту;
2. Какие требования будут предъявлены к системе планирования доставки? Насколько я понял, она потребует уникального номера точки доставки, т.е. альтернативного адреса клиента. Действительно ли будет необходимо как - то выделять точки продаж клиента в аксапте?
Старый 11.05.2009, 14:46   #5  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,766 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Точки доставки он предлагает сделать альтернативными адресами в клиентах
На адрес сможешь добавить сроки доставки и будет работать сводное.
Старый 11.05.2009, 19:06   #6  
Ariman is offline
Ariman
Участник
 
7 / 10 (1) +
Регистрация: 11.05.2009
и так:
Вариант 1 (Торговая точка - клиент, за которого платит другой клиент)
Торговые точки (точки продаж) в основном самостоятельно делают заказ товара, следовательно разумно их рассматривать как клиентов, за которых платит другой клиент-плательщик. В этом случае в таблице проводок по клиенту будет заполнено поле плательщик и клиент (торговая точка в нашем случае). При этом не потребуется ничего дорабатывать - стандартный отчеты по клиентам можно использовать и даже доработка новых отчетов будет проходить с минимальными потерями.
Сопоставление при этом проходит в рамках клиента-плательщика.

Вариант 2 (Торговая точка - отдельная таблица, результат доработки системы)
В таблице проводок клиентов никакого упоминания о торговой точке, только упоминание о клиенте-плательщике. Что бы сделать какой-либо отчет по ТТ надо в шапку заказа на продажу или в таблицу проводок клиента допиливать поле с указанием точки. Не будем забывать, что при необходимости облегчения БД в аксапте можно удалить заказ, но не проводку. Поэтому в форме заказа логично дорабатывать только то, что совпадает с циклом жизни заказа, а все, что живет дольше логично допиливать в вечно живущие проводки. Не понимаю, зачем туда допиливать то, что там уже и так есть. Еще надо допиливать и форму сопоставления, там как-то надо будет указывать на какую ТТ выписана накладная, что в Варианте 1 уже сделано и не подлежит доработке.

PS:
Тот самый "Ведущий консультант"
Старый 12.05.2009, 11:56   #7  
Zodiak is offline
Zodiak
Участник
 
61 / 22 (1) +++
Регистрация: 16.01.2004
Адрес: СПб
Цитата:
Сообщение от Ariman Посмотреть сообщение
и так:
Вариант 1 (Торговая точка - клиент, за которого платит другой клиент)
Торговые точки (точки продаж) в основном самостоятельно делают заказ товара, следовательно разумно их рассматривать как клиентов, за которых платит другой клиент-плательщик. В этом случае в таблице проводок по клиенту будет заполнено поле плательщик и клиент (торговая точка в нашем случае). При этом не потребуется ничего дорабатывать - стандартный отчеты по клиентам можно использовать и даже доработка новых отчетов будет проходить с минимальными потерями.
Сопоставление при этом проходит в рамках клиента-плательщика.
возможно, я, конечно, торможу... но все-таки не могу понять одну вещь. Зачем поставщику в его учетной системе аналитика (а фактически это так) продаж (ну, почти) по торговым точкам его клиентов? Были бы это точки отдельными юридическими лицами, на которые надо выписывать соответствующие первичные документы - я бы понял. Но такой вводной нет. Зачем вообще эта часть постановки задачи? Почему бы не обойтись только альтернативными адресами, соответствующим образом их допилив при необходимости?
Старый 12.05.2009, 12:44   #8  
Ariman is offline
Ariman
Участник
 
7 / 10 (1) +
Регистрация: 11.05.2009
В принципе частично согласен, но в мировой бизнес потихоньку срастается и интегрируется друг в друга, поэтому появилась технология БИТУБИ

В общем производитель давит на дистрибьютера, а тот в свою очередь на клиентов, что бы те выдали инфу по своим торговым точкам.

Производитель хочет знать своих конечных клиентов в лицо, что бы продавать больше, времена, когда производителю было достаточно знать оптовика, а дальше трава не расти ушли.

Что делать - конкуренция однако, слабые и не любопытные должны покинуть рынок
Старый 12.05.2009, 12:47   #9  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,766 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Я же считаю что и точки продаж, и точки доставки «достойны» отдельных таблиц или таблицы. В данном случае необходимо добавлять некоторый функционал.
Не надо
Старый 12.05.2009, 12:50   #10  
Ariman is offline
Ariman
Участник
 
7 / 10 (1) +
Регистрация: 11.05.2009
Нам необходимо знать, что у нас торговые точки типа "гипермаркет" купили столько-то, а торговые точки типа "киоск" столько-то,

да и ассортимент товара у одинаковых точек одинаков,
поэтому если все точки типа "киоск" продают пиво, а какая-то нет,
то дистрибутер может подсказать клиенту - продавай,
ну или разобраться почему такая аномалия
Старый 12.05.2009, 15:02   #11  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Немного конструктива .

Все что написано ниже основывается на том случае, который я упоминал (по описанной в вопросе ситуации информация скудная или умалчивается).

Если отгрузка идет реально одной накладной одному юрлицу, то клиенты в качестве точек не совсем уместны. Т.к. одно юрлицо теоретически может само развозить по нескольким точкам.

Отгрузка юрлицу это не реализация в точках. Есть разница во времени. Речь может идти именно о реализаци точек.

Речь шла об очень большом количестве клиентов и еще гораздо большем количестве точек. Здесь есть вопрос в производительности системы. Даже не уровне справочников. Еще более важно: CustTrans — тяжелый вариант тупо для статистики, т.к. реально кладет данные в херову тучу таблиц (проводки по клиенту, номенклатуре, ГК, сальдовые таблицы, сопоставления при закрытиии склада, и т.д., и т.п.). Вопрос роста БД.

Статистика по точкам может быть недостоверной (кто-то предоставляет, что-то нет; кто-то в Эксельке с ошибками, кто-то вообще по факсу (точка м.б. киоском, Аксапты там нет)). Она может быть несвоевременной, что будет корежить фин. отчетность и отчетность по дебиторке.

Так что за "отдельные таблицы" (в случае с точками речь вполне может идти о ДО из CRM) аргументы есть и серьезные. Нужно смотреть по ситуации.
__________________
С уважением,
glibs®
Старый 12.05.2009, 16:37   #12  
Ariman is offline
Ariman
Участник
 
7 / 10 (1) +
Регистрация: 11.05.2009
сетевых клиентов, которые сами распределяют товар между своими точками - мало,
ибо зачем отказываться от услуги доставки и самим тратить деньги на транспортировку,
поэтому для большинства клиентов утверждение, что на на каждую точку формируется отдельный заказ и потом отдельная накладная - справедливо
Старый 12.05.2009, 17:13   #13  
otkudao
Гость
 
n/a
А мне понравилось вот это:

Цитата:
Сообщение от glibs Посмотреть сообщение
Вполне возможно, у консультанта есть причины.

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

раскройте тему, пожалуйста, на примере. Что имеется в виду и чем не устраивает распределенное хранение достаточных для построения отчетности и анализа данных вне какой-то специализированной структуры, созданной исключительно для этой цели?
Старый 12.05.2009, 23:10   #14  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,766 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Вопреки общепринятому мнению, системы придуманы не для разработчиков
Отчётность, индикаторы, анализ данных служат для трансляции данных из системы в мозг манагеров, управляющих предприятием. Задача манагеров - предприятием управлять на основании этих данных.

Цитата:
раскройте тему, пожалуйста, на примере.
Человек берёт с плиты кастрюлю воды. Он ощущает, видит катрюлю, её размер, вес (с весом другая диковина связана, но это уже психология ). О температуре организм никакого сигнала не даёт. Человек прикасается к кастрюле и обжигается.

Аналогично с предприятием - система не даёт информации - предприятие не управляется.
Например, в аксапте есть возможность получить и где хранить время выполнения маршрута, операции, задания. Однако производство представляет из себя котёл, куда сливается всё варево. И в итоге, Манагеры не могут продигустировать диковиный вкус компота.
Старый 12.05.2009, 23:47   #15  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,307 / 3540 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от otkudao Посмотреть сообщение
но ни разу еще не затачивал структуру данных под формирование отчетности и анализ данных.
раскройте тему, пожалуйста, на примере.
Можно еще сказать по-другому. От системы в конечном счете нужна информация за приемлемое время. Бизнесу нужно от системы (аксапта, 1С, сап, и т.д.) получение некоторых отчетов за определенное время с нужной детализацией и достоверностью.
При этом имеются "вот такие-то" входящие данные.
Соответственно - исходя из этих потребностей и возможностей определяется структура хранения информации в БД.
Это в идеале при написании системы с нуля.
В уже имеющейся системе можно пойти двумя путями:
1. "Натянуть бизнес на систему". Т.е. привести входящие данные бизнеса к уже заложенным предполагаемым входящим данным и довольствоваться отчетами, предлагаемыми системой. Ну или ограничиться минимальным "допиливанием" (это к вопросу - "минимально" - это сколько?).
2. "Натянуть систему на бизнес". Т.е. сделать самописку "на базе системы" но в угоду бизнеса. Тут надо придерживаться вышесказанного - "получение отчетов за определенное время с нужной детализацией и достоверностью".

Вы хотите, чтобы Вам сшили пиджак. Вам ведь без разницы - удобно ли швее вытачивать карман или нет?
__________________
Возможно сделать все. Вопрос времени
Теги
как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Квартальный план продаж CRM silvestra DAX: Функционал 0 17.07.2006 09:57
Проводка предоплаты в книге продаж и книге покупок aevi82 DAX: Функционал 4 23.06.2005 16:35
CRM - ошибка. Форма Конструктор группы продаж. (3.0 SP3) dirigente DAX: Функционал 1 08.12.2004 23:51
Прогноз продаж AlexUnik DAX: Функционал 16 23.09.2004 18:08
Книга продаж eremite DAX: Функционал 6 07.04.2004 07:23
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:57.