ありがとうございます！

専門システムだと、売上と在庫が別になるかカスタマイズ費用が、、、
ってところでKintoneでという案がでてたので、、、。

もう一度、システム予算からどちらで行くか検討してみます。

それは考えてみたのですが、
1度の輸入品数が、１製品4000を超えてくるので、Kintoneヘルプ確認したところ、
目安が100行でしたので、多すぎるよねと悩んでました。

1度の輸入品数が、１製品4000を超えてくるので、Kintoneヘルプ確認したところ、目安が100行でしたので、多すぎるよねと悩んでました。

小生もテーブル行数上限の目安が100行とは知りませんでした。
学ばしていただきました。ありがとうございます。
変なこと言ってすみませんでした。

レコード数は上限無いようなので、製品名（型番）－S/N－発送先－修理部品などとした別アプリを用意し、掲題の売上・入出庫数管理アプリからは簡単にそこに飛べる／集計結果を利用したいのであれば別アプリの値を持ってくるとかしないとダメかもですね。

ふと思った感想ですが、種々のパラメータを統合した一大データベースを用意し、各管理部門には業務の目的に合ったパラメータを登録・ピックアップして集計などを行う集計アプリ（仮称）を別々に用意して配布しておく…などというのもアリかと。

なるほど！！
確かにそれなら、見たい箇所だけみれます！！
ただ、一大データベースの更新を誰がするのか問題ですね。
各々だと乱雑になりそうで。

一つ解決すれば、新たな課題が生まれ、、、
いろいろ考えていただきありがとうございます！！

小生がザクっと考えたシステムイメージをお伝えします。

一大データベース

全てのデータが詰まったレコード群のイメージです。
これを、「（あくまでも緊急時、）全データをメンテナンスできるkintoneアプリ」として作っておきます。

更新を誰がするのか

平時は、前レスで出した「集計アプリ（仮称）」(※１)を、各管理部門で上の”アプリのデータを"（←ここがデータが乱雑にならないための肝ですかね）登録・修正等（いわゆる更新）できるように作って(※２)渡しておきます。

　※１：データ更新アプリ⇔集計アプリと別々にするのもアリだと思いますが、そこはお好みで。
　※２：様々な連携方法があるので、ここもお好みで。

スタート時に初期データを用意しておく必要はあるかと思いますが、こうしておけばリリース後は手離れよくアプリの作りのメンテナンスに専念できるかと。

こんな感じです。

あくまでも小生だったらのイメージなので、求める仕様にそぐわないことは多々あると思います。
その点、ご了承ください。

ありがとうございます。
難しく考えすぎておりました。

一度ダミーデータを作成してみます！