1538 results found

1. Commercial: improve organization units for shopping lists

   Currently, the organization unit field on shopping lists is purely an informational indicator from which unit the list was originally created.

   The following improvements should be added to give this more utility:

   • The OU field should be definable during creation (i.e. by admins or the customer account) and changeable / re-assignable afterwards when needed.
   • Role permissions should be added that define which lists from which OU an employee can see - this allows better separation between units which should not see lists from other departments.
   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  ·  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

2. Add promotion code via link

   It would be a nice feature if discount codes could be redeemed via link in the same way that EasyCoupon does it for example. This would allow merchants to send mails already including a working link to get the customer shopping with their discount. For the customers, this would make the journey smoother because they don't need to back and forth to get some code and find the field to enter it and so on.

   Plus, the customer is probably much more likely to actually complete the checkout if they see their shiny discount applied at all times right from the moment they visit the store.

   It would be a nice feature if discount codes could be redeemed via link in the same way that EasyCoupon does it for example. This would allow merchants to send mails already including a working link to get the customer shopping with their discount. For the customers, this would make the journey smoother because they don't need to back and forth to get some code and find the field to enter it and so on.

   Plus, the customer is probably much more likely to actually complete the checkout if they see their shiny discount applied at all times right from… more

   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  ·  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

3. Advance payment for subscription for a fixed subscription period

   The following use case occurs very frequently in our business model:
   A person gives away a subscription for 3, 6, or 12 months. The giver does not want to pay for each individual shipment separately, but rather pay the total amount once at the beginning, and the subscription ends after the prepaid period.

   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

   1 comment  ·  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

4. Improvements to the thumbnail generator

   One customer noticed these limitations of the thumbnail generator:
   Square dimensions are used by default. This means that images with different widths and heights can vary greatly in quality when portrait and landscape images are used at the same time.

   The media manager allows the width and height to be set differently, but thumbnails that deviate from this format will be of poorer quality.

   In the customer's words:
   A square display is rarely the case. The most common display is landscape format.

   For optimal quality, the shortest side should be used rather than the longest side.

   This is the only way to ensure that images are always (!) optimally used in the respective resolution and based on the srcset / sizes attributes.

   One customer noticed these limitations of the thumbnail generator:
   Square dimensions are used by default. This means that images with different widths and heights can vary greatly in quality when portrait and landscape images are used at the same time.

   The media manager allows the width and height to be set differently, but thumbnails that deviate from this format will be of poorer quality.

   In the customer's words:
   A square display is rarely the case. The most common display is landscape format.

   For optimal quality, the shortest side should be used rather than the longest side.

   This is the only… more

   8 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  ·  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

