Клиенты - точки продаж и точки доставки, как организовать?

[skof]

Ситуация:
1. Клиенты компании – магазины и частные предприниматели.
2. У каждого клиента есть одна или несколько точек продаж. А также одна или несколько точек доставки товара. Иногда точки продажи совпадают с точками доставки товара, иногда нет.
3. Продажи товаров осуществляются торговыми агентами в полях. В некоторых случаях в маршрут агента входит посещение каждой конкретной торговой точки клиента, а иногда он делает заказ из головного офиса клиента не указывая для какой конкретно торговой точки сделан заказ.
4. В некоторых случаях товар для нескольких точек продаж доставляется в одну точку, иногда в сами точки продаж. Иногда в рамках клиента товар доставляется в несколько точек доставки и каждая точка доставки привязана к нескольким конкретным точкам продаж.
5. У клиента может измениться юрлицо, но точки продаж и останутся.
6. В будущем будет эксплуатироваться программа планирования доставки заказов, которая потребует уникальный идентификатор для точек доставки.
Проблема:
Ведущий консультант предлагает сделать и юрлицо и точки продаж клиентами в Аксапте. В точках продаж указать основного клиента в поле «Платеж на». При сопоставлении поступившего на основного клиента платежа продажи сделанные на клиентов-точек продаж видны и их можно сопоставлять. Точки доставки он предлагает сделать альтернативными адресами в клиентах. Я же считаю что и точки продаж и точки доставки «достойны» отдельных таблиц или таблицы. В данном случае необходимо добавлять некоторый функционал.

[glibs]

Вполне возможно, у консультанта есть причины.

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

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

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

[skof]

Цитата:

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

Вполне возможно, у консультанта есть причины.

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

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

Весь комплект есть и у нас. Только на душу населения продаж не считаем.

[Zodiak]

согласен с glibs в том, что структура данных должна быть изначально заточена под отчетность, и из этого надо исходить в реализации задачи. т.е., у меня после прочтения возникли следующие вопросы:
1. Если один (фактически) клиент будет разбит на несколько клиентов - точек продаж, то как они будут связаны при построении отчетности? "Платеж на" будет очень сложно использовать при получении сводной цифры продаж по клиенту;
2. Какие требования будут предъявлены к системе планирования доставки? Насколько я понял, она потребует уникального номера точки доставки, т.е. альтернативного адреса клиента. Действительно ли будет необходимо как - то выделять точки продаж клиента в аксапте?

[Vals]

Цитата:

Точки доставки он предлагает сделать альтернативными адресами в клиентах

На адрес сможешь добавить сроки доставки и будет работать сводное.

[Ariman]

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

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

PS:
Тот самый "Ведущий консультант"

[Zodiak]

Цитата:

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

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

возможно, я, конечно, торможу... но все-таки не могу понять одну вещь. Зачем поставщику в его учетной системе аналитика (а фактически это так) продаж (ну, почти) по торговым точкам его клиентов? Были бы это точки отдельными юридическими лицами, на которые надо выписывать соответствующие первичные документы - я бы понял. Но такой вводной нет. Зачем вообще эта часть постановки задачи? Почему бы не обойтись только альтернативными адресами, соответствующим образом их допилив при необходимости?

[Ariman]

В принципе частично согласен, но в мировой бизнес потихоньку срастается и интегрируется друг в друга, поэтому появилась технология БИТУБИ

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

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

Что делать - конкуренция однако, слабые и не любопытные должны покинуть рынок

[Vals]

Цитата:

Я же считаю что и точки продаж, и точки доставки «достойны» отдельных таблиц или таблицы. В данном случае необходимо добавлять некоторый функционал.

Не надо

[Ariman]

Нам необходимо знать, что у нас торговые точки типа "гипермаркет" купили столько-то, а торговые точки типа "киоск" столько-то,

да и ассортимент товара у одинаковых точек одинаков,
поэтому если все точки типа "киоск" продают пиво, а какая-то нет,
то дистрибутер может подсказать клиенту - продавай,
ну или разобраться почему такая аномалия

[glibs]

Немного конструктива .

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

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

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

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

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

Так что за "отдельные таблицы" (в случае с точками речь вполне может идти о ДО из CRM) аргументы есть и серьезные. Нужно смотреть по ситуации.

[Ariman]

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

А мне понравилось вот это:

Цитата:

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

Вполне возможно, у консультанта есть причины.

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

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

раскройте тему, пожалуйста, на примере. Что имеется в виду и чем не устраивает распределенное хранение достаточных для построения отчетности и анализа данных вне какой-то специализированной структуры, созданной исключительно для этой цели?

[Vals]

Вопреки общепринятому мнению, системы придуманы не для разработчиков
Отчётность, индикаторы, анализ данных служат для трансляции данных из системы в мозг манагеров, управляющих предприятием. Задача манагеров - предприятием управлять на основании этих данных.

Цитата:

раскройте тему, пожалуйста, на примере.

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

Аналогично с предприятием - система не даёт информации - предприятие не управляется.
Например, в аксапте есть возможность получить и где хранить время выполнения маршрута, операции, задания. Однако производство представляет из себя котёл, куда сливается всё варево. И в итоге, Манагеры не могут продигустировать диковиный вкус компота.

[sukhanchik]

Цитата:

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

но ни разу еще не затачивал структуру данных под формирование отчетности и анализ данных.
раскройте тему, пожалуйста, на примере.

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

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