Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies| Author: | calsbricks  | | Posted: | Dec 15, 2019 04:26 | | Subject: | Re: Parts Category Tree | | Viewed: | 45 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | In Catalog, StormChaser writes:
| | I get (for the most part) what mfav and calsbricks are proposing, but it remains
to be seen the level of investment TLG is willing to sink into the catalog (and,
considering their own websites, what the results would be). Provided that the
site chooses to retain the hierarchical system, I think we all agree it can definitely
be improved.
|
Nope. It won't be improved. It will be different. This is just rearranging
the content on shelves in the supermarket.
If the last couple deployments of "site improvements and updates" aren't
enough to dissuade you from tinkering with the site, well...I don't know
what to think. Kind of feels like the wheels are coming off the stagecoach and
the horses are headed for the ravine.
I sincerely appreciate the time, thought, enthusiasm, and commitment you have
for the catalog. Sincerely, I do. That said, I recommend letting stuff settle
down a bit. I'm afraid anything you cook up at this point may be wasted effort.
Stuff that was working two days ago may not be working now.
But it's your effort to waste, so I respect that.
|
So do I but mfav is 100% correct.
|
 |
| Author: | calsbricks | | Posted: | Dec 14, 2019 04:55 | | Subject: | Re: Parts Category Tree - Update | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, mfav writes:
| | it's impossible to project what disruptions there may or may not be.
|
It's not impossible to make educated guesses.
| | categories as we now recognize them is . . . not relational-database-thinking.
|
Could you provide an example of a large online database that is structured this
way so that I could understand it better?
| | Yes, yes. Many people find my ideas useful while objecting to me having ideas.
|
There seems to have been a miscommunication. I was saying I would object to
a system that required more effort and offered less certainty when performing
catalog/inventory work. That's probably not the system you were describing,
though - just how I imagined it would work. Again, I'd like to see an example
of the relational database you're proposing so that I could more fully understand
it.
|
To help you get a better idea of the desing and development of a relational database
you might want to look here.
https://www.opengatesw.net/
There is a free 30 day trial and it deals with the issue in simple and straightforward
terms for non-programmers. In fact with the free trial you can design a catalogue
and see how it breaks it up and relates.
|
|
| Author: | calsbricks | | Posted: | Dec 12, 2019 17:10 | | Subject: | Re: Add Search Options to Advanced Catalog Search | | Viewed: | 30 times | | Topic: | Suggestions | |
|
| In Suggestions, StormChaser writes:
| | I need the ability to select from the following unavailable options as checkboxes
on the Advanced Catalog Search page:
Items Inventoried as Regular
Items Inventoried as Counterpart
Items Inventoried as Extra
Items Inventoried as Alternate
Thank you.
|
definitely agree especially counter parts
|
|
| Author: | calsbricks | | Posted: | Dec 11, 2019 08:23 | | Subject: | Re: Parts Category Tree | | Viewed: | 40 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, calsbricks writes:
| | […]
It is almost like waiting with baited breath.
Roll on New Years.
|
2020: SuperPlasticCorp contracts Accidenture to audit BL’s systems and databases.
2023: Accidenture’s multi-million-euros 632-PowerBullet-slides report finally
delivered.
It boils down to: “Oh my god! It’s full of noddles!”
2025: SuperPlasticCorp contracts Debacle to modernize BL’s database.
2038: Another year, another billion sunk into the still not delivered Debacle
system.
Old BL is still running, somewhat, for people who kept their 2010 PCs and
like 500 errors.
(Names have been changed to protect the victims’ families.)
|
Good grief - I might not make it then 
Roll on the fountain of youth - or something similar. 
|
|
| Author: | calsbricks | | Posted: | Dec 11, 2019 06:49 | | Subject: | Re: Parts Category Tree | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, bje writes:
| | In Catalog, mfav writes:
| | There seems to be some conflation or confusion regarding the data and the database
structure and how those things relate.
The structure is how it's built and the data is what's within the structure.
Rebuilding the data from the ground up is not necessary. Some of the data is
fine as is and simply would need to be migrated or an existing field related
to a new table and field.
There's no other way to increase functionality or make operations more efficient
without some fundamental change to the underlying structure.
There is no way to create substantive efficiencies within the existing framework.
You have 256 deck chairs and a 900 x 900 foot deck. You can rearrange the chairs
all you want, but it's never going to be more than 256 deck chairs. The arrangement
that makes chair #125 easier to find may make chair #93 harder to find. Everything
is a trade-off.
There is no quick and there is no easy.
If you want to undertake "reorganizing" or "cleaning" the data...for example,
examine all the minifig heads. Rewrite all the descriptions in a uniform manner...start
from top to bottom...hair, eyebrows, eyes, nose, mouth, whiskers, scars, blemishes,
wrinkles, and so on...then that will lead to an incremental improvement in the
data. Functionality isn't going to be improved without a change in the available
tools. I often state that you can cut down a tree with a spoon, but it's
not the best tool for the job. It will get done, but with great effort and it
will take a long time. Invest in an appropriate tool, like a chainsaw, and the
effort decreases, the time decreases, and the satisfaction increases.
Your argument seems to be for changing one spoon for another.
Additional categories won't solve anything. At this point, this is the difference
between sorting mixed pieces of lego in 230 boxes or 240 boxes. You're just
rearranging the deck chairs. Again. When the supermarket redesigns the floor
plan and product location within the store you've been shopping in for 10
years, does that help you find the chicken soup?
Not that I expect you to go through the exercise, but here http://v4ei.com/mini-fig-ure-outer/index.php
is the custom search instruction thing I wrote. It will take about 2 or 3 hours
to complete if you want to do it. Anyway, going through the source information
(skip creating the html if you want) will kind of lay bare the inconsistencies
within the current data. You'll find obvious typos. You'll find similar
items described similarly, but with differing sequences...like items described
dissimilarly...dissimilar items described similarly...nothing you wouldn't
expect when the data is crowd sourced over a long period of time. Some swaths
of data are really good. There has been effort put into the data, but not always
of consistent quality or consistent methodology.
Looking at a dataset as a whole, and not piecemeal, can be quite enlightening.
Do we need any listing that contains the phrase "without such-and-such"? Is it
helpful to list what something doesn't contain? Fish without bicycle spokes.
Butterfly without steel beams.
So, to answer your question, yes and no. I'm making the argument for additional
data. I'm making the argument for additional database structure. I'm
making the argument for thinking things through thoroughly before starting to
build something.
Right now there's no way to add deck chairs to our deck. We need another
deck. And a way to get chairs from one deck to another. And ways to get users
from deck to deck and chair to chair.
If you decide to do the custom search creation, all of it, I think by the end
of that exercise it should provide enlightenment as to the limitations of what
can be done within the current structure and the quality of the current dataset.
Those things should be able to inform your thinking on how to better conceive
a plan for improvement within the current limitations.
Read what Bill says in the light of Bill actually knows what the f--- he's
talking about instead of Bill's a cranky old man. Bill is a cranky old man
because he actually does know what the f--- he's talking about. When
you fully understand what Bill is saying, at that point you'll understand
the complexity of the issue. You seem to think the problem is lack of simple
programming. It's not. It's waaaaaay deeper than that.
Discussion at this point isn't leading to any solutions. I currently find
no value in the obsessive hand-wringing, worry-warting, prognostication of doom,
hopes, wishes, unfulfilled dreams, and ideas of improvement around here. Be patient
and wait for Superplasticorp to take over the Titanic and see where we are in
a month or two.
If you need to do something because you need to do something, I'd suggest
creating a wish list to present to Superplasticorp. They say they want to engage
with the AFOLs. Well, here's your opportunity. What's most important?
Is it more data that's definitive and easily accessible? Is it greater selection
of trans-neon-green elements? History? Factory tours? Let Superplasticorp know
what they can do to facilitate their selling you more stuff...they'll listen
to that.
Improvements of the type often discussed here on the board will take years
to implement, if that's even an option. It could be that Superplasticorp
leaves the current BL management in place and things carry on in the lopsided
manner they have been for the last several years. Or Superplasticorp could actually
value the AFOL community, engage with the community, cooperate with the community,
respect the community, find value in the knowledge the community has to offer,
and not expect those with the knowledge and who actually provide the content
to work for free versus working for mutual benefit. Time will tell. Maybe.
I'm going to shut up now.
|
No need to shut up. This goes the way it always goes as we are always trying
to find WHAT must be done with the data, as opposed to WHERE the data must be.
As someone who has worked in an actual library and made a top to bottom study
of the Dewey, AL and Coleridge's systems, I can only say +1 000 to everything
both you and Bill wrote. And I'll add a tail piece - if you do not document
a la Dewey how you are supposed to classify, then nothing will come of it. You
can tag, describe, redesign all you want but if there is no consistent documented
method of adding a minifigure head with its correct description, then mistakes
will appear again, meaning all of the work preceding that single mistake is factually
useless.
There is a reason some very clever people spent many years designing library
catalogue systems such as Dewey. There is also a reason the best accounting systems,
whether an open source ERP or a shelf package, all start with the design of the
chart of accounts - it is the basic start as to WHERE the data must go, not what
must be done with it. I have consistently designed charts of accounts to be useful
across the board - whether it is a micro business or a group of companies, the
basic chart design comes down to knowing upfront where that data must go. Even
in the old days of HAPAS, it only took for 1 first year clerk with an allocation
error as a result of bad documentation to screw up an entire chart in use for
3 years and from there the P&L and the Balance sheet. All of the discussions
on here, including Bill's discussion some time ago about the catalogue, end
up with what must be done with the data. In a well designed system, the data
is available anywhere for anything because it is known how it is classified.
Thus, a user can extract his sales data for individual colours of individual
parts only when the data is consistently available across the entire platform.
At present you have to search for cushions in order to find the chairs and do
not ask for different colours of chairs
The catalogue does not IMO need another band aid over the festering and pus filled
wound of its poorly designed descriptors and poorly documented and inconsistent
application of catalogue entries. It needs corrective surgery, much like everything
else. Time will tell if the investment required will be made. At present though,
there is still not enough information to make that call. All I see is that searching
the catalogue, even with the best of tools, remains for many users a difficulty.
IF the present systems is deemed to be the way forward, then by all means bring
in the tags (which was supposed to have been done sometime this year if I remember
correctly) and resort categories. It will be fun, but not productive. TLG might
want suggestions and make improvements, then again they might look at the scope
of what needs to be done and decide that plasters is maybe a bit cheaper and
more readily available. After all - adding tags and reclassifying will be done
with volunteers, redesign has to be done with (paid) employees. Some things require
money and that is the measure of the commitment. TLG's commitment remains
to be measured - we know the level of commitment of volunteers already.
|
Hi Jean
I have spent the better part of my life designing and implementing charts of
accounts - some for the UK's largest organisations both commercial and charitable.
It is a complex job and needs a level of understanding which Dan and Eric will
have had but as there wasn't the quality documentation that was needed the
current development team will have found difficult - hence their reluctance to
delve into the 'Spaghetti code' they were left.
You need to understand what is required at the end of it as well as how to use
it for the purposes of data collection
Hence my earlier comments about system analysts doing a system design job before
code gets written.
Time will tell what Lego are prepared to put into the site as well as where the
resources for this need to come from. There is a tremendous amount of knowledge
and talent in the membership and this time it needs to be used as opposed to
being overridden or ignored. .
It is almost like waiting with baited breath.
Roll on New Years.
|
|
| Author: | calsbricks | | Posted: | Dec 11, 2019 04:00 | | Subject: | Re: Parts Category Tree | | Viewed: | 51 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | There seems to be some conflation or confusion regarding the data and the database
structure and how those things relate.
The structure is how it's built and the data is what's within the structure.
Rebuilding the data from the ground up is not necessary. Some of the data is
fine as is and simply would need to be migrated or an existing field related
to a new table and field.
There's no other way to increase functionality or make operations more efficient
without some fundamental change to the underlying structure.
There is no way to create substantive efficiencies within the existing framework.
You have 256 deck chairs and a 900 x 900 foot deck. You can rearrange the chairs
all you want, but it's never going to be more than 256 deck chairs. The arrangement
that makes chair #125 easier to find may make chair #93 harder to find. Everything
is a trade-off.
There is no quick and there is no easy.
If you want to undertake "reorganizing" or "cleaning" the data...for example,
examine all the minifig heads. Rewrite all the descriptions in a uniform manner...start
from top to bottom...hair, eyebrows, eyes, nose, mouth, whiskers, scars, blemishes,
wrinkles, and so on...then that will lead to an incremental improvement in the
data. Functionality isn't going to be improved without a change in the available
tools. I often state that you can cut down a tree with a spoon, but it's
not the best tool for the job. It will get done, but with great effort and it
will take a long time. Invest in an appropriate tool, like a chainsaw, and the
effort decreases, the time decreases, and the satisfaction increases.
Your argument seems to be for changing one spoon for another.
Additional categories won't solve anything. At this point, this is the difference
between sorting mixed pieces of lego in 230 boxes or 240 boxes. You're just
rearranging the deck chairs. Again. When the supermarket redesigns the floor
plan and product location within the store you've been shopping in for 10
years, does that help you find the chicken soup?
Not that I expect you to go through the exercise, but here http://v4ei.com/mini-fig-ure-outer/index.php
is the custom search instruction thing I wrote. It will take about 2 or 3 hours
to complete if you want to do it. Anyway, going through the source information
(skip creating the html if you want) will kind of lay bare the inconsistencies
within the current data. You'll find obvious typos. You'll find similar
items described similarly, but with differing sequences...like items described
dissimilarly...dissimilar items described similarly...nothing you wouldn't
expect when the data is crowd sourced over a long period of time. Some swaths
of data are really good. There has been effort put into the data, but not always
of consistent quality or consistent methodology.
Looking at a dataset as a whole, and not piecemeal, can be quite enlightening.
Do we need any listing that contains the phrase "without such-and-such"? Is it
helpful to list what something doesn't contain? Fish without bicycle spokes.
Butterfly without steel beams.
So, to answer your question, yes and no. I'm making the argument for additional
data. I'm making the argument for additional database structure. I'm
making the argument for thinking things through thoroughly before starting to
build something.
Right now there's no way to add deck chairs to our deck. We need another
deck. And a way to get chairs from one deck to another. And ways to get users
from deck to deck and chair to chair.
If you decide to do the custom search creation, all of it, I think by the end
of that exercise it should provide enlightenment as to the limitations of what
can be done within the current structure and the quality of the current dataset.
Those things should be able to inform your thinking on how to better conceive
a plan for improvement within the current limitations.
Read what Bill says in the light of Bill actually knows what the f--- he's
talking about instead of Bill's a cranky old man. Bill is a cranky old man
because he actually does know what the f--- he's talking about. When
you fully understand what Bill is saying, at that point you'll understand
the complexity of the issue. You seem to think the problem is lack of simple
programming. It's not. It's waaaaaay deeper than that.
|
Cranky old man ??? Hmm - Just because I want it done correctly?
| |
Discussion at this point isn't leading to any solutions. I currently find
no value in the obsessive hand-wringing, worry-warting, prognostication of doom,
hopes, wishes, unfulfilled dreams, and ideas of improvement around here. Be patient
and wait for Superplasticorp to take over the Titanic and see where we are in
a month or two.
If you need to do something because you need to do something, I'd suggest
creating a wish list to present to Superplasticorp. They say they want to engage
with the AFOLs. Well, here's your opportunity. What's most important?
Is it more data that's definitive and easily accessible? Is it greater selection
of trans-neon-green elements? History? Factory tours? Let Superplasticorp know
what they can do to facilitate their selling you more stuff...they'll listen
to that.
Improvements of the type often discussed here on the board will take years
to implement, if that's even an option. It could be that Superplasticorp
leaves the current BL management in place and things carry on in the lopsided
manner they have been for the last several years. Or Superplasticorp could actually
value the AFOL community, engage with the community, cooperate with the community,
respect the community, find value in the knowledge the community has to offer,
and not expect those with the knowledge and who actually provide the content
to work for free versus working for mutual benefit. Time will tell. Maybe.
I'm going to shut up now.
|
|
|
| Author: | calsbricks | | Posted: | Dec 10, 2019 11:48 | | Subject: | Re: Parts Category Tree | | Viewed: | 48 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | The category tree is not really the issue.
There needs to be an understanding of the difference between classification and
identification.
Browsing probably takes place against classification.
Identification should not be limited to classification. Identification should
take place against element attributes.
The existing database framework is inadequate to meet what is desired.
The underlying database needs many additional tables and fields to store specific
relevant information.
Classification of any single piece should not be restricted to a single category.
For example
should be categorized as brick and wedge
should be categorized as plate and wedge
should be categorized as panel, window (if transparent), wall element,
windscreen...and perhaps other things.
Identification should be effected against several different and some as-yet-non-existant
fields with specific criteria.
Instead of trying to identify by the contents of the q (title or name) field,
which is the only option at the moment, additional fields should be created that
contain specific attributes of an element: how many studs, how many sides with
studs, how many sides with stud receptors, how many sides without studs, symmetrical
or asymmetrical shape, general shape (rectangular, circular, triangular, rhomboid,
irregular, etc.), protruberances and sockets (axle holders, holes, clips, bars,
pins), and so on.
All this needs to be paired with an illustrated glossary of terms.
After the foundation is laid, then the data needs to be populated in a regular
manner which adheres to strict conditions for consistency. In the instances where
a field can contain discrete "checkboxable" items, that should be simple. Where
a field is "open" criteria should be set in place such that the data is entered
in a logical and repeatable manner.
The much discussed "tag system" is nothing more than an additional name/title
field, perhaps with a character limit in excess of 256 characters, but is susceptible
to the same problems as the current name/title field. It's just more of the
same thing as exists now, so it will fail/succeed/operate in the same manner
as the current name/title field, just in a second field. If the "solution" of
the "tag system" is effected, then you're still going to have data inconsistency...some
items will have value A in field one and some items will have value A in field
two. So that ends up compounding the frustration instead of alleviating it.
Colors should not necessarily be limited to any one institution's nomenclature.
The colors are indexed by an integer value. Any one value can carry multiple
labels. Thus XXX can be both Medium Stone Gray and Light Bluish Gray.
Ultimately this means something like a 10x increase in data (or more), additional
fields, additional forms for both discovery and data entry, and more.
tl;dr
A glossary needs to be in place describing all pertinent aspects and glossary
terms should be used in the datasets.
The underlying database needs to be 1) expanded and 2) available for modification
on a periodic basis as needed.
The data needs to be more, better, and consistent within a field.
It's going to be a lot of work.
|
Hiya
Nice post and quite accurate. Most modern day research into tagging v hierarchical
systems show that neither are quicker and there are pluses and minuses for both
– so the best recommendation is to incorporate both in your database design.
Lots of articles about best practices for this.
What it needs is a couple of senior analysts to sit down and design this properly
possibly in conjunction with a number of experts that exist within the community.
From there hand it to the programmers and let them write it – test it thoroughly,
correct it – test it again etc. Then release it fully documented. Lots and lots
of the core data that is needed is already in the database – but yes it does
need work eliminating, where possible, inconsistencies.
Analysts can be expensive people but quite honestly they are worth their weight
in gold. Testing is the same – whatever length of time you spend on it up front
is more than compensated for in the less time fixing it when it is supposedly
‘live’. And if it is well documented less time in supporting it.
Modern day software should have lots and lots of parameters built in so that
individuals do not lose features that they utilize. Major accounting software
today – products like Navision, Axapta, Great Plains, SAP + others are heavily
customizable within the organisation that bought the product. Oracle are the
same – that is where they make the majority of their money from consultancy to
set it up the way you wish to use it.
Yes it is lots of work, or at least it can be but if it had been started 6 years
ago maybe we wouldn’t be having this conversation today and time would not have
been spent on tangent developments.
Still lets see what Lego has to say about this as and when they begin exerting
influence/decisions on the site. That isn’t that far away, at least from early
comments about completing by the end of 2019.
|
|
| Author: | calsbricks | | Posted: | Dec 9, 2019 06:55 | | Subject: | Re: Parts Category Tree | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | In Catalog, calsbricks writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
This is a good idea and follows our Family level above categories which we put
into the forum a very long time ago. but whether anything will ever get done
about it remains to be seen. Since your departure and recent return nothing much
has happened on the development side and with the Lego acquisition due shortly
it may be some time before anything actually does. We have done this offline
with our own database system.
It does work and is not clumsy nor long winded - after all unless your are really
into the catalogue you probably don't even know that much about all the sub
menus. A 'soccer mom' might want a star wars set for her son but will
she know which one of the sub menus it is under - not likely - that is for collectors
and enthusiasts.
|
I think it needs a complete rethink and a more modern idea - where something
can be more than one thing. So for example, I'd like to see one category
called "Bricks", and inside this, there can be all the existing types of bricks
categories. This would allow someone to search just through the "Bricks" parent
category but all of them at once. However, there are also technic bricks, which
don't get called "Bricks, technic", rather they are "Technic, bricks". They
are also bricks, so should be searchable under a "Bricks" parent, but also under
a "Technic" parent too.
|
That is pretty much the way our system works. We decide what the families are
(level above categories) and what goes in them. All of our analysis is done by
family but if we want to take it lower we can. We have bricks, Minifigs, Other,
Plates, Sets (Small polybags), Slopes, Technic and tiles. Other is obviously
the catch all for items that don't fall into any of the others. It does work
and it makes it very easy for us to see what is moving and what isn't
We think the level above categories should be user definable as not everyone
will want to combine the same things. It isn't that complicated to program
and lots of the big high end inventory management systems have it built in, so
there is excellent code examples out there to accommodate.
I think the only real thing we can say is - no harm in dreaming.
|
|
| Author: | calsbricks | | Posted: | Dec 9, 2019 06:17 | | Subject: | Re: Parts Category Tree | | Viewed: | 64 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
This is a good idea and follows our Family level above categories which we put
into the forum a very long time ago. but whether anything will ever get done
about it remains to be seen. Since your departure and recent return nothing much
has happened on the development side and with the Lego acquisition due shortly
it may be some time before anything actually does. We have done this offline
with our own database system.
It does work and is not clumsy nor long winded - after all unless your are really
into the catalogue you probably don't even know that much about all the sub
menus. A 'soccer mom' might want a star wars set for her son but will
she know which one of the sub menus it is under - not likely - that is for collectors
and enthusiasts.
|
|
| Author: | calsbricks | | Posted: | Dec 4, 2019 07:31 | | Subject: | Re: Show the set from which a piece was ordered. | | Viewed: | 38 times | | Topic: | Suggestions | |
|
| In Suggestions, Lilbeastie22 writes:
| | Please show in the order details, the set from which pieces were ordered. As
a seller, this would be hugely helpful in finding the ordered pieces and sending
the order within a reasonable time.
|
Voted no as this really isn't possible. Pieces can and do come from a multitude
of sets so which one it comes from cannot be isolated except in rare circumstances.
|
Next Page: 5 More | 10 More | 25 More | 50 More | 100 More
|
United Kingdom, England
