v8: Ошибка 8.3 при записи движений в регистре бухгалтерии. #667530

Чуда не случилось, и как всегда старт новой платформы чреват наличием довольно грубых ошибок. Попробовал перевести базу на 8.3. В результате даже не очень глубоких тестов прямо сходу наткнулся на некорректную работу по перепроведению документов (без отмены проведения). Данный трабл наблюдается стабильно при просо перепроведении документа, без его модификации и при условии того, что по документу делается всего одна единственная проводка по регитсру бухгалтерии. Если модифицируется документ, либо по документу больше 1-й проводки такого поведения не словил (может просто не повезло). Исходные данные по документу: Оперативное проведение: разрешить Удаление движений: Удалять автоматически при отмене проведения Запись движений при проведении: Записывать выбранные Режим блокировок: Управляемый Модуль обработки проведения: При перепроведении корреспонденция остается одной и той-же, меняется только сумма проводки (для тестирования специально выхолостил весь алгоритм и сумму формирую случайным образом). На выходе из процедуры в отладчике и сумма проводки верная, и признак записи регистра бухгалтерии установлена. Но после выхода в проводках сумма остается неизменной!!!! Если в результате перепроведения изменится что либо кроме суммы - то эта ситуация отлавливается и все перезаписывается, но вот сумму игнорирует. Более того, пробовал перепроводить с интерактивным изменением данных в документе -  если что-то влияеет на набор записей кроме суммы - все срабатывает, если просто изменение не повлекшие изменения в данных (например сумму повтороно пробио то же самое значение в форме) - то фиг - проводки не переписываются, если же изменить какой-либо реквизит -  то и тут засада, почти по всем документам проводки тогда перезаписываются (во всяком на выборочном десятке), но вот на последнем документе по времени в журнале - НЕТ!!! Я фигею, дальше только чисто по-русски... :)

Чуда не случилось, и как всегда старт новой платформы чреват наличием довольно грубых ошибок. Попробовал перевести базу на 8.3. В результате даже не очень глубоких тестов прямо сходу наткнулся на некорректную работу по перепроведению документов (без отмены проведения). Данный трабл наблюдается стабильно при просо перепроведении документа, без его модификации и при условии того, что по документу делается всего одна единственная проводка по регитсру бухгалтерии. Если модифицируется документ, либо по документу больше 1-й проводки такого поведения не словил (может просто не повезло). Исходные данные по документу: Оперативное проведение: разрешить Удаление движений: Удалять автоматически при отмене проведения Запись движений при проведении: Записывать выбранные Режим блокировок: Управляемый Модуль обработки проведения: При перепроведении корреспонденция остается одной и той-же, меняется только сумма проводки (для тестирования специально выхолостил весь алгоритм и сумму формирую случайным образом). На выходе из процедуры в отладчике и сумма проводки верная, и признак записи регистра бухгалтерии установлена. Но после выхода в проводках сумма остается неизменной!!!! Если в результате перепроведения изменится что либо кроме суммы - то эта ситуация отлавливается и все перезаписывается, но вот сумму игнорирует. Более того, пробовал перепроводить с интерактивным изменением данных в документе -  если что-то влияеет на набор записей кроме суммы - все срабатывает, если просто изменение не повлекшие изменения в данных (например сумму повтороно пробио то же самое значение в форме) - то фиг - проводки не переписываются, если же изменить какой-либо реквизит -  то и тут засада, почти по всем документам проводки тогда перезаписываются (во всяком на выборочном десятке), но вот на последнем документе по времени в журнале - НЕТ!!! Я фигею, дальше только чисто по-русски... :)

прикольно

не катастрофа и даже не беда, но за инфу спасибо

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

А зачем рапортуешь на мисте? Отправляй сразу в Контрольную группу k@1c.ru

Да и в принципе: как можно пользоваться системой, которая даже записи в базу делает не те, которые от нее требуют?!! Я не уверен что и по регистрам какой-нибудь аналогичной бодяги нет!!! Тупо смотреть на картинки на экране?! Нах такая система!!!

Мда... Прикольная оптимизация записи :)

Видать хитрый случай с единственной проводкой проскользнул через юнит-тесты :)

может просто журнал проводок барахлит?

