JCA手順資料室

JCA手順とは、日本チェーンストア協会が規定した手順で・・・・、いや、ここはテストや学校の勉強で使うための資料ではありませんので、そういった定義については説明しません。学校の勉強やレポート等で使う場合は、このサイトは利用しない方がいいでしょう Googleで検索して別のサイトをご利用ください。ここでは、現場で働くプログラマーやメンテナンス係のために、「要するに何なのか」について説明します。

1990年、バブルの絶頂の頃、大型チェーンストアの進出に伴い、それまで街をにぎわしていた商店街がどんどんシャッター通りになっていった頃のお話。個人商店はこの先生きのこる 生き残りをかけて直接お店で売るのではなく、大手チェーンストアに品物を卸すようになりました。

ところが、次第にチェーンストア同士の競争が激しくなり、他店より１円でも安く売るため、仕入れにかかるコストをどんどん削っていくようになりました。それまで電話やFAXで行っていた注文を、コンピューターを使った電子取引にする事で、人手を減らし、コストを削減し、その分を価格に反映できるようにしたわけです。そのため、「コンピューターを使って電子取引をしない商店とは取引をしない」という強行手段に出たチェーンストアも多かったようです。

ところが、当時のパソコンでは286か、ようやく386が登場した頃。ハードディスクも多くて100メガ（ギガにあらず）なので、とても今のようなパソコンを使って作ったサーバーでは、大量の発注を管理する事ができません。当時は（というか今でも？）、大手の発注を管理していたのはもっぱら汎用機(メインフレーム)でした。またインフラも現在のようなインターネットがどこの会社や一般家庭にもある状況とは違い、通常の会社・個人商店にある通信設備といえば、アナログ電話でした。

というわけで、この頃にチェーンストアから個人商店に対してコンピューターで発注データーを送信する手段として、アナログの電話回線を使ってデーターを送信する手段が使われました。そこで登場したのがJCA手順です。これはBSC手順という半二重同期通信手順に、「制御電文」という、要求コード・パスワード・返答コードなどを指定した電文を追加したものです。先に述べたように、これらが電子取引を強制された商店の多くで導入されたため、現在でも多くの商店で残っているものと思われます。

というわけで、まずは「BSC手順」と、「制御電文」について説明します。

BSC手順とは、Binary Synchronous Communicationの略で、RS-232Cポートを使って同期通信を行う手順を定めたプロトコルです。ITU-T勧告の、V.26bisという規格を使って2400BPSの半二重同期通信を行います。

BSC手順に使うモデム
モデムは、普通にパソコン通信用として売られていた廉価なモデムは使えませんので、ここ数年にOA機器メーカーに就職してその辺の事情に詳しくない方は注意してください。

なぜ、低価格のパソコン通信用のモデムが使えないのかというと、半二重同期通信を行うためです。

・EOTコードを受信する毎に送信権を反転させる回路が必要
・精度の高いクロックが必要
・業務用なので、電源入れっぱなしで何年も稼動し続けなければならない
・量産されていない

特に、耐久性が必要なことと、量産されていない事は価格を大幅に引き上げる要員となっています。なので、BSC手順で使うためのV26bis対応のモデムは総じて非常に高価で10万円前後はしました。

筆者が実際に業務で用いたモデムは以下の通りです。

田村電機 HM2410
東芝 MT2400A
オムロン MD24HS

これらは現在では入手困難ですので、万一故障などで、これらのモデムがどうしても必要になった場合は、[半二重 モデム V26bis]のようなキーワードでGoogleで検索してみてください。あいにく最近（ここ16年ほど）これらの業務から離れている関係で、今現在V26bisのモデムがいくらぐらいで、どれぐらいの機種に対応して作られているのか詳しくないもので。

同期通信について説明する前に、まずは調歩同期方式について説明します。

パソコン通信で使われていた方式で、「非同期」とも言われます。ただし、これは「同期式」の対になる言葉として用いられる言葉であり、実際には同期自体をとってないわけではありません。

この方式は、パソコン通信のように、いつデーターが来るかわからない場合に適しています。パソコン通信では、端末からコマンドを入れたり、メニューを選択したりするまでは、サーバーと何もデーターが送受信されずにアイドル状態になっている事が多いです。

全二重ですので、サーバーも端末もアイドル状態ではずっと111111111111…と、ストップビットを送信しています。そして、これからデーターが来るぞという時に0（スタートビット）を送信します。



データー長の７ビット/８ビット、パリティビットのあり/なしは、ホストによって異なります。これは、ATコマンドを使ってモデムをホスト毎に設定しますが、大抵の通信ソフトでは有名パソ通ホストの場合はオートパイロットでATコマンドを自動で発行してくれますし、そうでなくとも大抵はメニューで設定する事で自動でATコマンドを発行してくれます。

調歩同期方式のモデムに内蔵されたクロックはさほど高精度ではないので、１バイトごとに11111…というストップビットの連続したギャップの部分があって クロックのズレを調整しながら通信をしています。なので、実際に送受信する本データーの他に同期をとるためのビットが大量に送受信されるため、一度に多くのデーターを送受信する通信には向きません。

・・・・と、最初のうちはそういう話だったんですけど、その後PCの性能が向上した上に、非同期モデムの性能も向上してほとんどが9600BPS対応になってくると、もうLHAやZIPで圧縮したものを Zmodem、 BPlus、 Quick-VAN とかのバイナリプロトコルで送受信した方が、下手に同期通信で送るよりよほど速かったりもしました。

同期通信ではEBCDICコードによる制御コードが使われます。

EBCDICコード

注）
・見やすいように全角で書いてるものがありますが、実際には全部半角です。
・グレーの部分はメーカーによって独自に拡張されたものなので、メーカー毎に異なります。
・タイプミスがある可能性もあるので、正確なEBCDICコードを知りたい時はGoogleで別途検索してください。
・なお、私はオフコンを扱った事はありません。

EBCDICコードは、本来は英大文字と数字と一部の記号だけしか規定されていないのですが、これでは英小文字やカナが扱えないため、各メーカーごとに独自に空いたコードに小文字やカナを割り当てました。そのため、グレーの部分はメーカーごとに異なります。

チェーンストアからの発注では、半角カナを使うので、英小文字ではなく半角カナを割り当てられたコード(いわゆるEBCDIK)を使います。ただし、カナの小さい文字（ァィゥェォャュョッ）は使わない所が多く、伝票上では「ショウヒン」は「シヨウヒン」という風に表記されます。

上記のコード表は手持ちの資料の丸写しですが、ワーチョワチョガイナンジャネーノ 写し間違いのある可能性もあるので、 あんまりアテにしないでくださいね。 この表はいちお制御コード（STX、STX、SYN）とかの説明用に掲載しているだけで、 私自信あんまりEBCDICコードに詳しくありません。なにせオフコンとか全く使った事ありませんし・・・。

BSC通信
上記コード表で、赤字で示した制御コードがBSC通信で主に使われます。同期通信では、同期信号は11111…というストップビットではなく、SYNというバイト（キャラクター)を使います。SYN STX [256バイトデーター] ETX のように、SYNバイトがSTXになった後の256バイト（もしくは128バイト）が本データーです。調歩同期方式とは違い、その間にストップビットが入らないため、データー量が少なくて済みます。

そのかわり、256バイト送受信している間、送信側と受信側でタイミングがズレてはいけないので、双方に精度の高いクロックが必要になります。これがモデムの価格を引き上げる要員の１つになっています。

また、STXの後は必ず256または128バイトを送信しなければならないため、送信するデーターが１ブロックに満たない場合でも、何らかのデーター（大抵は 0x40=スペース）で埋めなければなりません。（これをFILLERといいます） そのため、パソコン通信のような、アイドル期間が発生する通信には向きません。送受信するデーターがあらかじめ決まっていて、アイドル時間なしでたて続けて送り続けるような通信に向いています。

エラー訂正
BSC同期通信では、送信側は１ブロックをたてつづけに送信します。なので、エラー訂正は、１ブロックごとに行います。送信側がETXを送信した後、受信側がエラーをチェックし、（すいません。この辺は市販のライブラリ任せにしていたので、具体的にどういうエラーチェックをしているのかはわかりません）エラーがなければACK、エラーがあればNAKを送信します。受信側がNAKを送信したら送信側は今のブロックをもう１回送信します。受信側がACKを送信したら、送信側は次のブロックを送信します。



このため、頻繁にエラーが発生する環境では、むしろ調歩同期方式よりも無駄な送受信が多くなってしまいます。したがって、同期通信を行う場合、電話回線の質には十分注意してください。ラジオやノイズを拾ってしまうような電話回線だった場合、NTT等に連絡して配線を見直してもらう必要があります。

送信権の反転
半二重通信なので、送信権はどちらか一方しかありません。送信権のない側は、ACK（肯定反応）、NAK（否定反応）を１ブロックごとに送出するだけです。最初は、送信権は回線を接続しに行った側（つまり端末側）にあり、送信権のある側がEOTを送信するごとに送信権が反転します。EOTとは、トランシーバーでいうところの「OVER」と同じで、ニュース番組でいうところの「こちらからは以上です」に相当します。

送信の終了
送信を終了するためには、まず送信権のある側がEOTを送出します。送信権が反転しますので、送信権を受け取った側は直後に何もデーターブロックを送信せずに、ただEOTだけを送出します。これによって、「双方ともに送信するものがない」と判断されます。ニュース番組でいうところの、「こちらからは以上です」「ありがとうございました」に相当します。その後、通常は回線を接続した側（つまり端末側）が回線を切断します。



ここで注意しなければならないのは、サーバー側が終了電文の後にEOTを送出したら、もうこの後にデーターが何もない場合がほとんどです。しかし、端末側ですぐに回線を切ってしまうアルゴリズムにしてしまうと、サーバー側は「通信エラー」となり、次回接続した時には前回と同じデーターがまた送出されます。なので、サーバー側がEOTを送出したら、すぐに回線を切らずに端末側もEOTを送出してから回線を切断するようにしてください。

電文というのは、何バイト目に何が書かれているといったフォーマットの決まったデーターの集合体です。現在のインターネット時代でも、ソケット通信を使って電文を送受信したりします。制御電文とは、チェーンストアと端末側で認証や要求事項をやりとりするために定められた電文の事です。BSC手順＋制御電文＝JCA手順となります。

