gifts2017

[ОБУЧАЛОВКА] Как с минимальными затратами сделать "красивый" прайс

Опубликовал Сергей (Che) Коцюра (CheBurator) в раздел Программирование - Практика программирования

Предлагается подход к формированию многопризнакового прайса без изменения схемы данных.
ВНИМАНИЕ!!! В данной статье рассматривается один из возможных вариантов решения задачи (читайте комментарии)
 
Рассмотрим банальную ситуацию.
...
Продажам (отделу) стрельнуло в голову сделать супер-пупер прайс - дескать, от этого продажи попрут в гору, денег фирме обломится немеряно, программеру домой канал в 2 метра толщиной заведем - но надо быстро-быстро сделать.. причем мы сами пока толком не знаем... типа вот тут чтоб было жирным цветом, а вот этот товар обязательно красным, а вот эти товары - синий шрифт на желтом фоне и пр.
...
Городить доп.реквизиты в справочник товаров не будем - мало ли что стрельнет в голову продажникам через неделю, опять же флажков не напасешься... опять же будут дергать сделать еще это, а это убрать и т.д.
...
Поэтому делаем не сложно, а суперпросто: забульбеним универсальный инструментарий, и пусть продажи, пользуясь им - как хотят, так и "раскрашивают".
...
Для этого применим замечательный механизм свойств, реализованный в типовых ТиС (на примере ред.9.2)
...
Рассмотрим реализацию данной задачи на примере простого требования: некий произвольный перечень товаров выводить в прайсе жирным шрифтом.
...
1. Выработаем систему обозначений: если у товара свойство "ВыделитьВпрайсе" принимает значение "Да" (отличное от нуля) - эта позиция подлежит выделению в прайсе. При этом "нулевое" значение свойства (все что отлично от "Да" или отсутствие такого свойства у товара вообще) означает обычную позицию в прайсе.
...
2. Дадим инструментарий для быстрого заполнения/переключения данного свойства у нужных товаров (на базе типовой обработки установки свойств номенклатуры/контрагентов - немного ее упрощаем/модифицируем в части заточки под данную задачу: переключение да/нет)
...
3. Обязательно предусмотрим механизм протоколирования действий по п.2 - в основном, чтобы "отмазаться" от наездов возмущенных продажников по типу "какого .. эта позиция выделена?" - в принципе это вопрос может решаться многими методами и протоколирование, на самом деле, последний из них - типа спасательного круга на крайний случай. Протокол пишем в обычный текстовый файл с именем по шаблону ГГГГММДДЧЧММ.txt и кладем в специальный папочку/подпапочку, где у нас хранятся всяческие протоколы...
Например, в данный файлик пишем:
МенеджерПоПрайсам 30.11.05 16:36:56
НЕТ -> ДА 00009469 Пензитал табл.п.о №30
НЕТ -> ДА 00001312 Флемоксин Солютабл. табл.раствор.125мг №20
Итого: видно кто и когда произвел манипуляции с раскраской файла
...
4. При формировании типового прайса (или даже нетипового - идея та же самая) сделаем вставочку типа:
//
Запрос = СоздатьОбъект("Запрос");
ТекстЗапроса =
"//{{ЗАПРОС(Сформировать)
|Обрабатывать НеПомеченныеНаУдаление;
|ВидСвойства = Справочник.СвойстваНоменклатуры.ВидСвойства.Наименование;
|ЗначениеСвойства = Справочник.СвойстваНоменклатуры.ЗначениеСвойства.Наименование;
|Номенклатура = Справочник.СвойстваНоменклатуры.Владелец;
|Группировка Номенклатура;
|Условие (Найти(ВРЕГ(ВидСвойства),""ВЫДЕЛИТЬВПРАЙСЕ"") < > 0);
|Условие (Найти(ВРЕГ(ЗначениеСвойства),""ДА"") < > 0);";

Если Запрос.Выполнить(ТекстЗапроса)=0
Тогда Возврат;
КонецЕсли;

ТЗВыделить = СоздатьОбъект("ТаблицаЗначений");
Запрос.Выгрузить(ТЗВыделить,1,0);
..
6. Далее, при построчном выводе прайса ищем текущий товар в таблице ТЗВыделить, нашли - выводим жирным шрифтом, не нашли - как обычно.
..
На что следует обратить внимание при использовании данной методики?
а) Следует тщательно продумать "систему условных обозначений" для прайса и ограничить круг лиц, которые могут модифицировать справочники видов свойств и сами значения свойств.
б) предложенная методика - достаточно универсальная и без особых затрат может "клонироваться" на родственные задачи. Но! За счет универсальности - работать будет медленнее... Поэтому - сначала оцениваем соотношение "затраты программиста/скорость работы программы" и реализуем то, что считаем более подходящим.
...
Понятно, что данный пример - самое простое, что можно придумать, слегка "расширив" рассмотренную схему можно построить достаточно универсальную программулину. Основное при этом - "хитрость" программиста... Типа: можно значения свойств кодировать "прямо", т.е. задав "значение=font[bold]color[255000000]" и написав в коде что-то типа "применить к выводимой строке текущее значение свойства" автоматом получим жирные красные буквы на белом фоне без излишних "если-то-иначе"...

