В поступлении сумма взаиморасчетов не соответствует итогу по сумме в табличной части. В ТЧ один товар. Сумма взаиморасчетов равна цена * другое количество. Я пробовал на копии добиться такого же результата в пользовательском режиме - безрезультатно, при всех манипуляциях сумма взаиморасчетов = итогу по сумме ТЧ. От меня требуют указать причину ошибки. Ваши предположения, как такое могло произойти?

"Ваши предположения, как такое могло произойти?"Ну наверно кто то пожаловался на вас в спортлото :)
А по факту смотри Отчет взаиморасчеты с документами движения, Сумма взаиморасчетов = Долг на дату документа + Итог по документу

(1) я имел в виду реквизит шапки поступления, СуммаВзаиморасчетов. Реквизит ТЧ Сумма. Так вот СуммаВзаиморасчетов <> Итог("Сумма").

(2) А пользователь, который завел этот док-т, что говорит?

(2) А не будет равна если не закрыт прошлый долг или был аванс или предоплата

(4) Не помню такого.

(2) Если обновляешь табличную часть (например вводишь такое же количество) - результат тот же? Если да - пройдись отладчиком на рабочей базе. Если нет, то... А в этой конфе есть история изменений? Посмотреть что он тыкал и под ним в копии сделать то же самое.

(5) Функция глТекущийДолг(Фирма, Договор, Роль) Экспорт
    Перем Рез;
    
    Если (ПустоеЗначение(Фирма)  =1) или
         (ПустоеЗначение(Договор)=1) Тогда
        Рез = 0;
    Иначе
        
        Если нРег(Роль) = "поставщик" Тогда
            РабРег = Регистр.Поставщики;
            Рез    = РабРег.СводныйОстаток(Фирма, Договор, , , "СуммаВал");  
            
        ИначеЕсли нРег(Роль) = "покупатель" Тогда
            РабРег = Регистр.Покупатели;                                      
            Рез    = РабРег.СводныйОстаток(Фирма, Договор, , , ,"СуммаВал");
            
        ИначеЕсли нРег(Роль) = "все" Тогда
            РабРег = Регистр.Поставщики;
            Рез    =       РабРег.СводныйОстаток(Фирма, Договор, , ,  "СуммаВал");
            РабРег = Регистр.Покупатели;                                      
            Рез    = Рез + РабРег.СводныйОстаток(Фирма, Договор, , , ,"СуммаВал");
            
        Иначе
            Рез    = 0;
        КонецЕсли;
        
    КонецЕсли;
    
    Возврат Рез;

КонецФункции // глТекущийДолг()
Вспомнила?

(7) А как же (2)?

+ (8) Долг и сумма по ТЧ - разные вещи.
Может ТС не правильно выразился, но мне понятно (о чем речь).

ТАм 2 поля ТекстТекущийДолг
Сумма по документу:
ему какой?
Может что то с НДС?

Документ вылечился тем, что ввел другое количество, потом ввел первоначальное. Сумма взаиморасчетов исправилась.
Из всех версий наиболее правдоподобная пока - сбой в программе при записи документов. Из других - редактирование таблиц внешним редактором (злой умысел), а также зомбоящеры и инопланетяне.
(10) Кстати, НДС! надо проверить...

нет, это был не НДС...

(11) Еще к единицам товара есть коэффициент, он тоже влияет

(11) у меня в УТ была подобная фигня то ли с СуммаДокумента то ли ещё с каким то реквизитом. Воспроизвести не удалось, так и не понял откуда сбой возник. Учитывая что за год и несколько десятков тысяч документов это был один случай, то решил счесть за сбой на уровне платформы при записи.

(3) пользователь молчит, как партизан.
(13) одна единица - штука, с коэф = 1.

(14) Звучит правдоподобно. За отмазку сойдет. Так сказать, есть прецедент! Спасибо! :)

(16) На копии попробуйте ТиИ сделать, может это как то прояснит ситуацию

Если файловая, то возможно ондексы слетели, а точнее пользак на вопрос Произвести индексацию БД ответил нет

