Buchungsdatum bei VK-Rechnung

Hallo zusammen,

bin neu hier und habe eine (wahrscheinlich) banale Aufgabenstellung:
Ich will sicherstellen, dass das Buchungsdatum der VK-Rechnung (wird über fakturieren erzeugt) immer das heutige Arbeitsdatum ist.

Hintergrund:
Zwischen Lieferung und Rechnung vergehen häufig mehrere Tage und unsere User vegessen schon mal da das "richtige" Buchungsdatum im VK-Auftrag nachzutragen.

Ich sehe zwei Möglichkeiten:
a) Das Buchungsdatum nach der Lieferung wieder zu leeren
b) eine Abfrage/Dialog ob Buchungsdatum = Arbeitsdatum

Vielen Dank schon mal für die Unterstützung!

Robert6.0

Herzlich willkommen bei uns :)

Da es manchmal Sinn ergibt, dass das Buchungsdatum nicht das Tagesdatum ist, haben wir hier eine Abfrage, ob das Buchungsdatum gleich dem Tagesdatum gesetzt werden soll, was bei einem Klick auf "Ja" dann automatisch gemacht wird.

Vielen Dank für die schnelle Antwort. Ich würde dann das wie folgt im OnAction-Trigger der Page lösen:


<Action75> - OnAction()
// Test
IF Rec."Posting Date" <> WORKDATE THEN BEGIN

IF CONFIRM('Wollen Sie das Buchungsdatum auf das Arbeitsdatum setzen?', TRUE) = TRUE THEN BEGIN
Rec."Posting Date" := WORKDATE;
Rec.MODIFY;

END;

END;
//

Hallo Robert,

also ich persönlich würde möglichst davon absehen, etwas auf Pages und/oder Forms zu programmieren.
Ich an deiner Stelle würde mich in die Codeunit 81 (Sales-Post (Yes/No)) einhängen. Zum Beispiel dort in der Funktion Code()

Code:

Code()
IF (SalesHeader."Posting Date" <> TODAY) THEN BEGIN
  IF (CONFIRM(Text50000, FALSE)) THEN BEGIN
    SalesHeader.VALIDATE("Posting Date", TODAY);
    SalesHeader.MODIFY(TRUE);
  END;
END;
[...]


Wenn du ausschließlich bei Rechnungen (Verkauf) diese Prüfung machen willst, solltest du etwas weiter unten in der Function Code() einsetzen:

Code:

Code()
[...]
WITH SalesHeader DO BEGIN
  CASE "Document Type" OF
    "Document Type"::Order:
      BEGIN
        Selection := STRMENU(Text000,3);
        IF Selection = 0 THEN
          EXIT;
        Ship := Selection IN [1,3];
        Invoice := Selection IN [2,3];
      END;
    "Document Type"::"Return Order":
      BEGIN
        Selection := STRMENU(Text002,3);
        IF Selection = 0 THEN
          EXIT;
        Receive := Selection IN [1,3];
        Invoice := Selection IN [2,3];
      END ELSE
        IF NOT
           CONFIRM(
             Text001,FALSE,
             "Document Type")
        THEN
          EXIT;
  END;

  IF ((Invcoice) AND (SalesHeader."Posting Date" <> TODAY)) THEN BEGIN
    IF (CONFIRM(Text50000, FALSE)) THEN BEGIN
      SalesHeader.VALIDATE("Posting Date", TODAY);
      SalesHeader.MODIFY(TRUE);
    END;
  END;

  SalesPost.RUN(SalesHeader);
  [...]


Gruß,
Christoph

Hallo Robert,

also ich persönlich würde möglichst davon absehen, etwas auf Pages und/oder Forms zu programmieren.
Ich an deiner Stelle würde mich in die Codeunit 81 (Sales-Post (Yes/No)) einhängen. Zum Beispiel dort in der Funktion Code()

Code:

Code()
IF (SalesHeader."Posting Date" <> TODAY) THEN BEGIN
  IF (CONFIRM(Text50000, FALSE)) THEN BEGIN
    SalesHeader.VALIDATE("Posting Date", TODAY);
    SalesHeader.MODIFY(TRUE);
  END;
END;
[...]


Viel Spass beim Stapelbuchen wenn Buchungsdatum != Today

Hallo Robert,

also ich persönlich würde möglichst davon absehen, etwas auf Pages und/oder Forms zu programmieren.
Ich an deiner Stelle würde mich in die Codeunit 81 (Sales-Post (Yes/No)) einhängen. Zum Beispiel dort in der Funktion Code()

Code:

Code()
IF (SalesHeader."Posting Date" <> TODAY) THEN BEGIN
  IF (CONFIRM(Text50000, FALSE)) THEN BEGIN
    SalesHeader.VALIDATE("Posting Date", TODAY);
    SalesHeader.MODIFY(TRUE);
  END;
