327 results found

1. Enable Variant Changes Directly in the Shopping Basket and Checkout

   Currently, when customers want to change a variant of a product already added to the shopping basket — for example, choosing a different size or color — they are required to leave the basket or checkout and navigate back to the product detail page. This process interrupts the purchasing flow and increases the likelihood of order cancellations or customer frustration.

   With this enhancement, customers should be able to easily modify product variants directly from the basket or checkout interface.

   Functional Proposal:

   Add a variant selector for each product line item in the shopping basket and checkout.

   When a customer changes a variant, the system automatically updates the line item’s price, stock information, and product image accordingly.

   Currently, when customers want to change a variant of a product already added to the shopping basket — for example, choosing a different size or color — they are required to leave the basket or checkout and navigate back to the product detail page. This process interrupts the purchasing flow and increases the likelihood of order cancellations or customer frustration.

   With this enhancement, customers should be able to easily modify product variants directly from the basket or checkout interface.

   Functional Proposal:

   Add a variant selector for each product line item in the shopping basket and checkout.

   When a customer changes… more

   6 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Checkout  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

2. Optional inclusion of “free shipping” products in cart value for threshold rules

   Use case

   We configure shipping so that standard shipping is free from a minimum order value (e.g. 50 €), using price-based shipping costs on the shipping method.

   Current behaviour

   Products marked “free shipping” are excluded from the value used for all shipping price calculations (via getWithoutDeliveryFree() in DeliveryCalculator::matches()). That means:

   If the cart mixes free-shipping and regular products, only the non–free-shipping lines count toward the threshold.
   Example: total cart 60 €, but only 40 € from non–free-shipping lines → the customer is below the 50 € free-shipping threshold and pays shipping, even though the visible cart total is above 50 €.

   Expected / desired behaviour
   For price-based rules (minimum order value / free shipping from X €), we need the full cart value (or a configurable choice) to determine the tier, not only the sum excluding free-shipping products.
   Products marked “free shipping” should still ship without their own fee when they are the only items, but when combined with other products, they should count toward the threshold so behaviour matches merchant and customer expectations.

   Suggestion

   Please consider one of:
   A configuration option on the shipping method or globally: “include free-shipping products in cart value for price-based shipping rules”, or

   an extension point (e.g. protected method, strategy, or event) so projects can implement this without forking DeliveryCalculator.

   Use case

   We configure shipping so that standard shipping is free from a minimum order value (e.g. 50 €), using price-based shipping costs on the shipping method.

   Current behaviour

   Products marked “free shipping” are excluded from the value used for all shipping price calculations (via getWithoutDeliveryFree() in DeliveryCalculator::matches()). That means:

   If the cart mixes free-shipping and regular products, only the non–free-shipping lines count toward the threshold.
   Example: total cart 60 €, but only 40 € from non–free-shipping lines → the customer is below the 50 € free-shipping threshold and pays shipping, even though the visible cart total is above 50… more

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Checkout  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Gathering Feedback

   
   

   We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

   
   

   Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

3. Payment method change after order receipt with new payment method

   Currently, when changing the payment method of an existing order (/account/order/edit-payment), the rule engine is not re-executed.

   Instead, Shopware continues to use the payment methods that were available at the time the original order was placed.

   This results in the following scenarios not being handled correctly:
   - Payment methods become valid for the customer retroactively (e.g., based on tags, customer groups, or rules) → but do not appear in the selection.
   - Rules change retroactively (e.g., "Always valid" is added) → no update occurs.
   - Changes to customer data, addresses, or order items are not reflected.

   This means that customers cannot select an updated payment method, even if they meet the requirements after placing the order.

   The payment method cannot currently be changed in the admin panel either.

   When changing the payment method for an existing order, the payment methods should be determined dynamically based on current data and rules – not based on historical data.

   The customer should therefore always see all currently valid payment methods.

   Currently, when changing the payment method of an existing order (/account/order/edit-payment), the rule engine is not re-executed.

   Instead, Shopware continues to use the payment methods that were available at the time the original order was placed.

   This results in the following scenarios not being handled correctly:
   - Payment methods become valid for the customer retroactively (e.g., based on tags, customer groups, or rules) → but do not appear in the selection.
   - Rules change retroactively (e.g., "Always valid" is added) → no update occurs.
   - Changes to customer data, addresses, or order items are not reflected.

   This means that customers… more

   5 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

