Changelog

Haben Sie etwas zu sagen?

Sag conlutio, wie sie das Produkt nützlicher machen könnten!

Completed

Corrupt files when loading from GOS

In rare cases, files in XML Office format (e.g. .xlsx, .docx) which are taken over from the generic object services are corrupted. The Microsoft Office programs can still open these files, but show a warning message. This problem is caused by unnecessary characters at the end of the file which are added during import. This error is corrected with Support Package 08.

Jürgen Almost 4 years ago

🪲Bugs

Completed

Direct upload using an external archive system

The direct upload function currently saves uploaded files in a database table. This table can become very large under certain circumstances. There must be a possibility of storing the files in the external archive system (via Archive Linke content repositories) when using the direct upload function.

Jürgen About 4 years ago

📝 Feature Request

Process responses received by email

Many e-mails are sent to business partners from SAP via the xtMail Suite. Answers to this end up in the sender's normal e-mail inbox and cannot be seen in SAP. Solution: In the customizing of the xtMail Suite it should be possible to set a Reply-To address. An email address that is processed by SAP is specified here. Alternatively, an employee can simply forward a received email to an email address in SAP. Outgoing e-mails must automatically have a unique ID, for example at the end of the e-mail or in the subject If a recipient replies to an e-mail, the reply can be processed automatically. The unique ID is used to identify the outgoing document to which the response belongs and the received e-mail can be automatically stored there in the services for the object. However, there should be a report in SAP in order to be able to monitor and read all incoming e-mails with various selection options and authorization checks. In a second step, semi-automatic processing would also be desirable. In this, incoming answers are first collected and a user can decide what should happen with them. Some delivered or freely definable actions would also be important here. Example for "Actions": - Discard the email - Archive the e-mail on the outgoing document - (MM) Maintain an order confirmation and archive the e-mail afterwards - (SD) Create sales order for an quoation and store the e-mail on both documents. - ...

Jürgen Over 4 years ago

📝 Feature Request

Request Read Receipt for outgoing emails

In Microsoft outlook it is possible to request a read receipt for sent emails. If this is supported by the recipients e-mail client he can send a mail back automatically to confirm that he has read the email. There should be an option to enable this in xtMail Suite to. The interface of CL_BCS allows this by calling SET_STATUS_RECIPIENT.

Jürgen Over 4 years ago

📝 Feature Request

Completed

New Cockpit Action - Forward in Outlook

If an email was already sent successfully and is listed in the cockpit transaction, there should be a new action button "Forward in outlook". When clicking this button a copy of the email with all recipients, subject, mailtext and attachments should open in Outlook, but the user can change it to forward it to somebody else. Update, function will be available in detail screen of sending log:

Jürgen Over 4 years ago

2

📝 Feature Request

Keep unresolvable text symbols when maintaining emails

Some text symbols (placeholders) cannot be replaced when creating a new document, e.g. the document number is unknown before saving the first time. If the e-mail is maintained in dialog these placeholders are removed as the placeholder is initial. e.g. Subject: "Purchaseorder &EKKO-EBELN& / &EKKO-EKGRP& is replaced by Subject: "Purchaseorder / 123" If changing the subject in dialog the text symbol is permanently removed. Same applies to mailtext. Possible solution: If a text symbol cannot get resolved as it is currently empty, the placeholder should be shown in dialog. So with above example when calling the dialog the subject should be "Purchaseorder &EKKO-EBELN& / 123". When the subject is changed by the user and he keeps the text sybol it should be still replaced during sending.

Jürgen Over 4 years ago

📝 Feature Request

Completed

Changing language or partners displays wrong e-mail content

This is only a display problem (new UI) but should get fixed: Create a new document, e.g. an sales order Call the dialog of xtMail Suite one time and leave it again Change the partners of the sales order or change the communication language without saving the changes. Call the dialog of xtMail Suite again -> It still displays the data based on the partners or language of the first call. When sending the e-mail, always the correct data is used.

Jürgen Over 4 years ago

1

🪲Bugs

Planned

More Placeholders for filenames/attachments

There are placeholders which can be used to create a filename for attachments in the sending profile. Eg. Order_Confirmation_{{DOCNUMBER}}.{{EXTENSION}}. The available placeholders are limited to fields in Structure /conlutio/ms_filename: This structure should get extend to also allow document or business partner specific fields to be replaced. Examples are: Sales: Customer purchase order number (VBAK-BSTNK) Customer: Shipper's (Our) Account Number at the Customer or Vendor (KNVV-EIKTO) It would further be very useful if customers could append own fields to /conlutio/ms_filename and to fill them with a new BAdI-Method.

Jürgen Over 4 years ago

📝 Feature Request

New BAdI-Method to change the final mailtext (with signature and HTML coding)

The current BAdI-Method SET_MAILTEXT is called for the actual mailtext but does not contain the signature or html coding which was added via profile. We need a new BAdI-Method (e.g. SET_MAILTEXT_FINAL) which is called when the final mailbody was created by the mailtext profile. The text, which could be changed by the method, should include HTML-Header, Text, Signature and HTML-Footer with all replacements of text-symbols done.

Jürgen Over 4 years ago

📝 Feature Request

Completed

New sender type - reply-to address

E-mails can have an additonal "reply-to" address which might be different from the actual sender. This is a header field in the e-mail (https://en.wikipedia.org/wiki/Email#Message_header). The sender profile should be extended with a new sender type (with a fixed e-mail address) to set the reply-to address(es) in the header if it should be different from the sender address. . Preview Support Package 08:

Jürgen Over 4 years ago

2

📝 Feature Request

Completed

Email recipient - fixed recipient

We already have several organizational units that in certain cases would like to send an email to the same email address that is independent of the document, e.g. in the case of a fall-back solution. So far we have solved this using the BAdI. However, we would like to forego the developments if there were also a fixed email address as the recipient type -> analogous to the organizational unit in the sender profile.

Jürgen Over 4 years ago

1

📝 Feature Request

Completed

Archive outgoing emails in EML Format in generic object services

At the moment, outgoing e-mails are only documented in the sending log of the xtMail Suite. For long-term archiving, it would be desirable to store the e-mail (additionally) in EML format in the generic object services of the document. The assignment to a document type would be useful.

Jürgen Over 4 years ago

1

📝 Feature Request