|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
Доброго времени суток! Возникла такая задача. Есть 2 таблицы. Таблица1 содержит поля: Лицевой счет (ключ, поле уникальное), Квартирная плата (сумма начисленная к оплате, а в случае длительных неплатежей - это сумма долга). Фактически, можно считать, что во втором поле денежный остаток на лицевом счету (поле 1). Таблица2. Это платежи. Таблица2 содержит поля: Лицевой счет (ключ, поле уникальное и связь с Таблицей1), Сумма платежа, Дата платежа. Необходимо чтобы при внесении и сохранении данных в поле "Сумма платежа" Таблицы2 пропорционально изменялись значения остатков в Таблице1 поля Квартирная плата. Вероятно - это запрос на обновление. Который необходимо выполнять каждый раз после разнесения платежей. Дабы в отчете были остатки по лицевым счетам "срезом на сегодня". Заранее благодарю за помощь. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 16:56 |
|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
В том и дело. Что есть только только понимание в голове. В Экселе в связанных таблицах значения объединенные меняются. А тут не могу понять как. Дело не только в репорте. Репорт - это уже частное. А мне надо. Скажем в таблице 1 "Лиц. счет" "Остаток средств" 1000 200 В таблицу 2 внесли значение. "лиц счет" "Платеж" "Дата" 1000 100 27.11.2015 Мне необходимо понять какие нужно сделать манипуляции, чтобы после записи строки Таблицы2 в Таблице1 значение поля "Остаток средств" стал: 200 (было) + 100 (внесли) = 300 и запомнилось там. А отчет уже по факту - у кого сколько осталось на сегодня. Если так не возможно в принципе, то тогда алгоритм второго варианта. Талица1 содержит статические значения в поле "Остаток средств" на момент запуска базы. Такие как бы опорные значения. Таблица2 Постоянно растет. Каждый месяц по одному и тому же "лиц. счету" идут "платежи". А по итогу строится некий отчет или запрос, который мог бы для уникального "лиц. счета" на заданную дату (она тоже есть в платежах) собрать итоговое значение. Например: 200 (было) + 100 (ноябрь)+100(декабрь) + 100 (январь) = 500 на 1.02.2016. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 17:32 |
|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 17:40 |
|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
MyTaR, В access ёкселевские подходы не приемлемы и по-хорошему нужны таблицы (к ним добавляются и другие) "начислено" и "оплачено", которые завязаны на основную таблицу "лицевой счет"-как-то так... А вообще имеется куча готовых программ (есть очень не плохие) лучше которых Вы навряд-ли создадите-может копать в сторону их поиска? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 18:14 |
|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
Судя по структуре и наполнению таблиц, значение поля "Квартирная плата" первой таблицы на самом деле в любой момент времени может быть вычислено из значений поля "Сумма платежа" второй таблицы и некоего поля "Начисленная квартплата" третьей таблицы, которая в описании вообще отсутствует, либо заносится в таблицу 2, но с отрицательной суммой. Если это так, и третья таблица или отрицательные суммы имеет место быть - то схема, которая тут реализуется, на языке баз данных именуется не иначе как "переопределённые данные". Как неоднократно сказано - для переопределения нужны крайне веские основания, которых тут и близко не наблюдается. По науке нужно вообще удалить первую таблицу за ненадобностью, и все необходимые данные по текущему балансу платежей получать запросом в момент, когда они нужны. Так данные всегда будут получаться актуальными, и будет исключена вероятность разбаланса и нарушения целостности данных. А если сведений о начислениях (третья таблица или отрицательные суммы) не существует - то описанная база данных вообще не имеет смысла. MyTaRНеобходимо чтобы при внесении и сохранении данных в поле "Сумма платежа" Таблицы2 пропорционально изменялись значения остатков в Таблице1 поля Квартирная плата. Поясните свою мысль. У меня никак не укладывается в голове, что тут делает слово "пропорционально"... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 18:36 |
|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
sdku, Благодарю. И дело вовсе не в написать "изобретая колесо". Все ПО под ЖКХ платное и довольно весомо. Более того, тут не используется комплексный учет. Нет нужды в избыточном функционале. Вот и зародилась идея. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 19:23 |
|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
Akina, Все Вами сказано верно. Это если мы стартуем с 0. Знаете, в 1С есчть такая ф-ция при старте - "Ввод остатков". Так вот Таблица1 - это и есть остатки на начало работы предприятия, если так удобнее. В момент старта базы уже были и должники, и энтузиасты, кто платит больше положенного. И это все в гроссбухах (на бумаге). Я не могу спистьа все в 0. Мы с этими данными стартуем. По поводу Таблицы3 - Вы абсолютно правы. Там тоже самое - "Лиц. счет" и "Начислено". Я не стал ее описывать потому что там проблема таже только зеркальная. В первом случае "Платежом" нужно уменьшить значение ячейки, а во втором увеличить "Начислением" в след месяц. Процедура одна. Знак разный. "Пропорционально", возможно, слово выбрал неверное. Имелось ввиду (я там давал пример) - Что если в ячейке "Остаок" сегодня утром 200, то после проведения платежа в 100 в Таблице2, в этой ячейке должно число измениться на эти 100. Если это долг "-200", то стать "100", а если у человека положительный баланс "200", то стать "300". Начисление из Таблицы3 делает просто обратное. При начислении 100 на "200" положительного -выходит 100 (списание), а при долге "-200" - выходит "-300" - увеличение долга. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 19:31 |
|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
MyTaRЭто если мы стартуем с 0. Знаете, в 1С есчть такая ф-ция при старте - "Ввод остатков". Так вот Таблица1 - это и есть остатки на начало работы предприятия, если так удобнее. В момент старта базы уже были и должники, и энтузиасты, кто платит больше положенного. И это все в гроссбухах (на бумаге). Я не могу спистьа все в 0. Мы с этими данными стартуем. Ясный пень... для этого просто вводится особый тип платежа "перенос остатка". Ну или, если хочешь, делается первое списание/начисление, равное сумме текущего баланса. Или ты правда думаешь, что ты первый начал использовать учётный софт не с нуля? Собсно перенос старых данных в архив сопровождается удалением переносимых данных и занесением вместо них одной записи указанного особого типа. "Всё украдено уже до вас...". MyTaRтам проблема таже только зеркальная В итоге у тебя есть две таблицы. И обе содержат абсолютно одинаковые, если формализовать задачу, данные - изменение текущего баланса на определённую сумму в определённую дату по определённой причине. То есть - одна сущность, разнесённая на две таблицы. Я думаю, что тебе надо отложить в сторону процесс создания базы данных и почитать что-нибудь по вопросу анализа предметной области. Ну просто чтобы потом, когда половина работы будет проделана, не выяснять, что структуру (и обрабатывающий на ней данные софт) нужно переделывать... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 20:24 |
|
Инкремент/декремент значения поля Таблицы1 используя значения из поля Таблицы2
|
|||
---|---|---|---|
#18+
MyTaR, 1. Сначала нужно понять суть системы (допустим это оплата коммунальных услуг), и разделить её на основные составляющие: А). Клиент (плательщик) Б). Оператор (принимающий платежи) В). Собственно бухгалтерия ЖКХ, которая всё это сводит в кучу. 2. Затем нужно рассмотреть эти составляющие подробно с точки зрения предмета автоматизации: Клиент – его функции ограничены тем, что он должен получить квитанцию на оплату с полной информацией (лицевой счет, адрес, сумма за текущий период, сумма задолженности, бла, бла) и пойти её оплатить, очевидно, что предметом автоматизации здесь является квитанция и это функция бухгалтерии ЖКХ. Оператор – должен тупо принимать платежи, его рабочее место в идеале должно быть напрочь отвязано от основной системы ЖКХ и работать в автономном режиме, даже если у бухгалтерии выходной и у них компы выключены. То есть в идеале рабочее место оператора делает тупой лог – по какому лицевому счету когда и сколько заплатили – всё… Другая информация по клиенту (ФИО, адрес, долги) доступна оператору из квитанции Клиента. Соответственно таких операторов может быть много и каждый из них автономен. В конце дня делается закрытие смены, формируется файл лога и отправляется любым способом в бухгалтерию. Бухгалтерия – импортирует логи (пополняя баланс клиента), выставляет новые счета и рассылает новые квитанции. (имеется ввиду только основной процесс – прием коммунальных платежей) Вот тут уже имеет место структура и однозначно таблица Клиенты : - лицевой счет - ФИО - Адрес - параметры для формирования суммы по тарифам на оплату (условно) - Бла… бла… Затем нужно принять два решения : 1. Сколько будет таблиц учета операций (две или одна) - две таблицы это если Счета и Оплата отдельно - Одна таблица это когда и то и то в куче с разными признаками или (и) с положительными / отрицательными суммами … 2. Нужно ли хранить текущий баланс в Таблице Клиенты . - если не храним, то получаем всё вычислениями из таблиц учета, пусть хоть час считается (если много клиентов) – всё равно это делается раз в месяц. Новые Квитанции сформируются быстро (на основании таблицы Клиенты), время уйдет на вычисление долгов по таблицам учета операций. - если храним – то, новые счета (квитанции) распечатаем за 3 сек, но нужен механизм поддержания баланса Клиента в актуальном состоянии: А). При выставлении новых счетов Б). При импорте логов о платежах В). Принудительный контроль и пересчет балансов клиентов по требованию. Ничего, никому не навязываю… сделал – работает уже лет 5, еще есть у нас час58 (приложил руку к ЖКХ) может откликнется (если захочет)… ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2015, 12:23 |
|
|
start [/forum/topic.php?fid=45&msg=39115317&tid=1614216]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
others: | 34ms |
total: | 204ms |
0 / 0 |