Excelで以下のような販売個数を管理するものを作って使っています(仕事がら商品、といった分類はないので、個数と名前だけです)
日付 名コード 数量
と3行あり、それぞれにいれていきます
VBAで上の日付と名コードセルを自動コピーするようにしていて、数量だけを、資料をもとにいれまくるものです
日付や名コードが変わるときには手動で修正しています
入力したデータを日付や月ごと、日毎、名コードなどをピボットテーブルで集計して利用します
集計値をコピーして別のテーブル(請求書や支払い明細に)に貼ったりします
そこで質問です
1.
ACCESSにはピボットテーブルのようなものがありませんが、ある指定した範囲や条件の集計をひとつのレコードもして扱うことはできませんか?
2.
Excelのように立てにずっと入力していくのはACCESS的ではないようです
上部に日付と名コードを配置して下部に子テーブルとして数量をいれるフィールドを配置するものだと思います
このときに、キーボードからマウスに持ち替えなくていいように
任意のタイミングで、任意のキーを押すと、日付フィールドや名コードをアクティブにするのとはできますか?もちろんまた、数量フィールドにも戻りたいです
Excelでは単価計算もしているので数千、数万行になってきたら不安定になってきました。一応テーブル機能を使いましたが追加された行の色が再度開くまで適応されない、とか
よろしくおねがいします
クロス集計クエリというものがあります。
フォームを作成してテキストボックスを配置すると規定値プロパティが使えるので、VBAでこれを制御するのが分かりやすいと思います
キー入力時というイベントがあるので、これで任意のキー入力に対して特定のコントロールをアクティブにすることができます。
また、オプションに「Enterキー入力後の動作」があるので、これを変更するとExcelと似たような動作になります。
このオプションはパソコン(インストールされたACCESS)毎の設定をデフォルトから変えることになるので、環境ごとに設定が必要です。
ありがとうございます
今はピボットテーブルで集計してその値をコピペして請求書を作っています
請求書には別のシートからコピペしたものもあります
ACCESSだと、クロス集計クエリで集計した結果と、他のテーブルのレコードを
請求書レポートに並べることになりますが、かんたんに混ぜることはできますか?
各レコードには請求書番号を付与して、再発行や確認に使う予定です
集計結果に請求書番号を付与することはできないと思いますし
請求書作成時に、大本のレコードすべてに付与することもむずかしいでしょうか?
集計結果を1つのレコードとして扱いたい場合は、一旦EXCELで入力、集計してインポートするのが
一般的でしょうか?
前段階でクエリでデータを結合しておく、レポートにレポートを埋め込む仕組み(サブレポート)、VBAによる制御、等柔軟に対応する仕組みはあるので大抵のことはできますが、どの程度なら「かんたん」で済むのかは要件次第でしょう
ルールさえしっかりしていればできないことはないと思います。
ただ、請求書番号が未決定のレコードについて、新規で番号を取ればいいのか、集計で統合される別なレコードですでに決定されていないか、それらで請求書番号に矛盾がないか等の問題と対策が発生します。請求書番号は集計結果ごとの管理にしたほうが楽でしょう。
また、ちょっと難しい言い方になりますが、「印刷時に自動で請求書番号を決定するシステム」は難しいです。
プレビューで請求書番号を仮発行するのか、キャンセルした場合どうするのか、上記問題と合わせてどのような表示順にするのか
そして、これらを実現するための複雑な処理等、様々なことに悩まされることになります。
集計条件を記録するテーブルを用意してそこに条件を追加していけばいいです。集計結果自体は計算で求まるので記録する必要はないですし、そのテーブルに「請求書番号」フィールドを設ければ、集計結果の1レコードごとに「請求書番号」を管理することができます。
結局のところデータ構造自体はよくある「請求書」「請求明細」の構造と同じです。運用や作業性に合わせてどのようにシステムを組み込んでいくかという問題になると思います
くわしい解説ありがとうございます
集計条件を記録するテーブルを用意、というのはどういったものですか?
理解できなくてすみません
具体例を挙げていただければそれに合わせて回答もできるんですがたとえば
のようなデータがあったとして請求書が
となるような場合なら
集計条件を記録するテーブルは
になります
集計条件はいつ、どのように記録するのでしょうか?
集計条件に該当するデータの入力があったとき(日々のデータ入力のとき)
VBAで集計条件の有無をチェックしつつSQLを発行して
hirotonならこうするだろうというたとえです。実際には要件に合わせていろいろでるでしょう
繰り返しますが
結局のところデータ構造自体はよくある「請求書」「請求明細」の構造と同じです。運用や作業性に合わせてどのようにシステムを組み込んでいくかという問題になると思います
「請求書を発行する」という目的があるようなので今あるデータを使って請求書を作ってみるといいでしょう。ACCESSで実現するために(データベース的な考え方として)何が必要か見えてきますし、そのうえで「では、新しい請求書を発行するためにはどのようなデータ構造、入力・処理が必要か」というのが見えてきます
始めてみないとわからないと思いますよ?
テーブル作成、クエリ作成(テーブルのクエリ化)、フォーム作成(クエリのフォーム化)、集合形式から表形式に変更、高さ、上位置、左位置の微調整、単票フォームから帳票フォームに変更まで、頑張りましょう。
まず、テーブル作成ボタンを見つけて、データ型を選べますか?主キーのON/OFFを出来ますか?
次に、クエリ作成ボタンを見つけて、何をどうすればいいかわかりますか?テーブルを選んで、フィールドを選ぶだけですが。
最後に、フォームは、基本操作の解説動画を探して下さい。思い通りに移動させたり、大きくしたり小さくしたり、出来ますか?ワードやエクセルのように、雰囲気では無理です。
日付のプロパティ・・・・・既定値Date()
名コードのプロパティ・・・既定値ほにゃらら(数値型、短いテキスト型、既定値を決めて下さい。)
ここまでが準備です。Excel(表計算)みたいな何かを作る企画がスタートします。
業者に発注して、Excelみたいな何かを作ってもらうのが、早いと思います。
基本的に、上から下に入力するのが、Accessだと思います。左右と上下に入力するのは、Excelみたいな何かでしょう。基本的に、持ち替え(根回し)を避けられないのがAccessだと思います。何も考えずに超スピードで入力出来るのは、Excel的な何かでしょう。
データモデリングがポンコツならば、遅かれ早かれ、不安定でどこかおかしいAccessになると思います。根回しがしっかりしていれば、AccessみたいなExcelがあってもおかしくないと思うのですが。