Ситуация:
Обратились ко мне за помощью, у ребят, при загрузке с сайта заказов происходит дублирование номеров документа "Заказ покупателя".

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

Обработка по обмену запускается в виде регламентного задания с интервалом в 300 сек. База SQL, версия конфигурации УТ 10.3.13.2 (так же немного допиленная, но не в части формирования номеров документов)

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

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

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

Присваивать последнему документу максимальный номер тоже пробовал. Проблему не устраняет.

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

Версия платформы 8.2.15.294

Ну хотя бы версий подкиньте, где поискать!

Просмотрел исходный код обработки "ОбменССайтом", на предмет наличия конструкцции типа:
Документ.ОбменДанными.Загрузка = Истина;

Насколько я понимаю она должна отключать контроль уникальности номеров.
Но таких конструкций нет.

Так же, я понимаю что каждому вновь созданному документу 1С резервирует номер документа, и возможно если двумя независимыми процессами одновременно создавать новые дкументы "ЗаказПокупателя" - то возможно будет зарезервировано два одинаковых номера.
Но ведь при попытке их записать одному из документов будет выдан отказ в записи с ошибкой "Номер не уникален". Т.е. насколько я могу понять - дубли не должны появится в журнале документов.
Однако они есть...

что за сайт ??

(3) Это принципиально? Сайт торгует моб. телефонами.

(4) конечно - посмотреть, что там за сервис настроен

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

(5) Не уверен что проблема на стороне сайта. Сайт вообще не изменялся в течение этого времени. Как отдавал информацию в CML так и продолжает отдавать.

(7) давай адрес - сейчас посмотрю

(8) Изини - таких полномочий (адреса раздавать) мне не предоставили.

Если объяснишь что собрался там смотреть - скажу. Ни лично я не понимаю при чем тут сайт? Если все операции с базой выполняются на стороне 1С?

Версии, господа! Должны быть версии...
Проверил "ПривилегированныйРежим" - тоже не используется.

Доступа к консоли Сервера 1С у меня нет.

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

(12) "А слона то мы и незаметили"... в журнал регистрации не догадался заглянуть... ща изучу...

Толи я не туда смотрю, то ли нет записей в журнале регистрации по данному обмену.

(6) у вас в связи с переездом не могла возникнуть ситуация, когда с одной базой SQL работает два разных сервера приложений?

(15) Ситуация которую вы описываете вполне вероятна. Т.к. 1С эти ребята арендуют у аутсорсеров... или как их назвать.. т.е. платят за сервак на котором уже работает 1С, им ее там подключают, отключают, переносят между серверами. Всю эту работу делают админы компании аутсорсера. Поэтому ни доступа к консоли сервера ни к MS SQL нет.

Я просто никак не могу понять: в результате чего (каких операций) возможно появление в журнале документов двух документов с одинаковым номером.
Знаю что такая возможность существуют когда выполняют обмен/загрузку... но для этого якобы надо включить "ОбменДанными.Загрузка = Истина".. я не нашел нигде (в рамках работы обработки )этой инструкции.
не исключено что плохо искал.

сайт пишет напрямую в SQL? без Com?
Тогда очевидно что из 1с будут выдаваться номера согласно своей нумерации и они будут повторяться. Если да - то нужно в 1с перед открытием формы обязательно вызывать процедуру из глобального привелигилированного модуля с обновлением номеров.

(14) ну в крайнем случае есть технологический журнал, но это для тех, у кого черный пояс

(19) Технологический журнал, наверняка, как и консоль Сервера Предприятий недоступен.
(18) Я в (0) написал обмен идет по стандарту CommerceML - напрямую в базу ничего не пишет. Сайт вообще никуда ничего не пишет. Он по запросу из 1С формирует CML (XML) файл определенной структуры, а уже 1С в обработке "ОбменССайтом" выполняет операции по разбору файла и создании документов.
Участие сайта в этом процессе минимальное и никакого отношения к номерам документов сайт не имеет.

