Ihre LimeSurvey-Version: 5.3.8
Eigener Server oder LimeSurvey-Cloud: Eigener Server
Genutzte Designvorlage: keine
==================
Hallo,
ich bin in einer Solidarischen Landwirtschaft tätig. Einmal im Jahr gibt es eine sogenannte Bieterrunde in welcher die Mitglieder auf z. B. einen Gemüseanteil bieten können.
Hier ist es aber nicht so das der Höchstbietende einen Anteil bekommt, sondern das die Preise solidarisch verteilt sind. Das heißt Leute mit geringen Einkommen können weniger bieten und Leute mit hohem Einkommen eben mehr. Im Durchschnitt liegt dann (hoffentlich) bei dem Preis den der Landwirt pro Anteil benötigt um ordentlich zu wirtschaften.
Letztes Jahr haben wir da erste mal eine digitale Bieterrunde mit Limesurvey gemacht.
Die Umfrage hat eigentlich wunderbar geklappt, allerdings hat uns die Auswertung einiges an Zeit gekostet.

• Ich hätte gerne das man mit so wenig Aufwand wie möglich einen Durchschnittswert der Kisten bekommt von allen abgegebenen Geboten. Wobei ein kleiner Anteil nur zur Hälfte gezählt werden darf.
• Wenn ich einen kleinen Anteil auswählen wird mir kein Preis im gesamt Betrag angezeigt. Wie sollte die Formel aussehen?

Ich habe mal meinen ersten Ansatz angehängt, dann wird das eventuell deutlicher. Oder ist der eventuell komplett falsch und ich sollte es anders machen?

Danke und Gruß, Jan

Hallo,
erzähle doch bitte einmal, was Du Dir unter dieser Gleichung vorgestellt hast.
Was soll sie machen?

{(SO2021GEM2_SQ001 * SO2021GEM3) or (SO2021GEM3)} 
Dies ist zunächst einmal nur ein logischer Term, der Wahr oder falsch ist; er könnte beinhalten (72 OR 24).
Also das geht so nicht.

Außerdem: In SO2021GEM1a hast Du als Codes "AO01" und "AO02" benutzt, dann aber zusätzlich Bewertungswerte (1,2) genommen, diese aber nicht angesprochen.
Siehe [url] manual.limesurvey.org/ExpressionScript_-...#Access_to_variables [/url]
Warum nimmst Du nicht gleich 1 und 2 als Codes?

So, kommen wir zum Schlussakkord:
Dein Preis wäre:
Entweder er kauft ein kleines Gebinde, dann ist es einfach SO2021GEM3
oder er kauft ein großes, dann muss er noch die Anzahl angeben, also SO2021GEM2_SQ001 * SO2021GEM3
Wieso ist denn SO2021GEM2 eine mehrfache numerische Eingabe; es wird doch nur der Gemüsepreis eingetragen.

Wenn Du den Preis ausrechnen willst (ich nehme jetzt als Codes 1 und 2)
{if(SO2021GEM1a==1,SO2021GEM2_SQ001 * SO2021GEM3,SO2021GEM3)}

Wobei mir die Logik nicht besonders klar ist. Wieso soll ich nur, wenn ich einen großen Anteil haben will, die Anzahl angeben?
Aber das ist Eure Sache.

Nur: Warum müssen es immer so lange Fragencodes sein?
SO2021GEM2. Dass es 2021 ist, muss doch nicht in jeden Fragecode hinein, und GEM für Gemüse geht auch kürzer. Eigentlich reicht G1, G2, G3,... für Gemüse, O1, O2,... für Obst, F1, F2, ... für Fleisch, usw.

Und bei diesen drei Fragen gibt es drei verschiedenen Fragetypen. Das verwirrt das / mein Auge
Warum nicht so?
 


Gut, und dazu

• Ich hätte gerne das man mit so wenig Aufwand wie möglich einen Durchschnittswert der Kisten bekommt von allen abgegebenen Geboten. Wobei ein kleiner Anteil nur zur Hälfte gezählt werden darf.

