[gelöst] Beschreibungen in den Sachposten? - Teil 2

[dr]

hallo, ausgehend vom thread Beschreibungen in den Sachposten? habe ich noch ein paar anmerkungen und eine frage...

ich stehe vor dem gleichen problem, zusammengefasst ist dies folgendes:
ein kunde erfasst einkaufsrechnungen, wobei n zeilen auf das gleiche sachkonto verweisen und er eine jeweils eigene beschreibung eingibt. die n zeilen werden zu einem sachposten vereint und erhalten als beschreibung in etwa rechnung xyz. ergebnis soll aber sein, dass auch n sachposten entstehen und die in der rechnung eingetragene beschreibung mit übertragen wird.

durch nachforschung bin ich nun zu folgendem gekommen:
a) es ist möglich, die beschreibung aus den zeilen mit durchzuschleifen, eine beschreibung wie diese anpassung auszusehen hat findet man bei hier - problem hierbei ist jedoch, dass mehrere zeilen auf ein sachkonto zu einem sachposten werden und dieser die beschreibung der ersten aufgetretenen zeile erhält

b) über einen trick könnte man jetzt schon erreichen was erwünscht ist, nämlich über den weg eines pseudodimensionscodes. sprich ich lege eine dimension an (z.b. laufende nummer mit werten 1,2,..) und vergebe bei den entsprechenden zeilen diese pseudodimension mit einem anderen wert. navision wird dann von alleine getrennte sachposten anlegen und die beschreibung würde durch a) korrekt sein.


mit einem kollegen habe ich dann noch weiter geforscht, weil wir der meinung waren, dass wenn es durch die dimensionen zu getrennten sachposten kommt, manss man dies doch auch ohne diese anders hinbekommen muss und sind dabei in der codeunit 90 auf den InvoicePostingBuffer (table 49) gestoßen. weiterhin wurde durch a) in eben dieser table 49 ein weiteres feld "line no" hinzugefügt und durch die entsprechende zeile aus der purchase line gefüllt. weiterhin hat die besagte table 49 nur einen einzigen key und in der codeunit 90 wird über genau diesen entschieden, ob eine zeile aus einer einkaufsrechnung ein eigener sachposten wird oder mit einem bereits bestehenden vereint wird. also haben wir bei der table 49 die "line no" am ende mit in den schlüssel aufgenommen und siehe da... mit anpassung a) aber ohne verwendung von dimensionen erhält man aus n zeilen auf sachkonto xxx auch n sachposten mit der jeweils eigenen beschreibung.


aber:
es ist nicht leicht zu überblicken, ob diese änderung irgendwelche negativen auswirkungen haben kann, daher wollte ich den thread mal in den raum werfen. vielleicht fällt einem noch etwas ein, an was wir nicht gedacht haben oder eine stelle/sache, die man nochmal explizit prüfen sollte. ansonsten ist die lösung evtl. auch für andere interessant. allerdings ist sie noch völlig ohne gewähr...

Zuletzt geändert von dr am 15. Juli 2014 11:14, insgesamt 1-mal geändert.

So, nach all den Jahren bin ich jetzt auch an diesem Thema dran
Werden Sachkontenzeilen in EK- und VK-Belegen gebucht, sollen die Beschreibungen der Belegzeilen in die Sachposten (nur die der Beleg-Sachkonten) übernommen werden - aber nur in dieser speziellen Konstellation!
Taucht aber das gleiche Sachkonto in mehreren Belegzeilen auf, werden durch den Standard diese Belegzeilen zu einem Sachposten zusammengefasst, womit eine eindeutige Zuordnung entfällt.

durch nachforschung bin ich nun zu folgendem gekommen:
a) es ist möglich, die beschreibung aus den zeilen mit durchzuschleifen, eine beschreibung wie diese anpassung auszusehen hat findet man bei hier - problem hierbei ist jedoch, dass mehrere zeilen auf ein sachkonto zu einem sachposten werden und dieser die beschreibung der ersten aufgetretenen zeile erhält

Frage an unsere(n) Fibu-Experten:
Wie kann man diese Splittung ohne Pseudodimensionen am besten realisieren?

1. T49 um ein Primärschlüsselfeld erweitern (siehe Beitrag über mir)?
2. Im Code eines der bestehenden T49-Schlüsselfelder mit einer Konstante (z.B. DUMMY-Zeilennr.) belegen? (Wir arbeiten z.B. nicht mit Job No.)
3. Oder (nur!) im Falle von Sachkontenzeilen T49 nicht füllen und dafür in CU80/90 das Buch.-Blatt direkt füllen und buchen?

Hallo,

die direkteste Lösung ist eigentlich, das Feld "Beschreibung" in T49 hinzuzufügen und mit in den Primärschlüssel aufzunehmen, wenn dieser noch Platz hat. Zusätzlich muss man das Feld in CU80/90/598x dem Puffer zuweisen und aus dem Puffer in die Buchblattzeile übernehmen. Nebenwirkungen gibt es keine - die Sachposten werden zusätzlich nach Buchungstext zusammengefasst. Wenn man das statt über Beschreibung mit Zeilennr. löst gehts auch, deaktiviert aber praktisch den kompletten Effekt des Rechnungsbuchungspuffers.
Wir (Plexada AG) haben übrigens auch ein (kleines) AddOn, wo diese Lösung allgemeingültig umgesetzt ist, im Sinne von "beliebig viele Felder hinzufügen".

