1464 results found

1. Admin content language selection

   When you currently access an overview in our Admin (e.g. Product overview), the content will always be shown in the system default language, no matter what your admin user setting is. I have attached a screenshot, where you can see, that the menus overall are all in english but the content is showing the german language instead, since it's the default system language.

   This really annoying since it forces me to switch in every menu the content language back to english.

   My suggestion would be to take the language settings of the admin user into account and always show the content also in that language.

   When you currently access an overview in our Admin (e.g. Product overview), the content will always be shown in the system default language, no matter what your admin user setting is. I have attached a screenshot, where you can see, that the menus overall are all in english but the content is showing the german language instead, since it's the default system language.

   This really annoying since it forces me to switch in every menu the content language back to english.

   My suggestion would be to take the language settings of the admin user into account and always show the… more

   •  

   1 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  ·  User Experience  ·  Edit…  ·  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

2. API extension: Make trial status for plugin rentals queryable

   For extensions with usage-based features (e.g., character quotas, API limits, etc.), it would be very helpful to be able to query the current trial status of a plugin rental via API.

   Specifically, the following scenario applies:
   For plugins that unlock the full range of functions during the trial month (e.g., a translation plugin that can translate almost the entire shop), we are increasingly observing that users take advantage of the free month to translate the entire shop once and then cancel. Without a technical way to recognize the trial month, it is difficult to limit this fairly.

   A simple flag would be desirable, e.g., isTrialActive, which can be queried via API. This would allow us to activate a transparent limitation during the trial period and automatically unlock full functionality after it expires.

   Example application:
   During the trial month:
   - quota of, for example, 100,000 characters.
   - All functions can be tested realistically.
   - However, the free trial month is not used as a full “free full version.”

   After the end of the trial: Automatic release of the full quota/scope with active rental
   Such a trial flag would make it possible to design fair trial periods – both for merchants (realistic testing) and for developers (protection against abuse) – without complicated workarounds or external billing logic.

   For extensions with usage-based features (e.g., character quotas, API limits, etc.), it would be very helpful to be able to query the current trial status of a plugin rental via API.

   Specifically, the following scenario applies:
   For plugins that unlock the full range of functions during the trial month (e.g., a translation plugin that can translate almost the entire shop), we are increasingly observing that users take advantage of the free month to translate the entire shop once and then cancel. Without a technical way to recognize the trial month, it is difficult to limit this fairly.

   A simple flag… more

   1 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  ·  In-App Purchases  ·  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

3. Enhanced in-app purchase API for usage-based models

   We want to develop extensions that are billed entirely via IAP (comment from Shopware: IAP stands for In App Purchases) – without our own subscription logic or external billing. Typical use cases are usage-based features such as quotas (e.g., search volume per month), limits, or activations with periodic renewal.

   Currently, Shopware.InAppPurchase.isActive(‘MyExtensionName’, ‘my-iap-identifier’) only returns a Boolean (purchased: true/false).
   However, for usage-based models, we lack the specific billing period, e.g., to reliably reset quotas when transitioning to the new period.

   Our request/feature request:
   In addition to isActive(), minimal contract information would be helpful, e.g.:
   - Purchase or start date of the current billing period
   - Billing interval (e.g., monthly, annually)
   - Flag indicating whether it is a wildcard/stage environment

   This would allow usage-based features (such as search volume, API quotas, free requests, etc.) to be implemented correctly, transparently, and fairly— without having to implement a parallel subscription or billing solution alongside Shopware IAPs.

   We want to develop extensions that are billed entirely via IAP (comment from Shopware: IAP stands for In App Purchases) – without our own subscription logic or external billing. Typical use cases are usage-based features such as quotas (e.g., search volume per month), limits, or activations with periodic renewal.

   Currently, Shopware.InAppPurchase.isActive(‘MyExtensionName’, ‘my-iap-identifier’) only returns a Boolean (purchased: true/false).
   However, for usage-based models, we lack the specific billing period, e.g., to reliably reset quotas when transitioning to the new period.

   Our request/feature request:
   In addition to isActive(), minimal contract information would be helpful, e.g.:
   - Purchase or start date of the… more

   1 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  ·  In-App Purchases  ·  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

4. Use Flow Builder for automatic refunds

   If an order's status is changed to 'cashback', the Flow Builder should automatically trigger a PayPal refund for that order. This reduces the need for manual work and eases the burden on customer support.

   1 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

