[ic] Preorder & Stock Alert Question

[Mike Heins]

Quoting Dave Barr (dave.barr@cricinfo.com):
> Debian 2.2.17, MySQL 3.22.32, IC 4.5.6 (latest CVS), perl 5.005, patch 03
> 
> Hi,
> This is mainly pointed at the developers in Akopia and have a quick 
> question about the Pre Order and Stock Alert functions, I notice that 
> with Interchange and the Construct Demo they are available when an 
> item reaches an inventory level of "0"... great idea! We're in the 
> process of setting up business rules with our main fulfilment house 
> and having a Preorder/Backorder system will be invaluable. However 
> (as I'm sure you are aware) they have not been fully implemented;
> 
> Preorder works as a normal order with the status ending up as the 
> norm of "pending" instead of "Back Ordered" which makes sense with a 
> multi-item order, but not per se with a single item order.

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.

> 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.

> 
> 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?

> I guess that's me being pedantic again [sorry]...
> 
> 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.

> 
> 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__'

???

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.

> 
> Enuff waffling, sorry for the long mail, if anyone has any comments 
> or have been working on similar ideas I would grateful to hear about 
> them.
> 

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-)

-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

I have a cop friend who thinks he ought be able to give a new ticket;
"too dumb for conditions".