https://cust-projects.seeburger.de/redmine/issues/25214

In POCollabStatus.generateExport(boolean bCustomerIsActing, boolean forceExport) wird folgendes geprüft:

if (!forceExport)
{
  if ( bCustomerIsActing && isCollabActorImport())
  {
    log.info("Skipping processing of export-on-collab on PO '"
                         + getPOTitle(true)
                         + "' hence collab-actor is IMPORT and therefore submission of values is ambigous.");
                return;
  }
}

Die Methode isCollabActorImport() prüft, ob der aktuelle collabActor ein IPOConstants.COLLAB_ACTOR_IMPORT ist. Im Fall von CSV-Upload ist es einer. Deshalb wird gleich return gemacht, d.h. der Export wird geskippt.

Um eine Order mit “AutoAccept”-Feature zu erzeugen, muss man in der XML-Nachricht die Felder AutoAcceptQTYLowerLimit und AutoAcceptQTYUpperLimit befüllen. Damit das Feature “losgeht” muss man die Menge (im Fall von Suppier die “Promised Quantity”) zwischen diesen 2 Werten haben. Dann wird der “AutoAccept”-Code ausgeführt.

In der modify()-Methode aller POCollabStatus* Klassen, wo if(POCollabStatusToolbox.checkForAutoAccept()) gemacht wird, dafür sorgen, dass der CollabActor auf IPOConstants.COLLAB_ACTOR_USER gesetzt wird.

Wichtig: Prüfen, ob das irgendwelche Querwirkungen verursachen könnte. D.h. ob der CollabActor nach dem Setzen (außer der o.g. Stelle im isCollabActorImport()) noch irgendwo verwendet wird.

• POManagerEJB.doAutoAcceptForSplit()
• POCollabStatusCCOR.modify()
• POCollabStatusNOP.modify()
• POCollabStatusOPEN.modify()
• POCollabStatusSAWC.modify()
• POCollabStatusSCOR.modify()