5. Add separate configuration options to distinguish between “allow payment method change after checkout” and “allow retry of an aborted paymen

   To better support payment workflows, especially with PayPal, it would be highly beneficial to separate two currently combined behaviors:

   At the moment, the option “Allow payment method change after checkout” also controls whether customers can retry a previously aborted payment (e.g., PayPal popup was closed by mistake).
   However, enabling this option on PayPal unintentionally allows customers to change from any other payment method (e.g., Prepayment/Bank Transfer) to PayPal after the order is placed. This causes serious issues in ERP/WMS integrations where such changes are not allowed.

   Proposed improvement:
   Introduce two independent configuration options per payment method:

   “Allow switching to this payment method after checkout”

   “Allow retrying an aborted payment for this payment method”

   Benefits:

   Customers can still complete PayPal payments if they accidentally aborted the payment window.

   Merchants can prevent unwanted payment method changes (e.g., Prepayment → PayPal) that break ERP workflows.

   Provides clearer, more predictable, and more granular control over payment behavior.

   This enhancement would significantly improve flexibility and avoid unintended side effects in multi-payment setups.

   To better support payment workflows, especially with PayPal, it would be highly beneficial to separate two currently combined behaviors:

   At the moment, the option “Allow payment method change after checkout” also controls whether customers can retry a previously aborted payment (e.g., PayPal popup was closed by mistake).
   However, enabling this option on PayPal unintentionally allows customers to change from any other payment method (e.g., Prepayment/Bank Transfer) to PayPal after the order is placed. This causes serious issues in ERP/WMS integrations where such changes are not allowed.

   Proposed improvement:
   Introduce two independent configuration options per payment method:

   “Allow switching to this… more

   1 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  ·  Edit…  ·  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

6. Add user friendliness to new language handling

   Since Shopware 6.7.3.0 the language pack displays a warning, that it's recommended not to use it and that it will not work with 6.8.x anymore. Unfortunately the deinstallation of the language pack removes all translations included there (test with 6.7.4.0, with selection "Remove all data it even throws an exception).
   The dev docs recommend this way https://developer.shopware.com/docs/resources/references/upgrades/core/translation/language-pack-migration.html. But not every customer is feeling comfortable being forced to use the command line. It is intended to activate / deactivate a language via the language itself. So why don't you add an install / uninstall routine in settings > language to process bin/console translation:install --locales it-IT linked to the switch's setting? Perhaps in addition whether the snippets should be installed / uninstalled?

   Since Shopware 6.7.3.0 the language pack displays a warning, that it's recommended not to use it and that it will not work with 6.8.x anymore. Unfortunately the deinstallation of the language pack removes all translations included there (test with 6.7.4.0, with selection "Remove all data it even throws an exception).
   The dev docs recommend this way https://developer.shopware.com/docs/resources/references/upgrades/core/translation/language-pack-migration.html. But not every customer is feeling comfortable being forced to use the command line. It is intended to activate / deactivate a language via the language itself. So why don't you add an install / uninstall routine in settings > language to… more

   1 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  ·  Edit…  ·  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

7. Improve Safety and Flexibility for Promotion Code Configuration

   Context

   In the current version of Shopware 6, when creating a new promotion, the field “Promotion code type” is automatically set to “No promotion code required”.
   This UX choice was made intentionally to simplify creation of general cart-level discounts, which are the most common use case.

   However, this default selection can lead to unintended activation of promotions when a user forgets to change the option to “Fixed” or “Individual promotion code.”
   In such cases, discounts may be applied to all customers instead of a limited target group, which can cause serious financial and operational issues.

   Problem

   • Users may overlook that a promotion is configured without a code, because “No code required” is preselected

   • This can unintentionally trigger discounts for all customers

   • Currently, there is no system-level control or "safeguard" to prevent this

   Proposed Solutions

   We suggest adding configurability or safety mechanisms for the “Promotion code type” field to reduce user errors and increase administrative control.

   There are three possible options that could be implemented independently or in combination:

   1. Require explicit selection (no default preselection)
      Remove the preselected value “No promotion code required.”

   2. System-wide default configuration
      Add a configuration setting in system or admin preferences allowing administrators to define the default for new promotions

   3. Optional warning before activation
      Display a confirmation or warning when activating a promotion that has no promotion code set.
      Example message:
      “This promotion will be applied to all customers because no promotion code is required. Are you sure you want to activate it?”

   Expected Benefits

   • Prevents accidental large-scale discount activations

   • Improves administrative control and safety

   • Reduces support incidents and potential financial losses

   • Aligns the promotion workflow with enterprise-level requirements

   Context

   In the current version of Shopware 6, when creating a new promotion, the field “Promotion code type” is automatically set to “No promotion code required”.
   This UX choice was made intentionally to simplify creation of general cart-level discounts, which are the most common use case.

   However, this default selection can lead to unintended activation of promotions when a user forgets to change the option to “Fixed” or “Individual promotion code.”
   In such cases, discounts may be applied to all customers instead of a limited target group, which can cause serious financial and operational issues.

   Problem

   • Users may overlook that… more

   1 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  ·  Edit…  ·  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

8. Filters for Flow Builder

   For bigger lists of any entity, it is super important to have filters in order to find efficiently what you are looking for. We have filters for the Products, Customers, Rule Builder overviews and probably in many other menus as well.

   There for we should most definitely also have this kind of filtering also for the Flow Builder overview.

   Finding the flow you are looking for only with the search is a pain. Try to search for the flow "Order placed". Since the string "order" is part in 90% of all flows out of the box, you will not be able to find it but will need to filter manually through the list of flows again.

   For bigger lists of any entity, it is super important to have filters in order to find efficiently what you are looking for. We have filters for the Products, Customers, Rule Builder overviews and probably in many other menus as well.

   There for we should most definitely also have this kind of filtering also for the Flow Builder overview.

   Finding the flow you are looking for only with the search is a pain. Try to search for the flow "Order placed". Since the string "order" is part in 90% of all flows out of the box, you will not be… more

   1 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  ·  User Experience  ·  Edit…  ·  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

9. "not specified" salutation handling

   This is handled rather inconsistently in Shopware. In some but not all places, if you leave out the salutation, Shopware searches the database for the "not_specified" entry that comes with the installation and inserts it if found. If also sometimes inserts it just for display in the Administration if the real salutation reference is null, so you wouldn't even know the real value without looking directly into the database, but again, not always.

   Crucially, that "not_specified" entry can be changed and deleted at will, so there's no guaranteed meaning behind it.

   Also, sometimes like in the contact form the salutation is randomly required. You can delete it for addresses and the database has a default value of null, but then there is a non-configurable validator that won't let you through the checkout process if no salutation is given. And again, "given" can just mean that you set the "not_specified" salutation, which can have any meaning you assign to it.

   This is an intransparent mess and should be changed. The very legality of requiring a salutation is now even in question. Just allow null values for all salutations in the application, it's already allowed in the DB structure, stop enforcing it in random places without a way to turn it off, and make the display name of a "null" salutation translatable via config.

   This is handled rather inconsistently in Shopware. In some but not all places, if you leave out the salutation, Shopware searches the database for the "not_specified" entry that comes with the installation and inserts it if found. If also sometimes inserts it just for display in the Administration if the real salutation reference is null, so you wouldn't even know the real value without looking directly into the database, but again, not always.

   Crucially, that "not_specified" entry can be changed and deleted at will, so there's no guaranteed meaning behind it.

   Also, sometimes like in the contact form the salutation… more

   1 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  ·  Content management  ·  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

10. Display order details clearly on one page instead of using tabs (similar to Shopware 6.4)

    The details of an order should be clearly displayed on one page. Unfortunately, the details are currently spread across several tabs.

    Clicking around, loading the various tabs and changing details takes longer than if everything could be done on one page.

    Shopware 6.4 is clearer than Shopware 6.7.

    Please change this.

    1 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

11. Add selection field in user profile settings for measurement preferences

    When a user changes the unit in a product, this change is applied at the user level and stored in the database in the user_config table with the key measurement.preferenceUnit. If there is already a dedicated entry for this in the database, it would be nice if the selection could be changed directly in the user profile.

    1 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  ·  Edit…  ·  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

12. organisation unit should be defined in new emplyee

    As the organisation units are available with version 6.7, it should be possible to map the unit for new employees.

    Currently only the role can be set.

    Employees can only be mapped within the organisation unit when the employee is active (invitation link is clicked within the 2 hours reaction time).

    If organisation units are active in the customer and units are defined, it should be possible to map it within the employee mask. For existing and new employees.

    1 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

13. Add empty alt tags to untagged thumbnails in image galleries

    Untagged images in the gallery get an empty alt tag when not tagged, which is a good default behaviour. The thumbnails in the gallery also need this. Currently, untagged images don't get any alt tag at all. This is an accessibility problem!

    1 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  ·  Content management  ·  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

14. Contact Form: Remove salutation Requirement

    In most places, the salutation is no longer a requirement, but for some reason, in the contact form, it still is.
    If you want to override this via an extension, you have to override not only the template but also the validation as well as the ContactFormRoute since it builds criteria with the salutationId and assumes it to be set.
    There doesn't seem to be a good reason to force this requirement. At the very least, there should be a config to make the field optional.

    1 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

    DECLINED  ·  1 comment  ·  Content management  ·  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

15. Zahlungsart ändern

    Die Zahlungsart sollte man nach dem Kauf ändern können. Es passiert oft, dass eine Zahlung fehlschlägt (über Amazon Pay oder PayPal) oder die Zahlung abgebrochen wird und der Kunde trotzdem die Ware möchte.

    Momentan kann man leider nicht die Zahlungsart auf "Kauf auf Rechnung" ändern. Auf den Rechnungen steht dann die falsche Zahlungsart drauf.

    Außerdem sollte man die vorausgewählte Zahlungsart der Kunden wieder ändern können. Mit 6.7.x ist diese Funktion entfernt worden.

    ENG: The payment method should be changeable after a purchase.
    It often happens that a payment fails (for example via Amazon Pay or PayPal) or is cancelled, but the customer still wants to receive the goods.

    At the moment, it’s unfortunately not possible to change the payment method to “Invoice purchase”. As a result, the wrong payment method is shown on the invoices.

    In addition, it should be possible to change the preselected payment method for customers again.
    This function was removed with version 6.7.x.

    Die Zahlungsart sollte man nach dem Kauf ändern können. Es passiert oft, dass eine Zahlung fehlschlägt (über Amazon Pay oder PayPal) oder die Zahlung abgebrochen wird und der Kunde trotzdem die Ware möchte.

    Momentan kann man leider nicht die Zahlungsart auf "Kauf auf Rechnung" ändern. Auf den Rechnungen steht dann die falsche Zahlungsart drauf.

    Außerdem sollte man die vorausgewählte Zahlungsart der Kunden wieder ändern können. Mit 6.7.x ist diese Funktion entfernt worden.

    ENG: The payment method should be changeable after a purchase.
    It often happens that a payment fails (for example via Amazon Pay or PayPal) or is cancelled, but… more

    1 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

16. Image keyword assistant for logos

    The image keyword assistant should be able to recognize well-known logos, not just objects.

    For example, when you upload the Shopware logo, only “Logo” appears as the alt text. When you upload Facebook logo, “Symbol, sign, cross” appears, which isn't really accurate, and nothing appears at all for Instagram logo.

    1 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  ·  AI  ·  Edit…  ·  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

17. UI / UX Improvements on Data Mapping in Shopping Experiences

    Please add pagination and search field to the data mapping (Datenzuordnung) list in CMS elements.

    1 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  ·  Content management  ·  Edit…  ·  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

18. Multi Inventory - Save multiple stock updates at once

    Feature: Multi Inventory

    If you have multiple warehouses in a warehouse group, at the moment you need to save the changes for every single warehouse one after the other. This does not feel intuitiv and slows down the process.

    I have recorded this in a test environment:
    https://www.awesomescreenshot.com/video/44727162?key=8481c10b30e8e71a1daeda1cee4be3da

    As you can see this can be quite annoying.

    In my opinion, it would be more user friendly if there would be one global save button for the multi inventory window than having to save every single change for every single warehouse.

    1 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  ·  User Experience  ·  Edit…  ·  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

19. Multi Inventory - Adding stock redirects annoyingly

    When working with the Shopwares Multi Inventory feature and wanting to assign stock to products, there is an annoying redirect to the first Warehouse Group after every update of stock in another Warehouse group.

    I have recorded this to showcase:
    https://www.awesomescreenshot.com/video/44724575?key=28cd44e9f3bd2e226b5b66e013185d70

    As you can see in the video, whenever I apply changes to warehouse group 2 & 3, you get redirected to the group 1 again, even if I might still need more changes applied in those previous groups. This interrupts and slows down the process, because I have to navigate back to either group 2 & 3 again.

    1 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  ·  User Experience  ·  Edit…  ·  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

20. Individual mandatory fields in the components

    In Shopware, there are both optional and required fields for the billing address and delivery addresses, where this assignment makes no sense in the B2B sector. A personal contact person is, in most cases, an optional addition in the B2B sector.

    The typical billing information for a company address is: Mustermann GmbH Musterweg 1 12345 Musterhausen

    Persons are also rarely listed in the delivery addresses. Here, too, it should only be an option. In the delivery addresses, it may be necessary to explicitly list a recipient: Mustermann GmbH, Attn: Marketing Department - Uwe Kleemann, Musterweg 1 12345 Musterhausen.

    Currently, the following required fields are available:
    First name, Last name, Street and house number, City, Country

    and the following

    optional
    fields: Company, Department, ZIP code, State

    The following distribution would make sense for the B2B sector, and therefore for us:

    Required fields:
    Company, Street and house number, ZIP code, City, Country

    Optional fields:
    First name, Last name, Department, State

    In Shopware, there are both optional and required fields for the billing address and delivery addresses, where this assignment makes no sense in the B2B sector. A personal contact person is, in most cases, an optional addition in the B2B sector.

    The typical billing information for a company address is: Mustermann GmbH Musterweg 1 12345 Musterhausen

    Persons are also rarely listed in the delivery addresses. Here, too, it should only be an option. In the delivery addresses, it may be necessary to explicitly list a recipient: Mustermann GmbH, Attn: Marketing Department - Uwe Kleemann, Musterweg 1 12345 Musterhausen.

    Currently, the… more

    1 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