c# - Does a 2-char check digit for a barcode use the first or second char? -

based on understanding of how check digits supposed calculated barcodes, namely:

0) sum values of characters @ odd indexes (1, 3, etc.) 1) multiply sum 3 2) sum values of characters @ indexes (o, 2, etc.) 3) combine 2 sums steps 1 , 2 4) calculate check digit subtracting modulus 10 of combined sum 10 

so example, barcode "04900000634" combined sum 40*; check sum, modulus (40 % 10) == 0, , 10 - 0 == 10.

• odd characters == 7; x3 = 21; characters == 19, combined sum of 40.

since check digit scalar value, if result of check digit calculation 10? 1 use "0" or "1"?

here code i'm using (thanks here: why 1 + 0 + 0 + 0 + 3 == 244?); i'm assuming formula pseudocoded above applies regardless of length (8 chars, 12 chars, etc.) , type (128, ean8, ean12, etc.) of barcode.

private void button1_click(object sender, eventargs e) {     string barcodewithoutczechsum = textbox1.text.trim();     string czechsum = getbarcodechecksum(barcodewithoutczechsum);     string barcodewithczechsum = string.format("{0}{1}", barcodewithoutczechsum, czechsum);     label1.text = barcodewithczechsum; }  public static string getbarcodechecksum(string barcode) {     int oddtotal = sumoddvals(barcode);     int oddtotaltripled = oddtotal*3;     int eventotal = sumevenvals(barcode);     int finaltotal = oddtotaltripled + eventotal;     int czechsum = 10 - (finaltotal % 10);     return czechsum.tostring(); }  private static int sumevenvals(string barcode) {     int cumulativeval = 0;     (int = 0; < barcode.length; i++)     {         if (i%2 == 0)         {             cumulativeval += convert.toint16(barcode[i] - '0');         }     }     return cumulativeval; }  private static int sumoddvals(string barcode) {     int cumulativeval = 0;     (int = 0; < barcode.length; i++)     {         if (i % 2 != 0)         {             cumulativeval += convert.toint16(barcode[i] - '0');         }     }     return cumulativeval; } 

update

the calculator here: http://www.gs1us.org/resources/tools/check-digit-calculator claims check digit 04900000634 6

how being arrived at?

update 2

this http://www.gs1.org/barcodes/support/check_digit_calculator revises understanding of last part of equation/formula, says, "subtract sum nearest equal or higher multiple of ten = 60- 57 = 3 (check digit)"

so, in case of 04900000634, combined sum 40. based on formula, "nearest equal or higher multiple of ten" of 40 40, 40-40=0, , expect check sum (not 6)...so, still confused...

update 3

i'm not understanding why yet, mike z's comment must correct, because when reverse "==" , "!=" logic in sumoddvals() , sumevenvals() functions, results correspond generated http://www.gs1us.org/resources/tools/check-digit-calculator

update 4

apparently, based on http://en.wikipedia.org/wiki/european_article_number, powers behind check digit calculations don't consider first position position 0, position 1. confusing developers, trained see first item residing @ index 0, not 1!

the check digit last.

starting digit left of check digit , moving left, sum each digit, applying weight of 3 , 1 alternately.

the check digit number needs added produce result multiple of 10.

this works ean/upc codes - upc-e, ean-8 (which valid 8-digit codes except whoch start 0,6 or 7) upc-a (12-digit), ean-13, ean-14 (sometimes call "tun" or "carton" codes) , ssccs (actually 18-digit, implemented part of ean128 standard ai of '00', misleading believing they're 20-digit codes)

when upc-e introduced, original scheme [language][company][product][check]. 0,6 , 7 assigned english , remainder unassigned. [company] , [product] variable-length total 6 digits; short company numbers companies many products, long companies few products.

ean used remainder of numbers, assigned [country][company][product][check] country 2-digit.

that system ran out of puff, still assigned small products - , original products had numbers before upc-a/ean-13 introduced.

upc-a used same schema upc-e, lost reference 'language'. 0,6 , 7 assigned us/canada. company+product extended 10 digits.

ean-13 extended scheme 13 digits, 2 country, 10 company+product, 1 check. upc-a compatible prefixing leading "0".

by implementing 13-digit scheme, companies track each of these codes , upc-as did not need issued on products had ean-13 assigned. scheduled completion 8 years ago, companies still lag behind.

ean-14s used carton outers. leading digit normall referred "trade unit identifier/number" hence entire code called tun. @ first, there attempt codify leading digit (1=1doz, 2=2doz, etc.) abandoned. companies use number packaging level (1=cluster of individual items, 2=tray of clusters, 3=box of trays - depending on each company's preference. 9 reserved. not idea use 0 (though companies have) since produces same check-digit 13-digit code. i've used ean128 codes bearing batch number on non-retail goods; ai=01;ean-14 (=ean13 tun=0);ai=10;batch-number.

ssccs can of worms. they're 18-digit - first digit used logistical descriptor, there's country-code, manufacturer-code , package-number check-digit. originally, "3" meant "external" pallet , "4" "internal" pallet, fell disuse impractical "internal" pallet has re-numbered if gets sent "outside" , vice-versa.

and of course 2-digit country-codes have been supplanted 3-digit more countries have adopted system.