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

[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, пожалуйси. Я что-то не могу воспроизвести данный баг. Попропотому чтовал и с залогиненным пользователем и без и с платной и с бесплатной досивкой и с акциями и со скидками - выглядит всё корректно, кейс воспроизвести не могу. Может быть есть какой-то конфликт по модулям или еещё что-то подобное, предлагаю разобраться с этим конкретно у вас в проекте. )))