4. Support immutable promotion versions behind stable promotion codes

   Currently, Shopware locks certain promotion discount settings after a promotion has been used in an order. For example, the discount amount can no longer be changed once the promotion was applied at least once.
   From a data integrity perspective, this is understandable: changing the discount definition after it has already been used could affect order recalculation, order editing, tax distribution, or historical consistency.
   However, from a merchant perspective this creates a practical limitation. A commonly used promotion code such as WELCOME cannot easily be reused with a changed discount configuration. The merchant either has to create a new visible code, or the existing promotion becomes effectively frozen.

   Suggested improvement
   Shopware could support immutable promotion versions behind a stable public promotion code.
   The customer-facing code would remain unchanged, for example:

   Internally, Shopware would resolve this code to a concrete promotion version.

   Example:

   Code: WELCOME
   Version 1:

   internal promotion/version ID: abc123
   valid from: 2026-01-01
   valid until: 2026-03-31
   discount: 10%
   used for existing orders / historical order edits only
   Version 2:
   internal promotion/version ID: def456
   valid from: 2026-04-01
   valid until: open
   discount: 15%
   used for new carts and new orders
   Expected behavior

   For new carts and new orders, the entered code WELCOME should resolve to the currently active promotion version.

   For existing orders, order edits, recalculations, or similar historical operations, Shopware should continue to use the originally applied promotion version.

   In other words:

   New checkout:
   WELCOME → latest active promotion version
   Existing order edit:
   use the promotion version that was originally applied to this order

   The old version should not remain generally usable just because it was valid in the past. It should only be used where there is already a concrete historical reference, for example on an existing order that originally used that version.

   Why this would help

   This would preserve historical calculation integrity while allowing merchants to keep stable, recognizable promotion codes.

   It would also avoid forcing merchants to create new customer-facing codes every time they want to adjust a promotion. Common codes such as WELCOME, SUMMER, or BLACKWEEK could stay the same while their internal discount definition is versioned safely.

   Possible implementation approach

   Instead of modifying a promotion discount definition after first usage, Shopware could create a new immutable promotion version.

   The admin UI could offer an action such as:

   Create new version of this promotion

   This new version would inherit the existing configuration, allow changes to the discount settings, and become the active version for future carts.

   Existing orders would continue to reference the previous version.

   Benefits

   Keeps historical order data stable
   Avoids recalculation inconsistencies
   Allows merchants to reuse established promotion codes
   Improves usability in the Administration
   Provides a cleaner alternative to permanently locked discount fields
   Makes promotion changes explicit and traceable
   Additional context

   This is not meant as a request to allow direct editing of already-used discount definitions. The goal is to keep those definitions immutable, but introduce a versioning layer so that the same public promotion code can safely point to a newer internal promotion version for future orders.

   Currently, Shopware locks certain promotion discount settings after a promotion has been used in an order. For example, the discount amount can no longer be changed once the promotion was applied at least once.
   From a data integrity perspective, this is understandable: changing the discount definition after it has already been used could affect order recalculation, order editing, tax distribution, or historical consistency.
   However, from a merchant perspective this creates a practical limitation. A commonly used promotion code such as WELCOME cannot easily be reused with a changed discount configuration. The merchant either has to create a new visible code,… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Marketing & Promotions  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Gathering Feedback

   
   

   We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

   
   

   Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