Штатно:
.
"Итого" по документу - считается простым "суммированием" строк (с учетом вкл/выкл/всумме/сверху НДС). Выражается в валюте документа. "СуммаВзаиморасчетов" (именно она идет в регистры/отчетность по взаиморасчетам) рассчитывается из "Итого" пересчетом в валюту договора.
.
с самопроизвольным "несовпадением" - за все время не встречался. С "кривыми" руками/доделками когда такое несовапдение "внезапно" получается - да это обычная норма. Смотреть всякие загрузки документов из файлов и самописные пересчеты всяких "скидок"/бонусов итд (также м.б. посмотреть историю/следы состоянии заказа поставщика). Также доступ к универсальным обработкам, которые позволяют менять документ неконтролируемо извне (это вряд ли для обычных пользюков). СуммуВзаиморасчетов можно штатно поправить если валюта документа не совпадает с валютой договора - тогда кнопка ВОЗЛЕ СУММЫ ВЗАИМОРАСЧЕТОВ - становится доступной и СуммуВзаиморасчетов можно обычным образом менять вручную.

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

(20) -(17) Делал?

Блин, только сейчас понял что речь про семёрку)

(21) а как ТИИ поможет в кривых цифрах, которые друг с другом связаны только через алгоритм?
этак вообще все что не "сходится" в цифрах у булгахтерш можно было бы лечить...

(23) Запросто, не разу такого не видел? И поди пересчет итогов никогда не делал?

ТиИ подождёт. Пока жду юзера с обеда. Есть документ недельной давности. Паяльник греется...

(24) как пересчет итогов и прочих служеюных данных и ТИИ повлияет на прсотой числовой реквизит шапки документа?

(25) смотри на найденные проблемные документы, может закономерность какая есть? (самое простое - поменять валюту договора, потом подправить документ по СуммеВзаиморасчетов вручную как описано выше через доступную кнопку, потом поменять валюту документа обратно. и все шито крыто. Посмотри еще в ЖР изменения договоров по этим документам.

(26) Да хер его знает о каких полях идет речь, если по долгами так напрямую, а может у него ТЧ в документах попорчены

(28) будем ждать вестей с полей. !cybre в запасе всегда надо иметь 100-ваттный ректальный криптопаяльник ;-)

(29) аналоговый криптоанализатор термально-ректального действия

(25) Как вариант: загрузка, сначала заполняются поля ТЧ, потом сумма документа (напоминаю - загрузка, всё делается программно). А что там грузится - вопрос...
Сумма документа пересчитывается при изменении поле на ФОРМЕ.

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

Сумма взаиморасчетов считается как сумма документа-основания (заказа поставщика), при том, что товара пришло меньше, чем в заказе (согласно складскому приходному ордеру). Чугунную медальку предшественнику!

(32) 1. При программном вводе - сумму документа не присваивать, а суммировать.
2. При изменении ТЧ (добавление, удаление строк, изменение полей (номенклатура, ЕИ, кол-во, цена)) пересчитывать сумму (по строке) и сумму док-та.

(35) В общем, получил я свою картонную медальку за исправление и втык за отсутствие бдительности и навыков телепатии.
"Напились генералы кофею, наелись сдобных булок и надели мундиры. Поехали они в казначейство, и сколько тут денег загребли — того ни в сказке сказать, ни пером описать! Однако, и об мужике не забыли; выслали ему рюмку водки да пятак серебра: веселись, мужичина!"

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

(32) "Ввод поступления на основании заказа поставщику."
- это в конфиге поддерживается штатно. Все что надо сделать в поступлении - скорректировать количество поступления товара (возможно цены и суммы в поступлении также могут отличаться от заказа). Все оставшееся (недогруженное по заказу) повиснет на заказе. заказ поставщику не полностью закрытый - закрыть штатно.
.
у себя в конфиге я допилил дополнительно (отсутствующее в типовом):
- Отмена заказов поставщикам (аналог штатного "Отмена заявок покупателей");
- отчет "Ведомость по Заказам поставщикам" (аналог штатного "Ведомость по Заявкам покупателей")
.
Плюс к этому может быть полезным такая фича, когда ПоступлениеТМЦ на основании ЗаказПоставщику закрывает заказ поставщику  ПОЛНОСТЬЮ, даже если Поступление "меньше" заказа поставщику. Такая фича вкручивается в типовую конфигу буквально 1-2 операторами в нужном месте кода. По такому принципу у меня реализации на основании заявок покупателей сделана. Заявка на 100 тыс, Реализация на 98тыс (брак на складе или еще что) - реализация полностью "закрывает" заявку (клиентура нужное сама дозаказывает в новых заявках, работа по длинным заявкам - не прижилась, клиенты и "мои" менеджеры не тянут такую схему и/или она не нужна - клиенту проще новой заявкой выставить). Такая фича также удобна тем, что ели Заявка на 100, отгрузили на 100, у клиента проблемы, манагеры исправляют документ реализации на 98, заявка не "всплывает" как незакрытая...