Обновляю правленную базу бухгалтерии 568. Md готовился под ХР и семеркой, блоками, md с блоками правок сохранялись с текущей кодировкой семерки и ХР соответственно, потом объединялись под ХР. Полный md сохранен с текущей кодировкой ХР.
При объединении с md на копии боевой базы SQL дает ошибку "CREATE UNICUE INDEX terminated because a duplicate key was found for index ID 2.Most significant primary key is '1FUPQ '. SQL State: 01000.Native 3621... The statement has been terminated.".
Предполагаю, что проблема в неправильной кодировке, надо было с кодировкой "русский, белорусский и т.д." сохранять. Что можно сделать сейчас? Поможет ли накат этого md на боевой в пустой базе dbf с сохранением в русской кодировке?

(90) можно в скуле проапдейтить табличку, чтоб позиция дока была такой же, как  в _1sjourn

(92) Как я поняла, придется менять время документов, операций и проводок в закрытых периодах.
Можно ли при этом обойтись без перепроведения, чтобы не посыпались данные в закрытых периодах? Какие таблички в SQL при этом и как стоит поменять, причем так, чтобы не посыпался 1С?

(93) _1sentry/_1soper + файло итогов пересчитать потом

Вот, нашёл тут :)


///******************************** ADirks 03.10.2013 ************
Функция сзТаблицы()
    сз = СоздатьОбъект("СписокЗначений");
    сз.ДобавитьЗначение("_1SACCSEL");
    сз.ДобавитьЗначение("_1SENTRY");
    сз.ДобавитьЗначение("_1SOPER");
    сз.ДобавитьЗначение("_1SSBSEL");
    Возврат сз;
КонецФункции

Функция тзПроводки()
    ТекстЗапроса = "Set NoCount ON
    |
    |-- Время проводки не совпадает с временем документа
    |
    |select
    |    Right(_1sJourn.Date_Time_IDDoc, 13) [Doc $Документ],
    |    _1sjourn.IdDocDef,
    |    _1sjourn.IDDoc,
    |    _1sjourn.DocNo,
    |    _1sjourn.Date_Time_IDDoc,
    |    _1sentry.Date_Time_DocID,
    |    count(*)
    |from
    |    _1sjourn (nolock)
    |    INNER JOIN _1sentry (nolock) ON (_1sjourn.IDDoc = _1sentry.DocID)
    |where
    |    _1sjourn.Date_Time_IDDoc <> _1sentry.Date_Time_DocID
    |GROUP BY
    |    _1sjourn.Date_Time_IDDoc,
    |    _1sentry.Date_Time_DocID,
    |--    Right(_1sJourn.Date_Time_IDDoc, 13),
    |    _1sjourn.IdDocDef,
    |    _1sjourn.IDDoc,
    |    _1sjourn.DocNo
    |";
    тз = ЗапросСКЛ.ВыполнитьИнструкцию(ТекстЗапроса);
    Возврат тз;
КонецФункции

Функция тзТаб(Имя)
    ТекстЗапроса = "Set NoCount ON
    |
    |-- Время проводки не совпадает с временем документа
    |
    |select
    |    Right(_1sJourn.Date_Time_IDDoc, 13) [Doc $Документ],
    |    _1sjourn.IdDocDef,
    |    _1sjourn.IDDoc,
    |    _1sjourn.DocNo,
    |    _1sjourn.Date_Time_IDDoc,
    |    "+Имя+".Date_Time_DocID,
    |    count(*)
    |from
    |    _1sjourn (nolock)
    |    INNER JOIN "+Имя+" (nolock) ON (_1sjourn.IDDoc = "+Имя+".DocID)
    |where
    |    _1sjourn.Date_Time_IDDoc <> "+Имя+".Date_Time_DocID
    |GROUP BY
    |    _1sjourn.Date_Time_IDDoc,
    |    "+Имя+".Date_Time_DocID,
    |--    Right(_1sJourn.Date_Time_IDDoc, 13),
    |    _1sjourn.IdDocDef,
    |    _1sjourn.IDDoc,
    |    _1sjourn.DocNo
    |";
    тз = ЗапросСКЛ.ВыполнитьИнструкцию(ТекстЗапроса);
    Возврат тз;
КонецФункции

