v7: Создаётся документ другого (неправильного) типа #765958

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

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

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

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

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

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

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

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

180

терминал?

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

Да

+11 Файловая.

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

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

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

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