I talk to many small businesses and start-ups who have basic needs for setting a minimal erp+e-shop to start their activity.
By minimal, I mean they sell a small number of products with few variants, and buyers need a cart and a portal to follow their order and billing, ideally on-line payment. They all know they will later have to pay more to adapt to their growing business.
Today we don’t have this kind of “off-the-shelf” e-shop to start with.
Would such an entry point e-commerce solution be of help for you too in closing new contracts or improving the way you use Tryton ?
Does it make sense from a technical standpoint ?
Would it be worth a funding campaign ?
I think we still miss an important module to be able to have a e-shop build on top of Tryton out of the box. It is payment module for e-payment and it is sets of services support (like paypal, stripe etc.).
Otherwise I think a minimal website could be built using flask-tryton (and the all Flask ecosystem).
And to be complete, we have already the module web_user to manage authentication and it will also require a module for the cart (POC: https://tryton-rietveld.appspot.com/6351002/).
I am interested in this. Mostly the payment gateway part, but also the e-shop part as I am looking for something simple.
I am actually going to build a new payment gateway module from the end of next week that will specifically target Stripe as the payment gateway, so happy to contribute to this activity.
Until now I had been looking at using Openlabs/Fulfil.io’s modules, but these are not suitable because they require PCI audit as the credit card information still passes through Tryton servers. My module will only store a “token” for a customer and a card that can be used to charge the card.
I was actually discussing this just the other night with Cedric. One particularity of my usage is that I use a web client as a Tryton client so I can using the stripe.js method to communicate with Stripe directly from the client.
thank you.
one of my problems is that I don’t know how it should workb because I’m missing basic culture.
I guess it is different if we consider paying a supplier from Tryton server or getting paid by a customer. I was thinking that paying solutions may already exist outside Tryton. Can you elaborate on the dev you plan ? and if Sharoon or someone can advocate Nereid’s choice, I would be very interested in balancing/understanding the stake.
I propose we discuss several aspects of this topic, but not only:
Is there a requirement ? I guess yes but the more people will confirm their interest, the better
what would be the minimum shipping criteria, the most basic solution which could fit for some part of the “market”
then we may call for propositions so the most clever of us will be able to plan and fund a project, either point product or solid basement for Tryton architecture.
Indeed this is not so different. And both cases are managed by the module account_payment but this module needs to be extended to add support for different methods/protocols. Currently we have only the SEPA protocol but support for Stripe or Paypal should not be difficult.
I’m sure to understand what you name solution. But any external solution should at least fill payment data in Tryton.
Of course for payment on e-commerce, it is better to rely on external providers like Stripe to actually process the payment with their UI/API. But they still have to be integrated into Tryton.
I think they should be use the account_payment module as all the current states will be enought to know the state of the remote payment. The other fact is in ecommerce normally each payment is payed separately so I doubt if it has sense to group them.
I’m wondering if anyone wil require to create the payment before the invoice if it’s created. In this case, the payment should be created without any oriign, and then linked receivable line to know it have been payed.
I actually don’t understand the functionality of the account_payment module. What is a business example to use this?
In my experience every business tracks payments with invoices/bills in their accounting software solutions. Also, in terms of payment gateway usage, I cannot think of scenarios where payments won’t be made against a particular invoice. On a web shop a customer will be charged on an invoice, and at a point of sale the customer will also be charged on an invoice.
BTW: You can generate a payment not linked to any move line (an then not linked to any invoice)
The main usage is to generate a SEPA (European Standard Format) file that you send to your bank to request that you must charge to the into it’s bank account some abount.
So we are an accounting software, so we must take care of the accounting part too.
I yes, I have normally seen that the payment is linked to an invoice, but I’m wondering if there is people that have the case that the invoice is not created until the payment is fully accepted, that’s why I’m asking here.
I’m not sure if it’s an error with discuss, but I don’t know what the why is in relation to because my comment you have responded to is not a negative.
If are you asking why not grouping - it’s because I just couldn’t recall ever using this. However, I have just realised that in Australia we do have a similar system that I just hadn’t used it - it’s called the ABA [1]. So does this mean that a group corresponds to a file with a list of payments?
I understand that Tryton allows the creation of payments and does not link them to invoice ( in regards to the module account_payment and the payments model ) - to me this seems wrong and this is why I am not sure about using the account_payment module as a “base” for a payment gateway module.
Good point about the invoice generated only after a payment is fully accepted, but I don’t have experience of this. The payment is usually accepted as successful, although usually it will go through a “clearing process”.
Sorry I understood the other way arround. Everything is clear now. [quote=“vincent, post:11, topic:217”]
I understand that Tryton allows the creation of payments and does not link them to invoice ( in regards to the module account_payment and the payments model ) - to me this seems wrong and this is why I am not sure about using the account_payment module as a “base” for a payment gateway module.
[/quote]
It’s an opt-in, so if you want to link it with invoices is possible via the move line, which will be linked to the invoice. So I think it’s the right way as it may fit both possible scenarios.
The main goal about using account_payment module is to provide a common basis to manage all payments in the system. In this way, user will be able to switch from one service to another without pain nor losing history.
Then developer will process one payment at a time. That’s not a problem.
If your move is created with the account_invoice it will be related to the invoice via the origin field, so it’s move_lines are (indirectly related to the invoice too), via the move origin field. Then you can create a payment for each of this moves (that are the payment moves of the invoice), and you have the payment related with the invoice.
I hope I explained it well, as maybe it’s a little bit complex.
I do get the move related to invoices. And at the moment I use InvoicePaymentLines to find payment moves related to invoices. But I don’t see how the payment or the payment moves are related to the invoice moves.
I just tried using account_payment to pay an invoice, but I must be missing something because I don’t get any moves created.
You don’t pay the invoice directly, you create a payment related to the invoice payment lines. As the payment is related to the move_line, and the move_line is related to the invoice, the payment is (indirectly) related to the invoice. Something like:
Going back to the main topic, I’m wondering where the payments (and the invoice if any) will be created. Same for the shipments required to send the goods.
Very interesting topic for me.
The only point that prevent me from switching to Tryton and this easy e-commerce possibility.
Nereid seemed to be a good start as far as I could play with the demo, but development seems to be stopped.
I found that http://fulfil.io is maintaining and/or continuing the development of nereid. They have made a webshop app and other tryton modules in order to have a fully functional e-commerce backed by tryton, including shipping and payment integration. Check their github repos.