Need advice on where and who to talk to about...

[trickyjoe]

To anyone that reads this post many thanks. To anyone that replies....MUCH LOVE!!!

 

Ok here goes

 

I need to know who to talk to or where to start about the following situation.

 

I have 2500 pairs of shoes in a SQL database. I can get them into OSC/MYSQL quite easily but.... They are all individual items. They do have a stucture the last word always being the Size.

 

What i have at the moment is a site written in asp vbscript which makes sence code wise, but I'd really like to use OSC because its loads better overall, and I want to learn PHP in time.

 

My current code splits the description, removes the last word, puts it into new size varible, then loops through until the first part of the split changes. Then I use a sub loop that writes the available size varibles as a drop down within a form.

Check out http://www.rollersnakes.co.uk/skate_shoes....AM&search=1

 

Does anyone think this can be done in OSC?

 

Hope it can - I don't even mind sponsoring it as a project for OSC as I think loads of people might want to use it.

 

Thanks for any advice

 

Joe

[kgt]

Let me be sure I understand:

 

You have the following records in the database:

 

Black Shoe 10M

Black Shoe 7W

 

And you wish to keep them as separate records, but display them as one shoe in different sizes. I assume you do this for stock reasons? If so, you might want to think about using the contribution QTPro. It modifies OSC to allow you to track stock for different product attributes (size being an attribute). This way you would have one product for each shoe and still be able to track stock for the various sizes. Or is there another reason to have separate records for each size?

[trickyjoe]

Let me be sure I understand:

 

You have the following records in the database:

 

Black Shoe 10M

Black Shoe 7W

 

And you wish to keep them as separate records, but display them as one shoe in different sizes. I assume you do this for stock reasons? If so, you might want to think about using the contribution QTPro. It modifies OSC to allow you to track stock for different product attributes (size being an attribute). This way you would have one product for each shoe and still be able to track stock for the various sizes. Or is there another reason to have separate records for each size?

 

Yeah we have to have individual items for our in house system.

 

I'll have a look into QTpro thanks. Does it actually change the display of the items to the customer. Or just literally enable you to track stock?

 

Just so you know my data looks like the following if i pulll the basics out

 

100387 tnails/S14301BG.jpg EMERICA KIRCHART-4 BROWN/GUM 8UK 59.99 1 2006-06-16 5 2 8uk EMERICA SHOES EMERICA SHOES VAT Active EOREOR

100389 tnails/S14301BG.jpg EMERICA KIRCHART-4 BROWN/GUM 12UK 59.99 1 2006-06-16 7 2 12uk EMERICA SHOES EMERICA SHOES VAT Active EOREOR

102553 tnails/S14301BG.jpg EMERICA KIRCHART-4 BROWN/GUM 6UK 59.99 1 2006-06-16 1 2 6uk EMERICA SHOES EMERICA SHOES VAT Active EOREOR

 

I've written something in TSQL to split the description and put the colour and size into different feilds if needed.

 

I've even tried using the easy populate mod, but it's not really up to the job because I need the items to appear grouped based on the description.

[kgt]

Well how will you be handling stock between the two databases?

 

QTPro makes a change that allows for stock tracking on individual attribute combinations for a single product. The products become one product, with size and possibly model number as attributes of that single product.

[trickyjoe]

Well how will you be handling stock between the two databases?

 

QTPro makes a change that allows for stock tracking on individual attribute combinations for a single product. The products become one product, with size and possibly model number as attributes of that single product.

 

Basically I only feed into the OSC database stock > 0. As something sells out its automatically removed from the feed. Once an item is sold online I import the order into our inhouse system which then fires out the order/adjusts stock and the cycle continues.

 

So OSC doesn't need to have any form of stock control other than know the item is active.

 

I use a DTS to pump out the stock from SQL to TAB FILE. Then use the EP cont to pump into MYSQL.

[kgt]

Basically I only feed into the OSC database stock > 0. As something sells out its automatically removed from the feed. Once an item is sold online I import the order into our inhouse system which then fires out the order/adjusts stock and the cycle continues.

 

So OSC doesn't need to have any form of stock control other than know the item is active.

 

I use a DTS to pump out the stock from SQL to TAB FILE. Then use the EP cont to pump into MYSQL.

 

So is there any true need to keep the data in this format (a separate record for each size)? Someone wrote an EP version that works with QT pro. You'll still have some juggling to get it working how you want.

 

How are you importing orders? This is a dump from the OSC database to your in house system? Depending on how your dump is done, you may or may not want to go the QTPro route. Have one product record per shoe style will solve the display problem in OSC, but will make the order import a little more complicated. It's certainly not overwhelmingly complicated though.

[trickyjoe]

So is there any true need to keep the data in this format (a separate record for each size)? Someone wrote an EP version that works with QT pro. You'll still have some juggling to get it working how you want.

 

How are you importing orders? This is a dump from the OSC database to your in house system? Depending on how your dump is done, you may or may not want to go the QTPro route. Have one product record per shoe style will solve the display problem in OSC, but will make the order import a little more complicated. It's certainly not overwhelmingly complicated though.

 

I've got to keep the stock to one item = one size, because our lives have been bulit around it.

 

I'm importing the orders back into the system via csv. But I'm going to look at using a XML feed to speed things up.

 

Thanks for your advice on all of the above, but after messing with QTpro its not the ticket I'm after.

 

I think the only thing thats going to sort it is... If somehow I can get some help to replecate my VBscript code in PHP/OSC. So literally the products are split and grouped on the fly, for display purposes only.

 

Cheers

 

Joe

[kgt]

Doing so will not be a small project. OSC is based on product id, not product name, so you will have your work cut out for you to rework the whole thing to operate based on product name.

 

I'd suggest trying to make what's available work WITH what you need. You'll decrease the amount of work you need to do. If you're doing dumps/feeds between the databases, how does it matter what format OSC stores the data? The scripts are for making the two formats works.