Требуется подсказка от гуру 1С. Задача следующая.
1. Есть товар (количество товара 50-60 тыс.шт. в год) на который при поступлении на склад навешивается баркод, товару присваивается ряд характеристик (7 штук).
2. После товар собирается в партии и происходит его отгрузка покупателю.
3. У покупателя происходит изменение этих характеристик и добавляются еще 2. Одновременно с этим формируется цена.
Необходимо контролировать сколько, когда и какого товара (пришло/ушло/продалось) и какие характеристики были/стали (старые не переписываются, а сохраняются).
Сейчас я реализовал это в виде справочника в который записаны баркоды и все характеристики (в виде реквизитов). Движения записаны так же в реквизитах (т.е. ссылка на документ присвоения/отгрузки/продажи). Контроль за целостностью (чтобы не удалить уже проданный баркод) реализовано при проведении документов. Но все это жутко неудобно, громоздко и медленно работает. Отсюда вопрос. Может есть в 1с иной механизм удобно реализовать подобное? 1с 8.3

Ни у кого нет идей или нет желания подсказать? Может я сформулировал как то не так?

Вы одновременно ведете учет и у поставщика, и у покупателя?

(2) В одной базе и по одному контрагенту :))))

(3) и все это делает один человек

(4) Голосовым управлением

Обычно под отгрузкой понимают переход права собственности.
В этом случае п.4 противоречит самому принципу коммерческой сделки
Следовательно можно предположить что покупатель никакой нафиг не покупатель а коммтсионер\агент\подобноечтото

Назачем менять характеристики?

Соответственно имхо в тс написана какая-то хня или вечьмавесьма специфическая область деятельности

По нулевому посту естьиподозрение что автор не знаком с концепцией регистров сведений и накоплений и ведением учёта по характеристикам - то есть то, что реализовано в типовой УТ

(2) Нет учет у поставщика.
(3) База одна, но поставщиков не один.
(4) Это проблема?
(5) Сканером штрих кодов, в основном.
(6) Покупатель это действительно не покупатель, а коминтент. И отгрузка здесь это отправка к коминтенту для дальнейшей продажи товара на аукционе, поэтому и цена возникает после отгрузки. Я об этом не стал писать, чтобы не загромождать лишним. От этого сама суть вопроса не меняется.

(10) имхается вы путаете комитента и комиссионера\агента.

Почему не хочешь писать все это в РС? Там же быстрее будет происходить. А громоздким оно у тебя будет всегда, А вот в скорости РС будет лучше справочника

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

(0) Изучить основы "партионного учета" и способы реализации.

(11) Я и еще поставщики поставляем товар на аукцион, а он от нашего имени это продает. Так будет точнее.
(12) РС это регистры сведений?

(14) А реализовывать в 1С с помощью чего?

(14)+ Фактически выделите самую мельчайшую неделимую единицу товара которая отличается от других подобных.

Это и есть минимальная партия, далее ведите учет в них. справочник "Номенклатура" и прочее это группировки для "Партий".

Иногда если группировки не нужны есть смысл сделать Партия=Номенклатура и по сути на каждую новую "партию" (строка-позиция накладной документа поступления) заводить новый элемент справочника Номенклатура.

(16) Справочник самое оптимальное, просто во всех документах/движениях должна быть ссылка на него.

У вас тормоза из за 3-й связи между сущностями  путем штрихкодов. Вместо того чтобы напрямую сущности связывать.

(17) У меня КАЖДАЯ единица товара важна. Т.е. нельзя объединить даже 2 шт. вместе. Учет ведется побаркодно.

(19) Ювелирка?

(20)+ Ну так и заводи на каждую эту единицу новую номенклатуру со своим весом и прочими характеристиками ))

И в ней доп.реквизитом если она произошла (была произведена из) от некой другой номенклатуры

(18) У меня в справочнике ссылка на документ, а не наоборот. В документе может быть 15-20 тыс баркодов. А без штрих кода вообще ничего не выйдет. Так как аукцион по продажам отчитывается как раз по баркодам.
(20) Нет, пушнина.

(22) ИМХО, не правильно. У тебя (все-таки) справочник. Только слегка специфичный.