Надеюсь, данная статья окажется кому-нибудь полезной.
Принимаются заказы на темы, по которым вы хотели бы почитать что-нибудь полезное.
В планах:
- статья о реализации простого электронного магазина на базе этих самых свойств;
- подробная методика построения системы "прайс-аналитика" для настоящих пацанов.
Пишите свои пожелания и отзывы.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Автор 28.03.06 02:57
50 чел посмотрело.. никто ниче не сказал...
вывод - написал лажу?
2. Генадий 28.03.06 09:49
Почему? Неплохое техническое задание на создание выделения прайса :) Но это далеко не минимальные затраты, это обычная работа программиста
3. Автор 29.03.06 02:36
Ну так и буум стремится, чтобы программист обходился минимальными затратами ;-)
На самом деле - больное место: механизм формирования разным клиентам "разных" прайсов - одному хоть убейся только в DBF, второй ничего кроме экселя не понимает, третий - еще что...
пятому хоть глаза выколи чтоб колонка "цена" шла пятой, а не 4-ой (наша программа по другому не умеет - уроды моральные ;-) седьмому нафиг не надо по мылу слать - дайте ему ссылку ftp-шную откуда он стянуть сможет... стоит насущная задача конструктора прайсов и способов их доставки... если кто подскажет м.б. готовый полуфабрикат/решение - буду благодарен (втроенный язык и конфигуратор не предлагать - это я и сам могу ;-)
4. Egor (Egor) 24.04.06 05:10
Не скажу, что лажу, но уж если заикнулся о скорости работы, мог бы привести модельный пример - насколько замедляется работа. Идеи и реализации на коленке многие могут изобразить, а вот написать грамотную завершёную статью - нет.
5. Автор 02.05.06 16:07
> Идеи и реализации на коленке многие могут изобразить, а вот написать грамотную завершёную статью - нет.
"Грамотные завершенные статьи" - только за гонорар.
Статья не преследовала цели сделать за вас все,а как раз наоборот - натолкнуть на идею/возможность реализации... ;-)
6. Олег Пономаренко (O-Planet) 15.06.06 16:02
Охеренеть... Ну ни в жизни бы не стал использовать столь полезный механизм свойств номенклатуры для раскраски документиков печатных... Нет, это - не метод. Надо учитывать, что чаще всего товары объединяются в группы, и свойства товара в прайсе может определяться свойствами, установленными на его группу. Потом, у одного моего клиента в прайсе ок. 8000 позиций. Так что он мне, интересно, скажет, если я ему предложу на каждую позицию свойства прайса выставлять...

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

Вывод:
1. Такое решение - более простое для понимания менеджера. Он теперь просто сам набирает в документ те товары, которые хочет как-либо выделить
2. Оно менее ресурсоемкое и более быстрое
3. Логика использования свойств номенклатуры для аналитических целей не нарушена!

