[ic] Preorder & Stock Alert Question

[Dave Barr]

At 1:46 pm -0400 4/10/00, Mike Heins wrote:

[del]

>Thanks for the thoughtful comments.
>
>How would you suggest we make the decision about what is to be done?
>I think you know this, because of your "minefield" comment, but I will
>reiterate for the record that Interchange is not an accounting system,
>and that any inventory it keeps has to be taken with a grain of salt. It
>is designed to work in concert with feedback from an actual accounting
>system.....
>For instance, some people want inventory decremented when the item
>ships. This is a problem with any sort of shipment prediction based
>on inventory level, obviously. And if you also sell via phone, you have
>to keep the inventory up to date there. The obvious solution is a shared
>inventory database, but there are some problems with hooking that up in
>the real world.
>I put the inventory stuff in under protest -- representing that we can
>actually keep track of that is a bit misleading. We cannot hope to unless
>we are tightly coupled with a purchasing/MRP system.

And thankyou Mike for taking an interest, I was worried as I realised 
after I had sent the mail that I had more or less spouted a "stream 
of consciousness" without *really* thinking it through or doing my 
homework ... apologies to follow  :-)

Suggestions. Interchange is a multi-purposed/tiered solution, I am 
not selfish enough to ask for solutions to cover only my needs and 
desires and suggest that we look at the problem from at least two 
sides (with further levels incorporated). It would make sense to 
continue with the current implementations based on manual 
intervention via the excellent Admin backend, this would cover areas 
that I had previously forgotten to take into account (thanks again!) 
such as faxed/phone/eMail orders. I can understand your apprehension 
to add the inventory functionality but strongly believe that it is an 
*essential* element to the eCommerce platform. I wish to make the 
experience of buying from the end users point of view as transparent 
(as well as straight forward) as possible. Nothing piddles me off 
more when I'm buying items off the Net than not knowing if the item 
is in stock and when (or indeed "if") I am likely to receive it.

I represent what I would call the "Corporate" end of the scale, 
customised automated external CGIs being a necessity with having an 
external third party fulfilment house communicating with our cart 
server. It would not be practical to have a team of monkeys working 
in the background manually updating orders and sending "state of 
play" eMails to our customers. This in the second level or "Small 
Storefront" end of the scale would work very well. There is of course 
the middle ground where a mixture of the two would need to be 
addressed, that is what I meant earlier about "further levels 
incorporated".

How to get around this... blimey, quite a can of worms...  :-)

As you mentioned, Interchange was never intended to be a 
one-stop-shop solution with built-in accounting and inventory 
management, this makes sense as there are too many variables to take 
into account. 'IF' mentioned in his follow-up the idea of a wish list 
of supported "hook-up" proprietary software, this 'could' work, but 
the underlying question of background data management remains before 
establishing those programmes. My main concern is with adding to 
Interchange so many proprietary hacks (or additional proprietary db 
tables) that upgrading in the future would become a nightmare (been 
there, seen it, bought the "T"). If we can establish the data flow 
and base requirements to meet the needs of the many as opposed to the 
few, then the solutions will hopefully become more apparent.

More to follow...

>  > The 1st conformation eMail makes no mention of this either (that 
>any item on
>>  order is back ordered) and it is a manual process of amending the order per
>>  line via Admin (which works well, bar the fact that Billing Country
>>  'disappears' when a partially shipped conformation eMail is sent [?]) which
>  > allows the customer to see the state of their order.
>
>I think we can set that one up with a Knar value that would set the status
>to something (I will default to backorder) on a partial ship.

Yes... that would make more "logical" sense, from a programatical 
point of view as well as to the end-user/customer. Routines could 
then be applied to do a "heads-up" that this is a special case order 
(Backorder Vs. Pending)...

(I think you fixed that with the 4.5.7 CVS available today)

>  > Maybe (like Amazon...pleeugh) a partial ship of order routine could
>>  be built in?
>
>Can you give more specifics? Do you mean the customer checks "I WANT
>partial shipments" or "I DON'T WANT partial shipments" and you honor
>that?

Ahem, first apology... Yes, that is exactly what I meant, so I guess 
your ESP powers are on the rise  ;)  Like above, this could be used 
as another heads-up routine to signify a special case. Then a whole 
new set of routines would come into play to establish the new 
shipping costs incurred with having 2 or more shipments made on one 
order. (Now that in itself is a nightmare on Elm St!)

>  > I realise this is a minefield subject, and am not making a complaint
>>  [honest], its a fantastic start and am merely trying to understand
>>  where this will be heading as I will have to automate alot of this as
>>  we will not be doing fulfilment in-house and will be sending data
>>  back and forth between the third party fulfilment house and our
>>  remote cart server... joy  ;)
>
>I am doing a bit of this with a vendor serviced by 12 different
>fulfillment houses. So I know about that "joy". 8-) We are just trying
>to keep track of when we sent them the order -- shipment status is a
>ways off.

12? [gasp... shudder]... I'm having kittens trying to work out how I 
am going to get around the problems with having one centralised point 
of fulfilment - you are a braver man than I Mr. Heins!

>  > As for the Stock Alert, it sends a conformation mail and that is
>>  where that ends...(i.e. no writing of data to userdb) I guess
>>  (hopefully) this will be added to the userdb and be activated by
>>  "Alerts and Recalls" under mail_list in the customer control section
>>  of Admin?.. Or do you have other ideas?
>
>What functions would you have that data do? Isn't that made redundant
>by a query like:
>
>	SELECT code,order_number,sku FROM orderline
>	WHERE  username = ?
>	AND    status != '__UI_SHIPPED_STATUS__'

This is where I wish to *really* apologise (slaps head and makes 
mental note to "try harder"). I didn't do my homework (or indeed use 
my brain), that's where the "stream of consciousness" comes in...

>I have done a cron routine for Interchange in the past, where
>a series of conditions is set up to automatically generate alert
>emails (that was for an auction system). I think that is the way
>to go.

That's definitely the way to go, and the way I anticipate how I shall 
be approaching the problems mentioned. Its a case of establishing 
what will be used and where it will be stored (in the db) in order to 
make the routines tick. I hadn't looked at the likes of the orderline 
table to see what was currently available -- I shall endeavor to do 
my homework before writing and making a complete fool of myself again 
:-)

>Once again, thanks for the comments.  I am very interested in
>creating a dialogue about this type of issue. As we integrate with more
>ERP/accounting systems, we will need to set up a series of models which
>can be selected at different points in the process.
>
>In fact, perhaps we can let it begin with your message. 8-)

So Mike, I am grateful that you replied in such a positive tone and 
have helped me to see several ways of approaching the impending 
problems, this topic of discussion is good as it will open my eyes to 
several topics that I had previously overlooked. So, as long as the 
inventory functionality remains (with an order decrementing the 
current value, which I believe is important) many things can be done 
with the UPDATE command in SQL via external CGI scripts.

Possible follow-ups;
Vote/Poll on the types of Accounting/ERP systems that IC/MV users are 
trying to hook into their carts.

Further configuration options added during cart creation:
	Is your inventory controlled in-house
	Is your inventory controlled by a third party
	Do you use the ABC accounting system
	Would you like to create additional tables to handle backorders
	... etc etc ad infinitum...

Any dialogue most welcome...
Regards
Dave

-- 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dave Barr        eCommerce Technical Manager      CricInfo Ltd
www.cricinfo.com   dave.barr@cricinfo.com    Tel: 01249 700748
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~