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

Давно не брал в руки ключшки, не доводя дело до паяльника, что еще может быть причиной кроме банального вредительства?

(0) а что монитор-то говорит?...

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

В ПриОтменеПроведения() логируй в текстовый файлик текдату, теквремя, ИмяКомпа, ИмяПользователя для этого номера документа

(3) дельно, спасибо

если скуль, может зашит быть скрипт в скуле, можно в шудлер скрипт закатать правки напрямую в скуле, если ДБФ можно напрямую из 1с-ки править ДБФку, дата номер может браться из какого нить текстовика, тесктовик и модуль отмены проведения можно загружать как шаблон, лежать может где угодно, я так экспериментировал, на тот момент 3-е программистов коллег этот код не нашли.

файловая или серверная?

(5) из этой же базы свою дбф не поправишь.
Но вообще, соглашусь - способов навредить 100500

(5) дбф в терминале. Надеюсь у них мозгов поменьше. Костыль на запись текстовика сделал, проверим

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

(0) Что стало с предыдущим программистом?

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

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

(12) рибы бы в логах засветились, автор говорит что в логах чисто))

(12) риб нет
(10) не могу знать, я там пришлый, попросили помочь
(11) никаких обработок. Те что в  Extforms провели аудит. Хотя сам об этом думаю, где-то сидит код.
Странно, что один и тот же документ снимается с проведения, не похоже на вредительство. Будем посмотреть. Спасибо

(3) :) почему в текстовых-то? а ЖР чем плох?

(15) вдруг злодеи чистят?

(15)скрытый костыль )

(14) откуда уверенность про "никаких обработок", права проверили на запуск, или верите людям на слово?

(16) а еще злодеи могут заходить в конфигуратор, менять текст обработки, запускать ее, отменяя проведение документа, а потом снова в конфигураторе менять текст обработки на чистый... рептилоиды они такие!

"один и тот же" это один и тот же номер дата документа или ID проверял? Было у меня разок...

И пересчет итогов и реиндексация мало - для ДБФ выгрузка-загрузка иногда глюки лечит

ну и ТиИ само собой

вид документа, номер, дату и время в студию.

(19) можно сделать защиту от дурака, но нельзя - от изобретательного дурака!

(23) чем это поможет. Выписка банковская от 2020 года, один документ
(20) в сабже писал, что клонировали док, клон тоже снимаетсяс проведения

(21) все пройдено

обмены с банк клиентами?

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

(27)плюсую. Загрузка платежных документов иногда интересные эффекты даёт)

(27) писал в сабже, вводят в ручном режиме

(28) скорее по дате и расчетному счету. Номер в теме лишне указан

если в метаданных все корректно но тем не менее на лицо ошибка - значит есть проблема в данных, которые скармливаются корректному "проверенному" коду.
(29) не верю.
если нет следов в ЖР, и ЖР настроен - то изменения однозначно обработками.
поскольку вы все в экстформс изучили, у вас нет РБД и банк клиентов, но вы игнорируете 18 - значит у вас ЕСТЬ пользователь которому разрешен запуск внешних обработок, в нем и причина.

(25) а клон чем отличался от оригинала? только idом?

(31) вот поэтому пока остановился на (3). Админам озвучил предложение убрать права на запуск доп обработок.

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

В модуль проведения документа тупо вставить текстовый логгинг с "фильтром" на этот документ
При срабатывании фильтра - писать в текстовый лог кто когда и сразу формировать "уведомление" пррограммисту

(16) (17) :) можно подумать что если злодеи чистят ЖР то не смогут тхт файл

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

тест № 2 - Последний документ (Первый документ), сделать не первым, а 20-тым, т.е. передвинуть вперед.

Если все же первым документом окажется другой документ, то предлагаю начать копать дальше в поисках "волшебной" обработки, которая это делает :)


Вопросы:
1С 7.7 типовая или вы использует разные ВК, от 1С++ до VK с подменом модулей ? :)

(36) Журнал не чистят, это 7.7, здесь обработка царь и бог :)

(36) его еще найти надо!. а для этого в код залезть. Хотя и тут "есть варианты", но надеюсь они не настолько сообразительные - иначе одним документом бы не обошлось.

