市倉丈寛/Ichikura Takehiro Silver Trophy

こんにちは。 在庫台帳は、指定した日付範囲における在庫の動きを時系列で確認するための帳簿であるため、前月と今月を横並びにして増減を計算するといった使い方は想定されていません。 ただし、「月」という列を追加してグループ化することで、月単位でまとめて縦に表示することはできるため、ある程度は比較しやすくなるかと思います。 ご質問の意図とは異なる回答になってしまうかもしれませんが、参考になれば幸いです。

こんにちは。 Sandbox では検証用途のため、ライセンスチェックが緩和され、通常はライセンスが必要なコピーや編集ができてしまう場合があります。 ほかの回答でも触れられていますが、正式に利用する場合は、適切なライセンスを Oracle 社から購入することをおすすめします。

こんにちは。 オラクル社のサポートでは「ビジネスインパクト」を重視する傾向があります。 ここでいうビジネスインパクトとは、障害や不具合が顧客の業務や運用（本番環境、売上処理、請求、決算など）にどの程度影響しているか、また回避策の有無といった観点を指します。 回避策がなく、実際に業務に影響が出ている場合は、ケースの優先度を上げて対応してもらえることがあります。 今回のようにサポートケースが1週間以上進行中で、このままでは自社のビジネスに影響が出る状況であれば、その点を明確に記載したうえで、早期対応やエスカレーションを改めて連絡するとよいと思います。…

ドリルダウンフィールドは、保存検索の結果を集計（グループ化など）した際に、グループ化した内容をクリックした際に、明細をどのフィールド単位で表示するかを制御する設定です。個人的には、あまり使う機会はありません。

こんにちは。 この更新については、 顧客・仕入先などを含むトランザクションの保存検索を実行した際に、本来は意図していない住所情報まで結果に表示されてしまっていた挙動が、 今後は表示されなくなります、というお知らせです。 もう少し具体的に言うと、 これまではトランザクション（例：注文書、請求書など）を主とした保存検索で 顧客住所を結果に指定した場合、 顧客レコードに登録されている複数の住所 （請求先・配送先など）が、すべて検索結果に表示されてしまう ケースがありました。 そのため従来は、 ・デフォルト配送先・デフォルト請求先、もしくは表示したい住所を条件や数式で指定し、 複数の住所が表示されないように工夫する必要がありました。…

https://community.oracle.com/netsuite/japanese/discussion/4511758/%E3%83%90%E3%83%B3%E3%83%89%E3%83%AB%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E8%B3%AA%E5%95%8F こんにちは。 内容としては以下になります。 SPS Commerce Fulfillment for NetSuite は、NetSuite 連携に特化した専任スペシャリストチームによってサポートされる、フルサービスの EDI ソリューションです。…

ご確認ありがとうございました。 設定自体は正しく入っているようなので、その点は問題なさそうです。 ただ、「予期しないエラー」が表示される場合は、設定ではなくシステム内部のエラーの可能性が高く、こちら側ではこれ以上の切り分けや対応が難しい状況です。力になれず申し訳ないです。 お手数ですが、この状況をサポートベンダーへの相談、もしくはサポートチケットを利用してNetsuiteサポートチームへ調査依頼されるのがよいと思います。

念のため補足いたします。 ・設定 ＞ 会計 ＞ 会計期間を管理 ・設定 ＞ 会計 ＞ 税期間を管理 上記 2 点については、一度設定すれば以後変更不要というものではありません。 例えば、9月決算の子会社であると仮定して今回のエラー事象を時系列で整理しますと、 2022年頃に税期間を3年分設定し、2025年9月までを税期間として登録されている場合、 2025年10月以降（4年目）については税期間が未設定の状態となり、 その結果、設定の保存や各種処理が行えなくなる可能性が考えられます。 税期間および会計期間はいずれも自動的に更新されるものではなく手動で作成する必要があるため、…

https://community.oracle.com/netsuite/japanese/discussion/comment/16906424#Comment_16906424 ご確認いただきありがとうございます。 私の環境では、ファイルキャビネットをテキストファイルの直接アップロード用途では使用しておらず、主に作成された PDF をダウンロードしたり修正があればアップロードする形で利用しております。 ほかに利用者のお話は、ユーザーミーティングに参加されて聞いてみてもよいかと思います。 また、ご共有いただいた手順と同一の方法で検証したところ、私の環境においても UTF-8…

https://community.oracle.com/netsuite/japanese/discussion/comment/16906336#Comment_16906336 ご確認ありがとうございます。保存できない要因としては ・締め請求書消費税調整 ・7513-00 営業外費用：売掛金処理科目 の設定で、どこかがおかしいのかと個人的に考えていますが発見が難しいですね。 「7513-00 営業外費用：売掛金処理科目」について子会社も含んでますが、 子会社も税期間、会計期間は問題なく設定していますか？

日付の話が出ましたので、追加で確認いただきたい点として、以下が考えられます。 ・設定 ＞ 会計 ＞ 会計期間を管理 ・設定 ＞ 会計 ＞ 税期間を管理 上記それぞれについて、開始日および終了日が正しく設定されているか、また 対象期間が有効（オープン）な状態になっているか をご確認いただけますでしょうか。 これらの設定が未設定、もしくは不整合がある場合、処理や設定の保存ができなくなる可能性があります。

ちなみに「毎月締め請求書先の保存先を変更していた」というのは、 締め請求書の実行時または設定変更時に、 日本向けローカライゼーション設定内の「売掛金借方／貸方調整項目」自体を、 『締め請求書消費税調整』から別のアイテムに切り替えていた という理解でよろしいでしょうか。 それとも、調整項目には触れず、保存先（フォルダや紐付け先）のみを変更していた、という認識でしょうか。

設定内容自体は大きな問題はなさそうに見えますが、いずれにしても現状は、当該アイテムレコードが要因となり、日本向けローカライゼーション設定の保存ができなくなっている状況かと思われます。 私の環境では同様の事象が発生しておらず、現時点では明確な解決策を把握できていないため、ヒアリングを行いながら原因および対応策を整理しているところです。すみません。 次に確認すべき点としては、「7513-00 営業外費用：売掛金処理科目」の勘定科目の設定が考えられます。 こちらの勘定科目が無効になっていたり、何らかの設定が入っていなっていないか、ご確認いただけますでしょうか。

https://community.oracle.com/netsuite/japanese/discussion/comment/16906173#Comment_16906173 「締め請求書消費税調整」レコードに設定されているアイテムが原因で発生している可能性が高いかと思います。 私の環境では保存時にエラーが発生していないので、関係がありそうなところを抜粋しますので、差異がないかご確認ください。 原価カテゴリ：デフォルト原価カテゴリ 収益勘定：4902 仮受消費税(締め請求書用) 無効：チェックなし 売上消費税コード：2.売上消費税10% 原価見積もりの種類：アイテム定義原価 最小を強制：チェック入り

https://community.oracle.com/netsuite/japanese/discussion/comment/16906093#Comment_16906093 日本向けローカライゼーションの設定の中に「売掛金借方／貸方調整項目」という項目があるかと思います。 もしその項目が見当たらない場合は、日本向けローカライゼーション設定画面のスクリーンショットをご共有ください。 おそらく、そこに設定されているリストの値が無効になっている可能性があります。 そのため、「手数料アイテム」の設定内容に問題があるのではないかと推測しています。

https://community.oracle.com/netsuite/japanese/discussion/4511628/%E6%97%A5%E6%9C%AC%E5%90%91%E3%81%91%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%A9%E3%82%A4%E3%82%BC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A7%E5%A4%89%E6%9B%B4%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%9B%E3%82%93 @Mikui 様 こんにちは。…

https://community.oracle.com/netsuite/japanese/discussion/comment/16905988#Comment_16905988 「可能性」として考えられるのは ・実際には UTF-8（BOM付き） でアップロードしてしまっている（作業ミス）。 ・ファイル名に 全角文字や日本語、記号 が含まれていたり、改行コードやエンコーディングの混在 により、純粋な UTF-8 として認識されていない。 ・アップロードしたファイルが、ファイルキャビネットで正式にサポートされていない形式 である。 など考えられます。

https://community.oracle.com/netsuite/japanese/discussion/4511608/bom%E4%BB%98%E3%81%8Dutf-8%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%83%BC%E3%83%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 yuki nomoto 様 こんにちは。 「アドバンスド追加（Advanced…

https://community.oracle.com/netsuite/japanese/discussion/4511600/%E7%B7%A0%E3%82%81%E8%AB%8B%E6%B1%82%E6%9B%B8%E3%81%AE%E5%89%8A%E9%99%A4%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%9B%E3%82%93 @Mikui 様 こんにちは。…

