Hello everybody, does somebody know if its possible to have more than just a flat key->value stru

UPWG9AYH2

Hello everybody,
does somebody know if its possible to have more than just a flat key->value structure for product attributes? Something like nested attributes?
Background: Our concrete products consists (phyisically) of multiple items which are not sellable in spryker but necessary for determining a price. So we have to transmit them along the cart calculation or checkout to the ERP system. So in the end its just some kind of meta information, which normally would fit into something like product attributes.
Is it somehow possible to reflect that using product attributes on the concrete product or is this a fully custom implementation?
The added data has something like: part_id, quantity, description … so the amount of rows of the party will differ for each concrete product. Any other suggestions or experience?
Best regards.

Helen Laktionova

Hello Ingo

If you need it just as an information storage - use Json and then parce it when you need

If you need some more advanced functionality, like filtering/searching by this attribute or something else - please describe more, so we can try to find the best fit here.

Hope it helps 🙂

UPWG9AYH2

Hello Helen,
thanks for your response.
It might be that saving it as a json string is not sufficient. Another idea: Is there some concept of “virtual product” in spryker? I could imagine that something like this is required for digital products (no stock management etc.).
We consider to create this unsaleable parts as normal spryker products anyway. But they must not be searchable and they don’t have a price. Also stock might not be a topic. Then just simply create a m:n relation and connect it to the concrete product. Any experiences with this?
Best

Helen Laktionova

Hello Ingo, sounds a bit like product bundles with never out of stock and not searchable products inside the bundle.
https://documentation.spryker.com/docs/en/product-bundle
I think you can adjust the functionality a bit for concretes, to hide them outside of the bundle (PDP will be still available).

UPWG9AYH2

We also had that product bundles in mind. That means, a Bundle consists in the end of not saleable products, right?
The problem here is, that you cannot sum up the “product variants” like you do in the abstract/concrete pattern. Here you have input fields where you decide the concrete variant of an abstract product.
What i got is, that this is not possible with a product bundle. So you cannot “drill down” the desired product bundle on a detail page, right?
Best

UPWG9AYH2

for the workflow in Abstract/Concrete pattern this would mean:

Search for Abstract Product A -> go to the detail page -> configure super attributes -> results in Variant 1 -> show related components

Is it also possible with the bundles? That would mean something like

Search for “Abstract Bundle A” -> go to the detail page -> configure super attributes -> results in bundle variant 1 (consisting of other concrete products)

Helen Laktionova

It is like bundle with abstracts.
There is no OOTB functionality according to what I know.

There are some other features, they will not cover the request fully, but just to get inspired:
https://documentation.spryker.com/docs/configurable-bundle
https://documentation.spryker.com/docs/product-group
https://documentation.spryker.com/docs/product-sets

In general questions before start the implementation:

• How to show all the variants selections on 1 page?
• How to calculate availability (in case we should have it)?
• Is there some additional functionality?
Probably the best would be to have project adjustments to OOTB feature (you can choose which one can cover better the requirements) or custom implementation (depending on the answers and effort).

Custom implementation can be better from the perspective of future Spryker updates for bundle functionality. And it is recommended.

OOTB feature customisation can be better because of the speed of implementation, but will increase time for future Spryker updates.

Hope it helps and curious about your decision and implementation 🙂

UPWG9AYH2

Hi Helen,
thanks for response. That seems to work so far.
One question left:
Is it possible to have one abstract product with different variants without defining a super attribute? For example the abstract product would be “mechanical part” and the difference on variant level is in fact the sku … so they dont really have any common attribute on which they could differ. Just a different SKU … if i try to import in that way like described, i get something like “Attributes of each variant must not be equal”.
Defining the SKU as an super attribute feels ugly since this is already a property of the concrete variant …
Any idea?
Best

Helen Laktionova

We need to distinguish concretes somehow. For that we are using the super attribute.
So the fastest way is to have the fake super attribute

Helen Laktionova

Otherwise you can update the OOTB behaviour, but it will take some time