Доброго времени суток уважаемые форумчане.
Столкнулся со следующей ситуацией. Клиент торговая фирма желает изменить систему ценообразования следующим образом.
Все продаваемые товары объединены по товарным группам. Например Кондитерские изделия или консервы. Товары в каждой товарной группе имеют
тип цен ОПТОВАЯ или РОЗНИЧНАЯ. Необходимо сделать систему при которой для каждого контрагента на различные товарные группы будет цена ОПТОВАЯ или РОЗНИЧНАЯ. Например на консервы РОЗНИЧНАЯ а на кондитерские изделия ОПТОВАЯ. В настоящий момент цена указывается в договоре с контрагентом. Соответственно у каждого контрагента несколько договоров. Например договор "кондитерка" цена ОПТОВАЯ, договор "консервы" цена РОЗНИЦА. Соответственно получаются несколько документов реализации контрагенту, на каждый договор один документ. Это естественно неудобно. Может быть уже есть готовые реализации подобной системы ценообразования для 1с77 ТИС, или может быть кто либо уже решал подобную задачу. Прошу поделится опытом или советом.

Знакомая картина. Мои бойцы лет пять назад делали такое. Надо будет поискать в архивах. Приподними ветку в понедельник, раньше не получится найти.

Делали, на регистре :)
Измерения товар, договор, тип цены
Так давно было, что подробностей не помню

автор - дятел.

> Необходимо сделать систему при которой для каждого контрагента на различные товарные группы будет цена ОПТОВАЯ или РОЗНИЧНАЯ. Например на консервы РОЗНИЧНАЯ а на кондитерские изделия ОПТОВАЯ.
- делается штатно.

> Соответственно получаются несколько документов реализации контрагенту...
- а какое отношение это имеет к поставленной задаче "для каждого контрагента на различные товарные группы будет цена ОПТОВАЯ или РОЗНИЧНАЯ."...? - здесь фигурируют контрагенты, товары и цены. Никаких реализаций здесь не упоминается.
.
включаем мозг и ставим задачу ВНЯТНО.
.
по всей видимости, ТС требуется возможность в одном документе реализации товаров по разным типам цен...
- ну так это, вообщем, тоже делается штатными средствами.
.
если это делается вручную -  то ничто не мешает подобрать товары сначала по одному типу цены, потом товары по другому типу цены (геморно, конечно, но можно). Программно документ можно вообще заполнить произвольно (проблемы могут быть только если учет по рознице и опту надо вести в разных валютах учета взаиморасчетов).
.
вторйо вариант: заведи тип цены, назови ее "оптоворозничная", на кондитерку заполни ее оптовыми ценами, на консервы - розничными (при таком построении реализации заполняются штатно, усложняется обновление цен на товары).
.
Все.
.
наименование типа цены к РЕАЛЬНЫМ ЦЕНАМ не имеет никакого отношения. исключительно для визуальности.
.
ну и в договоре вовсе не обязательно заполнять тип цен

(3) Предлагаешь плодить типы цен как кол-во типов цен*кол-во контрагентов?
Я понял что так нужно

(4) ну хз... можно (3), можно (2) - от частностей зависит

У меня такое реализовано, через документ установка цены (для согласования и истории) и справочник типы цен (подчиненый контрагенту)

еще придется поменять обработку по формирования цены, так как у тебя будет не фиксированный тип цен, а "цена клиента"

Основная задача чтобы одному контрагенту можно было назначить разный тип цен на разные номенклатурные группы. Есть идея доработать форму справочника контрагентов таким образом что бы в нем была некоторая таблица соответствий номенклатурная группа - тип цены. Таблицу хранить видимо лучше в регистре. Естественно  придется доработать процедуру определения цены. Вопрос быстродействия также не на последнем месте так как ежедневно формируется достаточно большое количество документов.

(8) Это тебе не 8-ка. Тут нет ТЧ у справочника и нет регситра сведений. Чем тебе подчиненный справочник контрагента не устраивает?

Собственно у тебя должно быть у контрагента:
Реквизит Тип цен - сюда задается общий тип цен, для тех групп по которым не указан тип цен
Реквизит Процент - в любом случае у тебя будет опт+5% Розница - 3%, поэтому без этого никак
Реквизит округлять цены - некоторые клиенты хотят чтоб точность была до копейки, типа 3р 59 коп, а другие хотят чтобы цены были "круглые" типа 3р 60коп. Вот ждля этого и нужен этот реквизит