END;
[...]


Viel Spass beim Stapelbuchen wenn Buchungsdatum != Today

Auch wieder wahr... aber auch unter dem Aspekt würde ich weiter von der Programmierung auf Pages absehen. Du etwa nicht?
Für Stapelbuchungen oder ähnliche Prozesse bei denen man MESSAGE, CONFIRM, o.ä. unterdrücken möchte kann man ja auch recht einfach kleine Schalter ähnlich SetHideValidationDialog() einbauen. Schönes Beispiel für die Verwendung ist zum Beispiel die Tabelle 36 (Sales Header).

Nachtrag
Mir fällt gerade auf, dass das Beispiel mächtig hinkt. Ich habe vorgeschlagen in die Codeunit 81 "Sales-Post (Yes/No)" einzusteigen. Wenn man Stapelbuchungen über diese Codeunit macht wird man seines Lebens eh nicht mehr froh. Dort drin werden nämlich per Standard eh die Fragen nach "Liefern & fakturieren" gestellt.

Code:


Code()
WITH SalesHeader DO BEGIN
  CASE "Document Type" OF
    "Document Type"::Order:
      BEGIN
        Selection := STRMENU(Text000,3);
        IF Selection = 0 THEN
          EXIT;
        Ship := Selection IN [1,3];
        Invoice := Selection IN [2,3];
      END;
[...]


Aber netter Versuch... hast mich auch kurz zum zweifeln gebracht

Gruß,
Christoph

Hallo Robert,

also ich persönlich würde möglichst davon absehen, etwas auf Pages und/oder Forms zu programmieren.
Ich an deiner Stelle würde mich in die Codeunit 81 (Sales-Post (Yes/No)) einhängen. Zum Beispiel dort in der Funktion Code()

Code:

Code()
IF (SalesHeader."Posting Date" <> TODAY) THEN BEGIN
  IF (CONFIRM(Text50000, FALSE)) THEN BEGIN
    SalesHeader.VALIDATE("Posting Date", TODAY);
    SalesHeader.MODIFY(TRUE);
  END;
END;
[...]


Wenn du ausschließlich bei Rechnungen (Verkauf) diese Prüfung machen willst, solltest du etwas weiter unten in der Function Code() einsetzen:

Code:

Code()
[...]
WITH SalesHeader DO BEGIN
  CASE "Document Type" OF
    "Document Type"::Order:
      BEGIN
        Selection := STRMENU(Text000,3);
        IF Selection = 0 THEN
          EXIT;
        Ship := Selection IN [1,3];
        Invoice := Selection IN [2,3];
      END;
    "Document Type"::"Return Order":
      BEGIN
        Selection := STRMENU(Text002,3);
        IF Selection = 0 THEN
          EXIT;
        Receive := Selection IN [1,3];
        Invoice := Selection IN [2,3];
      END ELSE
        IF NOT
           CONFIRM(
             Text001,FALSE,
             "Document Type")
        THEN
          EXIT;
  END;

  IF ((Invcoice) AND (SalesHeader."Posting Date" <> TODAY)) THEN BEGIN
    IF (CONFIRM(Text50000, FALSE)) THEN BEGIN
      SalesHeader.VALIDATE("Posting Date", TODAY);
      SalesHeader.MODIFY(TRUE);
    END;
  END;

  SalesPost.RUN(SalesHeader);
  [...]


Gruß,
Christoph

Als Anfänger gestattet mir dir Frage:
Warum darf/kann ich eine Abfrage wie weiter oben dargestellt nicht in der Form/Page machen?

Gruss Robert6.0

Hallo Robert,

also ich persönlich würde möglichst davon absehen, etwas auf Pages und/oder Forms zu programmieren.
Ich an deiner Stelle würde mich in die Codeunit 81 (Sales-Post (Yes/No)) einhängen.

Als Anfänger gestattet mir dir Frage:
Warum darf/kann ich eine Abfrage wie weiter oben dargestellt nicht in der Form/Page machen?

Die Frage ist natürlich berechtigt, jedoch auch ganz leicht zu beantworten:
Schreibst du den Programmcode in der Form/Page, so wird er nur ausgeführt, wenn die Funktion aus genau dieser einen Form/Page aufgerufen wird.
Schreibst du es jedoch in die Codeunit 81, so wird er immer ausgeführt, wenn eine Funktion auf irgendeiner Form/Page die Codeunit 81 aufruft.
Beispiel: Im NAV 5.0 Standard gibt es schon vier (4) Stellen, an denen die Codeunit 81 aufgerufen wird: Forms 42, 43, 44 und 6630.
Darüber hinaus kann es noch weitere branchenspezifische und/oder individuelle Stellen geben.