What are the Slack Archives?
It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.
Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..
Hello everybody, does somebody know if its possible to have more than just a flat key->value stru
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.
Comments
-
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 🙂
0 -
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?
Best0 -
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).0 -
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?
Best0 -
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)
0 -
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-setsIn 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 🙂
0 -
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?
Best0 -
We need to distinguish concretes somehow. For that we are using the super attribute.
So the fastest way is to have the fake super attribute0 -
Otherwise you can update the OOTB behaviour, but it will take some time
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 75 Spryker News
- 921 Developer Corner
- 781 Spryker Development
- 88 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 34 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 25 Job Opportunities
- 3.2K 📜 Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 32 Product & Business Questions
- 70 Spryker Safari Questions
- 50 Random