gifts2017

Ценообразование - задача и решение (несколько прайсов для товаров)

Опубликовал Максим Красовский (noook) в раздел Программирование - Практика программирования

Цель - автоматизировать ценообразование организации
Задачи:
- ускорить процесс переоценки всей номенклатуры
- избавиться от человеческого фактора в расчетах и перерасчетах
- сделать так, что бы внесения изменений в конфигурацию были минимальны и осталась возможность обновления без потери данных
- создать простой механизм

ЗЫ
Извинюсь сразу перед теми, кто не поймёт что то - срашивайте и не стесняйтесь.
Я не программист 1С, я больше сисадмин, но с 1С работал много, в частности с 7.7 версией.

Последнее время переквалифицируюсь на управленца и сейчас вообще админство заброшено.
Бизнес консультирование и управление заняло основное время (готовился к этому и учился 7-8 лет самостоятельно).
Хочу рассказать про (при внедрении 1С 8) решение одной из задач, которых нет в стандартной поставке 1С и естественно в яндексе тоже нет, все решают кто как может.
Я решил это так и старался расписать тут это подробно.

Текст связан с ценообразованием, типами цен, ценами на товары, справочником номенклатура, изменениями курса доллара.
Все фамилии и цифры вымышлены, дабы показать общность процесса и скрыть "реальные бизнесс секреты".

Моя ситуация упращалась тем, что главный продавец работал в фирме, был ответственным и внимательным, поэтому на первых порах все возникающие ошибки
ручного ввода (а ручной ввод конечно был на начальном этапе) минимизировались четким взором этого внимательного человека.
Так же я прибег к услугам программиста 1С для быстрого создания обработок, которые мне были нужны.

Цель - автоматизировать ценообразование в организации.

Задачи:
- ускорить процесс переоценки всей номенклатуры.
- избавиться от человеческого фактора в расчетах и перерасчетах.
- сделать так, что бы внесения изменений в конфигурацию были минимальны и осталась возможность обновления без потери данных.
- создать простой механизм.
- перейти с 1С 7.7 на 1С 8.2 безболезненно за минимальное количество времени(побочная цель ;-)

Входные данные:
1С 8.2 Комплексная, устоявщийся способ расчета цен на товары и способ внесения в базу, полученный список групп товаров.
Организация - малый и средний бизнес.

Первоисточник:
Была 1С 7.7 Комплексная, цены менялись руками на каждый товар в случае смены входной цены ИЛИ курса доллара,
цена DDP это цена входящая в долларах, остальные цены в рублях. Количество товара около 2 тысяч позиций в справочнике.

Существовали такие типы цен: "DDP, спец, пр1, пр2, пр3, опт, розница".
Я решил добавить ещё парочку и получился такой список в порядке возрастания цены:
"DDP, закупочные, минимальная, спец, пр1, пр2, пр3, опт, розница".

Закупочная - это цена DDP, но в рублях на дату курса валюты.
Минимальная - это цена ниже которой будет не выгодно продавать вообще, и для того, что бы её внести в настройки пользователей минимальной цены,
точнее что бы по ней контролировать продажу в убыток (процент наценки я посчитал вручную сам, по предыдущим периодам работы организации).

Ценообразование строилось таким образом:
Были товары в справочнике Номенклатура, каждый товар мысленно относился к какой то группе товаров,
которые так же мысленно были в голове у начальника и главного продавца.
Цена предыдущего типа цены отличалась от следующего на сколько то процентов.
Тут было у меня 2 желания: сделать либо просчёт цены от входящей цены, либо от предыдущего типа цен как устоялось.
Начальник дал наценки только от предыдущего типа цен, я же вычислил от входящей, но получились "некрасивые" проценты, например 12,56% (от входящей).
Я решил, что некрасивыми цифрами оперировать сложнее и перерасчеты менее точные получатся, поэтому второй вариант отпал.

Ситуации когда нужно было переоценить товар:
1) При смене курса доллара цены менялись все ибо DDP цена была именно в долларах и не пересчитывалась от какой либо.
Ввели внутренний курс и округляли до целого числа, что бы не пересчитывать каждый день цены по РБК.
2) При смене входной цены (она DDP).

В итоге получил от начальника такую вот таблицу, я её прозвал "матрица цен":

  спец прайс1 прайс2 прайс3 опт розн
