Import von nur 30 Zeichen für Orte des Debitoren/Kreditoren und Kost2

[#1]

Guten Tag,

ich nutze DATEV "nur" für die Buchhaltung (halt Rechnungswesen) und den Zahlungsverkehr.

Nun exportiere ich aus meinem Warenwirtschaftssystem bzw. WaWi (Concept Office CO) die Firmen (Debitoren + Kreditoren) und die Ausgangs- und Eingangsrechnungen und will diese dann ins DATEV importieren.

Es klappt ja auch, nur DATEV meckert immer bei den Firmen, wenn der Name des Ortes länger als 30 Zeichen ist und kürzt z.B. bei "Blankenfelde-Mahlow OT Dahlewitz" in "Blankenfelde-Mahlow OT Dahlewi". 

Gut, das scheinbar DATEV in Finnland nicht eingesetzt wird ;-).

O.K. Die Kürzung wäre ja noch akzeptabel.

Aber nun exportiere ich auch noch die Bestellnummer des Kunden in KOST2. Dieses konnte ich umständlicher Weise über meinen Steuerberater wenigstes auf 30 Zeichen aufbohren. Aber was macht DATEV, wenn dieses Feld mehr stellen hat? DATEV importiert nicht davon, nicht einmal abgeschnitten. 

Ist doch sehr unschön.

Was sind 30 Stellen? Wir leben doch in einer "modernen" Welt. Es wäre doch ein leichtes, diese Felder auf 255 zu ermöglichen mit dem hinterliegenden SQLer. Die Formulare sollten natürlich auch angepasst werden.

Hoffentlich haben hier auch mehr User diese Probleme und DATEV reagiert.

Liebe Grüße

Peter Hussock