(22) Пофиг, пушнина в принципе тоже самое, уникальные изделия каждое со своими характеристиками типа вид животного, площадь, качество и т.д.

Эти характеристики либо перечислимые (выбираются из справочника, перечисления), либо числовые/строковые. Вот и прописывай их для элемента номенклатуры.

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

(21) Я так и сделал. У меня программа уже 5 лет работает. Просто каждый раз когда смотрю на все это безобразие (на код) то хочется переделать. Вот и спросил может я неоптимально изначально все сделал. Я сейчас прикрутил к базе HTTP клиента, так вот некоторые отчеты секунд по 30-40 делаются, а у Веб пользователя создается ощущение что все повисло.

(24) Вот ровно так все и есть. )

+ (23) Не вникая в подробности учета: поступление (практически, типовое) - перемещение (обрастает всякой фигней - тут пилить и сильно, а может и свой док-т сделать) - реализация (сама продажа)

(25) Переделай это на новую типовую конфу (на 8-ке УФ) и все, на том же принципе только чтобы не остаться как раньше на 77 в аутсайдерах.

(25) Тогда откуда ссылка на документ?

(23) А что неправильно?

(30) В документе ссылка на элемент справочника. А не наоборот.

(29) Ссылка пихается при проведении документа. И проведение иногда по две мин из за этого висит. (

(30) Скажи, а движения товара по справочнику смотрят?

(28) У мня написано с 0 на 8.3 в УФ.

(33) Да.

(32) Эээ у тя что подбор конкретной номенклатуры идет при провдении документа?
А не при добавлении строки в документ движения (перемещение/расход)?

(35) Капец... Видела я такие контейнеры... Убила бы...
Переписывай!!!!

(33) Так быстрее. Потому что у товара есть еще реквизит поставщик и сначала нужно по нему отобрать.

(34) Не было смысла, те можно было любую конфу торговую использовать (УТ11, Розница 2.2) и даже БП3 типовую

(37) Я так и не понял, а как сделать то?

(40) Не обращай на нее внимания, ей просто внимания не хватает хотя она ничего не поняла ;)

(36) Когда делается например отгрузка на аукцион, то просто открывает документ и сканируем товар, в ТЧ пихаются ссылки на справочник, если надо то меняем или добавляем цену например. При проведении документа берем ссылку на справочник и в ней меняем параметры и записываем ссылку на документ. Документов всего 3 и у каждого баркода может быть только один документ отпределеного типа (т.е. 3 реквизита у справочника)

(40) Структура должна быть: справочник -> документы -> отчеты.
Даже если товар уникален, все равно это справочник.

(42) Понял тя, тормоза из-за перезаписи элементов справочника при проведении документа.

(39) В типовой много лишнего понаворочено, а тут все только нужное.

(44) Ага. Из за них. В замере производительности проверял. 70% всего времени.

(41) Была конфа "Контейнерные перевозки" (ну, типа того).
Все построено на справочнике. То есть движение контейнера отражается в справочнике.

А теперь сам подумай...

(42) Один баркод -> три документа -> изменения в отчете.
А не три реквизита у справочника.

(46) А писал сам или по типу чего-то?

(43) Но у меня 1 элемент справочника 1 документ отгрузки/продажи. А в документе 20 тыс. записей причем разных поставщиков и для перебора, например в запросе, один фиг сначала надо по справочнику отобрать. А так придется потом еще делать какое нибудь соединение к документам (перебирая десятки тысяч ненужных записей)
То что выглядит это все криво я и сам знаю.

(49) С чистой базы. Все сам кроме подключения сканера. Его из типовой выдрал.

(42) Убери запись ссылки на документ в элемент справочника, это не надо.
При необходимости это запросом легко найти.

(48) Изменения в отчете это о чем? Я не очень понял.

(53) Изменения по товару: пришел, ушел, когда, за сколько.

(52) Там кроме ссылки еще и параметры записывать нужно (новая сортировка, цена и.д.). Так что ПолучитьОбъект/Записать все равно делать.

(54) пришел/ушел это больше справочная информация основные данные в реквизитах справочника (цвет,сорт,дефект,размер,седина,тон,оттенок и т.д.) по ним и собираются отчеты.

