It just cannot happen 
1 Like
Sorry @emre
I just cannot seem to trap current {PRICE TAG} for an Order as this is the last ingredient needed to update a Price:
Show Dialogue:
Should be simple right?
Also I will need to trim {NAME} to remove the PORTION suffix.
There is a tag for product name without portion.
Use it on my template to override Name.Portion to have a space rather than the point.
Not at PC but it will be something like product name or item name.
Check the ticket template tag list, it’s on there somewhere.
1 Like
Cool thanks JTRTech - {PRODUCT NAME} does the trick. Just need the last piece of the puzzle now “Price Definition” used for an Selected Order Line?
#oh no a conundrum!
So here is the thing {PRICE TAG} is working but the Update Order ACTION is effecting the change of Price of the DEFAULT Price as no Price Tag is passed! The resultant new Price for the Order Line will be listed as a Regular Price.
In this case {PRICE TAG} = Null.
I think I remember reading somewhere that {PRICE TAG} is broken. What version are you running?
1 Like
I did almost sugest that, I remember that being said and sure emre said fixed for next release, which release was next after that am not sure LOL
Good Morning Q - yep running the latest beta version V5.1.60.
Hi @QMcKay
Can you cast your eye over the generated SQL - I think the last bit is wrong? Should it be:
AND isnull(ppr.[PriceTag],'(REG)',[PriceTag]) = 'Happy Hour'
Are we missing the ,[PriceTag]
[EDIT]
Wait a moment - HOLY MOLLY - writing Normal Prices…
Oh no the “Old Cache” issue, I was worried about that 
No, it looks correct. It should be, as it is:
isnull(ppr.[PriceTag],'(REG)') = 'whatever'
The reason we do that is for when we want to update the Regular Price (the price that has no PriceTag). By using the isnull(field,'replacement') then we don’t need to change the code for the special case of the Regular price. If we did not do that, then we would need to change it to the following, but only for the special case of the Regular price:
[PriceTag] is null
Instead, we match our special case to (REG) and we don’t need to change our code:
isnull(ppr.[PriceTag],'(REG)') = '(REG)' -- the price has no PriceTag
isnull(ppr.[PriceTag],'(REG)') = 'VIP1' -- the price has PriceTag of VIP1
ISNULL is similar to COALESCE(field,'replacement')
Hey thanks Q! - guess what I (we) have it working, “the unworkable solution” actually working. The only thing I am having an issue with is the Cache.
When the price is updated, I do Refresh Cache ACTION but this only takes effect when I cancel the order and close ticket. What actually happens then is the Menus go blank? Then when I reclick Department all comes back and the new price is available in any Portions and Price Tag.
As we are in a Ticket, ummmm…
Hey @emre
Well the permanent pricing workflow is operating well with 1 small hitch - the “old cache” scenario. From the GIF below you can see the price is written to the DBO using script but the Menu Pricing Cache is not refreshed until I close the Ticket and I guess Navigate.
I know you would have special controls here to ensure SambaPOS works fast and efficient.
So what can you suggest?
PS: The Menu goes blank on its own, I assume due to the Refresh Cache Action.
[EDIT]
Well another midnight finish 
Happy to accept any suggestions over night. I am thinking of an no so elegant flow of placing the ticket on hold (this may submit an old price?), switching Menus or Navigate or something, reload Ticket. Sort of clunky…
Do you know you need to reset cache on all terminals if it is a permanent change 
1 Like
That is a good point @emre!
But for now I have the problem that the Cache Reset does not do the Job as we are in middle of a Ticket? I do not know how to get around that one…
Anybody feel free to offer suggestions while I pull the remaining hair from my head overnight.
Nope switching Menus back and forth will not do it after a Refresh Cache.
On next update mutation m{postResetProductCacheMessage{id}} API command will reset product prices inside tickets on all terminals.
Also updateProductPrice mutation will include notifyClients parameter to do that automatically after updating a product price.
PS: Refresh cache won’t work inside tickets and setups a late trigger that works after closing ticket as refresh cache action clears entire cache and that may create issues with ticket’s state data.
4 Likes
Ok thanks @emre.
Are you referring to what I am trying now? If Yes, no problems I have already removed all that flow late last night (morning). The message to the user now says “WARNING: Please log off/on each terminal to refresh the new prices”.
1 Like
I know it’s a bit late and proably not what you wated but I made a website for effecting price changes permanently, with a nice interface which can be accessed from anywhere (your phone) or a managers office or simply from a HTML viewer inside an entity screen.
1 Like
Hey sounds cool 
why don’t you drop a GIF here and show us what you have done?
Here you go.
You can see in that Large Flat white how I was waiting for the cache to update…
Oh Yes I remember seeing that - neat work. You should try implementing @QMcKay’s code above as it will do Price Levels Tags and Portions.
You may not need that as you used MenuItems for Portions but his code is always genius. Best of all it works first time so I do not know why I even question it sometimes…