search

microsoft / ALAppExtensions

Repository for collaboration on Microsoft AL application add-on and localization extensions for Microsoft Dynamics 365 Business Central.
MIT License
795 stars 622 forks source link

[Request for External] E-document: EDocExport; Allow send from manual Doc. Send. Profile #25785

Open JaredKMiller opened 10 months ago

JaredKMiller commented 10 months ago

Describe the request

Please remove internal on EDocExport CheckEDocument, CreateEDocument, ExportEDocument, ExportEDocumentBatch.

Additionally, it would be helpful if we could trigger E-Document creation from standard Document Sending Profile instead of only via the OnAfterPost subscribers. (For instance, with the Posted Sales Invoice, Send button; allow the Select Sending Options dialog to trigger E-Document creation. So, remove the "E-Document Subscription".BeforeSendEDocument block of handling "Extended E-Document Service Flow")

Additional context

We would like to extend E-Documents to other types of Records, as well as be able to trigger E-document creation manually via Document Sending Profiles instead of just OnAfterPost events. Internal work item: AB#498035

pduck27 commented 7 months ago

I would like to support this two request. It confuses users using the dialog. And also prevents the re-creation of eDocuments after posting. Also none of them is mentioned in the official documentation.

Groenbech96 commented 2 months ago

We are not going to do that. These are not meant as points of extensibility. The interfaces that are provided are the extensibility points.

Feel free to describe your scenario, as i dont understand why you need these removed. Can you give me an example of triggering standard document sending profile, and feel free to create a PR with this idea.

y0m0 commented 4 weeks ago

@Groenbech96

We are not going to do that. These are not meant as points of extensibility. The interfaces that are provided are the extensibility points.

Understandable, probably a better approach would be to expose them via some facade codeunit or some other interface.

Feel free to describe your scenario, as i dont understand why you need these removed. Can you give me an example of triggering standard document sending profile, and feel free to create a PR with this idea.

I guess a simple example would be an existing BC customer that wants to start using the E-Document module. Imagine they have a bunch of already posted sales invoice that they now want to send via E-Document.

Another simple example could be that a user forgot to add the correct Document Sending profile code to a customer card before posting a sales invoice. And after discovering and correcting it, now they want to send the already posted sales invoice as an E-Document.

Lastly what if we want to send a custom document type as an E-document?

As far as I know at the moment there's no way of doing that.

DanielGoehler commented 4 weeks ago

I guess a simple example would be an existing BC customer that wants to start using the E-Document module. Imagine they have a bunch of already posted sales invoice that they now want to send via E-Document.

I’ve noticed the same recently while preparing to teach our customers about the new e-document module. In Germany, they’re legally required to send electronic invoices to B2B customers if requested.

pduck27 commented 4 weeks ago

@Groenbech96 Another simple example could be that a user forgot to add the correct Document Sending profile code to a customer card before posting a sales invoice. And after discovering and correcting it, now they want to send the already posted sales invoice as an E-Document.

Or you must switch the format / channel and resend without posting a credit memo before. In Germany are (unfortunatley) a couple of allowed formats and channels in place.

We also have customers who use batch jobs for final sending. Sometimes they prepare / enhance the posted invoices with attachments (e.g. work time sheet) afterwards in a batch job before final sending. So the creation should not be hard linked to posting in BC.

Groenbech96 commented 3 weeks ago

@y0m0 I totally agree that we should add support for these cases. We are looking into how we can natively support this in the framework. As Aleksandar (PM on EDocuments) said, this is going to be looked at in coming months.

Groenbech96 commented 3 weeks ago

@pduck27

We also have customers who use batch jobs for final sending. Sometimes they prepare / enhance the posted invoices with attachments (e.g. work time sheet) afterwards in a batch job before final sending. So the creation should not be hard linked to posting in BC.

Could you describe this in more detail for me? I am curious what challenges they have with current framework, and if it is supported at the moment? The more i know about scenario the better. And if you are at Directions this week, lets talk!

Groenbech96 commented 2 weeks ago

Would this be flexible enough? @JaredKMiller @y0m0 @pduck27 @DanielGoehler Image

Groenbech96 commented 2 weeks ago

Idea here is that we now have action "Post and Send (With service) that will trigger edocument creation. Post would no longer send anything. Just post. Then we will add capability to trigger creation of Edocument after it beeing posted.

DanielGoehler commented 2 weeks ago

@Groenbech96 I don't see any difference compared to today. When you post the invoice, it will be sent to the E-Document Module. As @y0m0 mentioned, if you change the document sending profile from Email to E-Invoice after posting, you can send this document to the E-Document Module.

y0m0 commented 2 weeks ago

@DanielGoehler I think the flow chart is correct. The difference from today solution would be that it's possible to avoid creating E-Documents on Posting and instead manually invoke an action afterward.

@Groenbech96 I think we are going in the right direction, but I have a few doubts/questions:

  1. wouldn't it be better or easier to add a setup field to turn on and off the auto creation of E-Docs on posting? In this way a end user won't need to use a different action to post with or without send to w.service

  2. It would be nice to be able to use the new capability to trigger creation of E-Document from a job queue.

  3. In your suggested solution, how would we handle Validating documents? We should avoid ending up in a situation where a posted document is now missing some information causing the E-Document Check to fail. This obviously assumes that a Document Profile was set on the Customer Card before posting.

  4. In regards to extensibility, I can think of a few possible scenarios, but they all boils down to being able to use the E-Document module for other type of documents which are not already included in the framework. Because of how CheckEDocument, CreateEDocument, ExportEDocument, ExportEDocumentBatch are all set to internal we still wont be able to do it. Or at least not without copying a huge chunk of the E-document module to replicate the same functionality. I understand not wanting to expose those procedure from the E-Doc Exp. codeunit but I really think we should find a solution for this issue.

DanielGoehler commented 2 weeks ago

@y0m0 Thank you. So, the Create E-Document action is a manual user action. I find this flowchart a bit confusing because the action is triggered in "Post Document". It would be great if this could instead be triggered in "Posted Document".

pduck27 commented 4 days ago

Sorry for not replying but I read all the comments and appreciate all of your support. I think the idea of @Groenbech96 is nice, especially for smaller customers. But for larger ones I would try not to find a setup way but more extensibility for partners. @y0m0 mentioned most of the necessary requirements in the last post. In our current projects we spend most of the time to clarify the contents of the invoices lines and resend several times. Especially stuff around "item no.", credit lines, discount lines is exhausting because E-Invoice formats to not follow the NAV/BC structure of posted documents. Resending and the possibility to jump on events during creation would be very helpful.