I need to allow Sales staff to add options in Quotes, and display a subtotal line under each option.
I'm thinking of using a couple of comment lines:
OPTHEAD (Sales will detail the option here, e.g., "Option 1: Full product line"
Sales Quote lines
SUBTOTAL
I'd like to replace the SUBTOTAL comment line when it is printed, with the total of lines between that and the Option Header. Along the lines of "Subtotal Option 1, $1000"
Could someone please provide me a pointer to achieve this? I'm having trouble finding guidance/documentation for this, but it must be a fairly common requirement.
The method you mention is one possibility, however might be difficult to manage.
I suggest you add a new field to the Sales Line table e.g. Sales Option of type Integer. The field would also need to be added to the Sales Quote subform page.
The salesperson then needs to assign a value to the Sales Option field in order to group the lines into options.
The Sales Option should be added to the report dataset for each line which will enable you to group on it on the RDLC layout.
You can then add a sum per group.
Related
In Sale Order Line, there is an option to write down some notes in the lines as "note". When the Sale Order is confirmed, the data is sent to stock.picking (Transfers) and the lines from Sale Order Line appear in Detailed Operations in the Transfers page, but without the note.
Where should I look for in order to customize and/or configure it to achieve such goal?
There is no differanciation of line types for stock.picking lines as for sales order lines. In sales order lines it's made by the field display_type.
Trying to imitate this feature for pickings could end in a mess. Personally i would try to get all notes and either copy them to a new notes one2many field or just in one new note text field on the created picking. Or maybe even "easier" is to compute all notes, because every picking line (stock.move) has a connection to the original sales line (sale_line_id) and so indirectly to the sales order or even directly by field stock.picking.sale_id.
I have an Access Database and i'm trying to create a report that has me a bit stumped. Basically this report is going to display each employee's order processing performance based on a user specified date range, the report gives an itemized detail of each unique product on the order and it's price and Quantity.
Each Product has an 'Assembly Category' either 'DRFLUSH' or 'FRAME'.
In the summary of each Order i want to total the Quantities of each Assembly Category in a separate field.
Initially i rushed this report and have now found that the way i intended on completing this task is incorrect as the value given is only a Count of how many times an instance of each value 'DRFLUSH' or 'FRAME' occurs. I started with as follows: (Please ignore the bad practice with field naming i have taken this database on from a previous employee).
=Count(IIf([ASSEMBLY ITEM CATEGORY]="FRAME",1,Null))
And
=Count(IIf([ASSEMBLY ITEM CATEGORY]="DRFLUSH",1,Null))
However as previously stated this is wrong. I want the fields to sum the Quantity of each line item but only where the criteria is matched.
Any help is greatly appreciated, i'm sure this is a ridiculously simple task however i just cannot seem to wrap my head around it today.
Thanks
Alex
Sorted this by changing the statements to as follows:
=Count(IIf([ASSEMBLY ITEM CATEGORY]="FRAME",[QTY],Null))
=Count(IIf([ASSEMBLY ITEM CATEGORY]="DRFLUSH",[QTY],Null))
I'm very new to Microsoft Access and I've run into a bit of a conundrum. I'm building a basic Access database that can help my Dad use past invoices to quote future jobs. I really only have two objects I'm working with. An invoice Table that hold all the costs that we paid for specific metals in 2013 and a Form I'm making that pulls information from that table. In my basic table I have a Currency field called PPLB(Price Per Pound). Now throughout the year we sometimes buy the same metal multiple times and if you know anything about metal, you know that the amount of metal you purchase sometimes affects the price that you pay. So in my Quoting Form I have a Query that looks like this->
SELECT DISTINCTROW Avg(MAT_QuickBookInvoices_2013.PPLB) AS [Avg Of PPLB]
FROM MAT_QuickBookInvoices_2013
GROUP BY MAT_QuickBookInvoices_2013.Material, MAT_QuickBookInvoices_2013.[Material Subtype], MAT_QuickBookInvoices_2013.Spec, MAT_QuickBookInvoices_2013.Shape, MAT_QuickBookInvoices_2013.Sizes
HAVING (((MAT_QuickBookInvoices_2013.Material)=[Forms]![MAT_QuoteTable]![Mat_CB]) AND ((MAT_QuickBookInvoices_2013.[Material Subtype])=[forms]![MAT_QuoteTable]![SubType_CB]) AND ((MAT_QuickBookInvoices_2013.Spec)=[forms]![MAT_QuoteTable]![Spec_CB]) AND ((MAT_QuickBookInvoices_2013.Shape)=[forms]![MAT_QuoteTable]![Shape_CB]) AND ((MAT_QuickBookInvoices_2013.Sizes)=[forms]![MAT_QuoteTable]![Size_CB]));
I know that's long but what it's doing is grouping the different type of metals into their most common grouping using Combo Boxes in the Quote Form and then finding the average price for that group. So now the problem. When I run the query it pulls up the correct price but when it transfers to the combo box it rounds price to the nearest whole dollar. How can I change or correct this? I've tried changing and formatting the source table as a double instead of currency and this hasn't helped. Any hints at all would be appreciated.
On the Property sheet for your comboBox, set the Formay property to Fixed. Then. immediately underneath that, set the number of decimals to 2 or 3 or whatever. That should do it.
Cheers -
I am looking for a solution or to be told it simply is not possible/good practice.
I currently have a database whereby I can create new orders and select from a lookup table of products that I offer. This works great for the most part but i would also like to be able to add random miscellaneous items to the order. For instance one invoice may read "End of Tenancy Clean" and the listed product but then have also an entry for "2x Lightbulb" or something to that effect.
I have tried creating another lookup table for these items but the problem is i don't want to have to pre-define every conceivable item before I can make orders. I would much prefer to be able to simply type in the Item and price when it is needed.
Is there any database design or workaround that can achieve this? Any help is greatly appreciated. FYI I am using Lightswitch 2012 if that helps.
One option I've seen in the past is a record in your normal items table labeled something like "Additional Service", and the application code will recognize this item and also require you to enter or edit a description to print with the invoice.
In the ERP system which we have at work, there is a flag in the parts table which allows one to change the description of the part in orders; in other words, one lists the part number in the order and then changes the description. This one off description is stored in a special table (called NONSTANDARD) which basically has two fields - an id field and the description. There is a field in the 'orderlines' table which stores the id of the record in the special table. Normally the value of this field will be 0, which means that the normal description of the part be displayed, but if it's greater than 0, then the description is taken from the appropriate row in the nonstandard table.
You mean something like this?
(only key attributes included, for brevity)
I have a quote that contains items (store in table QuoteItem):
QuoteItemId, QuoteId, ItemId, Quantity etc.
Now, I need to be able to create a group of chosen items in the quote and apply a discount on it.
Well that's simple, I create two more tables:
Group: GroupId, DiscountPercentage
GroupQuoteItem: GroupId, QuoteItemId
Let's say I have 30 items in a quote.
I made a group that contains items 1-20 from the quote and I applied a discount on it.
Now I need to have another group that contains items 10-30, the problem is about those inner 10 items, I need to control whether the discount should apply on the items after the other discount or it should be on the items' base price.
For instance, I am gonna talk about item no. 15 in the quote: QuoteItem.Cost = 100
I applied 1st discount of 10% = 90.
Now I want to apply the second discount, I need to be able to control if the discount should be on the 100 or should be on the 90.
Same is when I have multiple discount groups and when I wanna apply a complex architecture of discounts.
Any assistance will be really appreciated.
I would look into adding a column to the GroupQuoteItem table, GroupQuoteItem.Priority. This column would be used in the query that determines the final price. If you have N discounts with the same, highest priority, they will be stacked atop each other (the order doesn't matter, thanks to associativity of multiplication).
If all of these high-priority discounts are later removed, lower-priority discounts can take their place. This should help you in setting up pretty complex discount structures.
I hope that at least gives you somewhere to start from.
It really depends on your own business rules. Do you want to apply the discounts on the price after discount or on the original price. When you ask questions like this it helps with SAMPLE Data then show us expected results.
This may be one of those rare times in normalization when you want to store data that you could calculate otherwise. So, in QuoteItem, you could have a Cost field and a DiscountedCost field. If they're the same, then you know no discount has been applied, if they are not, then a discount has been applied. By having this field, you would also be able to do comparisons on what the discount is already and whether you want to add the additional discount. In fact, you could also store that number in an ExistingDiscount field.
Why not store a column in the Group table that specifies whether or not the discount can be accumulated with other discounts versus if it must be applied to the base price only? You could name the field something like "ApplyToBasePriceOnly."
Other than that, I agree with JonH that a lot of this logic should be placed in business rules. I think your general database structure looks pretty good.