Part-Out Question/Problem

I am probably missing something obvious, but as I am parting out the set 70195, Two-Face Double Demolition, I am seeing results that are not what I am expecting.

I chose to part out to 'store' and to include the extra parts.

I see the Batman minifigure 'together' along with the 'Break' button. In this case, I am going to go ahead and leave it together and post the mf rather than the individual parts. OK. But then a few items down the list are the components of the mf (e.g., the cape, the mask, etc).

I don't expect to see both the mf (together) and the individual parts to be posted as for sale in my store. I would think it is one or the other.

I understand that alternates for parts that have variations are indicated with a matching number along the left side and that only one of that item should be left checked (to be posted for sale), otherwise, the result would be overstating the inventory. It seems that this may be happening with the mf/individual parts issue. The problem is that I haven't been proactively looking for the individual parts of un-check them when I choose to post the mf.

Do I have a basic misunderstanding of parting out? Am I missing something special about this case?

I appreciate any insights or observations.

Paul

Comments

  • 6 Comments sorted by Votes Date Added
  • @pmitch Paul, you're doing nothing wrong, it's just one of those things that happen.
    Normally, when a fig is created from within an inventory of a set, the fig gets 'in' and the parts go 'out', and you will find yourself in the perfect condition to part out. Now this particular Batman also appears in set 70917, if you check the inventory of that set, you won't find a single minifig piece, so it is very likely the fig was created from that set. Now BO is made in a way that it will automaticly discover the same 'fig' combination is in another set, will then act automaticly, add the fig to that set, and remove the parts. However, if a contributor 'adds' the fig 'manually' in the mean while, and it gets approved, then indeed the subparts of the fig remain... So in this particular case, they need to be removed manually by someone. So simply 'edit' the inventory, click the 'delete' box for all batman fig parts and state 'why' you're doing so (fig already in inventory).
  • Apologies, when an item within a Minifigure is used in multiple Minifigs in that set, it takes several runs of the automatic process to remove them all. I've run that again and they have now been removed.

    Just to clarify, if a figure is added manually, as long as the exact component parts are within the inventory, the system will suggest to me to remove them. I'm sure it's not too helpful this is all an undocumented black box
  • Thanks for stepping in and running the automated prcocess ;-)
    I'm still not convinced this particular feature is the ultimate solution to add figs to sets, we all know TLG will oftenly put the same subparts in certain sets (like the city line), but then create other figs by switching heads and/or torsos and/or legs and/or hair/headgear. Under those circumstances you'll end up with the wrong fig in another set simply because it carries the same sub parts (and we already had such cases). Cases like that are complicated to resolve as it means re-adding the parts to the set, create new figs and delete the wrong ones.
    It might be usefull to have an options during the creation of minifigs to request from the submittor whether or not the fig comes in another set and depending on the answer (the set number(s)) add it automaticly and then remove the parts. This would mean a human confirmation about it, and if the anser is 'no' (submittor doesn't know) at least another set wouldn't be affected and can be adjusted by someone else.
    I do believe minifigs should be handled (approvals in particular) manually and preferably by 1 person to avoid such conflicts or other problems, we all know TLG increases the amount of (new) minifigs year by year, it's hard to keep up with as it is, but then 'problems' (by the automated processes) need to be resolved on top...
  • It certainly would be a mess if it was fully automated, fortunately it submits it as an inventory change request just like a normal user, I then check it against the set image and approve/deny.
  • Yes, as you explained before, I still see issues: you're a human, so mistakes can happen, alltough I feel most will be covered quite accuratly, still, you can't remain focussed 24/7 ;-) The secondary reason is even more important: a set image will be accurate in 99%, but we all know TLG sometimes messes up between setimage and actual built (or throws in a last minute alternate), things like that can only be discovered by looking at actual parts/builds, the most reliable source there is the community...
    Anyway, Paul came with a question and it got answered and solved, that's what counts :-)
  • Thanks Eric and Lawrence!

    Yes, it is an undocumented black box, but it is nice to know the general rationale. As an old (mainframe) programmer, I respect the complexities that you are dealing with. Outstanding job given all of the variables and relationships. I also appreciate your serious approach to building a system with integrity, both technically and business (e.g., the recent decision on third-party products).

    Thanks for the very precise explanation. Even with no clear, complete solution, it helps to know when there is a possible problem to watch for.
Sign In or Register to comment.