///******************************** ADirks 03.10.2013 ************
Процедура Показать()
    сз = сзТаблицы();
    Для н = 1 По сз.РазмерСписка() Цикл
        Имя = сз.ПолучитьЗначение(н);
        тз = тзТаб(Имя);
        тз.Сортировать("Doc", 1);
        РедакторТЗ(тз, Имя);
    КонецЦикла;
    //
    //тз = тзПроводки();
    //тз.Сортировать("Doc", 1);
    //РедакторТЗ(тз);
КонецПроцедуры

Процедура Выправить()
    сз = сзТаблицы();
    Для н = 1 По сз.РазмерСписка() Цикл
        Имя = сз.ПолучитьЗначение(н);
        тз = тзТаб(Имя);
        РедакторТЗ(тз, Имя);

        тз.ВыбратьСтроки();
        Пока тз.ПолучитьСтроку() = 1 Цикл
            ЗапросСКЛ.Выполнить("Set NoCount ON
            |UPDATE "+Имя+"
            |    Set Date_Time_DocID = '"+тз.Date_Time_IDDoc+"'
            |WHERE
            |    DocID = '"+тз.IDDoc+"'
            |");
        КонецЦикла;
    КонецЦикла;
КонецПроцедуры

(95) ну, тесты проверок, в своё время кто тока не писал :))
В одну кучку Z1 собирал.. в своё время
на 1cpp валяются

чорт, не заметил про update внизу
..

Мне быстрее написать, чем найти готовое :)

(94), (95) Ребята, милые вы мои, дорогие, спасибо огромное за помощь!) Сейчас посмотрю тексты процедурок).
Только закончила вразумлять бухов).

(98) А Вам мне просто в ножки поклониться надо!) Как это ни выглядит смешным сегодня - но хочется!)

(95) 1. Что за РедакторТЗ(тз, Имя)? Не наблюден.
2. При просмотре наискось показалось, что время документа правится по времени операции. Для ситуации с 23:59:50+ операции записаны на незнамо когда. Надо бы наоборот - операцию к документу привязать)... Возможно ли это?) Естественно, документы перед этим поднять на пораньше, причем их надо записать, но не перепроводить - в закрытых периодах...

РедакторТЗ() - человеческая замена для тз.ВыбратьСтроку()
можно произвести обратную замену

вообще-то в данном случае во все таблички пишется дата-время из _1sjourn. Подозреваю, что в принципе без разницы что к чему приводить, лишь бы одинаково было.

(102)Ага, значит, можно и в операциях менять?) Уррряяяя!) А то ж закрытые же ж периоды же ж)... Через полчасика возьмусь).

(102) А это все можно делать под сервером скульным 2000?) Я так поняла, что да?)

Ну да, можно операции, и для SQL.
Собственно, это боевая обработка, коей мы обнаруженный косяк правили.

(105) А что за ЗапросСКЛ и ВыполнитьИнструкцию?

(106)
В яндексе забанили?
http://yandex.ru/yandsearch?text=ВыполнитьИнструкцию+1с&lr=213

(107) Хорошо, неправа насчет ВыполнитьИнструкцию. А как определить ЗапросСКЛ? Код ругается. В гугле  про запрос СКД только вижу. Ругай, переживу, только поверни в нужнгую сторону. Это же не 1Совский запрос.

(108) И, потом, ВыполнитьИнструкцию - это 1С++? У меня не установлен.

(108)
ЗапросСКЛ = СоздатьОбъект("ODBCRecordSet");

(109)
ЗагрузитьВнешнююКомпоненту("1cpp.dll") воткни перед этим

(108)

Вам привели пример. Ваша задача адаптировать его.
соответственно пример написан на чистом tsql.
и для его исполнения достаточно иметь ms SQL Query Analyzer
либо любой другой инструмент, позволяющий исполнять запросы.

(110),(111) Вот это другое дело). Сделаю).
(112) И так попробую.

