[Поддержка] Микрофинансы - удобный мониторинг финансового состояния магазина

[OtezVikentiy]

48 минут назад, sakun сказал:

Да, это бы решило все проблемы, но к сожалению, поставщиков предоставляющих API найти, крайне, сложно)

Можно и подгрузку CSV делать например. Если есть например почта куда бы поставщик присылал новые отчеты в каком-то заранее известном формате - то можно их парсить и обновлять автоматически - тоже вариант ))) Главное - чтобы было откуда брать данные, а остальное - дело техники )))

[Ivanzo]

7 часов назад, sakun сказал:

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

Просто из практики в голове не укладывается как это все руками будет делать ответственный за это направление. По каждому заказу поднять доки по какой цене поступил товар и все это проверять и исправлять в заказе. Если заказов в день немного и в заказах по одной позции наверное реально. Просто тут мы уже говорим о функции своевременного обновления цен. Тут несколько путей все это автоматизировать или делать функционал учета поступления товара. Или 2 в 1. 

[OtezVikentiy]

В планах разработки по данному модулю - реализация минималистичной CRM системы.

Если есть пожелания - пишите, постараюсь всё учесть. )))

[Ivanzo]

Предложение.

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

2. Отчеты выводить не от разницы базовой цены, а от реальной закупочной, т.е. по себестоимости. Для этого да тогда надо сделать учет поступления товара. Внедрив поступление сразу решаться вопросы что тут писали про корректировку закупочной цены в заказе и т.д. Т.е. всегда будет актуальная закупочная цена.

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

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

Ну для минимализма это будет уже достаточно. 

[OtezVikentiy]

9 часов назад, Ivanzo сказал:

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

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

 

9 часов назад, Ivanzo сказал:

2. Отчеты выводить не от разницы базовой цены, а от реальной закупочной, т.е. по себестоимости. Для этого да тогда надо сделать учет поступления товара. Внедрив поступление сразу решаться вопросы что тут писали про корректировку закупочной цены в заказе и т.д. Т.е. всегда будет актуальная закупочная цена.

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

 

9 часов назад, Ivanzo сказал:

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

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

 

9 часов назад, Ivanzo сказал:

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

Ну для минимализма это будет уже достаточно. 

Да, это тоже планирую реализовывать. Работу с клиентами и статистику по каждому клиенту.

[Ivanzo]

11 часов назад, OtezVikentiy сказал:

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

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

[OtezVikentiy]

1 час назад, Ivanzo сказал:

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

 

Ааа... ну плюс-минус понял... Только все равно отчеты считать корректно по закупочной стоимости, а не по базовой. Потому что например базовая стоимость 100 рублей например, а фактическая стоимость покупки например 80. Соответственно считать по 100 рублей - это будет завышать расходы магазина фактически.

 

[Ivanzo]

2 часа назад, OtezVikentiy сказал:

 

Ааа... ну плюс-минус понял... Только все равно отчеты считать корректно по закупочной стоимости, а не по базовой. Потому что например базовая стоимость 100 рублей например, а фактическая стоимость покупки например 80. Соответственно считать по 100 рублей - это будет завышать расходы магазина фактически.

 

Все верно про это ровно и пишу, что закупочная должна формироваться от поступления. Поэтому и нужно поступление. И это правильно, все товаро-учетные системы так ведут учет.

А та цена которая сейчас (закупочная) она нужна только для проставления наценки и своевременного обновления цен. Ведь не все товары которые размещаются на сайте будут в наличии, а цены на них надо же обновлять. Вот и должна быть наценка от базы опта например.

А закупочная цена формируется уже по факту поступления.

[OtezVikentiy]

1 час назад, Ivanzo сказал:

Все верно про это ровно и пишу, что закупочная должна формироваться от поступления. Поэтому и нужно поступление. И это правильно, все товаро-учетные системы так ведут учет.

А та цена которая сейчас (закупочная) она нужна только для проставления наценки и своевременного обновления цен. Ведь не все товары которые размещаются на сайте будут в наличии, а цены на них надо же обновлять. Вот и должна быть наценка от базы опта например.

А закупочная цена формируется уже по факту поступления.

Да, думаю в разрезе CRMки надо будет реализовать подобные механики... Возможно даже стоит сделать историю базовых/закупочных цен, потому что может быть кейс, когда 1 и тот же товар покупается в разное время по разной цене и выставлять на него наценку сразу повышенную тоже не совсем прям корректно... о_О

