Hi,
vielleicht hilft dieser Hinweis für die Konten?
Hinweis 634887
Gruss,
JW
vielleicht hilft dieser Hinweis für die Konten?
Hinweis 634887
Gruss,
JW
↧
Re: Ãbersetzungen von CO Stammdaten
↧
Re: Abgabe Steuererklärungen Spanien ab 7/2017: System SII
Eisele:
Hallo Exberliner,
ich habe dir meine Email-Adresse gesendet :-)
Hallo Exberliner,
ich habe dir meine Email-Adresse gesendet :-)
↧
↧
Umsatzsteuer bei Lieferung aus Werk im Ausland
Liebe Kolleginnen und Kollegen,
folgendes ist die Ausgangssituation:
deutsche Gesellschaft A hat ein Lager in UK und liefert von dort aus an die britische Schwestergesellschaft.
A ist in UK umsatzsteuerlich registriert.
Welche Einstellungen sind nötig, um Fakturen über SD mit britischer Umsatzsteuer zu erstellen ?
In der VK13 sind nur Steuerschlüssel möglich, die in TAXDE enthalten sind. Nötig wäre aber ein Steuerkennzeichen aus TAXGB.
Da das eine durchaus übliche Konstellation ist, bin ich hoffnungsfroh, einen Lösungsansatz zu erfahren.
Vielen lieben Dank
Michael Schwabe
folgendes ist die Ausgangssituation:
deutsche Gesellschaft A hat ein Lager in UK und liefert von dort aus an die britische Schwestergesellschaft.
A ist in UK umsatzsteuerlich registriert.
Welche Einstellungen sind nötig, um Fakturen über SD mit britischer Umsatzsteuer zu erstellen ?
In der VK13 sind nur Steuerschlüssel möglich, die in TAXDE enthalten sind. Nötig wäre aber ein Steuerkennzeichen aus TAXGB.
Da das eine durchaus übliche Konstellation ist, bin ich hoffnungsfroh, einen Lösungsansatz zu erfahren.
Vielen lieben Dank
Michael Schwabe
↧
Re: Ãbersetzungen von CO Stammdaten
Hallo,
diese Möglichkeit der manuellen Übersetzung mittels SE63 kenne ich, leider löst diese nicht ansatzweise mein Problem.
Ich suche nach einer Möglichkeit (am besten im Standard) in einer Transaktionsmaske alle Sprachen zusammen zu pflegen.
Z.B. Kostenart anlegen und neben der Anmeldesprache gleich die Übersetzungen in EN, FR, PL, IN mit zu pflegen, oder diese im Nachgang per Massenpflege nachzupflegen.
diese Möglichkeit der manuellen Übersetzung mittels SE63 kenne ich, leider löst diese nicht ansatzweise mein Problem.
Ich suche nach einer Möglichkeit (am besten im Standard) in einer Transaktionsmaske alle Sprachen zusammen zu pflegen.
Z.B. Kostenart anlegen und neben der Anmeldesprache gleich die Übersetzungen in EN, FR, PL, IN mit zu pflegen, oder diese im Nachgang per Massenpflege nachzupflegen.
↧
Re: Ãbersetzungen von CO Stammdaten
Hi,
aber in dem Hinweis geht es doch gar nicht um die Transaktion SE63, sondern mit Hilfe eines Programmes werden alle fehlenden Sprachen für die Kostenarten ergänzt.
Vg,
JW
aber in dem Hinweis geht es doch gar nicht um die Transaktion SE63, sondern mit Hilfe eines Programmes werden alle fehlenden Sprachen für die Kostenarten ergänzt.
Vg,
JW
↧
↧
Mahndruck
Hallo zusammen,
ich habe ein Problem mit dem Mahndruck. Wenn ich Mahnungen gedruckt habe, erstellte das System für jede Mahnung einen Spoolauftrag. Das habe ich dadurch gelöst, dass ich bei dem Userstammsatz "Sofort druck" ausgeschaltet habe. Jetzt wird zwar nur einen Spoolauftrag erzeugt, das Problem ist aber, wenn wir Duplex Druck mach haben wir Probleme bei den Mahnungen mit Ungerade Seitenzahl. Die nächste Mahnung wird auf die Rückseite der vorhergehenden Mahnung ausgedruckt. Wie kann ich es steuern, dass dieser Effekt nicht auftritt?
Danke für eine Antwort im Voraus
Johannes
ich habe ein Problem mit dem Mahndruck. Wenn ich Mahnungen gedruckt habe, erstellte das System für jede Mahnung einen Spoolauftrag. Das habe ich dadurch gelöst, dass ich bei dem Userstammsatz "Sofort druck" ausgeschaltet habe. Jetzt wird zwar nur einen Spoolauftrag erzeugt, das Problem ist aber, wenn wir Duplex Druck mach haben wir Probleme bei den Mahnungen mit Ungerade Seitenzahl. Die nächste Mahnung wird auf die Rückseite der vorhergehenden Mahnung ausgedruckt. Wie kann ich es steuern, dass dieser Effekt nicht auftritt?
Danke für eine Antwort im Voraus
Johannes
↧
Mahndruck
Hallo zusammen,
ich habe ein Problem mit dem Mahndruck. Wenn ich Mahnungen gedruckt habe, erstellte das System für jede Mahnung einen Spoolauftrag. Das habe ich dadurch gelöst, dass ich bei dem Userstammsatz "Sofort druck" ausgeschaltet habe. Jetzt wird zwar nur einen Spoolauftrag erzeugt, das Problem ist aber, wenn wir Duplex Druck mach haben wir Probleme bei den Mahnungen mit Ungerade Seitenzahl. Die nächste Mahnung wird auf die Rückseite der vorhergehenden Mahnung ausgedruckt. Wie kann ich es steuern, dass dieser Effekt nicht auftritt?
Danke für eine Antwort im Voraus
Johannes
ich habe ein Problem mit dem Mahndruck. Wenn ich Mahnungen gedruckt habe, erstellte das System für jede Mahnung einen Spoolauftrag. Das habe ich dadurch gelöst, dass ich bei dem Userstammsatz "Sofort druck" ausgeschaltet habe. Jetzt wird zwar nur einen Spoolauftrag erzeugt, das Problem ist aber, wenn wir Duplex Druck mach haben wir Probleme bei den Mahnungen mit Ungerade Seitenzahl. Die nächste Mahnung wird auf die Rückseite der vorhergehenden Mahnung ausgedruckt. Wie kann ich es steuern, dass dieser Effekt nicht auftritt?
Danke für eine Antwort im Voraus
Johannes
↧
Re: Planeinzelposten für statistische Innenaufträge
Hi,
sitzt den der Status PLEP bei deinem Auftrag?
Vg,
JW
sitzt den der Status PLEP bei deinem Auftrag?
Vg,
JW
↧
Re: Anlage Debitor aus Geschäftspartner mit einer kreditorischen Rolle -Berechtigung-
Problem gelöst. Durch die Geschäftspartnerintegration zu den Kreditoren müssen die Berechtigungsobjekte im FI auf 02 gesetzt werden. Für den BP kann es auf Anzeige bleiben. Dann klappt das.
Kessi
Kessi
↧
↧
Re: SAP Umstieg von Rulebook 3.2 auf Rulebook 6.0/7.0
Hallo,
ich antworte mal auf die originale Frage --> Umstieg von Rulebook 3.2 auf Rulebook 7.
Mein Datenträger ist soeben von der Raiba AT als korrekt abgenommen worden ;-)
Folgende Vorgehensweise musste ich durchleiden :-)
(ggf. hätte es auch einfach gereicht NUR: urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 in der FBPM bei den Formatparametern anzugeben![]()
???)
Formatbaum SEPA_CT aus SAP Hinweis 2220926 als Z* Baum in der DMEE hochgeladen
- "2220926 - SEPA-Überweisung Lastschrift DTA XML-Definition für Zahlungsformate SEPA_CT SEPA_DD"
- die Anlage SEPA_CT.zip ist vom 27.09.2016 (und ist Version 2.7 - 2.9 --> Rulebook Version weiß ich immer noch nicht zu erkennen :-( )
Hinweise 1939284 & 1958567 via snote hochgeladen
1939284 - SEPA_CT, SEPA_DD additional tags in DMEE tree required
1958567 - DMEE-Formate SEPA _CT und SEPA_DD - länderspezifische Erweiterung
Durch die Hinweise wird ein Erweiterungsspot (SE18 ES_FI_DMEE_SEPA_COUNTRIES) ins System geladen. Folgende BAdI Definitionen sind darin enthalten:
FI_DMEE_SEPA_COUNTRIES
FI_DMEE_SEPA_EXIT
Im BAdI FI_DMEE_SEPA_COUNTRIES gibt es 2 Erweiterungsimplementierungen.
FI_DMEE_SEPA_COUNTRIES_IMP für Credit (SEPA_CT)
FI_DMEE_SEPA_COUNTRIES_IMP_DEB für Debit (SEPA_DD)
Die SAP liefert das für die Länder BE, LU, AT, PT & SK aus.
In der Methode IF_FI_DMEE_SEPA_COUNTRIES~GET_VALUE werden dort die Länderspezifischen Knoten nachträglich zum DMEE Formatbaum aktiviert.
Man muss sich das so vorstellen das der Standard SEPA_CT Baum über den Hinweis 2220926 in DMEE hochgeladen/definiert wird. Über den BAdI werden weitere Tags im SEPA_CT.xml für die oben genannten Länder im Format zur Laufzeit angereichert.
Für Österreich (AT) war da allerdings ein sehr merkwürdiges Coding drin: (<Ustrd> ist der Tag für den Verwendungszweck)
WHEN: '<PmtInf><CdtTrfTxInf><RmtInf><Ustrd>'.
IF i_fpayh-ziban IS INITIAL.
IF i_extension-node-node_type = 'TECH'.
c_value = 'X'.
ENDIF.
ENDIF.
Auf deutsch. Wenn die IBAN des Lieferanten nicht gepflegt ist wird der Verwendungszweck im Formatbaum aktiviert ??? Diese Abfrage finde ich allerdings sehr unlogisch und habe daher im 2.ten BAdI FI_DMEE_SEPA_EXIT des Erweiterungsspots ES_FI_DMEE_SEPA_COUNTRIES meine eigene Implementierung angelegt. Darin habe ich die Abfrage des Verwendungszweck der SAP übersteuert:
WHEN: '<PmtInf><CdtTrfTxInf><RmtInf><Ustrd>'.
IF i_fpayh-ziban IS not INITIAL.
IF i_extension-node-node_type = 'TECH'.
c_value = 'X'.
ENDIF.
ENDIF.
Damit wird dann der Tag für den Verwendungszweck im im SEPA_CT.xml aktiviert.
Weiterhin hatte ich Probleme mit einem seelenlosen Tag: <Purp/> welches irgendwie unter dem Tag <CdtrAcct> hing. Den akzeptierte die Bank so nicht. Den musste ich dann leider manuell im DMEE Format Knoten "Purp" über eine nie erfüllte Bedingung: FPAYH LAUFI 2 = SPACE 1 lahmlegen.
In der FBPM (SAPFPAYM) Variante zum Datenträger (obpm4) habe ich NUR den Namensraum: urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 angegeben. Namensraum Schema & Ort des Schemas habe ich leer gelassen.
Bei der DTA Erzeugung hatte ich dann noch zusätzlich das Problem das der Zeichensatz mit UTF-16 angeben wurde intern aber UTF-8 verwendet (Trotz Eintrag 4110 im Format). Dafür musste ich dann noch den BAdI DMEE_XML_BADI_01 für mein Format aktivieren. Filterwert ist dann der Z*Formatname aus der DMEE. Damit wird dann das SEPA_CT.xml in UTF-8 erzeugt.
Ganz schön knackig den Weg den die SAP da vorgibt. Geht das auch einfacher ? Hat es jemand anders gemacht ?
Kann mir ggf. einer die Frage beantworten wie das offizielle Vorgehen ist die Länder Filterwerte des BAdI's FI_DMEE_SEPA_COUNTRIES_IMP zu ändern ?
Da sind ja die Länder BE, LU, AT, PT & SK als Filter drin. Ich möchte "SK" da nicht drin haben. Ich kann jetzt einfach über SSCR Ojektregistrierung den Filter "SK" löschen. Aber das ist ja dann eine Modifikation oder ? Ich habe versucht meine eigene Implementierung für FI_DMEE_SEPA_COUNTRIES_IMP anzulegen. Dabei kommt dann aber die Fehlermeldung:
BAdI ist SAP intern, Implementieren im Kundennamensraum verboten. Meldungsnr. SEEF_BADI176
mfG
Charakter_Kopf
ich antworte mal auf die originale Frage --> Umstieg von Rulebook 3.2 auf Rulebook 7.
Mein Datenträger ist soeben von der Raiba AT als korrekt abgenommen worden ;-)
Folgende Vorgehensweise musste ich durchleiden :-)
(ggf. hätte es auch einfach gereicht NUR: urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 in der FBPM bei den Formatparametern anzugeben
???)Formatbaum SEPA_CT aus SAP Hinweis 2220926 als Z* Baum in der DMEE hochgeladen
- "2220926 - SEPA-Überweisung Lastschrift DTA XML-Definition für Zahlungsformate SEPA_CT SEPA_DD"
- die Anlage SEPA_CT.zip ist vom 27.09.2016 (und ist Version 2.7 - 2.9 --> Rulebook Version weiß ich immer noch nicht zu erkennen :-( )
Hinweise 1939284 & 1958567 via snote hochgeladen
1939284 - SEPA_CT, SEPA_DD additional tags in DMEE tree required
1958567 - DMEE-Formate SEPA _CT und SEPA_DD - länderspezifische Erweiterung
Durch die Hinweise wird ein Erweiterungsspot (SE18 ES_FI_DMEE_SEPA_COUNTRIES) ins System geladen. Folgende BAdI Definitionen sind darin enthalten:
FI_DMEE_SEPA_COUNTRIES
FI_DMEE_SEPA_EXIT
Im BAdI FI_DMEE_SEPA_COUNTRIES gibt es 2 Erweiterungsimplementierungen.
FI_DMEE_SEPA_COUNTRIES_IMP für Credit (SEPA_CT)
FI_DMEE_SEPA_COUNTRIES_IMP_DEB für Debit (SEPA_DD)
Die SAP liefert das für die Länder BE, LU, AT, PT & SK aus.
In der Methode IF_FI_DMEE_SEPA_COUNTRIES~GET_VALUE werden dort die Länderspezifischen Knoten nachträglich zum DMEE Formatbaum aktiviert.
Man muss sich das so vorstellen das der Standard SEPA_CT Baum über den Hinweis 2220926 in DMEE hochgeladen/definiert wird. Über den BAdI werden weitere Tags im SEPA_CT.xml für die oben genannten Länder im Format zur Laufzeit angereichert.
Für Österreich (AT) war da allerdings ein sehr merkwürdiges Coding drin: (<Ustrd> ist der Tag für den Verwendungszweck)
WHEN: '<PmtInf><CdtTrfTxInf><RmtInf><Ustrd>'.
IF i_fpayh-ziban IS INITIAL.
IF i_extension-node-node_type = 'TECH'.
c_value = 'X'.
ENDIF.
ENDIF.
Auf deutsch. Wenn die IBAN des Lieferanten nicht gepflegt ist wird der Verwendungszweck im Formatbaum aktiviert ??? Diese Abfrage finde ich allerdings sehr unlogisch und habe daher im 2.ten BAdI FI_DMEE_SEPA_EXIT des Erweiterungsspots ES_FI_DMEE_SEPA_COUNTRIES meine eigene Implementierung angelegt. Darin habe ich die Abfrage des Verwendungszweck der SAP übersteuert:
WHEN: '<PmtInf><CdtTrfTxInf><RmtInf><Ustrd>'.
IF i_fpayh-ziban IS not INITIAL.
IF i_extension-node-node_type = 'TECH'.
c_value = 'X'.
ENDIF.
ENDIF.
Damit wird dann der Tag für den Verwendungszweck im im SEPA_CT.xml aktiviert.
Weiterhin hatte ich Probleme mit einem seelenlosen Tag: <Purp/> welches irgendwie unter dem Tag <CdtrAcct> hing. Den akzeptierte die Bank so nicht. Den musste ich dann leider manuell im DMEE Format Knoten "Purp" über eine nie erfüllte Bedingung: FPAYH LAUFI 2 = SPACE 1 lahmlegen.
In der FBPM (SAPFPAYM) Variante zum Datenträger (obpm4) habe ich NUR den Namensraum: urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 angegeben. Namensraum Schema & Ort des Schemas habe ich leer gelassen.
Bei der DTA Erzeugung hatte ich dann noch zusätzlich das Problem das der Zeichensatz mit UTF-16 angeben wurde intern aber UTF-8 verwendet (Trotz Eintrag 4110 im Format). Dafür musste ich dann noch den BAdI DMEE_XML_BADI_01 für mein Format aktivieren. Filterwert ist dann der Z*Formatname aus der DMEE. Damit wird dann das SEPA_CT.xml in UTF-8 erzeugt.
Ganz schön knackig den Weg den die SAP da vorgibt. Geht das auch einfacher ? Hat es jemand anders gemacht ?
Kann mir ggf. einer die Frage beantworten wie das offizielle Vorgehen ist die Länder Filterwerte des BAdI's FI_DMEE_SEPA_COUNTRIES_IMP zu ändern ?
Da sind ja die Länder BE, LU, AT, PT & SK als Filter drin. Ich möchte "SK" da nicht drin haben. Ich kann jetzt einfach über SSCR Ojektregistrierung den Filter "SK" löschen. Aber das ist ja dann eine Modifikation oder ? Ich habe versucht meine eigene Implementierung für FI_DMEE_SEPA_COUNTRIES_IMP anzulegen. Dabei kommt dann aber die Fehlermeldung:
BAdI ist SAP intern, Implementieren im Kundennamensraum verboten. Meldungsnr. SEEF_BADI176
mfG
Charakter_Kopf
Zuletzt bearbeitet am 21.04.17 13:30
↧
Re: Ãbersetzungen von CO Stammdaten
Bernd60:
Ich suche nach einer Möglichkeit (am besten im Standard) in einer Transaktionsmaske alle Sprachen zusammen zu pflegen.
Z.B. Kostenart anlegen und neben der Anmeldesprache gleich die Übersetzungen in EN, FR, PL, IN mit zu pflegen, oder diese im Nachgang per Massenpflege nachzupflegen.
Hallo Bernd,
so was gibt es meines Wissens im Standard so nicht und eingedenk des Umstandes, dass es ab S/4 das Objekt "Kostenart" als eigenständiges Stammdatenobjekt nicht mehr gibt, wird SAP das (vermutlich) auch nicht mehr entwickeln und ausliefern.
Für die "Massen(nach)pflege" der Kostenartentexte steht ja immerhin das Z-Programm aus dem genannten Hinweis zur Verfügung. Alles andere wirst Du im Zweifel selber basteln müssen.
Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog
↧
Re: Mahndruck
Hallo,
in meiner alten Firma wurde das ziemlich kompliziert über eine Z* Kopie vom RSPOPRNT gemacht der mit Zusatzfunktionen für einen Spool Split abhängig vom Simplex / Duplex Druck angereichert wurde.
1) Zuerst erzeugt die F150 über das normale Druckprogramm die Mahnbriefe.
2) mit dem Z*RSPOPRNT wurde Mahn Spoolauftrag wurde nachträglich in 2 Spoolaufträge 1seitig und mehrseitig aufgesplittet.
Die Tabelle: parts wurde in der Z* Kundenentwicklung ausgelesen. Da kriegt man dann die Info ob's einseitig oder mehrseitig ist. Mit der Info wurden dann 2 Spoolaufträge Typ1=einseitig Typ2=mehrseitig aus dem originalen Mahn Spoolauftrag gesplittet.
War ein mega frickel aber stabil im Ergebnis.
Ich hoffe es gibt eine einfachere Lösung oder dies hier dient als Denkanstoß für eine mögliche Lösung.
mfG
Charakter_Kopf
in meiner alten Firma wurde das ziemlich kompliziert über eine Z* Kopie vom RSPOPRNT gemacht der mit Zusatzfunktionen für einen Spool Split abhängig vom Simplex / Duplex Druck angereichert wurde.
1) Zuerst erzeugt die F150 über das normale Druckprogramm die Mahnbriefe.
2) mit dem Z*RSPOPRNT wurde Mahn Spoolauftrag wurde nachträglich in 2 Spoolaufträge 1seitig und mehrseitig aufgesplittet.
Die Tabelle: parts wurde in der Z* Kundenentwicklung ausgelesen. Da kriegt man dann die Info ob's einseitig oder mehrseitig ist. Mit der Info wurden dann 2 Spoolaufträge Typ1=einseitig Typ2=mehrseitig aus dem originalen Mahn Spoolauftrag gesplittet.
War ein mega frickel aber stabil im Ergebnis.
Ich hoffe es gibt eine einfachere Lösung oder dies hier dient als Denkanstoß für eine mögliche Lösung.
mfG
Charakter_Kopf
↧
Re: Umsatzsteuer bei Lieferung aus Werk im Ausland
Hallo,
das Thema "Werke im Ausland" ist recht komplex. Grundsätzlich solltest Du Dich dazu im OSS belesen.
Bitte mal folgende OSS Hinweise sichten:
730466 - Gesetzliche Anford Steuerbasis mit Steuerkurs umrechnen
1056310 - Hinweis 730466 falscher Kurstyp für Meldeland
10560 - Steuerermittlung bei Werk im Ausland
1589287 - Erweiterung Schnittstelle BTE 2051 um Export LWBAS LWSTE
Bei uns musste das Thema NUR im FI eingeführt werden. Grundsätzlich werden die Werke im Ausland im FI Customizing aktiviert... über Finanzwesen/Umsatzsteuer/Werke im Ausland/Werke im Ausland aktivieren.
Letztendlich wird durch diesen Schalter (der ist nicht Mandantenübergreifend wie die SAP behauptet). Im Landescustomizing (SAPNetweaver/Allgemeine Einstellungen/Länder einstellen/Länder definieren/ ... bei Dir dann "GB" 2 neue Felder aufgeblendet:
- Landeswährung
- Kurstyp
Bei uns war das ein Werk im Ausland Ungarn. In die 2 neuen Felder habe ich dann HUF & einen neuen Kurstyp MNB (für HU Forint) angelegt um für die Landesbank Magyar Nemzeti speziellen Kurs für die Steuermeldung RFASLD15 umrechnen zu können (HU Landesrecht !!!).
In den Steuerkennzeichen FTXP gibt es dann ein neues Feld Steuermeldeland (unter Toleranzsatz wird das aufgeblendet), T007A-LSTML. Bei uns mussten für die Werke im Ausland neue Steuerkennzeichen angelegt werden die dann mit Steuermeldeland "HU" gepflegt wurden. Weiterhin mussten diese Steuerkennzeichen auch im TAXHU zumindest rudimentär angelegt werden. Wenn die dort nicht gepflegt waren kriegte der RFASLD15 ein Problem mit dem Lesen der Steuerkennzeichen.
Effekt der ganzen Sache ist im FI das die Tabelle BSET 3 weitere Felder befüllt werden die RFASLD15/RFUMSV00 auswertet:
BSET-LSTML
BSET-LWSTE
BSET-LWBAS
Im RFUMSV00 kann man dann den Schalter "Landeswährung statt Hauswährung" aktivieren. Dabei werden dann die oben erwähnten Felder zum Steuermeldeland gelesen und ausgewertet.
Ich hoffe das war ein "bisschen" verständlich und hilft Dir ggf.
mfG
Charakter_Kopf
das Thema "Werke im Ausland" ist recht komplex. Grundsätzlich solltest Du Dich dazu im OSS belesen.
Bitte mal folgende OSS Hinweise sichten:
730466 - Gesetzliche Anford Steuerbasis mit Steuerkurs umrechnen
1056310 - Hinweis 730466 falscher Kurstyp für Meldeland
10560 - Steuerermittlung bei Werk im Ausland
1589287 - Erweiterung Schnittstelle BTE 2051 um Export LWBAS LWSTE
Bei uns musste das Thema NUR im FI eingeführt werden. Grundsätzlich werden die Werke im Ausland im FI Customizing aktiviert... über Finanzwesen/Umsatzsteuer/Werke im Ausland/Werke im Ausland aktivieren.
Letztendlich wird durch diesen Schalter (der ist nicht Mandantenübergreifend wie die SAP behauptet). Im Landescustomizing (SAPNetweaver/Allgemeine Einstellungen/Länder einstellen/Länder definieren/ ... bei Dir dann "GB" 2 neue Felder aufgeblendet:
- Landeswährung
- Kurstyp
Bei uns war das ein Werk im Ausland Ungarn. In die 2 neuen Felder habe ich dann HUF & einen neuen Kurstyp MNB (für HU Forint) angelegt um für die Landesbank Magyar Nemzeti speziellen Kurs für die Steuermeldung RFASLD15 umrechnen zu können (HU Landesrecht !!!).
In den Steuerkennzeichen FTXP gibt es dann ein neues Feld Steuermeldeland (unter Toleranzsatz wird das aufgeblendet), T007A-LSTML. Bei uns mussten für die Werke im Ausland neue Steuerkennzeichen angelegt werden die dann mit Steuermeldeland "HU" gepflegt wurden. Weiterhin mussten diese Steuerkennzeichen auch im TAXHU zumindest rudimentär angelegt werden. Wenn die dort nicht gepflegt waren kriegte der RFASLD15 ein Problem mit dem Lesen der Steuerkennzeichen.
Effekt der ganzen Sache ist im FI das die Tabelle BSET 3 weitere Felder befüllt werden die RFASLD15/RFUMSV00 auswertet:
BSET-LSTML
BSET-LWSTE
BSET-LWBAS
Im RFUMSV00 kann man dann den Schalter "Landeswährung statt Hauswährung" aktivieren. Dabei werden dann die oben erwähnten Felder zum Steuermeldeland gelesen und ausgewertet.
Ich hoffe das war ein "bisschen" verständlich und hilft Dir ggf.
mfG
Charakter_Kopf
Zuletzt bearbeitet am 21.04.17 16:00
↧
↧
Re: Differenzen zwischen Einzelpostenanzeige und Kreditstammblatt
Hallo Gernot,
anscheinend besteht bei Euch eine Diskrepanz zwischen den Belegen und dem sog. Kreditvektor (vereinfacht gesagt eine summarische Zusammenfassung aller Werte, die gegen das Kreditlimit gerechnet werden (Auftragsobligo, OP's, Anzahlungen,...)). Das kann z.B. dann entstehen, wenn zu einem Debitor nachträglich Kreditlimitdaten erfasst wurden. Im Kreditmanagement gibt es eine Funktion zum Neuaufbau des Kreditvektors. Hab gerade kein SAP on, aber das findest Du im Anwendungsmenü unter "Debitoren... Kreditmanagement" oder so ähnlich.
Hoffe, das bringt Dich weiter...
Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog
anscheinend besteht bei Euch eine Diskrepanz zwischen den Belegen und dem sog. Kreditvektor (vereinfacht gesagt eine summarische Zusammenfassung aller Werte, die gegen das Kreditlimit gerechnet werden (Auftragsobligo, OP's, Anzahlungen,...)). Das kann z.B. dann entstehen, wenn zu einem Debitor nachträglich Kreditlimitdaten erfasst wurden. Im Kreditmanagement gibt es eine Funktion zum Neuaufbau des Kreditvektors. Hab gerade kein SAP on, aber das findest Du im Anwendungsmenü unter "Debitoren... Kreditmanagement" oder so ähnlich.
Hoffe, das bringt Dich weiter...
Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog
↧
Erlöskonten nur automatisch bebuchbar
Hallo Zusammen,
vielleicht ist mein Hirn noch im Osterurlaub... :-) Kann mir jemand auf die Sprünge helfen, bitte.
Die MM-Bestandskonten sind gekennzeichnet als nur automatisch bebuchbar. Meines Wissens nach ist das bei Erlöskonten bzw. Konten die durch SD bebucht werden auch so. Bei uns gibt es ein Konto Frachterklöse das nicht als automatisch bebuchbar gekennzeichnet ist. Sollte es aber sien, oder ? Oder liege ich da falsch? Welche konten sollten nur automatisch bebuchbar sein?
Danke & Grüße
Exberliner
vielleicht ist mein Hirn noch im Osterurlaub... :-) Kann mir jemand auf die Sprünge helfen, bitte.
Die MM-Bestandskonten sind gekennzeichnet als nur automatisch bebuchbar. Meines Wissens nach ist das bei Erlöskonten bzw. Konten die durch SD bebucht werden auch so. Bei uns gibt es ein Konto Frachterklöse das nicht als automatisch bebuchbar gekennzeichnet ist. Sollte es aber sien, oder ? Oder liege ich da falsch? Welche konten sollten nur automatisch bebuchbar sein?
Danke & Grüße
Exberliner
↧
Re: Erlöskonten nur automatisch bebuchbar
Hallo Exberliner,
Konten, die nur integrativ bebucht werden (also z.B. aus MM, SD oder anderen Modulen) sollten als "nur automatisch bebuchbar" gekennzeichnet sein. Korrekturbuchungen, z.B. im Bereich der Bestände, werden üblicherweise auf separaten Korrektur, bzw. Wertberichtigungskonten gebucht.
Bei den Frachterlösen müsstest Du mal schauen, ob hier tatsächlich alle Frachten ein Eurem Prozess über SD fakturiert werden oder ob es auch reine FI-Rechnungen gibt (wäre bei Frachten zumindest nicht ungewöhnlich). Das findest Du am einfachsten raus, in dem Du mal einen Blick auf die Einzelposten wirfst und z.B. nach der Belegart schielst oder direkt BKPF-TCODE auswertest.
Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog
Konten, die nur integrativ bebucht werden (also z.B. aus MM, SD oder anderen Modulen) sollten als "nur automatisch bebuchbar" gekennzeichnet sein. Korrekturbuchungen, z.B. im Bereich der Bestände, werden üblicherweise auf separaten Korrektur, bzw. Wertberichtigungskonten gebucht.
Bei den Frachterlösen müsstest Du mal schauen, ob hier tatsächlich alle Frachten ein Eurem Prozess über SD fakturiert werden oder ob es auch reine FI-Rechnungen gibt (wäre bei Frachten zumindest nicht ungewöhnlich). Das findest Du am einfachsten raus, in dem Du mal einen Blick auf die Einzelposten wirfst und z.B. nach der Belegart schielst oder direkt BKPF-TCODE auswertest.
Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog
↧
Re: Erlöskonten nur automatisch bebuchbar
Danke, Mr.Bojangles.
Es gibt in der Tat eine Handvoll manuelle Buchungen auf dem Konto Frachterlöse. Also wohl in Ordnung so...
Es gibt in der Tat eine Handvoll manuelle Buchungen auf dem Konto Frachterlöse. Also wohl in Ordnung so...
↧
↧
Belegart steuern
Hallo Zusammen,
gibt es eine Möglichkeit bei der Belegart festzulegen, ob diese nur für maschinelle oder manuelle Buchungen genutzt werden darf?
Ich habe schon das ganze Customizing und das halbe Internet durchforscht - aber ich kann weiterhin keine Steuerungsmöglichkeit finden.
Weiß jemand von Euch rat ?
Liebe Grüße
Elbe4
gibt es eine Möglichkeit bei der Belegart festzulegen, ob diese nur für maschinelle oder manuelle Buchungen genutzt werden darf?
Ich habe schon das ganze Customizing und das halbe Internet durchforscht - aber ich kann weiterhin keine Steuerungsmöglichkeit finden.
Weiß jemand von Euch rat ?
Liebe Grüße
Elbe4
↧
Re: SAP Umstieg von Rulebook 3.2 auf Rulebook 6.0/7.0
Hallo,
es gab doch noch ein Fehler beim Upload im ELBA 5.8.0![]()
Der Zahlungsträger war als Salaries "SALA" gekennzeichnet und konnte daher in ELBA nicht weiter bearbeitet werden. Das kam aus dem merkwürdigen Coding der Implementierung FI_DMEE_SEPA_COUNTRIES_IMP für Land "AT".
Bei der Suche nach der Ursache habe ich doch tatsächlich noch etliche weitere Hinweise zum Erweiterungsspot ES_FI_DMEE_SEPA_COUNTRIES gefunden die z.T. vom 07.04.2017 erst von der SAP upgedatet wurden.
Grundsätzlich war das erste Coding was SAP da als AT Standard ausgeliefert hatte ziemlicher Mist. Die neue Version hatte viele der fraglichen Nodes Abfragen dann auch nicht mehr drin ;-)
Mit den Hinweisen
2140438 - SEPA_CT: Ölsterreich - Name des endgültigen Gläubigers bei Barauszahlung (Postbarzahlung)
2013784 - SEPA_CT: Steuerzahlungen in Österreich
und den Hinweisen die da noch als Vorausetzung dran hingen wurde ein neuer Funktionsbaustein: FI_FPAY2REGU_SEPA ein SEPA_CT Formatbaum (abweichend zum Standardhinweis für DMEE SEPA Formatbäume 2220926 - SEPA-Überweisung Lastschrift DTA XML-Definition für Zahlungsformate SEPA_CT SEPA_DD) eine eigene AT Implementierung FI_DMEE_SEPA_COUNTRIES_IMP_AT ausgeliefert.
Leider musste im Zuge der Hinweis Upload Orgie auch Coding für Slowakei und Schweiz eingearbeitet werden (FI_DMEE_SEPA_COUNTRIES_IMP_SK)
2043822 - SEPA_CT: Switzerland Specific Enhancements for SEPA Credit Transfer
2096717 - CH: SEPA_CT: Removing of tag 'PmtTpInf' at level-C in the Switzerland DME file
2140126 - SEPA_CT for Slovakia (You should have OSS notes 1939284, 1958567 and 2232531 implemented in your system)
2150594 - SEPA_CT: BE and LU Specific Enhancements for Non-SEPA Payments
2158180 - SEPA_CT: Slovakia - new SK specific enhancement
Beim letzten Hinweis kam es dann leider auch noch zu Konflikten der Landesversionen SK & AT:
2168088 - SEPA_CT: Österreich: Performanceproblem (Aufruf des Funktionsbausteins FI_FPAY2REGU_SEPA ) + Korrektur für Name des engültigen Gläubigers
Die konnte ich aber irgendwie umfahren....
Die SAP hat die Landesimplementierungen zig mal hin-her geändert:
FI_DMEE_SEPA_COUNTRIES_IMP
FI_DMEE_SEPA_COUNTRIES_IMP_AT
FI_DMEE_SEPA_COUNTRIES_IMP_SK
Die Filterwerte der Badis mehrmals hin-und-her geschubst....beim einen raus beim anderen rein etc.
Wegen mangelhafter Performance auch an vielen weiteren Stellen (speziell die Filter der Badis) nachgebessert.
Friede sei mit dem der kurzfristig ein Support-Package dafür einspielen kann. Ich kann es leider nicht und muss mich mit den tollen Hinweisen durchquälen. Aber das ist man ja gewohnt![]()
Ach ja ... nicht vergessen die Implementierung der ersten fehlerhaften Nodes aus dem Badi: FI_DMEE_SEPA_EXIT wieder zu deaktivieren bzw. zu entfernen.
Letzter Stand ist jetzt das in der SE19 eine Erweiterungsimplementierung
FI_DMEE_SEPA_COUNTRIES_IMP_AT mit scheinbar korrektem Coding zu den Nodes in der Methode "IF_FI_DMEE_SEPA_COUNTRIES~GET_VALUE" drin sind.
Zusätzlich gabs auch noch eine weitere Funktion für steuerliche Zahlungen die dann im Segmenttext über "i_fpayp-sgtxt+0(1) = '+'." ein "+" aktivert werden kann.
Vermutlich liest hier eh keiner mehr mit. Aber ich wollte mir die Mühe machen eine Umsetzung für den SEPA_CT Datenträger für AT nach Rulebook 7 aktuell mit ELBA 5.8.0 zu dokumentieren. Mit allen blöden Problemen die dabei aufgetreten sind.
Ich hoffe es hilft ggf. jemanden der das aktuell auch machen darf :-)
Viel Spaß damit
Charakter_Kopf
es gab doch noch ein Fehler beim Upload im ELBA 5.8.0
Der Zahlungsträger war als Salaries "SALA" gekennzeichnet und konnte daher in ELBA nicht weiter bearbeitet werden. Das kam aus dem merkwürdigen Coding der Implementierung FI_DMEE_SEPA_COUNTRIES_IMP für Land "AT".
Bei der Suche nach der Ursache habe ich doch tatsächlich noch etliche weitere Hinweise zum Erweiterungsspot ES_FI_DMEE_SEPA_COUNTRIES gefunden die z.T. vom 07.04.2017 erst von der SAP upgedatet wurden.
Grundsätzlich war das erste Coding was SAP da als AT Standard ausgeliefert hatte ziemlicher Mist. Die neue Version hatte viele der fraglichen Nodes Abfragen dann auch nicht mehr drin ;-)
Mit den Hinweisen
2140438 - SEPA_CT: Ölsterreich - Name des endgültigen Gläubigers bei Barauszahlung (Postbarzahlung)
2013784 - SEPA_CT: Steuerzahlungen in Österreich
und den Hinweisen die da noch als Vorausetzung dran hingen wurde ein neuer Funktionsbaustein: FI_FPAY2REGU_SEPA ein SEPA_CT Formatbaum (abweichend zum Standardhinweis für DMEE SEPA Formatbäume 2220926 - SEPA-Überweisung Lastschrift DTA XML-Definition für Zahlungsformate SEPA_CT SEPA_DD) eine eigene AT Implementierung FI_DMEE_SEPA_COUNTRIES_IMP_AT ausgeliefert.
Leider musste im Zuge der Hinweis Upload Orgie auch Coding für Slowakei und Schweiz eingearbeitet werden (FI_DMEE_SEPA_COUNTRIES_IMP_SK)
2043822 - SEPA_CT: Switzerland Specific Enhancements for SEPA Credit Transfer
2096717 - CH: SEPA_CT: Removing of tag 'PmtTpInf' at level-C in the Switzerland DME file
2140126 - SEPA_CT for Slovakia (You should have OSS notes 1939284, 1958567 and 2232531 implemented in your system)
2150594 - SEPA_CT: BE and LU Specific Enhancements for Non-SEPA Payments
2158180 - SEPA_CT: Slovakia - new SK specific enhancement
Beim letzten Hinweis kam es dann leider auch noch zu Konflikten der Landesversionen SK & AT:
2168088 - SEPA_CT: Österreich: Performanceproblem (Aufruf des Funktionsbausteins FI_FPAY2REGU_SEPA ) + Korrektur für Name des engültigen Gläubigers
Die konnte ich aber irgendwie umfahren....
Die SAP hat die Landesimplementierungen zig mal hin-her geändert:
FI_DMEE_SEPA_COUNTRIES_IMP
FI_DMEE_SEPA_COUNTRIES_IMP_AT
FI_DMEE_SEPA_COUNTRIES_IMP_SK
Die Filterwerte der Badis mehrmals hin-und-her geschubst....beim einen raus beim anderen rein etc.
Wegen mangelhafter Performance auch an vielen weiteren Stellen (speziell die Filter der Badis) nachgebessert.
Friede sei mit dem der kurzfristig ein Support-Package dafür einspielen kann. Ich kann es leider nicht und muss mich mit den tollen Hinweisen durchquälen. Aber das ist man ja gewohnt
Ach ja ... nicht vergessen die Implementierung der ersten fehlerhaften Nodes aus dem Badi: FI_DMEE_SEPA_EXIT wieder zu deaktivieren bzw. zu entfernen.
Letzter Stand ist jetzt das in der SE19 eine Erweiterungsimplementierung
FI_DMEE_SEPA_COUNTRIES_IMP_AT mit scheinbar korrektem Coding zu den Nodes in der Methode "IF_FI_DMEE_SEPA_COUNTRIES~GET_VALUE" drin sind.
Zusätzlich gabs auch noch eine weitere Funktion für steuerliche Zahlungen die dann im Segmenttext über "i_fpayp-sgtxt+0(1) = '+'." ein "+" aktivert werden kann.
Vermutlich liest hier eh keiner mehr mit. Aber ich wollte mir die Mühe machen eine Umsetzung für den SEPA_CT Datenträger für AT nach Rulebook 7 aktuell mit ELBA 5.8.0 zu dokumentieren. Mit allen blöden Problemen die dabei aufgetreten sind.
Ich hoffe es hilft ggf. jemanden der das aktuell auch machen darf :-)
Viel Spaß damit
Charakter_Kopf
Zuletzt bearbeitet am 25.04.17 17:34
↧
Re: Belegart steuern
Hi,
ist im Customizing der Belegarten direkt drin.
rechte Seite --> besondere Verwendung --> Checkbox Nur Batch Input.
Greetz
Charakter_Kopf
ist im Customizing der Belegarten direkt drin.
rechte Seite --> besondere Verwendung --> Checkbox Nur Batch Input.
Greetz
Charakter_Kopf
↧