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

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

DivaVocals:

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

2. Invoice/Estimate received

3. Invoice/Estimate is routed to customer's accounting department

4. Accounting issues PO

5. Customer provides PO data to vendor

6. Vendor processes the order

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

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

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

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

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.

chadderuski:

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

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

chadderuski:

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.

DivaVocals:

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

DivaVocals:

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.

cjcraven:

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.

DivaVocals:

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.

cjcraven:

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.Actually that does NOT work because there is other Super Orders code (namely the code which drives auto payments for credit card payments) which is dependent on certain payment types being configured in a particular way. Additional language support in Super Orders will require some substantial re-writes to be done correctly..

However, like I said I have a down and dirty workaround included in the upcoming release. It requires the use of a DB script to directly enter the payment types for additional languages.

DivaVocals:

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.

Is the fix in super_data_sheet.zip? I wish you a speedy recovery and thanks for helping from the hospital!

DivaVocals:

Actually that does NOT work because there is other Super Orders code (namely the code which drives auto payments for credit card payments) which is dependent on certain payment types being configured in a particular way. Additional language support in Super Orders will require some substantial re-writes to be done correctly..

However, like I said I have a down and dirty workaround included in the upcoming release. It requires the use of a DB script to directly enter the payment types for additional languages.

Nuts, I was hoping for the simple solution.

cjcraven:

Is the fix in super_data_sheet.zip? I wish you a speedy recovery and thanks for helping from the hospital!

Yes that was the fix! Works fine except for minor Japanese language issues. The fix is in post #55 http://www.zen-cart.com/forum/showpost.php?p=977666&postcount=55

Had SO3 installed for a while now and although only used test orders it seemed fine.

My site is beginning to receive orders and payment through paypal. However I have noticed that the payment details come through ok but the amount has not been applied automatically...
Just wondered if this is correct and I have to manually apply payment or if I have a bad install? as there is no PayPal option in the manual method.

Thanks

Rizla:

Had SO3 installed for a while now and although only used test orders it seemed fine.

My site is beginning to receive orders and payment through paypal. However I have noticed that the payment details come through ok but the amount has not been applied automatically...
Just wondered if this is correct and I have to manually apply payment or if I have a bad install? as there is no PayPal option in the manual method.

ThanksSeveral posts here already covering this topic -- quoted one of these posts for your reference..

Short answer -- Auto payments for orders paid via PayPal is not working and will be addressed in the next release..

DivaVocals:

Status on the upcoming release (highlights):

Super Orders Auto Payment Generation for PayPal Orders:
So after a LOT of trial and error, I was able to fix the PayPal auto payments code.. Still dunno why the code in the current v3.0 fileset worked on my client's store.. (and still does) But no matter got it all working. Felt I needed to explain HOW the PayPal auto payments will be generated so that it is CLEAR how this functionality will work.

A Super Orders payment record will be auto-created for PayPal paid orders if:

• There is no existing Super Orders payment record for the order

AND

• The PAYPAL payment status is "Completed"

IF BOTH conditions are true, then a Super Orders payment record will automatically be created for the order.

NO AUTO PAYMENT will be generated if:

• There is an existing Super Orders payment record for the order

OR

• The PAYPAL payment status (NOT THE ORDER STATUS) is NOT "Completed"

The benefits to this are two-fold:

• Super Orders payment records will generate for older orders now.:clap: (All you have to do is open the target order and the Super Orders payment record will be auto created for you!!)

• Super Orders will not inadvertently generate a Super Orders payment record until the PayPal payment has been completed and cleared by PayPal. (preventing orders in which the payment is NOT "Completed" from being inadvertently marked as a paid order when in fact it is not) When the PayPal payment status is updated (an automatic Zen Cart function), then the Super Orders payment record will automatically be created!

Credit Card Auto Payment Generation Tweak:
I decided to update the class file that auto generates Super Orders payments for credit card paid orders based on Blindside's post here:
http://www.zen-cart.com/forum/showpost.php?p=276219&postcount=207. (just the part of this code which relates to credit payments.. PayPal auto payments are handled differently)

I meant to include this in the v3.0 release, but it slipped my mind..:laugh:

I liked the fact that it no longer hardcodes the credit card codes, and instead relies on the data in the Super Orders payments types table. IF a NEW credit card type is supported by Zen Cart, the only thing Super Orders users need to do is to create a corresponding Super Orders payment type (the Super Orders payment code must match the corresponding credit card as it does now for supported credit cards).. This is loads easier for all I think!!

This will help keep people -- particularly newbies -- "out of the code" just to update the module.. Having to edit module files is often where things go wrong for newbies:smile:..

Just so it's clear -- Auto payment generation for credit cards is slightly different than the new PayPal auto payment generation.

Auto payment generation for credit cards **happens at the time of checkout. While PayPal auto payments are generated when the order is accessed from the Super Orders management screen.

The reason for this difference has everything to do with the general assumption that credit card payments are collected at the time of the sale, while PayPal payments may not be confirmed until 24-28 hours after the order is completed.

===============================

Got a lot ready for the next release (these are just some highlights).. I still have a few buglets left to grapple with.. I'll post here when I have additional updates on the next release.. (Please don't ask for an ETA.. I have to fit this work in between all my other obligations.. I am working as fast as my free time allows folks.. But I am hoping you will see something REALLY soon!:smile:)

Arrh... Good news... Not me then ;))

Thanks Diva (bet I was 1.5 pages off on back posts (

I'm using Reward Points module, but, when using Super Orders to delete a Order, the points are not being deducted from the customers account.

Any feedback on this?

leilanddale:

I'm using Reward Points module, but, when using Super Orders to delete a Order, the points are not being deducted from the customers account.

Any feedback on this?If I had to take a swing at a guess, I'd say that Reward Points makes changes to **orders.php. **Whatever those changes are in the orders.php file to support this add-on must be included in super_orders.php to work with Super Orders.

Not familiar with Rewards Points, and the issue is very specific to how that add-on works (not truly a Super Orders specific issue).. I'm afraid you'll have to get more details on the required changes on the Reward Points support thread.

Any idea when the new version will be posted? I could have swore I read several months ago that a new version was submitted?

I am looking forward to the "No Order Payment Data Available" being fixed!