Update Order ACTION - Update '$0' Order Lines

Hey @emre, you said:

I have a problem where my ITEM is Zero priced and the Operator enters the Price. The issue is if I call Update Order Action with a Price Definition after the Operator has entered a price the Price is reset back to $0.00.

Is there a way we can avoid this? As the ACTION is called with no selected Order as desired it will update all orders. The Zero priced one is reset.

The desired behaviour would be to not reset n Item to $0.00 (Zero) PRICE is there was no Price Entered for the Price Definition.

GIF DEMO:

I like how you show the keyword “Price” after the operator has entered a price!

Counter Sales

@pauln I think your describing an issue I faced a week or so ago.

We have a regulars price list.
I have several items as ‘Open Priced’ like specials.
The implementation of the regulars price list was originally select all and update ‘Price Tag’ with {PORTION} so as to keep portions.

What was noticed that is a regular had ordered an open priced item swiping their fob would reset the order back to 0 as there was no price defined for that tag.

In theory this would reset ANY order which had received a ‘Change Price’ function.

My solution was to filter the ‘Select Orders’ action to a new state.

You would presumably want to duplicate this as part of the change price flow if used.

Then because we cant negatively map you obviously need a general version of this state for everything else;

This was then the rule for the changing of the price.
Ignore the ask question,
The first unshown select orders is select all = falce to clear any selected orders.

Umm nice work around @JTRTech - I was thinking about heading down that track but thought this really should not be the default behaviour?

When The Update Order ACTION is called it works well for not changing prices to a Definition Price if there was no price defined. So I feel it should work the same for Default Pricing “Price”.

I would like to see Emre “poo-poo” it first… :smile:

I see what your saying, that custom price tags default back to Default ‘Price’ if there is no custom price set.

I think there might be complications with that as its not that there is no happy hour price but there is no price set for any price band…

Yes Emre did some recent work on that a few days ago - fantastic. What the behaviour is - “leave Price alone” so when trying to change it to a Definition that is zero it gets left where it is. I would expect this behaviour instead of going to Zero.

PS: I really pushing Price Definitions for accuracy as these are a major function in our Marketplace.

1 Like

See what your saying…

But this is because of the existing method of if not defined use default price which happens to be set to zero…

On that basis would it not be good/more controllable to have a True/False field for ‘Update Overridden Prices’?
As this in theory wouldn’t just be if 0 but if you had manually changed the price.
Since we know the current price tag and what price it should be that if the existing price differs from the listed price for the price list currently set?
This way it would not only not change to zero but if you had overridden the price but maybe just discounted with change price that a change of price list would not reset the price overide?

What if you were purposefully wanting an order to be 0 priced?
I have this for some ‘included’ items although have not looked at how they would be effected by such a change.

Totally agree with you on this point and if I wanted to build in the ability for “persistent manual price changes” then your method would be best. This possibility had crossed my mind.

What throws me out is the default behaviour of entering a price from the default keypad; selecting an item with 0 PRICE and having the price appear. I really liked that functionality :disappointed: - no extra actions, no extra rules, simple defaults.

I like that too but dont use it personally as prefer the space to a keypad so use a change price action with [?Price] prompt with keypad.

That flow would be incorperated in such a flow as the current price would still differ from the listed price for that product :slight_smile:

You could in theory just built this yourself in a similar manor to my post above by making a automation command executed rule using the price tag as command value and a custom state flow for manual overides or any other senario seen fit for the command/action to key on which would allow it to be used for any price list change however a “persistent manual price changes” option would be allot simpler :slight_smile:

Just realized thats what you said anyway LOL

If this is cause a loophole in your flow you could overide this by setting a price - even 0.01, but using a [?prompt] to set the price instead and not show a cancel button to FORCE setting a price.

1 Like

Hey @emre

Could you give me some direction on this? Is this an issue where Prices are set to a Price Level that is Zero?

Can you PM me a backup?

1 Like