There is a choice of “SALE” or “AUTHORISATION” in the Magento Paypal settings. We ideally wish to stay with “SALE” as that covers 99.9% of anything we do (we always have goods in stock). The “Authorisation” option worries me with the 3 day limit, plus it adds an extra “capture” step that could go wrong later.
So…….
“SALE" works fine but in Magento it automatically creates an INVOICE in the system. Other payment systems we use such as Sofort AG make this setting optional and for a very good reason.
Magento is set so that once you have produced an INVOICE and a SHIPMENT it automatically marks any order as COMPLETE.
We create UPS labels, with a tracking number which of course is added to the SHIPMENT details. So my problem is:
As soon as we try to create a UPS label (without even printing) Magento sets the Paypal orders to COMPLETE. This is because it has seen an INVOICE
and a SHIPMENT for an order.
We need to disable a Paypal “SALE” from producing an invoice. We can easily produce and send the invoice once the shipment has been produced
and sent, and then set it finally to Complete.
Is there a setting I have missed to disable this forced invoice? I can see a company used to make a module for this purpose but it is out of date for Magento 1.9. (I did try it just in case!!)
http://www.magentocommerce.com/magento-connect/disable-automatic-generation-of-invoice.html
No, there is no setting to fix this: paypal create an object called transaction and this kind of object should be created with the object invoice. It's not a good practice to don't create invoice and I suggest you to stay away to any component that don't create a transaction.
Probably it works well, but in the flow of order creation when you will evalutate to play with order status. Anyway there is not a setting to do this.
I am observing the strange situation of orders with subtotal and grand total of 0, but with products in it. The products row have prices and no promo rules or discounts are being used. This happens sporadically and not only with one site. The version of Magento is 1.7.0.2. There are also no additional extensions installed. system.log and exception.log do not contain traces of errors that may have something to do with this problem.
At first i thought it may be because of server overload. I think this may have something to do with it but the last "0"-subtotal order happened when the server was not loaded at all.
Any ideas? Thanks!
I 've had the same problem with you guys and it was really annoying because I could not reproduce it and could not find a proper solution.
I started to believe that it was just another Magento bug caused by some bad timing in database operations.
Anthony's post really helped me and guide me to find a practical fix.
So here it is.
Indeed the error is caused by the trigger recollect flag that is set in markQuotesRecollect (for instance when a product is saved) and causes
all active quotes to recollect their totals.
I had to spent a lot of hours in debugging IWD OnepageCheckout code to understand that in Geo.php saveBilling function creates a new shipping address by cloning
the billing address (in case shipping is same as billing) and passes (almost) all data from billing address to the shipping address which later on is saved (through the parent quote save).
This way cached_items_* data are set and when Geo.php saves payment even if you intentionally set quote to recollect totals (i.e by setting collected flag to false) shipping totals
are not calculated correctly.
Eventually I had to add this lines of code in saveBilling method after line that writes:
$ship->addData($bill->getData());)
$ship->setSameAsBilling(1)->setShippingMethod($ship_method)->setCollectShippingRates(true);
$ship->unsetData('cached_items_nominal');
$ship->unsetData('cached_items_nonnominal');
$ship->unsetData('cached_items_all');
So far (after 10 days and around 1000 orders) had no random zero total orders.
Hope this helps you all
Kind Regards
Lefteris
I have had the same problem. And I have done some researches here.
I used IWD onepagecheckout module. And the issue was inside this module.
Lets consider situation. You are doing smth in adminpanel or cron is doing some tasks this products or you could apply some catalog rules. In any kind of these actions will be called event catalog_product_status_update or catalog_product_save_after.
So every time you're changing smth in products all current quotes will be updates by events.
ok, here you'll ask me - what does it mean?
It means that each quote changes the field trigger_recollect in sales_flat_quote table.
You can find it here
app/code/core/Mage/Sales/Model/Resource/Quote.php::[markQuotesRecollectOnCatalogRules and markQuotesRecollect methods] to get more in details.
The trigger_recollect field is a trigger/signal to recollect whole quote total sums. You can find this step here
app/code/Mage/Sales/Model/Quote.php::_afterLoad.
protected function _afterLoad()
{
// collect totals and save me, if required
if (1 == $this->getData('trigger_recollect')) {
$this->collectTotals()->save();
}
return parent::_afterLoad();
}
And accurate at this moment all current quote total sums became 0. The follow step is to get address collection and for some reason we have not product items it the address object now. Magento cannot recollect correct here. But it occur only when you or system are doing smth with a products and at the same time customer is pressing the button "send order". Why - I do not know yet. By the issue was occurred and catched.
Just check in the Configuration->Advanced->advanced->Disabled Module Outputs
Mage_Tax option is enabled or not.
Zero Subtotal Checkout
Using this
System > Configuration > Payment Methods > Zero Subtotal Checkout
More info to go hear
I am trying to make a functionnality so that a customer will be able to split his order into 2, in case some articles are temporarily unavailable and if they wish that we send them part of their order first. So the idea is to create 2 new orders and cancelling the old one.
Do you have any idee about how to do this programmatically please ?
What you're describing doesn't sound necessary... You're talking about sending part of the order first... Notice in the Magento Admin once an order is place you can create an invoice, take note that you do not have to invoice everything at one time, the same is true when you create a shipment. You'll need to make sure you're merchant / payment gateway supports multiple partial captures against a single authorization.
However, if you really want to split the orders in two, it is a rather complicated process. We've done it, and its very tricky... you need to modify the opcheckout.js file, you'll need to modify the template since you will have to create seperate shipping methods for each order. You'll need to modify the OnePage controller & Model files very significantly. There are tricky areas in terms of re-executing the totals and making sure data on the order and subsequent quote and address models is precisely what is required by Magento. Maintaining the other checkout functionality requires diligence, such as saving the customer's address when checking out. If you're really going down the path of coding something that splits an order into two orders during the checkout process, feel free to send me a message and we can talk more in-depth and I'll send you some code.
I've built an observer that listens to the registration_success_observer event that is emitted upon new user registration (from the accounts page). The observer handles various functionality, most importantly upgrading the user to a membership group if a membership id is passed in.
The problem is that I need to have the same functionality for users who are checking out AND signing up as a new customer. I somehow need a way to figure out if they are signing up as a new customer (via event?) from the one page checkout screen, in addition to re-calculating the totals -- some items in our store have special pricing for groups.
Does anyone know the best way to go about this? Specific events that I should listen for, or any other code snippets for handling functionality within the one page checkout screen would be helpful.
** Update **
It just occurred to me that a customer isn't actually created until after the order is complete. Any workarounds for this?
You could create your own 'custom event' using the logic below to check which method they use to check out on success.phtml or incorporate it in sales_order_place_before
$quoteId = Mage::getModel('sales/order')->loadByIncrementId($this->getOrderId())->getQuoteId();
$quote = Mage::getModel('sales/quote')->load($quoteId);
$method = $quote->getCheckoutMethod(true);
if ($method == 'register'){
//the customer registered...do your stuff
}
Source : http://www.magentocommerce.com/boards/viewthread/273690/#t375160
But what your trying to do may not be possible without rewriting the onepage checkout, because a customer is created before order is store in the db but after processing the credit card so the amount the credit card is bill for wouldn't equal the order total.
You could try to add a third option to the first step in the checkout process ('register as a member') that allow them to create an account before start checking out.
I have a requirement to be able to accept different forms of payment within the same order - ie not just the usual credit card or paypal for the whole thing, but perhaps paypal for one item, cheque for another. I know this sounds quite crazy, but there is a good business reason for the requirement so I can't just push back.
The best way I can think of implementing it at the moment is to have kind of a hub page, where you can "launch off" into multiple flows for each of the payments by opening new windows. I can't figure out a way of doing this in a linear flow as for example you can't guarantee that a user will come back from paypal, so you'd then lose the user completely.
Is there a neater way of doing this that anyone can think of, or can anyone point me to an example of a site that does somethign similar for inspiration?
Even when opening several windows at once, there is no guarantee that the user will complete all payment methods. So you are most probably going to lose a few users or payments. Be sure to send automated e-mail follow-ups for missing payments to minimize this problem. The e-mails could contain links to your payment providers for easy accesss to their outstanding payment operations.
This is a difficult problem, but how many payment processors do you have to go offsite for? Should only be paypal.
In any case, I'd give the user all their payment options on one page, and let them fill in the amount for each processor or payment type. Then the next page would list those they chose, the amount for each, and a link to "Complete this payment".
The link would open in a new window.
You'll have to have a good back end and javascript, as well as user warnings so that the payment page gets updated as each payment is processed. Consider using popup dialogs to show that a payment has completed, or that the order has sat idle for more than 10-30 minutes without complete payment.
Also, consider sending emails and letting the user complete the payments through links in the emails. Send a new email each time a payment is completed, and a final email if all payments are complete and the order is moving forward.
Send an email one hour, and one day later for uncompleted orders with remaining payments required, that also give them the option of choosing different payment options for the remainder.
Email isn't best (lose more orders that way due to changing minds) but it's good for the type of transactions you're thinking about.
Personally, I'd do it like this:
Let the user fill their basket in the ususal way
Allow them to add payment types and amounts to a list (2nd basket almost)
When the payments balance against the basket, start processing the payments
For external sites, try a frame which has a progress indicator at the top.
In an ideal world it wouldn't be linear. But a lot of users might lose a spawned window, or get confused by the parallelism.
Better to stick to established IxD principals and rely on good feedback instead. Give the user control from the outset and keep it transparent.
Lastly, start the payment process with the most immediate (e.g. paypal) to reduce users giving up. (COD should come last!)
Hope this helps,
Tom
If possible, just separate your order into separate smaller orders based off of the payment selections of the user.
And don't do it linearly. If anything you could open up each payment processor in a separate window so that you maintain presence.
I would take an approach where the whole order is broken down into sub-orders for each of the necessary payment methods. You can load the PayPal portion, the check portion, etc. and process them separately. It's important for the user to know how much is being charged to each of their payment methods, so it makes sense in this case to present the whole order as broken down by payment method (versus displaying as a unified order).
Implementation would be easiest if it's always a certain subset of items that is forced to any payment method. If this differs by user, or if it's when the order reaches a certain amount, the situation could become much more complicated. Can you be more specific about your approach?
Processing Multiple Order Payments
Give the user the option to make a payment for a pending order using any of your payment types.
Let the user specify an (Amount <= [Order Total] - [Payments Received]), if that is part of your requirement.
If the order is still pending after you process the payment (see how below), take them back to step 1 to rinse and repeat.
How to store and process each payment made:
Use a Payments table to store all order payments, the PaymentMethod used and its Amount with its CurrencyCode.
When a payment is received for an order, store the payment and sum all received amounts converted into your base currency as [Payments Received].
If [Payments Received] >= [Order Total], mark the order as Paid. Or, if dealing with double-converted foreign exchange rates, check if it is correct to within a small-enough margin, eg 0.5%.
Optionally, convert any overpayment into prepaid credit for the client.