[Owen Dessauer]

Hmm. Thanks john. Unfortunately, in my case the MPN: contains an essentially made up number (only used internally), so I do not use it in the Product ID field.Any other suggestions?

Also, does Sixbit have (or could you create) some documentation/videos on using the Teleriek Report Designer? I can’t find anything, and frankly, that is one very un-intuitive and very difficult to figure out piece of software. I’ve learned a ton of software on my own (of course often using docs etc.), but so far without any help Telerik has me beat, and I’m just trying to customize a label here, and a Packing List there!

[Owen Dessauer]

@Bob V.#
Thanks. You’ve confirmed my point and provided, as you’ve said, a kludge that is perhaps a slightly better way of handling it than I used for moving forward.

Maybe if enough people point these things out Sizbit will put appropriate priority on the necessary improvements. I have a few others I will probably point out when I have the time and feel motivated enough (unfortunately even a slight feeling like it’s falling on deaf ears is very unmotivating for providing what should be considered VALUABLE customer feedback!).

[Owen Dessauer]

John,

You perhaps missed my point (and kind of restated what I said).

Yes, cancel doesn’t work.
SO WHAT AM I SUPPOSED TO DO NOW??? That item REMAINS in Sixbit under
SHIP ORDERS >> IN PROCESS

So based on your response, I changed STATUS to RETURNED (even though that’s not what actually happened).
Then I processed the return in Sixbit per the suggested instructions, and included in the notes “Order was CANCELLED before being fulfilled”.
I see that works fine, so I suppose I’m being a stickler over language? In this case, it’s really “Returned or Cancelled” (but since Sixbit just says “Returned” we need to just know this). And so that’s what my rant is all about…

[Owen Dessauer]

DItto. Everything about Bonanza seems unpolished and very much like someone simply paid for an
“eBay Clone Script”, gave it a name and domain and threw it up.

[Owen Dessauer]

Bam,
Thanks, this does solidify in my mind the concept and implementation of items VS listing (and the GO TO function is helpful). However, I’m afraid what I described I would like to do is probably not possible. Please correct me if I’m wrong, but this is where I see it failing what I want (and what I suggest would be a better implementation of the concepts of ITEMS and LISTINGS)..

Yes, I want items separate from listings. Unfortunately, so much of the data required for an item (when creating an item entry) is in fact LISTING DATA. It seems when you create an item, you are in fact already writing (to a large extent) your listing. Then when you SUBMIT, it’s just uploading it and now shows the same exact info but with a “listing” label (or in a LISTING View). This is not at all what I described, Why does a LISTING have so much in common with an ITEM??? I suggest that it should not!!!
Please read again my initial goal. I want a much greater abstraction between items and listings (and believe that would be a big improvement). In my above question, A PART record (an item) does not need all the LISTING data. By truly separating the two, COMPLETELY DIFFERENT LISTINGS could be created from a SINGLE ITEM. One could experiment with different sales or marketing tactics, verbiage, etc, to see what sells best. Etc, But the way it is now in my Sixbit, I have many different “ITEMS” that are actually all the same item, simply because when creating them, I am actually creating a LISTING (it just isn’t SUBMITTED YET). And because I must do this to have the different listings (how else can I have different listings), the concept of Inventory Management is broken!!!

Does this make sense?

Put another way, I’m saying an ITEM would for the most part only have data associated with what it is (but not listing info), it’s source(s), costs, part numbers, amount in stock, etc. Of course at least some of this info would/could still be used i.e. UPC’s, but that should be optional (for competitive reasons I actually do not always want to use a UPC in my listing, since many of my buyers rarely search in that manner).
Then when you create LISTINGS you would FILL IN ALL THE REST, and could be done many times in different ways. But inventory would work more flexibly because they would all tie back to the ITEM.

You could/should still have listing templates.

[Owen Dessauer]

Since posting I read a bit more in the manual, but I still don’t know… I see there’s different views, for a list of inventory items, VS a list of listings, but part of my confusion stems from the fact that while the grid view is somewhat different (inventory item grid by default shows info such as SKU’s, etc. that listing does not), when you actually open an individual item from either view (to edit it), they both are almost identical. The Inventory item has SAVE buttons VS the listing item has the REVISE button, but basically everything else is the same. While that makes sense, in my scenario above an inventory item would be fairly different than a listing. Or at least more basic, with just info about the item, it’s source, costs, etc., while the LISTING view would have pretty much everything it currently does.

Does this make sense?

[Owen Dessauer]

+1 for Prestashop!

[Author]

Posts