не сложилось как-то с диалогом 1С. Не знаю , может сейчас что изменилось, но раньше без предоставления данных о регистрации и прочей мути 1С даже не хотела слушать об ошибках. Я работаю на разных клиентов, и мало того что я за бесплатно тестирую ихние траблы, то мне теперь надо клиента поднять, а предоставьте ваши данные, на что мне в 90% случаев посылаю нафиг, ибо кому-то надо напрячься, перевернуть все свои мусорки во всех кабинетах в поисках регисртационных данных, то это у Мани, то это у Клавы.... У меня уже выработался стойкое убеждение: А мне оно надо?. Может кому мое сообщение поможет в принятии решения переходить на 8.3 или нет -  это для меня важнее. Может трабл не в самом прведении, а например в конвертации данных, а ж не идиот теперь все с нуля набивать.  Может кто-то еще проверит и подтвердит, или опровергнет...

- Может и барахлит, только в журнале у меня ничего из алгоритмов ВООБЩЕ нет, просто вывод данных из регистра. И даже если это он, то мало утешений.

- одна проводка - далеко не хитрый случай. Изначально наткнулся на это из реальной ситуации: акт приходования выпущенной продукции. Не замораяиваю почему, но так уж случилось, что клиенту удобно приходовать единственную позицию, а не список продукции. Потому в документе и формируется 1 единственная проводка. Но даже при таблице, запросто может оказаться аналогичная ситуация

Ну, 1С тоже можно понять. Им нужно как-то фильтровать вал обращений к разработчикам, который без оной фильтрации на 99% будет тупо спамом.

на месте 1С за сообщения об ошибках следует еще и бонус начислять! Я ж не по-поводу того, расскажите а как это сделать? Значит если регисрационные данные представляешь, то мы будем с нашими траблами разбираться, если нет, то не будем (как будто и нет их, будем ждать пока кто-то педантичный со всеми атрибутами появится). А простите собственно сам процесс исправления от этого как-то меняется? Я что прошу с ними переписки? Я сообщаю факт. Даже с регистрацией - их право рассматривать, реагировать или нет на мое сообщение. Что мешает соотвествующим людям вникать и проверять. Или что, зарегистрированного пользователя на счетчик поставят, если он их ввел в заблуждение? Не понимаю! С консультациями - да ваше право не разговаривать с незарегистрированными пользователями, но принимать сообщения об ошибках?... нонсенс. Это то же самое если кого-то в подъезде зарезали, а полиция не будет принмать фотографии того как это было, пересланные по почте... Пока -что даже заплатить пообещают, если очень надо :)

Знаешь, сколько таких багонаходителей вчера открывших ломаную 1С будет всякой фигни слать? Кто будет эти авгиевы конюшни разгребать? Причем девочку с ресепшена не посадишь, надо спеца садить. Другое дело, что подготовить хороший баг-репорт (особенно если проблема не простая) по которому разработчик сможет воспроизвести проблему - это тоже время/деньги. А мотивации практически нет. Ящитаю, за подтвержденные баг-репорты надо в самом деле как-то премировать.

- ладно суть данной темы не в том общаться или не общаться с 1С и каким образом. проверил - барахлит не журнал, отчет показывает аналогичные цифры, и перезагрузка 1С не помогает, так что все 100% трабл в записи данных

уже на 8.3 перешел. ну ты храбр однако. или у тебя зело крепкая задница и много вазелина

(+14) если кто-то посчитает нужных сообщить об этом баге - 1С валяйте, претензий не имею :)

- не перешел, а посмотрел на предмет перейти. А крепкая задница должна быть на любом релизе: покажите мне хоть один в котором нет каких-то траблов :)

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

+100 :)

а кто-нить реально проверил ?

Ну я озвучил трабл - сначала 2 дня кувыркался вокруг, думал я что-то накосячил. Потому и накроптал тестовое проведение, чтобы ну на все 100 быть кверенным что некие иные подводные камни не влияют. Единственное - не было времени с нуля создать пустую урезанную конфигурацию, и в ней попробовать (это что бы отмести возможный вариант конвертации базы 8.2). Хотя пробовал и в режиме 8.2. без каких-либо преобразований (теоретически) и в файловом и в серверном варианте - поведение стабильно одинаковое на моих данных (тобишь реальных данных версии 8.2). Если кто-то на пустой базе такое сварганит - и получит тот же результат, ну тогда на все 500 будет фиксированный баг

ответ "нет" удовлетворит?

Если бы кто-нить проверил - уже отписался бы. А если не подтвердится, то может оказаться еще хуже - значит требуется какая-то совокупность условий, которые еще надо устанавливать. Ну, или как легкий вариант, ты - лох :)

