我已经构建了一个应用程序来为客户端生成NACHA文件。它看起来可以正确执行所有操作,除了尝试将输出上载到ACH系统时,文件被拒绝。就我所能解决的问题而言,它似乎与NACHA格式所期望的记录分隔符有关。
应用程序从多个Excel电子表格中提取数据,并以NACHA格式输出.txt文件。由于客户的要求,它是用VBA编写的(尽管VB.NET可以作为替代选择)。
输出遵循所有记录的格式要求,但是银行的系统以错误消息响应,指示错误的记录长度。但是,我们尝试将输出的精确副本手动输入到记事本中,银行的系统已接受该输入(!)
通过TextStream方法生成输出。这是我原始代码的简短示例:
Dim fso As Object
Dim stream As Object
'Create output file
Set fso = CreateObject("Scripting.FileSystemObject")
If fso.fileexists(SavePath) Then Kill SavePath
Set stream = fso.CreateTextFile(SavePath, False, True)
'Insert file header
FileHeader = Get_1_Record
stream.WriteLine FileHeader
...其中,Get_1_Record是一个子函数,用于汇编包含该特定记录的文本字符串。
WriteLine自动在记录的末尾插入换行字符(ASCII码10),这似乎是不正确的。当银行的技术支持人员告诉我他们已经成功上传了手动键入的文件副本时,我认为答案将是代替回车(ASCII码13)。他们必须使用“ Enter”键结束每条记录,据我所知,每条记录都会插入一个CR。因此,我尝试了上面的最后一行:
stream.Write FileHeader
stream.Write Chr(13)
但这一次,银行的系统将整个文件视为一行。
我看过其他语言的代码示例,例如js,但它们似乎都在应用隐式记录定界符,类似于此处使用的WriteLine方法,因此我看不到如何构造单个记录。
我在这里不知所措,坦率地说超出了我的深度。有人能对此提供一些见识吗?我是否通过关注记录定界符来吠叫错误的树?
答案 0 :(得分:1)
我们尝试手动将输出的精确副本手动输入到记事本中,这被银行系统接受(!)
这是正常现象,因为记事本没有显示诸如换行符之类的分隔符...问题可能是银行看到了chr(13),但是期望的是chr(13)和chr(10)从技术上讲,即使您在记事本上看到的外观相同,大小也不一样。 如果您尝试用chr(13)和chr(10)和chr(10)替换chr(13),它应该可以工作
所以尝试:
stream.Write vbcrlf