制御電文

ここでいう「数字型」というのは、COBOLでいうところの9タイプのことです。つまり、バイナリではなく数値をキャラクターで表す方式です。Ｃだとsprintfで（例えば6桁なら） %06d みたいに編集したのと同じです。000001のように、有効数字の左側は0で埋められます。

「文字型」とは、EBCDICコードの英数カナ記号の事ですが、電文にはカナや記号は使われません。半角の英数字が入ると思っておいてください。データーはEBCDICコードで送受信されますが、大抵はライブラリの方でASCIIからEBCDICに変換してくれます。

要求区分
サーバーに何をして欲しいのか。または、サーバーからの応答がセットされます。
AA01 ・・・・ 送信要求。未受信のデーターを送信してもらう。
AA02 ・・・・ 再送要求。既に受信済みのデーターを再送してもらう。
AA90 ・・・・ サーバーからの応答。「これにて通信を終わります」という意味です。
すいません。他にもあるみたいですが、他のは使った事ありませんで。

電送年月日
いつのデーターが欲しいのか。といっても、大抵のチェーンストアは受信済みデーターは１日しか保存してないので、前日の日付をセットしてもダメな場合がほとんどです。

日付が６桁なのは、この頃作られた仕様は大抵は2000年問題は考慮されていないため、年は西暦の下２桁をセットするようになっているためです。1990年当時は、MicroFocus Level II COBOL言語でも日付は年の下２桁のみ取得されるし、入力させるにしても、自動でセットさせるにしても、日付を8桁で要求するとむしろクレームになるぐらいでした。

センターコード
取引先ごとに異なります。チェーンストアから配布されている仕様書に、ここに何をセットすべきか書かれています。

取引先コード・ステーションコード
取引先コードをセットします。これにより、サーバーはどの取引先のデーターを送信して欲しいかを判別します。ステーションコードとは、同じ取引先でも営業所や工場が複数ある場合に、別々にデーターを管理できるようにつけられた枝番です。ステーションコードが不要な場合、大抵は00をセットします。

センターコードと取引先コードとステーションコードはパスワードの役目もしていて、これがある事で悪意をもった第三者が勝手に発注データーを受信できないようになっています。（作業をする人は、むやみにこれらのコードを他人に教えてはいけません）

識別子・データー種類
チェーンストアから配布されている仕様書に、ここに何をセットすべきか書かれています。識別子とデーター種類の組み合わせによって、何のデーターを送出すべきかサーバーが判断します。

実際に現場で稼動しているプログラムでは、MOVE ZERO TO 識別子.　みたいに、オールゼロを固定でセットしているプログラムも多いかと思いますが、これは、この項目を使っていない場合にオールゼロをセットするように指示される事が多いためです。

カウント１、カウント２
データーの一部が欲しい場合に、カウント１には受信済みの件数、カウント２には 何件分出したいかをセットします。PostgreSQLでいうところの、OFFSETとLIMITみたいなものです。とはいえ、現場レベルではオールゼロを固定でセットしているプログラムがほとんどです。というのも、この機能自体使わない人が多く、また、サーバーによってはこの機能自体対応しておらず、オールゼロを固定でセットするように指示している仕様書すらあったりします。

ここにオールゼロがセットされた場合は、「最初から最後まで全部」という意味になります。

処理区分
サーバーからの応答で使いますので、端末側は空白をセットしておきます。
NG ・・・・ パスワード不一致。
NO ・・・・ 送信すべきデーターがない。
ST ・・・・ サーバーの準備ができてない。

NGが出たときは、センターコード、取引先コード、ステーションコードのいずれかが間違っているので、仕様書をよく確認してください。STはサーバーの準備ができてないという意味で、オンラインで通信ができる時間帯が決まっている場合があり、時間外にアクセスするとこの区分が返ります。

NOは一度正常終了した直後に、再送要求ではなく送信要求をした場合に出る事が多いです。一度正常終了するとサーバー側にフラグが立つので、以降は再送要求でないと受信できない事がほとんどです。サーバーによっては、送信データーがないのにNOではなく空白（つまり、正常終了）を返してくる場合があるので注意が必要です。その場合、自前のルーチンで「受信データーはありませんでした」みたいなメッセージを作らねばなりません。

データー本体は、チェーンストアによってフォーマットが異なりますので、それぞれの仕様書を見てください。大抵はヘッダーレコードと明細レコードになっていると思います。

ヘッダーレコードとは、伝票番号、注文日、納品日、便など伝票のヘッダーの部分に記載するデーターが書かれていて、伝票１枚につき１レコードです。明細レコードとは伝票の明細行のデーターのことで、商品コード、商品名、数量、単価、金額などが書かれています。これは、伝票の行数分だけあります。

１ブロックが128バイトだった場合（これは申し込み時に選択できる事が多いです）、ヘッダーにしろ明細にしろ１ブロックに収まらない事がありますので、その際は２ブロック受信ごとに内部で結合する必要があります。

受信中に常に判断しなければならない点として、先頭の２バイトが「AA」なら、それはヘッダーや明細ではなく制御電文だという点です。先頭２バイトがAAであれば、処理区分をチェックしてNG、NO、ST、空白によって処理を変更します。