Какую-то мизерную вероятность оставляю, может изначальный трабл где-нибудь еще с 8.2 тянется из каких-нибудь служебных полей, хз... Пока нет времени до чистого эксперимента на пустой базе (текущую работу все-таки никто не отменял). Если у кого-то есть время и желание, может раньше проверит, если нет - чуть позже попробую сам (для очистки совести) :)

запости на партнерском

Подпишусь

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

- это уже интересно. Попробую уточнить: Удаление движений: Удалять автоматически при отмене проведения и Запись движений при проведении: Записывать выбранные? Ибо естественно если поставить Удалять автоматически - то все будет ок (перед проведением ясный перец движения очищаются автоматически)

давай .dt с одним документом.

+100. Я тоже попробовал бы, а то если блин еще железо влияете или роза ветров... - то блин... :)

первый пункт - да второй ( Запись движений при проведении: Записывать выбранные) не вижу где он.

Конфа

-  там же в свойствах рядом (если открыт свойства документа)

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

угу, нашел, палец разработчикам в глаз, по F2 не все свойства.

Bober, в твоей базе еще круче, с каждым перепроведением добавляется еще одна строка :)

5 раз перепровел не закрываюя форму - 5 проводок! :) И вроде с первого взгляда все нормально настроено. Единственное переключив в режим совместимости 8.2 и запуск обычного приложения - н о это не должно влиять на поведение

И вопрос в неоперативном проведении!!! Если перепровести оперативно - то одна проводка, если неоперативно - то проводка добавляется!!! Но по-моему это еще один косяк в платформе! или я уже как белка в колесе закрутился...

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

Блин - тут еще поведение проведения зависит от формы, в которой открыт документ: не меняя ничего в модуле проведения если открыть в обычном режиме и проводить - то при неоперативном проведении документа проводки плодятся. Если проводить документ в управляемом интерфейсе - то проводки делаются по одной и да таки с изменением данных. Правда формы генерируются автоматически. Кстати вот тут и есть кажется момент в разном поведении. И поэтому тестовая база от Bober ведет себя по-иному. Попробую выудить истину

Я чего-то не въеду: база от Bober - я в ней просто создал формы документа и настроил режимы использования как у меня. Один и тот же документ (наглядней 2-й) открываем и пробуем перепроводить несколько раз. В управляемом интерфейсе поведение нормальное, в обычном - плодятся проводки по последнему документу (при неизменном алгоритме проведения). Или я уже дошел до тупизма..? :)

Ну вот - что и требовалось доказать: добавил минимальное количество объектов, как в моей базе (в частности субконто и т.п.) Остальное все с чистой базы от Bober. И поведение аналогичное (к выше найденному необъяснимому поведению при проведении из разных форм) - то как у меня. Сумма не переписывается!!!! В базе готовая ситуация для демонстрации трабла. Попробуйте кто-нибудь еще - может это только на моем железе...

Окончательные результаты теста: Для более детального рассмотрения немного изменил процедуру в проведении: Перед началом записей очистка набора движения Хозрасчетный сознательно не делается (в 8.2 такой алгоритм работал без вопросов да и должен по логике). 1. Перепроведение из обычного интерфейса: проводки плодятся с количеством проведений (добавляются всякий раз независимо от оперативно или неоперативно проводится документ). Перепроведение из управляемого интерфейса - в неоперативном режиме проводки поменются если их количество по сранению с предыдущим состоянием изменится, дальше перестают изменяться (триггерный эффект). Оперативно проводимый документ - делает правильные проводки. 2. Если в начале модуля поставить очистку набора (Движения.Хозрасчетный.Очистить;) то в обычном интерфейсе приходим к одинаковому поведению с управляемым - то бишь тогда проводки не плодятся. Резюме: грубая ошибка платформы 8.3 (в таком режиме в ней работать нельзя). Если я не прав - поправьте меня. (база с эмуляцие ошибки в посте 43, можно переписать модуль на вариант приведенный здесь).

1. Это не ошибка. Так и в 8.2 было. При открытии обычной формы система считывает все данные документа, в том числе и его движения. А так как свойство очистки движений стоит "Автоматически при отмене проведения", то как следствие, перепроведение документа будет плодить записи.

не гони, все известно что снеговик сырой и глюченый.

:) Нудануда...