Ребята, простите, что так надолго замолчала.  Начальник уходил в отпуск, и, раз сразу не получилось, не стал рисковать и вернул базу, в которой ваяли сутки, на место. Мне пришлось разбираться и восстанавливать информацию.
Теперь пора заняться основной темой).Я посмотрела код в 95, и вижу, что им можно воспользоваться напрямую, спасибо огромное! Но есть один вопрос: поскольку много доков на 23:59:59, то не стоит ли прежде прибивания операций и проводок к ним поменять их время? И можно ли это сделать прямо в 1Се для закрытых периодов - т.е.перезаписать с другим временем без перепроведения и потом прибить к ним все SQLем?
Или, учитывая кривость таблиц, лучше все сделать SQLем? Если да, то как поменять им время? Не скажется ли UPDATE таблиц из сзТаблицы() еще на чем-то 1Свском? Потому что сделать запрос по образцу я смогу, а вот дальше боязно)...

(114) проапдейтить таблички.. это фигня.. тебе придётся потом бух итоги пересчитать.

на счет исправления времени в табличках проводок - вам Алексей постами выше дал рабочий код..

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

По мне, я бы исправил всё и пересчитал всё.

(116) Я про код написала-код замечательный). Но он для прибивания операций и проводок к докумен6там, а мне прежде время доков менять надо). Об этом и страх)

(118) Конечно, все до ума доводить надо). Вопрос - время доков из 1Са менять или все сделать SQLно, добавив в код про сдвиг доков?

И потом пересчитать итоги...

Ребята, я все перечитала, мне помогают с написанием процедур на SQL, но, все-таки не все понимаю еще. Базу вернули в исходное состояние, до обновления. Сейчас мне надо сперва обновить - попасть на ошибку - убрать уникальность в DDSе - закончить обновление - удалить _1scrdoc  - сделать ТИИ с 1 галкой - включить уникальность обратно (или сперва включить уникальность, а потом ТИИ?, или TRUNCATE TABLE dbo._1SCRDOC и далее в Тии , галка пересчет служ. данных?). И потом SQL-й процедурой подтянуть время документов в 1sjourn, а потом к ним привязать _1SACCSEL, _1SENTRY, _1SOPER, _1SSBSEL? В середине путаюсь, про обновление. Помогите еще раз, очень прошу!

(122)+ Или вообще сперва наладить время документов, а уж потом обновлять?

(123) Попробуй для начала запустить тот скрипт, который я приводил, и накатывай обновление. Вроде должно сработать.
С временем остальных доков я бы не заморачивался.

(124) Скрипт из (95)? До обновления? Или все же сперва обновить-ошибка-убрать уник.-законичть обновление-TRUNCATE TABLE dbo._1SCRDOC-пересчет служ.данных?
А насчет времени остальных доков не все так просто. Если связь доков с операциями и проводками разорвана из-за того, что из в 23:59:59 в какие-то даты собралось слишком много, скажем, больше 10000, то в новых доках, формирующих проводки, и записанных в эти даты, опять разорвутся связи с проводками и операциями. Поэтому и хочу поднять их с 01:00:00, как в одном месте рекомендовалось. Причем делать это придется скульно, чтобы не перепроводить доки в закрытых периодах. А потом то ли пересчитывать итоги, то ли они встанут на место при пересчете служебных данных - тоже хочу уточнить... Ведь доки буду поднимать в том же порядке и в пределах той же даты, так что итоги не должны полететь как бы?

Ага, из (95), до обновления. Все те манипуляции с уникальностью индекса на самом деле были проделаны, чтобы быстренько обновиться, а потом уж разбираться. Если исправить ситуацию до, то во время обновления проблем уже не будет.

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

(126) А без обновления этот разрыв нам нервы трепать не будет? На итоги это не повлияет?

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

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

(127) В том то и дело, что ни на какие итоги не влияет. Я, честно говоря, сильно удивился, когда стали смотреть что к чему, и выяснили, что документов с одинаковым временем - до чёрта. Т.е. прям полностью идентичные части Date_Time в Date_Time_IDDoc.

(129) насчёт разрывов я бы не был так уверен - там время вроде ни при чём. Что касается договоров, так это достаточно распространённая ситуация, связанная с кривизной ручек 1Снегов из 1С.

(130) Насчет разрывов, как мне кажется - дело в нарушении связей как раз между документами-основаниями и подчиненными, т.е. в нашей любимой табличке, нет? Этого до обновления ведь не было...
А вот с договорами что делать мне, бедной?) Убьют ведь, а Новый Год на носу)...