受信したデーターはすみやかにプリントアウトします。チェーンストア統一伝票に印刷する場合がほとんどですが、中にはそのストア専用のフォーマットのものが指定されている場合もあります。



印刷位置
チェーンストア伝票のうち、PCで印刷するように作られた「連続帳票」は、10CPIでちょうどピッタリ入る幅になっているので、印刷は半角文字を10CPIで印刷するように設定します。プロポーショナルフォントとかにすると印刷位置が合わなくなるので注意が必要です。

10CPIで半角文字のみを印刷していればズレる事もなく、印刷位置あわせもやりやすくなっています。しかし、ユーザーがスプロケットを動かしてしまったり、プリンターによっては上マージンが必要なため２枚目からしか印刷できない場合があります。（この場合、毎回１枚目を犠牲にします。）そのため、テストプリントの機能をつけるようにします。

テストプリントには、全ての項目に、XXXXX や 888888　などの文字を印刷することで、印刷位置のズレを確かめる昨日です。商品コードや商品名の項目にはXXXやYYYYY、数量単価金額の欄には9999や8888を印刷します。この際に、隣り合う項目には違う文字を打つようにします。（でないとズレがわかりませんので）

すいません。この見本はPhotoshopで作ったのでピッチが合ってません。本当は10CPIでピッタリ合いますのでご心配なく。

備考欄
伝票切れや伝票詰まりの関係で、途中から途中までの一部分を印刷したい場合があります。この場合、伝票番号指定だと長すぎるので、内部管理用の連番みたいなのを備考欄に印刷させたい場合があります。

ところが、チェーンストア伝票にある「FGHIJKL」欄はあくまでチェーンストアが使うために儲けてあるものであって、端末側で勝手に使ってはいけない事が多いです。もちろん、「ここだけは自由に使っても良い」と仕様書に書かれている場合もあるので、仕様書をよく確認してください。使って良いと書かれた欄以外には、端末側の管理番号などを印刷してはいけません。

余った行
伝票に9行あるとして、印刷データーが４行や５行しかない事があります。というか、行が全部埋まる場合はめったにありません。なにしろ、伝票は納品する店舗ごと、部門ごと、納入担当者ごとに分かれていますので。

その場合、送信されてきたデーターにはありませんが、余った行に「ﾖﾊｸﾆﾊｷﾆｭｳｼﾅｲﾃﾞｸﾀﾞｻｲ」もしくは「余白には記入しないでください」みたいに注意書きを印刷するように指定されていると思います。これは、受信データーには含まれませんので、プログラムの方で最大行よりも明細データーが少なければ自動的に品名・規格欄に固定文字を出力するようにします。


小数点
数量と原単価の欄には小数点があります。数量の小数点は、つまり計り売り商品などグラムやメートル単位で仕入れる場合とかで使います。とはいえ、スーパーで売るなら普通は梱包済みの１個単位のものを仕入れるので、めったに使いませんが。

原単価はつまり納品する側にとっての売単価ですね。これは、１個当たりの値段に端数が出る場合があります。この場合、数量で調整して原価金額には小数点が出ないようになっています。


注意しなければならないのは、小数点はめったに使わないので、通常は空白にしなければならないという点です。小数点は小数点以下が存在するときだけ印刷します。色々なやり方がありますが、COBOLなら例えば、

のようにREDEFINESでメモリーを再定義しておいて、小数点部分（この例ではMEI5-6-2)が "00"だったらSPACEをMOVEするという方法があります。じゃあ他の言語だったら・・・・と言うかもしれませんが、すいません、他の言語でこの業務作った事がありませんで。

伝票の修正の機能、または請求書の発行の機能をを作るか作らないかで、コストもプログラム作成にかかる日数も全然違います。こういう仕事を請けるときは必ず真っ先に確認してください。

大手と電子取引をしている場合、紙の請求書を出さずとも大手の方のコンピューターで計算して月末に振り込んでくれる場合もありますし、経理処理の都合で紙の請求書が必要な所もあります。しかし、この両者の違いは、受信プログラムを作る側にとっては重大な違いです。

昔は「コンピューターで処理している」と言えば紙の請求書がなくても認めてくれたんですけど、近年消費税の関係で税務署もうるさくなってきまして、紙の請求書がないと経費として認めてくれなかったりするんです。

打ち合わせの時には紙の請求書が必要なんて話は一言も出なかったのに、いざ月末になって突然「請求書が出ない」というクレームになった事があります。その際に、「請求書を出すのは常識だろ！」とか、「普通は請求書ぐらい出るのが当たり前だから、あえてその話はしなかった」とか色々言われます。なので、必ず、作る側の方から積極的に聞くようにしてください。実際、これを怠ったために会社をまきこんだえらい騒ぎになった事がありました。なにしろ、その時は既にデーターは上書きされ、ハードディスクに残ってなかったわけですから。

通常、受信データーを印刷するだけでしたら、受信データーはテキストファイルとして残しておくだけで十分ですし、次の受信した時に上書きして削除してしまってかまいません。しかし、伝票の修正機能や請求書を印刷するとなると話は別です。その場合は、受信データーをデーターベースやISAMファイルで残しておかなければならないからです。

同期通信は、１ブロック毎にアイドル時間なしでたて続けにデーターを送受信しなければならないので、受信しながらデーターベースにINSERTなんてしていると、PCの処理速度がおっつかなかったりして、タイムアウトエラーになってしまう場合があります。とくに1990年当時のPCの性能では、受信しながら同時に処理ができたのは、テキストファイルに出力させるぐらいでした。なので、通信処理中はテキストファイルにログを記録するだけにしておいて、正常終了後に最後に一括してデーターベースに記録するようにします。

また、今でこそハードディスクが100ギガ200ギガは当たり前なので、おそらく一生分受信データーを残してもパンクはしないでしょうが、当時のPCについているハードディスクは20メガとか40メガ、多くて100メガ（ギガにあらず）程度なので、請求書を印刷したらデーターは削除する機能ををつけておかないとハードディスクがパンクして受信ができなくなります。まあ、今（2011年現在）のPCにリプレースするなら、永久に残すようにしても問題はないと思います。今なら300ギガ500ギガ・・・というか１テラとか当たり前ですからね。PCの進歩は素晴らしいものです。

伝票の修正
伝票の修正とは、仕入れ伝票にて指示された商品が、在庫がなくて納品できない場合に使います。なにしろJCA手順は半二重の一方通行。受信しながらリアルタイムに在庫切れを相手サーバーに伝える、なんて事ができません。受信側はあくまで受信だけです。そのため、在庫切れで納品できない時は、紙の伝票上でその事を明記しなければなりませんでした。

しかも、この頃は商店の方では在庫をコンピューターで管理してない所がほとんどで、修正ももっぱら手入力でした。伝票番号を入れて、修正したい伝票を画面に表示させて、該当部分の訂正数量を入れるという画面を作る必要があります。それなんで、どうしても受信データーをデーターベースに入れる必要があるわけですね。

修正できるのは納品日と数量だけですが、ストアによっては納品日の修正は認めない所もあるので、納品日の修正が可能かどうかは事前に確認してください。

数量は減らす事はできても、増やすことはできません。じゃないと、ストアの方でも発注した分以上に納品されて請求されたって困りますからね。修正を作る場合でも、入力ミスなどで元の数量よりも増やせないようにチェックする必要がります。同様に、納品日も指定日より前にはできないし、○日以上後にはできないと定められている事がほとんどですので、仕様をよく確認して入力チェックをしてください。

数量にしろ納品日にしろ、どこかを修正した時は、「訂正区分」の有に○をつけます。


これは、仕様書には大文字のOを打つように指示されてますが、全角の○でも特に問題にはなりませんでした。ただ、有や無になかなか狙って打つのは大変なので、大抵のストアではどちらかを****で消すのでも良いとされています。

こっちの方が、○をつけるよりは場所がシビアじゃないのでお勧めです。半角の*なら10CPIで印刷していればちゃんと合いますので。

訂正をする時は、必ず元の注文数も印刷し、それを=（イコール）で二重印字で削除します。なので、データーベースにも元の数量は残しておかねばなりません。右に訂正数量という欄がありますので、そこに訂正後の数量を印刷します。


二重印刷をするために、まずは訂正のない内容を印刷して、改行幅を一時的に０にして改行した後、=====と訂正後の数量を印刷します。本当はこの後に金額も訂正する必要があるのですが、これは後で説明します。改行幅を０にする方法は、PR201系でしたらここ、 ESC/P系でしたらここを見てください。訂正が終わったら改行幅は1/6インチに戻しておいてくださいね。

数量を訂正したら、当然原価金額や売価金額も異なりますので、同様に訂正をします。といっても、訂正後金額という欄はないので、大抵の場合は、訂正後金額を上に印字します。ストアによって異なりますので、仕様書をよく確認してください。

単価に小数点がある場合、数量を修正した時に端数が出てしまう可能性があります。この場合の端数処理をどうするかは、仕様書に書いてあると思いますので、それに従ってください。大抵は円未満切捨てです。



合計金額は、ちゃんと訂正後の金額を書く欄がありますので、そこに印刷します。


また、在庫切れで全く納品できない場合（つまり、納品数０の場合）は、上記の訂正に加えて品名欄を======で削除するように指示されている場合が多いです。

※この商品コードは、キーボードを適当に打ったもので、実際とは異なります。

この、========をどこからどこまで引けばいいのかは、ストアによって異なりますので、ちゃんと仕様書を見て確認してくださいね。このサイトに書いてある通りに作ったのに審査に落ちたと言われても困りますので。

納品日を訂正する時は、「実納品日」のところに印字します。訂正がない時は空欄にしておきます。この場合、もともとの納品日の欄は====で消さない所が多かったです。

また、納品日の訂正自体を認めてない所もあるので、そういう時はこの訂正の入力自体ができないように作りましょう。

その納入業者が初めてＪＣＡ手順での受信を行う場合や、コンピューターのリプレースによってシステムを一新する場合は、テスト受信を求められます。これは、テスト用のデーターを受信して、それを伝票に印刷して、検査が合格になって初めてそのシステムでの稼動が認められます。