5. B2B Components: add CSV bulk import of Employees and Addresses

   Some customers may receive the request from business partners to create a lot of employee account with different addresses (see for example support case #SWAG-322222).

   Currently each employee and address would need to be added by hand or via the API. Bulk importing as a CSV would make this a lot easier.

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  B2B  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

6. AI: Productstreams / Crossselling

   Little has happened since the introduction of AI.

   The use of AI to generate customer-specific product streams for cross-selling would be indispensable and a major step forward. For example, based on order history. This is very important for the customer.

   Cross-selling is currently very rigid. AI could be used to analyze the customer's order and then make specific suggestions. This would be a huge step and benefit for customers and a game changer.

   15 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Gathering Feedback

   
   

   We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

   
   

   Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

7. Quick check for plugin and dependency updates compatible with current Shopware version

   Right now, there’s no quick way to see which plugin or dependency updates are actually compatible with the installed Shopware version.

   composer outdated shows all new versions, ignoring compatibility.

   The Admin popup just says “updates available” without details.

   It would be very helpful to have a CLI command and/or an Admin view that lists only installable updates based on the current Shopware version.

   7 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

8. Extended Product Visibility Control - Separate Search Settings

   Enhance visibility control options for products in product listing and search listing.

   Per product visibility setting, the following options are currently available:

   Visible (All)
   Hide in product listings
   Hide in product listings and search

   With the current logic, it is only possible to:

   Hide a product from listings, or
   Hide it from both listings and search.

   However, it is not possible to keep a product visible in listings (e.g., categories, sliders, cross-sellings) while hiding it only from search results.

   Requested Enhancement

   Introduce an additional visibility option:

   Visible in listings but hidden in search

   This would allow merchants to control product discoverability more precisely without removing products from structured browsing contexts. Greater flexibility for B2B and enterprise use cases.

   Enhance visibility control options for products in product listing and search listing.

   Per product visibility setting, the following options are currently available:

   Visible (All)
   Hide in product listings
   Hide in product listings and search

   With the current logic, it is only possible to:

   Hide a product from listings, or
   Hide it from both listings and search.

   However, it is not possible to keep a product visible in listings (e.g., categories, sliders, cross-sellings) while hiding it only from search results.

   Requested Enhancement

   Introduce an additional visibility option:

   Visible in listings but hidden in search

   This would allow merchants to control product… more

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Gathering Feedback

   
   

   We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

   
   

   Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

9. Admin orders: Add option to manually add deactivated products

   A customer of ours suggested this feature;

   It should be possible to have the option to add deactivated products to a manually placed order. Perhaps with a checkbox while we're adding the products or clearly mark the deactivated products in order to avoid mixing them up with active ones, in case product names are rather similar.

   The specific usecase is this:

   That merchant frequently places manual orders in their Admin for customers. Contrary to what one might assume (I did so as well), it is not a once-in-a-lifetime event that while you work on said manual order, another customer in the frontend already buys the stock away, leading to the product no longer being available. The shop owner reported THREE separate occasions where this happened and thus, understandably, now seeks a solution for these cases.

   There are workarounds of course, but they all come with advantages and disadvantages and at least I was not able to think of any which is really failure proof. They all also require multiple steps to get them working (like manually adjusting stock amounts before the manual order and then after again) other than automating everything via API, which sort of defeats the point of Admin orders.

   Assuming we tackle this problem, it should most definitely be a setting or option because if we show any and all products, even deactivated ones, as possible selection during the creation of manual orders, we'll probably introduce new problems for shops which only have products available once and never again afterwards. In these cases, the products likely end up disabled once they're sold out and they'd NOT want those to clutter the dropdown list when placing an Admin order.

   A customer of ours suggested this feature;

   It should be possible to have the option to add deactivated products to a manually placed order. Perhaps with a checkbox while we're adding the products or clearly mark the deactivated products in order to avoid mixing them up with active ones, in case product names are rather similar.

   The specific usecase is this:

   That merchant frequently places manual orders in their Admin for customers. Contrary to what one might assume (I did so as well), it is not a once-in-a-lifetime event that while you work on said manual order, another customer in… more

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Inventory  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

   Gathering Feedback

   
   

   We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

   
   

   Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

10. Newsletter - Fallback value for the name

    The name fields on the newsletter form are not required fields. If these are left blank during registration, the customer’s email address is effectively used as their name.

    This can cause errors on some email servers.

    It would be helpful to include a “placeholder” here by default to prevent such errors on email ser

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

11. PayPal: add option to disable Smart Payment Button for other payment methods

    Currently, users can only disable the Smart Payment Buttons for the standard PayPal payment method, which replaces the (by default) yellow PayPal button with the standard button to conclude the checkout.

    However that setting does not have effect on the other payment methods provided by PayPal, such as Apple Pay, Google Pay or even the Pay Later option by PayPal. Those still replace the default pay button with their own graphic.

    It would be useful to be able to disable them as well to have more control over the shop design.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  PayPal & Braintree  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

12. Generate ZUGFeRD e-invoices via Bulk Edit

    It is currently not possible to create an e-invoice using bulk edit.
    
    You can only send the e-invoice, but not generate it directly using bulk edit.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

13. Preselect correct Sales Channel mail template in "Send Document" modal

    Summary

    When manually sending a document (e.g. an invoice) from the order detail page in the Shopware 6 Administration, the "Send Document" modal always preselects the first globally available mail template of the matching type — regardless of which Sales Channel the order belongs to.

    If multiple mail templates of the same type (e.g. "Invoice / Rechnung") exist for different Sales Channels, the administrator must manually select the correct template every time. This is error-prone and leads to customers potentially receiving emails styled for the wrong Sales Channel (wrong branding, wrong logo, wrong sender identity).
    Current Behavior

    The sw-order-send-document-modal component preselects the first available mail template of the matching type, without considering the Sales Channel of the current order.

    Example:

    Order belongs to Sales Channel pizza1.de
    Available templates of type "Invoice": MotorGarten - Rechnung ✓ (preselected), pizza1.de - Rechnung, Rechnung ebay Template
    The modal preselects MotorGarten - Rechnung instead of pizza1.de - Rechnung
    

    Expected Behavior

    The modal should automatically preselect the mail template that is assigned to (or best matches) the Sales Channel of the order being processed.

    Fallback logic suggestion:

    Prefer a template explicitly assigned to the order's Sales Channel
    Fall back to the global/default template if no Sales Channel-specific template exists
    

    Why This Matters

    Shops operating multiple Sales Channels (e.g. different storefronts or marketplaces) typically maintain separate mail templates per channel for branding and legal reasons. The current behavior forces staff to manually pick the right template on every document send — and a wrong selection means the customer receives an email with the wrong branding.
    Suggested Implementation

    In sw-order-send-document-modal/index.js, when loading and defaulting the mail template selection, filter or sort templates by the salesChannelId of the current order and preselect the best match.

    Relevant file:
    src/Administration/Resources/app/administration/src/module/sw-order/component/sw-order-send-document-modal/index.js
    Environment

    Shopware Version: 6.x (reproducible across versions)
    Multiple Sales Channels with separate mail templates of the same type
    

    Summary

    When manually sending a document (e.g. an invoice) from the order detail page in the Shopware 6 Administration, the "Send Document" modal always preselects the first globally available mail template of the matching type — regardless of which Sales Channel the order belongs to.

    If multiple mail templates of the same type (e.g. "Invoice / Rechnung") exist for different Sales Channels, the administrator must manually select the correct template every time. This is error-prone and leads to customers potentially receiving emails styled for the wrong Sales Channel (wrong branding, wrong logo, wrong sender identity).
    Current Behavior

    The sw-order-send-document-modal component… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

14. Make Advanced Search 2.0 more configurable

    EN
    
    Advanced Search 2.0 / OpenSearch already offers good results. However, not all users can make optimum use of it because, for example, it is not possible to set how much deviation a result may have compared to the top-ranked result. In the technical trade, product names can be very close to each other, so an exact match is often required here. Although the best results are presented first, similar results are also presented. For example, S25 and S25+ would be very close to each other and therefore offer the potential for a bad purchase with subsequent returns.

    For customers with such search requirements, it would be helpful if they could set how high the deviation in the ranking may be or how far the distance may be in the fuzzy search.

    DE
    
    Advanced Search 2.0 / OpenSearch bietet bereits gute Ergebnisse. Jedoch ist nicht für alle Nutzer eine optimale Nutzung möglich, weil zum Beispiel nicht eingestellt werden kann, wie viel Abweichung ein Ergebnis im Vergleich zum top gerankten Ergebnis haben darf. Im technischen Handel können Produktbezeichnungen sehr nah beieinander liegen, daher wird hier oft eine genaue Übereinstimmung benötigt. Zwar werden die besten Ergebnisse als erstes präsentiert, aber ähnliche Ergebnisse ebenfalls. Somit würden als Beispiel S25 und S25+ sehr nah beieinander liegen und bieten somit Potenzial zum Fehlkauf mit anschließenden Retouren. Für Kunden mit solchen Anforderungen an die Suche wäre es hilfreich, wenn sie einstellen könnten, wie hoch die Abweichung im Ranking sein darf oder wie weit die Distanz bei der unscharfen Suche sein darf.

    EN
    
    Advanced Search 2.0 / OpenSearch already offers good results. However, not all users can make optimum use of it because, for example, it is not possible to set how much deviation a result may have compared to the top-ranked result. In the technical trade, product names can be very close to each other, so an exact match is often required here. Although the best results are presented first, similar results are also presented. For example, S25 and S25+ would be very close to each other and therefore offer the potential for a bad purchase with subsequent returns.

    For customers… more

    27 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    3 comments  ·  Search  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

15. Make font size configurable in document footers

    Make font size configurable in document footers via option in document settings.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

16. Feature Request: Country-specific delivery times per shipping method

    Currently, Shopware only allows one global delivery time per shipping method.

    To accommodate different delivery times for each destination country, separate shipping methods must be created.

    In more complex shipping setups, this leads to a very high number of shipping methods.

    In this case:

    • Approximately 130 standard shipping methods
    • Approximately 100 express shipping methods
    • Over 200 active shipping methods in total

    • This results in considerable administrative overhead regarding:

    • Maintenance and updates

    • Rule assignment

    • Quality assurance

    • Error potential

    • Overview in the admin panel

    Especially with service providers like DHL and DHL Express, detailed, country-specific transit time tables exist that need to be updated regularly. Grouping by region (e.g., EU, USA, Asia) is not practical here, as transit times change dynamically and the grouping logic would have to be constantly adjusted.

    Problem Statement
    The current system architecture forces merchants to create multiple shipping methods simply to represent different delivery times for each country.

    There is no way to define delivery times, similar to shipping costs, differentiated by destination country.

    Requested Feature
    Extension of shipping methods to include country-specific delivery time logic, e.g.:

    • A matrix within a shipping method:

    Country → Delivery Time

    or alternatively

    • Rule-based assignment of delivery times via the Rule Builder

    The goal is to represent different delivery times for each country without having to create separate shipping methods.

    Expected Added Value
    - Significant reduction in the number of shipping methods
    - Simplified maintenance when changing delivery times
    - Improved clarity in the backend
    - Reduced error susceptibility
    - Better scalability for international shipping

    Currently, Shopware only allows one global delivery time per shipping method.

    To accommodate different delivery times for each destination country, separate shipping methods must be created.

    In more complex shipping setups, this leads to a very high number of shipping methods.

    In this case:

    • Approximately 130 standard shipping methods
    • Approximately 100 express shipping methods
    • Over 200 active shipping methods in total

    • This results in considerable administrative overhead regarding:

    • Maintenance and updates

    • Rule assignment

    • Quality assurance

    • Error potential

    • Overview in the admin panel

    Especially with service providers like DHL and DHL Express, detailed, country-specific transit time tables exist that need to… more

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

17. Validation of individual voucher codes

    At present, there is no check to verify whether individual promo codes generated according to a custom pattern result in a valid code.

    Although the result is displayed in a preview, if you enter a pattern containing a hyphen (‘-’), no valid code can be generated, as hyphens appear to be reserved for the PRE and SUFFIX fields.

    Example: %s%s%d%d-%d%d-%d%d%d%s

    This would produce the following result: UP21-%d%d-%d%d%d%s

    The pattern following the hyphen is used as the code. Although this should be noticeable during creation due to the preview, validation would nevertheless be more sensible and is requested.

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Marketing & Promotions  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

18. Subscriptions available in Evolve

    Include Shopware Subscriptions already for lower tier plan(s) - at least Evolve.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

19. Improvement Proposal: Enhance Mail & Flow Logic for B2B Employee Context (Shopware Commercial)

    Current Situation / Problem:
    In B2B (Commercial) setups, there is a common requirement to send transactional emails (e.g. order confirmations) not only to the customer account, but contextually to the employee who actually placed the order.

    At the moment, the following limitations exist:

    • employee data is only available in mail templates if an employee is present in the order context.
    • The Flow Builder does not provide conditions based on employee data (e.g. “employee exists”, “employee email”).
    • Dynamic recipients (TO/CC/BCC) based on variables (e.g. {{ employee.email }}) are not supported.
    • CC/BCC fields can only be configured statically.
    • Workarounds (e.g. separate flows per customer) are not scalable.

    Proposed Improvements:
    1. Extend Flow Builder Conditions
    Add new conditions such as:
    “Order has employee”
    “Employee attributes” (e.g. email, name, ID)
    Provide access to employee fields similar to existing customer conditions

    1. Support Dynamic Email Recipients
       Enable variable-based configuration for:
       TO
       CC
       BCC
       Example:
       TO: {{ employee.email }}
       CC: {{ customer.email }}

    2. Recipient Fallback Logic
       Allow conditional logic such as:
       If employee exists → send to employee
       Else → send to customer

    3. Consistent Template Variable Availability
       Ensure employee is always available in templates (e.g. null if not set)
       Avoid inconsistent behavior in the template editor

    4. Optional (Nice-to-have)
       Introduce a recipient strategy setting (e.g. “Primary recipient = Employee / Customer / Both”)
       UI support for typical B2B communication scenarios

    Business Impact:
    - Covers a core B2B commerce requirement (employees ordering on behalf of a company)
    - Reduces manual effort in sales/customer service teams
    - Prevents misrouted emails
    - Significantly improves automation capabilities in Flow Builder
    - Avoids the need for custom plugin development for standard use cases

    Current Workaround:
    - Display employee information in the email template
    - Manual routing of emails after sending
    - Alternatively: custom plugin development

    Current Situation / Problem:
    In B2B (Commercial) setups, there is a common requirement to send transactional emails (e.g. order confirmations) not only to the customer account, but contextually to the employee who actually placed the order.

    At the moment, the following limitations exist:

    • employee data is only available in mail templates if an employee is present in the order context.
    • The Flow Builder does not provide conditions based on employee data (e.g. “employee exists”, “employee email”).
    • Dynamic recipients (TO/CC/BCC) based on variables (e.g. {{ employee.email }}) are not supported.
    • CC/BCC fields can only be configured statically.
    • Workarounds (e.g. separate flows… more
    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  B2B  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.

20. Different texts for error messages regarding promotion codes provide clearer instructions to the buyer. Currently, only one text is possible

    We want different texts for error messages with a promotion code showing our customers why they can not use this code - for example 150 Euros + ... then 5% discount - 100 euro in the shipping card - text " buy for 50 more euros to get the 5%" ... something like that.

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Marketing & Promotions  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Gathering Feedback  ·  AdminMoritz Naczenski (Admin, shopware AG) responded

    Gathering Feedback

    
    

    We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.

    
    

    Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.