Ну так то да, если _1scrdoc криво заполнилась, то ВыбратьПодчиненныеДокументы() тоже будет криво работать. Но тут ничего не могу сказать, лечение по фотографии не мой профиль.
С договорами вообще сложно. Надо прям с каждой конкретной ситуацией разбираться. Причём вопрос из чисто технического становится организационно/бухгалтерским.

(132) Пока пришью операции  и проводки, обновлю, а там посмотрим по месту). Значит, итоги при таком раскладе не трогаем?) Ура!)

(132) Для начала - очередное огромное спасибо!)

Ну там, ура не ура, а попробовать надо. Время, судя по всему, есть :)

(135) Дошли до дела, наконец-то). Написана процедурка в SQL, которая прибивает время в _SACCSEL,_1SENTRY,_1SOPER,_1SSBSEL по _1sJourn.
Стало ясно, что после обновления бухи начнут править и создавать новые документы в прошлых датах, где все прибито будет, но время 23:59:50+ у доков останется, и мы опять получим тот же компот. Посмотрела триггер из (68). В нем по событию такому правится только _1SOPER, причем время, если оно бредово, заменяется на 23:59:59, как я поняла...
Вопросы: 1) Надо ли править остальные 3 таблички аналогично или, по (73), ошибка возникает в _1SOPER и потом мигрирует по остальным таблицам? В какой момент мигрирует тогда? После отработки триггера? 2) Не повлияет ли это действо еще на какие-то вещи в базе? На таблицы, вроде, нет, я просмотрела DDS... 3) Что делать с _1scrdoc и когда? Удалять, TRUNCATE? Мозги окончательно всмятку.

(136) Еще момент: база была обрезана, т.е. были на начало 2012 года созданы начальные остатки, а все старье помечено на удаление. Сейчас в _1sJourn моей помощницей в SQL обнаружено в 2011, помеченном на удаление, году, у ряда документов бредовое время - больше 23:59:59 в 36-ричной системе. Те годы не волнуют, но возможно ли повторение такого в текущих годах? Если да, то стоит ли повесить триггер аналогичный и на _1sJourn? Если да, то скажется ли это сильно на производительности?
Ради подробного ответа согласна на любые сомнения в качестве моей ДНК!)

(137)
на сколько больше ?

(138) Вопрос непонятен.

(139)

на сколько  сенкунд (10 тысячных секунды) больше
чем   23:59:59 в 36-ричной системе

вполне возможно, что это время в пределах 1 секунды

(140) Сейчас посмотрим.

Вот что найдено:
полный день в долях секунд = 864000000
В _1SACCSEL
имеем EAGG40 =     864090000. Полностью строка:
5562356    518       3Z2            15T2D       20120531EAGG40 15T2D       0    0

В _1sJourn:
1154418    45264      OWJ3       45164    20    20110111WKESG   OWJ3            451642011        07-0000015              4    1    0    4
int=1969200000
Дальше коммент программиста SQL:
Возможно, в 11 году по-другому считывалось время
20110111WKESG, и по новым правилам должно быть написано так:
20110111 WKESG  
тогда это не ошибка.
Мой коммент: 1Са она не знает, сишник.

(140) Ответ в (141). Но писала вслед за сишником, второпях. Вижу, что ее коммент не в тему, главное, что время бредовое есть и в _1sJourn/

(143)

что скажет РазобратьПозициюДокумента("20120531EAGG40 15T2D",Дата, Час, Мин , Сек, Документ) ?

(144) Прости, что не сразу отвечаю - переключилась на подготвку болванки 570 релиза.
Код:
    //Перем ДатаДока, Ч, М , С, Док;  
    
    ДатаДока='01.01.01'; Ч="";М="";С=""; Док=ПолучитьПустоеЗначение("Документ");
    
    Позиц=РазобратьПозициюДокумента("20120531EAGG40 15T2D",ДатаДока, Ч, М , С, Док);
    Сообщить("Позиция = "+Позиц+"; ДатаДокумента = "+ДатаДока+"; Ч = "+Ч+"; М = "+М+"; С = "+С
            +"; Документ = "+Док);
Ответ:
Позиция =   .  .   00:00:00; ДатаДокумента =   .  .  ; Ч = 0; М = 0; С = 0; Документ =
Одинаково - через Перем или явно нач.значения задавать.