solltest Du einmal das Plugin "getStatInSurvey" ansehen; damit kannst Du über alle Teilnehmer einen Mittelwert errechnen. Noch etwas Vorarbeit in versteckten Fragen wegen des "kleinen Anteils".
[url] github.com/SondagesPro/LS-getStatInSurvey [/url]
Aber das ist Deine Arithmetik.

Joffm

Danke für deine Antwort.
Hab das jetzt mit deinen Tips erstmal umgebaut. Nur Buttons genutzt und Fragencodes gekürzt. Ist tatsächlich schöner mit zu arbeiten
Ich muss gestehen das ich keine Ahnung haben wofür die Bewertungeswerte sind und hab da beim rumtesten einfach was eingetragen.

Wieso soll ich nur, wenn ich einen großen Anteil haben will, die Anzahl angeben?

Weil zwei kleine Anteile ein großer wären

Das Plugin gucke ich mir mal an, Danke.
Zum Verständnis: Versteckte Fragen sind nur für mich als Hilfe. Also eine Art Merker, richtig?
Hab meine bearbeitet Gruppe mal angehängt.

Weil zwei kleine Anteile ein großer wären

Ehrlich? 
Nein, meine Idee war:
Ich möchte 1,5 Kisten haben. 1 große und 1 kleine. Das kann ich so nicht eintragen, da groß/klein alternativ ist.
Also nehme ich 3 kleine.
Ich weiß auch nicht, wie das ausgeliefert wird. Vielleicht hätte ich lieber jede Woche eine kleine, weil eine große ist mir zu viel.
Daran solltest Du Dich auch nicht aufhalten; Ihr wisst, wie alles funktioniert.

Zum Mittelwert:
Ich werde einmal etwas erstellen, und es dann als aktivierte Umfrage veröffentlichen.
Dann kannst Du sehen, was möglich ist.
Kommt dann später.
Und wenn Ihr dann das Plugin installiert habt, kommt auch die lss dazu.

Zu den Bewertungswerten:
Meiner Ansicht nach stammt dies aus alter Zeit, als es noch kein ExpressionManager/Script gab.
Die Geschichte mit den Bewertungsregeln usw. sollte man gar nicht erst anfassen. Das ist Schnee von vorvorgestern.

Aber die Bewertungswerte haben trotzdem noch eine Anwendung.
Man kann ja keine negativen Codes vergeben, und auch nicht zwei Antwortoptionen denselben Code geben.
Wenn ich dann einen Score über mehrere Fragen bilden möchte, kann ich im einfachsten Fall einfach die Codes addieren "sum(Q1.NAOK,Q2.NAOK,Q3.NAOK)" 
Was natürlich bedingt, dass die Codes numerisch sind.
Beispiel wäre hier Deine Frage G3.
Du hast Textcodes genommen, mit denen man schlecht rechnen kann.
Hättest Du hier Codes genommen, die die Anzahl repräsentieren, wie 1,2,3,... hättest Du nicht mithilfe der Property ".shown" auf den Text der Antwort zugreifen müssen
Die Gleichung wäre dann einfach "G3*G4".
Ich persönlich finde es ziemlich idiotisch, diese alphanumerischen Codes als default anzuzeigen. Zum Glück kann man es seit einiger Zeit in den "persönlichen Einstellungen" ändern.
Was glaubst Du, wieviele unserer User haben diese blauäugig benutzt, und sich dann später gewundert, dass sie damit keine statistischen Werte rechnen können.

Falls aber mein Algorithmus für den Score vorsieht, dass manche Antworten denselben Wert haben, manche eben negativ sind, wie hier
 
kann ich diese Bewertungswerte nutzen und dann mit einer anderen Property auf die Frage (auf diesen Wert) zugreifen.
Die Summenbildung sieht dann eben so aus:
"sum(Q1.valueNAOK,Q2.valueNAOK,Q3.valueNAOK)" 

Das hast Du ja bereits im bereits verlinkten Artikel des Handbuchs gesehen.

Und versteckte Fragen sind durchaus mehr als eine Hilfe.
Hier werden meist Berechnungen durchgeführt (Fragen vom Typ "Gleichung" werden meist versteckt), oder es wird javascript Code ausgeführt, welcher ein Ergebnis hat, welches wiederum irgendwo gespeichert werden muss (oftmals in Fragen vom Typ "kurzer Text")
Also wichtige Sachen für den Programmablauf, die aber keine Fragen an den Teilnehmer darstellen.

Und bitte, niemals lsq oder lsg Exporte, nur lss.
Begründung:
lsq und lsg Exporte sind sprachsensitiv.
Man kann sie nicht in eine Umfrage mit unterschiedlicher Basissprache importieren (selbst deutsch und deutsch-Du geht in die Hose)
Also müssen wir hier zunächst eine Umfrage neu anlegen, die Basissprache des Exportes erraten, um dann importieren zu können.
Erspart uns diese Mühe. Wir machen diese Arbeit alle freiwillig in unserer Freizeit.
Daher immer einen lss Export schicken.

Am besten:
Die Original-Umfrage kopieren, alle Gruppen / Fragen entfernen, die nichts mit dem Problem zu tun haben (aber auf gesetzte Filter achten), und diesen Rest dann als lss Export schicken.

Joffm

Hättest Du hier Codes genommen, die die Anzahl repräsentieren, wie 1,2,3,... hättest Du nicht mithilfe der Property ".shown" auf den Text der Antwort zugreifen müssen

Ah, auch gut zu wissen! Hab ich geändert.
Dann mache ich mir mal ein paar Gedanken ob ich nicht auch schon was mit den Codes auswerten kann, was mir mit der Auswertung hilft.

Das Plugin hab ich installiert und werde damit mal ein wenig rumspielen.
Das Angebot mit dem Beispiel nehme ich gerne an.

Und bitte, niemals lsq oder lsg Exporte, nur lss.

Wusste ich auch noch nicht. Wird gemacht
Aber nochmal vielen Dank für die ganzen Infos. Haben mir schon viel geholfen!

Gut, wenn Du das Plugin installiert hast, kommt hier gleich die lss eines Beispiels.
 
Ich habe einige Codes geändert, damit man besser damit rechnen kann.

Es ist zu beachten, dass

• diese errechneten Mittelwerte und übrigen Infos nicht im Datensatz erscheinen
• alles natürlich nur in einer aktivierten Umfrage funktioniert
• für eine Trennung nach Anteilsgröße dies auch in den Fragen G3 und G4 geschehen müsste

Ich weiß aber auch nicht, ob Du dies überhaupt den Teilnehmern zeigen möchtest, oder es nur für die Auswertung verwenden willst.
  
  

Dann mache ich mir mal ein paar Gedanken ob ich nicht auch schon was mit den Codes auswerten kann, was mir mit der Auswertung hilft.

Selbstverständlich; diese Gedanken muss man sich wirklich vorher machen.
Denn die Codes werden ja schlussendlich in Dein Auswerte-Tool exportiert.
Beispiel: Ich frage nach der Häufigkeit eines Kinobesuches mit den Antwortmöglichkeiten

1. einmal pro Woche
2. einmal pro Monat
3. einmal pro Quartal
4. einmal im Jahr

Wenn ich jetzt diese Codes 1,2,3,4, benutze, habe ich gerade einmal die Häufigkeiten der einzelnen Optionen
Wenn ich aber so codiere
52: einmal pro Woche
12: einmal pro Monat
4: einmal pro Quartal
1: einmal im Jahr
kann ich mit dem Mittelwert schon einmal eine rohe "mittlere Häufigkeit pro Jahr" errechnen.

Dann ist die Auswertung z.B. in EXCEL auch recht simpel:
Du hast in je einer Spalte

• den Code für die Größe  (1,2)
• den Code für die Menge (1,2,3,4,5)
• den Preis für einen Anteil

Dann brauchst Du nur noch zu multiplizieren und zu summieren.

Joffm

Oh super. Vielen Dank.
Damit kann ich was anfangen. Wenn ich fertig bin, zeige ich mal das Ergebnis. Eventuell kann das dann auch jemand gebrauchen.