Hi Diva,

Thanks for looking into this. Hope you didn't feel I was criticizing SO3's handling of PO's! I have no doubt that you are correct in your assessment of the proper handling of PO's.

I guess we have an uncomplicated relationship with our customer base. It's rather small (several thousand vendors). We are a true wholesale distributor, so we don't sell direct. Generally a customer will either FAX, e-mail or call in their order. Most if not all include a generated PO number from THEIR system. The order is entered in our ye-ole ancient IBM risc 6000 aix box, and an order confirmation is faxed/emailed back to them for validation and their actual pricing. So we end up with OUR order number and their PO number tied together. So from our point of view, allowing the customer to enter their PO # at order entry would be convenient.

I've had our website up and fully functional for years, but convincing the powers-that-be and allowing customers to login and submit orders via the website is a good thing has been a challenge to say the least.

But in other news, after years of banging away and stubborn indecision, "they" have finally made the decision to upgrade our server/enterprise software (to SAP).
So all this may be for naught as SAP has an integrated web solution far beyond what would be practical to add to ZC (like real time pricing and inventory).

I'm still excited about SO3 for other clients I have. Really do appreciate all the hard work!

-cj

Quote Originally Posted by DivaVocals View Post
So now that I looked at the mod I THINK you are using (there are several PO add-ons), I don't completely understand your question..

The workflow supported by Super Orders' currently included PO module is the standard practice used by most businesses who issue POs and businesses who accept POs..

  1. Invoice/Estimate received
  2. Invoice/Estimate is routed to customer's accounting department
  3. Accounting issues PO
  4. Customer provides PO data to vendor
  5. Vendor processes the order
  6. Vendor bill customer

In the standard flow, vendors do not receive POs until AFTER an order has been placed. The reason is simple. Their customers generally need to get the final total and an invoice/estimate from the vendor that they will route to their accounting department BEFORE issuing a PO to a vendor. (unless it is a blanket PO being issued - meaning it will be applied to multiple invoices until the PO is out of funds, and a new blanket PO will be issued).

Your workflow assumes that the amount of the estimate is known BEFORE the order is placed.. This is not a standard accounting workflow with regards to POs and their use in MOST businesses.

However, the add-on I THINK you are using captures PO numbers at checkout which seems to accommodate your desired workflow.. So I'm not sure why you think the PO module that comes with Super Orders should be updated to have the same functionality?? (capture PO numbers at checkout??)

It seems that both workflows need to be supported and there are already TWO payment modules which handle POs both BEFORE and AFTER the order is placed..