I have three tables:
(1) Audit Findings [up to 100 records per audit, depending on the standard],
(2) Types of Documents to check [different types and number, depending on the standard against which an audit is conducted], and
(3) Names of the documents that need to be present.
Records of (1), where the main audit findings are entered, contain a portal that lists the required documents. This list is provided by table (2). Next to this portal list, a "Document Type" relationship between (2) and (3) ensures that the correct document names appear after the relevant document types. Example: Shipping Notes: SN2234, SN8926; Sales Invoices: IV5673, IV7251, etc.
I now need to link the document names of table (3) to the audit at hand, i.e. table (1), to avoid that audit findings for any company always list the same ported document names. In other words, the 2 = 3 relationship needs to be filtered based on the audit date (clients are audited once a year), client number and standard info (most clients are multi-cetified) contained in table (1). Is this possible? And how?
This is more of a guess than an answer. It is based on the following assumptions:
Three tables, related as:
AuditFindings --< DocumentTypes --< DocumentNames;
There is a portal to DocumentNames, placed on a layout of AuditFindings, showing all the DocumentNames "grandchildren" of the currently viewed record in AuditFindings.;
There is a ActiveDate field in AuditFindings table;
There is a DocumentDate field, in the DocumentNames table.
Now, in order to filter the portal mentioned in point #2 above, so that it shows only records of matching dates, set the portal filter to show records only when:
AuditFindings::ActiveDate = DocumentNames::DocumentDate
Related
I would like to be upfront. I am by no means an expert or even really all that technologically savy. However, I inherited a training system where the only way to find out if someone was current was to dig through physical file cabinets and try to find the hard copy. I have put together a basic access database to try and improve the situation. It is working okay, but I've run into a problem.
Previously, most training occurred in small enough batches that data entry is not a problem. (No more than 15-20 entries at any one time). However, regulatory changes now mandate the company put everyone through a mandated training course annually. This means all information about the training will be identical, except for the employee ID associated with the record.
Right now I can manually enter this training just like any other, but I have to perform this nearly identical data entry for each of the several hundred employees in the company.
I would like to be able to enter the pertinent details about the training and then have access create an training record for each employee.
The current form asks the user:
Who is the employee that was trained? (The appropriate employee ID # is entered)
Which subject was trained on? (the appropriate selection is made via combo box)
On what date was the training completed? Date picker is used to fill.
What is the file path to the scanned training certificate? (The majority of this field is prepopulated so only the actual file name needs to be typed. For the specific training in question all the employees of the company will be included in the same scanned pdf. Subsequently, this filed will be identical for all employees.)
The fields on the current form are:
txtEmpID – Text box, where employee ID # is entered. Corresponds to
field "empID"
cboTask – Combo box, where the appropriate training
subject is selected. Corresponds to field "reqID"
txtDate – Text box, the date the training was completed.
Corresponds to field "trngDate"
txtFilePath – Text box, file path to the scanned pdf of the physical
training record. Corresponds to field "trngLocat"
I would like to be able to fill in the information for 2-4 but then have access create a record, for each employee in my employees table, where all the data from 2-4 is identical.
Is this possible?
Pertinent Tables:
tblEmployees – keyed on field “empID” which is the employee number.
tblTrngSubjects - Keyed on field "reqID" which is autonumber.
tblTrngRec – keyed on field “recordID” which is autonumber. Relates
to tblEmployees through field “empID”. Relates to tblTrngSubjects
through field "reqID".
tblTrngRec is the table in which the records will be stored.
Other information that may be relevant:
I am using Access 2016.
I once had a copy of Access 2010 the missing manual…but that was in 2010. It has been almost a decade since I did anything more advanced than “docmd.openform”
I greatly appreciate any and all advice. Thanks, in advance.
I admit I haven't worked with access in quite some time, so some of the syntax might be slightly off. You need to know a list of employee IDs that were in that training.
Insert into tblTrngRec(empID,ReqID,txtDate,txtFilePath)
select empID
,25 'You need to enter this manually
,"6/9/2020" 'You need to enter this manually
,"Enter your file path"
from tblEmployees
where EmpID IN (enter a comma delimited list of employee IDs)
I have a report that shows maintenance information for medical instruments. The selection criteria are based on several tables and fields. I needed to change the criteria, but results were not as expected. I managed to find the cause, but do not know what to do to get to the wanted situation.
So basically the problem is as follows:
I have 2 tables that are linked:
* Equipment (information related to a specific instrument eg EqmId)
* ObjectFeature (information related to a specific feature eg ObjfEqmId, ObjfId, ObjfYesno)
An equipment can have 0, 1 or many ObjectFeatures, and the tables are linked via
Equipment.EqmId -> ObjectFeature.ObjfEqmId with a left-outer join.
The problem I have is that i want to filter out al EqmId's where (ObjfId="64" and ObjfYesno=1). I do not want to see these EqmId's in the final list.
In my current setup, I have only removed the ObjfId="64" lines, but since an EqmId can have multiple features, it still is present in the list...
In my original report Equipment is my main table, so I need a way to filter this table before I do further filtering and joining.
I find myself limited in the selection formula, and thought of using a SQL command on the database. But I can't get my head around how to do this.
How and where should I do the filtering?
I have a set of 100 “student records”, I want to have checkboxes for each "favorite_food_type" and "favorite_food", whichever is checked would filter a "bar graph" that counts number of reports that contain that specific "favorite_food"type" and "favorite_food" schema could be:
name
favorite_food_type (e.g. vegetable)
favorite_food (e.g. banana)
I would like to in the dashboard be able to select via checkboxes, “Give me all the COUNT OF DISTINCT students with favorite_food of banana, apple, pear“ and filter graphs for all records. My issue is for a single student record, maybe one student likes both banana and apple. How do I best capture that? Should I have:
CASE A: Duplicate Records (this captures the two different “favorite_food”, but now I have to figure out how many students there are (which is one student)
NAME, FAVORITE_FOOD_TYPE,FRUIT
Charlie, Fruit, Apple
Charlie, Fruit, Pear
CASE B: Single Records (this captures the two different “favorite_food”, but is there a way to pick out from delimiters?)
NAME, FAVORITE_FOOD_TYPE,FRUITS
Charlie, Fruit, Apple#Pear
CASE C: Column for Each Fruit (this captures one record per student, but need a loooot of columns for each fruit, many would be false)
NAME, FAVORITE_FOOD_TYPE, APPLE, BANANA, PINEAPPLE, PEAR
Charlie, Fruit, TRUE, FALSE, TRUE, FALSE
I want to do this as easy as possible.
Avoid Case B if at all possible. Repeating information is almost always best handled by repeating rows -- not by cramming multiple values into a single table cell, nor by creating multiple columns such as Favorite_1 and Favorite_2
If you are provided data with multiple values in a field, Tableau does have functions and data connection features that can be used to split a single field into its constituent parts to form multiple fields. That works well with fixed number of different kinds of information -- say splitting a City, State field into separate fields for City and State.
Avoid Case C if at all possible. That cross tab structure makes it hard to analyze the data and make useful visualizations. Each value is treated as a separated field.
If you are provided data in crosstab format, Tableau allows you to pivot the data in the data connection pane to reshape into a form with fewer columns and many rows.
Case A is usually the best approach. You can simplify it further by factoring out repeating information into separated tables -- a process known as normalization. Then you can use a join to recombine the tables and see the repeating information when desired.
A normalized approach to your example would have two tables (or tabs in excel). The first table would have exactly one row per student with 2 columns: name and favorite_food_type. The second table would have a row per student/favorite food combination, with 2 columns: name and favorite_food. Now each student can have as many favorite foods as you like or none at all. Since both columns have a name field, that would be the key used to join (combine) the tables when needed.
Given that table design, you could have 2 data sources in Tableau. The first one just pointed to the student table and could be used to create visualizations that only involved students and favorite_food_types. The second data source would use a (left) join to read from both tables and could be used to look at favorite foods. When working with the second data source, you would have to be careful about reporting information about student names and favorite food types to account for the duplicate information. So use the first data source when possible. Finally, you could put both kinds of visualizations on a dashboard and use filter and highlight actions to make interaction seamless despite the two sources -- getting the best of both worlds.
I'm creating a compliance mailing for my organization, the mailing will include merge fields that identify the office location, physician, and SiteId. The mailing will also include a table of information that is dependent upon the particular SiteId.
I'd like to use the import table function of MS word and set up a query that references a merged field (SiteId) so that the inserted tables populate the appropriate data for the particular site. I'm unable to do this.
How can I set up this document so that I can import only records from my source (an ms access query) that match the SiteId merge field?
Word's mail merge does not support one-to-many relationships. There are ways to coerce it, but only one of them can yield a table as a result and over the years it has become less and less reliable as Microsoft has not regarded it as important enough to maintain...
What you need to do is set up a query that provides ONLY the information you want displayed in the table, plus the key (SiteId). It's best to sort it so that all the SiteId entries list together, and are in the order the data will come through in the mail merge data source.
On the Insert tab go to Text/Quick Parts/Insert Field and select the Database field from the list in the dialog box. Click "Insert Database" and follow the instructions in the dialog box to link in the data. Be sure to set the Query Options to filter on the first SiteId from the data source. When you "Insert Data" make sure to choose the option to "Insert as a field".
This inserts a DATABASE field in the document which you can see by toggling field codes (Alt+F9). The field code can be edited and what you need to do is substitute the literal SiteId value you entered for the query with its corresponding MergeField.
When you execute the merge to a new document that should generate a table for each data record corresponding to the SiteId for the record. But, as I said, Microsoft hasn't done a great job of maintaining this, so it may require quite a bit of tweaking and experimenting.
If the results are not satisfactory then you should give up the idea of mail merge and use automation code to generate and populate the documents.
You can find more (albeit somewhat out-dated) information on this topic at http://homepage.swissonline.ch/cindymeister/mergfaq1.htm
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
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:
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
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.
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:
Me.txtListPrice = DLookup("ListPrice", "Products", "ProductID = " _
& Me.cboProductID)
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:
SELECT ProductID, ProductName
FROM Products
ORDER BY ProductName;