It may be a little tricky. We run a business that sells recycled auto parts, and in certain cases we want that the customer send us their old part in exchange to the part they are buying. However, sometimes it is not possible so we charge an extra fee called 'core charge' to compensate the old part that he won't send.
So suppose a part 'xxxx' that costs $50 and that has a 'core charge' or $15 and another part 'yyyy' that costs $80 and that has a 'core charge' of $23. When the customer add these parts to the cart we would like something like this in the cart:
part xxxx.............................. $50
core charge for part xxxx..... $15
part yyyy.............................. $80
core charge for part yyyy..... $23
The more important is that the main price and 'core charge' show up separately but that the customer does NOT be able to remove the 'core charge' from the cart.
There is a way to do that?
in MultiStore by (1.2k points)
edited by
I assume that the core charge should be scaled by the quantity of the item in the cart - 5 of the item results in 5 core charges - and that the core charges should be adjusted as the quantity of the item in the cart changes.

We had a similar requirement with shipping surcharges for oversized items. Ended up creating a new field for the charge data on the ProductVariant table in the database and modifying a bunch of the core classes to handle it. The developer that did all this wasn't too keen on OOP, and it's a great big mess as a result.

It is possible, not sure if anyone else out there has experience doing this with the off-the-shelf components.
Hi Chris,

Yes the core charge should scale altogether with the quantity of items purchased (although in our case I think that 99.99% of times it will be only one part).

We already have a custom table with the core charge for the items in our inventory and I thought on make changes in the code. However I try the most I can to NOT mess with original code specially because the package updates. My hope was that MultiStore already had a native way of doing it.

As a 'plan B' solution I thought to capture the values (price, core charge and product description) then change it on-the-fly while the user is adding it to cart. The idea would be to summ the core charge to the price making the result as the new price and add a note to the description telling how much of core charge is being charged.

Thank you for your input.
Trust me, I wish my predecessor had been as concerned about source code mods as you are.

I can share some of my notes on what all was done, that should provide you a good jumping off point to extend those core classes. It's important to extend the Vortx source code, rather than modify it, because extending will preserve your upgrade path.

Give me a bit to compile some information for you.

I apreciate this... it will help a LOT! Thank you! I will await for your notes! :)

My concern about the code changes and such is because my boss likes to stay always in the latest update, so basically as soon as a new version is released he upgrades the system. I am more a conservative person and prefer to stay with what it working, but... I am not in charge of those decisions!

For database, here it goes a tip that may help you in the future. We have a 'side DB' with several tables that complements the MS original table set. In the case of the charge core, for instances, instead to modify an existing table we created a separate new table with two columns (the charge core value and the inventory number). Then when we need to know the charge core for a product is just to cross the inventory number and get it. It was a way we found to not mess with MS tables.

I have made some minor changes in the MS code but I keep it very well documented to be able to reproduce it after the updates. Even so it is a pain!

1 Answer

0 votes
Best answer

Here's an approach that looks very promising:

My thought is that you can set up your core charges as individual Product items that ship for free and set them as being required on the principal item, they'd auto-add to the cart, and not be removable without deleting the principal.

Testing it on my sandbox.

by (3.7k points)
selected by
Alright, the technical processing on this approach works well as long as the customer doesn't decrease the quantity of the principal item after setting it higher. The quantity of the required product will be automatically increased to match the quantity of the principal, but not auto-decreased.

Unless you have a tremendous quantity of items, or a lot of churn in them, then this may be a good track to take with it. It has the added benefit of enabling you to establish individual SKUs for each of the core charges, allowing you to do better reporting on the sales activity of them.

PM me if you want more details on the totally-wrong-headed approach we took.


I loved this approach!

I think that it fulfils perfectly the needs of the core charge stuff.

The thing about the dependable item do not decrease automatically along with the principal product seems to be a code implementation bug for me. I should report it to the Vortx team then it can be fixed for a future version. However in the case of our company it won't be a problem since 99.99% of our products will be sold as unitary.

Anyway, now I just have to submit this idea to my boss and see if he will be happy on doing it this way. Personally I don't see why it would not be considered good as it can be implemented in a blink of an eye and is too much less hassle than dive into the MS code and classes and... oh my!
I will let you know otherwise...

Thank you very much for this valuable help!


There is often a lot of good stuff in the legacy forums, but it can be a bear to search for it - especially since many of the pages ended up 404 after the hack that took the forum down.

Good luck with that approach, I really wish my predecessor had taken that approach instead of what he did, but it's too late to worry on it now.


I have very good news at my end. I submited this approach to my boss and he liked (and aproved) it. Actually we already are implementing it. I only have to thank you very much for this heads up. It was an absolutely fantastic solution.



As a side note I am not totally sure that your predecessor can be 100% blamed for choose the 'wrong' way. Pick an urgent change, add a demanding boss breathing in the back of your neck and sum it with a bad documented software and I will be surprised if you won't end with a bad solution.

I really wish that SF/MS had a better documentation. I had such a bad time when I started to write my first XML.CONFIG pages due to lack of information. There was several things that I had to guess and waste a lot of time making stupid tests to figure out. Currently after to have written a dozen of pages things are better but it is still tricky to find how to do certain things in MS.

The sadest part of it is that are tons of nice hidden features that several of us never will be aware of. Because this once in a while we are obligated to reinvent the wheel and recode features that already are there. The absence of a decent guide turns the life of a MS developer into a wild venture.