Hi
We are facing an issue that when we add a ticket to our basket and then login, which attempts to move the session to a Member only MOS (using ranking), this fails as an item is in the basket so sessions should remain on the default web mos.
The issue we are seeing is that when logininfo is called straight after the login call it is returning the MOS (and origMOS) as the Member MOS. When testing this manually, which imposes a delay in between the login call and the logininfo call the MOS then shows as Default Web MOS,. So it looks like the call we are making staright after login is catching the data at a state where it is still changing.
The reason we are doing this is that we had an issue where we needed to pass MOS in to the SYOS and Best Available calls and so this is now resulting in those showing incorrect information and either prevents users from adding items to their baskets or in some cases removes all previous items from their basket when adding a new one - obviously due to MOS discrepancies.
Has anyone else experienced this issue?
Thank you
Mark
So, first off, the performance already added in the cart needs to be available in the new MOS as well as the pricetype.
Then you must use the api method ChangeModeofSale. It's been awhile so I am a bit foggy on this. Ranking will associate the new MOS to the session; however the ChangeModeofSale is what actually changes the MOS. The ranking procedure alone does not change it. So after performing a get login info, you can store the id of the new mos and pass it to ChangeModeofSale, At least that's what my foggy memory recalls.