Чуда не случилось, и как всегда старт новой платформы чреват наличием довольно грубых ошибок. Попробовал перевести базу на 8.3. В результате даже не очень глубоких тестов прямо сходу наткнулся на некорректную работу по перепроведению документов (без отмены проведения). Данный трабл наблюдается стабильно при просо перепроведении документа, без его модификации и при условии того, что по документу делается всего одна единственная проводка по регитсру бухгалтерии. Если модифицируется документ, либо по документу больше 1-й проводки такого поведения не словил (может просто не повезло). Исходные данные по документу:

Оперативное проведение: разрешить
Удаление движений: Удалять автоматически при отмене проведения
Запись движений при проведении: Записывать выбранные
Режим блокировок: Управляемый

Модуль обработки проведения:

Процедура ОбработкаПроведения(Отказ, Режим)
   Ген=Новый ГенераторСлучайныхЧисел(0);
   Сум=Ген.СлучайноеЧисло(10,10000);
   
   Проводка=Движения.Хозрасчетный.Добавить();
   Проводка.Период=Дата;
   Проводка.Организация=Организация;
   Проводка.Содержание="Приход готовой продукции";
   
   Проводка.СчетДт=ПланыСчетов.Хозрасчетный._68_2_1;
   Проводка.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.ВидыПлатежаВБюждет]=Справочники.ВидыПлатежаВБюджет._Налог;
   
   Проводка.СчетКт=ПланыСчетов.Хозрасчетный._68_2_2;
   Проводка.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.ВидыПлатежаВБюждет]=Справочники.ВидыПлатежаВБюджет._Налог;


   Проводка.Сумма=Сум;
   Движения.Хозрасчетный.Записывать=Истина;
   
   Сообщить(Сум);
   
КонецПроцедуры

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

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

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

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

(0) А зачем рапортуешь на мисте? Отправляй сразу в Контрольную группу [email protected]

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

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

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

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

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

Может кому мое сообщение поможет в принятии решения переходить на 8.3 или нет -  это для меня важнее. Может трабл не в самом прведении, а например в конвертации данных, а ж не идиот теперь все с нуля набивать.  Может кто-то еще проверит и подтвердит, или опровергнет...

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

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

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

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

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

(14) - ладно суть данной темы не в том общаться или не общаться с 1С и каким образом.

(8) проверил - барахлит не журнал, отчет показывает аналогичные цифры, и перезагрузка 1С не помогает, так что все 100% трабл в записи данных

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

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

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

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

(19) +100 :)

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

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

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

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

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

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

Подпишусь

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

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

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

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

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

http://zalil.ru/34553450

Конфа

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

Вы еще попробуйте через
НаборЗаписей = РегистрыБухгалтерии.Хозрасчетный.СоздатьНаборЗаписей();
               НаборЗаписей.Отбор.Регистратор.Установить(Ссылка);

                   Проводка= НаборЗаписей.Добавить();
                      Проводка.Регистратор        = Ссылка;

   Проводка.Период=Дата;
   Проводка.Организация=Организация;
   Проводка.Содержание="Приход готовой продукции";
   
   Проводка.СчетДт=ПланыСчетов.Хозрасчетный._68_2_1;
   Проводка.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.ВидыПлатежаВБюждет]=Справочники.ВидыПлатежаВБюджет._Налог;
   
   Проводка.СчетКт=ПланыСчетов.Хозрасчетный._68_2_2;
   Проводка.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.ВидыПлатежаВБюждет]=Справочники.ВидыПлатежаВБюджет._Налог;


   Проводка.Сумма=Сум;
   Движения.Хозрасчетный.Записывать=Истина;
   НаборЗаписей.Записывать=Истина;

            НаборЗаписей.Записать();

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

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

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

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

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

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

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

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

Ну вот - что и требовалось доказать: http://zalil.ru/34553680 добавил минимальное количество объектов, как в моей базе (в частности субконто и т.п.) Остальное все с чистой базы от Bober. И поведение аналогичное (к выше найденному необъяснимому поведению при проведении из разных форм) - то как у меня. Сумма не переписывается!!!!

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

