Does anyone have experience successfully adding an assembly reference to an Electronic Interface?
I was able to get a 3rd party assembly (SshNet for SFTP) loaded through reflection and the result was cumbersome to say the least, but it works. Now I need to write back to the database and would like to use business objects per best practices. There has to be a better way to add a reference to an Epicor BO in the Electronic Interface code other than reflection, right?
Ewwww. I dont think there is a way in the EI files to do such without reflection. Perhaps you could move your code to either the form before/after the EI code is run? Or is there a BPM somewhere you could hang the logic off of? I honestly dont know, just trying to throw you a bone since it seems like a bear of a task.
I’m with Chris. What’s the business objective here? What document are you exchanging and what are you trying to post back?
A BPM could probably work. I’ll lose any options for verifying that the SFTP upload was successful though. Still, it’s something to consider.
What are you trying to update? you already have the Db Context object … I’m curious as to what you are trying to update that you don’t want to update directly.
The business objective is to process AP Payments straight to the bank. So far, it’ll generate a file (CSV) and upload it to the bank’s SFTP. The latest requirement is that we record back a reference to the AP Tran if the upload was successful, so I was looking to utilize the APTransSearchSvcContract in Erp.Contracts.BO.APTranSearch.
I was just going to toss it in the APTran comments, but that could change later.
Could I push it straight into the database? Yes.
Should I? Well…
Well its the Db Context and its a comment field… I don’t see any red flags.
Gotcha. At least with our ACH file, uploading it only makes it available for another user to approve so we wouldn’t know if it was successful or not until then. And even then, what does “successful” mean? Are we talking about an individual payment? The whole upload file? We’ve had the controller not approve a few payments but let the rest flow. Also, updating posted AP Invoices is a tricky business, let alone paid invoices.
How about making a Memo entry? That’s pretty safe and can be done after payment. You can create a Memo Category for FTP Transmission and then post the info in the Description and/or Text. This field is available from A/P Invoice Tracker too. (The “Post It” Note icon).
Mark W.
Our processes are a little different in that all approvals are already in place by the time the AP Payment is being processed. So, for us, success means that the individual payment was included on a file that made it to the bank’s SFTP. Dealing with the individual transactions isn’t too bad in this case because I already have to go through them to create the file as the bank wants it.
I do like the idea of a Memo entry. Safe and accessible. Thanks, Mark!
why not just make an external app then to monitor the output folder for the file, then you can snatch it up and SFTP it? You can also do your interface back to epicor, preferably using REST, but also you can use WCF.
That method was considered initially when we were exploring how to do this. Putting everything into the EI allows us to utilize Epicor’s own error handling to let the user know if there was a problem immediately. The main concern is that a payment would be processed in Epicor and Accounting wouldn’t necessarily know if there was a failure until the vendor asks us to pay them again.
Additionally, we can send the file immediately (and the bank picks it up within seconds) rather than having to deal with a delay from either a scheduled task or a service. I’ve also seen enough problems introduced from services not coming back up after a server reboot or colleagues disabling tasks inadvertently that I prefer not to trust business-critical tasks to those methods.
Should recording of the payment reference from the bank be done asynchronously? If yes then you would be better by creating a scheduled task.
Usually I would be all for asynchronous processing for better performance and less risk of locking, but not in this case. Each step of this process necessarily relies on the success of the previous step to begin and we want to judge the payment processing as successful only if the entire process (including sending the file to the bank) completes.
