[Gelöst] Buchungen und zeitliche Erfassung

Wie läuft die Buchung denn bis jetzt technisch ab?

Die Buchung läuft momentan noch von Hand ab.
Soll aber über die Webseite gemacht werden.

mit einem content_type, in dem der User das Recht zum Bearbeiten nicht hat (edit own).
Die Pakete könnten Taxonomy-Terms sein.
Da das Erstelldatum und das Pakt bekannt sind, kann eine rule das Delta berechnen.

Hallo Ronald,
Vor lauter Bäumen den Wald nicht gesehen.
Stimmt über so einen CT kann es gehen.
Pakete TaxTerms (? muss ich mir noch vergegenwärtigen)

Nur bist du noch so nett und erklärst mir was es mit der Rule Delta auf sich hat.
Mit Rules komme ich klar.
Das Delta kann ich nicht einordnen.

Danke für deine Hinweise

... So ich habe mal ein wenig herumgesucht.
Und es ergibt sich für immer noch die folgende Schwierigkeit:

Wenn ich einen CT erstelle dann kann ich den zwar "nicht editierbar" für den Buchenden setzen.
Doch wenn der Buchende eine neue Node unter diesem CT erstellt, dann wird er nach dem Titel und den Feldern gefragt und das ist bei einem festgelegten Paket sinnleer.

Ein Paket ist ein von mir vorher erstellter Node (?) und wie dem registrierten Nutzer dieses Paket zuordenbar gemacht wird ist mir immer noch nicht klar.

wenn die Pakete als Taxonomy-Term angelegt sind?

Dann kannst du festlegen, dass der User aus Dropdownliste eines auswählen kann.

Das würde doch deinen Vorstellungen entsprechen?

Wenn du weitere Infos im Paket benötigst (z.B. Laufzeit, Beschreibung ...), kannst du auch in Taxonomy weitere Felder anlegen.

Du kannst natürlich auch mit references arbeiten, was aber faktisch nichts anderes ist.

Mein Ansatz:
Einen content_type für die Bestellung, der ein Feld "Paket" enthält, das auf den Taxonomy-Katalog "Pakete" zeigt.
In diesem Katalog gibst du die Pakete ein, die dort angeboten werden sollen.

Eine rule, die von der Anmeldung getriggert wird, überprüft das Erstelldatum der Bestellung, zählt die Anzahl Tage drauf, die im Paket enthalten sind, und vergleicht das Datum mit dem aktuellen.

Und nun bleibt es dir überlassen, was dann passieren soll.

Hallo Ronald,
Danke für die ausführlichere Beschreibung.

Normalerweise habe ich mit D7 keine Schwierigkeiten.
Doch das ist eine echte Herausforderung, weil ich das irgendwie konzeptionell noch nicht verstanden habe, wie ich so etwas umsetzen kann.

Ich werde das so umsetzen und sehen wie es klappt.
Ich sage definitiv Bescheid.

ist anfangs nicht so einfach, weil man nicht glauben kann, dass es wirklich so einfach ist.

Ich empfehle die intensive Beschäftigung mit der learning library von nodeone.se

Drupal ist hochgradig relational aufgebaut.

Wenn du dir diese Denkweise angewöhnst, wirst du schnell zu entsprechenden Konzepten finden.

Danke das kannte ich noch nicht garnicht.

Meine Schwierigkeit liegt einfach darin, dass mir immer der Titel zum Ausfüllen angezeigt wird.
Und das macht bei fertigen, nur auswählbaren Paketen keinen Sinn.

Denn wenn der Benutzer ein Paket (CT: Bestellung) als neuer Inhalt anlegen muss, dann ist auch der Titel auszufüllen.
Insofern hakt es bei mir noch ein wenig.

Du kannst das Titelfeld benennen wie du willst.
Allerdings erfordert der content dieses Feld.
Welche Informationen brauchst du sonst vom Kunden?
Vielleicht lässt sich der Titel zu etwas gebrauchen ;-)
Die Position muss auch nicht zwangsläufig oben sein.
Bei der Anzeige ist der Titel jedoch in der Regel das Sortierkriterium.

