過去の桐井戸端ＢＢＳ　（桐ver.８）

19333	納品書＆請求書と売掛台帳システムの作り方	しぼうかん	2003/03/12-22:02
桐ｖ８.sp６を使って納品書＆請求書と売掛台帳システムを作ろうとしています。 今は納品書＆請求書を先に入力してこのデータを基に売掛台帳を作成しようとしているのですが、 別ツリーで売掛台帳を入力してそこから逆に請求書を発行する方法が有ることを知りました。 そこで一般の会計ソフトのシステムなどを知らないので不安になってしまったのですが、 桐でこのシステムを組む場合、納品書＆請求書から売掛台帳作成、と売掛台帳から納品書＆請求書を作成の どちらかが標準的な方法なのでしょうか、それともどちらも有りなのでしょうか。 もちろん会社内容によって違って来るとは思うのですが、 もし今のやり方が全く特殊な方法であるなら今の内に標準的な方法に変えてしまった方が 後々システム作りのトラブルが少なくて済むような気もします。 標準的な方法は知らないがうちではこうですよといった主観的なご意見でもけっこうですので 情報を頂ければ助かります。
19339	Re:納品書＆請求書と売掛台帳システムの作り方	悲しげ	2003/03/12-23:45
記事番号19333へのコメント どもっ、しぼうかんさん >今は納品書＆請求書を先に入力してこのデータを基に売掛台帳を作成しよう >としているのですが、別ツリーで売掛台帳を入力してそこから逆に請求書を >発行する方法が有ることを知りました。 これはきっと私が書いたことに関係あるんでしょうね。(^^;) で、私はそのような方式を、いわゆる「浦本」から学んだと云うことに過ぎませんので、 「標準的」かどうかは、私にはまったく判りません。 つーか、それ以外のやり方を使ったことがないので何ともコメントし難いところであります。 ただ一点だけコメントすれば、上記は「どちらか」と云う問題でもなく、 云ってみれば「どちらも」だと思います。 脂肪肝さんは「請求書」と一括していますが、 このことを敢えて別な云い方（請求伝票と集計請求書）として説明してみます。 Ａ．掛売上伝票＝納品伝票＝請求伝票を入力発行する。 　（請求「伝票」であることを強調しておきます） Ｂ．並行して入金伝票入力もあります。 Ｃ．これらを売掛台帳に転記保存します。 　（転記後、ＡとＢの伝票は空にする） Ｄ．月締めの請求書＝「集計」請求書は、Ｃの売掛台帳の中から、 　　任意の締日、任意の期間、任意の得意先について、請求すべき 　　データを絞り込み抽出して作成・印刷・発行する。 と云う訳で、「納品書＆請求書を先に入力してこのデータを基に売掛台帳を作成」と 「売掛台帳を入力してそこから逆に請求書を発行」とは、 それぞれ独立した別なやり方なのではなく、ひとつの一連の流れの中の各局面に過ぎない、 と云うことです。 あ、私の場合は、ですが。
19344	Re:納品書＆請求書と売掛台帳システムの作り方	masa	2003/03/13-02:01
記事番号19333へのコメント しぼうかんさん 今晩は。 >そこで一般の会計ソフトのシステムなどを知らないので不安になってしまっ >たのですが、桐でこのシステムを組む場合、納品書＆請求書から売掛台帳作 >成、と売掛台帳から納品書＆請求書を作成のどちらかが標準的な方法なので >しょうか、それともどちらも有りなのでしょうか。 私も桐で全てを作りたいと思いながら現状の仕事に追い回されなかなか進みませんが、 データを入れる物（納品書）を入力した物が加工され、元帳に反映され、 請求書が発行されるのではと思います。 請求書を発行するにも入金状態を管理する表が必要と思いますので 全て別の表と言えば別ですし、データが入った後はつながりがあるのでどれも同じにも思えます。 私は仕入れから管理して、売上管理、在庫管理を最終目標にしているのですが 実際には発注した段階で情報（単価等）がないと、 仕入れ伝票が来るのが遅い時があるので売り上げが付けにくかったり、 訂正すると在庫も変わってほしいので日々の在庫表が必要かなとか思ったりしてます。 データが多くなった時、結合表で作った場合と普通の表で作った場合とは どっちが早く開けるのだろうとか悩んだりします。 長々とすみません。
19357	Re:納品書＆請求書と売掛台帳システムの作り方	悲しげ	2003/03/13-12:08
記事番号19344へのコメント どもっ、masaさん 独立した表としての台帳を持たずに、売上データと入金データ（＋得意先データ等）から、 随時「結合」で台帳データを取得する方法も確かに有りでしょうね。 その方がディスクスペースとしても有利かもしれないし、 確かに「いかにもリレーショナルデータベース」って感じがしますね。 （私は結合苦手なんで使ってませんけど）(;_;) >データが多くなった時、結合表で作った場合と普通の表で作った場合とは >どっちが早く開けるのだろうとか悩んだりします。 この点は私も少々気にかかってはいます。 特に残高は結合時にその都度取得することになりそうですからね。 結合は（併合等に比べると）凄く速いとは思いますが。 話が例によって余談に流れますが(^^;)── 実は、会計（税務）処理を（現在は弥＊なる市販アプリを使ってますが） 何とか桐でやりたいとの気持ちは数年前からありまして、その際に上記の問題を考えていました。 主要な個々の帳簿（「現金出納帳」とか「経費帳」とか）を別表として用意しておいて、 総データ表である「仕訳日記帳」(弥＊用語かな？)は 随時結合で取得させるのがよいのだろうか？ あるいは、ともかく入力データは全て上記「仕訳日記帳」に保存させ、 各種帳簿は、随時そこから絞り込んで操作するのがよいのか？ いずれにせよ、残高と繰越額の問題は付随して来ますし、 それと入力データの転記先の問題もからんで来まして、要するに未だに未着手っつー訳で。(^^;)
19361	出力結果（印刷結果）から先に決めるのがコツになろうかと思います。	ONnoji	2003/03/13-15:46
記事番号19333へのコメント しぼうかんさん、こんにちは。 >桐ｖ８.sp６を使って納品書＆請求書と売掛台帳システムを作ろうとしています。 >そこで一般の会計ソフトのシステムなどを知らないので不安になってしまっ >たのですが、 >桐でこのシステムを組む場合、納品書＆請求書から売掛台帳作 >成、と売掛台帳から納品書＆請求書を作成のどちらかが標準的な方法なので >しょうか、それともどちらも有りなのでしょうか。 すいません、揚げ足をとるつもりは無いのですが、 桐ver.8で作る場合も、他のソフトで作る場合も大差は無いと思います。 そもそも、標準的な作り方などないような気さえします。 ソフトに人間を合わせるのか？人間にソフトを合わせるのか？ と、いう話題もありましたが…少し違う話題です。 そうですね… 現在の会社で行っていることを、そのまま機械化するということが失敗しないコツだと思います。 もちろん、そっくりそのままというわけにいきません。 手で書くところをキー入力等するわけですから、 それまでの人間のみの場合にはどうでもよかったことが、 機械に処理させるために、こまごまと入力基準やコード化基準などを作る必要があります。 しかし、機械化のために発生する新しい事柄は、まったく本質的では無いとおもいます。 機械で処理するから、仕方なくそうするだけなんだと思います。 いわば派生的な雑用ですね。 仮定の話ですが、たたえば機械でなく新しく雇い入れた宇宙人に仕事を任せると思ってみても良いと思います。 ※あまり良い例ではありませんですが…ご勘弁を。 もしも、この宇宙人はまったく日本語によるコミュニケーションができないとすれば、 ボデーランゲージで指示するしかありません。 しぼうかんさんは、機械の方がマシ？、それとも宇宙人の方がマシ？ですか… つまり、仕事を誰かにやらせること、その相手が機械だというだけのことなのはないでしょうか？ すいません、釈迦に説法のようなことを書いてしまいました。 しかし、… 現在の会社で行っていることを、そのまま機械化するということが本質だと思います。 その際には、使用するソフト側の都合などは、最初は無視する方が賢明かとおもいます。 事務処理を機械化する場合のコツとしては、出力結果を重視することのようです… そこで、今まで見たことも無い立派な帳票を印刷して見せて皆を驚かせるより、 従来から見なれた印刷物と同じ物を出力する方が皆から喜ばれます。 ですから、出力結果（印刷結果）から先に決めるのがコツになろうかと思います。 これが標準的な作り方と言えなくもありませんかね。 そうですね…開発業者は必ず、入力と出力を先に決定します。 途中（処理：プロセス）の部分は、それがどんなに出来が悪くても、 あるいは素晴らしい傑作であったとしても、 利用者にとってはなんの意味もありません。 つまり、途中（処理：プロセス）の部分はブラックボックスなんです。 しかし、しぼうかんさんの眼にはこのブラックボックスの中身が透けてしまうわけですね。 それは、しぼうかんさんが利用者と開発者を兼任している事から生じる悩みではないでしょうか。 以上長々と書いたのは、 私( ONnoji )から、開発者としての「しぼうかんさん」へのアドバイスということになるでしょう。 >もちろん会社内容によって違って来るとは思うのですが、もし今のやり方が >全く特殊な方法であるなら今の内に標準的な方法に変えてしまった方が後々 >システム作りのトラブルが少なくて済むような気もします。 >標準的な方法は知らないがうちではこうですよといった主観的なご意見でも >けっこうですので情報を頂ければ助かります。 簿記会計ソフトならば、法律や会計学の裏付けが必要ですが、 それ以外の、事務処理ソフトを作るのならば、あまり気にする必要はないと思いますよ。 機械化によって、今まで３日かかったものが１０分で終わるというのが本当の目的なのですから… ただし、逆に入力作業が新しい手間として増えるかもしれません。 しかし、その手間を差し引いても、（大抵の場合）効果が絶大と予想されますね。 いや〜とりとめが無くなりました。大変失礼しました。m(__)m それでは。…(@^^)/~~~
19365	老婆心ながら	ONnoji	2003/03/13-18:15
記事番号19361へのコメント しぼうかんさん、こんにちは。 老婆心ながら、もう少し述べさせていただきます。m(__)m 皆様は桐に慣れていらしゃるので… 表( .tbl )や結合表( .viw )等といったファイルを中心に考えがちになると思いますが、 最初は、会社の現場を一日中でもいいですから、納得できるまでじっくりと眺めるのがいいと思います。 他人の仕事内容を聞いても、そりゃすぐに理解できるわけではありません。 まず、ゴールになる「ご請求書」などを確認して、 「ご請求書」を作る段取りを調べて、などと順番に流れを遡っていくわけです。 そうすると、すぐには見えないけれど、だんだんと仕事の流れが見えてきます。 ところで、この時点でファイルのことに考えを巡らせるのはまだまだ早いのです。 そうではなく、机上に仮想的なものとして、 ゴールから逆走すれば… ご請求書 → そのために必要な台帳 → 台帳に記入するための伝票 また、スタートから順走すれば… 出荷伝票 → 出荷伝票の綴り → 出荷台帳 途中には、返品伝票や訂正伝票や絞め日の作業などがあることでしょう。 このように机上に大まかな流れを描いて全体の構成を大雑把に把握します。 ※ここで細かく流れを記述すると失敗します。 ※細かいところは後で確認すれば済むことです。 全体像が掴めたところで… 出力帳票のイメージをデザインをします。 入力画面のイメージをデザインをします。 これらは最初はラフで構いません。 後で大事なことが抜けているのに気が付くことが多いものです。 出力帳票が何個必要か？入力画面が何個必要などは、この時に大体決まります。 最後にこれらの机上プランを素にして…データ設計を始めます。 ※データ設計を後回しにして、論理設計を先にしてしまうと失敗します。 そして、これを桐ver.8ならばどうするかと、またしばらく時間をかけて考えます。 大抵の場合、現実の「伝票」や「台帳」に対応する「ファイル」を作ることになります。 考えあぐねたら、いくつかの試作品を作って、自分の構想を確かめてみてもいいでしょう。 だいたい頭の中のイメージが固まってきたら、それは一気に原型を作ってしまうといいですね。 時間をかけると忘れたりしますから、一気に作るといいです。(^^ゞ と、またまた余計なことを長々と書きましたが、 業者などは現場を見ても、その時にはファイルのことは考えないということを言いたかったのです。(^^ゞ 業者などがファイルのことを考えるのは、現場の流れを（ほとんど）すべて読み切って、 最後の段階であるアプリケーションを実際に作る時です。 また、とりとめが無くなりました。大変失礼しました。m(__)m それでは。…(@^^)/~~~
19368	Re:納品書＆請求書と売掛台帳システムの作り方	しぼうかん	2003/03/13-20:15
記事番号19339へのコメント お返事ありがとうございます。 >これはきっと私が書いたことに関係あるんでしょうね。(^^;) はい、非常に。(^^;) >私はそのような方式を、いわゆる「浦本」から学んだと云うことに過ぎませんの >で 浦先生の本はＶ５時代に本屋で読んだ記憶がぼんやりと有りますが今はＭＳ地方へ転勤された様で残念です。 ただ、たくさんのシステムを組まれてきたであろう浦先生の方法には当然何かの意味があると思いますので、 その意味がわかればいいなと思って、この方法についてぼんやり、じっくり、ぼんくり考えて見ると、 全ての作業を手作業で逐次処理した場合の手順をそのままシステム化した"普通"なシステムだと思つきました。 そこで「浦先生の代理人」といったら怒られそうなので、(^^;) 浦方式のユーザーさんへ今後のシステム作りの参考の為に１つ質問があるのですが。 脂肪肝を直すにはどうしたら・・・じゃなくてＡとＢの伝票を転記後、空にする意味は何でしょうか？ 通常、手作業の処理の場合でも請求伝票=納品伝票の印刷控えは保存するので 履歴という意味からも保存する方が自然に思うのですが。 >ただ一点だけコメントすれば、上記は「どちらか」と云う問題でもなく、云って >みれば「どちらも」だと思います。 これは多分、かってに解釈すると「納品書＆請求書と売掛台帳＆入金台帳（前回書き忘れです） という区分でなく納品書＆入金台帳＆売掛台帳＆請求書は編集するフォームは 別々だけれど本来システムとして一体であるべき物」と理解しました。 私は作りやすい所から順に少しづつ作って来たので （納品書データを売掛台帳に転記する処理は当時の私には難し過ぎて考えもしませんでした。） 最初の投稿の様に納品書＆請求書（注１）と売掛台帳＆入金台帳（抜けていました）といった妙な区分けをしてしまいました。 たぶん最終的には自社の特殊事情（注２）がに合わせた特殊な作りのシステムになるとは思うのですが、 出来るだけ"標準的な方法"（注３）の考えを取り入れて作ることで、 後々システムの修正や機能追加が非常に難解になったり、 また不可能になったりする可能性を減らす事が出来きたり、また将来、自社のシステムが変更になり、 特殊な方法をとらなくても良くなった場合にも短い期間に自然に移行できる様に作って置きたいと思っています。 いろいろな方のシステムや問題点といった情報は本などから手に入れる事が出来ないので大変参考に成ります。 情報提供ありがとうございました。 （注１）とりあえずこの２つで閉じたシステムは出来てはいるのです。 　　　　が、売掛台帳と入金台帳を組み込む為に一度壊さなければ成らない気がしてきました。 （注２）請求書に入金欄が無く、請求金額が例えば２月に２万の売上げが有り、 　　　　１万の入金があり、３月に３万の売上げがあった場合３月の請求書は４万では無くて３万になる） （注３）よく使われる方法という意味で、１つの方法だけをいった意味ではありません）
19369	Re:納品書＆請求書と売掛台帳システムの作り方	しぼうかん	2003/03/13-20:20
記事番号19344へのコメント はじめまして、masaさんお返事ありがとうございます。 >データを入れる物（納品書）を入力した物が加工され、元帳に反映され、請求書が >発行されるのではと思います。 悲しげさんやmasaさんもやっておられるこの方法が普通なのかもしれないですね。 システム作りの考えが"普通"のシステムからかけ離れていたら、いくら豊富で柔軟な機能を持つ桐であっても 機能の修正や追加をして行く内に修正不能状態に陥る可能性があるのではないかと思いました。 私の場合は最初に全体を見てシステム作りを始めた訳でなく、 信じられないかもしれませんが、まず納品書のデータを入力して印刷し、 その後、請求書発行時に請求書用にまた同じデータを入力し、 納品書の金額を卓上計算機で計算して合計額を請求書合計欄に入力して印刷するという方法、 全くデータベースらしからぬ方法を実行していたのです。 その後、作りやすい所から順に少しづつ作って来たので （納品書データを売掛台帳に転記する処理は当時の私には難し過ぎてでした） 最初の投稿の様に納品書＆請求書（注１）と売掛台帳＆入金台帳（抜けていました）といった妙な区分けを してしまいました。 たぶん最終的には自社の特殊事情（注２）がに合わせた特殊な作りのシステムになるとは思うのですが、 出来るだけ"標準的な方法"（注３）の考えを取り入れて作ることで、 後々システムの修正や機能追加が非常に難解になったり、また不可能になったりする可能性を減らす事が 出来きたり、また将来、自社のシステムが変更になり、特殊な方法をとらなくても良くなった場合にも 短い期間に自然に移行できる様に作って置きたいと思っています。 いろいろな方のシステムや問題点といった情報は本などから手に入れる事が出来ないので大変参考に成ります。 納品書に入力したデータと入金台帳データから売掛台帳を作成する方法はまだじっくりと考えていないのですが、 ぼんやりとイベントを使って併合などで出来ないかなと思っていたのですが、結合表に関しては余り考えていませんでした。 結合表は制限が多いような先入観があり、今までほとんど使っていなかったのですが、 もう一度見直す価値があるような気もしてきました。 一度、納品書＆請求書のシステムを離れて、まず、納品書と入金台帳から結合して 売掛台帳を作る方法も考えてみたいと思います。 情報提供ありがとうございました。 （注１）とりあえずこの２つで閉じたシステムは出来てはいるのですが、売掛台帳 　　　　と入金台帳を組み込む為に一度壊さなければ成らない気がしてきました。 （注２）請求書に入金欄が無く、請求金額が例えば２月に２万の売上げが有り、１万の入金があり、 　　　　３月に３万の売上げがあった場合３月の請求書は４万では無くて３万になる） （注３）よく使われる方法という意味で、１つの方法だけをいった意味ではありません）
19370	Re:老婆心ながら	しぼうかん	2003/03/13-20:23
記事番号19365へのコメント ONojiさん、なんとなく佐田先生にも似た本に出てくるようなわかりやすいシステム作りの講義 いちいちなるほどと思い読ませて頂きました。（私の無駄に長い説明と違い、わかりやすい説明は長くないです) >現在の会社で行っていることを、そのまま機械化するということが失敗しないコツだと思いま >す。 はい、今作ってある納品書＆請求書の発行システムは現在の会社で行っていることをそのまま機械化したつもりです。 ただあまりに特殊（というか変？）な為、他の方になかなか使い方を説明するのが難しいです。 私は作りやすい所から順に少しづつ作って来たので（納品書データを売掛台帳に転記する処理は 当時の私には難し過ぎて考えもしませんでした。）最初の投稿の様に納品書＆請求書（注１）と 売掛台帳＆入金台帳（抜けていました）といった妙な区分けをしてしまいました。 たぶん最終的には自社の特殊事情（注１）がに合わせた特殊な作りのシステムになるとは思うのですが、 出来るだけ"標準的な方法"（注３）の考えを取り入れて作ることで、後々システムの修正や 機能追加が非常に難解になったり、また不可能になったりする可能性を減らす事が出来きたり、 また将来、自社のシステムが変更になり、特殊な方法をとらなくても良くなった場合にも 短い期間に自然に移行できる様に作って置きたいと思っています。 >仮定の話ですが、たたえば機械でなく新しく雇い入れた宇宙人に仕事を任せると思ってみても >良いと思います。 あはは、実は、我が社にも宇宙人がおりまして、この宇宙人は権力が有り、システムをコロコロと変えてしまうので いつも苦労しています。(^_^;) >すいません、釈迦に説法のようなことを書いてしまいました。 もちろん釈迦が説法の間違いですよね？ >簿記会計ソフトならば、法律や会計学の裏付けが必要ですが、 >それ以外の、事務処理ソフトを作るのならば、あまり気にする必要はないと思いますよ。 はい、もちろん簿記会計ソフトを作ろうなどと大それた考えではなく 現在のわずかな業務の効率化とミス防止が目的です。 質問で一番知りたかったのは桐のどの機能を使ってシステムを作るかというより、 ONojiさんがおっしゃっている様な考え方やファイルの関連づけなどだったのですが、 さらに「もし桐で作るならこういうやり方があるよ」と実際に作られている方がおられれば、 次に進むときの作成の手引きになると思って期待していましたが、十分に手引きとなる情報を頂きました。 教えて頂いたことを参考にシステムを作って行きたいと思います。 長々と書いてしまいましたが、ありがとうございました。 （注１）とりあえずこの２つで閉じたシステムは出来てはいるのです。 が、売掛台帳と入金台帳を組み込む為に一度壊さなければ成らない気がしてきました。 （注２）請求書に入金欄が無く、請求金額が例えば２月に２万の売上げが有り、１万の入金があり、 ３月に３万の売上げがあった場合３月の請求書は４万では無くて３万になる） （注３）よく使われる方法という意味で、１つの方法だけをいった意味ではありません）
19373	Re:納品書＆請求書と売掛台帳システムの作り方	悲しげ	2003/03/13-22:05
記事番号19368へのコメント >>ただ一点だけコメントすれば、上記は「どちらか」と云う問題でもなく、云って >>みれば「どちらも」だと思います。 > >これは多分、かってに解釈すると「納品書＆請求書と売掛台帳＆入金台帳（前回 >書き忘れです）という区分でなく納品書＆入金台帳＆売掛台帳＆請求書は編集す >るフォームは別々だけれど本来システムとして一体であるべき物」と理解しました。 う〜ん、一寸違うような・・・・「本来システムとして一体であるべき」と 云うからには、それぞれ独立した別なやり方を何とか一体化するよう努力すしたいとのニュアンスを感じます。 私が書いたのは「べき」論以前に、元々既に一体のデータであるようなシステムを 使っていると云うことです。 だから#19339では >それぞれ独立した別なやり方なのではなく、ひとつの一連の流れの中の と話が続いている訳です。 ＊ >脂肪肝を直すにはどうしたら・・・ これはやっぱし食事と運動でしょう。 いわゆる「糖尿病食」ってのは、 万病にいいと思いますので、参考にしてください。 >・・・じゃなくてＡとＢの伝票を転記後、空にする意味は何でしょうか？ う〜ん、いやぁ、浦本がそうなっていたから・・・。(^^;) 色々なケースでそれぞれ意図が違ったりするでしょうけど、 １）入力専用の作業表でもって入力すること──これは入力作業の効率化と云う点で 色々と入力専用のノウハウとかも盛り込めるからじゃないかと思います。 例えば、データ保存表（台帳）は次のＤのような表であるとしても、 入力用の売上伝票はメイン&サブ（対象表はＡ表とＢ表）を使うとか。 ※ Ａ表は[伝番][年][月][日][得意先][税抜計][税額][税込計]と云った、 いわばヘッダ・フッタ部を担う表。 Ｂ表は[伝番]以外は、[品名][数量][単価][金額]……と云ったいわゆる明細部各項目を担当する表。 ついでに云えば、入金入力作業表（Ｃ表）は、カード風になるでしょうから [伝番][年][月][日][得意先][入金額]……辺りでしょうか。 Ｄ表（保存表=台帳）はこれら３表の項目を合わせ持つことになるとか。 ※メイン&サブである売伝データの転記には、若干のノウハウがあるのですが ここでは略。 ２）転記した保存データは原則として書き換えるべきではない。 だから例えば[残高]項目等以外は、なるべく項目計算式を設定しないようにしておく。 品名の#表引きもさることながら、単価の#表引きなんぞもっての他だからです （売り上げたその時点の単価であることに意義があるので）。 つまり、保存表はあくまで保存表として扱うと云う考え方であるからして、保存表上で 新規データを入力すると云うのは、趣旨に反することになる、とか。 ３）ま、浦本の場合は、売上・入金伝票はあくまで一時的な作業表に過ぎず、 云ってみれば「売掛台帳を作成することが目的である」みたいなところ、 確かにありますね。 ま、現金販売が主体である小売業のような場合は、 伝票自体は Point Of Sale（販売時点）でレジでレシートとして発行している訳だから、 一部の掛売にかかる伝票自体には実際的な意味がない（印刷する必要性が薄い）ことになるから、 たまたま作業表で十分だった訳です。 ただし、売上・入金伝票表はデータは保存表（台帳）に転記した後に、 空にしてしまう前に（浦本に有ったかどうかは定かではないが）念のためデータを旧売伝控表・旧入伝控表にも 保存させるようにはしてあります。 殆ど再確認の参照用にしか使いませんけどね（伝票の再発行印刷は・・・今気がついたですが そもそも伝票の印刷操作を盛り込んでなかったりする）。ま、附録です。 他にもあるかもしれませんが、とりあえずこんな辺りでどうでしょう？ ps: 保存表を、当店の場合は売掛台帳（旧伝控は単なる附録）としていますが、 売掛台帳を作らずに旧売伝控・旧入伝控までとする考え方も有り得ると思います。 その辺は目的いかんでしょう。私は売掛台帳は頻繁に参照するので、 やはり既存表とあった方が便利かな、と云うことで。
19376	「案ずるより生むがやすし」かもしれません	ONnoji	2003/03/13-22:43
記事番号19370へのコメント しぼうかんさん、こんばんは。 >ただあまりに特殊（というか変？）な為、他の方になかなか使い方を説明するのが難しいで >す。 日本の場合には業種や業態によって仕事のやり方は千差万別だと思ったほうがいいですよ。 地域差もあるでしょうし、笑ってしまいますが会社の伝統なんていうのも有りそうです。 日本ではビジネスはあまり学問と結び付いていません。 外国ではビジネスと大学の研究が密接になっている場合が少なくありませんが… ですから、日本では業務アプリケーションは星の数ほど用意する必要があるように思います。 >私は作りやすい所から順に少しづつ作って来たので（納品書データを売掛台帳に転記する処理 >は当時の私には難し過ぎて考えもしませんでした。） 作り易いところから造るというので良いと思いますよ。 パソコンに熱中してばかりいるとコラ！売上上げろ！って叱られますからね。(^^ゞ >最初の投稿の様に納品書＆請求書（注１）と売掛台帳＆入金台帳（抜けていました）といった妙な区分けをして しまいました。 この説明の詳しいところは自信を持って理解できていませんが、 別に○×台帳だからといって、とくに有り難い物なわけではありませんよ。 ただ、伝票は台帳に転記しておくと、伝票をひっくり返して捜すより楽だ！という程度です。(^^ゞ 私は「仕入品の支払管理」アプリを頼まれて作ったことがありましたが、 その時には現実世界に仕入台帳というのがドデ〜ンとありましたので、 ただそれを真似て作ったようなわけです。 業務では台帳が必須というのは、あまりにも常識的な発想ではないかと思います。(^^ゞ 例外だって有り得るのではないでしょうか？ パソコンでは伝票入力の累積が台帳の役目をしますしね〜。 あまり難しく考えるのもどうでしょうか？ >出来るだけ"標準的な方法"（注３）の考えを取り入れて作ることで、後々システム >の修正や機能追加が非常に難解になったり、また不可能になったりする可能性を減らす事が出 >来きたり 一般に知られるような標準的な方法というのは無いのではと思います。 ソフト開発の会社だって、コーディング規約などは標準化しますが、 ファイル構成などは、客先がどんな業種・業態かによって千差万別なのではないかと思います。 アプリケーションの製作工程などにはある程度の標準化手法がありますが…これは意味が違いますね。 入力作業→台帳転記→請求書発行などといった流れには「標準」というものは無いように思います。 企業によって、あるいは企業内でも部門によってすべて異なる可能性が高いです。 したがって、私には「しぼうかんさんがおっしゃる標準的な方法」というの無いように思います。 ソフト開発の場合には、システムアナリス（分析）の段階で、客先の仕事内容・流れを把握します。 だから、これが標準です！なんてことは言わないように思います（たぶん）。 ※流通業のような場合には、新技術に対応するために、 「これが標準ですよ」と提案することはあるかもしれません。 それから、業務アプリは変化しますよ。 しかし、これは仕事の内容に合わせて変化するというべきでしょう。 変化に対応できない業務アプリは廃棄されて、あたらしい業務アプリを用意する必要があります。 これは仕方のないことだと割りきったほうがいいですよ。 また、後継者問題ですが、そのときになってから考えればいいのではありませんか。 従来の業務アプリを無理やり押し付けるより、後継者にもソフトを選択する権利があるように思います。 次の投稿へ続く
19377	続「案ずるより生むがやすし」かもしれません	ONnoji	2003/03/13-22:45
記事番号19376へのコメント ＜前の投稿よりの続きです。＞ >はい、もちろん簿記会計ソフトを作ろうなどと大それた考えではなく現在のわずかな業務の効 >率化とミス防止が目的です。 賛成！そうですね。 こういった使い方には効果が期待できますね。(^^ゞ >質問で一番知りたかったのは桐のどの機能を使ってシステムを作るかというより、ONojiさんが >おっしゃっている様な考え方やファイルの関連づけなどだったのですが ファイルの関連付けに関してご興味があれば、 リレーショナルデータベース関係の参考書から、「データ（表）の正規化」に関してお読みになると良いですよ。 ※蛇足参照 一般にリレーションシップと呼んでいるものですが、「データ（表）の正規化」がなされていないと使い物にはなりません。 ※これは桐では結合表ですね。しかし、桐は結合表を使わなくてもかなりのことが出来ます。 また長々と書いてしまいました、すいません。m(__)m 「案ずるより生むがやすし」かもしれません。それでは。…(@^^)/~~~ ＜追伸＞ インターネットでデータ中心設計のことを書いたＨＰを見つけました。 データ中心設計 http://www.e-owl.net/course/trial/demosystem/course/cont/page/00026T11-01-05-L.html 初めて見たこのＨＰはいわゆるシステム開発講座のようですが… 耳学問として面白いでしょうけれど、実際への応用は大変だと思います。 ご興味のあるところだけにして、決して鵜呑みにすることのないようにされたほうが良いと思います。 ※お上の資格を取得しようとしている人には参考になるかもしれません。 なぜデータ中心設計の話題を持ち出すかというと、論理設計を先にすると失敗するからです。 ＜蛇足＞ できれば、私( ONnoji )のＨＰの掲示板のログで紹介している参考図書をお読みになることをお勧めいたします。(^^ゞ
19391	ありがとうございました。	しぼうかん	2003/03/14-19:23
記事番号19377へのコメント そうですか、業種が多種多様である以上、あまり"標準的な方法"にこだわらなくてもいいのでは？と言うことですね。 正規化に関してはしばらく前に見つけたhttp://www.kogures.com/hitoshi/webtext/ のＨＰで、(ほとんどは難し過ぎるのですが)ちょっとは知っていましたが、 ONojiさんの紹介して頂いたＨＰでさらに勉強したいと思います。 たしかアメリカのことわざで壊れていない物は直すなというのがあったと思いますが、 とりあえず現在出来ている物は今のまま運用して進めて置いて、 時間がある時に別の方法（結合表も含め）も試して見るという方針でいこうと思います。 ONojiさん、いつも懇切丁寧で、噛み砕いた説明よくわかりました。
19392	ありがとうございました。	しぼうかん	2003/03/14-19:29
記事番号19373へのコメント 悲しげさんの具体的な説明を見てＡとＢの伝票を転記後、空にする意味はよくわかりました。(かな？) たぶんこれは顧客の中に不特定多数の得意先が存在するシステムだからという事が要因ですね。 つまり、場合により"納品伝票＝納品書＝請求書の一種＝レシート"という様な場合もあり、 このデータは"納品書"とかでなくて"売掛台帳"で管理するほうがやりやすいという事も想像出来ます。 私の所(印刷業)では不特定多数の顧客は無いので、たぶんここの所は浦本と違っていても問題無いような気がします。 >※メイン&サブである売伝データの転記には、若干のノウハウがあるのですがここでは略。 ここの所を売掛台帳を"結合表"で作るのか、併合などを使って別表で作るのか、 しばらく勉強して見ます。 ps >>脂肪肝を直すにはどうしたら・・・ > >これはやっぱし食事と運動でしょう。いわゆる「糖尿病食」ってのは、万病にいいと思い >ますので、参考にしてください。 食事は魚を増やし、量を減らすようにしてるのですが、仕事を終えた後、 又運動する気力がなかなか起きなくて・・・今年の健康診断が心配です。 ＨＮが"とうにょう"に成りたくないので。(^^;)
19403	はて(?_?)	悲しげ	2003/03/15-00:52
記事番号19392へのコメント しぼうかんさん wrote >悲しげさんの具体的な説明を見てＡとＢの伝票を転記後、空にする >意味はよくわかりました。(かな？) >たぶんこれは顧客の中に不特定多数の得意先が存在するシステムだ >からという事が要因ですね。 はぁ？　う〜みゅ、なぜこのように読解されるのか不思議です。(^^;) 得意先が不特定多数であることと、転記後に空にすることは全く関係ありません。 全て掛売り（云い換えれば得意先が全て特定）であるようなシステムでも、 転記後に空にすることはあります。 私が取り組んでいるもうひとつの「大作(^^;)」は、顧客が全て健康保険証番号で 特定できるタイプのものですが、それでも入力作業表での処理を終えた時点で転記後空にしています。 先に私が書いたことを再度まとめてみると ・空にするのは入力作業表に過ぎないから。 ・入力作業表を使うのは、入力作業の効率化のため。 ・肝心なのは転記後の保存表であること。 　そして保存表自体は原則として変更しない。 　（保存表に直接入力=変更するようなことはしない） ──あたりでしょうか。 なお、前回も書いたように、その保存表のタイプは「台帳」風も有れば 「伝票のまま(控)」風も有り得ると思います。 その辺は用途次第。 ちなみに、転記後空にすることを勧めているのではありませんよ。 問われたので、理由と云うかその長所めいたところを説明しているだけです。 はて、上で「長所」と書きましたが、この方式の「短所」は・・・・、 ちょっと思いつきませんね。このやり方にあまりにも囚われすぎているからかも。(^^;)
19405	Re:転記後空に（追補）	悲しげ	2003/03/15-01:33
記事番号19403へのコメント 拙作「大作(^^;)」においては、入力作業表から保存表に転記する 過程で、在庫数量その他も更新させてたりします。 これらも「転記後空に」方式ならでは、かも。
19409	注意深い人や業者などは作業ファイルを使いますよ	ONnoji	2003/03/15-13:13
記事番号19333へのコメント しぼうかんさん、こんにちは。 悲しげさんの枝に割り込むと混乱するので、こちらに気がついたことを書かせていただきます。 このツリーの悲しげさんの枝に次のようなこと書いてありました。 >・空にするのは入力作業表に過ぎないから。 >・入力作業表を使うのは、入力作業の効率化のため。 >・肝心なのは転記後の保存表であること。 >　そして保存表自体は原則として変更しない。 >　（保存表に直接入力=変更するようなことはしない） >──あたりでしょうか >拙作「大作(^^;)」においては、入力作業表から保存表に転記する >過程で、在庫数量その他も更新させてたりします。 >これらも「転記後空に」方式ならでは、かも。 これは、 作業ファイル → 台帳 ※作業ファイル読み込みと同じ ですが、これは標準的な手法ですね。 ソフトに付属しているサンプルアプリなどでは、 いきなり本物のデータに追加や訂正をしていますが…(-_-メ) 注意深い人や業者などは、必ず作用ファイルを経由して本物のデータを変更します。 手業ファイルを使うと、一見すると面倒なのですが… 安全性や堅牢性が増しますので、アプリ製作では基本的な手法といえるでしょう。 しかし、少し複雑になる（見えるだけ）ので、サンプルアプリではあまり見かけることはありません。(T_T) この辺がソフト付属のサンプルの悲しいところでありまして… 残念ながら、本当に実用的な使用方法を示してくれないのであります。 ※日本製でもＵＳ製のどちらのソフトでも同じです。 悲しげさんの「大作」では（私は少しだけしか拝見していませんが…） 作業ファイル → 出荷台帳 　└→　在庫マスターの更新 というように、作業ファイルを反映する際に、在庫更新も同時に行っているのだと想像できます。 したがって、これは作業ファイルですから、 用が済んだら、いったんクリアされるか、または削除されるはずでして、 このような使用法は、注意深い人や業者などにとっては普通の使用法です。 しぼうかんさんが気になって仕方がなかったことというのは、このことだったようですね。(^^ゞ ＜蛇足＞ Windows版の桐には「トランザクション」コマンドが追加されていますが、 あまりにも芳しいことを聞いたことが無いので、使用しない方が無難だと思います。
19411	答案用紙です。（国語）	しぼうかん	2003/03/15-18:45
記事番号19405へのコメント あっははは。 毎度、毎度、わかりましたっ!と手を上げて答えると先生にそれ、ちっがーうよ！ あっさり言われてしまう自分の理解力の無さはあきれてしまいます。 最初にお返事を頂いたときの、 >Ａ．掛売上伝票＝納品伝票＝請求伝票を入力発行する。 の部分を自分のシステムに合わせて誤解して（一度誤解してその考えで内容が 解釈出来てしまうとずっとその方向で解釈を掛けてしまいました。）流れを、 納品書入力と印刷→売掛台帳作成→請求書入力と印刷と考えてしまいました。 そしてかなり自信が無い解釈なのですが、ＡはＣの売掛台帳を作る為だけが 目的の入力用であり、私が考えていた納品時に先方へ渡し、 先方で保管され、こちらから請求書送付時に検証して確認する為の伝票としても利用される"印刷される納品書"のデータを 入力して保存するフォームでは無いと言うことでしょうか？ ※ちなみに先方に送付する請求書には入金欄や明細欄が無いので 何をどれだけ納品したかは"先方へ送付する納品書"が無いと先方で請求内容のチェックは出来ません。 だとすると売掛台帳と納品書と請求書の関係だけでいうと、 流れでいうならばまず入力用のフォームＡからＣの売掛台帳へ転記保存し、 ここからデータを抽出して、私の考えている"納品書"を印刷したり、Ｄの"請求書"を 印刷したりすると言うことなるのでしょうか？ どうでしょうかこの解釈は○をもらえますか、それともmore　wrote？
19412	注意深くない人より	しぼうかん	2003/03/15-18:47
記事番号19409へのコメント どうも理解力不足でお恥ずかしい限りです。 悲しげさんの「大作」は以前ダウンロードして見ましたが、私レベルでは何が何だかチンプンカンプンでした。 >しぼうかんさんが気になって仕方がなかったことというの>は、このことだったようですね。(^^ゞ はい、こういうことだったんです。 もちろんそのままこの方法が今のやり方に当てはめられるかどうかはわかりませんが、 基本を知っていれば何かと応用も利かせやすいと思っていたので。 たぶん実際の作業をそのままシステム化していたら悲しげさんに教えて頂いた考えには至らなかったと思います。 私の所の実際の作業の順で行くと １.納品書入力と印刷、 ２.請求書の入力(発行日を入力するだけ)と印刷、 ３.売掛台帳への入金と納品内容と請求額の記帳（現在は手作業） という順になっています。 >手業ファイルを使うと、一見すると面倒なのですが… ここをいかに面倒にしないかが工夫のしどころみたいです。 わざわざ鈍い解読力の頭用に解説のフォローありがとうございました。
19414	大切なファイルを直接操作しないこと。	ONnoji	2003/03/15-20:31
記事番号19412へのコメント しぼうかんさん、こんばんは。 >たぶん実際の作業をそのままシステム化していたら >悲しげさんに教えて頂いた考えには至らなかったと思います。 実際の作業をそのまま機械化するという意味と、 作業ファイルを使用するということは別の問題ですよ。 >私の所の実際の作業の順で行くと >１.納品書入力と印刷、 >２.請求書の入力(発行日を入力するだけ)と印刷、 >３.売掛台帳への入金と納品内容と請求額の記帳（現在は手作業） >という順になっています。 作業ファイルを使用するというのは、 大切なファイルを保護するという意味合いが高いのです。 例えば… 入力フォームを開く 　　↓ ［納品台帳］ 　　↓ 表の枠組を書き出し 　　↓ ［作業ファイル］を用意する 　　↓ 変数を使ったフォームで入力作業 　　↓ ［登録］なら作業ファイルに［行追加　項目＝＆変数］ ［取り消し］なら変数を初期化 　　↓ 入力フォームを閉じる、または［転記］を選ぶ 　　↓ ［納品台帳］に［作業ファイル］を読み込む 　　↓ 　おわり 大部簡略な説明ですが… といった具合で、［納品台帳］を直接操作しないのが基本です。 また、［納品台帳］を訂正する場合には… 納品台帳保守フォームを開く 　　↓ 納品書番号を入力 　　↓ 納品書レコードを検索 　　↓ レコードの値を変数に代入 　　↓ 変数を使ったフォームで修正作業 　　↓ ［登録］なら作業ファイルに［行訂正　項目＝＆変数］ ［取り消し］なら変数を初期化 これも同じように大部簡略な説明ですが… ［納品台帳］を直接操作しないことになります。 DOS桐では変数を使ったフォームが使えないので、 変数の代わりにさらにもうひとつ余計に作業ファイルを用意する必要がありました。 Windows桐では変数を使ったフォームが利用できるので大部楽になりましたよ。(^^v もしも、このような方法を標準と呼ぶのなら、もちろん標準です。 COBOL や BASIC でも同じような方法を使うはずです。 つまり、大切なファイルを直接操作しない（というよりは、普通はできません）ということです。 例は相当に簡略していますので、実際にはもう少し複雑ですが… 注意深い人や業者などにとっては普通の使用法というのはこういうことです。 しかし、このようなことをシステム化と呼ぶわけではありませんよ。 これは普通トランザクション処理と呼んでいるものであって、普通の処理のことです。 もう一度、 実際の作業をそのまま機械化するという意味と、 作業ファイルを使用するということは別の問題ですよ。 長々となりましたが、このことをご説明したかった次第です。
19415	大分わかって来ました。	しぼうかん	2003/03/15-22:32
記事番号19414へのコメント >例えば… >入力フォームを開く 　　↓ 　　↓ 　　↓ >これも同じように大部簡略な説明ですが… >［納品台帳］を直接操作しないことになります。 いえいえ、桐で普通の作法によってシステムを実際に作ろうとする時の中継地や目的地は 十分にわかりますので参考にさせて頂きます。 ただ、一つだけ確認したい所があるのですが、納品書や請求書の"印刷"のボタンは[納品台帳] （売掛台帳の事ですよね）のフォームにあるという理解であってますでしょうか？
19416	作者の好みやデザイン次第で変わりますから	ONnoji	2003/03/15-23:14
記事番号19415へのコメント しぼうかんさん、こんばんは。 >ただ、一つだけ確認したい所があるのですが、 >納品書や請求書の"印刷"のボタンは[納品台帳]（売掛台帳の事ですよね）の >フォームにあるという理解であってますでしょうか？ 難問ですね〜。(^^ゞ ＜データに関して＞ 通常は画面で確認することを主としますが、 しかし、あまりに情報が多かったりすると、印刷するという手段も必要になります。 印刷を副とする場合も多いでしょうね。 例えば、残高確認は通常は画面で確認できれば済みますが、 印刷したい場合だってありますよね。 ＜書類に関して＞ 相手先に提出する書類は当然印刷できなければなりません。 この場合は、印刷を主として、画面確認を副とすることになるでしょうね。 ［印刷］ボタンがどのフォームにあるかというより、 必要があれば用意すれば良いということではありませんか？ しかし、納品書であれば、出荷時に印刷するでしょうし、 また相手先が納品書の再発行を要求する場合もありますね。 ※売上請求する対象ならば、もちろん売り掛けですね。(^^ゞ 請求書であれば、月単位の処理でしょうから、 ［月末処理とかなんとか］の中の［請求書発行］という部分でしょうね。 ここでは、画面プレビューと印刷の両方の機能が必要でしょうね。 しかし、こればっかりは、作者の好みやデザイン次第で変わりますから、 いろいろと案を練ってみたらいかがでしょうか？ しかし、案ずるばかりでいるよりは、一歩進める方が良いような気がしてなりません。
19420	（国語）答案のすり変わり？　(^^;)	悲しげ	2003/03/16-01:49
記事番号19411へのコメント #19368でのしぼうかんさんの質問は 「ＡとＢの伝票を転記後、空にする意味は何でしょうか？」 だった筈です。 そして、それに対する応答が、19373-19372-19403の流れだった筈です。 しかるに、#19411のしぼうかんさんのコメントは、一見した感じからすると、 元々の質問であった「転記後空に」問題については雲散霧消してしまって、 別な話題にすり変わっているかのようにも見えます。 このような「話題のすり変わり」は、実はネットではしばしば見られることではあるのですが、 一般的には「悪しきスタイル」であると認識すべきだと思います。 特に、『Ｑ＆Ａ』が主眼となっている本掲示板の特殊性から云って、 ひとつのツリーにおける主題は、できる限り固定されていることが望ましいと云えます。 この点は、現象的にひとつのツリーが長くなってしまうと云う「量」の問題ではなく、 ツリーの「質」の問題に関わっていると思います。 ま、しぼうかんさんの問題意識が、総論−各論入り乱れているようですから(^^;)、 仕方がないかなと云う面は、この間お付き合いさせていただいてきただけに重々承知できますけれども、 ま、今後はひとつ意識的に「話題のすり変わり」ふうにならないような努力を期待させていただきます。 以上は前振りです。(^^;) >流れを、納品書入力と印刷→売掛台帳作成→請求書入力と印刷と考えてしまいました。 請求書を「入力」することは無いので、「請求書入力と印刷」の部分を 「請求データ作成(抽出)と印刷」と読み替えれば、そのとおりの受け止め方でよろしいです。 >ＡはＣの売掛台帳を作る為だけが目的の入力用であり、私が考えていた納品時に先方 >へ渡し、先方で保管され、こちらから請求書送付時に検証して確認する為の伝票とし >ても利用される"印刷される納品書"のデータを入力して保存するフォームでは無いと >言うことでしょうか？ この長いセンテンスの主語が「Ａは」なのでしょうか？ とすれば「Ａは……保存するフォームでは無い」です。 なぜならＡは（転記後空にする）入力作業表だから。 で、（もし転記後空にする入力作業表的な方式を使うと仮定するなら）何度も書いているように、 問題の中心は「転記保存する表をどのようなものにするか」になると思います。 あとは引用はしませんが、しぼうかんさんのところが、入金／繰越残高に一切関与しない、 売上積算だけの請求書を発行するものであるとすれば、例えば次のふたつのやり方なんかを想像してみました。 １）納品時に３枚の伝票を印刷する。１枚目は先方に渡す納品伝票、２枚目は当店控、 そして３枚目は月締めで請求する際に先方に渡す請求伝票（月内に複数存在すればホチキス等で束ねるとか）。 この場合の保存表は、いわば「伝票そのまんま再印刷可能な形式」としておくことになろうかと思います （３枚目は納品時に印刷せずに請求時に再印刷するのでもいいかもしれない）。 ２）あるいは請求の書式が、請求伝票の束ねではなく、 う〜ん、云ってみれば「月内請求明細一覧表」のようなものであるとすれば、 保存表は、納品明細を転記したいわゆる「台帳」形式になろうかと思います。 請求時点では、この台帳の中から当月相当の期間内の納品データを絞り込んで 一覧的に印刷させることになろうかと思います。 主論は以上です。余談が少しありますが、それは別稿とします。
19421	別稿の余談です	悲しげ	2003/03/16-02:04
記事番号19420へのコメント （こちらにはコメント不要です、いやコメント戴いてもいいですが）(^^;) 入金／繰越額の類が除外されている請求書発行と云うやり方がかなり変則的であることは、 しぼうかんさん含めて了解が成立しています。 で、しぼうかんさんとしても、将来的・長期的には（あるいは可能であれば）、 ここら辺りを抜本的に何とかしたい（入金／繰越額も反映させるシステムにしたい）との 希望があるようにも取れます。 ここまでは判ります。 で、問題となるのは、現在書かれたり質問されたりしていることが、その希望（抜本的改良）の実現を目指したものなのか、 今回はそこまでは諦めて変則的なままでの微改良のレベルのものなのか、それが判別し難いと云うことです。 もしかすると、しぼうかんさん自身が（半ば無意識的に）その両方を射程に入れているからなのしれないし、 あるいはそんなことはないのかも知れませんが(^^;)、 つまりはその辺りが第三者にも明確に判別できるように問題を提出して戴けることをリクエストしておきます。<(_ _)>
19422	Re:（国語）答案のすり変わり？　(^^;)	悲しげ	2003/03/16-02:22
記事番号19420へのコメント #19420の補足です。 >２）あるいは請求の書式が、請求伝票の束ねではなく、う〜ん、云ってみれば「月内 >請求明細一覧表」のようなものであるとすれば、保存表は、納品明細を転記したいわ >ゆる「台帳」形式になろうかと思います。・・・・ 売掛「台帳」は、一般的には売上にかかる明細の他に、（前年度）繰越額や[入金額]、[残高]の項目を持っています。 しぼうかんさんの場合に使う「台帳」はこれらから売上明細にかかる項目以外のものを除去した形式のものを作ってもよいですが、 逆に将来性を見越して上のような一般的な形式としておいて、 売上関連データのみを入れておくのもグーかと思います。 後者の場合、残高欄が１年分の累積表示となるのも面白いですが、 いつの日か繰越額や入金額も転記しさえすれば、残高も生きる一般的な台帳に変身できますから。
19423	自己レスです	ONnoji	2003/03/16-09:11
記事番号19416へのコメント これは私( ONnoji )の自己レスですからリプライは不用です。 悲しげさんが、別の枝でこのように書かれています。 >入金／繰越額の類が除外されている請求書発行と云うやり方がかなり変則的であるこ >とは、しぼうかんさん含めて了解が成立しています。 確かに、請求書を発行しておいて、売り掛け管理を行わないというのは一般的には変ですね。 しかし、従来手で作成していた請求書を機械で発行したという意味ならば理解できます。 つまり、ワープロ的な処理ですね。 これを、データ処理的に発展させる… つまり、売り掛け管理のアプリをこれから作るのであれば、 未回収や繰り越しの問題をきちんと処理する必要がありますね。 ウ〜ム、ここが問題だったのか。 その際のデータ設計の問題であったのか。 売り掛けの問題だったら、 簿記の教科書か、 ビジネスマン向けの書籍で販売管理関係をあたれば、 おのずと糸口がつかめると思うのです。
19474	Re:（国語）答案のすり変わり？　(^^;)	しぼうかん	2003/03/18-19:13
記事番号19420へのコメント 返事が遅れて大変すいませんでした。 NO19422へのコメントです。 >ま、今後はひとつ意識的に「話題のすり変わり」ふうにならないような努力を期待させていただきま >す。 はい、今後気をつけます。すいませんでした。 現在は複写伝票を印刷に使い、まさに、ほぼ悲しげさんがおっしゃっている通りの１）の方の使い方をしています。 複写伝票なので請求明細として使う３枚目に関してはは納品書と同時に印刷してしまい、 請求時まで保管して請求時に請求書とホッチキスで止めて送付しています。 NO19421へのコメントです。 >で、問題となるのは、現在書かれたり質問されたりしていることが、その希望（抜本的改良）の実現 >を目指したものなのか、今回はそこまでは諦めて変則的なままでの微改良のレベルのものなのか、そ >れが判別し難いと云うことです。 これは頂いたお返事の内容により、その方法が現在の業務内容の中で可能で有れば抜本的な改良の実現を目指し、 もし現在は不可能であっても、標準的な方法を知って置くことで、 出来るだけいい方向へ改良をしたいと思って最初の投稿をしたのです。 NO19422へのコメントです。 >売掛「台帳」は、一般的には… 説明しなかったのですが、売掛台帳は一般的な物なので、[入金]欄も[残高]欄も[備考］欄も有ります。 そして最後にもう１つだけ質問させて頂きたいのですが、 ONojiさんにもほぼ同じ質問をさせていただいたのですが、もう少し具体的に、 入力専用の作業表から売掛台帳へ転記後、納品書を再印刷しなければならないとしたら、 この納品書の印刷のボタンを配置するのは、悲しげさんが同じ状況で作られるならば、 「売掛台帳」のフォームですか？
19475	返事が遅れて大変失礼しました。	しぼうかん	2003/03/18-19:16
記事番号19420へのコメント 余談です。（自分のミス分析）　 なぜ話題のすりすり替わりがおきたか原因を考えてみました。 （でないとまた同じ事を繰り返す危険性があると思ったので） 最初の投稿時の自分の考えは下記あ１）〜あ３）の様になるのかなと考えていました。 あ１）納品書フォーム(対象表：納品書.tbl)→(グループ化)→請求書フォーム（対象表：納品書.tbl） あ２）納品書フォーム(対象表：納品書.tbl)→(併合？)→売掛台帳フォーム(対象表：売掛台帳.tbl) あ３）入金フォーム(対象表：入金台帳.tbl)→(併合？)→売掛台帳フォーム(対象表：売掛台帳.tbl) ※(併合？)は具体的にどういう方法をとるかまで考えていませんでした。 しかし、頂いた返答によると納品書.tblのデータは売掛台帳.tblへ転記後、空にするとの事なので、 納品書の最初の印刷は転記前に行うとしても、納品書の再印刷の時にはどうやってするのかな？ という事を知りたい為に「NO19368の"ＡとＢの伝票を転記後、空にする意味は何でしょうか？」 という質問をしたつもりなのです。 それに対してNO19373の１）〜３）特に３)の >現金販売が主体である小売業のような場合は、伝票自体は Point Of Sale（販売時点）でレジで レシートとして発行している訳だから、一部の掛売にかかる伝票自体には実際的な意味がない （印刷する必要性が薄い）ことになるから、たまたま作業表で十分だった訳です。 という所をコンビニなどのレシートをイメージして誤解した結果NO19392の様な独解をしておしかりをうけてしまいました。 そこでもう一度NO19373の答えを解釈しなおして、NO19411の投稿をしたのですが、 ここでNO19411でいっている >そしてかなり自信が無い解釈なのですが、ＡはＣの売掛台帳を作る為だけが目的の入力用であり、 私が考えていた納品時に先方へ渡し、先方で保管され、 こちらから請求書送付時に検証して確認する為の伝票としても利用される 「印刷される納品書」のデータを入力して保存するフォームでは無いと言うことでしょうか？ この後に「もしそうであるならＡとＢの伝票を転記後、空にするということはわかります。」 と続けておけばよかったのだと思います。 しかし、そうである事(納品書や請求書や売掛台帳のデータは売掛台帳.tblにだけ保存するいう事)を 前提に、その場合の自分が思いついた問題点（納品書や請求書や売掛台帳の印刷や再印刷はどうするのか？ つまり印刷ボタンの配置場所）を質問してしまった事が原因で質問のすり替えにつながったのだ思います。 自分なりの結論として >だとすると売掛台帳と納品書と請求書の関係だけでいうと、 流れでいうならばまず入力用のフォームＡからＣの売掛台帳へ転記保存し、 ここからデータを抽出して、私の考えている"納品書"を印刷したり、 Ｄの"請求書"を印刷したりすると言うことなるのでしょうか？ この質問部分は最初の質問への返答を理解し、 また理解したことを相手にも理解してもらったのちに次の質問ですればよかったのかなと考えています。
19476	返事が遅れて大変失礼しました。	しぼうかん	2003/03/18-19:21
記事番号19416へのコメント 返事が遅れて大変失礼しました。 >例えば、残高確認は通常は画面で確認できれば済みますが、印刷したい場合だってあります >よね。 実はうちの会社ではパソコンを操作出来る人間がほとんどいません（たぶんパソコンに対する拒絶反応が原因でしょうが。） そこでパソコンで全て処理を行うとデータがブラックボックス化してしまう為、"納品書"や"請求書"と共に"売掛台帳"も 紙への印刷が必須となります。 >しかし、納品書であれば、出荷時に印刷するでしょうし、 納品後や納品前に発行する場合もあります。 また納品書発行後に数日して、金額訂正で再発行などの特殊処理も時たまあります。 困った物なのですが(^_^; そこでよく言えばかなり柔軟なシステム、普通にいえば人為ミスを防ぐのが難しいシステムを作ることになります。 まあ最初に投稿した時に比べてたくさん情報や知恵を頂きましたので、 それをたよりに何とか"使える"システムを作りたいと思います。
19480	Re:最後の質問	悲しげ	2003/03/18-23:15
記事番号19474へのコメント #19474 >そして最後にもう１つだけ質問させて頂きたいのですが、・・・・ >入力専用の作業表から売掛台帳へ転記後、納品書を再印刷しなければならないと >したら、この納品書の印刷のボタンを配置するのは、悲しげさんが同じ状況で作 >られるならば、"売掛台帳"のフォームですか？ どのような前提をとるかで異なってくるのですが、もし前提を「作業表による売伝入→転記後空に」とするなら、 原伝票は既に存在しないので、再印刷は必然的に転記保存表（を編集対象表とするフォームのボタン等）から 行うしかありません。 とすれば、またまた同じことを書くことになるのですが(^^;)、 問題は転記保存表をどのような形のものにするか、と云うことになります。 「納品伝票の再印刷」を主要な目的とするならば、保存表は伝票丸ごと控タイプにするのが最も簡単だと思います、 そのまんまですから。 ただ、台帳タイプの表からでも可能です。[伝番]項目が必須であることは自明の前提ですが、 顧客コードの類と伝番辺りをグループ項目とするフォーム（編集対象表は台帳的な保存表）から印刷させるとか。 あるいはグループ項目が顧客コードだけのフォームで、ある伝番の行をクリックすることで、 その該伝番レコードを絞り込みさせてから印刷するとか。 ※ちなみに（このことも前に書きましたが）当店の場合の転記保存表は 売掛台帳タイプと伝票そのまま控タイプの２系統を確保しています。 伝票を再印刷させることはないけれども、必要があればどちらの系統からでも可能です （そのようにボタン等を配置しさえすれば）。 なお、今回のご質問はたまたま「納品伝票の再印刷」に限定されていますが(^^;)、 「請求書」の印刷にも関係して来ると思います。 複数伝票をある期間（月）で絞り込んで印刷させるのなら、 伝票まるごと控タイプよりも、台帳タイプの方が断然使いやすいような気はします。 で、月締め請求書を、納品伝票１枚毎に印刷させたいのなら、 レポート定義で[伝番]を改ページに設定すればよい筈です。 でも、折角月締めで再印刷させるのなら（複数伝票をホチキスで止めるよりも） １枚に一覧的に印刷させたものを出力する方がカッコいいように思えます。 私が受け取る側だとすれば、前もって納品伝票が来ているのに同じものが 請求伝票として束になって再来するのは勘弁願いたいです。 厚さと俯瞰性の点からも一覧表を好みます。 #19476 >また納品書発行後に数日して、金額訂正で再発行などの特殊処理も時たまあります。 この場合は、発行済みの伝票を直に訂正して印刷させるのではなく、 それはそのまま残した上で、訂正伝票（マイナス伝票）を新たに起こしてから もう１本正しい額の伝票を作成発行する、と云うのが正式な作法だと聞いたことがあります。 （履歴を正確に残すため） 当店の場合、月次の〆を越してしまった等の事情でそこまでせざるを得ないことがまれにはありますが、 大抵はそこまではしないでもう１本正しい額の伝票を起こした上で、 間違った伝票を削除してしまいます（でも、手抜きであるとの認識はあります）。
19481	Do for it.v(^^)v	ONnoji	2003/03/19-00:09
記事番号19476へのコメント >まあ最初に投稿した時に比べてたくさん情報や知恵を頂きましたので、 >それをたよりに何とか"使える"システムを作りたいと思います。 しぼうかんさん、こんばんは。 今から思えば… 私にとってこのツリーは当初からご質問の意図があまりにも理解できていませんでした。 そこで… 私( ONnoji )としては、七転び八起き状態になったと反省しています。 ※私のハンドルネームは ONnoji でございますよ。 実はリプライはいただけないのではと反省しておりましたが、 りぼうかんさんからリプライをいただいて誠に恐縮です。 私の好きな言葉を書きとめて、この枝の締めくくりにさせていただきたいと思います。 Do for it.v(^^)v しぼうかんさん、今後のご活躍を心からお祈りいたします。 それでは、失礼いたします。…(@^^)/~~~
19501	最後の答えありがとうございました１	しぼうかん	2003/03/19-21:28
記事番号19480へのコメント "Ｒｅ：最後の質問"は自分の頭を整理するのに大変役立ちました。 まだ残っていた疑問に対する答えを見つける事も出来た気がします。 １） >「納品伝票の再印刷」を主要な目的とするならば、保存表は伝票丸ごと控タイプに >するのが最も簡単だと思います、そのまんまですから。 １−Ａ) 納品伝票の再印刷を主要な目的としているわけでは無いのですが、印刷物(納品書)と近い入力画面表示が わかりやすいので現在はこの形(納品書のメイン＆サブフォーム)でデータを保存しています。 ２） >ただ、台帳タイプの表からでも可能です。[伝番]項目が必須であることは自明の >前提ですが、顧客コードの類と伝番辺りをグループ項目とするフォーム（編集対象表は >台帳的な保存表から印刷させるとか。 >あるいはグループ項目が顧客コードだけのフォームで、ある伝番の行をクリック >することで、その該伝番レコードを絞り込みさせてから印刷するとか。 ２−Ａ） たぶんこの形なのかなとは思いましたが、いつも自分の想像はハズしてばかりなので確認したかったのです。 ３） >※ちなみに（このことも前に書きましたが）当店の場合の転記保存表は売掛台帳タイプと >伝票そのまま控タイプの２系統を確保しています。 >伝票を再印刷させることはないけれども、必要があればどちらの系統からでも可能です >（そのようにボタン等を配置しさえすれば）。 ３−Ａ） たしかに伝票そのまま控えタイプの話は見ていたのですが、あまり注視せず、 読んだというより、眺めた程度のようで、 その保存表を伝票を再印刷出来る形で保存する所までは考えを進めませんでした。
19502	最後の答えありがとうございました２	しぼうかん	2003/03/19-21:31
記事番号19480へのコメント ４） >なお、今回のご質問はたまたま「納品伝票の再印刷」に限定されていますが(^^;)、 >「請求書」の印刷にも関係して来ると思います。 >複数伝票をある期間（月）で絞り込んで印刷させるのなら、伝票まるごと控タイプ >よりも、台帳タイプの方が断然使いやすいような気はします。 >で、月締め請求書を、納品伝票１枚毎に印刷させたいのなら、レポート定義で[伝番]を >改ページに設定すればよい筈です。 ４−Ａ） いま現在は納品伝票の入力時に[得意先コード][締年][締月]などから [請求書番号]を自動的に入力してこの[請求書番号]をグループ項目にして 納品伝票のレコードをグループ化して請求書フォームを表示し、 そのフォームでグループ項目である[請求書発行年][請求書発行月][請求書発行日]を 入力後そのフォームから印刷する。 ※通常は請求書発行日は当然印刷時なので請求書入力フォームなどは必要ないでしょうが、 私の所の特殊事情で請求書発行日より前の日付で印刷したり、 後の日付で印刷したりするので必要になってしまいます。 ５） >でも、折角月締めで再印刷させるのなら（複数伝票をホチキスで止めるよりも） >１枚に一覧的に印刷させたものを出力する方がカッコいいように思えます。 ５−Ａ） そうですね。 自分が想像するには多分元々が手書きで書いていた納品書と請求書ですので、 例えば納品伝票の場合、手書きの場合は納品書(控)，納品書，請求明細書，受領書などで 同じ事を何度も書く必要が無い利便性からこれらを４枚を一緒にして使う複写伝票の形になったのだと思います。 しかしこれら４枚を印刷で行うので有れば確かに、複写伝票である必要は無くＡ４用紙２枚に分けて印刷すればいいと思いますし、 請求明細書も請求書とホッチキスで止めて、 などというカッコの悪い方法ではなくて請求書に明細部を作ってそこに一覧で表示するという形が理想です。 ここで教えて頂くまでは請求書や納品書には複写伝票が必須と思いこんでいましたが、 考えを改め、将来的にはその方向へもって行きたいと思います。 ただし、今はドットインパクトプリンタを買ったばかりで、 しかも、作ってしまった複写の請求書と納品書がまだ大量にある為にすぐに移行は難しいのですが・・・。 ６） >この場合は、発行済みの伝票を直に訂正して印刷させるのではなく、それはそのまま >残した上で、訂正伝票（マイナス伝票）を新たに起こしてからもう１本正しい額の >伝票を作成発行する、と云うのが正式な作法だと聞いたことがあります。 >（履歴を正確に残すため） >当店の場合、月次の〆を越してしまった等の事情でそこまでせざるを得ないことが >まれにはありますが、大抵はそこまではしないでもう１本正しい額の伝票を起こした >上で、間違った伝票を削除してしまいます（でも、手抜きであるとの認識はあります）。 ６−Ａ） この所は私も以前悩んだ事がありまして、納品書入力フォームの削除ボタンを押すと、 その削除したい伝票レコードが最後に入力された物の場合は完全削除をします。 また削除するレコードが、最後に入力された物で無い場合、 この伝票を削除すると[納品書番号]が連番にならず消えてしまうことに違和感を感じて、 (履歴を残すという考えは悲しげさんにいわれるまで知りませんでした。) [納品書番号]や[請求書番号]や[得意先名]をのこして[品名]や[金額]などの明細部を消去して、 備考欄には"この伝票は消去しました"と自動入力させています。
19503	最後の答えありがとうございました３	しぼうかん	2003/03/19-21:32
記事番号19480へのコメント "まとめと今の自分のシステム作成方針です" 私の現在の業務内容からいま一番簡単に出来る方法を、(システムＡ）とすると、 (システムＡ)は 《データの保存表としては納品書テーブルと入金台帳テーブルと売掛台帳テーブルの３種類とします。 それぞれメインサブフォームで編集を行います。 入力手順としては、まず納品書テーブルを対象表とした納品書入力フォームでデータを入力して （ここに納品書の印刷ボタンを配置）印刷時に、売掛台帳テーブルへ転記する。 入金台帳からの売掛台帳テーブルへの転記は月締後、必要な時に実行する。 請求書は従来通り、納品書フォームで入力した、データを[請求書番号]でグループ化した 請求書フォームで[請求書発行日]等を入力してこのフォームにあるボタンで印刷する。》 という形に成りますが、 同じデータが多く重複する売掛台帳テーブルと納品書テーブルを"売掛台帳"を印刷するときは 売掛台帳テーブルを使い、納品書と請求書を印刷する時は納品書テーブルを使うという保存表を ２種類使う（システムＡ）はデータベースのシステムとしては不自然な感じがするので 目標のシステムを(システムＢ)とすると (システムＢ)は 《入力作業フォーム(納品書用)から売掛台帳テーブルに転記したり、入力作業フォーム(入金用)から 売掛台帳テーブルに転記したりした後、この売掛台帳テーブルを対象表とする売掛台帳入力フォームに移動し、 そのフォームから納品書と請求書と売掛台帳を全て印刷したり、 売掛台帳テーブルを対象表とする納品書印刷用のフォームへ移動して印刷イメージを確認後印刷したりする形》にしたいと思います。 ポイントはフォームの形や種類ではなく、テーブルだと思いました。 ただ実際の作業としては業務を止める訳にはいかないので、現在既に出来ている納品書＆請求書の入力と印刷システムを使いながら、 追加して作成出来る(システムＡ)を作った後に(システムＡ)を運用しながら(システムＢ)を作って行き、 完成したら(システムＢ)に移行するという作業手順で進めていこうと思います。 繰り返しになるのですが、納品書と請求書と売掛台帳と入金台帳のデータベースで作ったシステムにおける関係について "標準"または"よくあるシステム"を知りたくて、最初の投稿をした訳なのですが、 紹介して頂いた標準のシステムがなぜそうなっているのか(総論)と実際の使い方(各論)への疑問点を 思いつくままに質問してしまった結果、総論、各論入り乱れてしまい、質問内容が非常にわかりずらい内容になってしまい ご迷惑をお掛けしましたが、いままで根気強く、おつき合いして頂いたおかげで 頭にあった"もやもや"が晴れてすっきり日本晴れです。ありがとうございました。
19504	大変失礼しました。そしてありがとうございました。	しぼうかん	2003/03/19-21:36
記事番号19481へのコメント あっちゃ〜ONnojiさん、ごめんなさい。m(_ _)m てっきりONojiと思い込んでいました。 前のツリーも見てみましたが最初から間違えてますね。 >今から思えば… >私にとってこのツリーは当初からご質問の意図があまりにも理解できていませんでした。 いつもの事ながら説明ベタ反省しております。 >そこで… >私( ONnoji )としては、七転び八起き状態になったと反省しています。 >実はリプライはいただけないのではと反省しておりましたが、 >りぼうかんさんからリプライをいただいて誠に恐縮です。 ONnojiさんが反省することは全く全然ありません。 というか反省しなきゃいけないのは私です。 ONnojiさん腰低すぎです。 でも、根気強くご指導して頂いたおかげで、何とか進む道の方向がわかりました。 長い間有り難うございました。 といっても、自分で長くする原因を作っているんですけどね。(^_^;)

戻る