ORALCE EBS大陆本地化功能需求征集

Frenkie1979

原帖由 goodhawk 于 2009-3-18 15:46 发表
好吧, 那我也来说几个, 回头有啥消息通知一下我.

1, 11i 是没有这个 subleger 的东东, 那么, 如果财务对于已经处理完毕的 journal, 在 装订的时候, 想针对某些 Journal 里头的某些 Account 进行汇总打印, 明细帐也是汇总打印, 是否有更好的solution.

2, 啥时候给中国的用户提供一套比较漂亮的 凭证, 明细帐, 科目余额 之类的报表哇.现在里头有fsg,也有很垃圾的报表,苦了广大人民群众.

3, 是否可以直接导入 付款

4, 报表打印 啥时候不要有那么多的bug, 莫名其妙的问题? 啥时候会是稳定的版本.

唉,简直就是苦水, 不说了. . .

4, 1 个OU为另外一个 OU 的付款, 该如何来做?

关于付款，查看了R12 新增的Oracle 集成信息库中，发现可用的接口都和EDI有关系，不熟悉那个东东 列下列内容吧 看是否有用
名称 内部名称产品类型状态说明OUTBOUND: Payment/Remittance (820/PAYORD/REMADV)APECEPYOPayablesOpen Interface有效Extracts the Payments/Remittances created in AP and writes it onto a EDI flat file.Outbound Payment/Remittance Advice (PYO) Extensible ArchitectureEC_PYO_EXTe-Commerce GatewayPL/SQL有效This package contains routines to populate additonal columns for 820/PAYORD Payment Advice/Remittance Outbound (PYO) flat file.Payment Order/Remittance Advice Invoice ViewECE_PYO_INVOICE_VPayables接口视图有效This view extracts invoices selected for payment to support the outbound Payment Order/Remittance Advice (820/PAYORD/REMADV) transaction.Payment Order/Remittance Advice Payment ViewECE_PYO_PAYMENT_VPayables接口视图有效This view extracts payment information for the outbound Payment Order/Remittance Advice (820/PAYORD/REMADV) transaction.

好好工作

AP：交叉付款，即发票币种为USD，付款用HKD，本币为RMB，没办法做。AR可以交叉收款的。
AP：应付票据，虽然有远期付款的功能，但没有票据交换、信用证功能。
AP：供应商关系，即采购订单供应商为A，但开票公司为B，或者开票公司为B，但收款公司为C(不要说用供应商地点来做哦）
AR/AP的外币重估：只能在GL，针对帐户余额进行重估，而不能针对供应商/客户的具体每一笔发票余额进行重估。

ORACLE的AP做得很垃圾，相反，AR则细致得多。


另外，说下楼上的，1 个OU为另外一个 OU 的付款, 该如何来做?
这个在R12下也是没法做的，MOAC只是让你在不切换职责的情况下，录入付款时，选择一个OU，但还是必须与发票的OU一致。

ayoung

精华.

Frenkie1979

原帖由 好好工作 于 2009-3-19 08:51 发表
AP：交叉付款，即发票币种为USD，付款用HKD，本币为RMB，没办法做。AR可以交叉收款的。
AP：应付票据，虽然有远期付款的功能，但没有票据交换、信用证功能。
AP：供应商关系，即采购订单供应商为A，但开票公司为B，或者开票公司为B，但收款公司为C(不要说用供应商地点来做哦）
AR/AP的外币重估：只能在GL，针对帐户余额进行重估，而不能针对供应商/客户的具体每一笔发票余额进行重估。

ORACLE的AP做得很垃圾，相反，AR则细致得多。


另外，说下楼上的，1 个OU为另外一个 OU 的付款, 该如何来做?
这个在R12下也是没法做的，MOAC只是让你在不切换职责的情况下，录入付款时，选择一个OU，但还是必须与发票的OU一致。

明白了 呵呵  做过的项目涉及到外币核算的不多 ，你说的这些我看了一下标准功能，是这个样子。 1 个OU为另外一个 OU 的付款确实做不到。但这种业务在逻辑上也存在一定的问题  OU层之间的业务隔离逻辑也是符合现实业务情形的

Frenkie1979

呵呵 另外 我开这个主题主要是想大家一起找出具有中国特色的需求出来  账证表 其实是蛮有特色的 SAP产品有中国的研究院 针对各行业也做了不同的产品方案出来 不像oracle 弄了个半成品出来  得靠自己来装修 苦了咱们 到处修修补补 解决bug的时间有的时候都大于真正的钻研系统的时间 这也很大程度上阻碍了产品行业特点的形成  产品所蕴含的管理思想不是没有 而是比较散乱和残缺  不是很完美 甚至于一些标准的企业业务流程点在新产品中都未完全走通的情况下  匆匆发布产品 虽然抢了市场 但是却失去了口碑  中国的企业信息化的核心原则是什么？ 稳定。务实。高效  oracle做的不好 太急于炫耀自己了 这样会害死我们这些工人 标准的ERP工人 纯卖体力了。

好好工作

原帖由 Frenkie1979 于 2009-3-19 09:27 发表
呵呵 另外 我开这个主题主要是想大家一起找出具有中国特色的需求出来  账证表 其实是蛮有特色的 SAP产品有中国的研究院 针对各行业也做了不同的产品方案出来 不像oracle 弄了个半成品出来  得靠自己来装修 苦了咱们 到处修修补补 解决bug的时间有的时候都大于真正的钻研系统的时间 这也很大程度上阻碍了产品行业特点的形成  产品所蕴含的管理思想不是没有 而是比较散乱和残缺  不是很完美 甚至于一些标准的企业业务流程点在新产品中都未完全走通的情况下  匆匆发布产品 虽然抢了市场 但是却失去了口碑  中国的企业信息化的核心原则是什么？ 稳定。务实。高效  oracle做的不好 太急于炫耀自己了 这样会害死我们这些工人 标准的ERP工人 纯卖体力了。

就像R12，安装了一个，在里边转了几圈，录入供应商、客户，什么乱起八糟的网页界面，眼花缭乱，点来点去，操作及其繁琐，赶紧闪人。
个人觉得ORACLE的FORM技术已经相当成熟，对end-user以及developer都是舒服的，为啥搞网页界面。

这个R12也是一个过渡性的卖唱的产品，看看ORACLE的下一代FUSION又会长出个什么怪胎。

wordsenyu

我来提一个，国内的制造业一般都用标准成本，但是报表又要求用实际成本，是否可以开发一个程序来自动算出物料的实际成本？

yichao0614

运费7%税率处理问题，PO含税价处理问题（虽然可客制，但国内多数企业以含税价进行采购的）

Frenkie1979

原帖由 yichao0614 于 2009-3-19 11:50 发表
运费7%税率处理问题，PO含税价处理问题（虽然可客制，但国内多数企业以含税价进行采购的）

这个问题我发过SR  以下是oracle的答复

ANSWER ====== PO does not support inclusive handling tax. It support only exclusive handling tax. oracle support  
This is because in purchasing while creating a PO the line amount will be decided first and it will be fixed . On top of that tax will get calculated based on the line amount. hence Exclusive handling tax will come in to picture here and not the Inclusive handling tax 、
Where as in AP while invoicing you specify the amount and create the invoice where the amount will be adjusted and Inclusive handling tax will come into picture If you want the PO to support the inclusive handling tax then an Enhancement request would be raised for the same.  

If you want the PO to support the inclusive handling tax then an Enhancement request would be raised for the same. Please confirm on this.   


Enhancement request  是个很遥遥无期的事情

好好工作

罄竹难书，罄竹难书...