Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Virtual products lead to incomplete invoices when using an Open Invoice payment method (e.g. Klarna) #2813

Open
pmzandbergen opened this issue Nov 25, 2024 · 2 comments
Assignees

Comments

@pmzandbergen
Copy link
Contributor

Describe the bug

private function itemsToBeInvoiced(Shipment $shipment): array
{
$shipmentItems = $shipment->getItems();
$invoiceItems = [];
foreach ($shipmentItems as $shipmentItem) {
$invoiceItems[$shipmentItem->getOrderItemId()] = $shipmentItem->getQty();
}
return $invoiceItems;
}

This code expects all items to ship, which is not the case for virtual products. This causes those items not to be invoiced leading to a partial (or failed) capture.

To Reproduce
Steps to reproduce the behavior:

  1. Place an order with both virtual and regular (simple) products
  2. Pay using an Open Invoice method (Klarna for example)
  3. Create a shipment
  4. Inspect the invoice and capture flow

Expected behavior
Items which do not require a shipment (e.g. virtual products) should be invoiced and captured.

Magento version
2.4.7-p3

Plugin version
9.6.0, but can be reproduced on the latest version (9.11.0) as well.

Screenshots
N/A

Desktop (please complete the following information):
N/A

Smartphone (please complete the following information):
N/A

Additional context
N/A

@candemiralp
Copy link
Member

Hello @pmzandbergen,

Thank you for creating this issue. This is indeed an interesting case and we've assumed it should be outside of the Capture on Shipment flow, so far. We are ready to discuss and improve the flow.

As you've mentioned, the code block above only captures the items require shipment as the name suggests. From my understanding, we shouldn't merge two distinct flows. We don't have enough evidence to capture the virtual products alongside of the shipment. It might not cover the use case of everyone. Capture on Shipment is only meant to be used with physical items.

However, in reality it might be cumbersome to go back and capture these virtual item/s again. Do you have any idea about a non-destructive flow? In the meanwhile, I will discuss this case with our product manager and get back to you.

Best Regards,
Can

@candemiralp candemiralp self-assigned this Nov 26, 2024
@pmzandbergen
Copy link
Contributor Author

pmzandbergen commented Nov 26, 2024

Hi @candemiralp ,

I agree mangling virtual items in the shipment flow might not be the best solution. If the order exists of only virtual products, there won't even be a shipment to call the observer.

If the invoice is created externally or manually for those items the flow should succeed, since the Adyen\Payment\Observer\InvoiceObserver already links those invoices with the Adyen payment. The transaction ID (PSP reference) doesn't seem to be populated in this case, that might need a little change in order to support online refunds. When the Invoice is created by the shipment observer the transaction ID is populated (with the PSP reference).

Regarding invoicing the virtual items, it might be an option to add a configuration flag to automatically create an invoice for those items. It should be disabled by default, since it heavily depends on the Store if this is a desired option (and it matches the current behavior).

Most virtual items are things like licenses, online gift cards, etc. which in general don't run out of stock and are processed instantly. Some modules containing logic for those virtual products might create an Invoice simultaneously, others do not. Providing an option in the Adyen module to create those invoices automatically would be nice, since you are already providing this option for regular (shipment) items.

Best regards,

Pieter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants