現場では当たり前の事ですが、この発想に及ばないのは実際の開発現場でのプリンタの管理が想像以上にこのようなお金の問題以外にもたくさんあるからです。
— コンピュータの専門学校 R101(開発担当) (@iseifu) December 27, 2022
2022年12月31日
VScode でダークテーマでキャプチャした画像を印刷しないようにしましょう。トナーがもったいないです。
2019年08月18日
Apache の index 表示でファイル名が長すぎて省略される場合の設定変更
Directory Listing Column Width ( stackoverflow ) IndexOptions に NameWidth=* を追加して再起動します。 ( IE11 はキャッシュを削除したほうがよさそう ) ▼ xampp\apache\conf\extra\httpd-autoindex.conf
<IfModule autoindex_module>
<IfModule alias_module>
#
# Directives controlling the display of server-generated directory listings.
#
# Required modules: mod_authz_core, mod_authz_host,
# mod_autoindex, mod_alias
#
# To see the listing of a directory, the Options directive for the
# directory must include "Indexes", and the directory must not contain
# a file matching those listed in the DirectoryIndex directive.
#
#
# IndexOptions: Controls the appearance of server-generated directory
# listings.
#
IndexOptions FancyIndexing HTMLTable VersionSort NameWidth=*
# We include the /icons/ alias for FancyIndexed directory listings. If
# you do not use FancyIndexing, you may comment this out.
#
Alias /icons/ "/pleiades/xampp/apache/icons/"
<Directory "/pleiades/xampp/apache/icons">
Options Indexes MultiViews
AllowOverride None
Require all granted
</Directory>
2019年02月13日
SQLServer の SQL でテーブルの日付が前月かどうかで条件を作成する
まず、dateadd と datepart の機能を確認する為の SQL が以下のようになります。 ※ m と mm は month の省略形です
select
cast('2019/01/01' as datetime),
dateadd(month, -1, getdate()),
dateadd(m, -1, getdate()),
dateadd(mm, -1, getdate()),
case
when datepart(year, cast('2019/01/01' as datetime)) = datepart(year, dateadd(month, -1, getdate()))
then '一致しました'
else '一致しません'
end as 年比較,
case
when datepart(month, cast('2019/01/01' as datetime)) = datepart(month, dateadd(month, -1, getdate()))
then '一致しました'
else '一致しません'
end as 月比較
▼ これを踏まえて条件にしたものです。
select * from [テーブル名] where DATEPART(year, 対象日付) = DATEPART(year, DATEADD(m, -1, GETDATE())) and DATEPART(m, 対象日付) = DATEPART(m, DATEADD(m, -1, GETDATE()))
現在の年月日を getdate() で取得し、その月を一つマイナスして年部分と月部分を別々に取得して、比較したい日付の年部分と月部分がどちらも一致していたら、前月です。 関連する Microsoft ドキュメント DATEADD (Transact-SQL) DATEPART (Transact-SQL) CAST および CONVERT (Transact-SQL) CASE (Transact-SQL)
2019年01月28日
販売管理 (2)
業務フロー 業務フローはその名の通り業務の流れを図解したものです。その中にはコンピュータの操作が発生するタイミング以外に、人間が実際に作業する内容も含まれています。 例えば、売上を発生させる為には商品が必要です。その商品は他の企業から仕入れるかもしれませんし、倉庫にある在庫から取り出すかもしれません。そして、その商品を必要とする顧客に引き渡す為には、誰かが届ける必要があり、届けた場合に相手が受け取ったという証明が必要になります。 これを販売管理に必要な事実として流れとして繋げると一例として以下のようになります。出庫 => 納品伝票作成 => 輸送 => 納品 => 受領書受取り => 売上確定まだこの前後に必要な販売活動のバリエーションがありますが、【売る】と言う事実だけを取り出すとこのようになります。企業は、この流れを日々繰り返して売上を蓄積させて締めというタイミングで合計して請求と言う作業を行います。 締め処理 締めのタイミングは取引では立場の強い支払い側が決定します。つまり、売る側からすると納品先毎に締めのタイミングが違う事になりますが、期間は管理上必ず１か月となります。 販売活動として、締めの日付の次の日から次の締めの日までの売上を合計して請求書を作成します。その請求書を何らかの方法で請求先に届ける必要があるので、得意先(支払い側)がその内容を確認するのは少し先になります。 支払い 得意先側も販売活動の一環としてその請求書の内容を確認する必要があります。その請求書に該当する期間に納品された商品の納品書の内容と請求書の明細とが一致するかを確認した上で、支払処理の準備をする必要があります。 支払い側は、他の仕入先も同じ締め日になるので、全ての支払う必要のある買掛金の合計を販売管理のシステムで合計する事ができます。そして、支払時期に合わせて現金やその他の支払う為に必要な対価を準備します。この作業を一般的に資金繰りと言います。この資金繰りの状況によっては、銀行に融資をしてもらったりする事もあり、最悪資金が調達できなければ企業が負債を抱えて倒産する事もあります。 単純には、売上げてもすぐ現金が入ってこない掛け売りという形態であり、さらに支払いに関して言えば通常締めの期日より1か月以上後に支払われる事は一般的です。なので資金繰りという重要な販売活動をする上で、売上や支払の金額を正確に知って分析する為に販売管理システムは販売活動の大きな助けとなります。 入金種別 企業の一般的な支払方法は銀行振込になります。その場合、振込手数料は慣習的に請求書を発行する側の負担になる事が多いようですが、支払側が事前の取り決めで負担してくれる場合もあります。 昔は集金という業務があり、現金で支払ってもらう為に直接出向いて現金を受け取るという形態もありましたが、今ではリスクが大きいのである程度の規模の企業が利用する事は稀だと思われます。 現金にやや近い形態が小切手による支払いです。小切手を利用するには当座預金が必要で、降り出した小切手を受け取った側が銀行に出向くという手間が必要になります。現金を持ち歩くリスクは無くなりますが、盗難のリスクは残ります。そして、銀行にある口座に預け入れてもらうか現金で受け取る事になるので、リスクを考えれば得意先の取引銀行に口座を持つ必要があります。 当座預金口座を持っておれば、支払い方法として手形を選択可能になります。手形に関する詳細はさらに複雑ですが、販売管理とは直接つながりません( 在庫管理のように大きな範囲では関連します ) 特殊な条件下では相殺という入金の種類があります。ある取引先が得意先にも仕入先にもなる場合、売掛金と買掛金が同時に発生する場合があります。その場合実際の現金の動きが必要無い場合は相殺という形で売掛金と買掛金を消滅させる方法です。この場合、販売管理で入金した場合は支払いも同時に発生する事になるので、ユーザができるだけ簡単に処理できるように考える必要があります。 金融機関を使う方法でもう一つ利用可能な決済方法があり、口座振替と呼ばれています。これは支払い側と同じ銀行に口座を持つ事によって、手続きだけで現金を移動させる方法です。これは、金融機関内の現金は変化せずに、持ち主のみが変わるので手数料が必要無いのが通常となります。
販売管理 (1)
販売管理システム 販売管理は、企業が利益を上げる為の活動として一般的に行われる手順をコンピュータの中で行う場合のシステムのジャンルです。 コンピュータが無い状態での販売活動の基本は、紙に記録する事です。それらは伝票であったり台帳であったりメモ書きであったりしますが、紙に記録する代わりにコンピュータの外部記憶装置に記録し、正しい事実や数字の管理をする事が大きな目的です。 その為に必要な手順として、まずシステム側とユーザ側でその企業における販売活動の詳細を整理する必要があります。その中で最もユーザ側が理解しやすい形でシステム側が提供すべきなのは【入力】と【出力】です。具体的には、【入力】はコンピュータの画面であり、【出力】はもともとは紙で記録されていたものです。そして、それらは専門的には画面設計や帳票(表)設計と呼ばれるもので、最終的にユーザ側が最も必要なものは『印刷されるもの』であって、それは紙である事が殆どです。 掛売り 企業の販売活動の要点は掛売りと言う取引で行われるところです。 掛売りとは、一般消費者が利用する店舗における現金との引換えでは無く、商品の対価の受け取りを一定期間の後に行う方法です。 簡単に言えば後払いで商品を売ることで、支払うという立場を一般消費者から見ればクレジットカード払いが似たように見えます( クレジットカード払いでは実際にはクレジットカード会社が先に払い、一般消費者はクレジットカード会社に支払うという形態で同じではありません ) 売掛金 そして、この方法による販売の対価の蓄積を売掛金と呼び、売掛と言う言葉は掛け売りとほぼ同じ意味に使用されます。 売掛金という言葉は簿記の仕訳の際にも使用されます。【借方】売掛金：1,000 ／ 【貸方】売上：1,000売上と売掛金は対を成す事になり、売掛金は経理上重要な言葉となりますが、販売管理としては売上と言う言葉で商品を納品した時点で積み上がります。そして、売掛金1,000円が振込みで支払われた場合は以下のような仕訳になります【借方】普通預金：1,000 ／ 【貸方】売掛金：1,000販売管理では、この支払われた売掛金を入金処理によって、入金の日付と種別(この場合は振込)と入金額をコンピュータに記録します。つまり、販売管理では売上と入金という現実に起こった事実に対して管理情報を記録します。それに対して売掛金という言葉は販売管理の中では使用せず、経理のシステムで使用される事になります。 企業の販売活動の目的は利益を上げる事なので、直接的に必要な事実は売上と入金です。しかし、実際の販売活動にはこれ以外の事実が発生するので、販売管理ではそれらを全て管理しなければなりません。そして、どのような事実が発生するかをユーザ側とシステム側で同じ認識にする手法として業務フローの作成があります。
Seesaa の各ページの表示について
Seesaa の 記事がたまに全く表示されない場合があります。その場合は、設定＞ 詳細設定＞ ブログ設定 で 最新の情報に更新の『実行ボタン』で記事やアーカイブが最新にビルドされます。 Seesaa のページで、アーカイブとタグページは要注意です。タグページはコンテンツが全く無い状態になりますし、アーカイブページも歯抜けページはコンテンツが存在しないのにページが表示されてしまいます。 また、カテゴリページもそういう意味では完全ではありません。『カテゴリID-番号』というフォーマットで表示されるページですが、実際存在するより大きな番号でも表示されてしまいます。 ※ インデックスページのみ、実際の記事数を超えたページを指定しても最後のページが表示されるようです 対処としては、このようなヘルプ的な情報を固定でページの最後に表示するようにするといいでしょう。具体的には、メインの記事コンテンツの下に『自由形式』を追加し、アーカイブとカテゴリページでのみ表示するように設定し、コンテンツを用意するといいと思います。※ エキスパートモードで表示しています アーカイブとカテゴリページはこのように簡単に設定できますが、タグページは HTML 設定を直接変更して、以下の『タグページでのみ表示される内容』の記述方法で設定する必要があります
<% if:page_name eq 'archive' -%> アーカイブページでのみ表示される内容 <% /if %> <% if:page_name eq 'category' -%> カテゴリページでのみ表示される内容 <% /if %> <% if:page_name eq 'tag' -%> タグページでのみ表示される内容 <% /if %>この記述は、以下の場所で使用します
|
|