テストデーターは、「ﾃｽﾄｼｮｳﾋﾝ」という名前である場合が多いですが、めったにない数量や原単価の小数点も送られて来ます。また、行がいっぱいの場合と、行に空きができて「余白には記入しないでください」がちゃんと印刷されるかどうかもテストされます。

ここで注意して欲しいのは、検査に出す前に社内でもよく確認するという事です。どうしても作った本人は先入観があって間違ってても気づきにくいので、社内の別の人にも必ず見てもらってください。というのも、検査は合格か不合格かしか教えてくれない場合や、良くて不合格の箇所を１箇所だけ赤ボールペンで丸をつけられて戻って来るだけです。つまり、どこがどういけないのかは一切説明してくれません。

実際、３箇所に誤りがあった時に、１回のテストにつき１箇所だけしか赤丸がつけられなかったため、本稼動前に３度ものテスト受信をしなければならなかった事があります。テストは大抵有料ですし、その分納期も遅れますので、印刷の間違いには十分注意してください。 というのも、納品する側にしてみればテストが通らないとストアに納品ができず死活問題なのですが、ストア側にしてみれば仕入れ業者なんていくらでも代わりがあるため、親身になってアドバイスする必要はないのです。それなんで、大抵はストア側の検査や指摘は非常に意地悪です。リバイバーの最終シーンぐらいの無理ゲーをクリアするつもりで臨む必要があります。

後述の「ピッキングリスト」や「機会損失一覧表」はあくまで端末側のためだけに印刷するものなので、チェーンストアとのテスト時には送らないようにしてください。（送っても迷惑なだけですので）請求書はストアによってテストでの承認が必要な場合もあるので、ストアに確認してください。

ピッキングリストとは、どの商品を何個出荷しなければならないかを集計したものです。 これを出すためには、やはり受信データーをデーターベースに入れなければなりません。

なぜこのようなものが必要かというと、印刷された伝票はあくまでもチェーンストアにとって都合がいいように、納品店舗ごと、納品日ごと、納入担当者ごとに別々の伝票に分かれているからです。出荷する側からしてみれば、店舗や納品日や納入担当者は関係なく、何がどれだけ必要なのかが知りたいのです。

ここでいくつかポイントを説明しましょう。

◆タイトル
我々プログラマーは「ピッキングリスト」と呼んでいますが、エンドユーザーにピッキングリストと言っても意味がわからないので、「商品別集計票」などといったわかりやすい名前にします。

◆日付
経験の浅いプログラマはよく帳票に日付の印刷をするのを怠ります。しかし、実際にはこの帳票が事務所のどこかに散らばってしまった際には、それがいつの情報なのかはとても重要になります。この場合、印刷した日ではなく何日に受信した分のデーターかを掲載した方がよいでしょう。

1999年に世間が2000年問題で騒ぐまでは、西暦の年は下２桁で表示するのが通例で、西暦の年を4桁で表示してしたらかえってクレームになってしまいました。しかし、データーベース内では年はフルで記録した方が良いでしょう。なお現在は西暦の年は4桁で表示するのが通例です。

◆商品コード
伝票にはJANコードが掲載されていますが、JANコードは大手メーカーの既製品を除き、特に生鮮食品ではストアごとに異なる事が多いです。さらにJANコードは13桁と長く、納入側では独自の商品コードをつけている場合の方が多いです。なので、ここではJANコードではなく社内用商品コードを表示します。ただし、会社によっては社内で既にJANコードが浸透している場合もあり、その時はJANコードも併記します。

受信データーにはJANコードしか入ってないので、JANコードと社内用商品コードは商品登録によって紐付けする必要があります。

◆数量
この帳票は、あくまで何をどれだけ準備する必要があるかの資料ですので、普通は数量は訂正前の数量を表示するのですが、 中には訂正した後にまた出してみて「数量の訂正が反映されない。数量を訂正したんだから訂正後が出るのは当たり前だろ」って言う人もいますので、 必ず訂正前の数量を出すのか、訂正後の数量を出すのか、両方併記するのかを打ち合わせ時に確認してください。

◆レイアウト
この帳票はあくまで社内指示用ですので、見積書や請求書みたいにキレイでカッコイイ必要はありません。見やすければいいのです。

◆商品名
大抵は普通に商品名を表示すれば良いのですが、服や靴を扱ってる納入業者では同じ商品の色やサイズ違いがあります。その場合は、

のように、[商品コード・色・サイズ]の３つを含めたキーで集計した後、色とサイズごとに必要な数を印刷する必要があります。 こういうクロス集計帳票を作るのには、あるの程度スキルや時間が必要になってきますが、その分開発費を多くもらえる事は稀ですので、 その分のコストはプログラマーの企業努力（？）によって吸収するしかありません。

また、このような帳票では縦の線を出すか項目ごとの間隔をできるだけ広くあけないと見づらくなってしまいます。（という事は、上の例ではあまり良くありません。）

機会損失一覧とはこんな感じのリストです。



伝票の時と単価が違うではないかとか、行の印刷位置が微妙にずれてるとか、数量×単価とか金額の合計の計算が合ってないとか、卵１パックが全て100円のはずがないなどと言ってはいけない。もっと温かい目で作者を見てほしいものである。（って、それはDr.スランプか）

