Автокоррекция значений в одной таблице при добавлении записи в другую

Привет всем.

Основной вопрос вот какой. У меня есть таблица наличия товаров, и таблица продаж.
Хочется сразу после добавления новой продажи, автоматически уменьшать количество товаров в наличии.
При этом я совершенно не понимаю что делать если вдруг, допустим продавец ошибся при заполнении, и заполнил что продал 3 единицы товара, вместо скажем 2, а потом исправит на 2. Получится, что количество в наличии сначала должно уменьшиться на 3, после добавления новой записи, а потом должно будет увеличится на 1, после исправления продавцом. В общем весьма странная логика получается.... Я так понимаю нужен VBA и на евенты куда то хендлеры навешивать.

И второй вопрос, возможно ли принять поля от формы, сформировать из них данные, сгруппировать их как-то и распихать по разным таблицам? Я так понимаю это только VBA возможно? Если да, то может есть пример как это делать?

Использую ms Access 2016.

0

В любом учёте всегда есть поступление и списание, либо вы их храните в одной таблице с разным типом операции (поступление/списание), либо вы храните данные в двух таблицах - поступление и списание. Никакие остатки никогда не хранятся в системах учёта, остатки рассчитываются: приход - расход = остаток.
Это всё независимо от программного продукта, которым вы пользуетесь. Можете вообще пользоваться тетрадкой в клеточку.

0

alvk, хотелось бы уточнить некоторую неясность.
А остатки расчитываются прям в таблице или всё-таки в запросе?

0

остатки рассчитываются: приход - расход = остаток.

Боюсь что в случае супермаркета детальная таблица расхода (каждая покупка), будет очень большой, и как результат будут жёсткие тормоза, при попытке найти разницу.

И все-таки, решаема ли задача с корректировкой?

0

Сообщение от VinniPuh ...А остатки расчитываются прям в таблице или всё-таки в запросе?...

Сообщение от misterx527 ...остатки рассчитываются: приход - расход = остаток...

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

Вложения

Движение Товара-05.rar (68.4 Кб, 200 просмотров)

0

Сообщение от VinniPuh А остатки расчитываются прям в таблице или всё-таки в запросе?

С чего вдруг неясность? Я конкретно всё написал.

Сообщение от misterx527 и как результат будут жёсткие тормоза, при попытке найти разницу.

Откуда такая уверенность?

Добавлено через 6 минут
Кстати можно хранить остатки в отдельной таблице на начало месяца и в расчётах использовать её. Тогда даже на Celeron 333 тормозить не будет.

Добавлено через 4 минуты
И последний вопрос: кому нужно видеть ежедневно остатки по всем товарам сразу?

0

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

0

Расчет запросом остатков всех товаров на миллионе записей около минуты. При таком времени нет гарантий, что рассчитанный остаток будет истинным (записи после расчета могли быть добавлены/удалены/изменены другим пользователем). В реальных системах надежнее хранить остатки в отдельной таблице и использовать функции с использованием SEEK. Пример такой функции здесь Автоматическое изменение количества в одной таблице при выборе позиции из другой таблицы.

0

Сообщение от VinniPuh Похоже у вас с терминологией совсем не густо.

Ну... как бы... это... я ж процетировал...

за движение товара отдельное спасибо, посмотрю.

Сообщение от VinniPuh И как видимо был прав, ибо ответ ТСа, весьма забавен и про запросы он похоже даже не слышал ни когда.

Почему забавен? Я слышал про запросы. Просто мне казалось правильным каждый раз поправлять сравнительно небольшую таблицу с ассортиментом каждый раз, чем пересчитывать разность прихода и расхода один раз в сутки. Я думал, о том, что может быть по другому организовать БД нужно, но 1) я не знаю как это сделать правильно 2) всё-таки интересно как можно сделать ввод и коррекцию полей более гибкой.

Сообщение от alvk Откуда такая уверенность?

Я так полагаю что зависит от количества продаж. Я неправ?
Представьте, что вы идёте в супермаркет. Покупаете молоко, хлеб, яйца, мороженное, минеральную воду, жвачку.
Каждая из этих позиций - это запись в таблице покупок. Поэтому только на одного человека было потрачено 6 записей в таблице. Пусть в магазине 4 кассы и среднее время обслуживания клиентов 1 мин. Допустим работает магазин с 8 до 20:00. Итого имеем 6*4кассы*60мин*12часов = 17280 записей в день. это около полумиллиона в месяц. Это по очень грубым прикидкам. Может это и не беда. Не знаю. Поэтому я здесь

Сообщение от alvk И последний вопрос: кому нужно видеть ежедневно остатки по всем товарам сразу?

я предполагал, что тот кто в магазе, отвечает за поставку товаров, должен в начале каждого следующего дня проверять чего в магазине не достаёт и заказывать товар. Как то так. А зачем ещё нужно знать про остатки?

Сообщение от ltv_1953 Расчет запросом остатков всех товаров на миллионе записей около минуты. При таком времени нет гарантий, что рассчитанный остаток будет истинным

Да, я тоже думал над этим, но в супермаркете это наверное не сильно принципиально. Примерные данные нужны с утра, чтобы сделать заказ недостающего товара. Однако для интернет магазина это весьма актуально. Чтобы показывать пользователю сколько того или иного товара осталось и не допустить заказа товара, который кончился.

Сообщение от alvk Кстати можно хранить остатки в отдельной таблице на начало месяца и в расчётах использовать её. Тогда даже на Celeron 333 тормозить не будет.

