Add plugin to associate simple products with bundle products.

[ghost]

fixes #21

To associate products to options in a bundle you need at least a column bundle_skus with the option-title and product sku separated by a colon. More optional options can be set. The defaults for these options can be set in the configuration. More products can be separated by semicolon.

The format for bundle_skus is:
"Option title in admin store:sku-of-product:[selection_qty]:[selection_can_change_qty]:[position]:[is_default]:[selection_price_value]:[selection_price_type];Option title in admin store:sku-of-other-product"

You may control the options with the bundle_options column. You can delete options by prefixing the title with a minus "-". If you want to delete all options you have to specify an option with a minus followed by an asterisk "-*". More options can be separated by semicolon.

The format for bundle_options is:
"Option title in admin store:[Option title in item store]:[type]:[required]:[position];-*"

[dweeves]

Accepting merge request, good job !!! will try it ASAP

[juggernaught]

Was there a reason for not using the default magento column headings (bundle_options & bundle_selections) and as well was there a reason for not using the dataflow format for each.

I forsee an issue with data migration from one server to another. If we export bundled products with dataflow we cannont import them with magmi without changing the format.

What are your thoughts around this? @tantau-limora

[ghost]

No other reason than sheer ignorance.
I thought Magento didn't have a way of importing this either. I will look into Magento's way and adjust the plugin accordingly.

[ghost]

@juggernaught Can you give me your Dataflow XML? I wasn't able to get anything out of Magento, except for the standard attributes.

I was using:

<action type="catalog/convert_adapter_product" method="load">
    <var name="store"><![CDATA[0]]></var>
    <var name="filter/type"><![CDATA[bundle]]></var>
</action>

<action type="catalog/convert_parser_product" method="unparse">
    <var name="store"><![CDATA[0]]></var>
    <var name="url_field"><![CDATA[0]]></var>
</action>

<action type="dataflow/convert_mapper_column" method="map">
</action>

<action type="dataflow/convert_parser_csv" method="unparse">
    <var name="delimiter"><![CDATA[,]]></var>
    <var name="enclose"><![CDATA["]]></var>
    <var name="fieldnames">true</var>
</action>

<action type="dataflow/convert_adapter_io" method="save">
    <var name="type">file</var>
    <var name="path">var/export</var>
    <var name="filename"><![CDATA[bundle_products.csv]]></var>
</action>

[juggernaught]

@tantau-limora

My bad on this. I was mistaken I used a custom advanced dataflow profile script to export bundles. However this still poses a problem with exporting bundles and importing them into a new server. Do you have any plans on building something to export bundled items from Magento using dataflow?

Also I did some further testing importing using magmi and this plugin works like a charm. I cant break it. Great work.

Some additional feature I found that would make this even better are the following:

1. Selecting a default selection - Currently there is no way to select a default selection.
2. Exporting bundled products from magento ( I have a script you can use perhaps you can modify it to work with your format)
3. Documentation. I was able to determine how to use this but there are still many questions.

Thank you for your excellent work on this.

[ghost]

@juggernaught

We are working with an external datasource, so we have no need for export functionality. You'd be on your own with that, sorry.

You can set a default by setting the the sixth parameter of bundle_skus to 1.

Regarding the documentation I will open a new ticket for that. I tried editing the wiki page, but I do not have the appropriate permissions.

[dweeves]

Documentation updated on wiki , made little changes (used skuXXXX instead of name like skus to avoid misunderstanding in samples)

Now my 2 cents on the format:

i would have preferred 1 column per option since it would be easier to undestand & fill.

The compact format you have is easy to parse but more complex to fill by a human being.

From a logical point of view, my guess is that for bundled, the user knows 2 things:

• The list of options that would define its bundle and the option parameters. (bundle structure data)
• Per option, the list of skus that would have to be proposed to the user. (bundle content data)

I think the current format you use requires for each sku the option name to be repeated , while a column based format would have been more straightforward.

Nevertheless, you did a fantastic job !

[juggernaught]

I have tested this extensively and tried to break it but couldn't. Great work!.

As for the format a column based approach would have been better especially when working with this in a spread sheet. However once you get going on making large spread sheets its really not that bad. You get used it this format. Infact the guy doing the work on the csv for me actually prefers this method. To each to there own.

GREAT WORK.

As for an export function I would contact dev.magelynx@gmail.com these folks are great and are itching to move on this.

[ghost]

Thanks. :-)

My rationale with using the compact format was that the number of options are row-specific. If you have a bunch of options you'd either have a lot of columns that are only needed by one product or you'd have to give them generic labels, making them harder to read.

But I guess it should be easy enough to extend the plugin to also support the colum based approach, if it is needed.

[dweeves]

You're right for the "varying" column number, but my guess is that bundled products are more or like "typed". (a bit like attribute sets which define a specific product type)

so i doubt in a single catalog you'll get many combinations of totally different bundles (but i may be wrong on this point).

Even in this case, i think it would be more convenient for the user to use several CSVs (one per bundle structure) , so one column set per csv,but once again , it's a guess.

[juggernaught]

I thinks its best to keep it in the compact format. I have bundles with 3
simples associated with them so this means I would need columns in
triplicate to achieve this , So for position you would do somthing like
1:1:1 each 1 representing a simple sku.

You cant get around the compact format better to keep it the way you have
it.

On Tue, Apr 29, 2014 at 8:28 AM, Sebastien Bracquemont <
notifications@github.com> wrote:

You're right for the "varying" column number, but my guess is that bundled
products are more or like "typed". (a bit like attribute sets which define
a specific product type)

so i doubt in a single catalog you'll get many combinations of totally
different bundles (but i may be wrong on this point).

Even in this case, i think it would be more convenient for the user to use
several CSVs (one per bundle structure) , so one column set per csv,but
once again , it's a guess.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/31#issuecomment-41691114
.

[jspenger]

Just tried it, and works great! Thanks alot for the hard work! Made a minor change to it, in order to bulk-import Bundle-Selections with the same SKU within a Bundle-Option, by commenting out

$existingSkus = $this->selectAll($sql, $bind);

Best Regards,
Jonas

[juggernaught]

There are benefits of both. I am currently using this plugin to import
complex bundles making the compact format far easier to use.

I did find one bug though. From time to time bundled product are
duplicated. When import using create new or update existing it create
duplicate products with the exact same sku.

On Tue, Apr 29, 2014 at 2:14 AM, Sebastien Bracquemont <
notifications@github.com> wrote:

Documentation updated on wiki , made little changes (used skuXXXX instead
of name like skus to avoid misunderstanding in samples)

Now my 2 cents on the format:

i would have preferred 1 column per option since it would be easier to
undestand & fill.

The compact format you have is easy to parse but more complex to fill by a
human being.

From a logical point of view, my guess is that for bundled, the user knows
2 things:

• The list of options that would define its bundle and the option
  parameters. (bundle structure data)
• Per option, the list of skus that would have to be proposed to the
  user. (bundle content data)

I think the current format you use requires for each sku the option name
to be repeated , while a column based format would have been more
straightforward.

Nevertheless, you did a fantastic job !

—
Reply to this email directly or view it on GitHub
#31 (comment).