5. Standardize shortName for Categories to ensure App and Headless stability

   Shopware provides a shortName for SalesChannels to enable environment-agnostic identification, yet this primitive is missing for Categories. This inconsistency forces App developers and Headless integrators to rely on volatile SEO URLs or environment-specific UUIDs to identify "Page Types" (e.g., Home, Support, Landing Page).

   By extending shortName to the Category entity, Shopware would provide a stable, indexed, and semantic developer contract. This eliminates the need for redundant repository searches or brittle Custom Field lookups, which currently penalize performance and complicate CI/CD pipelines. Standardizing this across core entities ensures that external systems can resolve both "Shop Context" and "Location Context" using the same native logic, drastically simplifying the integration of marketing, tracking, and CMS-driven Apps.

   Shopware provides a shortName for SalesChannels to enable environment-agnostic identification, yet this primitive is missing for Categories. This inconsistency forces App developers and Headless integrators to rely on volatile SEO URLs or environment-specific UUIDs to identify "Page Types" (e.g., Home, Support, Landing Page).

   By extending shortName to the Category entity, Shopware would provide a stable, indexed, and semantic developer contract. This eliminates the need for redundant repository searches or brittle Custom Field lookups, which currently penalize performance and complicate CI/CD pipelines. Standardizing this across core entities ensures that external systems can resolve both "Shop Context" and "Location Context" using the… 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  ·  App System  ·  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. ZIP code validation only takes effect once all other mandatory fields have been filled in during checkout.

   While testing the checkout process, I noticed inconsistent behavior when validating the postal code.

   Steps to reproduce:

   1. Go to checkout.

   2. Select country.

   3. Enter an invalid value in the “Postal code” field (e.g., asdasd or asd123).

   4. Leave at least one other required field blank.

   5. Click “Continue.”

   Result:
   All required fields are marked as incorrect except for country and zip code.
   The zip code is not displayed as invalid in this state.

   Further behavior:
   As soon as the previously missing required field is filled in, the zip code validation takes effect retrospectively and the field is then marked as incorrect.

   Expected behavior:
   The ZIP code should be validated immediately as soon as an invalid format is entered, regardless of the status of other required fields or alternatively, a uniform validation behavior should be applied to all required fields.

   Note:
   Even though this case is likely to occur rarely, the behavior appears inconsistent to users and could lead to confusion.

   While testing the checkout process, I noticed inconsistent behavior when validating the postal code.

   Steps to reproduce:

   1. Go to checkout.

   2. Select country.

   3. Enter an invalid value in the “Postal code” field (e.g., asdasd or asd123).

   4. Leave at least one other required field blank.

   5. Click “Continue.”

   Result:
   All required fields are marked as incorrect except for country and zip code.
   The zip code is not displayed as invalid in this state.

   Further behavior:
   As soon as the previously missing required field is filled in, the zip code validation takes effect retrospectively and the field is then marked as incorrect.

   Expected behavior:… more

   4 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

   1 comment  ·  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

7. Improving admin management for product reviews

   In order to work effectively with product reviews, improvements are needed in the admin management for product reviews.
   Currently, managing reviews is not possible; there are no filters (e.g. product, stars, sales channel, language, approved, date) and after editing a review, you are taken straight back to the first page.

   •  

   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  ·  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

8. Role permissions for the image editor

   Currently, it is not possible to enable or disable the image editor for users of a role.

   Only the designated administrators have access to the image editor on Content > Image Editor.

   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  ·  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