[Ivanzo]

4 часа назад, OtezVikentiy сказал:

Да, думаю в разрезе CRMки надо будет реализовать подобные механики... Возможно даже стоит сделать историю базовых/закупочных цен, потому что может быть кейс, когда 1 и тот же товар покупается в разное время по разной цене и выставлять на него наценку сразу повышенную тоже не совсем прям корректно... о_О

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

[OtezVikentiy]

9 минут назад, Ivanzo сказал:

Коректность цен и когда их обновлять это уже не логика модуля.  Тут уже сам предприниматель решает.

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

24 минуты назад, Ivanzo сказал:

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

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

[gidrik]

Скажите, а есть ли подобный модуль под OC Store 1.5.5.1.2?

[Ivanzo]

6 часов назад, gidrik сказал:

Скажите, а есть ли подобный модуль под OC Store 1.5.5.1.2?

Лучше перейти уже на 2.3 как минимум. У самого была такая же проблема не переходил потому что было много что допилено. Перешел теперь все что допиливаю стараюсь в окмоды закидывать и с обновлениями стало меньше проблем. Теперь хоть можно вспомнить где и что менял. Да и поддержка модулей и разработка новых под 1.5 у многих приостановлена. 

[gidrik]

2 часа назад, Ivanzo сказал:

Лучше перейти уже на 2.3 как минимум. У самого была такая же проблема не переходил потому что было много что допилено. Перешел теперь все что допиливаю стараюсь в окмоды закидывать и с обновлениями стало меньше проблем. Теперь хоть можно вспомнить где и что менял. Да и поддержка модулей и разработка новых под 1.5 у многих приостановлена. 

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

[OtezVikentiy]

9 часов назад, gidrik сказал:

Скажите, а есть ли подобный модуль под OC Store 1.5.5.1.2?

К сожалению под 1.5 планов по адаптации нету. Уж слишком старая версия движка. Даже не уверен, что оно там взлетит без лютейших костылей (которые ставить не хочется).

Поэтому...

3 часа назад, Ivanzo сказал:

Лучше перейти уже на 2.3 как минимум.

Соглашусь вот с этим...

[Ivanzo]

10 часов назад, gidrik сказал:

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

Такая же история была.  В итоге перешёл и реализовал новые фишки. Можно перейти безболезнено. Скоро уже придется на 3 переходить. Автор извиняюсь за то что не по теме.

[sakun]

Подскажите, не будет ли модуль конфликтовать с OrderPro?

Спойлер

Известные несовместимости (ограничения):
1. Дополнение не совместимо с модулями влияющими на подсчет итогов заказа, у которых "код итога" называется "discount"
Обычно файлы такого дополнения также имеют названия "discount.php" и в файле модели "catalog\model\total\discount.php"
имеют строку: "$total_data[] = array('code' => 'discount'
Чтобы обеспечить работу с таким модулем, необходимо изменить его код и названия его файлов на что-то другое, например "tdiscount"
2. Дополнение не совместимо с модулем "Опции с количеством", а так же с другими модулями, существенно меняющими функционал опций у товара.
3. Модуль не совместим с модулем Мультивалюта (Мультивалютные товары).

 

PS: на демо нельзя войти под указанными логину и паролю

[OtezVikentiy]

7 часов назад, sakun сказал:

Подскажите, не будет ли модуль конфликтовать с OrderPro?

  Скрыть контент

Известные несовместимости (ограничения):
1. Дополнение не совместимо с модулями влияющими на подсчет итогов заказа, у которых "код итога" называется "discount"
Обычно файлы такого дополнения также имеют названия "discount.php" и в файле модели "catalog\model\total\discount.php"
имеют строку: "$total_data[] = array('code' => 'discount'
Чтобы обеспечить работу с таким модулем, необходимо изменить его код и названия его файлов на что-то другое, например "tdiscount"
2. Дополнение не совместимо с модулем "Опции с количеством", а так же с другими модулями, существенно меняющими функционал опций у товара.
3. Модуль не совместим с модулем Мультивалюта (Мультивалютные товары).

 

PS: на демо нельзя войти под указанными логину и паролю

Добрый день! Судя по описанию - конфликтов быть не должно. Но в случае чего - всегда можно посмотреть и адаптировать. 

 