Далее подчиненый справочник с реквизитами НоменклатурнаяГруппа (причем у меня можно задавать как конкретную позицию, так и свойство номенклатуры, как тебе надо - тебе виднее)
ТипЦены и Процент - тут всё понятно

Хм. То есть цены пересчитываются автоматически в зависимости какой установлен процент а не берутся из справочника цен на указанный тип цен?

(11) У меня да, правда у меня и цены хранятся в регистре, а не в переодике

Спасибо буду пробывать.

(0) В (3) тебе правильно диагноз поставили. Все что ты сказал уже есть штатно. Ничего переделывать ненужно.

(14) Нехрена там нет

А в (3) это гланды через одно место

штатно, это Тип Цен Контрагента Иванова, Тип Цен Контрагента Петрова, Типе Цен Контрагента Сидорова .... и так далее. И штат менеджеров, которые при изменении базовой цены будут пересчитывает эти цены

Вариант "ничто не мешает подобрать товары сначала по одному типу цены, потом товары по другому типу цены " ... ну попробуй распечатай прайс для Клиента Сидорова? В екселе будем собирать его из кусочков?

В моем случае менеджер готовит документ "Цены клиента" где устанавливает типы цен и наценку на группы товара, далее ЛПР утверждает этот документ и дальше пофиг на изменения базовой цены, у меня цена всегда актуальна, и используется везде, начиная от прайса для клиента и заканчивая ценами в документах. И даже если маркетинг поменяет оптовую цену, цена клиента автоматом поменяется. Более того ненадо помнить а на какую группу и что мы дали и какую скидку, всегда можно открыть карточку клиента и посмотреть актуальную матрицу цен для текущего клиента. Т.е. если завтра менеджер уволиться/уйдет в отпуск ненадо помнить, а какую же мы клиенту давали цену, всё уже в базе

В любом случае я бы не стал бросаться такими ярлыками, тем более когда не втеме, а просто рядом стоял

(16) Вы в (17) все правильно указали:
"штатно, это Тип Цен Контрагента Иванова, Тип Цен Контрагента Петрова, Типе Цен Контрагента Сидорова .... и так далее."
Это как раз штатное решение.
И документ в (18) это лишь удобство разруливания (установки) цен. Опять таки - штатно это документ установки цен (название может отличаться). И да, штатный механизм его заполнения весьма убог, поэтому ничто не мешает вынести нужный функционал в обработку и ею уже заполнять документ.

"... я бы не стал бросаться такими ярлыками, тем более когда не втеме, а просто рядом стоял"
Ну да, ну да. Сами мы не местные, и 1С видели только издалека. Спасибо, повеселили.

А теперь возьмите в руки отладчик и померяйте какой вариант будет в расходной отрабатывать быстрее.

(19) И заодно посмотри сколько данных будет хранится в ИБ

(19) Цена для контрагента, она так и будет ценой для контрагента - куда бы вы её не прятали.
Если не нравится штатно "Тип цен для контрагента" (с автоматическим пересчётом от базовой цены - тут немного поколдовать, чтобы можно было указать, где розничная, где оптовая), то можно сделать отдельный справочник, где указывать применение типа цены.
Но, если мы хотим штатный подбор в накладную (причём, контрагенту и вам удобнее, чтобы все товары были в одной накладной, если, конечно, у вас не разные договора на разные группы товаров - что достаточно странно, так как цены должны зависеть от объёма и устанавливаться дополнительными соглашениями).
Теперь, если есть справочник цены контрагентов, то значения в нём будут обновляться только в момент изменения цены на какой-то товар. В момент подбора же цены мы просто берём значение из этого справочника (документа или регистра). Получается быстрее. Всегда можно собрать прайс для определённого контрагента.
Но, если контрагентов много, и они приходят редко, а цены меняются часто, то будет выполнение множества лишних действий по изменению цены контрагента, хотя она реально использоваться не будет. Тогда проще хранить не саму цену, а правила её определения. В этом случае, если розничные цены не для кого не меняются, мы можем хранить только условия применения специальной цены - причём, менять их от объёма закупленного. Но, в этом случае, при подборе товара придётся выполнять алгоритм расчёта цены.