9. Finetune the personalized Checkout Message

   Currently the checkout messages can’t be adjusted to exclude certain items or be fine-tuned. To customize the checkout message more precisely to your needs, it would be great to add further configurations to it.

   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  ·  AI  ·  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. Configurable mapping of the buyer reference in e-invoices (ZUGFeRD / XRechnung)

    In the current default behavior, the <BuyerReference> field in the generated e-invoice (ZUGFeRD / EN16931) is populated with the purchase order number.

    However, for invoices to public sector clients (government agencies), the routing ID is generally required in the <BuyerReference> field. If the purchase order number is used instead, this can lead to:

    • Validation errors in ERP/accounting systems (e.g., Lexware)
    • Rejections by public sector clients
    • Problems with input tax deduction
    • Rejection by Peppol/XRechnung validators

    Currently, there is no configuration option in the admin panel to adjust the BuyerReference mapping.

    Problem:
    - The <BuyerReference> parameter is not flexibly configurable by default.
    - Merchants with government clients must provide the routing ID.
    - - Currently, customization is only possible via:
    - custom code
    - event subscriber (ZugferdInvoiceGeneratedEvent)
    - plugin customizations.
    - This results in unnecessary implementation effort for a common scenario.

    Proposal
    Introduce a configurable option in the document/e-invoice setup:

    Option A – Selection field in the Admin

    In the section:
    "Settings → Documents → E-Invoice"

    Configurable mapping field for BuyerReference (fe):
    - Dropdown:
    - Order number
    - Customer number
    - Custom field (from Customer)
    - Custom field (from Order)
    - Freely definable mapping (e.g., via Twig expression)

    In the current default behavior, the <BuyerReference> field in the generated e-invoice (ZUGFeRD / EN16931) is populated with the purchase order number.

    However, for invoices to public sector clients (government agencies), the routing ID is generally required in the <BuyerReference> field. If the purchase order number is used instead, this can lead to:

    • Validation errors in ERP/accounting systems (e.g., Lexware)
    • Rejections by public sector clients
    • Problems with input tax deduction
    • Rejection by Peppol/XRechnung validators

    Currently, there is no configuration option in the admin panel to adjust the BuyerReference mapping.

    Problem:
    - The <BuyerReference> parameter is not flexibly configurable by default.… more

    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  ·  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. Allow B2B employee deletion when pending orders exist - GDPR compliance

    Currently deleting a B2B employee who has pending orders fails with a raw FK constraint error (SQLSTATE 23000). The only workaround suggested is cascade-deleting the orders, which is unacceptable.

    Real-world scenario: An employee leaves the company. The organization is legally required under GDPR (right to erasure) to remove that person's personal data. However, pending orders are financial records of the organization, not the employee's personal data, and must be preserved.

    The fix does not require decoupling orders from customers. It only requires allowing employee_id on pending orders to be nullified (SET NULL) or reassigned to another employee before deletion. The order record stays intact, only the link to the former employee is removed.

    Impact: Every B2B merchant with employee turnover faces this. In the EU, GDPR compliance is not optional - merchants cannot tell regulators "Shopware doesn't support it."

    Suggested solution:
    1. Change FK fk.pendingorder.employeeid to ON DELETE SET NULL
    2. Provide a way to reassign pending orders to another employee before deletion

    Currently deleting a B2B employee who has pending orders fails with a raw FK constraint error (SQLSTATE 23000). The only workaround suggested is cascade-deleting the orders, which is unacceptable.

    Real-world scenario: An employee leaves the company. The organization is legally required under GDPR (right to erasure) to remove that person's personal data. However, pending orders are financial records of the organization, not the employee's personal data, and must be preserved.

    The fix does not require decoupling orders from customers. It only requires allowing employee_id on pending orders to be nullified (SET NULL) or reassigned to another employee before deletion. The… 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  ·  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

12. Let B2B Employees changed their own password

    It should be a standard functionality that a user can change their password.

    This is currently not possible.

    Please implement this.

    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  ·  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. Advanced Product Catalogues - Assign Category & Product Visibility Via Pre-Defined "Template"

    ENG: Use case: As a shop operator with many categories and products, I don't want to have to individually determine which categories and products a unit should have access to when creating organizational units. Instead, it should be possible to create templates—which may only be usable and visible at the admin level—that can be used to define viewing permissions accordingly. If I then need to create several organizational units, I could simply—where possible—quickly define the permissions using the template without having to manually define the same permissions again and again for each additional organization.

    DE: Use-Case: Als Shopbetreiber mit vielen Kategorien und Produkten möchte ich bei der Erstellung einer Organisationseinheiten nicht immer individuell bestimmen müssen, auf welche Kategorien und Produkte ein Einheit Zugriff haben soll. Vielmehr muss es die Möglichkeit gebene, das - ggf. nur auf Adminebene nutzbar und sichtbar - Templates erstellt werden können, über die Sichtberechtigungen entsprechend definiert werden können. Sofern ich dann mehrere Organisationsienheiten erstellen muss, könnte ich dann einfach - wo möglich - die Sichtberechtigungen schnell über das Template festlegen lassen ohne dieselben Berechtigungen abermals für jede weitere Organisatzion manuell festlegen zu müssen.

    ENG: Use case: As a shop operator with many categories and products, I don't want to have to individually determine which categories and products a unit should have access to when creating organizational units. Instead, it should be possible to create templates—which may only be usable and visible at the admin level—that can be used to define viewing permissions accordingly. If I then need to create several organizational units, I could simply—where possible—quickly define the permissions using the template without having to manually define the same permissions again and again for each additional organization.

    DE: Use-Case: Als Shopbetreiber mit vielen… more

    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