По поводу демо - да, сейчас демо не доступно, у меня перестройка стендов сейчас идёт для CI/CD и автоматизации тестирования модулей. Ориентировочно через неделю - другую демо снова будет доступно.

[OtezVikentiy]

В 06.03.2021 в 16:11, sakun сказал:

Подскажите, не будет ли модуль конфликтовать с OrderPro?

  Показать контент

Известные несовместимости (ограничения):
1. Дополнение не совместимо с модулями влияющими на подсчет итогов заказа, у которых "код итога" называется "discount"
Обычно файлы такого дополнения также имеют названия "discount.php" и в файле модели "catalog\model\total\discount.php"
имеют строку: "$total_data[] = array('code' => 'discount'
Чтобы обеспечить работу с таким модулем, необходимо изменить его код и названия его файлов на что-то другое, например "tdiscount"
2. Дополнение не совместимо с модулем "Опции с количеством", а так же с другими модулями, существенно меняющими функционал опций у товара.
3. Модуль не совместим с модулем Мультивалюта (Мультивалютные товары).

 

PS: на демо нельзя войти под указанными логину и паролю

Демо стенд восстановлен. FYI

[OtezVikentiy]

В 24.01.2021 в 18:52, sakun сказал:

День добрый!

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

В ближайшем релизе подъедет этот функционал.

[OtezVikentiy]

В 24.01.2021 в 18:52, sakun сказал:

День добрый!

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

В ближайшем релизе подъедет этот функционал.

[OtezVikentiy]

В 06.03.2021 в 16:11, sakun сказал:

Подскажите, не будет ли модуль конфликтовать с OrderPro?

  Показать контент

Известные несовместимости (ограничения):
1. Дополнение не совместимо с модулями влияющими на подсчет итогов заказа, у которых "код итога" называется "discount"
Обычно файлы такого дополнения также имеют названия "discount.php" и в файле модели "catalog\model\total\discount.php"
имеют строку: "$total_data[] = array('code' => 'discount'
Чтобы обеспечить работу с таким модулем, необходимо изменить его код и названия его файлов на что-то другое, например "tdiscount"
2. Дополнение не совместимо с модулем "Опции с количеством", а так же с другими модулями, существенно меняющими функционал опций у товара.
3. Модуль не совместим с модулем Мультивалюта (Мультивалютные товары).

 

PS: на демо нельзя войти под указанными логину и паролю

Демо восстановлено

[max2020]

добрый день,  заметил такой момент если в заказе бесплатная доставка + использован промокод на скидку, то сумму считает не совсем верно,  пример: подитог 100р + 0р доставка - 10% скидки, то итого получается 90р.

 

И  в модуле в заказах считает  что 90р с доставкой и без доставки 100р, соответственно отнимает себестоимость товара от 100р.

 

Как можно поправить?) 

[OtezVikentiy]

4 часа назад, max2020 сказал:

добрый день,  заметил такой момент если в заказе бесплатная доставка + использован промокод на скидку, то сумму считает не совсем верно,  пример: подитог 100р + 0р доставка - 10% скидки, то итого получается 90р.

 

И  в модуле в заказах считает  что 90р с доставкой и без доставки 100р, соответственно отнимает себестоимость товара от 100р.

 

Как можно поправить?) 

Добрый вечер. Принял. Поправлю в ближайшем релизе.

Прям вот совсем скоро, уже сборку делаю. На днях выкачу новую версию - там будет исправлено.

Спасибо большое за багрепорт! 

[OtezVikentiy]

В 06.04.2021 в 18:46, max2020 сказал:

добрый день,  заметил такой момент если в заказе бесплатная доставка + использован промокод на скидку, то сумму считает не совсем верно,  пример: подитог 100р + 0р доставка - 10% скидки, то итого получается 90р.

 

И  в модуле в заказах считает  что 90р с доставкой и без доставки 100р, соответственно отнимает себестоимость товара от 100р.

 

Как можно поправить?) 

Добрый вечер! Не могли бы Вы выйти со мной на связь в телеграмм @otezvikentiy, пожалуйста. Я что-то не могу воспроизвести данный баг. Попробовал и с залогиненным пользователем и без и с платной и с бесплатной доставкой и с акциями и со скидками - выглядит всё корректно, кейс воспроизвести не могу. Может быть есть какой-то конфликт по модулям или еще что-то подобное, предлагаю разобраться с этим конкретно у вас в проекте. )))