Access 2010 - наличие нескольких продуктов для одного идентификатора котировки - PullRequest
0 голосов
/ 19 октября 2011

Я создал адаптацию базы данных «Товары», которая включает функцию цитаты. Пользователь выбирает клиента (таблица клиентов), продукт (таблица продуктов), количество, скидка и т. Д. Выбранные объекты затем сохраняются в таблице котировок, и в форме есть функция «печать».


Хотя информация может быть сохранена, а цитата распечатана с помощью отчета о расценках, у меня возникли серьезные трудности с поиском способа добавления нескольких товаров в одну квоту.


Основная цель заключается в том, чтобы иметь возможность выбрать различные товары и добавить их общую стоимость (товар после добавления кол-во, скидка) в ОБЩУЮ ИТОГО

Таким образом, общая стоимость составляет формулу Налог + Доставка + Итого

кто-нибудь? :)

Привет, ребята,

Спасибо за ответ, я действительно ценю это. Что касается налогов и доставки, они просто добавляются в форму и не перемещаются из других источников в базу данных. Это просто тип формы и отображение в отчете. Как вы сказали в ответе, HansUp, продавец рассчитает его отдельно и просто введет.

Что касается налога, товары будут отправляться по всему миру, поэтому налог / НДС также рассчитывается отдельно. Кроме того, каждая таблица имеет свой уникальный идентификатор.

Еще к тому, чтобы иметь QuoteProducts. Кажется, я не могу обойти это! Вы говорите, что независимо от того, какие продукты выбраны в QuoteProducts, вы создадите QuoteProd_ID, а затем общая стоимость этого идентификатора будет добавлена ​​в предложение?

Я пытался сделать подчиненную форму раньше, но через форму «множественные записи», но, очевидно, каждый выбор имел свой собственный идентификатор. Есть ли какой-нибудь способ, которым вы могли бы уточнить часть продуктов Quote и как она позволяет хранить несколько записей под одним идентификатором? Без понимания я бесполезен. Кроме того, как многократные записи тогда сложены, чтобы сделать промежуточный итог, также сбивает с толку меня. Это делается в форме цитаты?

Редактировать 2

HALLELUJAH.

Это работает! Я создал сумму в текстовом поле в нижнем колонтитуле подчиненной формы и затем поместил ее в промежуточный итог:)

У меня есть одна небольшая проблема:

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

Можете ли вы, ребята, помочь?

Цена по прейскуранту

вот что я пробовал:

1) Создать> Клиент> Дизайн запроса

2) Показать товары, QuoteDetails. По какой-то причине он автоматически предлагает ListPrice, ProductID (как и должно быть) и имя продукта, связанные с идентификатором в продуктах

3) Удалить ссылки с ListPrice и ProductName.

4) Показать все в цитатеDetails (*)

5) Форма создания нескольких элементов

Не работает! Что я делаю не так?

Я чрезвычайно благодарен за вашу помощь. Если я могу что-нибудь сделать, просто кричи.

Ryan

Ответы [ 2 ]

1 голос
/ 19 октября 2011

В дополнение к звездному ответу HansUp вас может заинтересовать DatabaseAnswers.org . У них есть ряд бесплатных моделей данных, которые могут дать дополнительную информацию о вашей ситуации и, возможно, послужить вдохновением для будущих проектов, с которыми вы можете столкнуться.

Редактировать 1

Забудьте на минуту о форме и отчете - они важны, но не так важны, как данные и способ их хранения.

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

Таблица котировок, как предложил HansUp, должна хранить такую ​​информацию, как Customer_ID, Employee_ID, OrderDate и, возможно, даже ссылку на BillingAddress и ShippingAddress.

Таблица котировок НЕ ДОЛЖНА хранить информацию о продуктах, заказанных клиентом в рамках этой цитаты.

Вместо этого эта информация должна храниться в таблице с именем QuoteProducts или QuoteDetails. Его структура будет выглядеть примерно так:

QuoteDetails_ID --> Primary Key of the table (autonumber field)
Quote_ID --> Foreign key back to the Quotes table
Product_ID --> Foreign key back to Products table
Quantity
UnitPrice

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

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

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

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

1 голос
/ 19 октября 2011

Для первых 3 таблиц, упомянутых в вашем комментарии, у каждой должен быть первичный ключ: Customers, customer_id; продукты, product_id; и сотрудники, employee_id.

Таблица кавычек будет иметь свой собственный первичный ключ quote_id и будет хранить customer_id и employee_id в качестве внешних ключей. (Я предполагаю, что вы хотите, чтобы employee_id записывал, какой представитель клиента / продавец создал цитату.) Вы также можете включить дополнительные атрибуты для каждой цитаты; например, цитата из даты и времени.

Продукты, предлагаемые для котировок, будут храниться в распределительной таблице QuoteProducts. Он будет иметь внешние ключи для quote_id и product_id, по одной строке для каждого продукта, предлагаемого в цитате. Здесь также можно хранить количество атрибутов и скидки. В дополнительном поле unit_price можно сохранить цену продукта, которая действовала на момент составления предложения ... что было бы полезно в случае изменения цен на продукт с течением времени. Я не знаю, должен ли налог быть включен в эту таблицу (см. Ниже).

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

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

Однако, если этот дизайн работает для вас (проверьте его, введя фиктивные данные в таблицы без использования формы), вы можете создать форму на основе кавычек с подчиненной формой на основе QuoteProducts. С quote_id в качестве свойства master / child ссылки, подчиненная форма позволит вам просматривать все продукты, связанные с текущим quote_id основной формы. Вы можете использовать подчиненную форму для добавления, удаления и / или редактирования продуктов, связанных с этой цитатой.

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

Редактировать : При использовании подхода основной формы / подчиненной формы каждая новая строка в подчиненной форме должна «наследовать» значение quote_id текущей записи в основной форме. Вы гарантируете это, устанавливая свойства master / child ссылки на quote_id. Crystal Long объясняет это более подробно в главе 5 Основы доступа Crystal : PDF-файл . Прокрутите вниз до заголовка Создание главной формы и подчиненной формы на странице 24.

Edit2 : Ваша стратегия может включать хранение Products.ListPrice в QuoteDetails.ListPrice. Это было бы полезно для записи текущего ListPrice, предлагаемого для цитаты. Если это так, вы можете получить ListPrice из Products и сохранить его в QuoteDetails при выборе ProductID для строки в подчиненной форме. Это можно сделать с помощью кода VBA в событии после обновления элемента управления, который связан с полем ProductID. Поэтому, если этот элемент управления является комбинированным полем с именем cboProductID, а элемент управления подчиненной формы, связанный с полем QuoteDetails ListPrice, является текстовым полем с именем txtListPrice, используйте такой код для cboProductID после обновления:

Me.txtListPrice = DLookup("ListPrice", "Products", "ProductID = " _
    & Me.cboProductID)

В этом предложении предполагается, что таблицы Products и QuoteDetails содержат поле ProductID, а его тип данных - числовой. И cboProductID имеет ProductID в качестве своего связанного поля и использует запрос в качестве RowSource, подобный этому:

SELECT ProductID, ProductName
FROM Products
ORDER BY ProductName;
...