rm#24264

• + Problem nachvollziehen
  • + Nachricht vom BIS:MT herunterladen (Zugangsdaten: DEV System bei TDS)
  • + Auf der DEV-Datenbank die Relation herausfinden und gucken, ob der Supplier registriert ist. → scheint registriert zu sein (SELECT * FROM TAIRPARTNERRELATION where CCUSTOMERCPID=101883 and CSUPPLIERCPID=10006399 and CNETWORKLINKID=20083503 and CCUSTOMERPLANTCODE = 'TOF' and CSUPPLIERNO='220915' and CSUPPLIERNOLOCAL = '55820494')
  • + Versuchen eine OSP und eine nicht-OSP (anhand vom Flag) Order zu importieren und schauen, ob eine Mail geschickt wird
  • → Ursache: in POOSPNotifier.sendMessageForChange() steigt er bei der Prüfung changeVerifier.getOSPTracking().size() == 0 aus. D.h. die OSPTracking-Einträge werden bei der Änderung über UI nicht angelegt.

• - Schauen wo und wie OSPTracking-Einträge erzeugt werden sollen.
• Bei dem Import ist die wichtige Stelle in der Methode POImportProcessorBase.processMessage()
• Bei Reingehen in die POCollabEngineEJB.modify() wird schon ein befülltes changeVerifier übergeben.
• POCollabEngineEJB.processCollabFromGUILine()
• Um wirklich sicher zu sein, dass die ganzen Daten im collabModel landen, müsste man die Methode POImportProcessorBase.processDataIfLineInitiallyOnDB() verallgemeinern, so dass sie nicht von dem Zustand des ImportProcessors abhängt und dann ausführen.

In POCollabEngineEJB.modify() wurde IF so angepasst, dass beim CSV-Import auch Mails verschickt werden: getPOOSPNotifier(poData).sendMessageForChange(collab.getChangeVerifier());.

Leider enthält die E-Mail, die nach dem CSV-Upload generiert wird, zu viele Änderungen.

• Die Order ist nicht vom Typ “OSP”, das sollte aber keine Rolle spielen, da es normalerweise nur auf Relation geguckt wird.
• Testdaten unter: D:\development\testdata\purchaseorder\rm#24264_POEMA\
• Buyer User: TST_BY_AFR_ADMRW
• Code: POCollabEngine.modify() → POCollabEngine:1036

• 132 → PO_UpdateVersion
• 165 → PO_CollabReqDate
• 167 → PO_CollabReqQty
• 182 → PO_UpdateVersion