Standardizing C2B Device Inspection Reports and Designing the Difference‑Item Report System
This article describes the evolution and unification of C2B device inspection reports, detailing the design of a difference‑item report system, its mapping templates, business configuration, implementation challenges, and the Java code that drives report comparison and generation.
1 Problem Background
1.1 What is an inspection report?
It is widely known that ZhiZhuan is an official second‑hand transaction platform that performs professional quality inspections on every item traded, producing a detailed inspection report for each device.
1.2 Why unify inspection reports?
In C2B online recycling, the original inspection reports contain many technical terms that can confuse end users, so the reports are repackaged before being shown. Early on, users saw defect‑item reports, which varied across phone and digital categories, and the reports viewed by customer service differed from those shown to users. The later addition of difference‑item reports made the situation even more chaotic, resulting in multiple reports per product with different links. To resolve this, a unified inspection‑report approach was introduced.
2 Evolution of C2B User Inspection Reports
2.1 Defect‑Item Report
The defect‑item report lists both the strengths and problems identified by the quality‑inspection team. The determination of each item’s status relies on the Apollo configuration maintained by operations. When new inspection attributes appear, the Apollo configuration must be updated accordingly. The effect of a defect‑item report is shown below:
2.2 Difference‑Item Report
The difference‑item report compares the user‑selected content with the actual inspection results, highlighting preferences, deviations, or consistencies. By displaying the user’s choices side‑by‑side with the real inspection outcomes, users can quickly understand the differences, improving their experience. The mapping between user selections and actual inspection items is stored in the database and managed through a backend interface for operations. The effect of a difference‑item report is shown below:
2.3 Unified Inspection Report
Unification means that both front‑end and back‑end have been aligned. The front‑end entry link for inspection reports is now consistently handled, and the back‑end inspection‑report API has been consolidated. Different strategies allow different product types to match the appropriate report type. After extensive testing, the priority order was determined as: Difference‑Item Report > Defect‑Item Report > Fallback Report.
3 Difference‑Item Report System Design
The difference‑item report compares the user’s estimated report with the actual inspection report, a capability that many business lines need; therefore we have generalized and sunk this ability.
3.1 Mapping Template
The mapping template defines the relationship between actual inspection items and user‑estimated items. Because the number of actual items can far exceed the number of user‑selected items, many actual items must be mapped to a single user item, requiring configurable mapping rules.
Many items : Managed via Excel and stored in the database.
Category : Templates are distinguished by product category.
Special cases : Specific templates can be created for special models within the same category.
3.2 Business Configuration
After configuring the mapping template, additional business‑line configuration is required. Since pre‑inspection and actual inspection belong to two independent business lines, the appropriate line must be specified to ensure correct mapping. This also facilitates future integration of other business lines.
3.3 Mapping Parsing
When the configuration is complete, the inspection report for qualifying products is parsed according to the predefined templates.
/**
* Compare report A' and B
* 1. Device attribute comparison
* 2. Single‑choice comparison
* 3. Multi‑choice comparison
* 4. Group by option type, sort single‑choice by price impact descending + multi‑choice order
* 5. Composite tag titles
*/
public void compareReport(QcInfoAfterMappingBo qcInfoAfterMappingSrcBo, QcInfoAfterMappingBo qcInfoTargetBo,
QcDiffTemplateBo qcDiffTemplateBo, QcDiffDetailDTO qcDiffDetailDTO) {
// Mapping from B report to A report
Map
> targetToSrcMap = qcDiffTemplateBo.getQcDiffItemsMappings()
.stream().collect(Collectors.groupingBy(QcDiffItemsMapping::getValueIdTarget));
// A report valueId -> qcItemMap
Map
qcSrcValueIdMap = qcInfoAfterMappingSrcBo.getNoMappingItemInfoList()
.stream().collect(Collectors.toMap(QcInfoAfterMappingBo.ItemInfo::getValueId, Function.identity()));
// B report basic info mapping valueIdTarget -> targetConfigMap
Map
targetConfMap = qcDiffTemplateBo.getDiffTargetConfMap();
// Use A' as template for comparison
Map
singleSelectMap = qcInfoAfterMappingSrcBo.getMappingSingleSelectMap();
List
noMappingTargetItemInfoList = qcInfoTargetBo.getNoMappingItemInfoList();
if (CollectionUtils.isEmpty(noMappingTargetItemInfoList)) {
return;
}
Map
> targetItemMap = noMappingTargetItemInfoList.stream()
.collect(Collectors.groupingBy(QcInfoAfterMappingBo.ItemInfo::getItemId));
QcDiffCompareBo compareBo = QcDiffCompareBo.builder()
.singleSelectItemsDetailList(Lists.newArrayList())
.multiSelectItemsDetailList(Lists.newArrayList())
.optionTypeDiffLevelNumMap(new HashMap<>())
.build();
// Device attribute comparison
deviceInfoCompare(qcInfoAfterMappingSrcBo, qcInfoTargetBo, qcDiffDetailDTO);
// Single‑choice combination
singleSelectCompare(singleSelectMap, targetConfMap, targetItemMap, targetToSrcMap, qcSrcValueIdMap, compareBo);
// Multi‑choice combination
Map
> multiSelectMap = qcInfoAfterMappingSrcBo.getMappingMultiSelectMap();
multiSelectCompare(multiSelectMap, targetItemMap, targetToSrcMap, qcSrcValueIdMap, targetConfMap, compareBo);
// Group by report type after combination
Map
> singleResultListMap = compareBo.getSingleSelectItemsDetailList()
.stream().collect(Collectors.groupingBy(QcDiffItemsInfo.ItemsDetail::getOptionType));
Map
> multiResultListMap = compareBo.getMultiSelectItemsDetailList()
.stream().collect(Collectors.groupingBy(QcDiffItemsInfo.ItemsDetail::getOptionType));
List
qcDiffItemsInfos = new ArrayList<>();
for (OptionTypeEnum optionTypeEnum : OptionTypeEnum.values()) {
QcDiffItemsInfo qcDiffItemsInfo = new QcDiffItemsInfo();
qcDiffItemsInfo.setName(optionTypeEnum.getDesc());
List
itemsDetailList = new ArrayList<>();
if (singleResultListMap.containsKey(optionTypeEnum.getCode())) {
// Composite tag content
itemsDetailList = singleResultListMap.get(optionTypeEnum.getCode()).stream()
.sorted(Comparator.comparing(QcDiffItemsInfo.ItemsDetail::getImpactLevelSrc).reversed())
.collect(Collectors.toList());
}
if (multiResultListMap.containsKey(optionTypeEnum.getCode())) {
// Single + multi
List
multiItemsDetail = multiResultListMap.get(optionTypeEnum.getCode());
if (!CollectionUtils.isEmpty(multiItemsDetail)) {
List
itemsDetails = multiItemsDetail.stream()
.sorted(Comparator.comparing(QcDiffItemsInfo.ItemsDetail::getImpactLevelSrc).reversed())
.collect(Collectors.toList());
itemsDetailList.addAll(itemsDetails);
}
}
Map
> levelNumMap = compareBo.getOptionTypeDiffLevelNumMap();
if (levelNumMap.containsKey(optionTypeEnum.getCode())) {
qcDiffItemsInfo.setBadTerm(levelNumMap.get(optionTypeEnum.getCode()).getLeft());
qcDiffItemsInfo.setCoincidenceTerm(levelNumMap.get(optionTypeEnum.getCode()).getMiddle());
qcDiffItemsInfo.setGoodTerm(levelNumMap.get(optionTypeEnum.getCode()).getRight());
}
qcDiffItemsInfo.setItemsDetails(itemsDetailList);
qcDiffItemsInfos.add(qcDiffItemsInfo);
}
qcDiffDetailDTO.setQcDiffItemsInfos(qcDiffItemsInfos);
}4 Issues Encountered
During the earlier stages, the defect‑item report configuration was stored in Apollo. As the business grew, several problems emerged:
Increasing number of inspection items exceeded Apollo's capacity.
More product categories required a full configuration set for each new category, raising operational workload.
Delays or omissions in configuring a new category caused the defect‑item report to fail loading.
Solutions:
We migrated the defect‑item configuration from Apollo to a database and built a backend management system for operators. For categories that are not configured in time, we introduced a fallback strategy that directly parses the raw inspection report.
With these measures, the unification of inspection reports is complete, and the backend management systems for both difference‑item and defect‑item reports are operational. Future changes to inspection standards can now be accommodated without code modifications, greatly improving development efficiency.
5 Summary
This article detailed the standardization process of ZhiZhuan's C2B inspection reports and the sinking of the difference‑item report capability. Unifying the reports significantly reduced user inquiries and enhanced experience. Ongoing optimization will enable more business lines to adopt the system seamlessly.
About the author
Fang Hebin, C2B Business R&D Engineer at ZhiZhuan
Zhuanzhuan Tech
A platform for Zhuanzhuan R&D and industry peers to learn and exchange technology, regularly sharing frontline experience and cutting‑edge topics. We welcome practical discussions and sharing; contact waterystone with any questions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.