Салон продаж "БЕЛКА": Бизнес Электроника (http://www.belkamag.ru)

7. Сhe Burashka (CheBurator) 16.06.06 02:44
> Сделал бы что-то типа документика "Прайс лист: приоритеты"
описанный выше вариант реализует такую же схему - возьми типовую обработку установки свойств номенклатуры - определяется перечень товаров, которыми будем манипулировать - это есть аналог внесения номенклатуры в твой документ.
> указал те товары, которые надо делать жирными или красным (синим, зеленым) цветом.
аналог - выставляем нужное значение свойства.
Имеено такая парадигма ближе работе менеджера - менеджер мыслит не регистрацией событий документами, а выполняет некие процессы, (которые у тебя привязываются к 1С-ой методологии доков).
Можно и твой и мой вариант использовать, а можно - и третий придумать...
А насчет ресурсоемкости - не надо ля-ля! В моем варианте пишется код обработки и все. В твоем - создаются новые объекты базы данных (документЮ, его реквизиты и пр)...
> менее ресупсоемкое и более быстрое - возможно... (см.выше ;-) зато мое - универсальнее..
> Логика использования свойств номенклатуры для аналитических целей не нарушена!
Ваще бред: с какого бодуна ты решил что свойства номенклатуры используются для аналитических целей...? Аналитические цели - всего лишь один вариант применения свойств, у меня например есть свойства по которым никогда аналитика не строится/не используется - мне что, нельзя так свойства применить? у меня на механизме свойств, например, контрагентов - целая система управления рассылкой прайсов построена... и ничего.. успешно работает...

Успехов!
8. Сhe Burashka (CheBurator) 16.06.06 02:49
> Нет, это - не метод. Надо учитывать, что чаще всего товары объединяются в группы, и свойства товара в прайсе может определяться свойствами, установленными на его группу.
..
Именно. Распределение товаров по произвольным группам, в т.ч. даже одновременно по нескольким непересекающимся - на раз делается свойствами безо всякого программинга...
..
> Так что он мне, интересно, скажет, если я ему предложу на каждую позицию свойства прайса выставлять...
..
Это ваши проблемы, если вы не можете путем использования стандартного универсального механизма подбора объектов определить совокупность объектов и прописать на них свойство... а не лопатить 8000 позиций вручную...
9. Олег Пономаренко (O-Planet) 16.06.06 04:34
Эх, вот не учат программировать видно в Москве...

Что лучше, документ или обработка. Да еще и приписал парадигму логики менеджера! Ты сядь и запраграммируй эту свою байду. Чем лучше документ? ТАМ ВСЕ НАГЛЯДНО. Его можно открыть и изменить. Можно ваще удалить. И никаких записей в справочнике свойств. Но ты главного не уловил: ты предлагаешь решение в лоб, а я - от обратного.

А по поводу анализа на основании свойств... Что сказать? У меня в одном ювелирном салоне в свойствах прописан материал, камень, размер, обработка, форма, тип изделия. Ты даже во сне не представишь, какую развернутую картину продаж на основании этого видит директор!
10. Сhe Burashka (CheBurator) 16.06.06 15:21
Ну, насчет как кого и где учат программировать - я уже высказался про отчет по остаткам, так что - не будем.... ;-)
А по существу: я предложил/показал метод, вполне работающий, с минимумом кодирования - сто не нравится-то?
Я ж ниже писал - кому-то удобнее документом, кому-то в свойствах прописать - не вопрос.
А использовать свойства для построения развернутой картиный продаж - ну и что? и у меня так есть... только я не замыкаюсь на использовании свойств для построения аналитических отчетов... вот и все...
11. AlexQC (alexqc) 24.08.06 16:32
Я не юзаю типовую российскую ТИС, поэтому как там сделаны свойства не знаю.
Но судя из вашего кода, это подчиненный номенклатуре справочник с реквизитами ВидСвойства и ЗначениеСвойства, которые тоже справочники.
Тогда вопрос:
НАФИГА искать в символьных строках
|Условие (Найти(ВРЕГ(ВидСвойства),""ВЫДЕЛИТЬВПРАЙСЕ"") <> 0);
|Условие (Найти(ВРЕГ(ЗначениеСвойства),""ДА"") <> 0);";
Ведь для этого 1Ске для каждого элемента придется вызывать свои ф-ции Найти,ВРЕГ

Гораздо логичнее и быстрее было бы сначала найти в справочнике видов свойств - то которое "ВЫДЕЛИТЬВПРАЙСЕ" (поместим его, наприер, в переменную ВидСвойства_Прайс), в справочнике значений - то которое "Да". И потом запрос бы преобразовался в 2 условия на равенства

|ВидСвойства = Справочник.СвойстваНоменклатуры.ВидСвойства;
|ЗначениеСвойства = Справочник.СвойстваНоменклатуры.ЗначениеСвойства;
|Условие (ВидСвойства=ВидСвойства_Прайс);
|Условие (ЗначениеСвойства=Значение_Да);

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

Ну а если в справочнике несколько значений ВЫДЕЛИТЬВПРАЙСЕ - тогда можно создать СписокЗначений? b использовать условие "В". Врядли таких значений много настолько, чтобы поиск подстроки стал эффективнее поиска по "В". Но лучше - привязать все такие свойства к одному ВидуСвойства, а лишние виды - грохнуть.

12. Сhe Burashka (CheBurator) 24.08.06 18:04
Конечно же, осноное назначение статьи - возможность обойтись механизмом свойств.
Поэтому особенно с конкретной реапусть сделает быстрее..
особо реализацией в статье не заморачивался - надо бы было код для позиционирования на свойствах и пр... А если чела подход устроил - уж соптимизирует как надо...
Спасибо за внимание к статье.
13. a_E (a_E) 24.03.09 03:03
а если потребуется прайс поэкономней печатать две колонки на страницу в альбомном формате к примеру тогда что? (1колонка-номеклатурный номер, наименование, цена) + разбиение по группам..
14. Сhe Burashka (CheBurator) 24.03.09 03:11
(13) а проблема в чем? делал такой для лавки семян, где позиций - мама не горюй, по группам, в несколько столбцов и т.д... если надо - хоть в виде книжечки - главное, чтобы работа была оплачена...
24. Олег Почекутов (PochekutovOleg) 21.11.11 16:09