Benutzerdefiniertes Feld bzgl. der letzten Änderung eines Artikels

Dschingis Lan

Dschingis Lan

Neues Mitglied
Hallo,

da ich noch recht neu im Sage unterwegs bin, hier eine Frage zu einem benutzerdefinierten Feld.
Das ich diese Felder im Administrator anlegen kann, habe ich soweit verstanden.

Aber wie lege ich ein Feld an, dass mir das Datum der letzten Artikeländerung (bestenfalls die letzte Änderung des Einkaufspreises) im Artikel und ggf. auch im Verkaufsbeleg in den Positionen anzeigt?

Danke für Eure Bemühungen!
 
Danke,

ja das kenne ich bereits und finde es, um mehrere Artikel schnell abzugleichen, zu umständlich und zeitaufwendig.
 
aber wenn du ein BDF anlegst, wie soll sich das dann mit dem Datum der letzten Änderung füllen - wollt ihr das manuell machen?

Grüße
 
Nein, dass wollen wir nicht manuell machen. Ich hatte gedacht, es sei möglich sich in irgendeiner Form das Datum der letzten Änderung automatisch in einem Feld anzeigen zu lassen.
 
Von einem manuellen Füllen rate ich unseren Kunden immer ab.

Das wird mal ne zeitlang - wenn überhaupt - gemacht und dann geht es vergessen.
Das Datum was dann drin steht ist nie wirklich sicher.

BDF sind immer nur erstmal "dumme" Felder die man dann verwenden kann.

Für den genannten Fall wäre zB eine DCM notwendig, die beim Speichern das Datum setzt.

Wobei dann die Aussagekraft dennoch fraglich ist, da ja dann nur das Speicherdatum drin steht.
Was+warum gespeichert wurde muss man dennoch in Mutationsprotokoll schauen.
 
Moin,
das wäre im Standard innerhalb von sage so nicht möglich. Man könnte das auch über einen Trigger in der Datenbank machen oder zusätzlich per DCM programmieren.
Würde ich aber nicht machen und sage hat das auch bewusst nicht gemacht.
Genau wie @KMoeser auch schon angemerkt hat, in der Sekunde wo ich so ein Feld hätte, und ein Artikel wurde geändert kommen doch sofort die Fragen, "Was wurde denn geändert?", "Wer von euch war das ???" und "Was stand da vorher drin?????"
Und genau diese Fragen beantwortet eben das Mutationsprotokoll oder die Zusatzlösung von desk.
 
Vielen Dank für die hilfreiche Unterstützung und die zahlreichen nützlichen Hinweise!

Dann hätte ich noch eine Frage bzgl. dem Mutationsprotokoll. Ich es richtig, dass ich hier beim Artikel nur die Änderung des Verkauspreises sehen kann und nicht die des Einkaufspreises?
 
Zuletzt bearbeitet:
Moin,
im Administrator das Optionale Mutationsprotokoll für Artikellieferanten aktivieren. Gilt aber natürlich nicht rückwirkend.

Mutation.png
 
planB schrieb:
Moin,
im Administrator das Optionale Mutationsprotokoll für Artikellieferanten aktivieren. Gilt aber natürlich nicht rückwirkend.
Zum Vergrößern anklicken....
1787125236133.png

Danke, habe nachgeschaut und dies ist bereits so aktiviert. Trotz dessen, erscheint eine Änderung der Lieferantenpreise (Einkaufspreise) nicht im Mutationsprotokoll.
 
Hier noch einmal ein Beispiel zum nachvollziehen:

alter Lieferantenpreis
1787129440264.png

neuer Lieferantenpreis
1787129512098.png

Mutationsprotokoll (Nur Änderungen)
1787129564296.png
Beim Verkaufspreis funktioniert dies tadellos.
 
Bei mir wird auch nichts protokolliert, es steht zwar drin, das ein User etwas am Preis verändert hat, aber nicht mit dem richtigen User und schon gar nicht der alte und neue Wert. Ist das schon an Sage im Support bekannt?

