Доброго дня!
Есть регистр сведений подчиненный регистратору, периодичность в пределах дня. 2 ведущих измерения.
В регистре есть две записи с одинаковым периодом и одинаковыми значениями измерений, регистраторы разные документ 1 и документ 2 с одинаковым типом. Вопрос как эти две записи смогли быть одновременно записаны? при попытке перепровести один из документов выходит ошибка о неуникальности данных. ОбменДанных.Загрузка = Истина не позволяет обойти проверку уникальности. изменение периодичности тоже не дает такой возможности. РИБ нет. Как такое возможно?

Нормально.
Ты просто не очищаешь набор перед записью.

(1) Отмена.
Может был сначала подчинен регистратору, потом поменяли периодичность.

(0) было еще одно измерение - удалили, или как в (2)

а может первая ошибка не связана со второй.

попробуй не перепроводить, а отменить проведение. потом провести.

Отладкой проверял, набор очищается. Если отменить проведение, тогда второй раз один из документов уже не провести, ругается на уникальность. Если попробовать поменять периодичность на по
позиции регистратора, заново провести документы, а потом снова попробовать поменять периодичность на день, тогда 1с не даст применить изменения в БД при реструктуризации таблицы все по той же причине, подозреваю, что если добавить измерение, ввести данные, а потом удалить будет тоже самое, хотя не проверял это еще.

(0) в таком раскладе Регистратор - ещё одно измерение
Если нужна уникальность отцепляй от регистратора

вообще это регистр ЦеныНоменклатуры в ут 10, он не менялся, соответствует конфе поставщика

(7) Вопрос в том, как эти две записи записались одновременно, сейчас оба документа проведены и обе записи есть в регистре

(9) Измерения = Регистратор (только его не видно в конфигураторе) + твои 2 шт
Срез последних достанет Ресурсы последнего документа

(10) Я мысль уловил, но тогда бы документы можно было перепровести или распровести и заново провести вместе, а этого сделать нельзя.

(0) Может периодичность была секунда, или в разрезе регистратора, а потом поменяли в пределах дня?

(11) Почему это нельзя? А как устанавливается следующая цена?
По факту, нужно проверить наличие дублей записей за день и не проводить второй документ

(12) нет, в 6 описал.

(13) при чем тут следующая цена? внимательнее (0), (6), (11) читайте.

(15) так почему нельзя проводить документы одновременно? последним 1С назначит один из документов по своему выбору

я уже писал: если очень нужно запретить такие фокусы - ставим контроль в ПередЗаписью и будет счастье

В УТ 10 периодичность "ЦеныНоменклатуры" - день
Да, это неудобно.
Можно сделать 1 сек, посмотрев код в УТ11 и подумав немного головой.

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

(16) ругается на уникальность записи. А каким образом до этого записалось не понятно

(17) Вопрос то не в неудобстве. А обмен разве может игнорировать контроль уникальности записи в таблице?

(19) ОбменДанными.Загрузка = Истина   и контроли отключаются

Товарищи, форумчане, вы бежите вперед паровоза! Я понимаю прекрасно что можно и как изменить и т.д. и т.п., но вопрос не в этом. Давайте так, ничего менять нельзя, надо вот оставить вот так как есть и до этого было так как есть сейчас. Нужно понять каким образом произошло то что описано в (0).

(20) Я добавил ОбменДанными.Загрузка = Истина при проведении документа, ничего не поменялось, в (6) написал об этом

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

(21) >> Нужно понять каким образом произошло то что описано в (0).

Зачем и кому это нужно?...

Сейчас вполне достаточно исправить ситуацию. Любым способом - хоть поменяв период одной из двух записей, хоть удалив одну из записей.

Если точно нет никаких обменов, то остаются только два варианта как такое произошло. Причём оба уже озвучивали выше.
1. Меняли периодичность. Увеличивали. Ранее она была "в пределах секунды" или "по позиции регистратора".
2. Изменялся состав измерений. Какое-то измерение удалили.
То, что сейчас регистр соответствует конфигурации поставщика, ни о чём не говорит. Во-первых, сам поставщик мог вносить изменения в регистр. Во-вторых, вполне возможно, что когда-то этот регистр отличался от конфигурации поставщика (меняли периодичность или добавляли измерения), но потом решили отказаться от дописок и вернули первозданное состояние регистру, а сообщение платформы о проблеме при применении изменений проигнорировали.

Конечно чисто теоретически мог быть ещё какой-то глюк платформы. Но это довольно маловероятно.

(24) еще могли напрямую в базу записать строчку в таблицу, что не законно в плане 1с...

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

Источник: "Записи регистра сведений стали неуникальными в 1С" - https://1c8v.ru/zapisi-registra-svedenij-stali-neunikalnymi-v-1s/

PS: я могу сделать то, что не удалось автору в (6).

(24) Кому и зачем достаточно исправить ситуацию? Где-то было об этом сказано? (23) попробовал добавить и документу и нобору записей флаг, все равно "запись с такими ключевыми полями существует" (26) что именно можешь сделать?