Und dann gibt es da noch das Modul [do:auto_nodetitle], mit dem Du das Titelfeld verstecken und aus anderen immer auszufüllenden Feldern aufbauen kannst. Vielleicht suchst Du ja so etwas.

Naja das ist eben der springende Punkt:

Alles bei einem Paket ist festgelegt.
Der Benutzer kann nur das Paket auswählen.
Und wenn ich von einem Nutzer verlange, dass er noch ein Feld (Titel) ausfüllen müsste, dann wäre das seltsam.

Ein Paket besteht im Grunde aus:
1. Titel
2. Beschreibung
3. Laufzeit
4. Preis

Alle Felder sind ausgefüllt und vorgegeben. Und sollen dem Benutzer nur angezeigt werden - Eben analog dem Paket welches er auswählt.
Und aus diesem Grund ist mir vom Konzept her nicht klar, wie das in Drupal realisiert wird.

Hallo Werner,
ich werde mir das ebenfalls noch anschauen.

Ich glaube, dann ist Dein Ansatz falsch. Der Kunde soll einen Datensatz anlegen, aber selbst keine Eingabe machen müssen. Also solltest Du über ein vorausgefülltes Referenzfeld (Taxonony oder Entity-Referenz), dessen Inhalt angezeigt wird, die Bestellung erzeugen. Dazu könntest Du den Titel aus Kundennummer und Referenznummer automatisch erzeugen. Mit dem Submit des Kunden wird dann die Bestellung angelegt und verknüpft den Kunden mit dem Paket eindeutig.

dann ist es doch eher wie ein Produkt, das gekauft werden kann.

Commerce halte ich aber für Overkill, wenngleich dort so etwas möglich ist. Wenn du willst, dann auch gleich mit Bezahlung über Paypal etc.

Vielleicht ist der Shopansatz doch der richtige?

Moin,

1. Kannst du die Title Pflichtfeld mit https://drupal.org/project/title ausrangieren.
2. Stimme ich Werner zu, dass dieser Ansatz Käse ist. Warum stellst du die Pakete nicht einfach als jeweiligen Inhaltstypen oder anderen Entity zur Verfügung und machst das jeweilige Paket mit dem Flag Module "flagbar". Jeder Flag ist dabei eine Buchung. Flag ist hochflexibel und voll in Rules und Views integriert. Somit können die Buchungen bestens verwaltet werden und auf jede Buchung kann individuell reagiert werden.

Also erstmal zu Werner wla:

---> Nun ich hatte noch nie einen solchen Fall. Und muss mich deswegen konzeptionell weiterbringen.
---> Das mein Ansatz falsch ist habe ich keine Zweifel.
---> Aus diesem Grund habe ich diesen Thread aufgemacht.
---> Und ... Ich bin dankbar für jeden Hinweis.

Und nun zu glycid:

---> OK

---> Ja warum wohl?
---> Weil ich es eben bis dato noch nicht besser wusste.

Zu Ronald:
Commerce ist in der Tat Overkill. Und kommt deswegen nicht in Frage.

So wie ich es verstanden habe, sind dies zwei Lösungsansätze.
Also ich bedanke mich zunächst für die nette Hilfestellung.
Und werde mich die kommenden Stunden an die Sache heranarbeiten.

Mit Entity-Referenz, Flag & Co hatte ich mich noch nicht beschäftigt.

Musst ja nicht gleich pampig werden. Meine Antwort war zwar als Frage formuliert, aber mehr als Vorschlag gemeint ;)

Hallo glycid,
Sorry - das war nicht pampig gemeint.

Ist heute sehr viel Stress im Office.
Ich habe das sehr wohl als Vorschlag aufgefasst.

An glycid:
Der Hinweis mit title war schon mal sehr gut.
Das lässt die Sache doch einfacher werden.

Wegen dem Rest schreibe ich noch.

Euch Allen ein schönes Wochenende

Ich habe das mit eurer Hilfe lösen können.
Das mit den Entities war mir nicht klar.
Und die enormen Möglichkeiten ebenfalls nicht.

Geholfen hat mir diese Seite auf Drupal.Org.

Schönen Sonntag

wie wäre mit commerce?

Ich dachte bei commerce handelt es sich um eine Shoplösung.
Und da es bei der Anforderung nicht um einen Shop handelt, dachte ich, dass es eben dafür nicht passt.

Allerdings habe ich mich mit Commerce und Shoplösungen noch nie auseinandergesetzt, da dies nicht mein Gebiet ist.

Kennst du dich aus mit Commerce, caw?
Inwofern ist so etwas für mich einsetztbar (siehe meinen ersten Post in diesem Thread)

Danke für deine Hilfe

sind die Entities bereits definiert, und es gibt den "in den Einkaufswagen" Button.

Nach deiner bisherigen Beschreibung halte ich commerce auch für einen Overkill, aber Seiten entwickeln sich.

Vielleicht ist der Shopansatz nicht so verkehrt?

... meine Schwierigkeit besteht einfach darin, dass ich zuwenig von den Shop/Commerce-Anwendungen weiss.

Wie ich es oben beschrieben habe, geht es ja im Endeffekt um Buchungen.
Im Shop-Kontext wären das Produkte, die im weitesten Sinne auf Zeit hinauslaufen.
Das heisst der Shop muss in der Lage sein für das buchbare Produkt entsprechende Regeln auszugeben:

1. Produkt startet ab Buchungszeitpunkt und erhält einen eindeutigen Buchungsablauf je nach Parameter.
2. Es darf nur ein Produkt buchbar sein. Und es darf während der Laufzeit keine Buchung mehr zugelassen werden.

Wie das in einem Shop realisiert wird ist mir einfach noch nicht klar.
Ansonsten hätte ich gegen einen Shop, auch wegen den Zahlungsmodulen nichts einzuwenden.

Vielleicht schreibt hier mal einer von Euch, der commerce besser kennt, ob die Anforderungen generell machbar sind.

dafür geibts bei commerce fertige moduel

Also erstmal danke für den Hinweis.
Ich schaue mir das an.
Denn wenn ich das mit commerce realisieren kann, dann passt das auch.

Kannst du mir noch sagen wie das Modul heisst?

aber auf der Site von drupal commerce wird eine Möglichkeit vorgestellt, den Zugriff auf Inhalte zeitlich begrenzt zu verkaufen.

Du verkaufst also ein zeitlich begrenztes Ticket für eine bestimmte Rolle.

Das gleiche Verfahren (ohne die Rollenzuweisung) ist hier anwendbar.

Das ist eine Kombination eines Produktes mit einer Rule, die prüft, ob die Laufzeit noch gültig ist.

Dazu muss das Produkt eine Laufzeit haben (was ja von dir als Paket vorgesehen ist).

Nun könnte eine Rule bei der Bestellung des Produktes aus der Laufzeit des Paketes das Ablaufdatum ermitteln, und in der Bestellung hinterlegen.

Mit einem täglich laufenden Job wird in einer anderen Rule geprüft, ob der Endtermin erreicht ist.
Dort legst du auch fest, was dann passieren soll - Aufforderung zur Verlängerung oder ...

Vorteil der Commerce-Lösung ist, dass du hier auch die Bezahlmethoden nutzen kannst, also die Mietverlängerung sich beispielsweise per PayPal bezahlen lässt.

http://commerceguys.com/blog/selling-content-drupal-commerce-using-conte...

Ja, du hast den Nagel auf den Kopf getroffen, ronald.
ich werde mir aufgrund dessen was ihr hier geschrieben habt, das D-commerce anschauen und testen.
Wenn es das macht was wir benötigen, dann nehme ich es.

Was Rules angeht, funktioniert Vieles.
Allerdings mit den Rollen klappt Einiges nicht.
Eine Rolle zuweisen ja.
Eine Rolle wieder entziehen nein.

Deswegen arbeite ich mich noch zusätzlich in Rules ein.

Unabhängig dessen schaue ich mir commerce heute an.
Nochmals danke für die hilfreichen Posts

Und danke für das Video.
Scheint meinen Fall zu treffen.