Опрос — отчет о продажах

Наш отчет о заказах выводит не верные данные и нам нужно изменить его алгоритм. Нужна ваша помощь чтобы сделать отчет точным и полезным.

Диаграмма «Доход» — это заказы со статусом «Готов» или «Оплачен», у которых дата изменения за определенный месяц.

Дата изменения — это изменение статуса заказа или заказ был отредактирован.

ТОП группы и товары считаются из этих же заказов.

Колонка доход в товарах и группах — это сумма цен товаров в заказах. Не цена товара а цена в заказе. Эти цены могут быть разные. Если валюты разные, мы их конвертируем в одну.

Что можно изменить:

  1. учитывать другие статусы заказа или не учитывать вообще
  2. брать заказы по другим датам, скажем дата создания заказа

 

Реклама

Опрос — отчет о продажах: 15 комментариев

  1. Необходимо, чтобы закрытые заказы считались по дате создания заказа, иначе портится статистика.

    было бы хорошо также кроме среднего чека знать:
    1. количество повторных продаж. Сколько продаж сделали и на какую сумму, клиенты, которые покупают не в первый раз в нашем магазине.
    2. Если вбита себестоимость, было бы неплохо подсчитывать доход автоматически.
    3. Можно с аналитики добавить данные, например топ 10 ресурсов, откуда пришли продажи с количеством и суммами продаж.

  2. 1. Было бы здорово иметь возможность управлять этой функцией у редактируемого статуса.
    Пример: создаём новый статус, где помимо цвета, названия, можно выбрать
    «Считать заказ закрытым»
    (Цена заказа с этим статусом будет суммироваться с остальным доходом и отобразиться в отчёте)

    2. «Необходимо, чтобы закрытые заказы считались по дате создания заказа, иначе портится статистика.» — Вроде да, но ведь когда пришло бабло (закрыли заказ), тогда и «доход», у кого-то может несколько недель заказ клиенту идёт, а оплата при получении или предзаказы всякие без предоплаты. Так что, как есть логичнее.

    А вот фильтр по датам, за произвольно выбранный период времени, очень нужен! )

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

  4. Есть такой вариант:
    Добавить кнопку «Закрыть заказ» — который говорит системе что заказ доставлен и оплачен. После этого заказ переходит в режим «только чтение» и такой заказ попадает в отчет. Такой вариант точно поставит точку с готовыми заказами.

    Статусом управлять сложнее, у каждого магазина они разные.

    1. Будет кнопка «Закрыть заказ» полностью аналогичная статусу «Готов» и не зависимо от статуса, при её нажатии данные заказа попадают в отчёт.
      Если я правильно понял, то ЗА! )

    2. Есть такой вариант:
      Добавить кнопку «Закрыть заказ» — который говорит системе что заказ доставлен и оплачен. После этого заказ переходит в режим «только чтение» и такой заказ попадает в отчет. Такой вариант точно поставит точку с готовыми заказами.
      Наконец-то, писал об этом еще год назад. Закрытый заказ однозначно должен попадать в режим чтения, ведь редактируя еже закрытые заказы можно воровать и никто не заметит, т.к. как по продажам и остаткам будет все сходиться.

  5. Так смысл? Есть статус Готов, у нас например эти заказы уже не редактируются. Готов — это значит оплачен и доставлен.
    Важна дата, которой этот заказ попадает в отчет. Нам необходимо, чтобы попадал датой создания заказа.

  6. 1. Осязательно сделайте произвольный выбор дат в разедел Отчеты NEW
    2. Я считаю, что конечно лучше чтобы заказы засчитывались в том месяце в котором заказ был создан, а не оплачен, это важно у кого сезонный спрос, тогда логично анализировать активность создания заказов, а. закрытие заказов может быть и через месяц, и тогда вся аналитика плывет
    3. Считаю, что нужно сделать вывод не только ТОП 10 товаров, а всех с сортировкой по популярности, или сделать так, чтобы пользователь мог выбрать варианты: ТОП 10, ТОП20, ТОП30 или вывод всех.
    4. В списке заказов нужно сделать суммирование доходов по статусам. Например выбрали статус «Оплачен», а там 20 заказов разной стоимостью, нужно чтобы в конце была общая стоимость всех оплоченных тваров. Это важно знать для анализа прогнозирования, сколько денег зашло, сколько еще зайдет, на какую сумму отгружено товаров и т.д….

  7. Здравствуйте. Так как возможности создать новую тему нет, пишу в этой ветке. Уже несколько лет вас просят добавить нормальный выбор наличия товара, сделать 3 статуса «В наличии», «Под заказ», и «Нет в наличии». У вас добавляется что угодно, кроме того, что действительно нужно и важно. Сегодня обратился за помощью к так называемому «Эксперту», с вопросом, как реализовать эти 3 статуса, предполагал и сам, как это сделать, с привязкой к кол-ву товара, но наивно полагал, что понятие «техническая поддержка» и гордое звание «Эксперт» не зря присутствуют на вашем сайте. В результате меня отправили к фрилансеру за деньги делать то, что изначально должно было быть с первого дня существования платформы. Напрашивается вывод, что политика компании такова, что часть функций осознанно не добавляется, с целью заработка своих же программистов-фрилансеров.

    1. Взял на заметку. Часто это реализуется как метки к товару, там можно написать что угодно и как угодно можно оформить — это очень гибкий механизм.

      1. Спасибо. Как угодно, лишь бы сделали. А то посмотрите, в новостях блога «Обновление Gollos 3.23. В этом обновлении мы исправили важные ошибки. Обновление Gollos 3.24. В этом обновлении мы исправили важные ошибки»… Но мы то платим вам не за исправление ваших ошибок, а вы подаете это как новость. Лучше не отчет о продажах улучшайте, а удобство пользования платформой, отчет — это косвенный показатель, который зависит от возможностей платформы, пусть он хоть в сто раз точнее станет, продажи не он приносит, а нормальный механизм управления интернет-магазином.

  8. >> Спасибо. Как угодно, лишь бы сделали.

    Сергей, спасибо за ваш комментарий.
    Следите за блогом и участвуйте в обсуждениях. Скоро все сделаем.

  9. «Есть такой вариант:
    Добавить кнопку «Закрыть заказ» — который говорит системе что заказ доставлен и оплачен. После этого заказ переходит в режим «только чтение» и такой заказ попадает в отчет. Такой вариант точно поставит точку с готовыми заказами.»

    Наконец-то, писал об этом еще год назад. Закрытый заказ однозначно должен попадать в режим чтения, ведь редактируя еже закрытые заказы можно воровать и никто не заметит, т.к. как по приход-продажи-остаток будет все сходиться.
    И еще:
    в поддержку писать устал потому, что это равносильно звонку в рельсу, хотя у меня вроде как и «премиум сервис», пишу здесь:
    1. для того чтобы дать доступ логистики и складу к статусам заказов приходится давать полный доступ к заказам (отдельный доступ к редактированию заказа предусмотрен, но он не работает), а это не допустимо т.к. редактируя еже закрытые заказы воровать можно безгранично.
    2. сделайте нормальный инструмент добавления товара, сейчас если добавляем товар на сайт то одно значение меняем на другое, но если в этот момент когда мы изменяем значения количества товара приходит заказ с этим товаром, то мы не видя актуальное количество товара в эту секунду, так как данные меняются только после обновления страницы, выставляем уже неправильное количество.
    3. В отчетах по продаже товара дайте возможность выбирать не только день, но и время либо заказ с которого по который вытянуть «Отчет». Поясню: переучет товара производим днем поэтому есть заказы которые до учета и после, т.к. «Отчет» только за день, при пересчете приход-продажи-остаток, в дни учета, продажи товара приходится пересчитывать вручную чтобы отсортировать продажи до учета товара и после учета.

  10. А разработчиков не смущает, что цифры в Отчете «NEW» в Топ Товарах в колонке «Доход» это не сумма цен товаров в заказах, эти цифры вообще никакого отношения к этим товарам не имеют,
    P.S. C 8 октября пытаюсь получить внятный ответ у «Экспертов», что это за цифры.
    Самые популярные ответы разных «Экспертов» по этому вопросу:
    «Передал проблему нашим программистам. Похоже что действительно есть баг и его нужно исправить.»
    «Мы проверим с чем связана такая проблема, исправления будут в обновлении платформы.»

    Но последний ответ убил последнюю надежду на решение этого вопроса:
    «Без помощи программистов определить скорее всего не получится, но если я попрошу их разобраться в том как это воспроизводится, рассмотрение вопроса очень затянется. В первую очередь они решают наиболее приоритетные проблемы.»

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s