Super Orders v3.0 Support Thread (for ZC v1.3.9)

[chadderuski]

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

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

[DivaVocals]

Not thinking you were criticizing anything.. I get that your workflow is different.. I am unclear why, if you have a PO module which allows this, did you think the one that comes with Super Orders should be modified.. I guess I'm unsure what you think is "missing" from SO3..

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

[chadderuski]

Not thinking you were criticizing anything.. I get that your workflow is different.. I am unclear why, if you have a PO module which allows this, did you think the one that comes with Super Orders should be modified.. I guess I'm unsure what you think is "missing" from SO3..

Ah, right. The two mods store and handle PO's differently. Was just looking at using one (SO3) and modifying it myself if need be to accommodate our work flow.

[DivaVocals]

Ah, right. The two mods store and handle PO's differently. Was just looking at using one (SO3) and modifying it myself if need be to accommodate our work flow.

But why?? You already have a PO module which does this.. The one that comes with Super Orders doesn't REQUIRE SO3 to use..

[chadderuski]

Now that I didn't know! I thought your PO solution was integrated into SO3!

[DivaVocals]

Now that I didn't know! I thought your PO solution was integrated into SO3!

It's just a PLAIN OLD Zen Cart payment module -- for POs.. Nothing more special about it.. It was bundled in with Super Orders because the client Super Orders was originally built for needed a PO payment module.. They still have to create a SUPER ORDERS PO Payment record once they have the PO in hand..

From the readme:

Go to Admin > Modules > Payment, you should find "Purchase Order" at the bottom. It should look familiar when you install and configure it, since it mimics the "Check/Money Order" module.

[cjcraven]

Additinal language support for payment types does not work (never has).. No idea when this will be addressed as I understand WHAT it does, but not how to fix it.. I do have a fairly decent woraround included in the upcoming release..

As for the data sheet issue, there is a fix posted in this support thread.. Please do a search in this support thread to locate this fix.


Posted via Mobile Device

Re: Blank Page Orders Listing
Did the search then went through the 40+ pages in this forum. I found the topic on page 5, 8, and 23 but did not find a resolution. Perhaps I overlooked it - could you suggest the fix or point me in the right location??

[cjcraven]

Super Orders is based on a custom module written for a US client. Super Orders 3 is based on this original code with improvements as noted in the readme.. Hence support for additional languages is lacking in MANY areas of the add-on.. ALL of these areas would required re-writes to support additional languages.. These re-writes are over my paygrade to tackle.. But it's open source and if a community member were to tackle this, and be willing to share it, I'd be happy to add it to the codebase..

Re: Language
Thank you, I'm just a simple shop owner and can make do with the Japanese text for these fields for now. Full language intergration is a lot of work but would be greatly appreciated.

[DivaVocals]

Re: Blank Page Orders Listing
Did the search then went through the 40+ pages in this forum. I found the topic on page 5, 8, and 23 but did not find a resolution. Perhaps I overlooked it - could you suggest the fix or point me in the right location??

I am not able to search for this right now.. (on a mobile device posting from a hospital)

Search in this thread for "super_data_sheet.php".. The "Print" button prints the Super Data Sheet. I posted a fix in this support thread for that file.

[cjcraven]

Additinal language support for payment types does not work (never has).. No idea when this will be addressed as I understand WHAT it does, but not how to fix it.. I do have a fairly decent woraround included in the upcoming release..

As for the data sheet issue, there is a fix posted in this support thread.. Please do a search in this support thread to locate this fix.


Posted via Mobile Device

Re: Payment Types
The simple workaround is to create a payment type for each language with a different code. Each language has a naming and code but only one of them actually seems to work, the others become duplicates and you get a db error.