тебе человек привел все выклпдки, код и базы. Глюкалово. Вот так вот, и не надо нам тут про СП и прочие подставки для кофия, все что там написано не правда

Я этот "глюк" на ИС конференции показывал.

Это просто еще один для тестов. Что неправильно работает набор или набор в составе объекта вводе движений.

- да в 8.2 аналогичное поведение (по поводу размножения проводок) - но... лично я отнесу это к ошибке, которая и в 8.2. сидит (ну хотите к недоработке). От того управляемый это интерфейс или обычный поведение не должно меняться. А так лажа. Пусть разработчик и будет меня уверять что это крутая фича. Это лично мое мнение. Ну а претензия не к размножению проводок, а к тому что они не прерписываются. Кстати провел тест на 8.2 на этой же базе (благо в режиме совместимости можно без конвертации открывать в одной или другой платформе) - в 8.2 все нормально проводится и при еоперативном проведении.

- уважаемый, записывать через набор далеко не удобней, и более того иногда вредно, как минимум в случае управляемых блокировок. Не моя прихоть - идеология 1С. Если хотите - можете скачать базу и измените алгоритм на ваш - проверите :)

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

И что управляемые блокировки только в модуле работают? Там нужно просто объявить транзакцию

- да хоть как назовите, но тогда где ж логика: для очистки нужно дать Движения.Хозрасчетный.Очистить. Перед эти открываем в отладчике Движения.Хозрасчетный - он пустой (ведь это набор записей). И команда очистки применяется к этому набору - другой вопрос что в базе есть записи прошлого периода. Ладно - чего по этому поводу спорить - я ж говорю это мое личное мнение: это плохо. Так же как отсутствие контекстного поиска в управляемых формах (именно поиск а не отбор). Сколько бы не утверждали что отбор это лучше - извините мое личное мнение это разные вещи. Так же как и выделение строки одним фоном независимо от режима выделения (ячейки или строки). Разработчик это считает нормальным - но извините мое мнение иное. Так и по различного поведения в обычной форме и управляемой - тоже это мое мнение, в данном случае я не претендую на истину единственно допустиму. . По этому поводу не стоит спорить - хотите пишите так. Долго докапываться до сути - но рекомендации 1С: при записи наборов движения документа следует использовать Движения.Записать, а не Движения.Хозрасчетный.Записать,Движения.Остатки.Записать и т.п. , а тем более записывать наборы. Все упирается в конкуренцию блокировки данных (в общих словах). Тем более ничего не мешает передавать в процедуры конструкцию (Движения.Хозрасчетный и даже просто Движения)

54 да и не навязываю свое видение. Просто протестировать вариант с набором.

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

- :) лень значится самому протестить. Ладно - набор записывается. Этого и следовало ожидать. Речь идет про движения объекта и его поведение. И запись набора никогда не будет плодить проводок (если только не убрать замещение), но... любой записанный набор будет переписан из Движения.Регистр - если это предусмотрено логикой программы (либо настройками записи движения, либо оставив для набора реквизит .Записывать=истина). Кстати в вашем листинге ошибка как раз с этим связанная (после проведения ничего нет в проводках) ибо не нужно оставлять тогда Движения.Хозрасчетный.Записывать=Истина;

Спасибо. Просто у меня куча дел делается. Там есть просто Движения.Хозрасчетный.Записывать=Истина; Просто я писал с листа вне 1С. Движения это и есть набор записей. Но для него автоматически заполняются регистратор, активность. Кстати а что просходит в модуле Регистра бухгалтерии при записи.

Ну вот, ситуация стала еще загадочней! Добавил в модуль регистра бухгалтерии пустые процедуры "ПередЗаписью" И "ПриЗаписи" (до этого там ничего не было) в отладчике посмотрел что там при проведении - там все как и должно было быть - и ... записи проводок стали правильными!! Удалил процедуры - все работает! И теперь уже не словить не рабочую ситуацию! Кто не верит - может скачать из инета базу. Я фигею

как вариант: кэш паразитирует на твоем рабочем месте.

->

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

- блин это уже сам закрутился. Пробовал в версии 8.2 и не заметил что назад на 8.3 не переключил. :) Неа - в 8.3. все по-прежнему не работает. В процедурах модуля регистра при записи все ок - циферки правильные, а вот в базе - нет их.

А если поменять на Записывать Модифицированные?

а может лучше поменять 1С? :)