(144) Правда, это я в боевой базе смотрела, а она работала в копии непосредственно на SQLе. Причем копия была создана не по нашим правилам, а чисто скульная. Возможно, это неважно, но попрошу завтра (сегодня она уже ушла) посмотреть то же самое в моей тестовой базе, и там прогоню этот пример, если ошибка обнаружится.

(136) насчёт триггера, вроде же Паша всё расписал в той теме на 1cpp?
В том то и прикол, что для доков с операциями date_time_iddoc берётся из _1soper, а вовсе не из _1sjourn. Это "немного странно", но факт. Именно поэтому триггер и навесили на _1soper - достаточно там исправить, дальше само разойдётся.
Насчёт crdoc ничего сказать не могу - не исследовали за ненадобностью.

(147) Т.е. время формируется в _1SOPER при записи документа, триггером правится, и при проведении остальные таблички цепляются за _1SOPER? И почему в _1SOPER ставим триггером время не такое, как в журнале, а просто конец дня?
И насчёт crdoc - мне неясно, как с ней быть - там есть дата и время подчиненных доков. Если я перед обновлением прибью все существующее к _1sjourn по 4 табличкам, что, сразу обновление запускать, и crdoc просто пересчитается? А итоги надо пересчитывать после приколачивания или после обновления? Или при таком раскладе все и так будет замечательно?)

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

(147)+ Еще раз перечитала все, вроде правильно понимаю?). Для верности пишу еще раз). 1. Меняю время в 4 табличках по _1sjourn. 2. Вешаю триггер на _1SOPER. 3. Обновляю. 4. Пересчитываю итоги. Все правильно?)

(150) Почти так. Триггер лучше вешать после обновления, потому что 1С может его и прибить (не проверял, у нас все триггера тупо пересоздаются после каждого обновления).
Что касается crdoc, то попробую завтра посмотреть, чего там происходит.

(150)+ Напрягло бредовое время в (142) - и в помеченном на удаление 2011 году в _1sJourn, и в рабочем 2012 году в _1SACCSEL. Ну ладно, во втором случае оторвалось все, а в журнале? Как 1С обрабатывает пометку на удаление в документах? База обрезана, все до 2012 года помечено на удаление, я писала в (137). Что делать, если бред со временем в журнале? База бухгалтерская, вроде как не очень важно, что когда в течение суток, но все же они ручками всегда переставляют приходы прежде расходов...
(151) Жду про crdoс - и заранее благодарна за любую инфу, вообще Вы меня капитально выручили уже, Алексей, спасибо! Очень большое!

(151) Пост (152) адресован Вам). Ошиблась).

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

ё..
порабы было ужо давно забить на эту базу
:))

(154) А что Вы думаете про бредовое время в помеченных на удаление доках в _1sJourn?
(155) Это как?) Дело не доделано, есть вопросы, знания я получаю только в этой ветке нужные. Да, медленно, прошу прощения. Но, будь я корифеем, вопросов и не было бы). В любом случае, спасибо за советы!) В этот раз очень помог Алексей, в другие разы Вы давали замечательные советы, за что я очень благодарна!) А сколько мне помог Михаил, это вообще слов нет... Спасибо вам, дорогие, что не плюете на нас с высокой1 горки своих знаний и умений!) Теперь, порой, по мелочи, и я кому-то помогаю)...

>А что Вы думаете про бредовое время в помеченных на удаление доках в _1sJourn?

я бы оставил как есть

(157) Еще раз о прошлых годах. До 2012 года все доки в базе помечены на удаление или сделаны непроведенными. В 4 табличках вся инфа по ним есть, но, насколько я понимаю, невидима для 1С. Вижу, что при изменениях в доке (проведен-непроведен-помечен на удаление) время в табличке журнала не меняется.
Вопрос: прибивать ли время к журналу в 4 табличках и за те годы? Не повлияет ли это на что-то? Насколько я поняла, нет и можно сплошь таблички прибивать?
И как быть, если в журнале время бредовое? Это только в прошлые годы бывало. Его подправлять на конец дня - все равно непроведенные доки?

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

(158)можешь вообще прибить эти доки.. насовсем, если ссылок по ним нигде нет.

+159 в табличке операций.. нет строчек с доками, помеченными на удалени или не проведенными.

