Office: (Office 2013) Bereiche verkleinern, Voraussetzungen dafür?

Hallo zusammen!
Ich schreibe gerade an einem Bericht, in dem einige Zeilen Gedrucktes mal auf dem Ausdruck erscheinen soll und mal nicht, abhängig von verschiedenen Parametern.
Alle betreffenden Felder befinden sich im Fuß des Berichts. Die Eigenschaft "verkleinerbar" steht auf "Ja"
Sollen Zeilen nicht gedruckt werden, erwarte ich , dass der Bericht "zusammenrückt und die Zeilen darunter weiter nach oben rutschen, so wie ich es von meinen anderen Berichten her kenne, wo dies gut funktioniert.
Im vorliegenden Fall nun klappt das nicht.
Verschieden Felder sind zwar wie gewünscht nicht auf dem Bericht zusehen, ihr Platz wird jedoch "frei gehalten".

Ich frage mich daher welche Voraussetzungen eigentlich erfüllt sein müssen, damit dies Zusammenrücken funktioniert.

Um Textfelder nicht mehr auf dem Bericht erscheinen lassen zu wollen, habe ich mich der Format Funktion bedient.
Zunächst habe ich mit einer Wenn-Funktion die Felder mit einer 0 gefüllt, wenn bestimmte Kriterien erfüllt waren. Das benötigte ich für weitere Berechnungen.
Über die Format-Eigenschaft des Steuerelements habe ich dann festgelegt, das bei einer 0 im Feld nichts dargestellt werden soll

Code:

Gruß OD

:)

 

Hallo,
wenn es auf der gleichen Höhe noch weitere Felder gibt, wird nicht nachgerückt.
Das Nachrücken funktioniert nur dann, wenn entweder alle Felder auf dieser Höhe betroffen sind, oder es nur ein Feld gibt.
Außerdem, solltest Du NULL verwenden und nicht NULLWERT.

 

Ich habe diesem Post mal zwei Screenshots angehängt.
Der eine zeigt den Berichtsausschnitt in der Voransicht, der andere die Entwurfsansicht dazu.

Im Screenshot der Entwurfsansicht habe ich den Bereich rot eingerahmt, der richtigerweise nicht auf dem Bericht dargestellt wird, wie man sieht.
Allerdings rückt von unten "nichts" nach...
Gruß OD

 

Hallo,
Falls ich die Bilder richtig gedeutet habe.
Wenn für unterschiedliche Steuersätze eigene Felder auf einem Bericht
benötigt werden, sind m.E. Zweifel am Datenmodell angebracht.
Der Steuersatz (und Nachlass) hängt doch vom Kunden und weiteren
Bedingungen (z.B. Lieferanschrift, Rabattstaffeln) ab. Da sollten sich die
richtigen Werte doch per Abfrage von vorneherein gefiltert zusammen
stellen lassen, statt mit Ausdrücken in (unnötigen) Steuerelementeinhalten.
gruss ekkehard

 

Hallo Ekkehard,
danke für Deinen Post.
Wenn Du auch noch eine Lösung für mein eigentlich beschriebenes Problem hast, wäre das toll.

Das ist nämlich noch immer nicht gelöst!

Zwischenzeitlich habe ich noch weiter recherchiert und bin darauf gestoßen,
dass es daran liegen soll, das sich Steuerelemente überlappen, und deshalb das Zusammenrücken nicht funktioniert.

>> ausprobiert >> leider ohne Erfolg.

Warum es notwendig ist die Steuerelemente so zu wählen wie ich es gemacht habe kann ich dir viell. später erklären, wenn es Dich interessiert.
Im Moment fehlt die Zeit.

Die MwSt-Senkung und die daraus resultierende Anpassung der Rechnungsprozesse hat auch mich, wie viele andere kalt erwischt.
Und das eine Woche vor dem Urlaub. Gruß OD

 

