[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Re: [ic] Preorder & Stock Alert Question
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Interchange-users mailing list
Interchange-users@www.minivend.com
http://www.minivend.com/mailman/listinfo/interchange-users
