Enum Lesson I Learned

Current situation: we have several service providers for our business, each of them has different values for a specific enum, for example, SegmentNo, V may have a value set {0,1}, whereas M may have {1,2}, further, our system defines our own enumerations to a unified object, like {10, 20} for the SegmentNo. The question is: How many enums do we need? Our current situation is 3 enums, worse that our team still prefer passing integer type for SegmentNo, rather than Enum, which forms a enum hell, we often pass a wrong value and boring to debug this again and again, developers often confused by the passed value, really unpleasant.

/* We often pass wrong parameter for this kind of API. Don't do this. */
public void doSomeBusiness(int vSegmentNo){

}

Improvement:
1. Encapsulate the mapping in a single enum if they have same semantic, only differ by value.

public enum SegmentNo {
	FT(10, 0), 
	H1(20, 1), 
	ET(30, -1);

	private int id;
	private int vSegmentNo;

	SegmentNo(int id, int vSegmentNo) {
		this.id = id;
		this.vSegmentNo = vSegmentNo;
	}

	public int getId() {
		return this.id;
	}

	public int getvSegmentNo() {
		return this.vSegmentNo;
	}
}

2. Refactor the API, pass enums instead of integers, fetch the right integer if and only if necessary.

public void doSomeBusiness(SegmentNo sn){
	int vsn = sn.getvSegmentNo();
}

If we code in this manner, unlikely to pass incorrect value between methods. I believe this practice is much better.