[quote=“pauln, post:1, topic:8883, full:true”]
I am looking for a simple method to navigate directly to “a” Customer Account. [/quote]
So I have the simple use of Navigation and Automation working well but I cannot get back from the Account Screen if Close is Used. The thing is you cannot chain navigation events as you always wind up on the last Navigate Request.
So above I have a custom Entity Search Screen with 2 new Automation Buttons which calls the Account shown in the Caption. If I use the Account Screen CLOSE we head back to SambaPOS Main Menu.
Can I confirm with anybody that the CLOSE is hardcoded and cannot be altered. I think this must be the case as if I use the SELECT ENTITY BUTTON from Ticket for that Entity Account - CLOSE will return back to FIND and then back to TICKET with Open Ticket in Tact.
It will be Button Mania! which I am trying to avoid. Also Note I have place an Automaton button which would be the same as Automation from a Question (which Account do you wish bla bla bla) and this also RETURNS TO MAIN MENU.
Simple, a customer Customer Entity Screen using a search widget. I have added 2 Automation buttons to navigate to an Account for different Entity:Bar Wallets. As you can see all works fine BUT when I use the CLOSE BUTTON we are returned to Main Menu?
I have tried stringing some automation together to get back to Ticket BUT any navigation AFTER this above Navigation to Accounts TAKE PRECEDENCE. Also used chain automation command so the second Navigate is not listed under the same rule.
Can this be done - going back to Ticket or simply Entity Selected after using CLOSE from the ACCOUNTS Screen?
[EDIT:] Hummm can you call Change Ticket Entity from the main Menu…
[EDIT2:] Yea-NO! Looks like its something to do with CLOSE and the hard coded logic only Emre can answer that. I hooked up some automation from the Ticket Screen so I could control Close/Open Ticket but Navigation just will not stop.
Pity as the “Account Details” screen has everything I want; Filters; Printing; Payments; Running Balances etc. Saves a lot of automation required.
Not sure I am following you. I mean create your own button mapped to that account screen for close that uses that action. Could call it Return to Ticket or something other than close.
SCREEN = Entity Customer but I have placed a Custom Search Grid onto it with Entity = Bar Wallet.
If I can do this problem solved as I can unmap the default buttons…
[EDIT] The Screen itself will be called “Bar Accounts” and not “Customer Search”. Back in 30 ins as dropping my son off to his mates place.
Store Ticket Id in a program setting while inside that ticket at some point possibly when you navigate to accounts… Call it TicketId May need to use Save Ticket action to ensure it generates an ID.
Use the Application Screen Changed event and use constraint of Previous Screen Equals AccountView
Use Display Ticket Action and set {SETTING:TicketId} as the variable for Ticket Id
That will probably work but might run into other issues when viewing accounts outside of tickets. So we could constraint the rule that uses Display ticket somehow maybe storing a setting for it to check…
I gotta say though its almost ironic how hard you try to “Use Default behavior” and avoid automation when the reality is there is no default behavior, its all customized, Emre just provided basic setup for people to start with. Most of your attempts to try and use basics as you say typically involve much more elaborate automation than you think
Embrace automation start customizing it for your needs and stop fighting it
Your requests really are asking to make it less simple and more customization yet you think your asking for more basic features. Most of these default behaviors were made to do simple basic things not meant to be customized much.
Look I know, I know, we have discussed this a few times but I am getting more into Automation now. I just trying to dig deep into the simple stuff, when I finally get a negative or positive from you guys as far as what can be done then I look for alternatives in Automation.
I might add I am really careful not to ask for customization leading to complex setups - that is exactly what I am trying to avoid. It is just little called it “Polishing” I have been asking for…
What I am saying is Emre designed those simple basic things for other types of people. You are not needing that in reality you need more customization.
I have to disagree you have studied every basic simple setup implementation Emre has done and have requested changes to most of it. You constantly request him to polish these things into what you need. So reality is you need more customization options. These functions are simple and work for most people… but not for you… I hope you can see my point.
Lets start looking beyond that and start pushing automation get it more flexible which is what you really need.
I will have a look at Application Changed Event - I did not think about that as I did not seen it fire. Of course it will not fire if there is not a Rule attached lol
You can test that event with simple Show Message action. Just leave constraint empty and start going through screens. Show message will list the screen names if you use one of the parameters [:PreviousScreen] or [:CurrentScreen] as the Message paramater
I am thinking you could get it to work with simple constraint looking for a specific setting this would ensure it only fires display ticket when you need it too. You would have to decide when to store that setting. In effect its almost like you would create a custom state flow using settings instead of States. lol.
Yes - lol - came to the same conclusions decided to use [SETTINGS:x] which work well, and already storing values there. The great this about “Multiple Account State” is that I can HIDE BUTTONS…Whereas [SETTING:x] you cannot. I been pushing the boundaries with both of these as you have read.
I was just a little worried about losing the plot with 1 gazillion States…
I didnt mean use actual states I meant use SETTING and it would in effect be similar to how States work. IT would become a State flow but it would not actually be a State. When I say State flow I mean as in the literal definition not a SambaPOS state flow.
Let me demonstrate a flow I was thinking you could consider.
You start a ticket for Ed. Ed has multiple accounts… You add customer Ed to ticket You save ticket so it generates ID then store that ID in a setting you then navigate to Eds Wallet account from the Entity Screen… It stores a Setting called ISTICKET and value is True. When you close that account screen it triggers the Application Screen Changed event and your rule fires checking a constraint for SETTING:ISTICKET Equals True it then fires Display Ticket action with paramater of SETTING:TicketID that we stored earlier this loads the original ticket you started with.
By the way I will apologise in advance as I going to request a parameter for Custom Search Widget. Its only a request, Emre can always say no. I think custom Search Widgets work well and still have a life span so feel it is worth putting it out there.
Never will take offence - always will listen to reason.
) I thought I would try to explain how I got to my recent posts. Below is the top image with new blue markings:
is that I can HIDE BUTTONS…Whereas [SETTING:x] you cannot. I been pushing the boundaries with both of these as you have read.