まあ、細かい事は気にせず概要だけ見てもらうとして（いいのか？そんなんで）、機会損失とは、在庫さえあれば売れていたはずなのに、在庫がなくて売れなかった一覧の事です。具体的には、伝票訂正によって納入数を減らしてしまった品物の数を、品物ごとに集計したものです。

この表であまり数の多い品については、優先的に在庫しなければならないという事です。また、逆に言えばこの表にないものを在庫しておくと、廃棄ロスにつながるという事です。

チェーンストア側も機会損失を最小限にしたいわけですから、あまり在庫切れが多い仕入先からは仕入れをやめてしまう事もあるため、機会損失は常に注意しなければなりません。同様に、生鮮食品を扱う以上は廃棄ロスも最小限にしなければならず、このような帳票で常に損失をチェックする必要があります。

請求書はチェーンストアで統一されたものは特にないので（注：あるかもしれないけど聞いた事がありません）、そのストア独自のものを使うか、ヒサゴやコクヨなどの既製品を使います。チェーンストア伝票が連続帳票なので、請求書も連続帳票を使うのが一般的です。



テストプリント
プリンターには、通常チェーンストア統一伝票仕入れ伝票が入れっぱなしになっていると思いますが、請求書を発行する際には用紙を交換するでしょうから、印刷位置が当然のズレます。したがって、請求書にもテストプリントが必要になります。

この見本はPhotoshopで作ったインチキなので印字位置が合ってませんが、通常は連続帳票は半角文字を1/10DPIで印刷すれば印刷位置は合うようになっています。

仕入れ伝票と請求書で、用紙の横幅が異なるため右のスプロケットを動かさないといけないのは仕方ないのですが、少なくとも左のスプロケットは動かさないで済むように作らねばなりません。でないと、仕入れ伝票と請求書を交換するたびにスプロケットの調節が必要になってしまうからです。

伝票番号と締日

請求書の伝票番号は、納品書や仕入れ伝票とは異なりその回の連番を打つのが普通です。これは、用紙自体が高価なため（１箱で約１万円弱）、途中で用紙がジャムった場合に最初からプリントしなおしでは印刷コストがかかりすぎてしまうためです。したがって、プログラムを作成する場合にも、途中ページのみを指定して印刷できるように作らねばなりません。ここで、00001と有効数字の左側にゼロを入れているのは、こうしないとスペースが空きすぎてしまうためです。

締日は、得意先ごとに異なります。大抵は月末締めか２０日締めです。月末締めの場合、31日ある月と30日しかない月があるので、間違った日付を入力した場合に画面に警告を出す等の措置をしておかないと、思わぬクレームになる場合があります。たとえば、5月の請求書を出すのに間違えて締日を95/05/30と入れてしまうと、5月31日の出荷分が丸損になってしまいます。２月ではうるう年かどうかの判別もしなければなりません。PHPのように指定月の末日を計算してくれる関数がある言語なら良いのですが、COBOLの場合は自前の計算ルーチンが必要になります。

「西暦が4で割れたら閏年」という安易な計算でも、西暦2100年まではバグにならないのですが、100年に一度閏年ではない年があり、400年に一度閏年ではない年ではない年があります。たとえば、西暦2000年は100で割れるのですが400でも割れるため閏年ではない年ではないので閏年という事になります。我々の子孫達が自分の作ったルーチンをコピペして流用する事も考えられるので、できれば恒久的に使える処理にしておきたいです。

日付の年は西暦の下２桁をプリントしていますが、これは当時（1995年）の慣習でこうなっていたためです。西暦を4桁表示するようになったのは、1999年にマスコミが2000年問題を大きく報じてからです。それまでは、日付を４桁で表示させたり、４桁の入力を求めたりするとクレームになってしまいました。

請求書に掲載するのは、納品日が締日までの発注です。発注日が5/31で納品日が6/1であれば、それは6月分の請求となります。とはいえ、データーベースには5月納品分も6月納品分も混在しているでしょうから、プログラムで判断して分ける必要があります。

前回繰越金額

前回の請求金額から、実際に入金があった金額を差し引いたものが繰越金額です。まさか大手チェーンストアが支払いが滞る事はないとは思いますが、汎用的な販売管理では処理ルーチンを作らねばなりません。

という事は、逆に言えば入金処理の入力をしないと請求金額がどんどん繰り越されて雪だるま式に請求金額が増えてしまうという事です。「大手の支払いが滞る事は絶対にあり得ない」「入金処理なんて面倒」というケースもあるので、その場合、入金処理というメニューを作らずに、プログラムの方で入金処理をしていなくても入金されたものとみなして御入金額、繰越金額を印刷する必要があります。

これはけっこう重要で、これらを曖昧にしたまま入金処理なしで作ってしまうと「繰り掛けが発生しているのに売り掛け処理ができない」と言われたり、逆に入金処理ありで作ってしまってユーザーが入金処理という作業を行わずに請求書を発行して、「請求金額がおかしい」「バグではないのか？」というクレームになったりします。特に、入金されているにもかかわらず先月分まで合わせて請求してしまうと、ストア側が激怒して取引停止という事態にもなります。入金処理が必要な場合は、当月の期間に入金処理がない場合に何らかのメッセージが表示されると親切です。

