Access 2010 - 将多个产品分配到一个报价 ID
我创建了“商品”数据库的改编版,其中包括报价功能。用户选择客户(客户表)、产品(产品表)、数量、折扣等。 然后,所选实体将保存到报价表中,并且表单上有一个“打印”功能。
虽然可以保存信息并通过报价报告打印报价,但我在找到将多个产品添加到单个报价中的方法时遇到了很大的困难。
主要目标是能够选择各种产品并将其总价(添加数量、折扣后的产品)添加到小计
因此,报价总额的公式是税费+运费+小计
有人接受吗? :)
大家好,
感谢您的回复,我真的很感激。至于税费和运费,它们只是添加到表单中,而不是从数据库中的其他任何地方推送。它只是一种表单类型并在报告上显示之类的东西。正如你在答案中所说的,HansUp,销售人员会单独计算并输入它。
至于税收,产品将在全球范围内运输,因此税收/增值税也应单独计算。 此外,每个表都有自己唯一的 ID。
更重要的是拥有 QuoteProducts。我似乎无法理解它!您是说在 QuoteProducts 中选择的任何产品都会创建一个 QuoteProd_ID,然后该 ID 的总价将添加到报价中?
我之前尝试过创建一个子表单,但通过“多个记录”表单,但显然每个选择都有自己的 ID。您是否可以通过任何方式详细说明报价产品部分以及它如何允许多个记录存储到一个 ID?如果不理解它,我几乎毫无用处。 另外,如何将多条记录相加得出小计也让我很困惑。是在报价单中完成的吗?
编辑2
哈利路亚。
有用!我在子表单页脚的文本框中创建了一个总和,然后将其推入小计:)
我确实有一个小问题:
我对 ListPrice 进行了查找和关系。我认为这不是正确的方法,因为它会计算出每种灯的价格(即 10 种产品售价 10 英镑,10 英镑在下拉列表中显示十次)。
你们能帮忙吗?
标价问题
这是我尝试过的:
1)创建>客户>查询设计
2)显示产品,报价详细信息。由于某种原因,它会自动显示 ListPrice、ProductID(理应如此)以及链接到产品中 ID 的产品名称
3) 删除与 ListPrice 和 ProductName 的链接。
4) 在 quoteDetails (*) 中显示全部内容
5) 创建多个项目表单
不起作用!我做错了什么?
我非常感谢你们的帮助。如果我能做点什么,就大声喊吧。
瑞安
I have created an adaptation of the 'Goods' database that includes a quote feature. The user selects the customer (customer table), Product (product table), qty, discount ect.
The chosen entities then get saved to the quotes table and there is a 'print' function on form.
Whilst the information can be saved and the quote prints via a quote report, I'm having major difficulty in finding a way to add multiple products to a single quote.
The main objective is to be able to select various products and add their total price (product after addition of qty, discount) to a SUB TOTAL
Quote total is therefore the formula Tax+Shipping+SubTotal
any takers? :)
Hi guys,
Thanks for the response I really appreciate it. As for tax and shipping, they are just added in the form and are not pushed from anywhere else in the database. Its simply a type in form and display on report sort of thing. As you said in the answer, HansUp, the salesperson will compute it seperately and just input it.
As for tax, products will be shiped globally so the tax/vat shall be computed seperately also.
Also, each table DOES have its own unique ID.
More to the point of having QuoteProducts. I can't seem to get my head around it! Are you saying that whatever products are chosen in QuoteProducts will create a QuoteProd_ID and then that ID's total price will therefore be added to the Quote?
I tried making a subform before but through the 'multiple records' form but obviously every selection made its own ID. Is there any way you could elaborate on the Quote products part and how it allows multiple records to store to one ID? Without understanding it i'm pretty much useless.
In addition, how the multiple records are then added up to make the subtotal also baffles me. Is that done in the Quote form?
Edit 2
HALLELUJAH.
It works! I created a sum in a textbox on the footer of the subform and then pushed that into subtotal :)
I do have one slight issue:
I made a lookup&relationship for the ListPrice. I don't think its the correct way to do it as it comes up with the price of every light (i.e 10 products priced £10, £10 shows up ten times in dropdown).
Can you guys help?
List Price Problem
here's what i've tried:
1) Create >Client>Query Design
2) Show Products, QuoteDetails. For some reason, it automtically comes up with ListPrice, ProductID (as it should) and Product Name linked to ID in Products
3) Delete links with ListPrice and ProductName.
4) Show all in quoteDetails (*)
5) Create Multiple Items form
Doesnt work! What am I doing wrong?
I'm extremely grateful for both your help. If I can do anything, just shout.
Ryan
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
除了 HansUp 的出色答案之外,您可能对 DatabaseAnswers.org 感兴趣。他们有许多免费的数据模型,可以为您的情况提供更多见解,并可能为您未来可能遇到的项目提供灵感。
编辑 1
暂时忘记表单和报告 - 它们很重要,但不如数据以及数据存储方式重要。
在您当前的设计中,您可能有一个带有自动编号键字段的报价表。出于本答案的目的,该字段被命名为 Quote_ID。
正如 HansUp 建议的那样,报价表应该存储诸如 Customer_ID、Employee_ID、OrderDate 之类的信息,甚至可能还存储对 BillingAddress 和 ShippingAddress 的引用。
报价表不应存储有关客户作为此报价的一部分订购的产品的任何信息。
相反,此信息应存储在名为 QuoteProducts 或 QuoteDetails 的表中。
它的结构如下所示:
您可能还需要考虑一个税费字段和一个单独的字段用于报价单上每个行项目的运输。您将不可避免地遇到某些情况,即某些商品在某些地点应纳税,而在其他地点则不纳税,等等。
此设计允许特定报价将任意数量的产品分配给该报价。
返回到您的表单\报告,您需要更改现有的表单和报告以适应这个新的表格设计。通常,人们会使用主表单来表示报价本身,然后使用子表单来表示报价详细信息(商品、价格、数量等)。
要获取报价总额,您需要对 QUoteDetails 中特定 Quote_ID 的项目进行求和。
您可能还想查看 Microsoft 的 Northwind 示例数据库。据我所知,Northwind 有一个示例订单系统,通过查看工作示例,可以帮助您使这些想法更加具体。
In addition to HansUp's stellar answer, you might be interested in DatabaseAnswers.org. They have a number of data models for free that might provide additional insight to your situation and possibly serve as inspiration for future projects you may encounter.
Edit 1
Forget about the form and report for a moment - they are important but not as important as the data and how you store the data.
In your current design, you have a quotes table presumably with an autonumber key field. For the purposes of this answer, this field is named Quote_ID.
The quotes table, as HansUp suggested, should store information such as the Customer_ID, Employee_ID, OrderDate and perhaps even a reference to a BillingAddress and ShippingAddress.
The quotes table SHOULD NOT store anything about the products that the customer has ordered as part of this quote.
Instead, this information should be stored in a table called QuoteProducts or QuoteDetails.
It's structure would look something like the following:
You may also want to consider a field for tax and a separate field for shipping per line item on the quote. You will inevitably run into situations where certain items are taxable in some locations and not others, etc.
This design allows a particular quote to have any number of products assigned to the quote.
Returning to your form \ reports, you would need to change your existing forms and reports to accomodate this new table design. Typically one would use a main form for the quote itself, and then a subform for the quote details (item, price, quantity, etc).
To get the quote total, you would sum the items in QUoteDetails for a particular Quote_ID.
You may also want to check out the Northwind sample database from Microsoft. From what I recall Northwind had a sample Orders system that might help make these ideas more concrete for you by seeing a working example.
对于您评论中提到的前 3 个表,每个表都应该有一个主键:Customers、customer_id;产品,product_id;和员工,employee_id。
Quotes 表将有自己的主键 quote_id,并将 customer_id 和 employee_id 存储为外键。 (我假设您希望employee_id 记录哪个客户代表/销售人员创建了报价。)您还可以决定为每个报价添加其他属性;例如,准备的日期和时间报价。
提供报价的产品将存储在连接表 QuoteProducts 中。它将具有 quote_id 和 Product_id 的外键,其中一行对应报价中提供的每种产品。您也可以在此处存储属性数量和折扣。附加字段“unit_price”可以让您存储在准备报价时有效的产品价格……这在产品价格随时间变化的情况下非常有用。我不知道这个表中是否应该包含税(见下文)。
我也不知道如何解决运输问题。如果与报价相关的所有产品都打算在一次装运中交付,则运输成本可以是报价表的一个属性。我不知道你打算如何获得这个价值。看来可能是由运输方式、距离和重量决定的。如果您让销售人员单独计算该值,然后输入该值,请考虑如何处理输入运费后产品选择发生变化的情况。
该设计有些简单,但可能足以满足您所描述的情况。然而,它可能会变得更加复杂。例如,如果您决定保留产品价格变化的历史记录,那么您最好现在就为此建立规定。另外,我不知道税收在您的情况下如何适用——是否是适用于所有产品的单一税率,是否因客户位置而异,因客户类型而异,和/或因产品而异。您的税收业务规则需要适应架构设计。
但是,如果该设计适合您(通过在表中输入虚拟数据而不使用表单来测试它),您可以创建基于报价的表单以及基于 QuoteProducts 的子表单。使用 quote_id 作为链接主/子属性,子表单将允许您查看与主表单的当前 quote_id 关联的所有产品。您可以使用子表单添加、删除和/或编辑与该报价关联的产品。
关于这份报告我无话可说。前面的描述有很多不确定性。但是,如果您的数据库设计允许您构建可行的表单/子表单,那么它还应该支持收集相同数据的查询。使用该查询作为报告的记录源。并使用报告的排序和分组功能来创建报价总计。
编辑:使用主表单/子表单方法,子表单中的每个新行都应“继承”主表单中当前记录的 quote_id 值。您可以通过将链接主/子属性设置为 quote_id 来确保发生这种情况。 Crystal Long 在 Access Basics by Crystal 第 5 章中对此进行了更详细的解释: PDF 文件。向下滚动到第 24 页的标题创建主表单和子表单。
编辑2:您的策略可能包括将 Products.ListPrice 存储在 QuoteDetails.ListPrice 中。这对于记录当前报价的 ListPrice 很有用。如果是这样,当您在子表单中选择一行的 ProductID 时,您可以从 Products 中获取 ListPrice 并将其存储在 QuoteDetails 中。您可以在绑定到 ProductID 字段的控件的更新后事件中使用 VBA 代码来执行此操作。因此,如果该控件是名为 cboProductID 的组合框,并且绑定到 QuoteDetails ListPrice 字段的子表单控件是名为 txtListPrice 的文本框,则更新后对 cboProductID 使用如下代码:
该建议假设 Products 和 QuoteDetails 表都包含 ProductID 字段,并且它的数据类型是数字。 cboProductID 将 ProductID 作为其绑定字段,并使用查询作为其 RowSource,类似于以下内容:
For the first 3 tables mentioned in your comment, each should have a primary key: Customers, customer_id; products, product_id; and employees, employee_id.
The quotes table will have its own primary key, quote_id, and will store customer_id and employee_id as foreign keys. (I'm assuming you want employee_id to record which customer representative/salesperson created the quote.) You may also decide to include additional attributes for each quote; date and time quote prepared, for example.
The products offered for quotes will be stored in a junction table, QuoteProducts. It will have foreign keys for quote_id and product_id, with one row for each product offered in the quote. This is also where you can store the attributes quantity and discount. An additional field, unit_price, can allow you to store the product price which was effective at the time the quote was prepared ... which would be useful in case product prices change over time. I don't know whether tax should be included in this table (see below).
I also don't know how to address shipping. If all the products associated with a quote are intended to be delivered in one shipment, shipping cost could be an attribute of the quotes table. I don't know how you intend to derive that value. Seems like it might be determined by shipping method, distance, and weight. If you have the salesperson compute that value separately, and then input the value, consider how to handle the case where the product selection changes after the shipping fee has been entered.
That design is somewhat simplistic, but might be sufficient for the situation you described. However, it could get more complex. For example, if you decide to maintain a history of product price changes, you would be better off to build in provisions for that now. Also, I have no idea how tax applies in your situation --- whether it's a single rate applied to all products, varies by customer location, varies by type of customer, and/or varies by product. Your business rules for taxes will need to be accommodated in the schema design.
However, if that design works for you (test it by entering dummy data into the tables without using a form), you could create a form based on quotes with a subform based on QuoteProducts. With quote_id as the link master/child property, the subform will allow you to view all products associated with the main form's current quote_id. You can use the subform to add, remove, and/or edit products associated with that quote.
Not much I can say about the report. There is a lot of uncertainty in the preceding description. However, if your data base design allows you to build a workable form/subform, it should also support a query which gathers the same data. Use that query as the record source for the report. And use the report's sorting and grouping features to create the quote grand total.
Edit: With the main form/ subform approach, each new row in the subform should "inherit" the quote_id value of the current record in the main form. You ensure that happens by setting the link master/child properties to quote_id. Crystal Long explains that in more detail in chapter 5 of Access Basics by Crystal: PDF file. Scroll down to the heading Creating a Main Form and Subform on page 24.
Edit2: Your strategy may include storing Products.ListPrice in QuoteDetails.ListPrice. That would be useful to record the current ListPrice offered for a quote. If so, you can fetch ListPrice from Products and store it in QuoteDetails when you select the ProductID for a row in the subform. You can do that with VBA code in the after update event of the control which is bound to the ProductID field. So if that control is a combo box named cboProductID and the subform control bound to the QuoteDetails ListPrice field is a text box named txtListPrice, use code like this for cboProductID after update:
That suggestion assumes the Products and QuoteDetails tables both include a ProductID field and its data type is numeric. And cboProductID has ProductID as its bound field and uses a query as its RowSource similar to this: