Purchase Order Basic

linuxguy2:

Hadn't given it much thought as I needed to get this working yesterday.and that's fine, but it appears you are suggesting this change as a feature request.. Respectfully I disagree that it should REPLACE the existing functionality.. I think this is better served as an option within the module..

linuxguy2:

Thought I'd pursue it further today. I posted that info in the Purchase Order Basic forum.
Apparently it was put there for a reason but I don't really see why you'd want any extraneous verbiage mixed in with a PO number......
And that's how YOU (or your client want to operate..) Other shopowners may choose to do things differently.. and they SHOULD be able to do that..:smile:

I do believed you are looking at things a bit myopically.. The logic currently in place makes the text + the number THE P.O. number.. Not merely "extraneous verbiage mixed in with a PO number". The logic to append the label with the number as a part of the P.O. was put in there because someone else wanted something different..

So I say.. Shouldn't the module be flexible and support BOTH options?? Shopowners should be able to CHOOSE how they wish to operate their store and manage their PO process.. Why does it HAVE to be ONE or THE OTHER???

DivaVocals:

and that's fine, but it appears you are suggesting this change as a feature request.. Respectfully I disagree that it should REPLACE the existing functionality.. I think this is better served as an option within the module..

And that's how YOU (or your client want to operate..) Other shopowners may choose to do things differently.. and they SHOULD be able to do that..:smile:

I do believed you are looking at things a bit myopically.. The logic currently in place makes the text + the number THE P.O. number.. Not merely "extraneous verbiage mixed in with a PO number". The logic to append the label with the number as a part of the P.O. was put in there because someone else wanted something different..

So I say.. Shouldn't the module be flexible and support BOTH options?? Shopowners should be able to CHOOSE how they wish to operate their store and manage their PO process.. Why does it HAVE to be ONE or THE OTHER???

Hey, I'm all for flexibility and I don't disagree with you, so the use of extraneous may have been a poor choice of verbiage (no pun intended)
It looks to me like hard coding the Label in with the PO Number was a quick way to get the PO Number into the "Order".
Obviously it was designed that way so someone else was also looking at the at solution a bit myopically.... :smile:
If the verbiage is a Label then one would need to add code in other places including the email template etc. to pull that data in. (More Code)
I for one am cognizant someone took the time to come up with a simple straight forward solution.

linuxguy2:

Hey, I'm all for flexibility and I don't disagree with you, so the use of extraneous may have been a poor choice of verbiage (no pun intended)
It looks to me like hard coding the Label in with the PO Number was a quick way to get the PO Number into the "Order".
Obviously it was designed that way so someone else was also looking at the at solution a bit myopically.... :smile:I agree.. the current solution is a bit myopic as well..:laugh:
linuxguy2:

If the verbiage is a Label then one would need to add code in other places including the email template etc. to pull that data in. (More Code)
I for one am cognizant someone took the time to come up with a simple straight forward solution.Understood.. But you do make a valid point that it could be improved.. Not a slam, just how software evolution works.. :smile:

abprice:

It appear that the Purchase Order module only works for physical items, but I need it to work with virtual (downloadable) items. Anyone know how I can make it work?

for anyone wanting this open up:

includes/languages/english/modules/payment

and comment out these lines:

// disable the module if the order only contains virtual products
#      if ($this->enabled == true) {
#        if ($order->content_type != 'physical') {
#          $this->enabled = false;
#        }
#      }

Seems to work fine for me :) But as always check check check/test test test
Thanks
Sarah

SarahL:

for anyone wanting this open up:

includes/languages/english/modules/payment

and comment out these lines:

Seems to work fine for me :) But as always check check check/test test test
Thanks
Sarah

Suggest using double slashes instead as follows```
// disable the module if the order only contains virtual products
// if ($this->enabled == true) {
// if ($order->content_type != 'physical') {
// $this->enabled = false;
// }
// }

We bill all our customers via invoice so no payment modules are mandatory
This PO field is for reference and not all customers will use it.
How do I make this optional on the "Confirm Order Page"?

Thanks, Lucien

linuxguy2:

We bill all our customers via invoice so no payment modules are mandatory
This PO field is for reference and not all customers will use it.
How do I make this optional on the "Confirm Order Page"?

Thanks, Lucien

Hacked the error code in purchaseorders.php around line 83 was "1" and changed to "0" which doesn't error out when the PO Number field is blank.

  '    error = 0;' . "\n" .

It''s not pretty but in my case it works.
Granted one can enter specific customers who can use a PO Number but I never know who will or won't use a PO Number and that's just more book keeping on my part.
Adding an option in the ADMIN section to make the PO number optional would be the appropriate way to go.
The box would be presented every time.
That's a little more coding than I'm capable of.