消費税
ＪＣＡ手順でのチェーンストアとの取引では、通常は外税です。つまり、仕入れ伝票には消費税は含まれておらず、請求時に月の合計に消費税をかけて請求します。ただし、これは私がこの業務を行っていた1995年までの話であり、2004年から外税表示が義務化されたため、ルールが変わっている可能性があります。必ずストアの方に確認してください。

税率は途中で変更になる場合があるので、表には現れませんが明細行ごとに税率を持たせておく必要があります。月の途中で税率が変更になった場合にも対応できるように、（変更前の税率の売り上げ金額）×(変更前の税率)　＋ （変更後の税率の売り上げ金額）×(変更後の税率)と言う風に計算しなければなりません。（注：税率をかけるといっても、5％だからって5をかけるわけじゃないですよ。5％なら0.05ですからね。）

消費税の端数は大抵は切り捨てですが、四捨五入の場合もあるので、どちらでも管理画面から変更できるように作らねばなりません。さらに特殊な例として、消費税を請求書の改ページごとに計算して端数を切り捨てるように指定される場合もあります。その場合、その顧客だけの専用ルーチンが必要にあんると思います。なんでも、改ページごとに消費税の端数を切り捨てにすると、全仕入先に対して年間で通すとけっこう大きいそうです。

消費税率を設定するためには、通常は管理マスターを使います。税率と端数処理を設定できるようにします。消費税が変更になる時は、通常では（といっても１回しか変更された事はありませんが(2011年現在)）○年○月○日納品分から○％という風に決められます。受信データーにはさまざまな納品日のデーターが混在していますので、管理マスターの方でも「○年○月○日納品分から○％」というように税率の変更またぎ期間に対応できるようになっている必要があります。特に20日締めで請求する得意先には区間またぎが発生する可能性が高いです。

今回請求額
今回請求額は、繰越金額＋税抜売上額＋消費税です。

請求明細

この明細はキーボードを適当に打って作ったものなので、伝票No.や品番や単価は、先の仕入れ伝票の例とは異なります。

明細の１行が伝票の１行に相当します。単価は仕入れ伝票の「原単価」です。というのも、チェーンストアから見た「売単価」とは小売価格の事であって、ストアに納品する業者の側から見た「原単価」がストアに対する「売単価」になるためです。

もし明細が０の場合・・・つまり、その月にまったく売り上げがない場合でも、繰越金額がある場合は請求書を発行する必要があります。単に売り上げ明細をソートして出力するだけのアルゴリズムだと、繰越があっても出力されません。別途、繰越があればヘッダーだけでも印刷されるようなアルゴリズムにする必要があります。

締日更新
請求書を発行したら締日更新を行います。 これは当月の消費税額、当月請求額を確定させて、当月請求額を前月請求額にしなければならないためです。 外税の消費税は、その月の合計金額にかけるものですので、請求書発行後に過去の伝票の数量を変更すると、 消費税がつじつまがあわなくなってしまいます。 仮に修正して減った金額分の消費税を前月請求額から引いたとしても、端数処理の関係で誤差が出てしまいます。 したがって、締日更新後の納品書の数量は、変更する事ができないように作らねばなりません。 締日更新後に間違いに気づいた場合は、もう仕方ないので、翌月の入金処理で相殺するしかないです。 締日更新は不可逆変化なので、更新前に修正忘れがないか、請求書のプリント忘れがないか、よく確認するようにメッセージを表示してください。

打ち合わせ時の注意
このように、単に「請求書を出す」といっても、作るためには閏年の計算から消費税の計算、税率変更への対応、入金処理の有無、繰越金額の管理、などなど、かなりのコストがかかります。というか、受信処理よりも数段こっちの方が大変です。

そのため、単に「ＪＣＡ手順の受信プログラムを作る」という仕事を受注したからといって、受信処理を作る事に全神経を集中させるわけにもいきません。必ず請求書が必要なのかを確認してください。請求書がいる場合、入金処理の有無や消費税の計算方法（外税・内税、端数の処理など）も詳細に打ち合わせしなければなりません。

よくやる失敗に「打ち合わせ時に請求書が必要だって言われなかったから作らなかった」というケースです。この場合、「納品書が出るんだから請求書も常識的に出るんだと思っていた」と言われます。この"常識的に"と、"だと思っていた" というキーワードはしばしばプログラマを苦しめます。こういうケースでは大抵は納品後に問題になり、翌日の受信開始までの間に請求書の部分まで全て完成を迫られます。こうなると、ジェバンニみたいに一晩でやらないといけなくなります。当然、翌日の受信にも立ち会わないといけないので、まる２日寝ずに作業なんて事もあります。おまけに、その仕事の受注時に金額は既に決定してますので、請求書発行プログラムにかかるコストは金額に上乗せもできません。

それを防ぐために、必ず打ち合わせ時に請求書が必要なのかを確認してください。 会社の代表者は業務に疎い場合もあるので、 実際にコンピューターを操作するオペレーターも打ち合わせに参加してもらってください。 でないと、会社の代表者と打ち合わせしたにもかかわらず、オペレーターの進言によって不良品扱いされてしまうケースもあり得るからです。

参考文献
オンライン取引の手引き イ禁則事項ですドー