https://community.oracle.com/netsuite/japanese/discussion/4511096/%E3%83%9E%E3%82%B9%E3%82%BF%E3%81%8B%E3%82%89%E9%81%B8%E6%8A%9E%E3%81%99%E3%82%8B%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB%E3%83%89%E3%81%AE%E6%A4%9C%E7%B4%A2-%E3%83%AA%E3%82%B9%E3%83%88%E3%81%AE%E6%A9%9F%E8%83%BD @Teru 様 基本的には、参照や閲覧の可否はロール（権限設定）によってコントロールされています。…

@Teru 様 NetSuiteの標準機能では、リンクをクリックした際に自動で新しいタブで開くように設定することはできません。 ただし、マウスホイールの真ん中をクリックすると、新しいタブで開くことができるかと思いますがどうでしょうか。

予測拡張コスト(ライン)で取得できると思います。

https://community.oracle.com/netsuite/japanese/discussion/4511017/%E4%BF%9D%E5%AD%98%E6%A4%9C%E7%B4%A2%E3%81%A7%E5%A3%B2%E4%B8%8A%E6%98%8E%E7%B4%B0%E3%81%AE%E7%B2%97%E5%88%A9%E3%82%92%E5%8F%96%E5%BE%97%E3%81%97%E3%81%9F%E3%81%84 @User_Q40WJ 様 アイテム原価ですかね

以下のような2通りの方法が考えられます。 1. DMARCレポートの監視 DMARCレポートを定期的に確認し、SPFがFAILになった送信元IPを検知して SPFレコードを更新する方法です。 人手での解析は現実的ではないため、Pythonなどで自動解析スクリプトを作成し、 異常を検知した際に担当者へ通知する仕組みを構築すると良いかと思います。 2. NetSuite Statusページの監視 https://status.netsuite.com/ 上記のNetSuite公式ステータスページでは、 所属しているデータセンターのメンテナンスや構成変更情報が公開されます。…

連連投失礼いたします。 資料を確認したところ、正しいSPF参照は以下のとおりでした。 正：include:sent-via.netsuite.com 誤：include:send-via.netsuite.com ご質問の投稿では「send」と記載されていたため、スペル違いにより SPF 認証が FAIL となります。 正しくは 「sent」 です。ツールでも確認しましたが、これであれば、SPFは通過します。 参考資料：Email Best Practices また、ツールによれば参照回数が6回と出ているので、これを減らしたい場合は、 include: で参照しているドメインの IP アドレスをすべて展開し、自分の SPF レコードに直接…

気になったため追加で調査したところ、 MXToolbox にて send-via.netsuite.com の参照状況・回数を確認した結果、 このドメインには SPF レコード自体が存在しない ことが分かりました。 したがって、自社ドメインの SPF レコードにinclude:send-via.netsuite.com を記載しても、 認証上の効果はなく、DNS 参照回数が増えるだけ となるかと思います。 なので、SPFは必ずFAILするため、 DKIM 署名と DMARC 整合性 によって 正当な送信元であることを証明する運用がいいのかと考えました。

運用方針によって一概に正解はありませんが、 個人的には SPF と DKIM の両方が PASS する構成が理想 と考えており、 その意味でも SPF の設定は基本的に必須 と考えています。 ただし、SPF の性質上（ルックアップ上限や転送経路の影響など）、 一部で FAIL となるケースは避けられないため、 DKIM を確実に PASS させることで補完する 運用を行っています。 また、SPF を常時 PASS させることを目的とする場合は、 NetSuite 用に送信用サブドメインを切り出し、そのサブドメイン側で SPF レコードを構成する方法が有効な回避策になると考えます。

https://community.oracle.com/netsuite/japanese/discussion/4510865/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E3%81%AEspf%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%AB%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E5%9B%9E%E6%95%B0%E8%B6%85%E9%81%8E%E5%95%8F%E9%A1%8C%E3%81%A8%E5%AF%BE%E5%BF%9C%E7%…

https://community.oracle.com/netsuite/japanese/discussion/comment/16903077#Comment_16903077 トランザクション明細行そのものに入力中の制限を直接かけることはできません。 現実的な方法としては、例えばアイテムA・B・C・Dを入力→保存した際に、保存時（レコード送信前）のワークフローで以下のような処理を行うことが考えられます。 各明細行の在庫アイテムフィールドに設定した「部門」項目を取得する。 入力した従業員の「部門」と照合する。 一致しない場合は、その行を削除またはエラー表示して保存を止める。…

https://community.oracle.com/netsuite/japanese/discussion/comment/16903071#Comment_16903071 その場合は「配送先住所」でフィルターしてみてはいかがでしょうか。直送と特注の違いは送り先が客先か自社倉庫の違いが出てきます。具体的には「発注書(発注)フィールド」の中にある、「配送先住所」が対象です。