Я готов отправить готовый багрепорт в 1с. Требуется четко описать 1. Конфигурацию ПО: версия платформы, тип приложения, ОС, СУБД 2. Проблема: кратко самая суть 3. Способ воспроизведения: желательно на минимальной конфигурации, приложенной к сообщению

- да пожалуйса: 1. Любая ОС Windows, любой вариант приложения (файловая или серверная, в серверном варианте тестил на SQL 2008). 2. Проблема: при неоперативном перепроведении документа (без предварительной отмены проведения) не перезаписывается в базу набор записей регистра бухгалтерии (как минимум если в проводках меняется только сумма). Оперативно проводимый документ записывает проводки. 3.   - dt с демонстрацией. Единственный документ в конфигурации и два документа в базе.

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

Т.е. если меняем сумму, то не перезаписывается, а если меняем измерение или субконто, то перезаписывается? Можешь сразу привести код?

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

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

Нужно указать минимальное изменение в демопримере, которое приведет к правильной работе программы. Там это предусмотрено?

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

Сейчас проведу еще один тест, на предмет чтобы заработало

Да - стоит при проведении в проводке изменить например субконто - первое перепровдение тогда записывает набор, последующие - не изменяет (естественно сумму, ибо остальные все поля неизменны)

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

Да куда еще проще?! Все что нужно для демонстрации - запустить (для минимума движений в управляемом режиме), открыть документ, и нажать "провести" - все!!! В базе всего 2 документа ! Один проводится всегда неоперативно (поскольку не последний по дате), второй всегда проводится оперативно - поскольку последний. По первому не правильно пишутся, по второму правильно. Чего еще надо чтобы исправить ошибку?!! Написать трактат на тему ...

хороший у тебя бухгалтерский учет :) Ген=Новый ГенераторСлучайныхЧисел; Сум=Ген.СлучайноеЧисло(10,10000); Проводка.Сумма=Сум;

(+78) или 1С уже исправляет ошибки вообще не открывая конфигуратор? - там блин всего 10 строчек кода

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

Я потому и пишу, что я попробовал. При попытке провести последний документ получаю ошибку "Запись не верна! Значение поля "Организация" не может быть пустым! (Регистр бухгалтерии: Журнал проводок хозрасчетный; Номер строки: 1)"

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

А ты смотрел Ген.СлучайноеЧисло(10,10000); НачальноеЧисло=ТекущаяДата-НачалоГода(ТекущаяДата); Правилнее наверное Ген.СлучайноеЧисло(1000,НачальноеЧисло);

Генератор генерит случайную последовательность по определенному алгоритму отталкиваясь от начального числа. По сути у тебя одно и тоже число каждый раз. или можешь сделать так НачальноеЧисло=ТекущаяДата-НачалоГода(ТекущаяДата); Сум=НачальноеЧисло % ПростоеЧисло

- чего вы доколупались до этого генератора? да напишите что угодно - какой нах разница? не формрует случайного числа? Чего - не формирует? батенька так вы откройте конфигурацию и посмотрите

А еще не плохо было бы посмотреть доку:Синтаксис:

Разрешаю замутить ряд Фурье - валяйте :)

Прошу прощения не посмотрел

86 Генератор будет всегда генерить одинаковую последовательность. Или использовать без параметра Формирование неинициализированного объекта Синтаксис: Новый ГенераторСлучайныхЧисел Описание: Генератор случайных чисел инициализируется временем работы операционной системы с момента старта.

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

Можешь для себя заменить ГСЧ на ВвестиЧисло.

- - все это мой последний вариант. Если это для разработчика сложно - то тогда всем нам нужно срочно искать альтернативный софт. Я не считаю, что изложил суть проблемы не доходчиво. Могут тогда просто искать свой баг просто по фразе: "заоптимизировались господа, у вас не записываются в базу проводки в регистр бухгалтерии при неоперативном перепроведении документа без его модификации и предварительной отмены проведения, когда меняется сумма проводки. В базе остается старая информация!!!"

+500 :)

Выдает 814 814 Да Сделай правильно. Новый ГенераторСлучайныхЧисел;

Автор, таки мы все уже умрем или может быть еще помучаемся?

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

и - и чего? чего ты мучаешь эту конструкцию.  Мало того что выдернул из контекста, так не вникаешь для чего это. Объект формируется каждый раз при проведении. Сделай 2 генератора, выполни одни те же команды и сравни. Усе - по поводу генератора я иссяк... :)