| Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies| Author: | calsbricks  | | Posted: | Sep 16, 2017 05:37 | | Subject: | Re: Change to information held in Catalogue | | Viewed: | 26 times | | Topic: | Suggestions | |
| In Suggestions, brickbrowser writes:
| | In Suggestions, calsbricks writes:
| | As for the quite common comment that it works on BO so it should work here -
that is a logical statement if all things were equal, but unfortunately they
are not. The stores we have spoken to that are on both sites have tended to tell
us they only ever ship large letter style parcels on BO whereas they do both
parcels and large letters on BL. (I think this may be down to somewhat smaller
orders on BO - but cannot be 100% accurate with that)
|
We sell on BO and it works well enough. If dimensions for a particular part
aren't in the catalogue the system defaults to parcel rate. If it fits large
letter, a refund for difference is easy to send at time of shipping. It's
not a perfect system, but it's worth the minor inconvenience for the benefit
that instant checkout brings and as you said - we have to start somewhere.
I spend more time sending BL reminders to late/non payers on BL than I do sending
refunds to BO customers for overpaid P&P!
|
Interesting - we don't sell on BO but have kept our options open. Have you
looked at the preview site and how it works in comparison with BO? There is almost
a deafening silence here about the preview site, which, of course adds to people's
concerns. If it was all working wonderfully well I am sure we would hear from
those who have the time to test it as well as NL with the 'good new'
but nothing like that at the moment.
We maintain our thoughts that BL needs to at worst add the dimensions capability
to the catalogue (or at least define where it is getting its information from,
and at best allow members to add those dimensions. That doesn't ensure that
it will, work but it gives it a better chance.
In our 6 years as a store we have had a handful of buyers that we had to chase
for payment - it isn't a major issue for us - but we do understand others
position as well. mot sure if we have ever completed an NPB. We may be lucky
with that and of course it can change almost instantly. but that side of it is
not our main concern. Getting the shipping right first time every time, which
is what we do manually, is.
|
 |
| Author: | calsbricks | | Posted: | Sep 16, 2017 04:13 | | Subject: | Re: Change to information held in Catalogue | | Viewed: | 22 times | | Topic: | Suggestions | |
| In Suggestions, brickbrowser writes:
| | In Suggestions, calsbricks writes:
| | The Bricklink catalogue has the perfect base for this change but it is a question
of whether the developers feel they can do it with minimum effort. Each item
in the catalogue has a PCC as well as its mould or design id number associated
with it. The PCC code is Lego's element id and it is what they print in their
instructions.
There have been lots of comments both in and out of the forum concerning part
weights and how there is a variance between colours of the same part number.
We have also experienced this. The simple way to deal with this is to add a weight
field against the PCC in the catalogue. This would allow the system to hold the
individual weights for each colour part and could be used to more accurately
provide cart weights for instant checkout when it comes out of preview.
|
There are far greater weight discrepancies / inconsistencies in batches of packaging
materials (even from same supplier), than those attributed to mold or part colour
differences. Furthermore, one weight submitter's scales and measuring technique
probably differs from another's to the extent that the exercise is moot.
I doubt that would ever be an effective use of people's time.
|
You may be right - the only thing is surely we have to start somewhere - as I
said in an earlier reply the current generic system only works because sellers/stores
have been doing this manually - it would be nice to know how the instant checkout
is actually going to calculate which box type - and the associated tare it is
going to use - easy enough to set up a different delivery method for your boxes
and have the tare weight associated with that but as you say that can differ
between batches and manufacturers. Large letters come in envelopes as well as
boxes and small parcel boxes have an almost infinite number available in the
UK - all with different tares.
We would like to understand how their calculations are going to work so we can
determine whether it is worthwhile or not. That information is lacking.
As for the quite common comment that it works on BO so it should work here -
that is a logical statement if all things were equal, but unfortunately they
are not. The stores we have spoken to that are on both sites have tended to tell
us they only ever ship large letter style parcels on BO whereas they do both
parcels and large letters on BL. (I think this may be down to somewhat smaller
orders on BO - but cannot be 100% accurate with that)
Ignoring that completely a very thorough and detailed description of how ic is
intended to work on BL would be very helpful for all parties.
|
|
| Author: | calsbricks | | Posted: | Sep 15, 2017 13:35 | | Subject: | Re: Change to information held in Catalogue | | Viewed: | 25 times | | Topic: | Suggestions | |
| In Suggestions, qwertyboy writes:
| | So how do you suggest BL tackles the weight issues resulting from TLG mold changes?
Niek.
|
There is no one single way of achieving that - Lego themselves haven't resolved
this. The K boxes of parts that get shipped to all the Lego stores differ in
weight for the same part and the same colour. Our suggestion was meant to be
an improvement on what is currently in place as it is far too generic. The reason
it has worked for so long is down to the individual stores and how they handle
orders - they have done the package weights manually and of course that is actual
not calculated. That works - there can be no denial to that. Where a postal system
is based just on weight it is the perfect solution - pick the parts - put them
in a parcel that will hold them weigh it and price it. Ship it - if instant checkout
can do that - then go for it.
Where volume calculations are required then it requires more than just weight
- manually it is easy and most stores who have been around a while will do it
almost instantly. Whether software can do that or not remains to be seen and
please do not refer to the other site for this. BL is not BO and vice versa -
if they were the same, despite the problem being the same - then BL would have
had instant checkout years ago - they aren't and probably never will be.
So the only real solution is doing it manually (AI solution perhaps - I doubt
it but that is feasible).
As not a lot is known about how the preview site is actually doing it is difficult
to comment accurately on where BL is with the feature. There are stores who are
clamouring for it - there are stores who are sitting back and waiting and there
are stores who say - not interested - don't need it. Time will tell - as
and when it gets released.
|
|
| Author: | calsbricks | | Posted: | Sep 15, 2017 13:20 | | Subject: | Re: Change to information held in Catalogue | | Viewed: | 24 times | | Topic: | Suggestions | |
| In Suggestions, yorbrick writes:
| | | | - In 627 orders processed on the other site, with them having one weight for
each part no, we haven't experienced one single issue. Weight differences
are small, the likelihood of this "screwing up" auto-checkout is minimal, and
if it does make an err, the seller can chalk it up to the cost of doing business.
|
I agree this is not really necessary. It is a huge amount of data to collect
as well especially if the data is meant to be "more" accurate.
A while ago I looked at the weight distribution of 100 of the Krusty torsos:
They are all identical parts, same colour and print, but they vary in weight
slightly (at most in the second decimal place - they were all 1.27+-0.03 g) with
a distribution that is very similar to the distribution of weights of a random
sample of torsos (both printed and unprinted).
If people are then adding "accurate" data based on PCC number, I really hope
they don't get this data by weighing just one part. They should be getting
it from a large number of the same parts with the same PPC, and taking the average.
If I had picked a single torso, I could have claimed the weight was as low as
1.24g, if another as heavy as 1.30g. I made the average for my batch 1.274g,
in the catalogue it is 1.25g.
If I sold 100 of them, I might think it is as low as 124g total or it could be
as high as 130g. The catalogue tells me 125g. That 6g possible difference is
well within the buffer I allow when estimating the weight of packaging, tape,
etc.
It is interesting to compare these torsos:
1.28g 1.30g 1.28g 1.28g 1.27g
They are all orange torso assemblies with (almost same) print and vary only in
the different colour hands. Are the hands really responsible for the variation
in weights? If a hand is 0.09g (I think all colours currently have same weight)
making a pair 0.18g, then the variation of 0.03g in 0.18g seems very large. Whereas
a natural variation within the same colour torsos and arms seems more reasonable.
The weight may well depend on the location of the part in the mold / on the sprue
if multiple parts are molded at once even though all are given the same PPC.
|
A huge amount of data is also required for actual dimensions rather than studs
but none of that is impossible especially when you have a willing and capable
membership the size of Bricklink.
It is a complicated scenario really - no one solution can do it all but we could
do with improving the one we currently have.
Bricklink, we believe do not want to open the catalogue any further - it is their
single most valuable asset, so it is probably unlikely that this suggestion will
get anywhere near implementation. If it causes thought then it will achieve what
it was set out to do. Same part with mould variations but the same PCC as well
as variances on colours and composition (differing amounts of ABS etc all make
this a very, very complex arena.
Perhaps most importantly this does not prevent auto-checkout from working if
and when it comes out of preview and we didn't in any way suggest that, despite
earlier comments. Auto-checkout has already been built and this wasn't in
place - they have used some information from somewhere to determine weight and
volume? Not sure what nor how - that really hasn't been explained but I am
sure it will work for some - maybe not for all just yet, but only time will really
tell.
|
|
| Author: | calsbricks | | Posted: | Sep 15, 2017 12:23 | | Subject: | Re: Change to information held in Catalogue | | Viewed: | 27 times | | Topic: | Suggestions | |
| In Suggestions, calsbricks writes:
| | In Suggestions, qwertyboy writes:
| | In Suggestions, calsbricks writes:
| | The Bricklink catalogue has the perfect base for this change but it is a question
of whether the developers feel they can do it with minimum effort. Each item
in the catalogue has a PCC as well as its mould or design id number associated
with it. The PCC code is Lego's element id and it is what they print in their
instructions.
There have been lots of comments both in and out of the forum concerning part
weights and how there is a variance between colours of the same part number.
We have also experienced this. The simple way to deal with this is to add a weight
field against the PCC in the catalogue. This would allow the system to hold the
individual weights for each colour part and could be used to more accurately
provide cart weights for instant checkout when it comes out of preview.
|
I would vote no, for two reasons:
- In 627 orders processed on the other site, with them having one weight for
each part no, we haven't experienced one single issue. Weight differences
are small, the likelihood of this "screwing up" auto-checkout is minimal, and
if it does make an err, the seller can chalk it up to the cost of doing business.
- TLG is known to have made changes to their molds just to save a few cents
by requiring less ABS. These changes are done to parts that keep the exact same
PPC, and most times BL doesn't differentiate (think hollow versus solid pins
under a 1x4 brick for example). Those weight changes could actually be more significant
than the weight change for different colors. In effect, the weight-per-PPC will
almost always be an approximation, not the 100%-always-correct-weight for a PPC.
In short, I am convinced these weight differences are a non-issue for auto-checkout.
Experience proves this. I am sure others can verify this. Don't make things
more complex than they need to be.
Niek.
|
Thank you for your comment. Your opinion is noted, however I am not convinced
using the other site as a reference point is really relevant. The other site
also has proper dimensions for each part, which BL does not and as far as I can
tell from the brief look at the preview site the implementation here is different
to that over there. We sell lots and lots of bulk orders and a small difference
on an individual part can make a significant difference overall. As far as putting
that down to cost of business we will let you do that - it is of no interest
whatsoever to us. Maintaining margin/profitability is a key factor to a successful
business and taking all steps necessary to prevent additional costs is one small
part of that. With over 4000 order on this site we have no mistakes on postage
costs - once bl's implementation of instant checkout can be shown to provide
that reliability we will consider using it, however it is not of major importance
to us at the moment. There are far more important things to deal with.
|
Sorry I mis-read part of your original post. We are not trying to overly complicate
things - our suggestion, we believe, would help not hinder, and I do not believe
in any way did we say that this would prevent 'screwing up' with instant
checkout. We suggested it would help - not hinder.
As for your opinion, you are, of course entitled to it as we are to ours. You
have been around this site nearly as lone as we have so you will appreciate that
lots of people differ on what is needed, what is important etc. That is the way
life and business goes but it is more than essential to compare apples with apples
not apples and pears. In terms of coding this is a simple change and would take
any programmer less than a day to achieve it and it may, yes may help - it certainly
isn't going to hinder by any stretch of the imagination.
|
|
Next Page: 5 More | 10 More | 25 More | 50 More | 100 More
|
|