[#2]

Vielleicht gibt das Feld KB mäßig in der Datenbank nicht mehr? Man kann nur Vermutung anstellen...

[#3]

Die Größe der jeweiligen Spalten in den jeweiligen Tabellen können doch vom Hersteller der Datenbank (DB) vorgegeben werden. Also müsste DATEV hier nur ran. Klar sollten sie dann auch was in den Ausgabeformularen machen.

Und vielleicht mal in 2020 richtig angekommen sein.

[#4]

Ich vermute das Problem ist nicht, die Größe des Datenfeldes anzupassen, sondern die Druckmasken.

Sie können ja schon froh sein, dass KOST soviel Platz zur Verfügung stellt. Und wenn Sie bedenken, wie lange es gedauert hat, dass das Belegfeld1 endlich lange Rechnungsnummer á la Amazon akzeptiert.

Gruß Achilleus

[#5]

Hallo Achilleus,

ja, ich glaube auch, das wäre der schlimmste Aufwand. Mit Formulare meinte ich auch die Druckmasken.

Ist mir nicht aufgefallen, das KOST auch einmal kleiner war. Ich versuche ja auch, nicht über Amazon einzukaufen ;-). Ich hatte mal eine Bestellung bei Amazon generiert und die schickten für einen Artikel, welchen ich 8x bei einem Amazon direkt kaufte, 8 Rechnungen. Da war es mir egal, wie die zurechtkamen mit meiner Überweisung:-).

Wenn DATEV da mal dran war, hätten sie auch alle solche Felder gleich durchziehen können.

Liebe Grüße

phussock

[#6]

Bei DATEV ist immer die Salami-Taktik angesagt.

Und manchmal bekommen Sie statt der Salami plötzlich gekochten Schinken.

Und wenn Sie viel Pech haben, dann bekommen eine halbe Brotscheibe mit Salami und die andere Hälfte ist noch trockenes altes Brot.

Alle können es besser, nur die DATEV nicht.

Die murksen noch technisch im Jahrzehnt 1990 rum.

Gruß Achilleus

[#7]

Hallo Achilleus,

so konkret wollte ich es nicht ausdrücken ;-).

Man will sich ja nicht streiten mit diesem großen Haus.

Liebe Grüße

phussock

[#8]

Hi Hr Hussock, 

Ja klar , Sie haben Recht! Auch das Datev Feld Auftrags Nr hat „nur“ 30 Zeichen. 

Warum nicht ihre Auftrags Nr.  einfach in den Buchungstext? Da haben Sie 60 Zeichen. 
Stammdaten, Ort: ihre Kunden und Lieferanten werden hoffentlich schon nicht alle in dort wohnen 🥴

Datev bietet: Standard, klappt also nur „allermeisten bei fast allen“ das aber scheinbar ganz gut 😌

[#9]

Hallo alexanderonline,

ich kenne das Feld "Datev Feld Auftrags Nr" leider nicht, vielleicht kommt das aus dem Rundum-Paket, DATEV-Arbeitsplatz und der somit angelegten leichten WaWi. Aber das nutze ich halt nicht, da ich eine Branchenlösung halt nutzte. In den Buchungstext exportieren wir den Kundennamen bzw. noch andere Informationen zum Lieferanten.

Also, den hake ich ab. 

DATEV ist leider ein gewisser Standard. Aber auch die sollten sich mal drehen. Wenn ein Mitarbeiter zu mir sagt, "es war doch immer so", kommt mir die Galle hoch.

Liebe Grüße

Peter Hussock

[#10]

Hallo Community,

danke für die Ideen und Vorschläge, über welche Felder ergänzenden Informationen zum Buchungssatz - wie in Ihrem Fall Herr Hussock, beispielsweise die Bestellnummern im Kost-Feld 2 - übernommen werden können. Ergänzend hier unsere Ideen, wie zusätzliche Informationen zum Buchungstext übernommen werden können:

1. Buchungstext
2. Auftragsnummer
3. Zusatzinformationen.

Natürlich bieten alle diese Felder Vor- und Nachteile. Gern besprechen wir mit Ihnen Möglichkeiten und Alternativen für Ihren konkreten Bedarf. Sie können uns gerne unter der Nummer 0911 319 38600 dazu erreichen.

Die Antwort auf die Frage, warum in KOST1 bzw. KOST2 maximal 36 Stellen möglich sind und warum die Felder bei größerer Länge nicht übernommen werden, stellen wir in einem Beispiel dar. Angenommen, es ist in einem Buchungssatz eine 40-stellige Kostenstelle enthalten, die nach einem Kürzen auf 36 Stellen genau die gleiche Kombination ergibt, wie bei einer bereits vorhandenen 36-stellige Kostenstelle. Dann werden Buchungssätze, die zu der 40-stelligen Kostenstellen gehören, einer Kostenstelle zugeordnet, wo sie nicht hingehören. Um diese falsche Zuordnung abzufangen, werden die Inhalte nicht übernommen.

Aus der Diskussion können wir auch entnehmen, dass eine generelle Verlängerung des Kost-Feldes wünschenswert ist. Ein Wort zum Hintergrund, warum die Felder 36-stellig sind. Bei der Entscheidung über die Länge der Felder KOST1 und KOST2, Belegfeld 1 usw. im Buchungssatz haben wir insbesondere die Kundensicht berücksichtigt und uns am Marktbedarf orientiert. Es hat sich herausgestellt, dass für die meisten Anwendungsszenarien die aktuell möglichen 36 Stellen ausreichen.

Natürlich können wir nachvollziehen, dass es auf den ersten Blick recht einfach scheint, ein Feld auf beliebig viele Stellen zu erweitern. Ein genauerer Blick auf die Umsetzung zeigt, an welchen Stellen in den Programmen, sowie Produkt- und Serviceinformationen Aufwände entstehen.

Hier einige Beispiele (nicht abschließend):

1. Anpassungen in der Datenbank
2. Anpassungen an allen internen und externen Schnittstellen
3. Anpassungen an Layouts für Druck
4. Anpassungen an der Darstellung in den online Auswertungen
5. Darstellung der Spalten auf dem Bildschirm – Wo und wie lange wird es dort dargestellt?
6. Anpassungen an Erfassungs- Dialogmasken
7. …. Bis hin zu Anpassungen in Schulungsunterlagen, Info-Dokis etc.
8.  

Aus jetziger Sicht und wenn wir die o.g. beispielhafte Liste an Aufwand berücksichtigen, werden wir die Länge der Felder im Buchungssatz mittelfristig nicht erweitern.

Beste Grüße

Severin Dimic

[#11]

Hallo Herr Dimic,

wird sich hier seitens der DATEV nun etwas ändern?

Klar verstehe ich es, erst einmal alte Strukturen zu behalten, aber ist mittelfristig nicht etwas vorbei?

Beste Grüße

Peter Hussock

[#12]

Hallo Herr Hussock,

wir haben keine Erweiterung vorgesehen. Es können in den beiden KOST-Feldern jeweils 36 Zeichen erfasst werden.

Beste Grüße aus Nürnberg

Manuela Sigert

DATEV eG

[#13]

Auch wenn es ein bisschen ketzerisch klingt.

Es dürfte sicher die Ausnahme sein, das Ortsnamen so lange dargestellt werden. Es ist zwar schön, wenn auch in kleinen Städten und Gemeinden der Ortsteil genannt wird. Ich könnte mir vorstellen, dass die Post den Adressaten auch ohne die Angaben des Ortsteils findet.  Hier in Köln - keine wahrlich kleine Kommune - kommen wir prima mit der Angabe der PLZ, aber ohne Benennung des Ortsteils aus.

Und ob eine Sextillion große Zahl nicht ausreicht um eine Kostenstelle darzustellen dürfte auch eher ein vereinzeltes Problem darstellen. Oder?

Hoffentlich fühlt sich niemand in seinem Lokalpatriotismus und als Erfinder von langen Kostenstellen auf den Schlips getreten. Eventuell ist dann DATEV zu "klein" und man sollte sich dann SAP gönnen. 

Liebe Grüße

Martin Heim