【正文】 過程：這個問題出現(xiàn)的有點莫明其妙。查看了固定資產余額表和變動表的相關記錄，查看了部門分配和科目分配的情況，發(fā)現(xiàn)都很正常。相關的核算項目也很正常。后來使用profile 工具進行跟蹤，發(fā)現(xiàn)程序在數(shù)據(jù)庫中查找 fyeear＝2022,fperiod=0 的余額表記錄，12 / 14但是數(shù)據(jù)庫中并沒有這種數(shù)據(jù)。為什么要找這些數(shù)據(jù)呢？經分析，原來這個賬套是引入過來的，原賬套的開始期間是 ，而當前賬套是 啟用，而按照當前賬套的設置，初始記錄的期間應該是 ，但實際的啟用期間并不是 而是 ，而計提折舊需要用到錄入時候的數(shù)據(jù)，而大部分的卡片都是初始化的時候錄入的，找不到相應的數(shù)據(jù)，當然會出錯。解答：這種問題可能是固定資產系統(tǒng)的啟用期間和余額表不對應引起的。處理的方法是到余額表中找出最早年度和期間，然后把 t_systemprofile 系統(tǒng)參數(shù)表中把固定資產系統(tǒng)的開始年度和期間改為相應的年度和期間即可。 計提折舊時提示“名稱或代碼已經在系統(tǒng)中存在”分析過程：按照錯誤提示，“名稱或代碼在系統(tǒng)中已經存在”，按照字面理解，應該是在數(shù)據(jù)庫中已經存在同樣的記錄，導致無法保存；但據(jù)知固定資產計提折舊知識更新余額表的相關字段，并沒有涉及到新插入記錄的問題，應該是不會違反主鍵約束的。點開錯誤提示的“高級”按鈕查看，發(fā)現(xiàn)真正的錯誤明細提示是“事務超時……”。由于提示“名稱或代碼已經存在”錯誤很大一部分原因是由于系統(tǒng)環(huán)境緩慢導致的，換了一臺配置較高的機器來計提，順利通過，說明的確是事務超時的問題導致的。解答：這種問題可能是由于卡片太多，事務超時引起的?？梢缘街虚g層服務器的管理工具的“組件服務管理器”中把組件的超時時間改為 0 看看。據(jù)經驗，如果固定資產卡片超過了 20220 條，則可能會出現(xiàn)這種問題。V94 版本已經作了優(yōu)化。 點擊類別管理時提示“element not found”分析過程：錯誤的意思是說“元素未發(fā)現(xiàn)”，這種“元素”一般是在填充某個數(shù)據(jù)樹狀結構的控件時的某個節(jié)點。為說明說“沒有發(fā)現(xiàn)”呢？原來程序在填充這些節(jié)點的時候，是按照先填充上級節(jié)點，然后填充下級節(jié)點的順序進行的，填充下級節(jié)點的時候，需要提供“上級節(jié)點”的值，如果這個值有誤或不存在，則會出錯。由于固定資產的類別是分級的，可能是數(shù)據(jù)庫記錄上下級次紊亂，查找 t_fagroup 固定資產類別表，發(fā)現(xiàn)有些記錄的fparentid（父級內碼）根本就非法，該內碼是不存在的，改為正確的、存在的內碼即可。解答：一般是固定資產類別表 t_fagroup 表記錄有非法情況引起的，如某類別的上級類別不存在。處理方法是把該記錄的上級內碼改為正確的、存在的上級內碼即可。 卡片新增保存時提示“類型不匹配”分析過程：13 / 14查看固定資產相關的數(shù)據(jù)很正常，使用 profile 工具也跟蹤不到有用的 sql，后來求助開發(fā)部使用程序進行斷點跟蹤，發(fā)現(xiàn)原來在保存的時候日期格式不對，為什么不對呢？原來系統(tǒng)保存時要取當前期間是從哪天開始的，而在 t_systemprofile 中沒有有關固定資產期間定義的記錄。該問題在 v93 以前是不存在，v93 版本開始卡片保存時才需要用到這個定義信息。同樣的賬套，使用 v91 版本來新增保存是正常的。解答：可能是由于固定資產期間定義丟失導致的。在 t_systemprofile 中有一個perioddates 的記錄，是專門用于記錄每個期間是從哪月哪日開始的，手工插入即可?？梢詤⒖伎傎~的定義，一般和總賬是一致的。 某個卡片作變動時提示“缺少余額數(shù)據(jù)”分析過程：提示“……缺少余額 ID Fassetid=180”，根據(jù)錯誤提示到 t_fabalance 表中查找fassetid=180 的記錄，發(fā)現(xiàn)只有初始錄入的那條記錄，而按照標準，每一個期間都是需要有一條數(shù)據(jù)的。這說明數(shù)據(jù)殘缺。解答：可能是在當期 t_fabalance 等等相關數(shù)據(jù)引起的。一旦出現(xiàn)這種錯誤，在t_fabalance 表中除了一條錄入該卡片時的記錄之外，其它期間的記錄可能都已經丟失。處理的方法是反結賬一直回到該卡片新增時的期間，編輯該卡片并重新保存，然后一期一期結賬過來即可。這種問題一般是有金蝶 2022 賬套升級上來導致的。 固定資產自動對賬和總賬對不上，但其它報表和總賬對的上分析過程：固定資產變動情況表的數(shù)據(jù)是最準確的，正常情況下，各種報表之間數(shù)據(jù)都是一致的。但是如果存在問題的話，可能就不一致。經查看 t_fabalance 余額表，發(fā)現(xiàn)其它報表的數(shù)據(jù)是對的，而自動對賬的數(shù)據(jù)是錯誤的。經過跟蹤，發(fā)現(xiàn)自動對賬查找數(shù)據(jù)的sql 使用了余額表和變動相關表，而余額表和變動相關表相關連的條件是固定資產內碼之外，還有固定資產的變動日期。去除變動日期的限制，數(shù)據(jù)就和其它報表的一致了，這說明變動相關表和固定資產余額表的變動日期有某些卡片存在不一致的情況。經查，確實如此。解答：這種情況一般是固定資產變動相關表和余額相關表的日期不相同導致的。正常情況下，t_faalter 和 t_fabalance 的變動日期是一致的，但是由于升級或其它的原因導致不一樣，而自動對賬的 sql 中是用到了這個變動日期的。使用下面的 sql 可以修正：update bal set faltdate= from t_fabalance bal,t_faalter faalter where =and =(select max(falterid) from t_faalter where fassetid=and (fyear or (fyear= and fperiod=)))14 / 14 折舊明細表和折舊費用分配表的折舊額不一致，其它報表正常分析過程：固定資產明細表和折舊費用分配表都涉及到了“分配”的問題，只不過不同的是“明細表”在部門和類別中分配，“費用分配表”在“折舊費用項目”中分配。既然有分配的問題，就有分配率的問題。經跟蹤兩個表的 sql 語句，發(fā)現(xiàn)都使用了余額表，折舊分配表還使用了折舊費用科目分配表。查找 t_fabalance 、t_fabaldept 和 t_fabalexpense 的記錄數(shù)目，發(fā)現(xiàn) t_fabalexpense 的數(shù)量少于 t_fabalance，而按照規(guī)則，t_fabalance 和t_fabalexpense 的記錄數(shù)應該是對應的，最起碼應該是 t_fabalexpense 和 t_fabalance紀錄數(shù)一樣多，而不應該少于 t_fabalance 表，因此發(fā)現(xiàn)了 t_fabalexpense 記錄缺少。解答：這種情況一般是 t_fabalexpense 或 t_fabaldept 等等相關表有某個表記錄丟失引起導致的。如余額表 t_fabalance 表有 1000 記錄，而 t_fabalexpense 只有 999 條記錄，說明 t_fabalexpense 缺少了一條，必須補上。修補的方法是參考 t_fabaldept 表或t_fabalexpense 表對應的記錄補