Вот здесь поподробнее, как это? То есть будет некий запрос, который мы будем запускать один раз в месяц и он будут выполнять пересчет и создание таблицы? Или как?

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

Добавлено через 8 минут

Сообщение от ltv_1953 Пример такой функции здесь Автоматическое изменение количества в одной таблице при выборе позиции из другой таблицы.

Не подскажете на какое событие и каким образом повесить этот VBA скрипт?

0

Сообщение от misterx527 я предполагал, что тот кто в магазе, отвечает за поставку товаров, должен в начале каждого следующего дня проверять чего в магазине не достаёт и заказывать товар. Как то так. А зачем ещё нужно знать про остатки?

Прочтите ещё раз мой вопрос, я не спрашивал про остатки, я спрашивал что? Вот на это и ответьте.

кому нужно видеть ежедневно остатки по всем товарам сразу?

Я считаю, что таких людей в природе нет, пусть один-два, ну страница хотя бы, но чтобы тысячи!

Сообщение от misterx527 проект некоммерческий, это мой курсовой

Тогда вообще можно не заморачиваться таблицей. Делайте расчёт в запросе.

Сообщение от ltv_1953 Расчет запросом остатков всех товаров на миллионе записей около минуты. При таком времени нет гарантий, что рассчитанный остаток будет истинным

В начале каждого дня до открытия или в конце после закрытия. Продаж нет, а значит результат истинный.
Если речь идёт о крупном супермаркете, то у него явно не тарантайка из 1999 года, а полноценный сервер, расчёт несольких миллионов записей = 4 секунды.

0

Сообщение от alvk Прочтите ещё раз мой вопрос, я не спрашивал про остатки, я спрашивал что? Вот на это и ответьте. кому нужно видеть ежедневно остатки по всем товарам сразу?

Отвечаю ещё раз: тому кто отвечает за поставку товаров в магазин.

0

Сообщение от misterx527 Отвечаю ещё раз: тому кто отвечает за поставку товаров в магазин.

А я уже сказал, что таких людей не существует:

Сообщение от alvk таких людей в природе нет, пусть один-два, ну страница хотя бы, но чтобы тысячи!

Компьютер только может с таким справиться или искусственный интеллект. Человек тысячи товаров смотреть одновременно не может!

0

Сообщение от alvk Компьютер только может с таким справиться или искусственный интеллект. Человек тысячи товаров смотреть одновременно не может!

Зачем тысячи? Пусть аксесс обрабатывает тысячные списки всех товаров и выдаёт десятки тех которых нет в наличии. А с парой десятков человек думаю справится.

0

Сообщение от misterx527 При этом я совершенно не понимаю что делать если вдруг, допустим продавец ошибся при заполнении, и заполнил что продал 3 единицы товара, вместо скажем 2, а потом исправит на 2. Получится, что количество в наличии сначала должно уменьшиться на 3, после добавления новой записи, а потом должно будет увеличится на 1, после исправления продавцом. В общем весьма странная логика получается

Одним действием можно - просто прибавить разницу между старым значением и новым.
Эта разница может быть и отрицательной.
Имена здесь русские, чтобы долго не объяснять.

0

misterx527, пока вы не пересилите себя и не начнёте делать реальную БД, а будете только теории всякие с предположениями строить, то так и не сможете понять, как это делается, ибо тут нужно кроме мозга и ручками поработать.
Скоро вторая страница пойдет, а воз и ныне там.

1

Сообщение от misterx527 При этом я совершенно не понимаю что делать если вдруг, допустим продавец ошибся при заполнении, и заполнил что продал 3 единицы товара, вместо скажем 2, а потом исправит на 2.

Простой, надёжный, быстрый и проверенный вариант в 2 формы:
01. Форма просмотра документа продажи (поступления) - Далее "ФП".
02. Форма редакции документа продажи (поступления)- Далее "ФР".
... дальше так:
При переходе ФР -> ФП производим списание содержимого документа со склада ....
При открытии ФР - возвращаем товар всё содержимое на склад - как будто документа и не было.
Всё.
... и никакой путаницы.

0

Сообщение от misterx527 А с парой десятков человек думаю справится.

Вот именно и тут начинаются варианты. Во всяком случае ваше мнимое торможение уже в топке.

0

Спасибо всем, все получилось. Сделал через запрос как разность прихода и расхода. Спасибо, Пух, за пример базы, помогла.

Сообщение от Capi Одним действием можно - просто прибавить разницу между старым значением и новым.

Спасибо за тот вариант про который я спрашивал. Я же правильно понимаю, что AfterUpdate привязываются только к элементам формы, но к таблицам привязать нельзя?

Сообщение от Eugene-LS При открытии ФР - возвращаем товар всё содержимое на склад - как будто документа и не было.

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

Сообщение от VinniPuh пока вы не пересилите себя и не начнёте делать реальную БД

Так я и начал, после чего и появились вопросы.

Добавлено через 5 минут

Сообщение от alvk Вот именно и тут начинаются варианты. Во всяком случае ваше мнимое торможение уже в топке

"Моё мнимое торможение" возникает не от того сколько записей в результате, а от того сколько записей в уменьшаемом и вычитаемом (в терминах разности двух чисел: приход(уменьшаемое)-расход(вычитаемое)=остаток(разность))

0

Сообщение от misterx527 Я же правильно понимаю, что AfterUpdate привязываются только к элементам формы, но к таблицам привязать нельзя?

Познакомься с макросами данных.

0

Сообщение от misterx527 а от того сколько записей в уменьшаемом и вычитаемом (в терминах разности двух чисел: приход(уменьшаемое)-расход(вычитаемое)=остаток(разность))

Где это?

0