Hallo,
wenn die Änderung der MWST Anpassungen an der Datenbank notwendig macht, hat man die Struktur falsch angelegt.
Ein andere MWST Satz ist einfach nur ein neuer DAtensatz in der MWST Tabelle und und ab Stichtag wird dann zur Berechnung der andere MWST Schlüssel eingetragen.
Es darf nicht sein, dass eine MWST Änderung Änderungen an Objekten notwendig macht.
Wenn die Änderung der MWST wieder zurückgenommen wird, musst Du das ja wieder anders rum machen.

MWST wird niemals fest in Formeln geschrieben, sondern immer aus einer TAbelle entnommen. Das lässt sich sogar über ein Gültigkeitsdatum automatisieren, muss aber nicht.
Das Eintragen eines neuen WMST Schlüssels genügt.

Diese Wenn Orgie in Deinem Bericht wird bei korrektem Aufbau ersatzlos überflüsig.

 

Moin,

mir ist es mal gelungen, ein Feld mit minimaler Breite anzulegen, das wurde dann als dermaßen dünner Strich angezeigt, dass ich es tatsächlich nicht wiedergefunden habe. Erst Vergrößern der Darstellung hat mich dem auf die Spur gebracht.

Ansonsten schließe ich mich @NeuerMann1978 an: Eine Query sollte sich den richtigen MwSt-Satz selbst besorgen, dann bräuchte es so ein Gedöns mit der Formatierung erst gar nicht.

 

es erstaunt mich wieviel Lösungsvorschläge es für ein Problem gibt, das gar niemand kennt, wohingegen das eigentliche Problem, welches ich hier thematisiert habe, offenbar keine Lösung findet.
Ich hatte ja schon geschrieben, das, wenn Zeit ist, ich das gern erkläre.

Wer im Baugewerbe unterwegs ist , wird wissen worum es mir geht:
Leistungszeitraum dehnt sich über dem MwSt-Wechsel aus,
Monatl. Abschlagsrechnungen, mit regelmäßig wiederkehrenden Pos. mit denen die Massenzunahmen abgerechnet werden enthalten dann Positionen die anfänglich mit 19% und ab 1.7. mit 16% abgerechnet werden müssen.

Bsp:
Es ist veranschlagt 5000Kg Kleber zu verarbeiten:
Anfang Jun beginnt das Projekt: Ende Juni sind 1000Kg verarbeitet und mit der 1. AR werden 1000KG mit 19% abgerechnet.

Ende Juli werden weitere 1000KG verarbeitet sein, und es folgt die nächste AR mit Angabe des seit Beginn verarbeiteten Kleber >> 2000 Kg
Diese Rechnung muss nun lt. Gesetz 16% ausweisen.

Das aber ist steuerrechtlich nicht korrekt , da ja die ersten 1000KG zum Steuersatz von 19% berechnet wurden.

Hier muß also auf dem Beleg in Zukunft unterschieden werden, wie groß der Anteil mit 16% und der mit 19% ist.
Dafür muß der Beleg neu layoutet werden, und es reicht mitnichten einfach einen Steuersatz durch einen anderen zu ersetzen, zumal diese Abgrenzung auch für den prozentualen Sicherheitseinbehalt und Nachlass auf die Auftragssumme gilt.
Beides muß auch getrennt nach Betragsanteilen und Steuersätzen aufgelistet werden.
So nun habe es jetzt doch schon erklärt


Und ja, natürlich verdrahtet man MwSt -Sätze nicht fest, aber wenn klar ist das eine Funktion nur für die zurückliegende Zeit (wo die MwSt sich nicht mehr ändern kann) genutzt wird, darf man das m.E. schon machen.

 

..so etwas in der Art hatte ich auch schon mal - versteckte Steuerelemente etc.
Leider ist es hier nicht der Fall.
Ich muss morgen mal weiter schauen.

Ich vermute es hängt viell. damit zusammen ob ein Feld eine 0 oder ein NULL "" etc. enthält. Mal schauen...
Gruß OD

 

\@Onkel Dittmeyer
Spielt doch bei der Endrechnung keine Rolle mit welchen Sätzen die Abschlags-
Rechnungen ausgestellt wurden. Die werden dann doch einfach Brutto vom Brutto
abgezogen.
gruss ekkehard