(161) там нет, а в табличках проводок и т.д. есть, потому и спросила.
(160) Да, это обязательно сделаю.

(160)+ Кстати, ссылки в скле где смотреть - в crdoc? Или где-то еще? А то через 1С долго искать.

(163) например
http://infostart.ru/public/60727/

(164) Чего-то не пускает, пароль, видно, забыла. А можно сюда линкануть?)

http://rusfolder.com/39429750

(166) И тут требует авторизации, или не читает. Попробую дома вечером из Оперы, что-то тут Эксплорер барахлит к тому же). В любом случае, спасибо большое!) Прошу прощения, что не сразу отвечаю - болванку готовила для обновления на 570).

теперь ждем мучений по работе с 1с++...

и еще через месяц-другой (постов 300)

... увольнения

(168) Ты о чем? С 1С++ работать мне нельзя в этой базе, поэтому все процедуры написаны в SQL. Если все сработает, все нормально. А если нет, и даже если меня уволят, что маловероятно, то зачем так?

(169)
стеб по поводу количества времени и постов этой ветки.

+ (170)
кстати сегодня месяц, как создана тема

(170) И что? И зачем стеб? Жаль.

(172)

"Жаль" не сотвествует (108)

(173) Соответствует, но не теме ветки, а другой теме. Но об этом я больше не пишу.

Ребята, существенно ли по каким-либо параметрам, где делать пересчет итогов - в режиме Предприятия или в Конфигураторе?

На тестовой базе все обновилось, осталось итоги пересчитать и добавить триггер). Всем помогавшим спасибо огромное!) Ну и надо проверить, конечно, не вылезет ли еще какая-нибудь бяка). Дай Бог, чтобы все прошло благополучно).

И еще: нашла ссылку еще с 2009 года, что под 25 релизом -  а у нас именно он - полный пересчет итогов может глючить под 25 платформой, а у нас именно она, и в любом случае, работает очень медленно. И что есть некая процедура чисто SQL-я, которая может быстро итоги пересчитать. Есть ли у кого-то информация по этому поводу?
Сразу - 27 релиз предлагала поставить 100 лет назад, но из-за сложностей работы с удаленными базами на это не пошло мое начальство. Теперь уже важно все добить и с весны начать все переводить на восьмерку.
И еще: Я обновила, но переиндексацию не делала, сразу запустила полный пересчет итогов в режиме Предприятия. А сейчас думаю - может, надо было сперва восстановить crdoc? И вообще итоги считать в Конфигураторе или найти быструю и более верную скульную процедуру?

(177)
зачем нужен пересчет итогов, если в результате Ваших исправлений итоги не должны были поменяться.

(178) Я тоже так думала, но... последние посты см. (150), (151). И до того было.

вот загатовка для обработки пересчета би
http://softpoint.ru/article_id46.htm

(179)
" пересчет служ. данных" <> "пересчет БИ"

"И до того было" -  про пересчет пересчет БИ не было советов.

(181): (94), (115), (117), (118), (150)-(151).
Но, кстати, итоги пересчиталлись аккуратно, с боевой базой совпадают.

(181)+ А вот насчет пересчета служебных данных не было речи, если 4 таблички (операции и проводки со всеми связями) прибиваются к журналу.

(182)
хорошо. совет про пересчет БИ был.

Для пересчета итогов по регистрам, и двиганья ТА в НЕмонопольном режиме есть такая штука: УстановкаТА, исходный вариант здесь: http://www.dev.citykirov.ru/

её потом кто-то допиливал, на предмет (кажется) оборотных регистров, и измерений с типом Неопеределено где качать найти теперь не могу, положил на http://rusfolder.com/39432040

(185)

для пересчета регистров есть обработки на 1cpp и infostart

а вот для БИ - не встречал.

(185), (186) Я их нашла, там и про БИ что-то есть, но, не разобрав, и не проверив, использовать пока не рискую. Запустила обычный пересчет в режиме Предприятия. Долгий он, правда...

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

(185) Спасипки

Ну вот, вроде все ОК). Всем огромное спасибо за помощь!) Чтоб у вас все всегда получалось, ребята!!!)

(190) более правильно этот тост надо говорить так:

"дай бог вам между ног крепкого здоровья!"