v10 - More about 'real time stock control'

[Mike Hughes]

Hi Bruce,

I'm just trying to get my head around this and the implications. In essence, RT stock control will reduce stock available in RT for each order placed whether or not the order is paid for.

The only complication comes when the 'allocate stock for PSP pending orders' box is not ticked. In which case (from what I understand) actinic will make the stock available again when the RT stock is syncronised with Actinic on the PC. Is that right?

i.e If we take the example where I have one of an item remaining in stock, and have the box 'allocate stock for PSP pending orders' NOT ticked.

1. A customer tries to order but the payment fails. RT stock control allocates that item so now no-one, including that customer, can order it.

2. When the PC syncs with RT stock control, it downloads the order, marks the stock as available again and updates RT stock control so it can be ordered again.

Looking back at my last 100 orders, I can see that I had 16 orders where no payment was received (and this excludes orders where the customer followed up and paid later on by another method). Of these 16, 10 were duplicate orders where the customer had to try twice before payment was accepted.

In total, half of the 'payment pending' order, in this case 8 out 16, (and 5 out of the 10 duplicates) were enough to prevent the same order being placeable again. Until that is, actinic syncs back, sorts out the stock and marks it available again.

I'm not sure this is likely to be quick enough, however fast you do it. From what I can see, a customer is going to try and place the order, have a payment problem, click back and then try again, only to be faced with an 'out of stock' message.

From what I can see, this is likely to stop 5% of my orders (even with regular synchronising) and isn't really going to work. I can maybe lessen it by synchronising often and having the 'out of stock' message say 'try again in 10 minutes' but it's not really a great solution.

This really puts a spanner in the works. For this to work properly you really need the RT stock control to have the option of not allocating stock if there's no payment.

I really can't see myself using using this if it's going to cost me 5% of my orders. That's a worse impact than the very occasional oversold problem I get.

Mike

[george]

Mike, we probably get a `failed payment order` followed by a properly completed one every other day.

I think the ideal scenario would be to allocate the stock once payment is completed? Sometimes, not often mind, we get a wee rush for products at the same time, if a product has been mentioned on a supporters forum for example.

[brucet]

I am investigating this to clarify how it will work

[Mike Hughes]

Thanks Bruce,

This is quite a complicated topic as the best approach depends on stock levels, typical order quantities and frequency, the impact of 'oversold' versus 'lost orders' and the frequency of failed payments.

This is why I think an optional 'only allocate stock on payment' control makes sense. Let the website owner choose the option that's best for them.

It also avoids having to keep the PC on all the time which is something I'd prefer not to do.

Mike

PS. This would also avoid the situation where a competitor could create false orders to 'buy' your available stock at peak demand times such as a product mention on a TV programme, etc.

[brucet]

We are looking into this ATM. The difficulty is not the non-allocation of stock for PSP Pending orders. It's doing that while still allocating stock for PSP orders that don't end up as Pending. There's no way of distinguishing them in advance - only after the customer has gone off to the PSP and either completed payment, or not. I think somehow we would have to tie in the stock allocation to the PSP callback, which is significantly more complex because it's outside our control, and different PSPs may do the callback in different ways.

The only alternative is to not allocate stock for any PSP orders, and rely on the automated sync from the desktop to do that allocation after the orders are downloaded. That wouldn't be my preferred choice - it's rather hobbling the 'real' in real time stock. But we may be able to offer it as an option if the first approach can't be made to work reliably.

[Mike Hughes]

I think somehow we would have to tie in the stock allocation to the PSP callback, which is significantly more complex because it's outside our control, and different PSPs may do the callback in different ways.

This really is the only way to do this properly. For me it's worse to allocate stock to orders that aren't completed (i.e. paid for) than to not allocate stock at all since you're more likely to muck up a genuine order than prevent a problem with a possible future one through overselling.

Here's the thing. Real Time Stock Control is only important to control the allocation of limited stock. If the stock isn't limited then it isn't needed. To allocate limited stock to an order that hasn't been completed is more harmful than helpful. Especially when the same customer might try several times before being able to complete the order.

And requiring frequent synchronising to a PC to make this work means you might as well just nudge actinic to do an update every 5 minutes. At least you won't wrongly mark stock as sold out when it isn't.

I'm not sure I see the technical challenge here either. The Actinic scripts are
triggered by the PSP callbacks to create the occ files. What's wrong with updating stock at this point?

And while we're discussing this I want to point out that this is not just about PSP payments either. If I get an order from someone wanting to pay by cheque then I don't want to allocate stock for that order until I receive the cheque. They can often take weeks to arrive (or not at all) so again it would be wrong. I only want to allocate stock to an order when it's been paid for. Until then it isn't a proper order.

Mike

[george]

I'm not sure I see the technical challenge here either. The Actinic scripts are
triggered by the PSP callbacks to create the occ files.

