|
 |
| | | Author: | calsbricks  | | Posted: | May 27, 2019 05:50 | | Subject: | Helpful but .... | | Viewed: | 233 times | | Topic: | Suggestions | | Status: | Open | | Vote: | [Yes|No] | |
|
| Firstly let me say that we know suggestions are not being implemented and according
to MP no work is being done on the classic site however this is a small request
which doesn't require huge amounts of development time and would make life
a bit easier.
Currently the method of manually adding inventory is long winded, provides no
audit trail of what has been done and at best is clumsy.
We use Brickstock for most of our updates to our store. It is much easier, quicker
and provides us with a complete audit trail - the only real snag is what happens
when the file gets to Bricklink, The verify screen drops off the Bricklink part
number for some reason so we are left with an audit trail which, when variants
are involved, isn't really all that helpful, although to be fair we have
used this for some time.
Simply placing the bricklink product code on the verify screen would be very
helpful and this is not a major programming issue. At the same time give us a
print button to print that screen Using the print command from the browser doesn't
work well with the page setup falling short of what is needed.
This is a simple matter and could be resolved in minimal time - please implement.
|
|
|
| | | | | |
| | | | | Author: | Stuart9 | | Posted: | May 27, 2019 05:55 | | Subject: | Re: Helpful but .... | | Viewed: | 36 times | | Topic: | Suggestions | |
|
| +1
In Suggestions, calsbricks writes:
| | Firstly let me say that we know suggestions are not being implemented and according
to MP no work is being done on the classic site however this is a small request
which doesn't require huge amounts of development time and would make life
a bit easier.
Currently the method of manually adding inventory is long winded, provides no
audit trail of what has been done and at best is clumsy.
We use Brickstock for most of our updates to our store. It is much easier, quicker
and provides us with a complete audit trail - the only real snag is what happens
when the file gets to Bricklink, The verify screen drops off the Bricklink part
number for some reason so we are left with an audit trail which, when variants
are involved, isn't really all that helpful, although to be fair we have
used this for some time.
Simply placing the bricklink product code on the verify screen would be very
helpful and this is not a major programming issue. At the same time give us a
print button to print that screen Using the print command from the browser doesn't
work well with the page setup falling short of what is needed.
This is a simple matter and could be resolved in minimal time - please implement.
|
|
|
|
| | | | | |
| | | | | Author: | uvt203 | | Posted: | May 27, 2019 06:00 | | Subject: | Re: Helpful but .... | | Viewed: | 35 times | | Topic: | Suggestions | |
|
| Voted YES - it's a really good proposal for a simple improvement.
/Asger
In Suggestions, calsbricks writes:
| | Firstly let me say that we know suggestions are not being implemented and according
to MP no work is being done on the classic site however this is a small request
which doesn't require huge amounts of development time and would make life
a bit easier.
Currently the method of manually adding inventory is long winded, provides no
audit trail of what has been done and at best is clumsy.
We use Brickstock for most of our updates to our store. It is much easier, quicker
and provides us with a complete audit trail - the only real snag is what happens
when the file gets to Bricklink, The verify screen drops off the Bricklink part
number for some reason so we are left with an audit trail which, when variants
are involved, isn't really all that helpful, although to be fair we have
used this for some time.
Simply placing the bricklink product code on the verify screen would be very
helpful and this is not a major programming issue. At the same time give us a
print button to print that screen Using the print command from the browser doesn't
work well with the page setup falling short of what is needed.
This is a simple matter and could be resolved in minimal time - please implement.
|
|
|
|
| | | | | |
| | | | | Author: | bje | | Posted: | May 27, 2019 07:51 | | Subject: | Re: Helpful but .... | | Viewed: | 61 times | | Topic: | Suggestions | |
|
| I voted yes, but I am not entirely sure this would be as simple as is believed
on first glance.
The reason that part number gets dropped is because in BL world, that part number
is not something used to differentiate inventory items. What you are adding are
lots, and not individual stock items or even different colours of an item. This
is the reason you cannot cost 2 different batches of the same inventory item
with different cost prices added at two different dates on BL, as you are merely
adding to existing lots, and not adding a new batch which must be reported on
separately. Showing the part number when importing would probably have to mean
that the lot would need an additional characteristic added to it to move it into
the realm of actual inventory of parts and not lots.
My information may be a tad wrong, but from experience, lots (that is your inventory
items) are differentiated only on the comments and the condition, nothing else.
It is, sadly, a throwback to auctioneer inventory where the lot is costed as
a unit and fees are earned on the unit. To get to a basis of project costing
or at the very least some average costing for your inventory items as actual
items and not lots, would possibly take a redesign of the entire inventory handling.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | calsbricks | | Posted: | May 27, 2019 08:42 | | Subject: | Re: Helpful but .... | | Viewed: | 47 times | | Topic: | Suggestions | |
|
| In Suggestions, bje writes:
| | I voted yes, but I am not entirely sure this would be as simple as is believed
on first glance.
The reason that part number gets dropped is because in BL world, that part number
is not something used to differentiate inventory items. What you are adding are
lots, and not individual stock items or even different colours of an item. This
is the reason you cannot cost 2 different batches of the same inventory item
with different cost prices added at two different dates on BL, as you are merely
adding to existing lots, and not adding a new batch which must be reported on
separately. Showing the part number when importing would probably have to mean
that the lot would need an additional characteristic added to it to move it into
the realm of actual inventory of parts and not lots.
My information may be a tad wrong, but from experience, lots (that is your inventory
items) are differentiated only on the comments and the condition, nothing else.
It is, sadly, a throwback to auctioneer inventory where the lot is costed as
a unit and fees are earned on the unit. To get to a basis of project costing
or at the very least some average costing for your inventory items as actual
items and not lots, would possibly take a redesign of the entire inventory handling.
|
Thanks for adding your comments/thoughts to this. I am not convinced they should
apply, though. The xml file to the mass upload feature includes the part no -
if it is in that file it can be displayed on the verify page. I understand the
lot concept but as Bricklink does not really have an inventory management system
built in we believe picking this field up from the xml file that it receives
should not be a problem.
Having said that as the code is referred to as spaghetti by the development team
they may not understand how to do this.
Speaking of average costing that would be a blessing - but again little chance
of that as BL move towards no stores, no inventory just Amazon/Ebay esque model.
We won't be involved with that as, when and if it ever appears, and from
the comments we have had from others neither will an awful lot more.
Brickowl also doesn't have a proper inventory management system and although
handling Lego items isn't easy - Lego have an in house modified system -
they do not have to deal with condition. Here you have part no colour and condition
to cope with.
A fresh design would be ideal but development investment is not high on the priority
list, it appears.
If you look at a sample of a small file we did yesterday, in-between server 500
errors, you will see what I mean
95345
88
18
P
3
0.270
U
The lot number is checked based on item no, colour and condition and if there
is a match it adds to that lot; if not it creates a new lot and adds that but
it still knows the item no. Displaying it, ther4efore is a couple of lines of
code to be added (according to my head of development).
Thanks again for your comments and for voting for the suggestion.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | qwertyboy | | Posted: | May 27, 2019 10:51 | | Subject: | Re: Helpful but .... | | Viewed: | 35 times | | Topic: | Suggestions | |
|
| In Suggestions, bje writes:
| | I voted yes, but I am not entirely sure this would be as simple as is believed
on first glance.
The reason that part number gets dropped is because in BL world, that part number
is not something used to differentiate inventory items.
|
That would be a valid argument, if BL weren't already showing the item description
on that exact same screen. If the program is able to show the description (which
is a lookup into the items table), it already knows the part number (or at least
grab it from the same table the description came from).
So yes, it is a request easily implemented.
Niek.
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | calsbricks | | Posted: | May 27, 2019 10:54 | | Subject: | Re: Helpful but .... | | Viewed: | 29 times | | Topic: | Suggestions | |
|
| In Suggestions, qwertyboy writes:
| | In Suggestions, bje writes:
| | I voted yes, but I am not entirely sure this would be as simple as is believed
on first glance.
The reason that part number gets dropped is because in BL world, that part number
is not something used to differentiate inventory items.
|
That would be a valid argument, if BL weren't already showing the item description
on that exact same screen. If the program is able to show the description (which
is a lookup into the items table), it already knows the part number (or at least
grab it from the same table the description came from).
So yes, it is a request easily implemented.
Niek.
|
Thanks Niek
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | calsbricks | | Posted: | May 27, 2019 11:51 | | Subject: | Re: Helpful but .... | | Viewed: | 28 times | | Topic: | Suggestions | |
|
| In Suggestions, qwertyboy writes:
| | In Suggestions, bje writes:
| | I voted yes, but I am not entirely sure this would be as simple as is believed
on first glance.
The reason that part number gets dropped is because in BL world, that part number
is not something used to differentiate inventory items.
|
That would be a valid argument, if BL weren't already showing the item description
on that exact same screen. If the program is able to show the description (which
is a lookup into the items table), it already knows the part number (or at least
grab it from the same table the description came from).
So yes, it is a request easily implemented.
Niek.
|
Thanks Niek
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | bje | | Posted: | May 27, 2019 12:02 | | Subject: | Re: Helpful but .... | | Viewed: | 34 times | | Topic: | Suggestions | |
|
| In Suggestions, qwertyboy writes:
| | In Suggestions, bje writes:
| | I voted yes, but I am not entirely sure this would be as simple as is believed
on first glance.
The reason that part number gets dropped is because in BL world, that part number
is not something used to differentiate inventory items.
|
That would be a valid argument, if BL weren't already showing the item description
on that exact same screen. If the program is able to show the description (which
is a lookup into the items table), it already knows the part number (or at least
grab it from the same table the description came from).
So yes, it is a request easily implemented.
Niek.
|
But the item number is optionally included, it is not even a required field.
And from what I can see, only the category field ties to the item number in the
catalog. As a matter of fact, you can list everything in your store without a
single catalog item number, so long as you have the category and comments fields,
mass uploads will work. We sell lots, not catalog items.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | calsbricks | | Posted: | May 27, 2019 12:40 | | Subject: | Re: Helpful but .... | | Viewed: | 30 times | | Topic: | Suggestions | |
|
| In Suggestions, bje writes:
| | In Suggestions, qwertyboy writes:
| | In Suggestions, bje writes:
| | I voted yes, but I am not entirely sure this would be as simple as is believed
on first glance.
The reason that part number gets dropped is because in BL world, that part number
is not something used to differentiate inventory items.
|
That would be a valid argument, if BL weren't already showing the item description
on that exact same screen. If the program is able to show the description (which
is a lookup into the items table), it already knows the part number (or at least
grab it from the same table the description came from).
So yes, it is a request easily implemented.
Niek.
|
But the item number is optionally included, it is not even a required field.
And from what I can see, only the category field ties to the item number in the
catalog. As a matter of fact, you can list everything in your store without a
single catalog item number, so long as you have the category and comments fields,
mass uploads will work. We sell lots, not catalog items.
|
Optionally included where? It is a mandatory field out of Brickstock for an xml
update inventory. The only time lot numbers come into it are if you wish to update
existing inventory. Niek is right - the system is doing a lookup to pick up the
description so it can look up the product id quite easily. Yes according to Bricklink
we sell lots but according to reality we sell items which make up lots. The fact
that this platform has no real inventory system available to stores does not
mean we cannot look at elements of the catalogue when we are bringing in data.
A schema would clearly e4stablish this - Product ID cannot be duplicated and
therefore can be read easily when a lookup to that table is done.
If I modify the xml file we created when we export xml to Clipboard - the mass
upload will not work - we get an error message that the file format is invalid.
If I put the itemid back in it works.
Whilst I am confident nothing will happen over this suggestion it would be welcome
for BL to comment.
Admin ?
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | bje | | Posted: | May 27, 2019 12:57 | | Subject: | Re: Helpful but .... | | Viewed: | 33 times | | Topic: | Suggestions | |
|
| In Suggestions, calsbricks writes:
| |
Optionally included where?
|
https://www.bricklink.com/help.asp?helpID=22
| | It is a mandatory field out of Brickstock for an xml
update inventory. The only time lot numbers come into it are if you wish to update
existing inventory. Niek is right - the system is doing a lookup to pick up the
description so it can look up the product id quite easily.
|
It performs a lookup on the category only, nothing else.
| | Yes according to Bricklink
we sell lots but according to reality we sell items which make up lots.
|
In reality there has never been a single catalog item sold on BL Mind blowing
I know, but download your orders with full detail - there is no such thing in
the catalog as a "Red Technic, Brick 1 x 14 with Holes" as a separate catalog
item, yet that is the only description on your invoice.
| | The fact
that this platform has no real inventory system available to stores does not
mean we cannot look at elements of the catalogue when we are bringing in data.
A schema would clearly e4stablish this - Product ID cannot be duplicated and
therefore can be read easily when a lookup to that table is done.
|
What do you mean by Product ID - the lot ID or the catalog item ID? These are
two different things altogether and bear no relation to each other.
| |
If I modify the xml file we created when we export xml to Clipboard - the mass
upload will not work - we get an error message that the file format is invalid.
If I put the itemid back in it works.
|
Export with a comment and delete the item field again, it will work. You could
conceivably list your entire inventory without a single catalog item id.
| |
Whilst I am confident nothing will happen over this suggestion it would be welcome
for BL to comment.
Admin ?
|
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | calsbricks | | Posted: | May 27, 2019 13:39 | | Subject: | Re: Helpful but .... | | Viewed: | 48 times | | Topic: | Suggestions | |
|
| In Suggestions, bje writes:
That is not how it works when we upload our xml file from Briokstock. The file
has the category number in it but leads with the itemid.
Knowing how the tables work and what is in them would be helpful to get this
sorted, but suffice to say that when the xml data comes along Bricklink has to
make up its mind what to do with it and it cannot do that without the itemid
e.g. part no. It requires part no, colour and condition to see if the data submitted
is a new lot or matches an existing lot. So the item id is used somewhere - it
cannot just work from the category id.
| | | | It is a mandatory field out of Brickstock for an xml
update inventory. The only time lot numbers come into it are if you wish to update
existing inventory. Niek is right - the system is doing a lookup to pick up the
description so it can look up the product id quite easily.
|
It performs a lookup on the category only, nothing else.
|
Sorry that cannot work - the category could have hundreds of items in it so how
is it going to know which item to either add or update? It simply isn't logical.
| |
| | Yes according to Bricklink
we sell lots but according to reality we sell items which make up lots.
|
In reality there has never been a single catalog item sold on BL Mind blowing
I know, but download your orders with full detail - there is no such thing in
the catalog as a "Red Technic, Brick 1 x 14 with Holes" as a separate catalog
item, yet that is the only description on your invoice.
|
The catalogue is made up of many related tables - the order detail download is
useless as far as we are concerned and has been set up by Bricklink to offer
info they wish to offer not the info we need.
| |
| | The fact
that this platform has no real inventory system available to stores does not
mean we cannot look at elements of the catalogue when we are bringing in data.
A schema would clearly establish this - Product ID cannot be duplicated and
therefore can be read easily when a lookup to that table is done.
|
What do you mean by Product ID - the lot ID or the catalog item ID? These are
two different things altogether and bear no relation to each other.
|
The lot id is a bricklink generated number assigned to each store for each item
no, colour and condition. That then represents , lets call it a stock item and
that is what we sell. Lot nos, however are cumbersome and clumsy, so we use Lego
design id nos or (Bricklink part nos) to refer to our items. No one uses lot
nos other than the system.
| |
| |
If I modify the xml file we created when we export xml to Clipboard - the mass
upload will not work - we get an error message that the file format is invalid.
If I put the itemid back in it works.
|
Export with a comment and delete the item field again, it will work. You could
conceivably list your entire inventory without a single catalog item id.
|
No, I am afraid it doesn't - the system tells us it is an invalid file format.
We have moved off the original point - the only real resolution to this is if
someone at Bricklink who understands the code  is willing to share that info
out in the forum.
| |
| |
Whilst I am confident nothing will happen over this suggestion it would be welcome
for BL to comment.
Admin ?
|
|
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | qwertyboy | | Posted: | May 27, 2019 13:24 | | Subject: | Re: Helpful but .... | | Viewed: | 35 times | | Topic: | Suggestions | |
|
| In Suggestions, bje writes:
| | In Suggestions, qwertyboy writes:
| | In Suggestions, bje writes:
| | I voted yes, but I am not entirely sure this would be as simple as is believed
on first glance.
The reason that part number gets dropped is because in BL world, that part number
is not something used to differentiate inventory items.
|
That would be a valid argument, if BL weren't already showing the item description
on that exact same screen. If the program is able to show the description (which
is a lookup into the items table), it already knows the part number (or at least
grab it from the same table the description came from).
So yes, it is a request easily implemented.
Niek.
|
But the item number is optionally included, it is not even a required field.
And from what I can see, only the category field ties to the item number in the
catalog. As a matter of fact, you can list everything in your store without a
single catalog item number, so long as you have the category and comments fields,
mass uploads will work. We sell lots, not catalog items.
|
You are missing the point. The issue here is that, when uploading a common "2x4
brick" (part 3001), the screen shows "2 x 4 Brick" - the official BL description
of part 3001. Obviously at that point the program knows it is dealing with part
3001 (as it had to look up that description) and it also shows a picture of that
part. As it has all the info, it is indeed easy to just add "3001" somewhere
on that line item.
Niek.
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | qwertyboy | | Posted: | May 27, 2019 13:35 | | Subject: | Re: Helpful but .... | | Viewed: | 37 times | | Topic: | Suggestions | |
|
| To illustrate, see attached picture of an upload of a yellow 2x4 brick. The program
knows it is part 3001, it even shows the picture, and if you hover over that
picture, the title says "Part No: 3001 Name: Brick 2 x 4". So don't tell
me that when showing this page it is difficult to add "Part No: 3001" somewhere
in clear text on that line.
Niek.
|
|
|
|
|
|
United Kingdom, England
Denmark
South Africa, Western Cape
Canada, Alberta