Дмитрий Кинаш

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

2) Использование в оборотном регистре ресурса с названием "СуммаОстаток" - это плохой стиль, который сбивает с толку читателя запроса. Если у вас есть есть приходы и расходы, то их нужно писать в просто "Сумма". А если вы хотите (зачем?) по дням хранить рассчитанные остатки, то вам нужен не регистр накопления - а регистр сведений.

напишите стандарт, по которому лично вы работаете, и которого придерживаетесь.

Главный стандарт для всего: здравый смысл!

Сначала сделайте функционал, который просят от вас в ТЗ, а потом с помощью подсистем и функциональных опций формируйте удобные рабочие столы пользователям. Какая разница из скольких подсистем вы можете открыть справочник Сотрудники, если у вас в принципе неправильно считается зарплата?

Вы явно что-то уже "испортили". В типовом пакете для Документооборота можно без проблем добавлять свои свойства - мой DMInternalDocument уже наполовину состоит из новых реквизитов.

0) Посмотреть журнал регистрации на предмет ошибок
1) Проверить права. Для теста можно выполнить запрос под учеткой админа.
2) Проверить наличие подписки на событие ПередЗаписью и проверить ее модуль. Обращать внимание на директивы компиляции и попытки вывода интерактивных сообщений.
3) Настроить широкое логирование с помощью технологического журнала и анализировать логи.

Если брать исключительно озвученные предпосылки:
1) была файловая и стала серверная
2) тормоза при поиске и последующем выводе всех ссылок на документы по договору

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

https://forum.infostart.ru/forum9/topic158211/

Все зависит от устройства. Хреновые датчики будут и час получать координаты. Хорошие за пару минут ориентируются.

Плюс в самом телефоне можно включить доуточнение координат по сотовым вышкам и окружающим WiFi-сетям, тогда даже "слепые" телефоны начнут выдавать похожие на "правду" координаты.

Из описания метода в синтаксис-помощнике:

Допустимые параметры:
Л (L) - Код локализации. По умолчанию используется код локализации, установленный в операционной системе. Примеры кодов локализации: ru_RU - Русский (Россия), en_US - Английский (США). В настоящий момент поддерживается только русский язык. Если код локализации не указан, то используется текущая локализация пользователя.

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

2) Да. При публикации на веб-сервере можно указать логин/пароль для анонимного входа как в целом, так и для конкретного веб-сервиса.
3) Да. При указании ссылки на веб-сервис использовать полный формат с указанием логина и пароля.

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

1) Делаешь запрос к таблице заказов и выбираешь нужные поля (номер, дата, покупатель и т.д.)
2) Делаешь обход результата запроса и формируешь описание заказа для таблицы.

Дело не в управлении, а в типах данных. Вы видите следствие.

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

Где-то в документации, наверное, мелким шрифтом написано какие типы можно в каких режимах использовать... Но на практике, когда видишь такую ошибку, то просто переписывай работу с параметром на структуры и массивы.

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

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

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

1) руками, в справочнике Банки.

2.1) скачать - нигде, линейка 7.7 давно не обновляется и поддерживается исключительно в рамках доработки регламентированных отчетов; более того, первое поколение 8-х конфигураций, которые сменили решения 7.7, тоже уже давно объявлены устаревшими, сняты с продаж и давно не поддерживаются.

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

Посмотрите как в вашей конфигурации это делается "руками" в пользовательском режиме, а потом повторите в коде.

Вопрос поставлен некорректно.

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

Скорее всего есть какой-то одноимённый общий модуль, где полный набор инструментов для работы с этим справочником. Если общий модуль не находится, то можно поискать в модуле менеджера этого справочника.