Добрый день. Такой опции нет, но мы в процессе работы над задачей 1 товар - несколько поставщиков.
Там будут разные варианты логики - сумма, хотя бы один.
Добрый день. Такой опции нет, но мы в процессе работы над задачей 1 товар - несколько поставщиков.
Там будут разные варианты логики - сумма, хотя бы один.
Еще есть вот такая ситуация с остатками в файле у поставщиков.
Есть Местный склад и Центральный и могут быть разные ситуации.
Местный - есть
Центральный - нет
Местный - нет
Центральный - есть
т.е. нельзя взять остатки какого то одного склада, нужна “сумма”. А общего остатка в файле поставщика нет.
Это как то можно сейчас обрабатывать?
Да такая опция есть - в вашем случае нужен модуль складов.
Модуль позволяет писать остатки в разные склады.
страшно даже влазить в логику мультискладовости…
Сейчас вот подумал, что если вы реализуете
то можно будет просто один и тот же файл прогонять два раза, в первом прогоне брать Местный склад, во втором Центральный и тоже должно сработать.
Мы не будем этого делать, наши клиенты используют склады и модуль отлично с ними работает даже в мультивендоре.
Вам тоже советую без костылей этот вопрос решить.
Максимум что можно предложить в рамках кастомной доработки для вас подготовить XML файл с суммированными остатками. Но портить работу модуля такой логикой не стоит.
что то я запутался.
вы написанное вчера уже НЕ планируете делать?
Это разное. У вас требуется сумма остатков внутри одного поставщика, такое делать не будем, это надо решать через склады.
Понял. Имхо конечно зря. Если у поставщика будет по 10 складов и 20 поставщиков.
Вся эта инфа в базе не нужна.
По сути не важно с какого склада поставщик привезет товар. Это его личный геморрой.
Надеюсь вы позже вернетесь к этой идее. Спасибо.
Вам проще заказать доработку у нас или у кого нибудь, не надо портить модуль который сейчас очень хорошо решает свою задачу.
Ну, тут сроки разные могут быть при поставке с разных складов и суммировать остатки будет не очень корректно, особенно при работе с маркетплейсами это может быть критично, кому-то лучше вести остатки в разрезе складов.
100%, поэтому как всегда нужна гибкость настроек.
Подскажите, модуль может сам удалять старые файлы прайсов?
прайс грузится по ссылке, и после загрузки имя файла отличается от предыдущих (динамический)
сейчас у нас один прайс весит около 200 мб, обновление происходит 1 раз в день. При этом файлы сохраняются на сервер. За неделю накапливается 7 файлов более чем на 1 гб. Приходится вручную удалять старые файлы прайсов. Почему бы это не вывести настройкой, сколько дней хранить файлы? или это уже предусмотрено?
Добрый день - поставьте настройку в парсере Хранить логи в нужном количестве дней, файлы тоже будут удаляться.
Здравствуйте! Скажите можноли реализовать такой сценарий.
В прайсе есть товар - Телефон Сони. остаток 100 шт.
В магазине наличие настроенно следующим образом: на вскладке общее в блоке остаток, стоит 100 торов
И настроены магазины и склады так.
Добрый день!
Брать значение из одной ячейки в несколько полей данных не получится.
Добрый день. Подскажите есть ли решение проблемы.
Модуль парсит 3 цены
Но только одну валюту.
Валют надо тоже 3, т.к. поставщики зачастую розницу ставят в национальной валюте, а закупку в у.е.
Скрин файла с разными валютами закупки и розницы и цены у одного товара.
В принципе на данный момент можно было бы выйти из ситуации создав 3 отдельных парсера для каждой из цен, но оказалось, что Закупочная цена и Рекомендованная цена НЕ пересчитываются вообще по курсу валюты.
А это уже прям проблемище.
Вот пример. 150 модуль умножил на 30.5 и получил 4575
а вот 172,8 просто округлил НЕ умножая на курс.
А можно выбрать в какое поле будет подставляться значение?
Или возможно только подставить количетсво в дефолтную ячейку наличия?
Добрый день, валюта одна на прайс, не для колонки.
Не очень понятно, что вы хотите сделать. Вы можете выбрать в какой склад будут писаться остатки.
Какой колонки?
Можете тогда это починить?
Закупочная цена и Рекомендованная цена НЕ пересчитываются вообще по курсу валюты.