Anzeigentransfer

Anstrich-Export

Allgemein

Vgl. auch /wiki/spaces/CON/pages/221087000

Der "Anzeigenlieferant" soll eine Rückmeldung über die Produktion seiner Anzeigen bekommen. Dazu werden beim Speichern nach verschiedenen Aktionen (platzieren, belichten, deplatzieren) Anstrichdaten in eine entsprechende DB-Tabelle (blattp.Anstrichtransfer) geschrieben bzw. dort aktualisiert (Pollstatus wieder auf 0). Die Daten können durch den Anstrich-Poller auf verschiedene Art und Weise an das Anzeigensystem übergeben werden (DB, XML). Bei erfolgreicher Übergabe wechselt der Pollstatus auf 2. Da nicht bei jeder Aktion die benötigten Daten korrekt zur Verfügung stehen um in die DB geschrieben zu werden, greift der Poller statt auf die Anstrich-Tabelle auf eine entsprechende View (blattp.VANSTRICHTRANSFER) zu - in der View wird über die Platzierung der Anzeige bis auf die Schemagruppe ge"Joint" (vgl.
DNT OP #6576828: Anstrichdaten unvollständig). Die View ist sehr ressourcenintensiv und beschäftigt den Datenbankserver stark - obwohl im Ergebnis meist festgestellt wird, dass nichts zu tun ist.

...

Ein weiterer Fehler führt dazu, dass deplatzierte Anzeigen mit falschem Status in der Anstrich-Tabelle stehen (3 - wenn sie ohne Termin für die konkrete Ausgabe trotzdem dort platziert und belichtet und erst danach wieder deplatziert wurden).

Mit CONS-53 werden nun auch Füller vom BPAnstrichExport erfasst. Als Testbemerkung (s. CONS-69) wird folgendes festgehalten: Wenn der Füller auf einer DMS platziert ist (z. B. 7 Ausgaben), wird beim Belichten der DMS nur ein Anstrichtransfer-Datensatz geschrieben und entsprechend die Verwendung in FUELLERATTRIB.REALERSCHEINANZ um einen Zähler hochgesetzt. Für eine in gleicher Weise platzierte Anzeige wird für jede beteiligte Ausgabe ein Transfer-Datensatz geschrieben, hier also 7 Stück. Prinzipiell ist das nicht korrekt, es müssten auch für DMS-platzierte Füller mehrere Anstrichtransfer-Datensätze geschrieben werden (entsprechend einer Zählung pro beteiligter Seite). Da die Füllverwendung aber bislang gar nicht geschrieben wurde und auch von keinem Verlag ausgewertet wird, soll die Funktionsweise erst einmal so belassen werden.

Die Intention zur Behandlung der Füller im VL-System scheint nicht ganz klar - der Poller prüft die Datensätze gegen den aktuellen Zähler und die zugeordneten Ausgaben, um zu entscheiden, ob er etwas schreibt oder nicht. Ggf. zählt er den Zähler hoch und schreibt PTermin- und KTermin-Datensätze (die in der Auftragsbearbeitung nicht sichtbar sind und offenbar nur bei EPLAT für den Export vorgesehen waren - vgl. OP unten). Eigentlich sollte es m.E. (Rene Bretschneider) so funktionieren: Die Blattplanung schreibt bei der Belichtung Füller-Datensätze zu den tatsächlichen Platzierungen (egal ob die Ausgaben "gültig" waren oder nicht und auch mit Beachtung von Durchläufern), der Poller schreibt bedingungslos  die Termin-Datensätze und Inkrementiert den Zähler. In der Blattplanung werden dann nur Füller angeboten, deren Zähler das Maximum noch nicht erreicht hat oder deren Maximum durch "-1" nicht zu beachten ist.
Korrespondierende OPs zu diesem Thema:
EPL OP #6302817: placemente data for filler - Anstrichtransfer für Füller (BP -> ANZ)
PLT OP #6705116: DEV: Füller - Max Erscheinungen auf 999 begrenzt

Kommandozeilen-Parameter beim Anstrich-Poller BPAnstrichExport.exe

Status in der Anstrich-Tabelle

Ein Verschieben der Anzeige auf einer bereits belichteten Seite führt nicht zu Status-Bit 4, nur das Verschieben auf eine andere Seite. Ebenso wird es gesetzt, wenn die Anzeige deplatziert oder erneut platziert wird und in der Anstrich-Tabelle bereits mit Status-Bit 2 enthalten ist. Belichten beseitigt das Status-Bit 4 wieder.

Testatfeld der Anzeigen

In der aktuellen DB platzierte Anzeigen mit bestimmten Testaten werden für die View explizit ausgefiltert: 2 (vor Korrektur, advantage Platzhalter), 4, 64 (Motiv gelöscht). Für unplatzierte Anzeigen wirkt dieser Filter nicht.