риветствую  уважаемое сообщество, прикольно что я сюда вернулся, как и собирался. В общем - нужна помощь. Как технического плана, так и морально-социального. Здравая критика также принимается и даже приветствуется.

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

Амбула. Акт второй.  Технический.  В наш хелпдеск поступает заявка на тему "заказ не пришел в систему". Я прошу развернуть копию базы, ее разворачивают - анализирую. Тут отступление - эта проблема поступала и ранее, тогда я сделал отдельный лог загрузки заказов, куда пишется, в т.ч. ЗначениеВСтрокуВнутр() - текущего документа.  По этому логу -я получаю внутр. представление, копирую его в собственную обработку уид77 (тм) - и получаю "Реализация №..." При том, что документы загружались исключительно как Заявки. т.е..  условно:  док = СоздатьОбъект(Виддокумента);... заполнение... Док.Записать(). ВидДокумента = "ЗаявкаПокупателя" - однозначно.

Ладно, думаю  я , реализация так реализация. Открываю через обработку документ - не открывается, ругается что нет реквизита... не суть, нахожу данную реализацию через номер - действительно Реализация есть, добрые оперы ее уже пометили на удаление, по комментарию (это общий реквизит, и туда пишется внешний номер заказа) - понимаю что это оно самое. Этот документ - пустой, т.е реквизиты не заполнены, ТЧ пустая. Лезу обратно, сначала в dd, потом в dbf - нахожу данные (dh и dt данного документа). Находясь в легкой степени диссонанса, проверяю - копия ли? Копия. Тупо меняю ручками в 1SJOURN.dbf вид документа на Заявку. Не выходя из 1С - тупо обновляю журнал - и вуаля - имею заполненный и внешне корректный документ ЗаявкаПокупателя - правда помеченный понятно, и с номером реализации, тоже понятно.
То есть по факту - имеем дикую багу базы/платформы (лично я вижу такое впервые, а я повидал)))

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

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

Собственно вопросы: Технический - у кого-то была подобная ситуация? Причины, решение?
Социальный - интересует просто мнение относительно.

Технически - могу посоветовать только обернуть все в транзакцию (весь код от создания объекта до записи/проведения).
Ловил похожие глюки при высоконагруженной базе и использовании "вложенного проведения" - когда из модуля проведения проводится другой документ.
Связано с не совсем корректной работой механизма , выдающего новые ИД для объектов. Сбоит при откате "вложенной" транзакции (вроде так).

Сталкивался с таким глюком.
База ДБФ.
Пользователь записал документ, продолжает дальше работать.
Но остальные пользователи ничего не могут записать, получают сообщение о транзакции.

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

Способа решения проблемы пока не нашел.
База с большим кол-вом пользователей. Возможно из-за этого.

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

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

Веди лог транзакций своей обработки расширенный.
В случае проблемы сигнализацию.

(1) >>>Технически - могу посоветовать только обернуть все в транзакцию (весь код от создания объекта до записи/проведения).

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

Вы используете ЗначениеВСтрокуВнутр() при обменах?!

(0) "Тебе бы не картины, начальник, - тебе бы книжки писать"©
А вообще, в транзакцию в данном случае достаточно обернуть создание нового (пустого) дока заданного вида, и его запись. А после уже спокойно заполнть, записывать и проводить.

(2) "большое количество" = это сколько?

(7) 180

(8) терминал?

+(9) я сталкивался с подобным на файловой, но не помню причину. Вроде натолкнуло на ответ что-то с итланда.. но хоть убей, не помню...

(9) Да

+11 Файловая.

(11) все равно, я так и не вспомнил...

(13) если, вдруг, вспомнишь, напиши пожалуйста сюда или в почту.

(3) Док.Вид() = "ЗаявкаПокупателя", Строка(Док) = "Реализация...". Такие чудеса) Т.е. по строковому представлению - да, теоретически -  можно проверять.

(6) Интересная мысль, спасибо.  Думал о записи в транзакции, типа откатывать транзакцию в случае неверного типа. Но оставался  вопрос сможет ли транзакция корректно откатиться (база dbf). В случае же записи пустого документа - времени на запись будет нужно меньше (хотя бы из-за пустой ТЧ) - и шансов, что новый док "застолбит" свой id с правильным видом - больше. Думаю, стоит предложить этот вариант)

(5) в данном случае - только в целях логирования. А в целом - да, используется для сопоставлений (надежнее чем номер/дата или код для справочников)