группа1 2 6 4 8 5 6
группа2 3 3 2 2 6 3
группа3 5 6 6 3 4 4
группа4 2 3 6 8 7 8
группа5 6 3 8 5 8 9
группа6 3 6 2 4 3 4
группа7 6 7 4 3 3 5
группа8 5 4 5 2 2 3

 

В этой таблице видно что существуют группы товаров и на каждую может быть своя наценка от предыдущего типа цен.
Эту таблицу я доработал, что бы были ещё те типы цен, которые я добавил сам.

Например, товар из группы "ГРУППА1" имеет наценку 3% от входящей и это получается СПЕЦПРАЙС, ПРАЙС1 считается добавлением к СПЕЦПРАЙСу 5%,
ПРАЙС2 считается добавлением 7% к ПРАЙС1 и так далее в этой группе "ГРУППА1". Для других аналогично, но проценты другие.
Такое в стандартной конфигурации не решается.

В 1С для этого я задействовал справоник Ценовые группы, внёс туда все группы товаров.
Попросил продавцов проставить в каждом товаре поле "Ценовая группа", НО можно было и задействовать для этого "Груповая обработка справочников и документов".
Теперь задача как связать эти группы с процентами типов цен, ведь нет места где можно хранить проценты.

Программистом был создан Регистр сведений "Матрица цен" с измерениями ЦеноваяГруппа, ТипЦены, БазовыйТипЦен и ресурсом ПроцентНаценки.
ТипЦены это цена которую расчитываю, БазовыйТипЦен это цена на которую добавляю, ПроцентНаценки это то сколько добавляю.

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

группа1 закупочные DDP 0 (здесь нужен НОЛЬ для того, что бы перевести доллары в рубли, а это просто перерасчет валют)
группа1 минимальная закупочные 2
группа1 спецпрайс минимальная 3
группа1 прайс1 спецпрайс 5
группа1 прайс2 прайс1 7
группа1 прайс3 прайс2 9
группа1 опт прайс3 11
группа1 розница опт 13
и так далее столько таких записей сколько групп товаров

Что имеем:
Номенклатуру, проставленные в ней поле "Ценовая группа", заполненную "Матрицу Цен", правильный курс доллара, осталось понять сам процесс КАК будет делаться цереоценка.

В 1С стандартно есть такой документ "Установка цен номенклатуры", в нём есть возможность ставить цены на товары.
Разобравшись с этим документов решил использовать его, но с дописанной возможностью прикрученной внешней обработкой заполнения табличной части.
Обработку написал программист, я её назвал "обработка таблицы по матрице цен"и добавил в кнопку ЗАПОЛНИТЬ.
Обработка сама пробегается по записанному документу и проставляет цены (заполняет ячейки) относительно матрице цен.
В этот документ можно внести номенклатуру руками или выбрать стандартными средствами по разным критериям.
Перед внесением товаров в табличную часть нужно обязательно выбрать типы цен с которыми нужно работать.

ОКОНЧАНИЕ:
Теперь процесс изменения цены быстр и прост.
1) Ставлю в валюте USD внутренний курс на день переоценки - будет использоваться при просчетах.
2) Выбираю номенклатуру всю или какую то группу.
3) Делаю пересчёт по матрице цен, если это переоценка изза изменения курса доллара ИЛИ вношу новые DDP цены, если это изменение входной цены.
Обычно у нас входные цены могут меняться раз (максимум два) в год.
4) Провожу документ и готово - новые цены изменены на всю выбранную номенклатуру.
5) Написал памятку как пользоваться - отдал ответственному лицу.