14. Rule-based hiding of Buy button

    In Shopware 6, the visibility of products can already be controlled via rules by using the dynamic access extension (up to a certain point, as the stock is not being validated). However, there currently is no native way to hide or disable the “Buy / Add to cart” button based on rules, especially when combining customer groups with product stock conditions.

    In B2B and hybrid B2C/B2B scenarios, it is common that products with stock = 0 (with closeout enabled) should still be orderable for specific customer groups, while the buy button should be hidden or disabled for all other customer groups. Moreover it should be possible to set "closeout" on sales channel level.

    In Shopware 6, the visibility of products can already be controlled via rules by using the dynamic access extension (up to a certain point, as the stock is not being validated). However, there currently is no native way to hide or disable the “Buy / Add to cart” button based on rules, especially when combining customer groups with product stock conditions.

    In B2B and hybrid B2C/B2B scenarios, it is common that products with stock = 0 (with closeout enabled) should still be orderable for specific customer groups, while the buy button should be hidden or disabled for all other customer… more

    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

    1 comment  ·  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

15. Filter visibility by selected sales channels

    For products, there is an option to set visibility for selected sales channels.
    
    This setting determines whether a product appears in search results or in the product listing.
    
    However, to see what is set for a product here, you have to open the product page and then click the settings button again.

    It would be nice to have an option right here in the product overview to filter by visibility 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  ·  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

16. Allow for CMS elements to be hidden on category pages when product listing page is not the first page

    When a category layout contains some text or images together with the product listing element, that text or element may be indexed by search engines multiple times for each page of the listing, leading to duplicate indexing and results.

    It would be helpful if certain elements could be hidden once the customer or the indexing bot navigates through the listing pages, or a URL contains the ?p= parameter. This would prevent redundant indexing.

    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  ·  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

17. The scrollbar in the category tree needs to be more user-friendly.

    If the shop has a complex category structure, navigating the categories in the admin area can quickly become very confusing. It often requires clicking and using the scroll bar, which is located at the very end of the category tree. This means users have to repeatedly scroll to the end of the tree, which is very time-consuming and needs to be simplified.

    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  ·  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

18. payment method per customer

    Default payment method should be available per customer so that we can use this information for
    - customer account
    - Reports
    - order confirmation

    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

19. 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

20. Product visibility: Only when customer has specific prices

    There have been a few requests by B2B shop owners where the challenge is as follows:

    Products should only be visible IF the observer/customer has specific prices for them. Basically, this means that no products are visible UNLESS the customer has a set price for it.

    From the perspective of a former B2B procurement manager: This is a relatively common thing to see. I purchased tools for the manufacturing personnel, for example. I'd contact the potential suppliers once a year, we'd sit down, talk projected order volumes, figures and conditions.

    After that was all negotiated, I'd get a price list for the various categories with individual prices, bonuses, conditions and so forth and the supplier would set it up on their end so that I could place orders online (if I wanted to) in their shop. Strictly speaking, I'd find all/most of the other items in their shop as well, but I would have preferred if I didn't - so my line of thinking aligns with the requests we got about this in Support, because I already negotiated every item which was relevant to the company I represented ahead of time - I don't need and don't want to see things I had no interest in and likely have no price list for either.

    So - two birds with one stone:

    1) The observer sees all the items they have a specific price for
    2) The observer does not need to filter what is/was relevant to them

    The implementation screams B2B Components. But I think the implementation is potentially simpler if done via Dynamic Access:

    If we had a condition which checks whether or not the observer has custom prices of any sort (be it via customer group - this should be the first condition in my mind - extended prices OR customer specific prices, we'd have all the rest covered already.

    There have been a few requests by B2B shop owners where the challenge is as follows:

    Products should only be visible IF the observer/customer has specific prices for them. Basically, this means that no products are visible UNLESS the customer has a set price for it.

    From the perspective of a former B2B procurement manager: This is a relatively common thing to see. I purchased tools for the manufacturing personnel, for example. I'd contact the potential suppliers once a year, we'd sit down, talk projected order volumes, figures and conditions.

    After that was all negotiated, I'd get a price list… more

    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