Здравствуйте, уважаемые. Прошу помочь в следующей беде.
Есть БД (Акцес, разумеется), в которую вносятся сведния о клиентах Компании, а также данные мониторинга этих клиентов. Имеется ввиду следующее - к клиенту раз в неделю ходит Агент, заполняющий Отчёт (отчёт генерируется Акцесом на основании данных о клиенте и дне недели, в который данного клиента нужно посещать, и естественно о дне недели, когда печатается отчёт). Отчёт состоит из полей "Код","Тип", "Имя клиента", "Адрес" и ещё 50 (не более) полей, в которые вносятся данные о параметрах клиента. В отчёте до 30 строк. В ходе заполнения отчёта Агент проверяет торговую точку на предмет наличия и ассортимента товара, причём мониторится товар "Нашей" фирмы и товар конкурентов, из чего делается вывод о ДОМИНИРОВАНИИ и МастСтоке (Must Stock - обязательный ассортимент товара).

Эта БД ведётся довольно давно, соответственно в ней уже накопилось порядочно сведений о клиентах и развитии ситуации в их магазинах.

Однако разработчики БД (не я делал, я олух) весьма неудобно сделали способ внесения данных из этих отчётов в базу, а именно: для внесения строки записи открывается одна форма, куда вносится "Регион" (то есть определённая территория, подведомственная "Нашей" фирме), фамилия Агента, дата заполнения отчёта (это заголовок формы, я разобрался), после чего в области данных становится доступным поле ввода "Кода" клиента (4-5 цифр, но это отображаемый код клиента, который не имеет ничего общего с ключом таблицы "Клиенты"). Далее щелчком по кнопке (к этому ещё вернусь) вызывается ещё одна форма, где в заголовке выводится "дата", "Код клиента" (отображаемый), его адрес (магазина), а в области данных - три поля "Код поля" (код тех полей из отчёта, которых не более 50), "имя поля" (после ввода кода поля становится видно - что это такое), "значение поля" - собственно, куда нужно ввести данные. "Код поля" - это 1-3 цифры (+Enter), значение поля - от 1 до 100 (но есть поля, которые в отчёте заполняутся "галочкой" - есть/нет позиция в магазине - для таки полей ставится 1 и Ввод), слава Богу, не заставляют вбивать нули

Простой подсчёт Вам подскажет, что при среднем количестве заполненных полей 30-35 (на строку) и 20-25 строк мне приходится за один отчет долбить клавиатуру 22000-25000 раз, а отчётов - три, а дней недели - пять, что приводит к туннельно-кистевому синдрому.  

Самое обидное, что отчёты практически не меняются, на что есть несколько причин:
1. Ассортимент в большинстве магазинов относительно стабильный, а если тип клиента "Бар" (откроюсь - мы оптом торгуем пивом группе клиентов на определённой территории) - то вообще не меняется.
2. Если Агент заболел или уехал на сессию (есть студент такой у нас) - то он просто перекатывает старый отчёт на "свежем" бланке.  

Вот я и хочу Вас попросить мне помочь:
1. Сделать форму, где отображались бы "Территория", "ИмяАгента", "Нужная дата", потом на основании этой даты выбирались бы точки, которые должны быть посещены в такой день недели, а для них данные предыдущих визитов, причём делался бы "ситнез" цифр (над полями должны быть "галочки", можно ли увеличивать/уменьшать это поле), а также вычислялись бы результирующие поля (количество "фейсингов" пива для каждой фирмы)
2. Предоставить возможность пользователю (то есть мне) изменить любое синтезированное значение (если в реальном отчёте данная позиция отличается от "синтезированной" цифры), причём до полного обнуления (не ноль, а Null).
3. После проверки отчёта вывести данные в таблицы, в которых обычно хранятся эти самые данные (их две, Visits и VisitDetails, связаны по ключу VisitId первой из них, тип - код репликации).

Вот такая задачка, простите за огромный размер, тем более, что это не всё описание проблемы и требуемой функциональности.
К сожалению, выложить базу не могу, так как она в архиве весит 12МБ 

Уважаемые форумчане, меньше не получается, извините.
Уточню немного задачу.
Есть таблица Visits, поля:
1. VisitId - счётчик, код репликации
2. PsId - ключ, числовой, код репликации (для связи с таблицей PS)
3. Date - ключ, Дата/время, краткий формат даты (содержит дату визита)
4. MerchID - ключ, числовой, код репликации (для связи с таблицей Merchandisers - агенты)
5. TimeStamp - Дата/время, полный формат даты, значение по умолчанию Now() (это за нами из центрального офиса следят, в какое время мы отчёты заполняем)

