> For the complete documentation index, see [llms.txt](https://quteng.gitbook.io/ke-hu-wen-da-ji/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quteng.gitbook.io/ke-hu-wen-da-ji/jiao-wu/jiao-wu-zong-lan.md).

# 交屋總覽

交屋系統是建案銷售的最後一哩路，負責將繁雜的最終帳務（包含代辦規費、水電、客變款）、實體物品（鑰匙、保卡）以及客變工程進行系統化的整合與點交。透過線上結算與電子簽署，確保交屋流程精準透明且無遺漏。

### 第一階段：交屋前置項目建置

此階段為交屋作業的前置準備，用於建立全案共用的收費與點交清單範本。

* **操作路徑**： 交屋系統 > 交屋點交項目 / 代辦費項目
* **操作流程**： 預先建立交屋時必須點交給客戶的實體物品清單（如：大門鑰匙、各類保證書等），以及需要向客戶結算的代辦費用項目。建置完成後，可供後續單戶交屋時直接帶入使用。
* 請參考 [交屋前置項目建置](/ke-hu-wen-da-ji/jiao-wu/jiao-wu-qian-zhi-xiang-mu-jian-zhi.md) 。

### 第二階段：新增交屋單與成立訂單

針對準備交屋的戶別，正式生成交屋作業單據。

* **操作路徑**： 交屋系統 > 交屋列表
* **操作流程**： 針對戶別點擊查看，進入「成立訂單」進度。若該戶別在銷售系統中已有訂單紀錄，系統將會自動帶入客戶與合約資訊。確認訂單資訊無誤後，即可正式成立單據。
* 請參考 

### 第三階段：確認繳款進度

處理交屋時的各項代收代付與最終帳務結算。

* **操作路徑**： 交屋系統 > 交屋作業 > 繳款進度
* **操作流程**： 依序核對與輸入各項代辦費、應收期款以及客變追加減帳的明細與金額。系統將自動彙整並計算出最終的「退補費用（應退或應補金額）」，確保交屋帳務精準無誤。

### 第四階段：確認交屋點交

帳務確認後，於交屋現場進行實體物件、權狀與客變項目的點收。

* 操作路徑： 交屋系統 > 交屋作業 > 交屋點交
* 操作重點： 依畫面清單逐一交付常規物品，系統亦會自動帶入前期客變系統設定的「客變點交」項目供現場一併驗收。點交完畢後，由客戶與現場業務分別於電子畫布完成簽名確認。

### 第五階段：交屋完成與產出 PDF

完成所有點交與簽名手續，正式結案並提供書面憑證。

* 操作路徑： 交屋系統 > 交屋作業 > 交屋完成
* 操作重點： 流程推進至最後階段，系統狀態將轉為「交屋完成」。操作人員可於此畫面直接產出並下載完整的「交屋證明單 (PDF)」與相關清單，提供給客戶留存，圓滿結束該戶的交屋旅程。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://quteng.gitbook.io/ke-hu-wen-da-ji/jiao-wu/jiao-wu-zong-lan.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.