You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 17, 2020. It is now read-only.
In situations where the simple and configurable product_type are each inserted as separate rows on SFOI, we use this field to filter out the simple rows. This prevents duplication.
parent_item_id references the item_id of the equivalent configurable row, for example:
@alexkleger is this actually creating an issue in the sample data, or do you just want this added for illustrative purposes? From what I can see, the data generated now doesn't even use product_type in this way (it seems to be inserting a category name like "tools" in to that field). Do we need to revamp how product/items data is generated in order to make this issue relevant or am I overcomplicating things?
@robertjmoore you are correct. I missed that there wasn't an open issue for product_type yet.
The data should be generated as in the above example — two rows for each product, where one row is simple, one row configurable.
BUT a workaround here is to simply to add a non-null parent_item_id to all the rows, as the goal of this is to be able to add a clause in the "Order items we count" filter set restricting the data to where parent_item_id is not null. This is how the SEs prevent double counting of items sold.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In situations where the simple and configurable
product_type
are each inserted as separate rows on SFOI, we use this field to filter out the simple rows. This prevents duplication.parent_item_id
references theitem_id
of the equivalent configurable row, for example:parent_item_id
= INT(10), default to nullThe text was updated successfully, but these errors were encountered: