你好
我是一个新的Concur用户,有一些问题,我希望有人能帮助。
在任何月份,一个月的信用卡交易通常不会在同一时间获得完全批准和提交。因此,我们有一些未分配和未提交的费用。
批准的指控让发布我们的会计系统通过一个上传,结果借记卡到适当的费用/ c和信贷美联社。记住,向美联社量要小于显示的金额为当月费用每声明由于未赋值的/ unsubmitted事务。
我们向信用卡公司全额付款,但该付款只能部分应用于上传的AP信用,在供应商账户中留下不适用的信用。
我们发布了一个反向分录,以便为未分配/未提交的交易,并将一个条目过账到任何以前未分配/未提交的交易中,这些交易后来已在Concur中提交。
这里提到的挑战是,在所有费用过账到账户之前,AP不会被更正。
我想知道你如何发布你的交易,因为这似乎不是最有效的方式。提前谢谢!
你好@拉德尔,
我公司目前使用的是CBCP卡程序,正是由于你描述的问题,我们想出了这个流程。很有可能的是,不是所有的卡片活动都将在报告中正确地协调,并在周期需要张贴到分类帐之前得到批准,我们需要一种方法来捕获全部的活动,而不仅仅是提交的内容。
因此,我们不使用批处理导出文件作为记录值的手段,而是创建了一个自定义流程,该流程使用了一些用完Analysis/Cognos的自定义报告。这些报告收集在我们的账单周期内发布的所有信用卡交易的信息,然后我们将这些报告汇编在一起,创建一个主上载到我们的分类账中。在Professional中,可能有一种更简单的方法来实现这一点,但由于我们使用的是标准,所以我们必须使用可用的方法。
我们有四个正在运行的报告:
在所有四个报告中,每一行都列出了惟一的Transaction ID,我们使用一些Excel VLOOKUP函数将所有编码信息、分配分割和itemizations拉到单个工作表中。然后我们清理数据(即将任何未定义的费用类型替换为杂项,一些组织特定的项目,并确保欺诈活动编码正确),验证总金额,并发送到我们的会计软件。
整个过程大约需要2-3个小时左右才能完成,但它为我们提供了一个报告周期内的全部交易。我们还将此作为员工的动机,告诉他们“如果您没有按时提交报告,将应用默认的编码值,如果您希望预算信息准确,您需要提交一个请求,在后端对其进行更正。”
平均来说,我们有大约5%的代码没有分配并且使用了默认代码,但是我们在一年前积极推动员工的默认代码更新,这样就减少了很多错误,即使只有这5%。
我们决定不发布我们鬼卡的CBCP费用通过一致... 由于上述问题与未分配/未提交的交易和必要的协调工作。
取而代之的是,我们从信用卡公司的发票源中寄出交易账单。
我们的Concur Travel被配置为向信用卡公司提交每个旅行者/交易的人员ID和成本分配信息,然后他们将其包含在他们的发票提要中,这样财务在收到信用卡账单时就有足够的信息进行过账。
在Concur Expense的会计提取(在我们的例子中,通过本地SAP集成到SAP FI)中,我们然后排除CBCP费用,因此最终不会发布两次。
这种方法对我们有效。可能不会为其他公司工作,但以防他们的员工拿着公司的付费卡到处乱跑,并经常错误地用这些卡支付个人费用。(我们唯一的CBCP卡是用于航班和火车预订的ghost卡。所有其他费用由员工自掏腰包支付,除了高层管理层的少数IBCP卡)。
之后,我们进行了一点努力,尽管是手动对账和“公司间结算”(在集团内部),因为我们的员工应该在他们的费用报告中输入“替代成本分配”,以防他们的差旅成本不应分配给他们的默认成本对象。为此,我们建立了每月显示差异的情报报告。。。然后,财务部门使用这些数据进行手动对账。
也许这会给你一些新的想法。。。
认为,亚历克斯
你好
对于涉及总账中临时账户的CBCP卡,我们采用了稍微不同的方法。
当我们从我们的银行收到月结单信息(以CSV格式下载)时,我们创建一个过账,将全部结单金额贷记给银行供应商,然后为每个卡交易创建单独的借记行,存入一个临时账户。在每个借记行中,我们记录银行提供的单个交易ID。
然后,当我们处理Concur的费用报销时,CBCP卡交易借记相关费用总账账户(基于费用类型),并在临时账户中创建贷记过账,将交易ID记录到同一字段中。然后,在临时账户上运行自动清算流程,将共享相同交易ID且余额为0的交易分组,并将其标记为已清算,就很简单了。
这种方法有助于我们保持“真实”总账的清洁,只过账已批准、已清算的费用,同时允许我们跟踪临时账户中未对账的费用。在每个月末,我们的财务团队可以查看临时账户中的总额,并输入适当的应计项目,然后在下个月初重新评估。
我希望这有帮助,如果需要,很高兴提供任何其他信息。
戴夫
你好
我们希望遵循与您几乎相同的流程,只是不使用临时帐户,而是上传供应商帐户上的个人借记。每个员工都将在SAP中创建为供应商。
目前的主要问题是,我们的Concur顾问无法从Master Card提要映射
您是否遇到过类似的问题?你是怎么解决的?
谢谢你!
你好
我会尽力解释我们的过程。
我们使用SAP FI本机集成将费用报销从Concur过账到SAP。此集成将信用卡交易参考号放入过账到我们临时账户的行的文本(SGTXT)字段中。我相信文本字段的使用正是因为您提到它可以支持更多的字符。
然后,在对账单发布后,我们每月从银行下载一次CSV文件。此CSV文件包含Concur中显示的相同事务参考号。然后,我们使用此CSV文件中的信息创建批量上载,以使用SM35在SAP中创建日记账。
然后,我们在SAP(OB74)中配置了自动清算,以使用SGTXT字段作为该临时账户清算的标准,然后使用一个变量设置F.13的夜间计划运行,以运行清算过程。
这使得这个过程非常有效。每天,当我们的费用处理人员批准Concur报销单时,他们会通过本机集成自动过账到SAP中,每天晚上自动清算运行,以清算和匹配临时账户中的交易。
希望这有帮助,
戴夫
嗨,戴夫,
谢谢你的补充信息。因此,Concur系统中的交易参考号与银行的参考号相同。太好了,这对我们来说是一个非常重要的信息!这应该在Concur和银行/万事达卡之间解决,为什么在我们的案例中这些ID不匹配。不幸的是,这是我们目前的一个主要障碍。您知道哪个技术字段映射到来自卡片馈送数据结构的Concur中的参考nr吗?
在标准系统中,不允许向OB74添加超过20个字符的字段。我猜你必须实现注释117393 1078256 2005540来做到这一点。你能从SGTXT中使用多少字符?
谢谢你!
韩元
伊丽娜
嗨,伊丽娜,
非常抱歉,但我不知道Concur如何映射从银行收到的导入文件-我们有来自不同提供商(MasterCard、VISA、AirPlus)的多个卡片源,并且在所有情况下都有效…Concur映射了交易参考号,与我们从每个提供商下载的CSV文件中看到的相同,以进行匹配。
我还很幸运,当我开始我们的自动清算流程时,我们的SAP系统已经启用,可以让我在OB74中选择SGTXT,因此我假设您提到的注释已经应用到我们的系统中,但这是由我们的SAP技术团队维护的。
很抱歉,我对你的问题很有帮助。。。我希望您能够通过Concur和现场测绘解决这种情况。
戴夫
嗨,伊丽娜,
我们也在尝试遵循Dave所描述的相同流程,但也面临相同的问题,即Concur提供的唯一交易密钥比SAP自动清算程序(24个字符)允许的长度长(37个字符)。我们发现在自动清除程序中只考虑前24个字符。这意味着,如果前24个字符匹配且net为零,则清除。
问题是,自动清除程序可以考虑附加项,因为它们唯一的事务密钥的前24个字符可能不是唯一的。这将导致某些项目在应该清除时无法清除。
想知道你是否解决过这个问题?
当做
迈克