Is this not complicated if the customer does not finish the payment process `properly`, clicking return to wherever.com as opposed to clicking on the top right `x`? (I'm maybe wrong on that though?)

I only want to allocate stock to an order when it's been paid for. Until then it isn't a proper order.

To add to the debate I would like the stock allocated for this payment method as we dont get many who dont pay. The ones that dont pay I find are usually one line orders from overseas who still think that COD exists. People who pay us by International Money order or Western Union often order many items so that stock levels have to be adjusted in our case.

An option per individual site is needed methinks!

[Mike Hughes]

Is this not complicated if the customer does not finish the payment process `properly`, clicking return to wherever.com as opposed to clicking on the top right `x`? (I'm maybe wrong on that though?)

No, the PSP callback triggers the OCC file creation irrespective of what the customer does.

To add to the debate I would like the stock allocated for this payment method as we dont get many who dont pay. The ones that dont pay I find are usually one line orders from overseas who still think that COD exists. People who pay us by International Money order or Western Union often order many items so that stock levels have to be adjusted in our case.
An option per individual site is needed methinks!

Absolutely. I just want to make sure Actinic realise this issue isn't just about PSP payments. Settings should be selectable for each payment type, not just on a global basis.

Mike

[george]

It'd be good to see others opinions on this. Looks like many are prepared to wait and see it come out and say it `could have been done better`, as opposed to chucking in their 50p worth now.

Actually, heres a plan, why dont Actinic ask their customers and ask what'd suit them best?

The revolution starts now.

Not.

*yaaaaawns*

[TraceyHand]

I think somehow we would have to tie in the stock allocation to the PSP callback, which is significantly more complex because it's outside our control, and different PSPs may do the callback in different ways.

Anything less would be a half-ass job, IMO

[pinbrook]

It'd be good to see others opinions on this. Looks like many are prepared to see it come out and say it `could have been done better`.

Actually, heres a plan, why dont Actinic ask their customers and ask what'd suit them best?

The revolution starts now.

Not.

*yaaaaawns*

Anything less would be a half-ass job, IMO

exactly.... at last we seem to be having the opportunity to spec stuff how it really should work and not the quickest and most convenient way the developer wants to code it. (see feefo thread too)

Let hope this continues and is taken into account - consider how many happy users there will be rather than disgruntled ones when it is released and actually comes up to expectation.

[rmorrow]

I'm not sure I see the technical challenge here either. The Actinic scripts are
triggered by the PSP callbacks to create the occ files. What's wrong with updating stock at this point?

You're right, Mike, it isn't really that hard. ActiveStock has not been tested with all PSPs, but I've not had any problems reported with the major ones it has been tested with (PayPal, WorldPay, SagePay, to name a few). It took me a couple of days to sort this out, once it had been brought to my attention that the option was required.

[Darren B]

exactly.... at last we seem to be having the opportunity to spec stuff how it really should work and not the quickest and most convenient way the developer wants to code it. (see feefo thread too)

Let hope this continues and is taken into account - consider how many happy users there will be rather than disgruntled ones when it is released and actually comes up to expectation.

You sure about this - IMHO whats said here is cherry picked not used as a basis for developement, hence all the other threads and wishlist items.

But my two pennith worth

For me allocating stock to orders not paid for would be a problem for me, especially at xmas time when stock can be at a premium and to lose orders because fred bloggs had trouble and tried three times to make a payment and successfully depleted all mystock of said item and lost me sales.

I have many kites worth a good few hundred quid and i can assure you i dont hold many instock 1's and 2's of these.

So i agree allocation should only be made when a psp call back is made, the ideal situation is that you decide how an order is handled by the psp, so where you have paypal you tick a box that says allocate stock before call back, AP the same again then you can decide by payment method.

I raise off line orders for payments by BACS but i never allocate stock as this is more successful than payment by cheque but some still dont make the payments.

So now onto offline orders, same again if im going to use the intergrated AP solution then i get the payment approval so allocating stock is fine, all other methods i dont want stock allocated.

I can see this will be like shipping 90% of it will be done but 10% will never get finalised and it will end up being an incomplete solution.

I hope i am proved wrong but you get to know how things are going to pan out after a number of years

[pinbrook]

You sure about this

at least we are having a discussion and pointing out potential areas that could be improved.

Agreed everybody will never be happy all the time.

[Darren B]

at least we are having a discussion and pointing out potential areas that could be improved.

But this has happened in the past thats why im sceptical, we all have ideas and suggestions but if they prove to hard to implement then they get ignored, which is fine but they are never really revisited at at later date which is the biggest frustration i have.

I know it sounds as though im mr doom and gloom but unfortunately its how i feel suggestions are looked these days. The contact form is a good example of suggestions dare i mention "captcha" and additional fields, we are still working with hacks.