Page 3 of 3 FirstFirst 123
Results 21 to 23 of 23
  1. #21
    Join Date
    Apr 2006
    Location
    London, UK
    Posts
    10,569
    Plugin Contributions
    25

    Default Re: drop shipping module

    Post #20 mis-quotes what I said in post #3. and loses the point that the question I was asking was rhetorical. However I broadly agree with mybiz9999's conclusions.

    This is a hugely complex area that intrudes into many of the areas in which Zen Cart operates, and in different ways each time. Zen Cart's current architecture doesn't work well with this sort of mod (even if a common set of functionality could be agreed at a sufficiently detailed level to allow development). However the object-orientated architecture with proper plugin support planned for 2.0 will be more amenable to it.
    Kuroi Web Design and Development | Twitter

    (Questions answered in the forum only - so that any forum member can benefit - not by personal message)

  2. #22
    Join Date
    Aug 2011
    Location
    Little Rock, AR USA
    Posts
    10
    Plugin Contributions
    0

    Idea or Suggestion Re: drop shipping module

    Hello to all contributors of this thread. It's taken me about a week to install Zen-Cart v1.3.9h from the FreeBSD Ports, sniff around the PHP code and configure a working custom template.

    This is my first post . . .talk about jumping from the kettle into the fire. Drop shipping is indeed a can of worms. Kuroi is on point, as is mybiz9999's comment regarding SAP. SAP is expen$ive, and expen$ive to implement.

    During January - October, 2003, I was part of a small team that developed an API for a major fiber optic cable manufacturer's "backend" purchasing system (ERP) with a web browser based interface provided by (what was then) CableNet International, Ltd. (a UK company). Development involved IBM's OS/400 DB/2, COBOL and the CLP. The cable mfgr's ERP system was an ASI (American Software, Inc.) product. The bigger parent company has bought back the stock of the cable mfgr. held by a "partnered" corporation, and now has now elected to convert to SAP. the system used by the parent company. . . .enough of my resume'.

    One complex consideration of interaction with a vendor's ERP system (assuming the vendor is willing to let you interact with their in-house/backend system) is the fact that a web browser application is a stateless protocol, and the vendor's system is probably a stateful session.

    One issue, for example, involves [FONT="Courier New"]quantities on hand[/FONT]. If your web-store receives a purchase transaction, then you need to check the vendor's QOH by initiating a query for the same which, for example, returns a transaction that posts a current QOH of three items. The Catch-22 here is that let's assume your web customer sees that three items are available, but the customer decides to go get a cup of coffee before placing the order. In the mean time, your vendor sells two of the three on hand, and your web customer's stateless web browser still displays three on hand. Fifteen minutes later, your web customer returns to his/her desk and proceeds to complete a purchase of two of the three items that the vendor's system previously posted as available.

    Obviously your web customer is going to be disappointed (to say the least) because now your vendor only has one item left. How this scenario is handled can become very complex. Your vendor's stateful/session system doesn't know what your web customer's browser has done . . .your web customer may have clicked out of your web store and purchased elsewhere. In any case, it's unlikely that your vendor's system will try to maintain state and generate an event driven transaction to update a web browser display that may not exist (and essentially, it can't because . . .remember, we're dealing with the HTTP protocol).

    To protect the integrity of the web customer's purchase, you need to go back to the well with an instruction that tells the vendor's system that your web customer has committed to the purchase of two items. In our example, the vendor now has to return a transaction that informs your web customer that insufficient quantities exist.

    OK . . .fine. Your web customer decides to purchase the remaining one item. Essentially, the process starts over at this point, but once the commitment to purchase the one remaining item is received by the vendor's system, then ideally, the vendor's system should allocate or lock the item record while the purchase is completed (this to prevent another customer from jumping in and purchasing the item out from under you . . .other inquiries should also reflect QOH less the allocation qty.). This completion process could involve such things as calculation of shipping cost and taxes, ship-to/bill-to addresses, etc.

    Payment will depend on your relationship with your vendor. If you're say . . .net 30, then you take payment from your web customer and no payment is transmitted for verification to your vendor and you pay your vendor with a single end-of-month payment, but on the other hand, if you're COD with your vendor, then this becomes more complicated and time consuming. You want to make sure that you're paid before you transmit a payment from your purchasing account.

    Now, remember that locked item record in your vendor's system? Suppose for whatever reason, the purchase transaction falls through . . .credit card authorization declined, your web customer blown away by a tornado . . .your vendor's system has no way of knowing, so how long to maintain the allocation lock on the item? Who knows . . .a rhetorical question?

    Developing this type of interaction will require a lot of "face-to-face" meetings with your vendor's IT people. Hopefully, your vendor will already have a drop ship system in place. Testing your interface will be time consuming and tedious. What if your vendor (probably) does not have a test system? Ultimately, your vendor's willingness to provide the service may very well depend on how much volume you're projecting to do with them.

    I hope I haven't come across as too negative on this. In fact, I'm very interested in drop shipping.

    OTTF,
    Ron W.

  3. #23
    Join Date
    Jan 2012
    Location
    Las Vegas
    Posts
    28
    Plugin Contributions
    0

    Default Re: drop shipping module

    Quote Originally Posted by fotofx View Post
    I am actually working on one now for a customer. They only use one drop shipper, so shipping will be calculated from shippers origin. The order has to be uploaded to the drop shipper after payment is confirmed. Email of the order will not be accepted. Does anyone have a "map" of the checkout-payment process. I need to ensure checkout success and then call my module. Trying to figure out where to put it that will allow multiple payment types and only execute on success.

    Any thoughts?

    Steve
    I also use one drop shipper, and would be interested in this module.

    Thanks in advance.

    Mike_B1

 

 
Page 3 of 3 FirstFirst 123

Similar Threads

  1. v150 What shipping module to use with shipping drop down box
    By U3nme in forum General Questions
    Replies: 6
    Last Post: 3 Nov 2012, 09:44 PM
  2. Shipping module for drop-shipping
    By litepockets in forum Addon Shipping Modules
    Replies: 73
    Last Post: 18 Apr 2012, 07:27 PM
  3. Drop Shipping Purchase Order Module
    By jderrers in forum All Other Contributions/Addons
    Replies: 86
    Last Post: 9 Jul 2009, 09:30 AM
  4. Need the Drop shipping module
    By Dralion in forum Addon Shipping Modules
    Replies: 8
    Last Post: 8 Jun 2007, 06:31 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
disjunctive-egg
Zen-Cart, Internet Selling Services, Klamath Falls, OR