7.7 Цена товара. Нестандартное решение

Есть переписанная конфа Юкола "Б/учет на предприятиях розничной торговли". Адаптирована для оптово-розничного предприятия. Устанавливали в начале года и сделали большую ошибку. Наименование товара не уникально, то есть по сути один и тот же товар может быть в нескольких элементах справочника, потому что были разные приходы и соответственно разные цены.
Сейчас подключил сканер ШК, для розничных магазинов написал конфу. Проблема в том, что практического смысла в штрихкодировании без уникального реквизита штрихкод нету.
Партионный учет не подходит. Пути решения 2:
- делать все реквизиты с ценами в элементе справочника "Номенклатура" периодическими,
- создавать подчиненный справочник "Цены", в который сохранять значения "Дата" и "Цена" и отбирать в документ уже именно в подчиненного справочника.
В любом случае переписывать довольно прилично, я все понимаю, но без этого никак, т.к. хочется реал-тайм видеть остатки на розничных объектах, вести учет в рознице количественно-суммовой (сейчас суммовой), привязываться в рознице к уникальному реквизиту "Штрихкод", сокращение времени инвентаризации (для ТСД интерфейс тоже практически готов) и т.д.
Позже будет дописана обработка, которая будет сама отслеживать минимальные остатки товара в рознице и формировать предварительную заявку. Это на будущее, но потенциал есть, есть куда расти.
При новом приходе товара товароведы выбирают уже существующий элемент справочника, ставят в приходе новую цену (если изменилась), при проведении документа создается документ "Переоценка товаров", в который выгружаются товары, по которым произошло увеличение учетной и отпускной цены и соотвественно формируются проводки на сумму переоценки на пополнение собственных оборотных средств.
В общем куча всяких "ништяков", но сейчас нахожусь на распутьи: создать периодический реквизит или подчиненный справочник?

Товары абсолютно одинаковые.
То есть у них на предприятии и раньше было так заведено в предыдущей программе. Пример: есть элемент справочника "Холодильник-ХМ32", цена поставщика его к примеру 10,000 руб. На складе было 10 штук, их продали, остатков нет. Через месяц опять приход тех же холодильников Холодильник-ХМ32 от того же поставщика, но цена поставщика уже 10,500руб.
В этом случае они заводят отдельный элемент справочника абсолютно аналогичный предыдущему за исключением цены.
Случается и такое, что в остатках могут числиться 2 одинаковых холодильника, но по разным ценам (разные элементы справочника), причем цены могут очень сильно разнится ввиду нашей нестабильной экономической ситуации и если торговый отдел вовремя не отследил приход и не сделал переоценку товара.

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

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

Это все понятно. С переоценкой проблем меньше, там можно все намного проще - товаровед приходует товар, который УЖЕ ЗАВЕДЕН в справочнике, по новой цене. Если на складе числятся остатки по этому товару - на счет учета товара относится разница между новой и старой ценой. Переписывается элемент справочника, в примечание добавляется № документа, по которому произведена переоценка. Тут все отработано и откатано.

Вопрос в топике: как проще поступить со справочником номенклатура - создавать подчиненный или делать периодический реквизит?

Поясню. В элементе справочника уже содержится цена производителя, цена поставщика, цена без ндс и с ндс, в подчиненном хранится розничная цена, поэтому необходимости подчиненного справочника "тип цен" нету.

Благодарю, значит я двигаюсь в правильном направлении

1) Создать реквизит, например, артикул, установить по нему уникальность и индексировать его.
2) выгрузить в ТЗ всю номенклатуру с остатками+код номенклатуры
3) в файле отсортировать по наименованию, выбрать из групп с одинаковым названием только ту, которая вам нужна. Если остатки висят на 2, то перекинуть с одной номенклатуры на другую остатки.
4) в 1с переместить неиспользуемую номенклатуру в отдельную папку и запретить выбирать ее в документах поступления, ну и так далее по списку
5) проставить оставшейся номенклатуре артикулы. Распечатать список и вручить тем пользователям, которые заводят номенклатуру, что бы они проверяли есть ли такая или нет.

Ну как бы цены реализации (опт, розница) там указаны можно сказать справочно, ибо окончательное решение об установлении того или иного процента надбавки принимает уже специалист по ценам уже непосредственно в ДОКУМЕНТЕ. Без его отметки, накладную распечатать нельзя. А создавать отдельные типы цен для каждого случая нужды нету, времени занимает больше, практической пользы никакой.

StarLight, спасибо за советы, но тут специфика своя. Артикул не уникален. В данном случае уникальностью могут обладать только внутренний код товара и ШК. Фильтровать справочник я уже придумал по другим критериям, "ненужные" элементы пока сложил в запароленную папку

Ситуация у нас неоднозначная на рынке, цены меняются чуть ли не каждый день, многие фирмы выдают счет-фактуры, срок действия которых 4 часа
Поэтому подстраиваемся под то, что изменить не в наших силах. Отдельные условия для конкретных покупателей, группировать их как-то нереально, ибо сегодня мы диктуем условия, завтра другие. При обороте в 6-7 тысяч единиц в сутки сами понимаете, чтобы только заполнять справочник цен надо нанять несколько людей и еще несколько, чтобы проверять то, как заполнен справочник
А так получается очень гибкое решение и требует минимум времени

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

Устроит, теперь я спокоен