price+level report showing Custom price only

Am looking to get a price level report that shows the standard price in one column and the custom price in another column as seen when enter the prices when creating a price level list.

If print the lists per price level it puts the standard price into the column if there is no custom price - the only work around I can find is to enter 0 value as the custom price but this means when invoicing have to click the drop down box each time an item is sold which does not have a custom price, but at least client can export the report to excel and filter by price to delete the 0 prices so can get the custom price list printed

Um thats what i have done I think - they are on enterprise but does not work as every item does not have a custom price entered they have left blank so puts in the standard price in the custom price field hence suggested entering "0" - but means the invoice as said brings up "0" - they change the standard prices regularly

It seems to me, if they are changing the 'standard' price regularly, they should be changing the associated custom price too - or at least have a custom price they want to promote.. If a database field is empty (ie: <null> ) then the other point might be, to mention/highlight to Reckon that <null> fields should not carry over the content of previous field. (If that is the issue). Such behaviour is the result of filling to clear output before reading fresh values. But from a sales consistency/quality point of view, if prices are volatile, surely some thinking needs to go into the relevant 'price level' figures as well, to ensure customers are not being over/under changed? What is the issue of failing to fill in the price levels, when standard prices change?

Gail, you've possibly highlighted two issues here. (1) a business risk, and (2) a programming oversight. But let's see what the DEVT team have to respond to in this regard.

The prices change due to the exchange rate being so volatile around the world and the nature of there business and as they buy stock from numerous countries, its nearly a full time job changing the prices all the time especially with out the report they want. They currently export to excel and painfully manipulate the report to be what they want

There are not a huge amount of custom prices as is on a volume buying basis or company type that the discounts come into play BUT there is no common factor with the some 71 price levels of which have between 3 and say 600 special prices out of 1500 items to amend

I see Gail. Exporting to Excel with a guideline of a percentage target (in Excel extra field), comparing the difference to existing values, to audit/check desired changes, may be the solution after all.

I wonder if focus could be placed more on the standard price being kept up to date, with price levels based on a percentage of that (rather than an entered/negotiated price). And then couple an overriding exchange rate FACTOR to the whole deal, seeing as it seems that exchange rate is the underlying aggravation FACTOR here. Perhaps a different way of tackling the matter, but that will depend on commercial arrangements preferred for quoting/dealing, I imagine.

Back to your original post above, am I right in understanding that custom pricing is PER ITEM, and that there are some items that do NOT have a custom price, which is the root cause of this dilemma. Perhaps for THOSE items that have no custom price, you actually make a price level RULE called "no custom price" that picks/selects all such items and has a rule that deliberately affects a zero percentage change to the standard cost. IE: it automatically calculates a custom price that is in fact the same as a the standard price (which is effectively correct in the end). Then the report issue would not be present. PLUS: you can print of an exception report that reminds you of such items having 'no custom price' VERSUS all the other real custom price varied items.

During invoicing, you'd have that dreaded drop down box for the items that hve 'no custom price' but it would be obvious that they are one and the same $ value.

As a safeguard then, you only have to mess with standard prices, whenever you have an exchange rate event giving rise to such a process.

This is a complicated thing to explain, but I share this with you, to avoid a dilemma i had of a similar nature in the past..... Bear with this, there is a good message within....

Say there are a number of items that are selected (in the Price Level List setup) that pertain to a specific Price Level "name" In the above, I mentioned a price level called: "No Custom Price". Actually that would yield a report ("Item Price Level List") with a modification to display "Price" as well, and you'd see the 'custom price (per the "no Custom Price" column, showing an identical value to the standard price (the "price" column.) That idea above, was purely mentioned to force a value to sit in all the columns on the report for you, rather than those pesky '000's)

But the 'exception' report aspect is something else (and requires other integrated toolsets too). I was guessing you'd like to be able to see, amongst the many items you have, which of those have customised pricing and those that don't/ IE: try to identify the ones that have just carried over the standard price into the custom price as per the paragraph above.VERSUS those that were not part of that rule at all.

From an invoicing/estimating point of view, the drop down "Price" field will show all relevant "price Level" rules. For those that have been selected at a "per item' (as opposed to fixed %) basis, you;ll get to observe whether that item is part of the "no custom price' regime or not. That may be one extra dropdown you may like or don't like - I guess that is the potential trade-off. OR it can be used as a good audit on sales staff to be aware that they are dealing with an item that in fact does NOT have a custom price - and that is worth knowing at estimating/invoicing time. But that is a personal choice for you to consider. It may not be on your radar.

Observe the three windows in the following screenshot, whilst I explain.....(I'm using a Reckon demo company which sells doors and windows of different sizes, as the example)But back to how to extract the list that you see when EDITING the "Price Level" I've shown the screenshot with both the invoice 'experience' on the right, as well as the small selection of only 4 items I've chosen in this example to be the items which have 'no custom price'

So, to the challenge of finding just those FOUR items that have that rule applicable to them. Your dilemma, is that the normal REPORTS in Reckon, show ALL ITEMS, with the application of the price level RULE, whether that rule applies to them or not! SO, attempting to solve both your "avoiding 000's" issue, and also the desire (I'm assuming) of finding what items really are applicable to the rule itself (ie: just the four "Windows Alum 1500x ...." special examples in the screenshot above left, well the normal reports can't distinguish between the two matters. IE: for those items that the RULE has not been specifically selected for (on left of screenshot), then the result of applying the rule (as the overall report seen in the background above shows), would be the SAME result. That's because the background report is applying the rule, as opposed to the left EDIT screen showing only the items that are really RELATED to the rule.

SO: using something like an exception report with tools like say: QODBC and EXCEL could look more closely at the nice results sitting in the "Edit Price Level" like screen, rather than the large"Item Price List" report in the background above. Notice the highlighted line on the large background report. I've pointed to the $300 1st of 4 Windows that are the 1500mm sized windows that are the only 4 items that really have the 'no custom price' rule set for them. Yet, the line ABOVE that, for the smaller 1200x mm Window, at $280, is showing what the price for THAT ITEM would be, had such a rule applied to it! So, the large report is mis-leading. You can't really differentiate between those that have the ruleset for them, as opposed to running a report that applies such a rule to ALL items (at the same time!). That's the tricky bit.

But deep down, we know from the EDIT screen, that there are only 4 items that fall into this category. And that is the exceptional list of items that might be nice to see on paper. But for that, you'll need API/SDK or QODBC/FastReports type solution, as the output from above standard reports in RA, applies the rule to all items (not what you need).

Anyway, I may have got you away from your original request, but the process of showing the two sides of the coin in operation here, will permit you to explore ways of getting around that burden of wondering how to avoid applying custom prices, purely because of an exchange rate change, and seeing the impact of taking this idea too far, yielding the dilemma I've illustrated above, is one that I battled for some time over, in a former job - and I felt sharing that with you might save you going too far down that path, without being aware of the fact that many of the reports are showing the APPLICATION of the price level rule, even or items that you would otherwise painstakingly setup as only a minority group. It can be misleading if you don't take a close look at the EDIT screen on the above left side. It's a real 'gotcha' otherwise.