1С 8.1. УТ 10.3.
Документ - "Поступление товаров и услуг".
Задача: заносить в свой регистр данные о поступающий товарах от контрагента, регистр не периодичный, нужно просто, чтобы там хранилась информация о том, что когда-либо поступало от контрагента, без дублирования.
Создаю свой регистр сведений - "ТоварыНаПоступление".
В нём 2 измерения - Контрагент и Номенклатура.
В модуле "Поступление товаров и услуг" в процедуре "Обработка проведения" добавляю:

Движения.ТоварыНаПоступление.Очистить();        
Для Каждого Товар Из Товары Цикл
   Движение = Движения.ТоварыНаПоступление.Добавить();
   Движение.Контрагент = Контрагент;
   Движение.Номенклатура = Товар.Номенклатура;
   Движения.ТоварыНаПоступление.Записать(Истина);
КонецЦикла;    

В итоге при попытке проведения ещё одного документа с таким же контрагентом и номенклатурой выдаёт ошибку о дублировании записей.
Хотелось бы, чтобы он или заменял их или даже не пытался записывать.
Мне нужно проверять наличие такого контрагента-товара перед проведением? Или какими-то простыми настройками можно этого добиться?

Тебе нужно проверять

добавь измерение Поступление

(2)
Так он для каждого поступления будет дублировать номенклатуру?
Не хотелось бы этого. Такой же я результат могу получить из регистра ТоварыНаСкладах, выбрав только приход.
Хотелось бы, чтобы был самый шустрый регистр.

пара вариантов:
1. сделай регистр независимым и допиши обработку удаления движений при распроведении.
2. сделай оборотный регистр накопления

(0) В чем сложность проверки?

Наложи отбор, прочитай. Если там есть твои данные, то продолжить,

(4) Нахера оборотный РН? я так понимаю, единственная цель этого регистра - показать, что этот контрагент является поставщиком этого товара.

(3) Без измерения документ будет плохо. Представь что ты отменяешь проведение некого документа, в нем была некая "Номенклатура". Как узнать была она еще в каких то документах или нет?

(5)
Сложности нет, но я надеялся, что Бориска Нуралиев придумал что-то более стандартизированое, когда ключевые поля становятся ключевыми только при их одновременном совпадении.

(7) оборотный РН с этим отлично справится.

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

(11) Еще раз,при отмене проведения, как ты узнаешь удалять товар из регистра или нет?

(9) Он лично ничего не придумывает.
А те, кто должны придумывать за него, уже давно разучились.

(12)
Ну, я и не буду удалять.

(14) Получишь фиктивную инфу

Сделают ошибочное проведение поступления на не того контрагента, записи об этом останутся, а по факту он товар не поставлял

(14) Наоборот, ставь проверку наличия при проведении. Тогда при отмене ничего дополнительно делать не надо будет.

(14) Ок, неверно занесли товар, или не на того контрагента. В итоге навсегда остались неверные записи.

(17) это медленно...

Сделать регистр периодическим

(19) В смысле? Долго код писать?

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

(22) Моментальным оно будет. Один запрос к не очень большому регистру.

(10)
Хм, ну, оборотный я сделал.
Он дублирует записи по каждой накладной.
Т.е. впринципе в моей ситуации всё-равно, что если бы я сделал регистр сведений с периодичностью по позиции регистратора.
Мне надо, чтобы записей была как можно меньше.

(22) А, типа, то, что ты пытаешься сделать - это что-то другое, да?
Что будешь делать, если отменят проведение документа с первым поступлением товара? Перепроведешь все последующие, чтобы в непонятном регистре, без которого 99,9% пользователей спокойно обходятся, записи на место встали?

(23)
Похоже, единственный вариант.
Чуть большая задержка при проведении лучше задержки при подборе в периодичном регистре.

(0)>Хотелось бы, чтобы он или заменял их или даже не пытался записывать.

Писать через менеджер записи, он автоматом перезапишет при совпадении ключевых полей.

(24) В модуле проведения делай записи не по таб. части, а по результату запроса. Вот и все решение.

(27) На подчиненном регистре не взлетит

(28) См. про отмену проведения

(30) См. в свой мозг!
Отмена будет работать штатно.

(24) записи дублируются, но таблица оборотов - нет, из неё всё будет быстро доставаться. Плюс решается проблема отмены проведения.

(24) Дублирующие записи - это не проблема, а защита от гемороя. Просто надо уметь правильно брать данные из этого регистра (см Срез последних)

(28)
Да не, дубли не из позиций приходной накладной, а дубли получаются если провести ещё одну такую же накладную.
Вобщем, буду проверять при проведении, есть в регистре или нету.

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

(34) это не правильно.

(30) в(0) такого не было)) я следую ТЗ.
(31) Отмена проведения? как это. Если регистр независимый - не отработает. А если подчинен регистратору - слишком много записей и не было бы проблемы с неуникальными записями как в (0)

(0) В типовых РС "Номенклатура контрагентов" не подходит?

(38)
Зобавно. Не думал о таком.
Ну, на данный момент регистр пустой.
Через какую константу включается?

(37) Регистр подчинен регистратору.
При проведении вносятся только уникальные записи.
При отмене проведения записи (если они есть) удаляются.

(38)
Всё, понял.
>>То есть можно ввести информацию о том, как называется данная позиция номенкла­туры в информационной базе поставщика.
>>Эта информация будет записана и регистр сведений Номенклатура контрагентов при записи цен.
Совсем для других целей используется.