LG Jens

Nebenwirkungen gibt es keine

Danke, das wollte ich hören

wow, nach 5 jahren nochmal aktuell geworden. leider weiß ich selber nicht mehr wie es damals ausging, aber danke für die info. wenn ich es wieder brauche erinnere ich mich hoffentlich an den thread
ich setze den titel damit auch mal auf gelöst.

Um dem Ganzen noch einen sauberen Abschluss zu geben, hier noch einmal unsere Umsetzung.
Gelöst haben wir das ganz ähnlich wie hier, nur dass unsere Anforderung lautete: Nur für Sachkontenzeilen im Einkauf und Verkauf anzuwenden. Einen Teil des Codes habe ich aus der Codeunit aus- und in die Tabelle eingelagert; aber das ist nur Geschmackssache.
Ziel war es, den Standard so wenig es geht zu ändern; das heißt, dass die Splittung auf Belegzeilenebene wirklich nur für Sachkontenzeilen vorgenommen wird.

So sieht es also aus:

Tabelle 49 Invoice Post. Buffer

• Neue Felder
  
  • 50000 Posting Description (Text 50)
  • 50001 Line No. (Integer)
  Primärschlüssel ergänzt um "Line No.".
  
  
• Funktion PrepareSales
  Ganz am Ende folgende Zeilen hinzugefügt:
  

  Code:

  ...
// >> NEU
IF SalesLine.Type = SalesLine.Type::"G/L Account" THEN BEGIN
  "Posting Description" := SalesLine.Description;
  "Line No." := SalesLine."Line No.";
END; 
// << NEU   

  
  
• Funktion PreparePruchase
  Ganz am Ende folgende Zeilen hinzugefügt:
  

  Code:

  ...
// >> NEU
IF PurchLine.Type = PurchLine.Type::"G/L Account" THEN BEGIN
  "Posting Description" := PurchLine.Description;
  "Line No." := PurchLine."Line No.";
END;
// << NEU  

Codeunit 80 Sales-Post

• Trigger OnRun
  

  Code:

          ...
        GenJnlLine.INIT;
        GenJnlLine."Posting Date" := "Posting Date";
        GenJnlLine."Document Date" := "Document Date";
        // >> NEU
        IF InvPostingBuffer[1]."Posting Description" <> '' THEN BEGIN
          GenJnlLine.Description := InvPostingBuffer[1]."Posting Description";
        END ELSE
        // << NEU
        GenJnlLine.Description := "Posting Description";
        GenJnlLine."Reason Code" := "Reason Code";
        GenJnlLine."Document Type" := GenJnlLineDocType;
        ...

  
  
• Funktion InsertICGenJnlLine
  Wer die Änderung auch bei Intercompany-Prozessen wünscht:
  

  Code:

  ...
TempICGenJnlLine.INIT;
TempICGenJnlLine."Line No." := ICGenJnlLineNo;
TempICGenJnlLine.VALIDATE("Posting Date",SalesHeader."Posting Date");
TempICGenJnlLine."Document Date" := SalesHeader."Document Date";
// >> NEU
IF (SalesLine.Type = SalesLine.Type::"G/L Account") AND (SalesLine.Description <> '') THEN BEGIN
  TempICGenJnlLine.Description := SalesLine.Description;
END ELSE
// << NEU
  TempICGenJnlLine.Description := SalesHeader."Posting Description";
TempICGenJnlLine."Reason Code" := SalesHeader."Reason Code";
...

Codeunit 90 Purch.-Post

• Trigger OnRun
  

  Code:

          ...
        GenJnlLine.INIT;
        GenJnlLine."Posting Date" := "Posting Date";
        GenJnlLine."Document Date" := "Document Date";
        // >> NEU
        IF InvPostingBuffer[1]."Posting Description" <> '' THEN BEGIN
          GenJnlLine.Description := InvPostingBuffer[1]."Posting Description";
        END ELSE
        // << NEU
          GenJnlLine.Description := "Posting Description";
        GenJnlLine."Reason Code" := "Reason Code";
        GenJnlLine."Document Type" := GenJnlLineDocType;
        ...

  
  
• Funktion InsertICGenJnlLine
  Wer die Änderung auch bei Intercompany-Prozessen wünscht:
  

  Code:

  ...
TempICGenJnlLine.INIT;
TempICGenJnlLine."Line No." := ICGenJnlLineNo;
TempICGenJnlLine.VALIDATE("Posting Date",PurchHeader."Posting Date");
TempICGenJnlLine."Document Date" := PurchHeader."Document Date";
// >> NEU
IF (PurchLine.Type = PurchLine.Type::"G/L Account") AND (PurchLine.Description <> '') THEN BEGIN
  TempICGenJnlLine.Description := PurchLine.Description;
END ELSE
// << NEU
  TempICGenJnlLine.Description := PurchHeader."Posting Description";
TempICGenJnlLine."Reason Code" := PurchHeader."Reason Code";
...

Diese Änderungen lassen sich analog für den Service-Bereich durchführen.