Задача решена.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Александр Зубцов (iov) 16.10.12 20:11
(0)
как вам матрица с таким раскладом - процент или фиксированная цена устанавливается на
группу контрагентов/контрагента/договор/тип цен документа/группу номенклатуры/номенклатуру/характеристику/время действия (относительное и абсолютное).
все это в иерархии и с разными приоритетами. А закупочные цены меняются только если они попадают в определенную вилку разрешенных изменений. Всё это рассчитывается автоматически согласно сезонности/объемов продаж/количеству возвратов(компенсация потерь). Дорого - очень производительность резко падает на операциях расчета цен - но результат попадание в рынок по 90% номенклатуре.
2. Максим Красовский (noook) 17.10.12 06:20
(1) iov, в Вашем случае я бы использовал нечто другое, чем матрица цен
думаю, что
_если взять "на группу контрагентов/контрагента/договор", то использовал бы доработку справочника + обработка в документе
_если взять "на тип цен документа/группу номенклатуры/номенклатуру/характеристику", то использовал бы использовал бы как то регистр, но мысль про матрицу моя бы не подошла
если взять "время действия (относительное и абсолютное)", то тут бы только использовал бы только доработку в документе
А у Вас уже действует то, про что Вы говорите?
3. Александр Зубцов (iov) 17.10.12 13:20
4. Андрей Казанцев (ander_) 19.10.12 09:17
(3) iov, какое примерно количество позиций номенклатуры, типов цен?
5. Андрей Казанцев (ander_) 19.10.12 09:19
noook, управленческий учет в какой валюте ведется?
6. Максим Красовский (noook) 19.10.12 09:25
(4) ander_, номенклатура более 1000 товаров, могу сказать точно если интересно
типов цен как в статье, то есть 9 штук + плановая себестоимость (типовой тип цен)
учет ведётся в рублях ибо мы в РФ живём, но много отчетов нужно и в долларах
7. Андрей Казанцев (ander_) 19.10.12 10:05
Вопрос.. наверное ко всем. Может есть идеи как быть в случае если нужна подобная гибкая схема, т.е. хранить и крутить процент от входа (ну или другой, возможно хитро рассчитанной базы), с возможностью указания накруток по каждому типу цен с точностью до товара. Но при этом номенклатуры от 100000 позиций...
8. Михаил Ражиков (tango) 19.10.12 10:15
+ за подход.
но тема, в общем-то, не раскрыта
9. Михаил Ражиков (tango) 19.10.12 10:16
10. Михаил Ражиков (tango) 19.10.12 10:20
автор, поправь орфографию, пожалуйста
тема актуальная, орфография нужна.
**
"Минимальная - это цена ниже которой будет не выгодно продавать вообще" - улыбнуло - "Умру, но не продам дешевле"
:)
11. Михаил Ражиков (tango) 19.10.12 10:23
...и добавил в кнопку ЗАПОЛНИТЬ.

эта ваще пять
12. Михаил Ражиков (tango) 19.10.12 10:26
Ставлю в валюте USD внутренний курс на день переоценки

собственно, вся байда именно в этом - определить "правильный курс", вся остальная фигня - два часа с клавой
13. Александр Зубцов (iov) 19.10.12 10:50
(3) 2500 позиций 20 типов цен
14. Александр Зубцов (iov) 19.10.12 10:59
(7) встречал примерно 6 разных решений. Если цены надо проставлять автоматически сразу на большую группу товаров- ничего не подходит. прайс формируется по несколько часов на 2000 наименований. Есть решения с использованием хранения во внешней базе с расчетом раз в сутки. В общем гибкость цен = тормоза в базе.
15. Максим Красовский (noook) 19.10.12 11:00
(12) tango, тема не раскрыта - понял, что нужно добавить? какие процессы описать подробнее?
Про текст - пытался писать с юмором. Орфографию где поправить?
У нас внутренний курс "задаёт" директор, поэтому тебе будет 2 часа + 1 минута общения с директором )))
16. Максим Красовский (noook) 19.10.12 11:01
(14) iov, В общем гибкость цен = тормоза в базе
это да, при большом количестве критериев и категорий
17. Александр Зубцов (iov) 19.10.12 11:08
(16) К сожалению у меня расчет цены на 1 позицию может до 2 секунд выполнятся (с учетом расчета средней маржы по документу)
18. Михаил Ражиков (tango) 19.10.12 11:54
(15) noook, два часа - я имел ввиду на реализацию сабжа.
"по несколько часов на 2000 наименований" (14) - это я даже не знаю как комментить. гг студенты писали?

(17) -
на 1 позицию может до 2 секунд
- можно кусок кода в студию?
19. Максим Красовский (noook) 19.10.12 12:13
(18) tango, я понял что на реализацию сабжа
20. Александр Зубцов (iov) 19.10.12 13:32
(17) со всем уважением - нет. условия контракта не позволяют. да и не я писал.
Основная суть тормозов - не удавалось получить в запросе нужные данные...
Про оптимизацию я соответственно знаю - но это не моя задача.

а расчет на 2000 позиций - это уникальные прайсы для клиента со всеми правилами. (на мой взгляд можно сократить вполовину - но тут надо будет исправить ошибку в архитектуре БД а это уже отдельная песня...)

