### Bug Classification - [x] Affects multiple customers - [ ] Affects only one customer ### Customer Interaction - [ ] Yes, reviewed together with the customer via TeamViewer - [ ] Yes, documented via screenshots - [ ] No, meeting is still pending - [x] No interaction yet ### Description of the Bug Bei Verwendung des Java-SDK wird eine vom Aufrufer gesetzte AttachmentId beim Erstellen des Payloads überschrieben. Dadurch geht die fachliche Referenz zwischen Fachdaten und Attachment verloren. Im .NET-SDK wurde dieses Verhalten bereits behoben (Fix in v3.0.3, Commit f71a11c6 vom 12.01.2026). 1. Attachment mit eigener attachmentId im Java-SDK erzeugen (z. B. über new Attachment(UUID, ...)). 2. Submission/Reply mit diesem Attachment über Java-SDK versenden. 3. In der ausgehenden Verarbeitung/Metadata bzw. Announcement prüfen, welche ID verwendet wird. 4. Beobachtung: Java-SDK ersetzt die ID durch neue zufällige UUID(s), Referenzen auf die fachlich gesetzte ID brechen. ### Current behavior: Java-SDK setzt in AttachmentPayloadHandler die attachmentId immer per UUID.randomUUID() neu, auch wenn am Attachment bereits eine ID gesetzt wurde. ### Expected behavior: Wenn eine attachmentId gesetzt ist, muss diese unverändert übernommen werden. Nur wenn keine ID gesetzt ist, darf das SDK eine UUID erzeugen. ### Environments: <!-- Specify here which environments are affected, e.g. DEV, TEST, STAGE, PROD --> ### Additional Information: - Betroffen im Java-SDK weiterhin reproduzierbar (u. a. bis Tag 3.1.3). - Abweichung zwischen SDKs: - .NET-SDK: Fix vorhanden in v3.0.3 - Java-SDK: weiterhin nicht konform zur REST-API und zum .NET-Verhalten ### Dependency / relationship to other issues: <!-- Write down here what kind of relationship it is and a brief explanation of it. --> ### Responsible person / team: <!-- Insert here the name of the person or team responsible for processing the bug. --> ## Transfer history to different teams <!-- Stories are sometimes assigned to different teams for processing. In this context, it has been found that a history of why the ticket was assigned to a particular team can be very helpful. --> ### Contact persons including contact details: <!-- Indication of contact persons such as the person who reported the error, how to reach them. --> ### Screenshots / Logs / Requests: <!-- Insert screenshots or other (visual) aids here if necessary to clarify the bug. --> ### Checklist: - [ ] Add Severity label - [ ] Add team label - [ ] Related/affected issues/stories/epics linked and explained in the bug issue - [ ] Creation of an automated test - [ ] Bugfix deployed on DEV - [ ] Bugfix tested on DEV - [ ] Bugfix deployed on TEST - [ ] Bugfix tested on TEST (possibly also by the connection project itself) - [ ] Successful fix reported to Team Operations (Teams channel) - [ ] Bugfix deployed on STAGE - [ ] Bugfix tested on STAGE if necessary - [ ] Bugfix deployed on PROD - [ ] Bugfix tested on PROD (possibly also by the connection project itself) - [ ] Final communication by Team Operations if necessary - [ ] Internal documentation was checked and updated if necessary - [ ] External documentation has been checked and updated if necessary - [ ] Updated changelog if necessary ### Approach/Solution: - Java-SDK anpassen: in AttachmentPayloadHandler gesetzte Attachment.attachmentId übernehmen, statt immer UUID.randomUUID(). - Fallback nur bei null: neue UUID erzeugen. ### Release version of the artifact: