I have received a couple of emails about releasing the POS work I have
down to integrate with Satchmo. I wasn't planning on releasing what I
had done, but I'm definitely not against the idea, its just its quite
customised to the client I did the job for. Its definitely not
'pluggable' and it depends highly on the settings configuration.
Again, these aren't major issues, I'm just a little pressed for time
right now.
There are a number of 3rd party libs that I was using including my own
django apps as well as jquery plugins like tabs etc. I would have to
release my own django apps which again, i'm not against in any way,
just not too sure how useful they will be. The payment modules I have
developed I do plan on releasing, when I get a bit of time to breathe.
To give you an idea about what it is I have done, it basically
operates as follows;
1. Store staff use /shop/pos/dashboard for initial customer
interaction. There is a special privilege that can be created to
protect any pos views from prying eyes. On the dashboard you can, use
jquery tabs;
1. Create a new sale using a modified version of the
quickorder interface.
1. When submitted, this interface removes any existing
cart that might exist for session.
2. Also features modifications so that the cart is not
bound to the user of the current session.
2. View the current cart - allowing you to goto checkout
3. View recent orders, allowing you to click on an order,
displaying 2 jquery tabs as follows;
1. All details of the order, including the ability to
download invoice, packing slip, shipping slip etc.
2. Payments page listing authorisations and payments.
For each authorisation there is a button to either complete or void
the authorisation.
2. Other work includes views that essentially take over
functionality from Satchmo. I'm not sure if this is really a good
idea, my guess is that its not but it does work. Basically you can
name a view, and if you give something the same name as a Satchmo
view, and depending on where you place it in your urls, then its url
will be used as opposed to the Satchmo url. As an example, this means
that when the user clicks checkout, rather than going to the satchmo
contact creation view (via its defined url) it goes to my own defined
view which does things like ensuring that the user of the current
session is not attached to the cart. This I imagine is definitely NOT
the django/satchmo way of doings things, however it was the only way I
could, at the time, do what I wanted. If I did this again I would
probably investigate doing it differently, however off the top of my
head I'm not quite sure how I would do it, even if I caught a postsave
signal for the form.
So, if this is the kind of thing that people would like to use then
I'm happy to put it up somewhere as is. The second item in the above
list concerns me however.
Thanks
Alex
On Oct 26, 2:11 am, Chris Moffitt <[email protected]> wrote:
> Do you see any interesting information in your logs?
>
> -Chris
>
> On Sat, Oct 24, 2009 at 8:37 PM, Alex Hayes <[email protected]> wrote:
>
> > Note, just by chance I tried something then, continuing on from my
> > example above;
>
> > 13.2) If 'Save Credit Card Numbers' is False;
> > 13.2.1) Comes back to confirmation page with message 'Card Number
> > required'
> > 13.2.2) User clicks 'Purchase Items' again
> > 13.2.3) Redirect to /shop/checkout/eway/success/
> > 13.2.4) Success, thanks...
>
> > So, definitely rather strange behaviour.
>
> > Thanks
> > Alex
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Satchmo users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/satchmo-users?hl=en
-~----------~----~----~----~------~----~------~--~---