Да и я не претендую на супер код - просто говорю что уже есть и как работает. Моя хата - производство - пока руководителей устраивает формирование цены - трогать не собираюсь (альтруизм в этом деле - враг).

Я лелею надежду написать статью - для решения проблемы "всем миром" и получения оптимального механизма/алгоритма
который пользователи инфостарта смогут использовать уже дальше. Но время - искусный враг.
21. Андрей Казанцев (ander_) 19.10.12 16:07
(9) tango, ага :)
интересны идеи, ибо вскоре планируется перенос управленческой базы на 8Х. Сейчас реализовано на 7.7 с 1с++, справочник 120т позиций, чуть более 10 типов цен. Все что нужно хранится в 1с (фактически - это правила), а на основе этих данных триггерами обновляется максимально развернутая (для быстродействия) матрица накруток. Так вот вопрос: то-же самое придется делать и 8-ке? или все-таки может есть идеи получше?
22. Михаил Ражиков (tango) 19.10.12 16:23
(21) ander_, держать матрицу в отдельной таблице, можно в той же базе, но созданной не конфигуратором. и средствами же скл ее пересчитывать
23. Михаил Ражиков (tango) 19.10.12 16:24
+(22) это как бы бесплатная идея
24. Александр Зубцов (iov) 19.10.12 16:28
(22) Работали с такой схемой - нормальная схема только с одним важным условием обновление цен - раз в сутки иначе как только меняю цены -тут же пытаются их использовать - но сама технология даже где то на этом сайте была.
25. Михаил Ражиков (tango) 19.10.12 16:35
(24) iov, а если сделать ее где-то в темпе, то, наверное, можно даже будет обращаться к ней как 1сной временной
26. Александр Зубцов (iov) 19.10.12 17:04
(25) вопрос в том что 2500 -4000 номенклатуры * 2*количество контрагентов * типов цен * кроче таблица огромная... я пробовал.. 4 раза кончал сервер по памяти вешал...
27. Александр Зубцов (iov) 19.10.12 17:06
(25) Я себе пометил - как только напишу статью - приглашу на обсуждение решения...
кстати в Питер ждать 15-16 ноября? Я бы не отказался лично пообщаться.
28. Михаил Ражиков (tango) 19.10.12 17:09
(27) iov, весьма польщен. но я там был по весне уже :)
пс: кепочку вот купил
29. Александр Зубцов (iov) 19.10.12 17:21
(28) Я настаиваю - приезжайте тут будет много 1снегов в лицо всех будет возможность запомнить на всякий случай.
На конференцию я думаю вопрос с проходм я решу.
30. Михаил Ражиков (tango) 19.10.12 17:28
(29) iov, меня управляющий не пустил даже на московскую инталевскую тусовку (они там про КиПиАй что-то парят)
типа за свой счет - пожалуйста... гы
реально жаба душит за каждый дневной получк
31. Александр Зубцов (iov) 19.10.12 17:37
(30) меня тоже не пускали - напомнил что они минимум 7 дней отгулов задолжали. Ну тогда летом велкам в Питер...
Летом мы регулярно вечерне ночные фото прогулки устраиваем я думаю Доржи тоже присоединится- он теперь тоже фотограф... В общем коньяк обещаю - фото не обещаю. :)
32. Михаил Ражиков (tango) 19.10.12 17:43
33. Михаил Ражиков (tango) 19.10.12 17:43
34. Андрей Казанцев (ander_) 20.10.12 07:19
(22)(23) tango, спасибо. В (21) об этом и писал, только не уточнил что "матрица" создана не средствами 1с (по-другому бы на таких объемах и не взлетело). Т.е. такой вариант уже был реализован, и работает. Просто думал, может еще какие очевидные варианты имеются.
35. Андрей Казанцев (ander_) 20.10.12 07:22
(24) iov, для этой цели удобно вешать триггеры на таблички влияющие на цену. Как только изменился один из параметров - пересчитываем соответствующие цены (естественно не все, а только те, которых это касается). Тогда всё работает практически в реалтайме.
36. Александр Зубцов (iov) 20.10.12 13:10
(35) Из-за объемов данных + из-за необходимости хранить историю изменения + время просчета слишком длительное +
изменения вносятся несколькими людьми и они могут вносить изменения в одной группе даже в подчиненных элементах , треггеры не использовались. Я тоже об этом подумал про них как увидел все это...
37. Максим Красовский (noook) 22.10.12 10:41
приятно у себя читать умных людей
спс Вам