Писал уже на эту тему, вот решил и код приложить. Суть проблемы - некоторые неточности в штатной работе подбора продуктов в мастере в sales commerce и enterprise может потенциально привести к указанию в заказе неправильных цен, неправильных ставок НДС или продать то, что данному клиенту вообще продать нельзя.
Как сделано в коробке:
1. Настраиваете прайсы, один делаете базовым
2. Настраиваете разные цены для разных продуктов, включая валюты и ставки НДС
3. Открываете мастер подбора и несколько удивляетесь, потому что:
- отображается та цена, которая соответствует текущему установленному в настройках прайсу
- у продуктов, для которых не установлена эта цена, отображается некая другая цена, если используется несколько валют и ставок НДС - ясно, к чему это все приведет.
По моему мнению данное поведение свидетельствует о том, при проектировании этой логики не все было продумано как следует, поэтому будем править, желательно малой кровью :)
Описано на примере заказа, но в принципе должно работать и в фактуре. То, что мы сделали в качестве обходного пути имеет несколько вводных:
1. У нас прайс-лист задается в лоб в заказе непосредственно. Если нужно задавать в клиенте, то вместо получения значения прайлиста в заказе нужно его из клиента тащить (лучше в заказ, тогда ничего нашего править не придется.
2. При изменении прайса в заказе автоматический перерасчет не осуществляется - правьте руками в позициях :)
Теперь суть изменений:
1. Основным модулем, отвечающим за работу мастера подбора является ProductSelectionViewModel. Чтобы его перестроить как нам надо, создаем замещающий пользовательский модуль, в качестве родителя указываем этот самый ProductSelectionViewModel и копируем туда все целиком из оригинала, включая Dependencies, картинки и строки локализации. Внимание - строки локализации должны быть переименованы в коде, иначе не подтянутся значения строчек. Например, в оригинале было PriceLabel: resources.localizableStrings.PriceCaption, у нас будет PriceLabel: resources.localizableStrings.ChlidPriceCaption, соответственно нужно создать новую строку локализации ChildPriceCaption, скопировать туда из оригинала текст.
2. Нужно загрузить туда заново иконки, их всего две - каталог и корзина. Это просто - сохраните в браузере и потом загрузить в наш модуль.
3. Добавляем в заказ поле "Прайслист" (справочник, прайслист), обязательное.
4. Теперь надо модифицировать код. В частности:
- в функции init: function(config) закомментить строку
- присвоение значения this.set("BasePriceList") перетаскиеваем в функцию requestMasterEntityData: function(callback):
добавляем
добавляем
теперь у нас есть значение параметра схемы BasePriceList, который соответствует прайсу в заказе.
дальше переопределяем то, что должно вывестисть в мастере подбора:
- в функции loadGridData: function() переносим строку
в вызов которой добавляем параметр basePriceList.value
- в самой функции initQueryColumns
вставлем новый параметр pricelist в объявление функции:
комментим вот эти строки:
// esq.addColumn("Currency");
// esq.addColumn("Tax");
вместо них вставляем
esq.addColumn("[ProductPrice:Product:Id].Currency", "Currency");
esq.addColumn("[ProductPrice:Product:Id].Tax", "Tax");
добвляем фильтр по прайсу (хотим только те продукты, которые имеют этот прайс)
функция готова :)
На этом этапе при нажатии на + в заказе у нас отобразится правильный список продуктов в правильными ценами. Проблема в том, что уже все работает, но при сохранении в позицию "продукт в заказе" пропишется базовый прайс.
Исправляем этот недочет:
- в функции saveSelectedProducts находим фрагмент:
insert.setParameterValue("PriceList", item.get("PriceList").value, Terrasoft.DataValueType.GUID);
} else if (this.get("BasePriceList")) {
insert.setParameterValue("PriceList", this.get("BasePriceList").value, Terrasoft.DataValueType.GUID);
}*/
и комментим его. Как я понял, у этого куска кода есть неслабая проблема - item.get("PriceList") при сохранении позиции из мастера всегда null, чтобы это побороть пишем "в лоб":
insert.setParameterValue("PriceList", this.get("BasePriceList").value, Terrasoft.DataValueType.GUID);
В принципе все :) НДС и валюты тоже тянутся, понятное дело.
еще мы от греха добавили
в запрос для новой позиции в функции loadGridData, но особой разницы не заметили.
И последнее - на фактуре (счете) не проверяли, но по идее, если туда тоже вставить поле "Прайс-лист" работать должно.
Во вложении исправденный модуль для 7.8.x - 7.10.x
Добрый день, Дмитрий!
Спасибо за обратную связь. Мы передали Ваше пожелание на добавление этой функциональности. Это пожелание будет рассмотрено командой разработки продукта для включение данной функции в будущих релизах в рамках проблемы 4896.
Что касается отображение продуктов в подборе, то в базовой функциональности продукта они всегда отображаются согласно одному только прайс-листу - "Базовый прайс лист" и суммы отображаются всегда в базовой валюте (так как в большинстве случаев продажа товара ведется в единой валюте). В данном случае при кастомизации схемы подбора продуктов будет более логичным вывод дополнительных колонок (стоимость в других валютах).
"Дмитрий Степанов" написал:Суть проблемы - методические ошибки в штатной работе подбора продуктов в мастере в sales commerce и enterprise может потенциально привести к указанию в заказе неправильных цен, неправильных ставок НДС или продать то, что данному клиенту вообще продать нельзя.
Если у Вас есть примеры/кейсы ошибок работы базового подбора продуктов, то опишите их, пожалуйста, в рамках отдельного обращения в техническую поддержку или здесь на форуме.
Валерий, приветствую! Спасибо за реакцию. Под методическими ошибками я подразумевал кривизную постановки задачи а не ее реализации. Вот вам наглядный пример:
1. В компании есть клиенты из разных стран (разные валюты и ставки НДС)
2. Некоторые продукты доступны к продаже в одних странах (по одному прайсу), иные - в других странах (по другому прайсу).
В коробе последовательность такая:
1. Набираем продукты в соответствии с базовым прайсом, не обращая внимание на цены, валюты и т.д. и выходим из мастера.
2. Открываем карточку клиента и смотрим, какой у него прайс (невыведенное по умолчанию поле "Pricelist").
3. Открываем раздел продуктов и выписываем на бумажку какие продукты для какого прайса вообще доступны
3. Возвращаемся в заказ и начинаем ручками проходиться по списку продуктов. Если продукт доступен для данного прайса, меняем ручками базовый прайс на нужный. Если не доступен - позицию удаляем.
Как вы сами понимаете это нонсенс. Если же менеджер по продажам не имеет доступа к теущему прайсу клиента, т.е. не знает какой он, то задача вообще не решаемая. Я уж помолчу о количестве ошибок в этом случае.
PS. В единой валюте прайсы как раз ведутся достаточно редко. Как пример - вы сами. Вот попробуйте мне выставить счет на 10 лицензий например используя типовой мезанизм, после этого отпадут все вопросы :)
Дмитрий, спасибо за детализацию.
Информация рассматривается командой разработки продукта. По факту анализа мы дадим Вам полный roadmap по реализации этого функционала.
Добрый день, Дмитрий!
На текущий момент задачу можно решить путем настройки каталога продуктов который будет давать понимание для каких стран можно отгружать тот или иной продукт.
Для фильтрации по выбранному прайс листу в контрагенте можно настроить бизнес процесс при добавлении который проставит нужный прайс-лист.
Данные доработки включены в roadmap развития продукта и планируются быть выполненными в 2017 году.
ну спасибо и на том, что может быть в коробку вставите.
PS. С БП тут не очень оптимальное решение.