На первый взгляд, задача некорректна. Пример:

День Пробег
1 100
2 200
(здесь прошло обнуление)
3 210

(в первый день наездили 100, во второй тоже 100, дальше обнулили и проехали 210)

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

По собственному опыту возни с ODBC и Win Server 2008 x64: 32-х битные программы, скорее всего, не увидят источников, созданных через ODBC Администратора в Панели управления. Надо ODBC-источник создавать из 32-х битного ODBC Администратора. Он лежит в %WINDIR%\SYSWoW64\odbcad32.exe (и запускать его надо "от имени администратора" вроде как, на 100% не уверен - запускал из-под админского FAR'а). Проверено с 1С и некоторыми другими 32-х битными приложениями, база (и драйвер) была Sybase SQL Anywhere 9. После использования 32-х битной версии источники начинают видеться.

Правда, я в итоге подключался к источнику из 1С через COM (ADODB.Connection), а не ВнешнийИсточникДанных (Конфигуратор не видел структуру таблиц во внешней базе - видимо, типы данных столбцов ему не нравились, хотя сами таблицы показывал).

Сразу хочу предупредить: налоговую с 5 знаками после запятой в цене клиент у вас может не принять. Что произойдет при попытке отправить такой документ на регистрацию в Едином реестре - непонятно (скорее всего, при отправке цена будет округлена до положенных 2 знаков, после чего начнет не сходиться арифметика: Цена * Количество <> Сумма, и документ может не принять уже налоговая).

"Структура подчиненности" работает через критерий отбора СвязанныеДокументы. Если в РТиУ добавлялся новый реквизит, то его нужно указать и в критерии отбора, иначе подчиненность по нему не будет видна.
В конфигураторе находим Общие -> Критерии отбора -> СвязанныеДокументы -> Состав -> Документы, ищем РеализацияТоваровУслуг и ставим галку напротив нового реквизита.
(по крайней мере, в УПП так. В УТП могут имена объектов отличаться, но вряд ли)

В конфигураторе проблемная форма открывается?

У меня была похожая беда на SQL-вой базе, когда во-время не обновил платформу и поставил обновление конфы, рассчитанное на более новый релиз. Формы отчетов не открывались и в конфигураторе тоже, он "падал", тестирование и исправление тоже падало. Решилось все так: обновил платформу, удалил из конфы поврежденные формы, скопировал их из cf свежего релиза (просто открыл cf в конфигураторе и перетянул объекты в рабочую конфигурацию). С тех пор перед обновлением конфы всегда проверяю, какая версия платформы указана в требованиях

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

ВЫБРАТЬ
   ЗапросПоследниеДаты.СчетСсылка,
   Поступление.Ссылка
ИЗ
   (
   ВЫБРАТЬ
      Счет.Ссылка КАК СчетСсылка, МАКСИМУМ(Поступление.Дата) КАК МаксДата
   ИЗ
      Документ.СчетВходящий КАК Счет
   ЛЕВОЕ СОЕДИНЕНИЕ
      Документ.ПоступлениеТоваров КАК Поступление
   ПО
      Поступление.Сделка = Счет.Ссылка
   ГДЕ Счет.Дата МЕЖДУ &НачалоПериода И &КонецПериода
   СГРУППИРОВАТЬ ПО Счет.Ссылка
   ) КАК ЗапросПоследниеДаты
ЛЕВОЕ СОЕДИНЕНИЕ
   Документ.ПоступлениеТоваров КАК Поступление
ПО
   Поступление.Сделка = ЗапросПоследниеДаты.СчетСсылка И
   Поступление.Дата = ЗапросПоследниеДаты.МаксДата

Дополнение по теме: думаю, что нашел, при каких условиях этот глюк происходит.

Требуется: сетевая версия 1С 8.2 (с другими не проверял), 2 и более компьютеров (назовем их А и Б), с которых делаются динамические обновления.

Исходные данные: на компьютере А открыт Конфигуратор с изменениями, на компьютере Б открыт "пользовательский" режим. С компьютера А применяют изменения динамически. После этого на компьютере А Конфигуратор закрывают, и открывают его на компьютере Б (не закрывая окно 1С Предприятия).

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

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

На форме открыть Свойства у добавленного поля ввода. Там найти Данные (в самом верху списка), и выбрать нужный реквизит. Он должен быть в группе ДокументОбъект.

И это должен быть именно реквизит документа, не реквизит формы. Реквизиты формы не сохраняются.

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

use ИмяАктуальнойБазы
go

truncate table [dbo].[Config]
truncate table [dbo].[ConfigSave]
truncate table [dbo].[DBSchema]
truncate table [dbo].[Params]
--truncate table [dbo].[Files]
go

insert into [dbo].[Config] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Config]
insert into [dbo].[DBSchema] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[DBSchema]
insert into [dbo].[Params] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Params]
go

В чем вообще проблема: после каких-то динамических обновлений конфигурация оказывается запорчена. Это выражается разными симптомами - не проходит применение изменений из Конфигуратора, юзеры вылетают в винду с ошибкой basic.dll, тестирование и исправление просто закрывается и т.п.

Что нужно для исправления: заменить конфигурацию на исправную из бэкапа. Если бэкапы регулярно не делались - Вам сильно не повезло.
В чем подвох: Конфигуратор это сделать не может. Даже при попытке Загрузить конфигурацию (а не Сравнить/Объединить) Конфигуратор падает на этапе принятия изменений.
Выход: заставить SQL-сервер сделать всю работу.

Конфигурация хранится в таблице Config, ConfigSave = непримененные изменения. Мы просто затираем нашу испорченную конфигурацию и потом вставляем поверх нее рабочую из бэкапа. Данные при этом не страдают. Всего-то и нужно развернуть бекап на том же сервере, но в другую базу, и выполнить скрипт, поменяв имена баз на свои.

А лучше так:

Запрос = Новый Запрос;

Запрос.Текст = "ВЫБРАТЬ
|   КОЛИЧЕСТВО(*) КАК КолВо
|ИЗ Справочник.Студенты";

Выборка = Запрос.Выполнить().Выбрать();
Выборка.Следующий();
Количество = Выборка.КолВо;

"ВЫБРАТЬ
               |    ТекНоменклатура.Ссылка,
               |    ТекНоменклатура.Наименование КАК Товар,
               |    ЦеныНоменклатуры.Цена КАК Цена
               |ИЗ
               |    Справочник.Номенклатура КАК ТекНоменклатура
               |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
               |        ПО ТекНоменклатура.Ссылка = ЦеныНоменклатуры.Номенклатура
               |ГДЕ
               |    НЕ ТекНоменклатура.ЭтоГруппа
               |    И ТекНоменклатура.Родитель = &Родитель
               |    И ТекНоменклатура.ВидНоменклатуры = &ВидНоменклатуры
               |    И IsNULL(ЦеныНоменклатуры.ТипЦен, &ТипЦен) = &ТипЦен
               |    И IsNULL(ЦеныНоменклатуры.Валюта, &Валюта) = &Валюта
               |
               |УПОРЯДОЧИТЬ ПО
               |    ТекНоменклатура.Наименование";

Вот это отберет всю номенклатуру, для которой есть цены (подходящие по условиям), и всю, для которой цен нет.

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