(20) По словосочетанием "Сервер Предприятий" - имел ввиду "Сервер Приложений 1С"

техножурнала нет, журнала регистрации нет, консоли недоступны. Есть хоть что то в этой темной комнате?

(22) В том то и дело.. что исходные данные таковы.
Смущает что все работало и дублей небыло...
Теперь все работает - но дубли есть.
За последний час в базе появилось дополнительно еще 15 дубликатов.
Т.е. каким-то образом дубли продолжают появлсться, игнорируя контроль уникальности.

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

(24) Ситуация осложняется тем что не каждый номер дублируется при загрузке.

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

Возможно я недостаточно глубоко залез в процедуры и функции типовой конфигурации - но даже посидев с отладчиком я не увидел возможности - каким образом можно сохранить документ с дублированным номером

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

(15) похоже на правду
Нечто подобное было когда к одной базу по ошибке подключили два сервера 1с и часть пользователей там работала, а часть на новом

Подскажите (сам не сталкивался) при обмене с битриксом он соединяется с базой по com, или база опрашивает битрикс и загружает заказы?

(27) Старый сервер не доступен. Пробовали подключится - непускает. Сделали вывод что его таки "потушили".
Скачал обработку "КонсольЗаданий", подключился - посмотрел заданий ровно столько - сколько должно быть. Запускаются согласно расписания.

(28) В данном случае база соединяется с битриксом забирает файл и сама его "парсит".

(26) В том то и дело что по документам понять ничего нельзя. Заказы номера которых дублируются имеют совершенно разные свойства, даже не похожи друг на друга. Единственное сходство между ними это 1С-овский номер документа который дублируется. Причем их бывает ровно два. Т.е не три и не четыре. Два не больше.

Так же известно что номера дублируются у документов в рамках одного дня.
Может это какой-то глюк платформы? Где-то глючит система резервирования номеров документов? Возможно ли такое? И если да - можно ли ее как-то обнулить или сбросить на 0.

И мне по прежнему непонятно - почему контроль уникальности номеров не срабатывает когда в одну базу записывается два одинаковых номера документа. (Галка "Контроль униклальности" - на заказе стоит)

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

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

Ответ уже был дан в (15). И это единственный вариант, при котором платформа позволит записать несколько документов с одинаковым номером. Даже при ОбменДанными.Загрузка = Истина не даст она вам номера задублировать, и даже в привелигированном режиме.

Ситуация с несколькими серверами на один SQL вполне позволит провернуть такую опу, когда юзер будет создавать документ на одном из серверов, а регламентное задание запустится на другом. У каждого из серверов в этом случае будет свой менеджер нумерации.

+(31) Это все справедливо конечно же, только тогда, когда в пофигураторе для документа установлена галочка "Контроль уникальности". Если она снята - то хоть обдублируйся

(0) РИБ имеется у базы?

(32) В (0) я писал что признак установлен. Так же я писал что попытки создать дубликат в ручную пресекаются системой. Т.е. механизм контроля дублей работает.
Но сами дубли появляюстя.

Написал письмо админам аутсорсиноговой компании о работе двух серверов одновременно. Жду реакции.

(33) РИБ - отсутствует. Все работают через RDP в базе напрямую

Итак, не долго думая заблокировали доступ на сервер, сменив пароль для получения файла обмена.
Дубли прекратились (по крайней мере с момента блокировки ни одного нового нет).

От админов получил четкий и лаконичный ответ "Выключил сервис старого сервера". Походу он таки работал подлец!

На данный момент проблема решилась. Но "подежурить" еще надо ... вдруг что всплывет :)

Как ни странно... Дубли продолжают появлятся.
Хотя админы сервера утверждают что другой (старый) сервер Предприятия остановлен.

Поэтому я бы не отказался услышать еще версии по поводу того что может быть причиной возникновения дублей.

Может в настройках регламентного задания есть какой-то свой кеш номеров? Который в какой-то определенный момент разошелся с кешем номеров базы?