Есть связанная с ней таблица VisitDеtails, её поля:
1. VDID - счётчик, код репликации
2. VisitId - ключ, числовой, код репликации (для связи с таблицей Visits)
3. Number - числовой, длинное целое (собственно, содержание поля отчёта конкретного визита)
4. TimeStamp - Дата/время, полный формат даты (аналогично полю TimeStamp из таблицы Visits)
5. FieldId - ключ, числовой, длинное целое (для связи с таблицей CardFieldsForDR - индекс поля, в отчёте 50 полей, не считая кода, имени и адреса точки, этот индекс служит для определения соответствия ИНДЕКСА поля его КОДУ, причём индекс не отображается в отчёте, а КОД ПОЛЯ - отображается, по нему вводятся данные).

Теперь логика работы:
Отчёт состоит из полей кода, имени и адреса точки, а также 50 информационных полей, имеющих свои КОДЫ.
При вводе данных в отдельной форме вбивается дата визита и код точки, после чего её PsId попадает в Visits.PsId , а дата в Visits.Date . В поле Visits.MerchID попадает код агента (мерчандайзера).
Вызывается отдельная форма, для которой источником данных служит VisitDеtails, отфильтрованный по Visits.VisitId . Здесь вбивается КОД ПОЛЯ (а подставляется ИНДЕКС) и его значение для данной точки в данный день.
Не все информационные поля заполнены - это нормально (то есть данной позиции в точке нет), соответственно, нельзя ожидать (и не требуется), чтоб в таблице VisitDеtails была непрерывная последовательность "Поле1", "Поле2", "Поле3"..."Поле50".

Таким образом, "параллельная" форма отчёта превращается в "последовательную" форму таблицы VisitDеtails.

В базе есть таблица DR, которая обновляется перед созданием печатной формы отчёта для каждого агента, и я нашел способ использовать её для выборки требуемой мне истории, то есть содержания всех заполненных полей всех предыдущих отчётов по выбранным точкам. Для этого я сделал (конструктором) запрос на создание таблицы LeveratorHistoryForDailyFull, куда попадают поля: из таблицы DR - код, имя и индекс ТТ (помогает для связи с таблицей PS), из таблицы VisitDеtails - все данные FieldId и Number (собственно - что ищется), из таблицы CardFieldsForDR - КОДЫ полей, соответствующие ИНДЕКСУ FieldId (мне так проще ориентироваться в их идентификации) Во вложении рисунок с частичным результатом этой таблицы.

Но вот вопрос: полученные данные можно отсортировать для каждой отдельной точки, а мне нужно разделить последовательность данных на "параллель", то есть дополнительная таблица, с полями "КодТТ", "Поле1", "Поле2", "Поле3"..."Поле50", причём требуется, чтоб данные из VisitDеtails.Number для поля с FieldId=5 (код поля 10 = FormFieldNumber) попадали в "Поле11" (порядковый номер в информационных полях отчёта)
  

Это сообщение отредактировал(а) dionisiu - 20.5.2006, 09:51

Присоединённый файл ( Кол-во скачиваний: 2 )
 __________________.GIF 63,37 Kb

Для вышеуказанного рисунка прикладываю ещё один

На нём изображена таблица с набором кодов, названий, адресов и типов ТТ, которые должны быть посещены в указываемый день (данные в строках).
Теперь мне нужно сделать так, чтоб в таблицу DR из таблицы LeveratorHistoryForDailyFull попадали усреднённые значения полей для каждой ТТ. 
Для поля DR.6 нужно выбрать в таблице LeveratorHistoryForDailyFull среднее значение LeveratorHistoryForDailyFull.Number для  всех LeveratorHistoryForDailyFull.FormFieldNumber=6, у которых LeveratorHistoryForDailyFull.Code=DR.Code
Далее, для DR.8 то же, при LeveratorHistoryForDailyFull.FormFieldNumber=8 и так далее.
 

Присоединённый файл ( Кол-во скачиваний: 2 )
 ________________.GIF 40,29 Kb

почти решил задачу, но наткунлся на непонятный глюк


как обратиться к полю таблицы, если имя поля - цифра? 

Задача почти решена. Осталось самую малость докурочить.
В полученной таблице DR есть поля, названия которых - цифровые, то есть DR.6,  DR.8, DR.52 ... DR. 204  (таких полей - 50 штук ровно, их нумерация "рваная", не последовательная). среди них есть поля, зависящие от значений других полей (поле 195 равно сумме полей 6, 8, 10, 12, 13 ... (всего14), поле 294 не может быть меньше поля 195, поле 270 равно 1, когда все поля для поля 195 содержат хотя бы 1, поле 271 равно1, если поле 195 больше "30"). Таких условий - несколько, особо важно условие для полей 130 и 298 - они отражают наличие в точке НАШЕГО холодильника, учёт которых ведётся в этой же базе (таблица Equipment, искать по коду точки).

Можно, конечно в модуле жестко прописать эти правила, но с течением времени (примерно раз в 1-2 месяца) поля отчёта меняются, по этому надо всё на автомате сделать, а вот как - не знаю