日付配列を

If ( Get(計算式繰り返し位置番号)  = 7 ; 週起算日[1] + (Get(計算式繰り返し位置番号) ) -7;
週起算日[1] + (Get(計算式繰り返し位置番号) )
)

にしてみたら上手く表示されました。

フルカレンダーを使ったスケジュール管理であれば理想のものが出来るのではないでしょうか。

https://github.com/frudens/filemaker-fullcalendar

端的に言って、データとなる情報の全てはテーブルに収められています。
レイアウトで使われていないテーブルを参照している可能性もありますが、テーブル内にあるレコードのデータを参照しているので、リレーション先のテーブルだったりします。
計算式などのフィールドは、基本的にレイアウトで使っているテーブル内計算フィールドで定義されています。

エクスポートは複数のテーブルから任意でどのフィールドを出力するか選択できるはずです。恐らく１つのテーブルから全て移動していると思うので、出力選択したテーブル内に意図としないフィールドが含まれているはずです。
エクスポートしたくないフィールドは選択しなければ良いだけです。

ツールの中に「データベースデザインレポート」と言う構造を分析できる機能はありますが、FileMakerに慣れ親しまないと分からないかもしれません…

ご自身で作っていないファイルの分析には多くの時間が必要になってきます。
いずれにしても、根気よく一つずつ紐解いていくしかないのが現実だと思います。

そのままの意味です。ファイルメーカーでの作成は紙ベースからのデザイン再現度が非常に高いです。
点検項目にレ点を付けていくようなものも出来るし、備考欄をつけてコメントを入れることも出来ます。
また、凝ったデザインも可能で、大項目を選んだら、詳細ベージがスライドで現れるような事も出来ます。

アクセス権セットの編集にデータアクセスとデザインがあります。
レコードなどの項目の中に「カスタムアクセス権」と言うものがあります。
より細かくカスタマイズすることが出来ます。

やり方が合っているかは分かりませんが、ボタンによるスクリプトステップで繰り返しフィールドを複製をしています。

サンプル：https://a-portal.net/fm-aid/id14860.zip

端的に言えば、ファイルが異なる場合であっても更新は可能です。

テーブルオカレンスに外部データソース（もう一方のファイルテーブル）を配置して、一方のファイルからもう一方のファイルの更新は出来ます。リレーションでの取り扱いは通常の感覚で関連付けが可能です。ただし基ファイルからのオブジェクトパネルでのフィールドの追加・編集は不可能になり、もう一方のファイルそのものにフィールドの追加・編集しなければなりません。
また、ファイルアクセスの認証などが必要になります。アクセス管理は煩雑になる可能性が高いです。

余談になりますが、統合モデルと分離モデルと呼ばれる手法があります。
統合モデルとは従来ファイルメーカーで作る一般的な方法です。分離モデルとはユーザーインターフェース、ユーザーが操作するデザイン部分とスクリプトを入れておくファイル、データテーブルを分けておくファイルで運用する方法です。
双方メリット・デメリットは存在しますが、分離モデルの致命的なデメリットは変数を直接他のファイルに渡せないことです。
様々な知見や手法をお持ちの方でしたら問題はありませんが、慣れていない場合は非常に制作しづらいものになります。
データの参照と更新程度なら何ら問題は無いと思われます。しかしながらその更新したいデータを変数で扱っていた場合は話が異なりますのでご注意ください。

FileMakerは様々なシュチュエーションにも幅広く対応出来ます。柔軟すぎるがゆえに時として弊害をもたらしたりします。
フルスタック開発と違い、仕様の変化にも柔軟に変更することも可能なので、構造上問題があるレイアウトがあったとしても、新たなレイアウトと再構築したオカレンス構造で対応が可能になります。（一つのレイアウトにこだわらず、複製などしながらもより良い構造を探していくのも手の一つです。）

FileMakerは対象レコードを絞り込むために様々なアプローチが存在します。
レコードの範囲を返すリレーションシップを構築することにより、割と簡単に希望のレコードを探すことも出来ます。

その時に思いついた最善だったのだから、根本が間違っているとは言えません。むしろそういった経験をすることにより、新たなアプローチ方法が思いついたり、創意工夫が出来るものです。

端からデジタル思考で考える必要はありません。自身の机の上で書類を整理していたとします。目次であったり、日付であったり、照合番号であったり、顧客名であったり、都道府県であったりと何を参照しながら逆引き的に目的のものを探しますか？
アナログ的思考も大事になってくる時があります。根幹となる最も重要なデータの始まりを考え、どの値と照らし合わせていくのか、どのデータと比較して参照していくのか、良く考えていく必要があります。

検索は非常に重要なセクションになります。クイック検索による検索、リレーションによる照合検索、範囲指定による検索、etc、様々な検索アプローチがあり、その時々で変化させる必要があります。

＞売上を入力するレイアウトから入力してその後で請求書の抽出レイアウトにいく仕組み
これは双方向から作成出来るような仕組みも可能です。
オススメする仕組みはあっても、100％こうした方が良いというものは正直存在しません。
「自分は請求書を作る際にこうこうこういう流れにしたいんだ！」っと言うものがあれば、FileMakerの仕様から大きく外れない限り、恐らく実現可能です。

とかく、成功失敗関わらず、臆病になることなく様々な経験をしたほうが良いと思います。

UUIDは非常に重宝するものです。
UUIDは「世界中で唯一のID」と表現されるほど、重複する可能性は低いものになります。
Shinさんの提示する方法が一番の方法だと思います。

発行番号に発行回数を含めたID変更は当然戻せないでしょう。
どうしても戻す必要があるのであれば戻すことは可能です。戻すことが前提であれば、むしろ発行回数を末尾に付ける必要はないと思います。

＞１
請求書番号末尾に発行回数を追加するより、発行回数として別フィールドを持っておき、カウント加算していけば良いと思います。

＞２
重複があるほうが問題になると思うので、同じ内容のレコードを２つ保存する必要はないと思われます。
締め日などある中で、どの地点で省く必要があるのかは存じませんが、１回以上の発行数があるのであれば、それを基に省くことは可能です。
請求書発行などは、どのレコードを対象に発行（印刷）するのか絞り込んでいくものなので如何様にもなります。