FA-期间重新打开

摘自:http://blog.itpub.net/7735683/viewspace-417431/


FA 期间被认为是 关闭后不再能打开。

虽然不知道强行打开具体会有什么问题出现, 但是还是避免不了客户误操作导致期间关闭,所以重新打开的需求将是很迫切的。我在一次事件中做过这样的操作, 测试了运行折旧, 和创建凭证, 以及核对资产的折旧金额, 均没发现问题。下面把修改过程共享下, 需要提醒的是 我在测试环境下通过, 如果要用到正式环境,请自己再仔细核对数据, 仅做学习之用。

某个客户 在7月1 号结6月帐的时候错误的把7月的帐也给关了
解决步骤如下:

SELECT * FROM APPS.FA_DEPRN_PERIODS P
WHERE P.PERIOD_NAME='JUL-08'
AND BOOK_TYPE_CODE = &book_name
--把7月的period_close_date 置为空(必须)
  把deprn_run 置为空(可选)


select * from fa_book_controls --last_period_counter
 where book_type_code=&book_name
--把 LAST_DEPRN_RUN_DATE  改为上个期间的关帐时间,从FA_deprn_period 中获得.
     DEPRN_REQUEST_ID 置为空。
     LAST_PERIOD_COUNTER 改为上个期间对应的FA 期间。

这个时候在fa_deprn_periods 应该会有两个记录的period_close_date 为空
 SELECT *
      --  INTO   :DEPRN_RUN.period_name
        FROM   fa_deprn_periods
        WHERE  book_type_code = &book_name
        AND    period_close_date
用下面的语句删除不要的那个期间
 delete from fa_deprn_periods 
 where book_type_code =&book_name
 and period_Name ='AUG-08'

--然后去运行折旧程序, 参数自动的出现了JUL-08
正确运行后再rollback 折旧(程序会把所有的旧数据都删除)。
再次运行折旧程序
fa_deprn_detail, 和 fa_deprn_summary 生成了最新的数据。

以上是11.5.8 测试环境下通过测试。欢迎大家讨论。


### 解析 Invalid UTF-8 Byte 错误 当遇到 `Invalid UTF-8 byte` 报错时,通常意味着程序尝试处理的数据流中包含了不合法的UTF-8编码字符。对于特定错误 `'FA.'` 的情况,在不同环境下可能有不同的原因和解决方案。 #### 数据源验证 确保输入数据确实是以UTF-8格式编写的非常重要。如果文件是在其他编码下创建的,则读取该文件的应用程序可能会因为期望的是UTF-8而抛出异常[^1]。 ```python import chardet def detect_encoding(file_path): raw_data = open(file_path, "rb").read() result = chardet.detect(raw_data) encoding = result['encoding'] return encoding file_path = 'path_to_your_file' print(f"The detected encoding of the file is {detect_encoding(file_path)}") ``` #### 修改IDEA配置 在开发环境中(如IntelliJ IDEA),可以通过调整项目设置来指定正确的编码方式: - 打开Settings/Preferences对话框 (Ctrl+Alt+S 或 Cmd+, on macOS). - 导航到Editor -> File Encodings. - 设置Global Encoding 和 Project Encoding 均为UTF-8. 此更改有助于防止因编辑器内部使用的默认编码与实际文件编码不符而导致的问题[^2]. #### Windows系统环境变量设定 针对Windows操作系统,默认情况下其控制台和其他组件采用ANSI作为主要编码标准而非UTF-8。为了使应用程序能够正确识别并解释来自外部资源(比如网络请求响应)中的Unicode字符,可以考虑修改系统的区域性和语言选项: - 控制面板->地区->管理标签页下的“更改系统区域设置”,勾选Beta版: 使用 Unicode UTF-8 提供全球语言支持。 这种做法能有效减少跨平台传输过程中产生的兼容性问题. #### Web服务器端点调试(LoadRunner场景) 如果是通过LoadRunner执行性能测试期间发生的此类错误,除了检查上述提到的内容外,还需要特别关注HTTP协议级别的参数配置。具体来说就是确认录制脚本时所选用的支持字符集是否恰当以及运行时间内的相应选项是否有做适当调整[^3]: - 录制选项 -> HTTP属性 -> 高级 -> 支持字符集; - 运行选项 -> 浏览器仿真模式 -> 字符串表单提交; 以上措施可以帮助缓解由客户端和服务端之间通信引起的潜在编码冲突。 #### XML声明修正(Apache Tomcat部署案例) 最后一种可能性涉及到XML文档本身的定义不当造成的解析失败。特别是那些用于描述Web应用结构的配置文件(.xml),它们应当明确定义根节点及其子元素遵循的标准命名空间规则。例如,对于Java EE web.xml 文件而言,应该包含如下声明以指明预期接收的内容类型[^4]: ```xml <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> </web-app> ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值