Т.е. Регистр сведений тут вряд ли подойдет?

(55) А! Вот если записываешь новое то не пиши в ту же номенклатуру!

Создавай новую номенклатуру, причем не в момент проведения а перед при заполнении документа-добавлении строк. И ссылку тута на прежнюю...

(56) xxx: Стройбат ФЛОТА? Это, наверное, что-то совсем опасное)
yyy: Это когда заставляют копать не землю, а воду... На два метра в глубину...

(57) РС это если периодика нужна или изменения по времени.
Можно реквизиты которые меняются для номенклатуры туда выносить.


Типа была шкура целая, а стала облезлая вот периодический РС тут в тему.

(58) Дак у меня тогда удвоится все, а это десятки тысяч записей. И для чего это делать? По сути то товар как был один так и остался. Мне нужны как раз отчеты о его "трансформации", а увязывать потом два разных справочника мне кажется излишним.

(61) Ну тогда дели справочник на неизменяемую часть справочник и изменяемые характеристики в периодический РС.

(60) Не совсем меняются, они дополняются. Т.е. был най размер Крупный, а на аукционе стал XXL (но "старый" размер как был так и остался).

(60) Есть 2 размера, 2 цвета, 2 дефекта.

Суть когда планируешь архитектуру конфигурации попробуй рассмотреть-прописать все варианты что будет.
Не будет ли тут тормозить и а как будем получать вот эти сведения?
Очень помогает.

(63) Понял, пофиг можно и в ТЧ справочника это оставить, но убери это из проведения документов.

Я когда писал так и делал, вот только может чего упустил по незнанию 1С. Раньше я с 7.7 работал.

(66) *в реквизитах или в ТЧ справочника

(61) Не, чукча не читатель :)
Товар один, а изменение (вся твою лабуда) - это РС. Запись в РС создается док-том. И потом в отчете собираешь записи РС по товару.

(66) А отгружен/продан или нет баркод каждый раз в запросе проверять?

(69) Попробую еще раз посмотреть на РС. Уже и не помню почему тогда его не выбрал, что помешало.

(70) Короче могу сказать только одно ))

Пойми вот этот твой уникальный самодельный лисапед делается за несколько дней по 2-3 часа в день на типовой конфе типа УТ/БП ))

Суть что уже есть требуемый функционал на 90% и допилить небольшой кусочек по доп.реквизитам и все.

Добавив удобные обработчики для быстрого ввода и заполнения документов/справочников.

К примеру тыкнули в типовом документе "новая строка" и открылась своя форма для ввода строки. Тыкнули по строке 2 раза "изменить" открылась формочка редактирования характеристик.

(72)+ Но чтобы это сделать сначала надо типовую конфу и их функционал изучить а это пару месяцев может не хватит.

(73) Зато у меня грузиться быстро! )
Согласен может так и проще было сделать, но теперь как мне кажется все то, что уже занесено будет довольно таки долго перетаскивать на типовую. Да и по работе все устраивает на 100% (кроме скорости и уродливости реализации). А будет ли а типовой это все сильно быстрее? С такими документами.

Спасибо всем за участие. Попробую посмотреть в сторону РС.

(74) "грузится быстро" это не та проблема на современных компах даже ERP2 в режиме предприятия весьма шустро шевелится

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

(76) Кассы точно не понадобятся. А учет оплаты как раз сейчас делаю.

(77) "Кассы точно не понадобятся"
это пока... хотелки растут на лету, сча при опте оплата наликом ККТ нужна

И вот в типовых "учет оплаты" давным давно есть, докрутить отчеты на СКД это простейше до требуемого вида.

(78)+ Смотри разрабатывать "свой автомобиль" (нетленку) есть смысл только если авто сильно специфичный и нельзя обойтись приобретением и обучением вождению типового.

Ну или легким "тюнингом" типовой конфы, в крайних случаях пишут свои "прицепы".

Вот если к примеру куча рабочих мест (под 100+) или ограниченное железо, или еще некие причины типа реализуемого функционала нету ни в каких типовых даже частично, тогда да есть смысл писать самописку.