Окончательные результаты теста: Для более детального рассмотрения немного изменил процедуру в проведении:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
   
   Ген=Новый ГенераторСлучайныхЧисел(0);
   Сум=Ген.СлучайноеЧисло(10,10000);
   
   Проводка=Движения.Хозрасчетный.Добавить();
   Проводка.Период=Дата;
   Проводка.Организация=Организация;
   Проводка.Содержание="Приход готовой продукции";
   
   Проводка.СчетДт=ПланыСчетов.Хозрасчетный._68_1;
   Проводка.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.ВидыПлатежаВБюждет]=Справочники.ВидыПлатежаВБюджет._Налог;
   
   Проводка.СчетКт=ПланыСчетов.Хозрасчетный._68_2;
   Проводка.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.ВидыПлатежаВБюждет]=Справочники.ВидыПлатежаВБюджет._Налог;


   Проводка.Сумма=Сум;
   
   Сообщить(Сум);
   
   Сум=Ген.СлучайноеЧисло(10,10000);
   
   Проводка=Движения.Хозрасчетный.Добавить();
   Проводка.Период=Дата;
   Проводка.Организация=Организация;
   Проводка.Содержание="Приход готовой продукции";
   
   Проводка.СчетДт=ПланыСчетов.Хозрасчетный._68_2;
   Проводка.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.ВидыПлатежаВБюждет]=Справочники.ВидыПлатежаВБюджет._Налог;
   
   Проводка.СчетКт=ПланыСчетов.Хозрасчетный._68_1;
   Проводка.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.ВидыПлатежаВБюждет]=Справочники.ВидыПлатежаВБюджет._Налог;


   Проводка.Сумма=Сум;
   Движения.Хозрасчетный.Записывать=Истина;
   
   Сообщить(Сум);
   
   //Ген = Новый ГенераторСлучайныхЧисел(0);
   //Сум = Ген.СлучайноеЧисло(10,10000);
   //
   //Проводка = Движения.РегистрБухгалтерии1.Добавить();
   //Проводка.Период=Дата;
   //Проводка.Содержание="Приход готовой продукции";
   //
   //Проводка.СчетДт=ПланыСчетов.ПланСчетов1.Счет1;
   //
   //Проводка.СчетКт=ПланыСчетов.ПланСчетов1.Счет2;
   //
   //
   //Проводка.Сумма=Сум;
   //Движения.РегистрБухгалтерии1.Записывать=Истина;
   //
   //Сообщить(Сум);
 
   
КонецПроцедуры

Перед началом записей очистка набора движения Хозрасчетный сознательно не делается (в 8.2 такой алгоритм работал без вопросов да и должен по логике).
1. Перепроведение из обычного интерфейса: проводки плодятся с количеством проведений (добавляются всякий раз независимо от оперативно или неоперативно проводится документ).

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

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


Резюме: грубая ошибка платформы 8.3 (в таком режиме в ней работать нельзя).

Если я не прав - поправьте меня.

(база с эмуляцие ошибки в посте 43, можно переписать модуль на вариант приведенный здесь).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(58)
Спасибо. Просто у меня куча дел делается.
Там есть просто
Движения.Хозрасчетный.Записывать=Истина;
   НаборЗаписей.Записывать=Истина;

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

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

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

(61) -> (60)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(0) хороший у тебя бухгалтерский учет :)

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

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

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

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

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

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

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

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

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

СлучайноеЧисло(<НижняяГраница>, <ВерхняяГраница>)

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

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

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

86 Генератор будет всегда генерить одинаковую последовательность.
Или использовать без параметра

Формирование неинициализированного объекта
Синтаксис:

Новый ГенераторСлучайныхЧисел()
Описание:

Генератор случайных чисел инициализируется временем работы операционной системы с момента старта.

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

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

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

(92) +500 :)

(91)
делал
Ген=Новый ГенераторСлучайныхЧисел(0);
   Сум=Ген.СлучайноеЧисло(10,10000);

   Ген=Новый ГенераторСлучайныхЧисел(0);
   Сум2=Ген.СлучайноеЧисло(10,10000);
   Сообщить(Сум);
   Сообщить(сум2);
Сообщить(сум=сум2);

Выдает
814
814
Да


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

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

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

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

(98) Успокойся в 97 уже попросил прощения.

Да я спокоен, как удав :)

Подготовил, опубликовал и отправил в 1С багрепорт.
http://partners.v8.1c.ru/forum/thread.jsp?id=1152901#1152901
http://infostart.ru/public/190058/

(101) - сэнкс, глядишь может быстрей что-то хоть со скрипом едущее появится :)