А я вот верю в (27). На все сто.
Поставь в Обработке.ПредприятиеКлиент после
Объект.Записать()
Объект.СнятьПометкуУдаления()
Объект.СделатьНеПроведенным()
нормальное логирование через
ЗаписьЖурналРегистрации и по итогу увидишь, кто и когда твой документ херит загрузкой.

Включаю телепата:
Где-то лежит старый kl_to_1c.txt за эту дату, сохраненный на закладке "Настройка обмена" в обработке "1с Предприятие-Клиент банк" под конкретным пользователем, пользователь тупо жмёт "Загрузить" не указав новый файл, а используя настройку по умолчанию. 100%

(34)
ОбработкаУдаленияПроведения() в модуле документа сработает при отмене проведения любым способом. Хоть интерактивно, хоть программно, и из обработки и из любого другого модуля

(40) профили пользователей тоже были проверены, нет файлов КБ
(41) согласен, это и реализовано

(41) Как много мне открытий чудных... Забыл, что Провести() и ОбработкаУдаленияПроведения() особые.
(42) А как проверялись профили? Не очень понимаю как это сделать. В каждой папке пользователя и в папке с базой данных можно проверить наличие файла kl_to_1c.txt, содержащего данные за проблемную дату.А потом? В папке каждого пользователя и в папке с базой данных открывать блокнотом rh418.lst (или какой там) и искать там все {"ИмяФайлаЗагрузки"," , чтобы посмотреть какие пути к файлу загрузки сохранены по умолчанию? Или заходить под каждым пользователем?  
Ну и в целом, как в анекдоте: может быть 99 разных причин отсутствия месячных из 100, но в 99 случаях из 100 - причина 1. Если они загрузкой выписок не пользуются - поставь заглушку на
процедуру Загрузки и посмотри, повторится ли проблема. И, кстати, если в базе есть документы "Операция по расчетному счету"  значит, врут и пользуются загрузкой (ну или нечаянно запускают).

емнип, если стоит "автоматическое удаление движений", то ОбработкаУдаленияПроведения не вызывается... а может, глючит меня уже.

Скорее вызывается. Надо проверить. В этой процедуры можно де статус возврата 0 бабахнуло независимо от того авто или не авто

(45) при отключенной галке автоматическое удаление движений, обработка удаления точно вызывается - проверил

Блин тут что всё клюшечники пасутся? ;-)

автоматическое удаление движений - это про проведение проведенного дока, т.е. про перепроведение.
ОбработкаУдаленияПроведения вызывается при отмене проведения и не вызывается при перепроведен и и флаг автоудалении не имеет значения

"и не вызывается при перепроведении" - как бы логично

(47) Многие когда-то ими были. А некоторые совсем недавно перестали быть таковыми.

как дела, нашли виновника?

(49) вовсе не однозначно.
Например _могла_бы_быть_ такая логика: при перепроведении - сначала ОбработкаУдаленияПроведения (при флаге автоудаления), потом ОбработкаПроведения

(52) вряд ли, как тогда понимать что выполняется отмена проведения или перепроаедение?

(51) рано говорить, выстреливало раз в месяц. Пока удочка закинута

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

в одной конфе было
регламентное восстановление последовательности
Сделано было через Отмену проведения/Проведение
Попался глючный зетотчет - руками проводится, а автоматом не проходит проверку, в результате проведение снято и назад не поставлено

(53) так же как в ОбработкеПроведения понимать проведение это или перепроведение )

Дата запрета редактирования вроде нормально запрещает изменять документы, не пробовали просто ее поменять.

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

(57) тут просто: если проведен - то это перепроведение, не проведен - проведение.

(58) обработкам пофиг на дату
(59) такого в 7ке не припомню. в 8ке штатная возможность платформы привязать движения одного документа на другой.
помню был этим несколько озадачен.

(61) рассказыают, что в 8-ке проводки можно даже другой датой формировать...?

(62) Правда.
К примеру, в БГУ к примеру, закрытие счетов в конце года - документ делаешь, ну, к примеру, первой рабочей датой 10.01.2022, а проводки у документа формируются 31.12.2021 в 23:59:59
Или, к примеру, там же - Заявка на кассовый расход - проводки делаются не датой документа Заявка, а датой Исполнения этой самой заявки.

(59) (61) это если iddoc дублируется. но тогда бы не прошла бы реиндексация, или ТиИ упало бы
(61) Штатно привязать к другому в клюшках нельзя, нештатно, естественно, можно...