[ 初めての方へ | 一覧(最新更新順) | 全文検索 | 過去ログ ]
『数値算出について』（フェンダー）
下記の仕様についてVBAでチェックデジット算出プログラム 作成考えているのですが 現在仕様がしっかり把握出来てない状態で どのように計算式を組み立てればよいかわかりません。
この仕様以外に情報がないのですが なにかプログラムを作成するにあたって アドバイス等あったらお聞かせください。
よろしくお願いします。
達成数値 １４桁文字列 ＋ 識別コード ＋ チェックデジット２桁 （合計１７桁）
１４桁の文字列と識別コード１桁から下記の仕様でチェックデジット2桁を算出
※ 識別コード 種別コード － チェックデジット算出用 ２ 帳票印字用 ＞
１ チェックデジット①
１４桁の文字列 （21371511322617） ＋ 識別コード１桁合計１５桁を１桁ずつ区切り以下の計算をします。
以降１桁ずつ区切ったデータをiとします。
チェックデジット① n=1～15 データテーブル（（指標テーブル ウエイト①（n) ・（ 21371511322617(n)+1 ）） /11の余り ―－－－－－－－－－－－－－－ －－－－－－－－－－－－ i j
2 チェックデジット②
１４桁の文字列 （21371511322617） ＋ 識別コード１桁合計１５桁を１桁ずつ区切り以下の計算をします。
以降１桁ずつ区切ったデータをiとします。
チェックデジット① n=1～15 データテーブル（（指標テーブル ウエイト②（n) ・（ 21371511322617(n)+1 ）） /11の余り ―－－－－－－－－－－－－－－ －－－－－－－－－－－－ i j
※i・jはテーブル行列を示す。
３チェックデジット算出
チェックデジット①②を判定して チェックデジット上１桁、下１ケタを算出
条件 設定内容 条件 設定内容
チェックデジット① チェックデジット上１桁 チェックデジット② チェックデジット下１桁
ZERO "-" ZERO "-"
1 ZERO 1 ZERO
上記以外 １１－ 上記以外 １１－
指標テーブル
n(１５桁） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
ウエイト１ 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1
ウエイト２ 3 4 5 1 3 4 5 1 2 4 5 1 2 3 5
データテーブル
j
1 2 3 4 5 6 7 8 9 10
1 00 02 04 06 08 10 01 03 05 07
2 00 04 08 01 05 09 02 06 10 03
i 3 00 06 01 07 02 08 03 09 04 10
4 00 08 05 02 10 07 04 01 09 06
5 00 10 09 08 07 06 05 04 03 02
エクセル2010 （フェンダー）
>現在仕様がしっかり把握出来てない状態で
チェックディジットの仕様を表すドキュメントが本当に提示されたものだけだとしたら・・・、 わかりづらい仕様書だと思います。だって、実例がないものねえ！！
>３チェックデジット算出
というところを見ると、計算結果によって、3パターンの結果が提示されていますよね！！ だとしたら、この3パターンになる実例をあげて、計算方法を説明すべきだと思いませんか？
こういう分かりづらい仕様書と出会うと自分が仕様書を書く時は、もっと分かりやすい仕様書にしてみせる なんて、思ったりしませんか？
>この仕様以外に情報がないのですが >なにかプログラムを作成するにあたって >アドバイス等あったらお聞かせください
これは、計算方法を明確にする というアドバイスにつきます。
逆にいえば、これさえ分かれば、コードは、それほど難しくないと思いますよ
明確にする手段としては、
投稿されたチェックデジットとは仕様が違いますが、 JANコードのチェックデジットの算出方法はどうなっているのか？ 調べて見ることです。
同じでは、ないですが、似ているところもありますから、JANコードのそれの算出方法と 今回投稿された仕様の算出方法を見比べてみて、違いは、何なのか？ なんて方向から、考えてみると見えてくるものがあるかもしれませんよ！！
１１－ この意味なんて、↑これで想像できそうな記述もあるかもしれません。
私の知っているウエイトという値は、 JANコードの算出方法のような使い方は、覚えがありますが、 ここでは、更にデータテーブルというのが存在するので、ちょっと複雑そうですね！！
この辺りから、フェンダーさんの見解を記述して下さい
ichinose
毎回アドバイスどうもありがとうございます。 やはり分かりにくいですよね。 複雑な仕様の場合もうすこし実行前と実行後の値も交えながら 記述されると業者側も分かりやすいとおもいます。
JANコードやEAN128、NW7等の計算方法は 過去チェックして把握しているのですが 値に-が加わった事例がありません。
過去に在籍してたプログラマが残してあるテストデータの 実行前と実行後の値が 残っていたのでそれを見ながら、仕様書含み色々と調べているのですが・・・
因みに
達成数値 １４桁文字列 ＋ 識別コード ＋ チェックデジット２桁 （合計１７桁）と 記述してますが 過去に在籍してたプログラマのデータのみ見てみると
実行前のデータが 3187004700265026で 実行後のデータが 318726001732031 0150
実行前のデータが 3113726402265026 実行後のデータが 3183260017840-0 0450
実行前のデータが 5180768398635026 実行後のデータが 0460631022270-- 0460
となっており現状よくわかりません。 おそらく15ケタの文字列からウエイトの値加えてチェックデジットを算出。そして データテーブルの値に仕様書通りヒットさせて値を出している思うのですが・・・ 仕様書をよく確認しつつ 現状実行前のデータと実行後のデータの計算方法を 検証しています。
（フェンダー）
言い忘れてましたが 実行前のデータの文字列下２桁26は固定文字になります。 そう考えると 下２桁26は、使用しない考えで作業は進める事になります。
実行前のデータが 3187004700265026で 実行後のデータが 318726001732031 0150
実行前のデータが 3113726402265026 実行後のデータが 3183260017840-0 0450
実行前のデータが 5180768398635026 実行後のデータが 0460631022270-- 0460
（フェンダー）
> 実行前のデータが 3187004700265026で >実行後のデータが 318726001732031 0150
チェックディジットの計算をしたら、元の数字まで変わるなんて事は、 私には、考えられませんが・・・。
そもそもこれ、何らかの計算方法を思いついたとして、それの検証手段を持っているのですか？
最初のフェンダーさんのチェックディジット計算仕様から、想像できる計算手順はありますが、 これで間違いない という検証手段がなければ、どれも思い付きにすぎませんよね！！ この検証手段に関しては、どうなんでしょうか？
ichinose
>そもそもこれ、何らかの計算方法を思いついたとして、それの検証手段を持っているのですか？
検証と記述してますが、自分の中で判断した基準になると思います。 最初から、エンドユーザーに仕様書の内容が分かりにくい、 もしくは詳しく一から説明してもらうとなると 時間もかかりエンドユーザーから嫌がられるといった感じにとらえてます。 たとえ実行結果が間違っていたとしても 想定内でプログラムが出来たら とりあえずテストを提出して、エンドユーザーから指摘されてから その先を考えるというようなイメージです。 具体的な方向が分かった時点で スポットで質問しようと思っているのですが その前に仕様書を解読出来る方がいれば アドバイスを頂けたらと思い投稿しました。
現在は、自分なりの判断でのプログラムも作成できてない状態なので ご相談させて頂いたという事になります。
因みに提示させてもらったデータが正しいかどうかは 分かりません。 もしかしたら仕様書通りには作れていない プログラムかもしれないという事です。
実行前のデータが 3187004700265026で 実行後のデータが 318726001732031 0150 実行前のデータが 3113726402265026 実行後のデータが 3183260017840-0 0450 実行前のデータが 5180768398635026 実行後のデータが 0460631022270-- 0460
（フェンダー）
すいません。 違うプログラムの実行結果を 記述してたようです。 下記の実行結果は 忘れてください。
実行前のデータが 3187004700265026で 実行後のデータが 318726001732031 0150 実行前のデータが 3113726402265026 実行後のデータが 3183260017840-0 0450 実行前のデータが 5180768398635026 実行後のデータが 0460631022270-- 0460
（フェンダー）
>最初から、エンドユーザーに仕様書の内容が分かりにくい、 お客様なのですから、そりゃあ 「仕様書の内容が分かりにくい」とは言いませんよね！！ 私が理解力がなくて・・・で よいではないですか？
>もしくは詳しく一から説明してもらうとなると >時間もかかりエンドユーザーから嫌がられるといった感じにとらえてます
計算方法を実例で2,3回説明してもらえば、済むことです。聞いてしまうほうが断然速い話だと思いますよ 明確でないと思った仕様をあれこれ悩むよりは・・・。 計算方法がわかったら、フェンダーさんがわかりやすい計算仕様を残しておく という手順です。
>たとえ実行結果が間違っていたとしても >想定内でプログラムが出来たら >とりあえずテストを提出して、エンドユーザーから指摘されてから >その先を考えるというようなイメージです。 私なら、こっちの方が嫌ですけどねえ！！ まだ、仕様も理解できてなかったんだ！！ という印象です。
http://mt-net.vis.ne.jp/ADFE_mail/0055.htm
↑ここにISBNコード（2006年までのものらしい）のチェックディジットの計算方法があります。
フェンダーさんの最初に投稿された仕様に少し似ているので見てください。
ISBNコード フェンダーさん提示仕様
コード桁数 10桁 17桁
（含 CD）
CD桁数 1桁 2桁
算出方法 計算結果を11で割った余り 計算結果を11で割った余り
注 CDは、チェックディジット 計算結果とは ウェイトと文字コードを使った何らかの計算方法
コードの桁数は、違いますが、ウェイトを使った何らかの計算結果を11で割った余りから チェックディジットを求めています。
ISBNコードは、
この余りが 1の時、 X
0の時、 0
上記以外 11-余り
フェンダーさん提示仕様では、
この余りが 0の時 -
1の時 0
上記以外 11-余り
余りが1,0の時の対処が違いますが、
11-余り の結果が 二桁になる場合を別に定義しているように見えます。
ISBNコードの場合は、ウェイト呼ばれる数値とコードの各桁の積の合計 という計算結果から算出しています
フェンダーさん提示仕様でも同じように計算してしまうと、データテーブルを使わないことになって しまいますから、計算方法には、まだ何かがあるのでしょう！！
ここでウェイト1、2の値に注目すると、
ウエイト１ 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1
ウエイト２ 3 4 5 1 3 4 5 1 2 4 5 1 2 3 5
全て 1～5の範囲内です。 仕様にiとあるように データテーブルの行番号に相当するのではないか？ 推察できます。
で列番号は 実際のコードの値ではないかと推察すると、
>１４桁の文字列 ＋ 識別コード１桁 が、 21371511322617 ＋ 6
の
213715113226176
この15桁のコードで見ると
ウェイト1で見ると、
最初ウェイトが2なので 2行 コード最初の数字が2なので 2+1列（3列）に相当する データテーブルの値 08が計算に関与しているのではないかと推察できます
同様に 2番目のウェイトが3なので 3行 コード2番目の数字が1なので 1+1列（2列）に相当する データテーブルの値 06が計算に関与しているのではないかと推察できます
これらの合計を11で割った余りからチェックディジットを算出なんて想像をしましたが、 いかがですか？
ichinose
（フェンダー）
>プログラムの細かい話は、暗黙の了解で >みなさん質問してないんですよ。
仕様があいまいなのに質問しない！！ 私の会社は、プログラミングも業務の一つですがが、これは有り得ないので 理解に苦しみますが、これには事情があるのでしょう。
>15桁目の識別コードの6はどこから >判別したものでしょうか？ チェックディジットを算出するのに必要な入力データとして、１４桁の文字列と識別コード１桁の最初の投稿に
>達成数値 １４桁文字列 ＋ 識別コード ＋ チェックデジット２桁 （合計１７桁） >１４桁の文字列と識別コード１桁から下記の仕様でチェックデジット2桁を算出
とあります。
つまり、１４桁の文字列と識別コード１桁は、チェックディジットを算出するのに必要な 入力データになります。
例として、無策の数値をあげたのですよ、6は、0～9の数値なんでも良いのです。 当然、その前の 14文字の数字も何でも良いのです。 何が入力されても15桁の数字から、チェエクディジットを算出するプログラムなのですから・・・。 識別コード1桁に関する情報は、それ以外は読み取ることが出来ません。
繰り返しますが、あくまで投稿した仕様は、フェンダーさんの最初の投稿から仕様を想像したものです。
でも、この私の想像した仕様で プログラミングしたものを提出すれば、
>とりあえずテストを提出して、エンドユーザーから指摘されてから >その先を考えるというようなイメージです。
と仰っているので、これでプログラミングしたものを提出してもよいのですよね？
ichinose
全く問題ありません。
単純に識別コードが６になっていたので気になってただけです。
一応仕様には
※ 識別コード 種別コード － チェックデジット算出用 ２ 帳票印字用 ＞と記述されてますが
あまり気にせず適当な数値として考えます。
ichinoseさんの想定を交えて
現在考えている途中です。
まだ
データテーブルの計算やその他の条件判定などこれからコードで考えますが。
Dim Weight1(1 To 15) As Long 'Weight①
Dim Weight2(1 To 15) As Long 'Weight②
Dim tmpCD1 As Long, tmpCD2 As Long
Dim tmp As String
tmp = "213715113226176"
Weight1 = Array(2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, 1)
Weight2 = Array(3, 4, 5, 1, 3, 4, 5, 1, 2, 4, 5, 1, 2, 3, 5)
dataTable 00, 02, 04, 06, 08, 10, 01, 03, 05, 07
00, 04, 08, 01, 05, 09, 02, 06, 10, 03 00, 06, 01, 07, 02, 08, 03, 09, 04, 10 00, 08, 05, 02, 10, 07, 04, 01, 09, 06 00, 10, 09, 08, 07, 06, 05, 04, 03, 02
とこんな感じで配列を作れば出来るのかなと。
For i = 1 To 15
tmpCD1 = tmpCD1 + Weight1(i) * (CLng(Mid(tmp, i, 1)) + 1)
Next i
tmpCD1 = 11-(tmpCD1 Mod 11)
tmpCD2 = 0
For i = 1 To 15
tmpCD2 = tmpCD2 + Weight2(i) * (CLng(Mid(tmp, i, 1)) + 1)
Next i
tmpCD2 = 11-(tmpCD2 Mod 11)
（フェンダー）
ご報告だけさせて頂きます。 ichinoseさんの想定と仕様書をチェックすると つじつまが合います。 11-の意味や、データテーブルの文字列＋1列なんかも 仕様書が分かりにくいというのも ありますが 理解力も必要になってくると思いますし ご相談してなければおそらく分からないままだったと思います。 どうもありがとうございました。
（フェンダー）
[ 一覧(最新更新順) ]
YukiWiki 1.6.7 Copyright (C) 2000,2001 by Hiroshi Yuki.
Modified by kazu.