I have an interesting one that I have searched for and can't find the solution to.
I am working with a developer who is trying to integrate our incident management tool into Palladium, a finance tool and we're stuck on being able to import invoices correctly.
Scenario
There is a view that contains the invoices but there's several elements to the invoice. The view here shows all the billing parts and includes value amounts for Products and Expenses but it doesn't show details of the products or expenses as there may be multiple line items in that invoice. There are 2 further views one containing the product information and one containing the expense information. There is a common field that can be used to reference the invoice in each of these views called Billing_Log_RecID.
Here's how the default invoice search view looks when exported. I've selected entries where there are products and/or expenses added.
What I need to do is display in a view a line item for each invoice but break out the multiple expense or product items into I guess separate columns so for example
Inv1 COMPANYNAME COMPANYID INVTOT PROD1 PVAL1 PROD2 PVAL2 etc EXP1 EVAL1 EXP2 EVAL2 etc, there's never likely to be more then 2-3 different items but to be safe 5 is a good number.
Here's an example of a query showing products attached to an invoice, I have highlighted where there are multiple lines.
The same exists for the expense items
Hope someone can help.
Dave
Related
I need to create a report that is using 2 datasets. One (yellow) is bringing product data, the other (green) is bringing company and quantity data. They can both be linked using a unique ID field.
One product may be used by up to 8 organisations and each organisation may have multiple departments.
Can someone explain how I can build a report to give the excel output as shown in the image.
I am familiar with lookup in SSRS, but not sure how to use this where groupings are required from the second dataset.
Right now, I am designing the database, as such I don't have any code. I am looking to use sql server, asp.net if that is relevant.
I have a big number of stores and a big number of products too, both in some thousands. For the same pId, prices may vary by sId. I would build it like this:
1. one "store" table containing fields (sId, name, location),
2. one "products" table containing fields (pId, name size, category, sub-category) and
3. "max(sId)" number of price tables containing fields (pId, mrp, availability).
where max(sId) is the total number of stores.
I would rather not make "max(pId)" number of tables containing fields (sId, mrp, availability) as I need to provide a UI to each store so that they can update the details about product prices and availability at their respective stores. I also need to display some products of a particular store but I never need to display some stores for any specific product. That is, search for stores by product is not required, but listing of products by store would be required.
Is this a good way or can I do better?
You appear to be on the right track and I will offer some recommendations. Although there is no requirement to display some stores for any specific products, you should always think about how the requirements will change and how your system can handle that. Build your system so that you can answer questions like these easily - What stores have product ABC priced under $3/piece?
Store table should contain, as you mentioned, information about stores. Take Aaron Bertrand's comment seriously. Name the fields in a way that the next developer can read and figure out what it is. User StoreID instead of sID.
StoreID StoreName ...other fields
------- --------------
1 North Chicago
2 East Los Angeles
Product table should contain information about products. It would be better to store category and sub-category into a different table.
ProductID ProductName ...other fields
--------- --------------
1 Bread
2 Soap
Categories can be located in its own table with hierarchal structure. See Hierarchal Data and how to use hierarchyid data type. This may help in finding out the depth of each top level category and help management decide if they are going overboard with categorization and making life miserable for everybody, including themselves unknowingly.
Many-to-many ProductCategory table can link products to categories. Also keep a history table. When a product's category is changed, keep track of what it was and what it is set to. It may help in answering questions such as - How many products were moved from Agriculture to Construction category in the last 6 months?
Many-to-many StoreProductPrice can bring together store and product and a price can be defined there. Also remember - prices may differ by customers also. Some customers may get discounts at a certain level. Although this may be too much to discuss here, it should be kept in the back of the mind in case a requirement to support customer discount structure comes up.
StoreProductID StoreID ProductID Price
-------------- ------- --------- -----
1 1 1 $4.00
2 1 2 $1.00
3 2 1 $4.05
4 2 2 $1.02
Availability of the product should be done through the inventory management database table(s). For example, you may have a master table of Warehouse and master table of Location. Bringing them together would be WearhouseLocation table. A WarehouseProduct table may bring together warehouse, product and units available.
Alternatively, your production or procurement facility might be dumping data into ProcuredProduct table. Your manufacturing unit might be putting locks on a subset of products while building something out of it. Your sales unit might be putting locks on a subset of products they are trying to sell. In other words, your products may be continually get allocated. You may run queries to find out availability of a certain product and that can be a little taxing. During any such allocation, the number of available units can be updated in a single table (which contains calculated available products that you can comfortably rely on).
So...depending on your customer's needs, the system you are building can get fairly complicated. I am recommending that you think about these things and keep your database structure flexible to anticipated changes. Normalization is a good thing, and de-normalization has its place also. Use them wisely.
Note: I'm working with a large complex database, so for clarity's sake I have simplified the set up below.
I struggled a bit with how to title the question since it's a bit of a complex question. I hope it's accurate enough....
A bit of background first:
I have an Access 2010 database that contains a one-to-many relationship between a table Called "Products" and a table called "Datasets" (ie I have a bunch of products, and each product has multiple datasets). Each has an autonumber key field (p_ID and d_ID respectively) as well as numerous other fields.
I have a form (lets call it frm_Main) that has two subforms: sub_Products (based on the "Products" table) and sub_Datasets (based on the "Datasets" table). On the main form I have a control ctrl_SelectedProduct which is linked to [sub_Products]![p_ID] to see which record in sub_Products is selected / has the focus, and the sub_Datasets subform is linked to this control so that it only displays Datasets records that belong to the selected Products record.
On the main form I also have a number of controls that I'm using for filtering the data in the subforms. For example, I have a control ctrl_Category. I have this control coded so that when the user changes the value of the control, a filter is applied that limits the records in sub_Products to only those that have a p_Category value equal to whatever is chosen in ctrl_Category. If the control is blank, it will show all records. All this works great when if comes to filtering based on fields in the Products table.
Now the problem:
My problem is that I also want to be able to filter based on fields in the Datasets table. For example, Datasets has a field called d_Status. I want the user to be able to chose the status in a control (ctrl_Status), and based on this:
1) sub_Products will be filtered to display only those Products records that have an assotiated Datasets record (or records) that has d_Status equal to whatever was chosen in ctrl_Status
then
2) when a Products record is selected in this filtered sub_Products, sub_Datasets will only show the Datasets records that has d_Status equal to whatever was chosen in ctrl_Status
I know how to do part2. But I have no idea how to get part1 to work. Since sub_Products is currently based on the Products table, which does not have the d_Status field, I have no way to filter it based on that field. Thus, I'm assuming my first step will be to change my setup so that sub_Products is based on a query that combines the two tables (or at least adds the d_Status field).
If I do that, however, I get duplicate Product records. I can't use the query's Unique Values property because if I have a product that has two datasets, one with status "Current" and a one with status "Archived", then those aren't considered duplicates, and the product info is there twice. If I don't have the status field displayed, it shows only unique products initially, but then I can't subsequently apply a filter based on that non-displayed field.
I also tried basing sub_Products on a Totals query in order to utilize the Group By functionality, but I still couldn't get it to work right. Even if I could I don't think that's the best solution, because you can only have 10 fields with Group By, and my Products table has more than 10 fields that I need displayed in sub_Products.
I feel like I'm now just going around in circles and am at a loss of what to try from here. Please help!
Couldn't you add something like this?
Private Sub ctrl_Category_AfterUpdate()
Form_frm_Main.Recordsource = "Select * from Products where p_ID IN(" & _
"Select p_ID from Datasets where d_Status = " & _
Me!ctrl_Category.Value & ")"
End Sub
Alternately, you can access the childform via the parent of the other child form.
This is a non-working snippet just to give you the idea:
Me.Parent.otherChildFormName.Form.Recordsource = whatever
I would be grateful if somebody could help me to find an elegant solution to this database design problem. There is a company with a lot of different products (P1,P2,P3,P4) and a lot of customers (C1, C2, C3, C4). Now they have a simple database table to deal with orders, something like
20101027 C2 P1 qty status
20101028 C1 P2 qty status
Now I would like to create groups of products ( eg. (P1+P3+p4) and (P2+P3)) that could be purchase together for a reduced price. What is the best way to represent such groups in a database system? Dealing with these groups as individual products doesn't work, because I need the functionality of replacing, adding or removing products from the groups. So I need to keep the currently given table of products.
Thanks for reading. I hope I will get some help.
Add a new table product_group_promotions, with an ID, name and discount price. Then create a table product_group_promotions_products that links products to product group promotions. This will contain a product group ID and a product ID. This way, you can place one product in multiple groups, and let groups contain multiple products (of course).
Jan's answer is correct but incomplete.
You'll also need start and end dates of the promotion. You'll probably want to enter next week promotions so they are ready but not apply them until appropriate.
Discount price may not be enough either. You also will need to get business rules from business people as to how to apply the discount. It could be a percentage or a free item or a fixed amount. If a percentage do you distribute the discount evenly, proportionally, on the cheapest product, the most expensive? If a free item, which one in the set is free. It could also be a fixed amount, $10 off if you buy x, y, and z. Is the discount applied more than once. If someone buys 5x of P2 and P3 do they get the discount on all of them or just the first ones. Is there a limit over a time period. As in the past example, if you don't give me the discount on all 5, I would just fill out 5 orders of 1 each and get the discount you were trying to prevent. If so you'd have to go back through previous purchase by that customer to see if they've received that discount.
You can see how ugly this can get. I would clarify with the business EXACTLY what they plan to use this new feature for and run through these use cases with them.
As Q, asked, if the basket of purchased items is large enough there could be more than one discount possible. Do you have to determine what to give, do you present a list of choices back to the UI... and the recalculate.
This is why I have mercy on department stores who screw this stuff up. It's not simple.
On the surface this is simple sounding but in reality it's very complex.
"Dealing with these groups as individual products doesn't work, because I need the functionality of replacing, adding or removing products from the groups."
Here are several things you need to look at:
Current Inventory vs Past Orders
How do you deal with Price Changes on P1, P2, P3
How do you handle adding a new product or products to an existing group
How do you handle removing a product or products from an existing group
In my opinion you need two sets of tables.
Tables that make up your current inventory
Tables that record what customers purchased (historical data tables)
If you need to reconstruct a customers purchase from six months ago, you can not rely on the current data givin the fact that a grouping may not look the same today as it did six months ago. So, if you do not already have a set of historical data tables for customer records then, I recommend you create them.
With a set of historical data tables that house what was bought by the customer you can pretty much do what every you want to the current invetory data. Change prices, regroup products, make products obsolete, Temporarily suspend a product, etc.
First post, please be kind.
NOTE: I have reviewed entry #20856 (how to implement tagging) but feel this is different due to the fact that the tags method I'm considering is organization specific in my app. I’m hoping someone can confirm the direction I’m going or point out some other options.
(background) We are building a web application that gives different organizations visibility to their inventory in different locations. The database stores users, organizations, sites, and items and there are links from sites and items to organizations that allow us to determine which items / sites to show to which users (based on their organization).
It is common for two (or more) organizations to want to use the portal to check on the stock status of (for example) Widget A in the Los Angeles Warehouse. That part is fine. However, the different organizations also track unique information about Widget A. For example, Org 1 wants to track the color, volume, and primary vendor for each item. Org 2 wants to track Color, Stock Type, Inventory Cycle, Buyer Code for each item. I want to avoid a situation where I have to have a table loaded with all these possible fields and then figure out which organizations use which fields.
I’m considering using something along the lines of tags, but adding a tag category, and having the tag category be defined at the Org level. So, the basic table structure would be something like:
Table: OrgTagCategory
Fields: OrgId, TagCategoryId, CategoryTitle
Table: OrgTag
Fields: OrgId, TagCategoryId, TagId, TagTitle
Table: OrgItemTag
Fields: OrgId, ItemId, TagId
Then, when the user logged in the main dashboard the grid would include their appropriate item fields as columns in the grid. So, from above example, Org 1 would see Item#, Description (would be shown for all), color, volume, and primary vendor. Org 2 would be shown Item#, Description, Color, Stock Type, Inventory Cycle, Buyer Code.
Am I overthinking this or is there a simpler method of doing this that I’m missing? All thoughts / feedback sincerely appreciated.
That should be no problem, but you're storing the OrgId redundantly. Also it seems like there could be some overlap (probably a lot of overlap, realistically) between tags and orgs.
Here's how I'd do it:
Table: OrgTag
Fields: OrgId, TagId
Table: Tag
Fields: TagId, TagTitle
Table: ItemTag
Fields: ItemId, TagId
This way each org is associated with the tags it's interested in, but you don't have redundant tags. A given tag that's used by multiple orgs just gets a bunch of rows in OrgTag, instead of multiple rows in Tag with the same TagTitle.
You'd only need a table OrgTagCategory if there were multiple tag categories per org. But you haven't described this extra association as a requirement.
Based on your description I sketched a simplified model and combined it with the observation pattern. This should enable you to track various item properties and user preferences for viewing them. Admittedly, the Preference table may grow large, but data has to be stored somewhere anyway, and you may retrieve it using sql, which simplifies the business layer.
- Organization and person are types of users. User table has columns common to all users, while Organization and Person tables have columns specific to each one.
- A stock item (widget class) can be found at several sites (warehouses); a site stores many items.
- One item belongs to one user; a user can own many items.
- Measurement and trait are types of observations. Measurement is a numeric observation, like height. Trait is a descriptive observation, like color.
- An observation is of a specific type (height, weight, color), there can be many observations of the same type.
- One item (widget class) can have many observations, an observation relates to one item only.
- A user can prefer to display many observations; an observation may be preferred (to display) by many users.
UPDATE
We could simplify user's subscription to item details (observations) by tagging observation type, for example height, weight, width would be tagged with: all, dimensions, physical. Some other tags would be: accounting_interest, tracking_specific, etc. A user would then subscribe to tags only. Tags (could) form a hierarchy with ALL at the top.
- One observation type (height, weight, color) can have many tags, one tag belongs to many observation types.
- Each tag may have a parent tag forming a hierarchy.
- A user stores preferences for a set of tags that she usually monitors.
UPDATE 2
Now we can sort out who is who and who owns what. In this modification a user (now a person) can work for more than one organization (having several part-time jobs or contracts). An item belongs to a organization now. A logged-in user can see all items from all organization that she works for.
My first quick thot on this would be that - if this is just limited to 'showing' particular fields to particular Orgs on Dashboard then it is better to handle it on the App side. If there's any other usage of 'tagging' then pls clarify.
Here's a simple approach -
You can store a field [OrgDashboardFields] in the Org master table or the OrgItem table. This will be a comma (',') separated list of fields to be shown on the dashboard. At run-time fetch the [OrgDashboardFields] field and parse the comma separated list in the app and make the Dashboard Grid behave accordingly.
Or, if there's a dynamic-query framework then based on the [OrgDashboardFields] field you can create a dynamic SQL-query and get the desired result which is purely Org specific.