> 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/shou-fu/chang-jian-wen-ti/ru-he-she-ding-jian-an-bao-xiu-bao-gu-tian-shu-yu-cha-kan-bao-xiu-bao-gu-zhuang-tai.md).
# 如何設定建案報修保固天數與查看報修保固狀態？
當管理員在後台為建案設定「報修保固天數」後，系統會結合各戶別的「交屋完成日」作為保固起始日進行自動計算。當新增報修單時，售服人員即可在報修列表中清楚辨識該筆報修為「保固內」或「保固外」。
### 預先準備與計算邏輯
* **保固起始日**：以該戶別於後台設定之 「交屋完成日」 當天作為第 1 天。
* **保固判定邏輯**：
* **保固內**：報修提報日期位於「交屋完成日」起算的保固天數內（例如：交屋日起算 365 天內）。
* **保固外**：報修提報日期已超過設定之保固天數。
***
## 操作步驟
### 第一步：管理員設定建案「報修保固天數」
1. 登入系統後，找到目標建案，點擊建案卡片右下角的 「**⋮**」（更多選單） 圖示。
2. 於下拉選單中選擇 「**報修保固設定**」。
3. 在彈出的「報修保固設定」視窗中：
* 選擇 「保固天數」。
* 於下方輸入框填入該建案預設的保固天數（例如：`365` 天）。
4. 點擊 「**確認送出**」 完成設定。
5. 設定完成後，建案卡片右上角將會顯示已設定的保固天數標籤（如：`保固天數 365天`）。
### 第二步：維護戶別「交屋完成日」
1. 點擊進入該建案，前往 **建案管理 > 戶別資訊管理** 頁面。
2. 找到目標戶別，點擊該筆資料右側操作欄位的 「**編輯**」（筆型圖示）。
3. 在彈出的戶別資訊彈窗中，於 「**交屋完成日**」 欄位選擇或填入該戶別實際的交屋日期。
4. 點擊 「**儲存**」。
### 第三步：於報修列表查看「保固狀態」標籤
1. 當客戶或工作人員新增報修單後，前往 **售服系統 > 客戶線上報修** 列表。（售服相關頁面皆可查看，如 **工務報修紀錄**、**保固評估報價** 及 **報修總表** 頁面）
2. 在報修列表中，查看 「戶別」 欄位：
* 系統會根據 【報修日期 - 交屋完成日】 與建案設定的保固天數比對：
* 綠色標籤「**保固內**」：表示提報時間在保固期限內。
* 橘紅標籤「**保固外**」：表示提報時間已超越保固期限。
***
### 常見注意事項
> 注意 1：若戶別尚未設定交屋完成日
>
> 若戶別欄位的「交屋完成日」留空，系統無法計算保固起始時間，新增報修後將無法自動判定保固狀態。**請務必確認交屋完成日已完整填寫**。
> 注意 2：保固狀態變更機制
>
> 系統判定保固狀態是以 「**報修單建立當下**」 的日期進行比對與註記。
---
# 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/shou-fu/chang-jian-wen-ti/ru-he-she-ding-jian-an-bao-xiu-bao-gu-tian-shu-yu-cha-kan-bao-xiu-bao-gu-zhuang-tai.md?ask=&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.
