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