По моей оценке (мои личные наблюдения согласуются с данными, которые я видел в интернете), 80-90% продавцов на маркетплейсах не занимается экономическим планированием систематически.
Те, кто занимается — считают плюс-минус такие же показатели по плюс-минус такой же методике. И ценность представляет не только то, что было в прошлом квартале и уже попало в бухгалтерскую отчетность, а то, что происходит прямо сейчас.
Динамика продаж какого-то товара может выглядеть так
Реальная динамика продаж некоторого товара
Через месяц вы увидите это в бухгалтерском учете в аггрегированом виде. Но реагировать будет уже поздно.
Не совсем так. Мы делаем оценки на основе данных, которые еще не отражены в бухгалтерском учете, но которые уже доступны для анализа.
Приведу пример. У нас есть данные о том что покупатель сделал заказ на маркетплейсе. Мы знаем конверсию заказа в продажу (от заказа можно отказаться, пока он в пути, или отказаться на ПВЗ после осмотра или примерки, или просто не прийти за ним, и тогда через какое-то время он уедет обратно на склад). Данные об этом заказе в бухгалтерской отчетности появятся только после того, как товар доедет до ПВЗ, покупатель придет и получит свой заказ, маркетплейс включит информацию о нем в отчет комиссионера, отчет комиссионера будет загружен в бухгалтерскую систему. Это может занять неделю, а может месяц. Но данные о заказе у нас уже есть, и мы уже можем использовать их для оценок и прогнозов.
Двойная бухгалтерия — это другое. Это та самая упорядоченная система сбора, регистрации и обобщения информации о фактических операциях, сведения о которых не отражены в официальных отчетах.
У нас же речь про прогнозы и оперативную оценку ситуации. Вот прямо сегодня на основе имеющихся данных мы можем оценить, что выручка за квартал составит 100 миллионов, а прибыль — 10 миллионов. Фактически, когда квартал закончится, и когда будет сведена бухгалтерская отчетность, числа могут оказаться другими. Но закон не запрещает делать оценки и строить планы, если в итоговой отчетности все верно.
Закон не регламентирует, как считать маржинальность или оборачиваемость каждого товара, чтобы решить, что закупать и в каком количестве, а что — выводить из ассортимента, на что повышать цены, а на что — уменьшать. Эти данные выходят за рамки контроля и регламента, но они важны для принятия решений. И этим тоже занимается управленческий учет.
Да, все верно. Это именно анализ для максимизации прибыли.
Плохой управленческий учет сам по себе не делает бизнес незаконным, но косвенно может быть индикатором проблем с бухгалтерским и налоговым учетом, которые можно рассматривать с точки зрения соблюдения законов.
Эти данные должны учитываться и в бухгалтерском, и в налоговом учете, да. Но это не запрещает использовать их в управленческом учете.
Бухгалтерский и налоговый учет регламентированы и по форме, и по срокам, и контролируются государством. Управленческий — нет. Его задача — дать данные для принятия решений, он может быть приблизительным, можно учитывать не подтвержденные документами операции, можно строить предположения. Но он должен быть оперативным. И прогнозирование, что будет в бухгалтерском отчете потом — важно сейчас.
Вероятно, да, я не знаю. Я употребил слово не задумываясь именно в таком значении, и мне казалось это значение естественным для русского языка. Возможно, это неправильно.
Проверки проводились с параметрами: NR=10, IR=20'000, ND=5, ID=10. Общее количество проверок для одного участника SUM=10'000'000
Меня смущает IR=20'000. Скажем, если в библиотеке реализовано кэширование на каком-либо уровне, она получит значительное преимущество.
Под кэшированием я понимаю что угодно, что ускоряет повторные прогоны: можно запоминать N последних результатов, можно кэшировать результат преобразования регулярного выражения из строки в более подходящую структуру данных, можно регулярное выражение представить в виде конечного автомата и запомнить его, можно скомпилировать регулярное выражение и сохранить результат компиляции.
Я не считаю такие оптимизации "нечестным преимуществом", кэширование и компиляция - отличные подходы. Но методология тестирования не учитывает, что скорость сопоставления строк с регулярными выражениями может драматически меняться в зависимости от того, повторяются ли регулярные выражения в процессе выполнения теста.
Независимо от конфигурации колес и их количества к каждому колесу подводится привод, все приводы вращаются с одинаковой угловой скоростью. По сути - жесткая связь с двигателем через редуктор.
Каждое колесо приводится во вращение через обгонную муфту. Быстрее привода вращаться можно, медленнее - нельзя.
Тогда на бездорожье грести будут все, и никакое вывешивание не снизит момент на колесах с зацепом. А на хорошем покрытии в поворотах толкать механизм будут внутренние колеса, остальные будут свободно вращаться быстрее приводов.
Из плюсов - предельная простота конструкции и ноль дифференциалов.
Проверил - к Меркурию лететь не имеет смысла. Для полета к Меркурию нужно погасить 7.5 км/с, а гравитационный маневр вернёт только 3 км/с максимум. Но к Венере лететь выгодно, нужно погасить 2.5 км/с, а разогнаться можно на 7.3 км/с.
Кстати, для полета к Юпитеру нужно 8.8 км/с, на Меркурий попасть все же проще. А вот чтобы на Солнце упасть, нужно 30 км/с погасить, в таком случае выгоднее лететь к Юпитеру и гасить скорость в афелии.
В исходном комментарии речь шла про то, как полететь как можно быстрее и как можно дальше. Думаю, как минимум быстрее и дальше Вояджера. А для этого нужно хорошо разогнаться, и просто разгоняться по прямой - не самое оптимальное решение. У химических двигателей сравнительно малое значение удельного импульса для этого (большой расход рабочего тела), у ионных двигателей - высокий расход энергии, которую негде брать, а еще куда-то тепло девать нужно, в космосе это не так просто.
И в итоге получается, что маршрут важен в том смысле, что должен максимально эффективно использовать гравитационные маневры, то есть, по сути, пролететь рядом с максимальным количеством планет. Статья на Википедии: https://ru.wikipedia.org/wiki/Гравитационный_манёвр
Вполне может оказаться, что энергетически выгоднее сначала полететь к Солнцу, посетить Меркурий, Венеру, Землю и остальные планеты, чем просто разгоняться двигателями. А это - не быстро, нужно учитывать огромные расстояния и взаимное расположение планет.
Очередь есть, без нее никак. Просто вместо отдельного сервиса это таблица в базе. Соответственно, из этой таблицы берут, там же обновляют статус и так далее. Пока что это отлично работает.
Что касается того, почему это не отдельный сервис:
У обработчика в памяти должна быть предпосчитанная вспомогательная структура, в случае с большими каталогами - несколько гигабайт. Поэтому взять задачу может не любой обработчик.
Обработчиков несколько, и каждый работает со своим каталогом, данные в оперативной памяти не дублируются.
В случае отключения или зависания обработчика его задачи по его каталогам должны перераспределиться на другие обработчики. Перед этим там считаются данные для каталога.
Задач относительно немного, и с таким набором требований оказалось проще самим написать логику очереди, чем использовать готовое решение. Когда эта часть станет узким местом, будем внедрять готовый MQ.
Могу на этот счет поделиться своим опытом.
По моей оценке (мои личные наблюдения согласуются с данными, которые я видел в интернете), 80-90% продавцов на маркетплейсах не занимается экономическим планированием систематически.
Те, кто занимается — считают плюс-минус такие же показатели по плюс-минус такой же методике. И ценность представляет не только то, что было в прошлом квартале и уже попало в бухгалтерскую отчетность, а то, что происходит прямо сейчас.
Динамика продаж какого-то товара может выглядеть так
Через месяц вы увидите это в бухгалтерском учете в аггрегированом виде. Но реагировать будет уже поздно.
Не совсем так. Мы делаем оценки на основе данных, которые еще не отражены в бухгалтерском учете, но которые уже доступны для анализа.
Приведу пример. У нас есть данные о том что покупатель сделал заказ на маркетплейсе. Мы знаем конверсию заказа в продажу (от заказа можно отказаться, пока он в пути, или отказаться на ПВЗ после осмотра или примерки, или просто не прийти за ним, и тогда через какое-то время он уедет обратно на склад). Данные об этом заказе в бухгалтерской отчетности появятся только после того, как товар доедет до ПВЗ, покупатель придет и получит свой заказ, маркетплейс включит информацию о нем в отчет комиссионера, отчет комиссионера будет загружен в бухгалтерскую систему. Это может занять неделю, а может месяц. Но данные о заказе у нас уже есть, и мы уже можем использовать их для оценок и прогнозов.
Двойная бухгалтерия — это другое. Это та самая упорядоченная система сбора, регистрации и обобщения информации о фактических операциях, сведения о которых не отражены в официальных отчетах.
У нас же речь про прогнозы и оперативную оценку ситуации. Вот прямо сегодня на основе имеющихся данных мы можем оценить, что выручка за квартал составит 100 миллионов, а прибыль — 10 миллионов. Фактически, когда квартал закончится, и когда будет сведена бухгалтерская отчетность, числа могут оказаться другими. Но закон не запрещает делать оценки и строить планы, если в итоговой отчетности все верно.
Закон не регламентирует, как считать маржинальность или оборачиваемость каждого товара, чтобы решить, что закупать и в каком количестве, а что — выводить из ассортимента, на что повышать цены, а на что — уменьшать. Эти данные выходят за рамки контроля и регламента, но они важны для принятия решений. И этим тоже занимается управленческий учет.
Да, все верно. Это именно анализ для максимизации прибыли.
Плохой управленческий учет сам по себе не делает бизнес незаконным, но косвенно может быть индикатором проблем с бухгалтерским и налоговым учетом, которые можно рассматривать с точки зрения соблюдения законов.
Эти данные должны учитываться и в бухгалтерском, и в налоговом учете, да. Но это не запрещает использовать их в управленческом учете.
Бухгалтерский и налоговый учет регламентированы и по форме, и по срокам, и контролируются государством. Управленческий — нет. Его задача — дать данные для принятия решений, он может быть приблизительным, можно учитывать не подтвержденные документами операции, можно строить предположения. Но он должен быть оперативным. И прогнозирование, что будет в бухгалтерском отчете потом — важно сейчас.
Вероятно, да, я не знаю. Я употребил слово не задумываясь именно в таком значении, и мне казалось это значение естественным для русского языка. Возможно, это неправильно.
Меня смущает IR=20'000. Скажем, если в библиотеке реализовано кэширование на каком-либо уровне, она получит значительное преимущество.
Под кэшированием я понимаю что угодно, что ускоряет повторные прогоны: можно запоминать N последних результатов, можно кэшировать результат преобразования регулярного выражения из строки в более подходящую структуру данных, можно регулярное выражение представить в виде конечного автомата и запомнить его, можно скомпилировать регулярное выражение и сохранить результат компиляции.
Я не считаю такие оптимизации "нечестным преимуществом", кэширование и компиляция - отличные подходы. Но методология тестирования не учитывает, что скорость сопоставления строк с регулярными выражениями может драматически меняться в зависимости от того, повторяются ли регулярные выражения в процессе выполнения теста.
Мы комментируем статью про «бессмысленный и беспощадный» дифференциал.
Машина получится еще веселее и беспощаднее, это да.
А если так:
Независимо от конфигурации колес и их количества к каждому колесу подводится привод, все приводы вращаются с одинаковой угловой скоростью. По сути - жесткая связь с двигателем через редуктор.
Каждое колесо приводится во вращение через обгонную муфту. Быстрее привода вращаться можно, медленнее - нельзя.
Тогда на бездорожье грести будут все, и никакое вывешивание не снизит момент на колесах с зацепом. А на хорошем покрытии в поворотах толкать механизм будут внутренние колеса, остальные будут свободно вращаться быстрее приводов.
Из плюсов - предельная простота конструкции и ноль дифференциалов.
Проверил - к Меркурию лететь не имеет смысла. Для полета к Меркурию нужно погасить 7.5 км/с, а гравитационный маневр вернёт только 3 км/с максимум. Но к Венере лететь выгодно, нужно погасить 2.5 км/с, а разогнаться можно на 7.3 км/с.
Кстати, для полета к Юпитеру нужно 8.8 км/с, на Меркурий попасть все же проще. А вот чтобы на Солнце упасть, нужно 30 км/с погасить, в таком случае выгоднее лететь к Юпитеру и гасить скорость в афелии.
В исходном комментарии речь шла про то, как полететь как можно быстрее и как можно дальше. Думаю, как минимум быстрее и дальше Вояджера. А для этого нужно хорошо разогнаться, и просто разгоняться по прямой - не самое оптимальное решение. У химических двигателей сравнительно малое значение удельного импульса для этого (большой расход рабочего тела), у ионных двигателей - высокий расход энергии, которую негде брать, а еще куда-то тепло девать нужно, в космосе это не так просто.
И в итоге получается, что маршрут важен в том смысле, что должен максимально эффективно использовать гравитационные маневры, то есть, по сути, пролететь рядом с максимальным количеством планет. Статья на Википедии: https://ru.wikipedia.org/wiki/Гравитационный_манёвр
Вполне может оказаться, что энергетически выгоднее сначала полететь к Солнцу, посетить Меркурий, Венеру, Землю и остальные планеты, чем просто разгоняться двигателями. А это - не быстро, нужно учитывать огромные расстояния и взаимное расположение планет.
Мало кто знает, что Маяковский работал именно за таким монитором.
Очередь есть, без нее никак. Просто вместо отдельного сервиса это таблица в базе. Соответственно, из этой таблицы берут, там же обновляют статус и так далее. Пока что это отлично работает.
Что касается того, почему это не отдельный сервис:
У обработчика в памяти должна быть предпосчитанная вспомогательная структура, в случае с большими каталогами - несколько гигабайт. Поэтому взять задачу может не любой обработчик.
Обработчиков несколько, и каждый работает со своим каталогом, данные в оперативной памяти не дублируются.
В случае отключения или зависания обработчика его задачи по его каталогам должны перераспределиться на другие обработчики. Перед этим там считаются данные для каталога.
Задач относительно немного, и с таким набором требований оказалось проще самим написать логику очереди, чем использовать готовое решение. Когда эта часть станет узким местом, будем внедрять готовый MQ.
Спасибо, устраняем проблемы. Часть уже исправили, часть еще в процессе.
Спасибо. Я знал про эту возможность, но почему-то не пользовался. Попробуем на практике.
Спасибо за замечания, будем исправлять.
Вопрос с хостингом закрывает человек в ЕС.
Логи хранятся в sql базе данных, поскольку работа с ними производится через Entity Framework, СУБД может быть любой.
С этой подводной лодки я никуда не денусь, это мой проект, и все риски на мне, если что.
Думаю, в этом и заключается моя роль в проекте - понимать, когда и что пора делать по-человечески, чтобы не было слишком поздно.
Ой, Razor конечно. Не знаю, как прочитал прошлый ваш комметнарий, и почему Razor не увидел.