Access総合相談所 28
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ OS、ACCESSのバージョンを明記してください。
★ 質問内容は具体的に書いてください。
・何がしたいのか
・どんな処理を試したか
・動作状況など駄目な理由
テーブル/フォームの構成、クエリ、VBAの内容など差し支えない
範囲で詳しく書くと、早く回答が得られるかもしれません。
図解があれば尚良し。
聞き返さなくても詳細が把握できる質問が望ましいです。
★ 事前にヘルプ・Google等で調べられる範囲は調べてください。
大概の疑問は検索することで解決します。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
ギブアンドテイクで情報を共有しましょう。
▼━質問テンプレ ━━━━━━━━━━━━━━━━━
【 システム環境 】 Windows**, Access**
【 VBAが使えるか 】 はい･いいえ
【 VBAでの回答 】 可･否
【 検索キーワード 】 Googleやヘルプでの検索キーワード
前スレ
Access総合相談所 27
http://mevius.5ch.net/test/read.cgi/bsoft/1424828244/ >>708
ありがとうございます！
ACCESS側の問題ではないようですし、一度SELECTで出力なりして
今一度WHEREの追加部分を再確認してみます Access初心者です。FOMっていうテキストを買って勉強を始めました。よろしくお願いします。 >>712
ありがとうございます。先は長そうですが頑張ります。 売上を入力して末締め処理で請求書をつくっています
資金繰り表を作りたいのですが
税金や様々な支払いなども同じACCESSのファイルに組み込んでやるものでしょうか？
別々に作成しておき、コピペや手動計算でEXCELのテンプレートに貼り付けながらやるものでしょうか？ そうゆうのに定石は無いと思いますよ
その会社次第、作る人次第
ですかね >>715
普通ならどちらのほうが良いと思いますか？ >>718
棒銀は将棋
将棋では石が使われないから定跡と書く 普通なら全部一緒の方が良いに決まってるじゃん
でも普通じゃない場合が多い
現状、何かの理由があって別にやってるんだろう >>719
囲碁の定石は、局地戦の必勝法的なやつ
将棋の定跡は、全体的に有利に進めるための方法みたいなので、盤面全体の動きを含む
同じようで、結構意味合いが違ったり 資金繰り表は、過去と現状と将来のデータを要求するものがほとんどだな
その語句でググって出てきたサンプルファイルとか、どれひとつ同じものは無い有様
税理士のサイトでサービスでExcelファイルとかDLできたりするけど
イマイチじぶんトコの状況にそぐわないモノが多い
いちばん良さげなのを自分なりに改良して使う ならExcelで充分
あくまでも予想・予測をメインとした帳票だから、記録・保存する意味もあんまし無いし
融資用に金融機関への提出を主眼とするなら尚更、その銀行がどういうデータを
欲しがってるかを見極めて、それに則したサンプルを探すだけだと思う 個人の感想やけど 提出帳票作るのにAccessは有効だが
単にデータ提供ならEXCELにデータ連携させてグラフ化とかさせる方が良いかもね
提出先の要求にもよる >>722
月々の利益などを把握するのはなんていう表になるんでしょうか？ ん？ 損益計算書系のハナシ？ 会計の範疇だ
貸借対照表とかキャッシュフロー計算書などと、財務三表と呼ばれてるうちのひとつか
その語句でググれば判り易く説明してるサイトはゴロゴロ出てくる アドレス貼ったら蹴られたから書かない
>>714 の最初の二行に惑わされたな 資金繰り表は、たいていの経営者ならざっくりとじぶんの
頭の中で把握してるものだが、それを一覧表で提出しなさい という人のために作るもの 個人の意見やけど 資金繰りなあ。仕入れと売上の両方のビルド必要でしょ。
個人的には会社の金勘定に関することはあまり自作しない。
スモールビジネスなら作るかもしれんけど。 >>714
そういう事は会計ソフトに任せたほうがよい。実も蓋もない答えだけど。
Acsessでやれるのは、見積もり・売上・入金・請求等、いわゆる販売管理まで。
請求事務の延長で回収予定表までは作ってもいいと思うけど、仕入れ管理は
してないでしょう。手形、現金、預貯金、借入金管理して、プラス残高試算表作
成しないと、資金繰り表は出来ないよ。素直に弥生とかを使おう。 >>727
「弥生会計」ですか？
決算書をつくったり簿記的なことをするわけではなくても会計ソフトでやるのが一番やりやすいんですか？
サービス業なので仕入れはほぼない、というか
社用車の整備くらいです > 資金繰り表を作りたいのですが
> 税金や様々な支払いなども
現金出納帳とか、小遣い帳とか どのメーカーも数万円代で高品質ですからね
買った方が、早くて安全です
財務会計が絡まないなら開発もアリですが おすすめはどのあたりのソフトになるんでしょうか？
現在、自社に合わせてEXCELやACCESSでやってる販売管理とは別にやるということになりますよね？
販売管理というかサービス業なのでいつどの仕事をどの従業員にやらせた
とかそういったデータです 書くことがコロコロ変わるなｗ 自分は何がしたいのかを書け
請求書を作ったのまでは判った 税金や支払関連をそれに繋げて将来の収支で
欠損出さずにうまく運営していくにはどういった方式が一般的か？ を聞きたいのか？
先ず、デカイ紙に一年分毎月の枠を作って、売り上げと支払を過去〜将来まで
分かってる範囲で書き出せ 毎月掛かる経費、人件費、税金は支払月（一括でも分割でも
期日はあるだろ、その月にその額を埋めとけ） それと収入を上下にでも左右にでも分けて
書き込め それをプラスマイナスしたのがその月の粗利だ
なにもキッチリ一円単位までちゃんと書く必要なんざ無い (千円) として、千円以下は丸めて構わない
それを何ヶ月か続けたら、じぶんが何を必要としてるか見えてくるだろ
その基本のキが無いまま、言われるがままにアチコチ手を出しても迷路に迷い込むだけだ
売上がキチンキチンと毎月必要額立つ商売ならそこそこ左団扇だろうけど、不安定で高収入だったり
低収入だったりの波が大きい場合は、上の紙情報がほんとに役に立つ
商売はモニターの中にあるんじゃない 現場で、生身の人間が汗と知恵を振り絞ってそうやって成り立つんだ 個人の感想やけど >>733
やりたいことは利益はでてるにはでてるが
結局いくら儲けてるのか曖昧ということです
売掛と買掛、税金の支払いやなんだかんだでよくわからなくなるので…… 掛けや税金の差し引きしなきゃいけない（よくわからなくなる）のに簿記的は事はしないって矛盾しないの 各会社のビジネスロジックはその会社独自
当然、こういう部分はAccessとかで作り込みが有効
でも会計業務は法律で規定されてるから会計ソフト使って定型作業するのが妥当
つまり会計関連業務はパッケージソフトを使う
それ以外の販売管理等はAccessで作り込む
その2つの連携で中小企業内部の事務作業はPC業務として効率化出来る、と言う話 >>736
法的に必要な書類は税理士に委託してます
すべての領収書や請求書などを渡して
決算書をつくってもらっています
税理士に頼まないとすると
ACCESSのデータを会計ソフトにインポートする感じですか？
ACCESSのデータを売掛金、などでまとめる処理が必要でしょうけど 逆に考えましょう。windows3.1ないし95が登場する前は事業所は
どういうふうに収入支出を記録し、
税務署への申告や決算書を作っていたか。ソフトはその原則と変わりません。
税理士あるいは会計士にすべて業務委託している場合は、その人が使っているソフトを使ってデータ交換することで、相手の作業量が減るので料金交渉が可能になります。
たぶんtkcの会計ソフトを使っていることが多いかな。
あなたのニーズの経営状態把握は
厳密性があまり必要ないので
売上管理、買掛管理、あるいは両方のデータを入れる会計ソフトから
一旦、汎用データ出力(csvやエクセルなど)して
Accessや表計算ソフトで加工するのが良いでしょう。
このレベルであれば表計算ソフトの式だけでも用は足りると思います 税理士に委託してる（自分でやりたくない）んなら税理士に必要な数字もらえばいいじゃん
税理士に委託したくないんなら自分で会計ソフトで管理するだけじゃん
面倒なことはやりたくないしお金もかけたくないけど必要な数字や処理は欲しいってわがままね accessで記帳して税理士にデータ渡すと、税理士が会計ソフトにデータを入れて、料金に記帳代行料が取られている件
どうせ金取られてるんだから、全部税理士に入力させろよ(笑) 普通はチェックだけしてもらうもの？
記帳して決算書をつくってお墨付きとらうだけ？ 法令で7年間保存が定められた帳票類を作成してもらう 個人なのか法人なのか、個人なら白色なのか、青色なのか。
いろいろわからんが、Accessで経理は止めた方がよい。
いずれにしても、例え記帳代行してもらうにしても、最低限の経理の知識は
身に着けておいた方がよい。
もはや経営相談だなw >>743
でかい会社でもない限り委託してる会計とは別に自分でわかるような感じやればいい
大した仕事量でもないだろうし だから自分で分かるような感じでやれるならやりゃいいだけなのに、
ACCESSでやるのか会計ソフトでやるのかどっちがいいの自分で分からないレベルだし、
会計ソフトが簡単ではという話に対しては税理士に委託してるからゴニョゴニョって
もうどうしたいんだよって話でしょ
ACCESSでもEXCELでも自分でゴリゴリできる人間ならこんな質問しないでしょ 法的知識無い人間が会計を自分でやる、なんて言っちゃダメだな
何の資格も無い社員がやれるのはデータ(金額)インプットまで
それから先は会計士に任せるか、会計ソフトに任せる以外に方法無い
つまりデータ整理加工部分だけをAccessでやるなら問題無いが、会計部分までAccessでやるなんて実務知らん素人の戯れ言でしか無い 実態任せてるのが実情だけどね
会計ソフト使うのが常導手段 >>746
資格は持っていなくても税金の申告は出来ます。
法人ならば会計責任者の申告として社員が申告書を作成するし、
個人事業主なら、本人の申告として納税する。
どっちにしても税務署はいつでも相談に乗ってはくれる。 >>749
公認会計士が税理士業務を行うには、税理士会に入会して税理士登録をしなければならない。
ま、税理士の嫌がらせだな。 2019.8月のWindows UPDATEでVBS,VBSが動かなくなってる 9 名前：デフォルトの名無しさん[sage] 投稿日：2019/08/17(土) 00:54:25.40 ID:lGsYaY1B
マイクロソフトのScotBrenさんによると
昨日リリースされた更新プログラムには、
特定のセキュリティの悪用を軽減する oleaut32.dll の変更が含まれていました。
残念ながら、この緩和策により、
空の ParamArray を渡していたすべての VBA および VB6 アプリが、
内部関数呼び出しからの返りとして
E_INVALIDARG を取得し始めるという予期せず発生しました。
とのこと
tps://answers.microsoft.com/en-us/msoffice/forum/all/windows-update-2019-08-cumulative-update-has/baeea089-9bba-4a2a-9660-0a220f1656e9 リンク先のスレでは、中の人が直すっていってる
ダミーでいいからParamArrayにパラメータ渡せば回避できるし
うちではやらないコーディングなので問題なかった
devsによる半年前からのレビューは今回も役に立ってないんだな しょぼい質問ですいませんが、ウインドウズ上でうごいてるDBMSってなんなのでしょうか？
オラクルとかSQL？
アクセスというのは、単なるアプリケーションでDBMSではないの？ >>758
SQLSERVER の mdf も、オラクルの dbf も、ただのファイルですね >>759
それらは管理サービスが動いてますよね？？ >>760
Access は JET が動いてますよ Accesは ACEデータベースエンジンに、連結フォームと連結レポートとマクロとVBAが付属しています たとえば商品マスターテーブルに100件以上ある場合
明細フォーム入力時にコンボボックスから商品コードを選んで入力するのに探すのが大変
Excelのフィルタだと検索ボックスが用意されてるけどAccessにはないですよね？
みんなどうやって解決してるんでしょうか？ 商品マスタを階層構造にして
コンボボックスにクエリかますの。 階層構造とは大ジャンル−小ジャンルのように分けるということですか？ >>764
コンボボックスに、最近使用した順で表示する そんなの創意工夫やで
コンボ2個構成でもいいし、マスターの構造上面倒くさけりゃ
検索ボックスとコンボならべて検索ボックスに入力された文字列と一致するのをコンボに表示するでもよし
運用上面倒くさけりゃもっと考えて（続きを読むには月額購読） そこまでやるならVBAではなくC#で、とも思うのですが
つい最近のアップデートでVBAは動作しなくなりましたし C#がAccess VBAより高等なことが出来るということは全くないぞ
SQL Server使うならライセンス料などコストも余計にかかる Access97あたりから入門したけど（今は使っていない）、
当時の入門書では、割と必須項目だったような。
参照される既存の商品マスタを
別途、Excelで予め階層構造に作り直しておいて、
大・中・小項目から順次クエリで絞り込むコンボボックスって、
VBA使わなくても、クエリのウィザードで作ってた。
商品マスタに新レコードを階層的に追加することも出来た。 >>772
記憶があやふやだけど、コンボボックスのレコードソースを変更するのにVBAが必要じゃなかったけ？ 実現するのにVBAを1〜2行書くだけで済むが
それが嫌なら別の手段を取るのも自由だ
好きにしたまえ
この話はそれで終了だろ >>773
大項目のコンボボックスの選択内容が変更されたときに、
中項目のコンボボックス用クエリを更新する
というようなことは、VBAを使わなくてもウィザードで出来たかと。 コンボ２の値ソースに
SELECT 大項目,小項目 FROM 商品マスタ WHERE (((大項目)="コンボ1"));
とすればいけるが、コンボ1を変えたときにリクエリしないといけないんでそこはVBAでやるしかない 再クエリはマクロで出来るんだけど
accessは、かつては超貧弱でマクロも変数も無かったので、それぞれVBAのを使ってた
今は、マクロも変数も有るでよ 分類が作れなくてフリガナの頭文字を別フィールドに入れてそれを項目にしてた事ある Access is NOT dead, (neither is VBA)
Catch my latest podcast on why Access is not dead! https://accessusergroups.org/microsoft-access-podcast/ [...] >>770
C#でデータベースサーバ繋げてバリバリとビルド、コンパイル、パッケージできるなら
それでいいじゃん。
うちら、本業が事務とか、売り物の製造とか、販売営業で
ビルドはサボりと同義で、
コソコソやってるんだから。
ところで私は、コード検索はモーダルウィンドウにして、例えば
商品名をキーにして
google検索ライクにキーワードをスペース区切りで打たせて、
リストを見せ、
okボタンでコードを埋め込むのを
どの管理ツールにも使い回してる。
この形式だと、一般従業員があまり迷わない。 >>764がやりたいのは多段コンボボックスとかじゃなくてこれじゃろ
入力するデータを選択する検索フォームの作成
http://gyoumuka.work/?p=528 教えてください。
エクセルの表をアクセスのテーブルにインストールしたところ、
「すべてのデータをテーブルに追加できませんでした」と出てきますが、その下に
「キー違反のため、0件のレコードが失われ、0件のレコードがが削除されました」とあります。
中をみたら、とくに問題なくインポートできているようです。
これ、気にする必要あるでしょうか？ >>782
たぶん欠落は生じてない。
エラーで除外したデータがあるときは別に自動でテーブルを生成する仕様だったと思うので、
それが存在するかチェック。 > これ、気にする必要あるでしょうか？
気になっちゃうだろ
レコード数を比較すれば安心できるだろ 気にする必要があるか？への答えなら、気にするべきだと思うわ
自分の作業中にそんなんでたら、たとえデータ数があっていても、
そのメッセージがなくなるまでデータをチェックして、原因を特定する
100万件のデータでも分割していけば20回で少なくとも1つの
原因データを特定できるんだし 「キー違反…」って主キーにインポートしたとき出るような気がする
気がするってだけ キー違反は主キーに同じ値があるときにでる
主キーはインポートしないで自動作成が基本かと 良く有る話
そもそもExcelで二重データのチェックなんてVBAでチェックルーチン作っておかないと、こういう間違いが発生する
ゆえにExcelをデータベースの代わりに使うって間違いって事 テーブルに通貨型でフィールド作って「単価×数量×1.08」で結果を帳票出力してる
この場合、書式を「通貨」にしとけば四捨五入されてるみたいだけどこれって偶数丸めなのかな？
そもそも消費税の計算で偶数丸めってありなの？ >>790
> この場合、書式を「通貨」にしとけば四捨五入されてるみたい
おい！ >>790
消費税の1円未満の端数は、
税法で切り上げか切り捨てか選択出来たような？
ほとんどの事業者は切り捨てみたいだけど。 どうでもいいことだけど、四捨五入にJISの規格があるって知った？ >>773
レコードソースをイジるのメンテナンス性おちるからやらない
それよりフィルタで絞り込むクエリをソースにする >>787
主キーはオートナンバー一択
そう考えていた時期が俺にもありました 主キー（main key)っていうのは、文字列フィールドでも、複数のフィールドの組み合わせでも構わないと
知ったときの驚き
初心者がやらかすのはテーブル同士の関連を示すリレーションシップを設定し忘れること
これやらないと想定したとおりのデータベース構造が出来なくなって詰まる >>798
用途にもよる。大手ベンダーが作ったERPのsqlserver覗いてみたら
リレーションマップは一つも作ってなかった。
伝票は商品名も含めて、わざと冗長的な記録をするので
参照整合性はむしろ邪魔になるのかもしれない。 >>782
Excelの表は正規化されてたのか？
正規化されてない表をテーブルに入れるとそういうエラーを出すことがあるな。
セル結合してるとか、表の題名をセルに入れているとか、同じフィールド名が複数あるとか いつもマスタに書かれてる商品名通りにはならんからな、伝票って 参照整合性ないとリレーショナルデータベースにならないよ
エクセルみたいなフラットベースの2次元データで良ければ、エクセルで良いじゃん
データの3次元構造を支えるのが参照整合性 >>799
>伝票は商品名も含めて、わざと冗長的な記録をするので
データファイルが無駄に大きくなりそうな気がする。
機能拡張やメンテナンスを含めて考えると、参照整合性を設定しておくべきかと
各テーブルに主キーを設定して、
各主キーに対応するフィールドにもつテーブルを用意してリレーションシップしとけば
後々面倒ないやん。 >>801
商品名がマスターに無いものでも扱うって状況が意味不明 1対多対応のリレーションシップでは
多になる方のが運用でレコードが追加されていくテーブルで、そこには1になる方の主キーだけが記録される。
だからレコード数が増えてもデータファイルの大きさは必要最小限になる。
商品コードと商品名では商品コードの方がデータ量は少ない
それがコード化の意義の一つなんだがなあ。
これ基礎だと思ってたんだが、そこからなのか？ >>806
だから用途による、と言ってるでしょう。
商品番号1 商品名A
で、リレーショナルデータベースの基本通りに
明細テーブルに 商品番号１、20個 だけ保管して
あとはマスターから引っ張り
商品番号１、商品マスタ．商品名”A”、20個、
商品マスタ．単価￥１００、 金額＝商品マスタ．単価×20個
なんて作ってごらんなさい。
単価は永久ですか？ 全オペレーターが商品番号１の
内容・商品名をBに変えないと言い切れますか。
税法上も取引履歴の長期保管は義務なのに
参照表示により、記録が変わってしまっては役に立ちません。
伝票系で私が参照整合張るのは、
ヘッダー項目と明細項目で伝票番号をキーに親子関係を
結ぶときくらいですね。 >>807
単価は商品テーブルじゃなくて単価テーブルに置くやろ
んで単価テーブルには単価と有効期限を設定しとく
処理日と有効期限を比較して単価を特定 ■ このスレッドは過去ログ倉庫に格納されています