Ich meine jetzt den Standard mit den Lieferanten Preise. Bei mir kommt nichts an.
 
Dur wirst um einen after update trigger nicht herum kommen

ungetestet:
ALTER TABLE khkartikel
ADD user_cng DATETIME2 NULL;
GO

CREATE TRIGGER trg_last_modified
ON khkartikel
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;

UPDATE t
SET user_cng = SYSDATETIME()
FROM khkartikel t
INNER JOIN inserted i ON t.id = i.id;
END;
GO

/* zb. Varianten auch */
CREATE TRIGGER trg_child_update_parent
ON khkartikelvarianten
AFTER UPDATE, INSERT, DELETE
AS
BEGIN
SET NOCOUNT ON;

UPDATE p
SET p.user_cng = SYSDATETIME()
FROM khkartikel p
INNER JOIN (
SELECT DISTINCT artikelnummer, mandant
FROM inserted
UNION
SELECT DISTINCT artikelnummer, mandant
FROM deleted
) x
ON p.artikelnummer = x.artikelnummer
AND p.mandant = x.mandant;
END;
GO
 
Zuletzt bearbeitet:
nOlivier schrieb:
Dur wirst um einen after update trigger nicht herum kommen

ungetestet:
ALTER TABLE khkartikel
ADD user_cng DATETIME2 NULL;
GO

CREATE TRIGGER trg_last_modified
ON khkartikel
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;

UPDATE t
SET user_cng = SYSDATETIME()
FROM khkartikel t
INNER JOIN inserted i ON t.id = i.id;
END;
GO

/* zb. Varianten auch */
CREATE TRIGGER trg_child_update_parent
ON khkartikelvarianten
AFTER UPDATE, INSERT, DELETE
AS
BEGIN
SET NOCOUNT ON;

UPDATE p
SET p.user_cng = SYSDATETIME()
FROM khkartikel p
INNER JOIN (
SELECT DISTINCT artikelnummer, mandant
FROM inserted
UNION
SELECT DISTINCT artikelnummer, mandant
FROM deleted
) x
ON p.artikelnummer = x.artikelnummer
AND p.mandant = x.mandant;
END;
GO
Zum Vergrößern anklicken....
Sieht interessant aus, aber davon habe ich leider bisher nicht wirklich Ahnung. Danke.
 
Wir reden aber schon über die Tabelle Artikellieferanten, oder? die wird bei mir problemlos geloggt.
Mutation.png
 
Mal kurz vom Fachhändler auf die Datenbank schauen lassen.
Wenn das Protokoll AUS ist sieht der Trigger TRU_Artikellieferant so aus:
Code: 
CREATE TRIGGER [dbo].[TRU_ArtikelLieferant]
ON [dbo].[KHKArtikelLieferant] FOR UPDATE
AS
   SET NOCOUNT ON
----***OPTIONAL LOG***BEGIN***
--   DECLARE @auCount integer
--   SELECT @aucount=COUNT(*) FROM inserted
--   DECLARE @auMandant smallint
--   DECLARE @auditID INTEGER
--   DECLARE @auditExpr1 varchar(128)
--   DECLARE @auditExpr2 varchar(128)
--   DECLARE @auditExpr3 varchar(128)
--   DECLARE @auditExpr1Old varchar(128)
--   DECLARE @valOld varchar(max)
--   DECLARE @valNew varchar(max)

Wenn der AN ist sieht er so aus. Die Auskommentierung wurde aufgehoben.

Code: 
--***OPTIONAL LOG***BEGIN***
   DECLARE @auCount integer
   SELECT @aucount=COUNT(*) FROM inserted
   DECLARE @auMandant smallint
   DECLARE @auditID INTEGER
   DECLARE @auditExpr1 varchar(128)
   DECLARE @auditExpr2 varchar(128)
   DECLARE @auditExpr3 varchar(128)
   DECLARE @auditExpr1Old varchar(128)
   DECLARE @valOld varchar(max)
   DECLARE @valNew varchar(max)

Der funktioniert problemlos, da sind keine extra Trigger nötig.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben