Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2

Доброго времени суток!
Возникла такая задача.
Есть 2 таблицы. Таблица1 содержит поля: Лицевой счет (ключ, поле уникальное), Квартирная плата (сумма начисленная к оплате, а в случае длительных неплатежей - это сумма долга). Фактически, можно считать, что во втором поле денежный остаток на лицевом счету (поле 1).
Таблица2. Это платежи. Таблица2 содержит поля: Лицевой счет (ключ, поле уникальное и связь с Таблицей1), Сумма платежа, Дата платежа.
Необходимо чтобы при внесении и сохранении данных в поле "Сумма платежа" Таблицы2 пропорционально изменялись значения остатков в Таблице1 поля Квартирная плата.
Вероятно - это запрос на обновление. Который необходимо выполнять каждый раз после разнесения платежей. Дабы в отчете были остатки по лицевым счетам "срезом на сегодня".

Заранее благодарю за помощь.

В том и дело. Что есть только только понимание в голове. В Экселе в связанных таблицах значения объединенные меняются. А тут не могу понять как. Дело не только в репорте. Репорт - это уже частное.
А мне надо.
Скажем в таблице 1
"Лиц. счет" "Остаток средств"
1000 200

В таблицу 2 внесли значение.
"лиц счет" "Платеж" "Дата"
1000 100 27.11.2015

Мне необходимо понять какие нужно сделать манипуляции, чтобы после записи строки Таблицы2 в Таблице1 значение поля "Остаток средств" стал: 200 (было) + 100 (внесли) = 300 и запомнилось там.
А отчет уже по факту - у кого сколько осталось на сегодня.
Если так не возможно в принципе, то тогда алгоритм второго варианта.
Талица1 содержит статические значения в поле "Остаток средств" на момент запуска базы. Такие как бы опорные значения.
Таблица2 Постоянно растет. Каждый месяц по одному и тому же "лиц. счету" идут "платежи". А по итогу строится некий отчет или запрос, который мог бы для уникального "лиц. счета" на заданную дату (она тоже есть в платежах) собрать итоговое значение.
Например: 200 (было) + 100 (ноябрь)+100(декабрь) + 100 (январь) = 500 на 1.02.2016.

Основы проектирования складской БД (v. 2)

MyTaR,
В access ёкселевские подходы не приемлемы и по-хорошему нужны таблицы (к ним добавляются и другие) "начислено" и "оплачено", которые завязаны на основную таблицу "лицевой счет"-как-то так... А вообще имеется куча готовых программ (есть очень не плохие)
лучше которых Вы навряд-ли создадите-может копать в сторону их поиска?

Судя по структуре и наполнению таблиц, значение поля "Квартирная плата" первой таблицы на самом деле в любой момент времени может быть вычислено из значений поля "Сумма платежа" второй таблицы и некоего поля "Начисленная квартплата" третьей таблицы, которая в описании вообще отсутствует, либо заносится в таблицу 2, но с отрицательной суммой.

Если это так, и третья таблица или отрицательные суммы имеет место быть - то схема, которая тут реализуется, на языке баз данных именуется не иначе как "переопределённые данные". Как неоднократно сказано - для переопределения нужны крайне веские основания, которых тут и близко не наблюдается. По науке нужно вообще удалить первую таблицу за ненадобностью, и все необходимые данные по текущему балансу платежей получать запросом в момент, когда они нужны. Так данные всегда будут получаться актуальными, и будет исключена вероятность разбаланса и нарушения целостности данных.

А если сведений о начислениях (третья таблица или отрицательные суммы) не существует - то описанная база данных вообще не имеет смысла.

MyTaR
Необходимо чтобы при внесении и сохранении данных в поле "Сумма платежа" Таблицы2 пропорционально изменялись значения остатков в Таблице1 поля Квартирная плата.

Поясните свою мысль. У меня никак не укладывается в голове, что тут делает слово "пропорционально"...

sdku, Благодарю. И дело вовсе не в написать "изобретая колесо". Все ПО под ЖКХ платное и довольно весомо. Более того, тут не используется комплексный учет. Нет нужды в избыточном функционале. Вот и зародилась идея.

Akina,
Все Вами сказано верно. Это если мы стартуем с 0. Знаете, в 1С есчть такая ф-ция при старте - "Ввод остатков". Так вот Таблица1 - это и есть остатки на начало работы предприятия, если так удобнее. В момент старта базы уже были и должники, и энтузиасты, кто платит больше положенного. И это все в гроссбухах (на бумаге). Я не могу спистьа все в 0. Мы с этими данными стартуем.
По поводу Таблицы3 - Вы абсолютно правы. Там тоже самое - "Лиц. счет" и "Начислено". Я не стал ее описывать потому что там проблема таже только зеркальная. В первом случае "Платежом" нужно уменьшить значение ячейки, а во втором увеличить "Начислением" в след месяц. Процедура одна. Знак разный.
"Пропорционально", возможно, слово выбрал неверное. Имелось ввиду (я там давал пример) - Что если в ячейке "Остаок" сегодня утром 200, то после проведения платежа в 100 в Таблице2, в этой ячейке должно число измениться на эти 100. Если это долг "-200", то стать "100", а если у человека положительный баланс "200", то стать "300". Начисление из Таблицы3 делает просто обратное. При начислении 100 на "200" положительного -выходит 100 (списание), а при долге "-200" - выходит "-300" - увеличение долга.

MyTaR
Это если мы стартуем с 0. Знаете, в 1С есчть такая ф-ция при старте - "Ввод остатков". Так вот Таблица1 - это и есть остатки на начало работы предприятия, если так удобнее. В момент старта базы уже были и должники, и энтузиасты, кто платит больше положенного. И это все в гроссбухах (на бумаге). Я не могу спистьа все в 0. Мы с этими данными стартуем.

Ясный пень... для этого просто вводится особый тип платежа "перенос остатка". Ну или, если хочешь, делается первое списание/начисление, равное сумме текущего баланса. Или ты правда думаешь, что ты первый начал использовать учётный софт не с нуля? Собсно перенос старых данных в архив сопровождается удалением переносимых данных и занесением вместо них одной записи указанного особого типа. "Всё украдено уже до вас...".

MyTaR
там проблема таже только зеркальная

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

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

MyTaR,

1. Сначала нужно понять суть системы (допустим это оплата коммунальных услуг), и разделить её на основные составляющие:
А). Клиент (плательщик)
Б). Оператор (принимающий платежи)
В). Собственно бухгалтерия ЖКХ, которая всё это сводит в кучу.
2. Затем нужно рассмотреть эти составляющие подробно с точки зрения предмета автоматизации:
Клиент – его функции ограничены тем, что он должен получить квитанцию на оплату с полной информацией (лицевой счет, адрес, сумма за текущий период, сумма задолженности, бла, бла) и пойти её оплатить, очевидно, что предметом автоматизации здесь является квитанция и это функция бухгалтерии ЖКХ.
Оператор – должен тупо принимать платежи, его рабочее место в идеале должно быть напрочь отвязано от основной системы ЖКХ и работать в автономном режиме, даже если у бухгалтерии выходной и у них компы выключены. То есть в идеале рабочее место оператора делает тупой лог – по какому лицевому счету когда и сколько заплатили – всё… Другая информация по клиенту (ФИО, адрес, долги) доступна оператору из квитанции Клиента. Соответственно таких операторов может быть много и каждый из них автономен. В конце дня делается закрытие смены, формируется файл лога и отправляется любым способом в бухгалтерию.
Бухгалтерия – импортирует логи (пополняя баланс клиента), выставляет новые счета и рассылает новые квитанции. (имеется ввиду только основной процесс – прием коммунальных платежей)
Вот тут уже имеет место структура и однозначно таблица Клиенты:
- лицевой счет
- ФИО
- Адрес
- параметры для формирования суммы по тарифам на оплату (условно)
- Бла… бла…
Затем нужно принять два решения:
1. Сколько будет таблиц учета операций (две или одна)
- две таблицы это если Счета и Оплата отдельно
- Одна таблица это когда и то и то в куче с разными признаками или (и) с положительными / отрицательными суммами …
2. Нужно ли хранить текущий баланс в Таблице Клиенты.
- если не храним, то получаем всё вычислениями из таблиц учета, пусть хоть час считается (если много клиентов) – всё равно это делается раз в месяц. Новые Квитанции сформируются быстро (на основании таблицы Клиенты), время уйдет на вычисление долгов по таблицам учета операций.
- если храним – то, новые счета (квитанции) распечатаем за 3 сек, но нужен механизм поддержания баланса Клиента в актуальном состоянии:
А). При выставлении новых счетов
Б). При импорте логов о платежах
В). Принудительный контроль и пересчет балансов клиентов по требованию.

Ничего, никому не навязываю… сделал – работает уже лет 5,
еще есть у нас час58 (приложил руку к ЖКХ) может откликнется (если захочет)…

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