I want to add our custom amount in total cart amount during checkout or payment in prestashop in custom payment module. And so can i change cart amount during checkout or payment in our custom payment module in prestashop?
There are three options I spontaneously know about:
Use an already available module for such purpose. In this case, there is in example the Additional Payment Fees module (which I use in production in a PrestaShop installation myself).
Write an additional module which can apply configurable fees on selectable payment options. This might be the favored option and bases on the same principles as the next.
Make your payment module use a specific cart rule.
I checked it again and cart rules do not appear to be a good idea for adding fees rather than discounts. In fact, the PrestaShop Back-Office does not allow to set up cart rules with negative "discounts".
These are the things to take care about:
Its best to add the fee distinct from the actually purchased products and eventual shipping costs to maintain transparency towards the customer. This might not be a technical detail, but valuable concerning user experience.
Display the additional fees for a payment type on the cart page. The hookdisplayShoppingCart or displayShoppingCartFooter is suitable for that. These hooks can also be used to initiate calculation of payment fees and storing them in association with the cart because calculation is necessary only when the customer is confronted with the choice of payment: in the cart.
Create an additional column in the cart table or alternatively a dedicated table which holds the fee information for each cart. This information must be stored permanently as it is necessary even after finished order.
Getting the cart's total value is easy: $this->context->cart->getOrderTotal(); - but keep in mind that this includes tax (provide false as first parameter). I am not sure about whether such fee must be applied to the net or gross value of the cart.
They must be visible on the invoice, too. In that case the displayPDFInvoice hook is suitable for inserting additional information into the invoice PDF.
I am sorry I did not find yet how to finally apply the fee to the cart for checkout but I hope it helps if I point into the direction of tax rules, which you could leverage programmatically for each order.
Sources
PrestaShop 1.5 documentation about hooks
PrestaShop 1.5 documentation about tax rules
PrestaShop 1.5.6.2 Cart class
Related
I am using django-stripe to generate Stripe Checkouts.
I would like to pass the Stripe fees on to my customers ("surcharging").
I found a help article from stripe regarding this. It says in general how to calculate the fees to put on top of the price of the product.
The problem is, that different payment methods have different fees.
And when creating the Checkout, I must calculate the final price (including the fees I want to pass on) before I know what payment method the customer will select (and therefore what fees the customer will have to pay).
So I don't know the fees when I must put them on top of the price the user has to pay in the Checkout.
Is there a way out of this dilemma?
Unfortunately there isn't a way to dynamically change the price based on the payment method presently. You must specify the amount to be paid prior to redirecting your customers to the Stripe Checkout interface.
You could create make your users select a Payment Method prior to redirecting them to Checkout (restricting the payment_method_types to their selection) and adjust the price based on their chosen Payment Method. But that requires a lot of work on your side and loses some of the nicest features of Stripe Checkout.
In an application that has many 'shops' every registered admin user has a 'shop' entity, each shop sells items where each item belongs to a certain 'category'. Having multiple clients (100's in some cases) each client has an account to follow up on their purchases and past orders. Each shop generates invoices for their clients, clients pays the invoice.
Admin User -- > Shop
Shop ---> clients
|-> items Categories
|-> items
|-> invoices
|-> payments received
An admin page shows a report showing invoices within the year (from Jan to Dec) this page is a client requirement. The shop is able to manually generate a new invoice when a purchase is made, and records a payment when it is paid. Note: This all happens in the actual shop, there is no online client purchases.
As a single shop generates few invoices per month (~100's), and multiple payments per month (~100's), showing this per year easily goes to thousands entities to show on a single page.
To optimize loading the page and generating the sales year report (total sales, revenue, payment...etc.), we thought we'd structure the data in a way where each item category per year is also an entity. This means that whenever a purchase is made for an item in this category, we need to add the item's purchase price to the itemCategory at that year in this month.
itemCategory Model:
itemCategory(ndb.Model):
shopID = ndb.KeyProperty()
year = ndb.IntegerProperty()
monthly_sales = ndb.FloatProperty(repeated=True) #12 months
This way we can load the entire sales table by reading just the list of itemCategory for this shop for this year, instead of reading all individual purchases through the year. This would save lots of Datastore reads and decrease page load time on the expense of an extra read, sum & write to this summary like entity.
Category Jan Feb Mar ... Dec
--------------------------------------
Men's shoes 1000 1300 850 ... 1400
Kids shoes 600 850 650 ... 900
The challenge at this point is that strong consistency is quite essential, for individual purchases and for the itemCategory entities. Because if the shop tries to add multiple purchases in a successive short timed way, with eventual consistency itemCategory might have not been updated with the last purchase sum yet. Resulting in wrong sales values. Also the same for individual purchase if there was a requirement to edit one right after it was added, a query for the entity without its ID might have no results. So it seems that Ancestor queries is essential here with maybe the shop as the parent entity. Yet, this will result in a contention issue later on (at least until Datastore is migrated to Firestore) with all those entities (thousands in this case!) having one single parent!
The same goes for invoices, generating a new invoice means knowing the latest invoice number so that they are always in sequence without gaps. Querying invoice with eventual consistency may result in duplicate invoice numbers.
What is the optimum way to structure the data at this point for strong consistency? Unfortunately the project has been there for a few years, and was started using Google Datastore rather than Cloud SQL (which seem to be more appropriate for this kind of projects). Hopefully all these issues goes away after the migration to Firestore having Strong consistency for all reads
Consider exporting the data and then importing it into a Cloud Firestore in Datastore Mode project. No more eventual consistemcy issues.
There are certain ways you can achieve strong consistency.
Query using key. Whenever you try to read an object via its key it is strongly consistent.
Another approach would be to use NDB Asynchronous Operations. See related documentation here.
A really naive approach would be to provide a delay which could help you but the delay should be provided in such a way that it is sufficient for the object to get updated.
And the final approach could be to export data into Cloud Firestore. There you can achieve strong consistency always.
Hope this answers your question!!!
Using ForeignKey relationships, I want to be able to copy data and store it in another model. For example, think of how you would handle past Invoices and billed Services.
The Invoice would have one or more Services associated with it and with prices for the Services. This prices for a Service can / will change over time - but the Service price recorded with the Invoice should remain as it was when the Invoice was created.
My first thought was to create a pdf from the resulting data and store it. But this would make the data somewhat inaccessible.
Is there somehow a way to copy the data and keep them accessible?
This is a pretty broad problem with multiple solutions. I dont think that what you're aiming to is the correct one.
One rule for saving invoices is, that invoices never change. You should never update an invoice. So not only your 'copies' of invoices should remain the same, but the original too.
Also, you should have a InvoiceItem (or InvoiceRow) model which are the items on your invoice. Don't bind Products to a Invoice directly.
Here are 2 solutions I've used:
Solution 1
You can normalize the data on your invoice(items). So, don't use foreignkeys, but normalize all data about the product, so product info (incl. price) is saved within the invoice(item).
Solution 2
Give your products revision numbers. So everytime a product is updated (name or price change for example), a new product is created in the database. Now you can link the InvoiceItem to a Product with a Foreign Key, and it will will be historically accurate.
Im sure there are some guides/best practices for creating Invoice backends. Language or Framework is not important. Invoicing is really important, so do alot of research before starting to build something. That's just my two pennies
I would like to get shipping costs of an order. I can get amount, customer information, purchase date of an order... but where is the shipping cost?
Any code or link would be very helpful.
Thanks.
Assuming that you are using the Orders API, the shipping charges for each item are stored in the shippingPrice property of the OrderItem type. You need to use the ListOrderItems operation to retrieve the order's items.
See page 26 of the Orders API documentation for a description of shippingPrice property. See page 25 for a description of the ListOrderItems operation.
I'm looking for advice on best practice for annual subscription management where the fees may change each year.
I have a Membership and MemshipYear models as well as the User models. Each membership category (membership.category) has an annual fee which may be different. Members will be able to download pdf invoices for membership fees at any time once logged in.
The pdf is generated at the time of request and the data is taken from the membership model. Therefore if the membership fee changes after one year the invoice would be caluclated with this figure and not the fee for that year.
One thought I had was to use price banding i.e A-F, and have a price band for each category for each year.
I reckon there's a better way.Anyone?
Logically, the membership itself should have a price, since that inherently belongs to the user. On creation, you would set this value from the category. Then, whenever you need to get the current price the user is paying, you pull it from their membership, instead of the variable price on the category.