Насколько я понял, цена в 1с устанавливается для конкретной номенклатуры, а если точнее, то номенклатура+характеристика. Бывают случаи, когда на одну и ту же номенклатуру нужно установить несколько цен, в зависимости от поступления товара и продавать по этим ценам. Я много раз натыкался на обсуждения подобного вопроса, но, как правило, народ просто не понимает зачем такое может понадобится и до конкретного ответа не доходит. Такое нужно, например, в аптечном бизнесе. Если номенклатура пришла по 100 руб, то розничная цена 100+20% наценка = 120, а если по 95, то 114. И в итоге, как бы это не казалось странным, один и тот же товар будет продаваться в торговой точке по двум разным ценам - 120 и 114 руб. Так надо, требование бизнеса.

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

Остается только вариант с доработками. По этому поводу смог найти только вот такое:

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

Опыт таких изменений уже существует - я видел много случаев когда цены назначались каждый раз на конкретную партию или серию. Например, в аптечном бизнесе такое практикуется.
Это дописка.


http://www.subsystems.ru/forum/forum3/topic479/

Только непонятно, как такую доработку сделать. Первое, что приходит на ум, добавить серию в регистр ЦеныНоменклатуры, а в серию писать некий идентификатор. Но мне совершенно непонятно как такая доработка отразится на существующем функционале. Я точно знаю, что в других системах такая задача решается достаточно просто, а в 1с не пойму как сделать. Городить что-то не очень хочется, хотелось бы понять как добиться желаемого и при этом стандартный функционал не сломать.

Подскажите, как можно минимальными доработками добиться того, чтобы можно было установить разные цены на одну номенклатуру в разрезе серий, например?

Последний выдох ГПЖв серию - как-то "широко" будет... надо совать в партию.

по крайней мере в еФарме цена была в партии.

зы а типовые решения для аптек от 1С - дрянь...

в Протеке хотя бы понимали что они делают и для кого (до поры до времени)

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

Мне бы хотелось разобраться что куда нужно добавить чтобы цены на партию устанавливались, а не на номенклатуру. Пусть даже не конкретно что и как дорабатывать, а хотя бы общий принцип. Ведь раз пишут, что это делается, значит можно это сделать в 1с, вот только как?

Последний выдох ГПЖ
но без конкретики что куда и зачем - это все сфер. конь в вакууме

Конкретика. Для простоты рассмотрим только одну номенклатуру. Приходуется товар от разных поставщиков в разное время.

От поставщика1 100 шт по 95 руб
От поставщика2 50 шт по 97 руб
От поставщика3 50 шт по 100 руб

По некому алгоритму рассчитывается ЦенаОтгрузки = ЦенаЗакупки+Наценка. Следовательно получится три цены отгрузки. Потом к цене отгрузки применяются скидки, но это пока не важно. Если просто оприходовать 200 шт, то будет непонятно, сколько штук можно продать по какой цене.
Что нужно сделать чтобы было понятно какой товар по какой цене был оприходован?

Понятно, что есть несколько вариантов, мне хотя бы один понять. А то что-то вообще не понятно с какой стороны подойти.

Вопрос, на самом деле возник от того, что утверждается, что эту проблему в 1с можно решить только через характеристики. Что-то не верится, если честно.

ShuhardLucky_13что утверждается, что эту проблему в 1с можно решить только через характеристики. Что-то не верится, если честно.
не верь - твоя проблема

Доказательства можете привести, что в 1с такое сделать можно только через характеристики?

Владимир ЛазуркоЕсли как в примере надо считать продажную цену от четко определенной поставки, то имеет смысл в регистр цен добавить связь по партии, а не только номенклатура/серия/характеристика.

Можно с этого место по подробнее. Серии в регистре цен, насколько я знаю нет, есть только номенклатура/характеристика/тип цены. Если бы там была партия, то я думаю это бы помогло.
Но вопрос, если добавить партию в регистр, сколько еще доработок потребуется? Не получится ли так, что после этого придется еще кучу всего переделать? Или это нормальная практика в 1с, когда добавляется что-то в регистр и все остальное работает как обычно?