Настройка скидок Розница 2.3. Логика проверки условий
Изначальная задача: нужно исключать из скидок уцененный товар.
Конфигурация от рарус Розница 8. Магазин одежды и обуви. По сути Розница 2.3
Написал внешнюю обработку для проверки условия (образец брал из комплекта поставки), но при тестировании заметил, что под скидку попадают строки, которые не должны.
В итоге вопрос сводится: как должны совместно отрабатывать условия скидки?
По моей логике все должны отрабатывать через логическое "И", но работает для каждой проверяемой строки - по последнему проверяемому условию. То есть если первое условие скидки для первой строки НЕ сработало, а второе условие сработало - то эта строка подпадет под скидку, если же строки условий поменять местами, то соответственно строка НЕ попадет под скидку..
Чтобы убедиться, что это не косяк моей внешней обработки сделал тестовую скидку штатными средствами: 10%, область применения - "В строке, в которой выполнились условия", в условиях 2 условия: "Количество в строке не менее 1 ед." и "Количество в строке не менее 2 ед.".
По моей логике скидка должна срабатывать только в строках, где количество >= 2, но если условие "Количество в строке не менее 1 ед." поставить в таблице условий скидки последним, то скидка срабатывает на все строки документа!
То есть построить из условий сколько-нибудь сложную логику разноплановых проверок невозможно..
Толкового описания, как это должно работать не нашел, может подскажете, где такое написано или скажете, что я не так делаю? Может все-таки возможно, чтобы все условия работали через "И"?
Есть используемая старая УТ 11.1 - там сколько условий не добавляй построчных и/или на весь чек - все корректно отрабатывает через логическое "И".
Конфигурация от рарус Розница 8. Магазин одежды и обуви. По сути Розница 2.3
Написал внешнюю обработку для проверки условия (образец брал из комплекта поставки), но при тестировании заметил, что под скидку попадают строки, которые не должны.
В итоге вопрос сводится: как должны совместно отрабатывать условия скидки?
По моей логике все должны отрабатывать через логическое "И", но работает для каждой проверяемой строки - по последнему проверяемому условию. То есть если первое условие скидки для первой строки НЕ сработало, а второе условие сработало - то эта строка подпадет под скидку, если же строки условий поменять местами, то соответственно строка НЕ попадет под скидку..
Чтобы убедиться, что это не косяк моей внешней обработки сделал тестовую скидку штатными средствами: 10%, область применения - "В строке, в которой выполнились условия", в условиях 2 условия: "Количество в строке не менее 1 ед." и "Количество в строке не менее 2 ед.".
По моей логике скидка должна срабатывать только в строках, где количество >= 2, но если условие "Количество в строке не менее 1 ед." поставить в таблице условий скидки последним, то скидка срабатывает на все строки документа!
То есть построить из условий сколько-нибудь сложную логику разноплановых проверок невозможно..
Толкового описания, как это должно работать не нашел, может подскажете, где такое написано или скажете, что я не так делаю? Может все-таки возможно, чтобы все условия работали через "И"?
Есть используемая старая УТ 11.1 - там сколько условий не добавляй построчных и/или на весь чек - все корректно отрабатывает через логическое "И".
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
По моей логике все должны отрабатывать через логическое "И", но работает для каждой проверяемой строки - по последнему проверяемому условию. То есть если первое условие скидки для первой строк
не хотите попробовать в условия скидки добавить сегменты номенклатуры ? думаю это вам поможет
Добрый день!
Да, тоже столкнулась с этим, при обновлении УТ ( давно это было)...Это их странное "ИЛИ" в скидках, тоже доставило хлопот.
Вышла из ситуации не лучшим способом: переписала блок скидок под "И". К моей вящей радости, именно эта конструкция, до сих пор 1С не переделывается, т.е при обновлении, просто вставляю свой кусок кода.
А , по логике 1С, должно быть , видимо, следующее : условия по скидкам нужно объединять по группам, чтобы проверка шла в них. Тогда , вроде, эта конструкция работает. Только уж больно многоэтажная она получается, даже при достаточно неразветвленных вариантах. Учитывая, что мною дописаны собственные условия скидок, остановилась на варианте использования собственного кода
Да, тоже столкнулась с этим, при обновлении УТ ( давно это было)...Это их странное "ИЛИ" в скидках, тоже доставило хлопот.
Вышла из ситуации не лучшим способом: переписала блок скидок под "И". К моей вящей радости, именно эта конструкция, до сих пор 1С не переделывается, т.е при обновлении, просто вставляю свой кусок кода.
А , по логике 1С, должно быть , видимо, следующее : условия по скидкам нужно объединять по группам, чтобы проверка шла в них. Тогда , вроде, эта конструкция работает. Только уж больно многоэтажная она получается, даже при достаточно неразветвленных вариантах. Учитывая, что мною дописаны собственные условия скидок, остановилась на варианте использования собственного кода
(3) возможно придется усложнять свое самописное условие, добавляя туда сегмент с ограничениями, но хотелось бы понимать как задумано. А если мне еще абсолютно другое условие нужно будет наложить? каждый раз дописывать каждое условие, чтобы оно позволяло все настроить в себе? мне кажется это неправильный подход..
Написал в поддержку, может чего ответят или направят куда почитать.
На крайний случай да - придется усложнять свое условие, ограничивать область действия сегментом в самой скидке, надеятся, что не появятся более сложные по настройке акции )
Написал в поддержку, может чего ответят или направят куда почитать.
На крайний случай да - придется усложнять свое условие, ограничивать область действия сегментом в самой скидке, надеятся, что не появятся более сложные по настройке акции )
(5) мне нужно исключить из скидки уцененный товар, это невозможно сделать сегментами, поэтому я делаю свою обработку, которая будет проверять по строкам первоначальную цену и текущую и определять подходит ли данный товар под условие для скидки.
Но это то, с чего начал, а в итоге пришел к тому, что я не понимаю, по какой логике должны проверяться условия скидки, если их указана несколько, абстрагируясь от деталей каждого из условий. По логике ведь все должно через "И". то есть для конкретной строки товара документа должны выполниться все условия из скидки и только тогда должна примениться скидка, а я вижу пример, когда первое условие по строке НЕ выполняется, второе выполняется и в итоге на эту строку скидка применяется.
Но это то, с чего начал, а в итоге пришел к тому, что я не понимаю, по какой логике должны проверяться условия скидки, если их указана несколько, абстрагируясь от деталей каждого из условий. По логике ведь все должно через "И". то есть для конкретной строки товара документа должны выполниться все условия из скидки и только тогда должна примениться скидка, а я вижу пример, когда первое условие по строке НЕ выполняется, второе выполняется и в итоге на эту строку скидка применяется.
(8) никто не хочет делать никто не оплачивает.
Просто я делаю это группами, напирмер все Соки или все макароны одной марки, поэтому сегменты отлично подходят для этого.
А если рандомно номеклатуру добавлять в сегменты, а потом как-то отслеживать что продано а что нет, и коректировать сегменты в этом плане действительно неудобно.
Поэтому я говорю что эти хотелки неправиильные, рекламмная компания и товары на распродажу надо превратить в акции, например "товар недели", или месяца" и делать акции на группу товаров.
А не так что смотришь на товар а у него через неделю срок годности заканчивается, значит его в распродажу.
Делайте группами
)Темболее эта вообще классическая хотелка которая решается за 2 минуты. делаешь группу минимум. туда все скидки и новую со скидкой 0% на сегмент или отбор.
у они как я понял рандомный товар отправляют на распродажу, и видимо список этот со временем сильно разрастается, и за ним надо следить. А этого Просто я делаю это группами, напирмер все Соки или все макароны одной марки, поэтому сегменты отлично подходят для этого.
А если рандомно номеклатуру добавлять в сегменты, а потом как-то отслеживать что продано а что нет, и коректировать сегменты в этом плане действительно неудобно.
Поэтому я говорю что эти хотелки неправиильные, рекламмная компания и товары на распродажу надо превратить в акции, например "товар недели", или месяца" и делать акции на группу товаров.
А не так что смотришь на товар а у него через неделю срок годности заканчивается, значит его в распродажу.
Делайте группами
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот