because of MAGE price calculation complexity + EPR incompatibility with MAGE calculation, I was thinking about overriding getPrice() and getFinalPrice() methods in a way, that they will call external webservice for a requested price.
Does anybody tried to solve price calculation in a suggested way and if, does this work in a real environment?
Second option is to reverse engineer price engine from ERP in MAGE database (additinal tables + logic inside MAGE).
What do you tink? Any advice would be welcome.
I had a similar problem with complex pricing issues.
I ended up with adding some custom attribute fields that where dynamically chosen on the
customer number.
Could you give me some background on your problem?
we have very complex price calculation. Every customer has its own pricing rules(per product,per product group, special discount, etc..).
There is 15.000 customers and 60.000 items.
It is possible to add all rules into MAGE, but price indexing takes very, very long and MAGE is almost unusable. pricing engine on the other hand is not so hard to implement, but a question remain if it is possible to use price engine from ERP(ERP has API for getting a price) or is it better to implement it inside MAGE (on mysql) with extending original logic.
There is no need to have administrator GUI for checking prices, because sync is done automatically and never entered by the user. (A goal is to completely replace pricing logic from MAGE).
Thank for your answer.
After some work and testing, I did new models in Magento and reimplement price calculation logic based od ERP rules. Webservice would work, but it would be very very slow(call to getPrice or getFinalPrice is executed at least twice for every item displayed).
Related
After a basic introduction to Python thanks to an edX course and a chat with a friend who told me about Django, I thought I could implement a solution for my laboratory. My goal is to keep track of every reagent order made by everyone of us researchers to the suppliers.
After one month I have a pretty decent version of it which I'm very proud of (I also have to thank a lot of StackOverFlow questions that helped me). Nonetheless, there's one requirement of the ordering flow that I haven't been able to translate to the Django app. Let me explain:
Users have a form to anotate the reagent (one per form) they need, and then it is passed to the corresponding manufacturer for them to send us an invoice. It's convenient that each invoice has several products, but they all have to: a) be sold by the same manufacturer, b) be sent to the same location and c) be charged to the same bank account (it's actually more complicated, but this will suffice for the explanation).
According to that, administrators of the app could process different orders by different users and merge them together as long as they meet the three requirements.
How would you implement this into the app regarding tables and relationships?
What I have now is an Order Model and an Order Form which has different CharFields regarding information of the product (name, reference, etc.), and then the sending direction and the bank account (which are ForeingKeys).
When the administrators (administratives) process the orders, they asign several of them that meet the requirements to an invoice, and then the problem comes: all the data has to be filled repeatedly for each of the orders.
The inmediate solution for this would be to create a Products Model and then each Order instance could have various products as long as they meet the three requirements, but this presents two problems:
1) The products table is gonna be very difficult to populate properly. Users are not gonna be concise about references and important data.
2) We would still have different Orders that could be merged into the same invoice.
I thought maybe I could let the users add fields dynamically to the Order model (adding product 1, product 2, product 3). I read about formsets, but they repeat whole Forms as far as I understood, and I would just need to repeat fields. Anyway, that would solve the first point, but not the second.
Any suggestions?
Thanks, and sorry for the long block!
I am currently building a Django application where visitors can buy an online course. I now want to implement the possibility to provide discount codes. As these discount codes should be limited by quantity I now have the following implementation idea:
Guest visits www.page.com?discount=TEST
The model discount contains the fields discount_codes & max qty. I will check here, if the code exists. Also, I have to count all entries in my order model that used the discount code TEST. My order model contains the foreign_key field 'redeemed_discounts').
As soon the user clicks on Pay (via Stripe) I'll once again count all the orders in my order model which contain 'TEST' to make sure, the 'max_qty' is not reached meanwhile.
Now I can charge the visitor.
Would you consider this as good implemented or do you see any problems with the way I am planning to do it?
instead of using max_qty why don't you use something like use_left and max_use
so whenever someone uses that code you can reduce the count accordingly and when count hits zero you can stop using that with this approach you don't have to scan order table every time to see if the coupon code is still available.
I'm trying to figure out how companies that use nosql database solve this general nosql race condition issue:
Lucky example: User and Product. Product has quantity of 1 and there are 2 users. When the first user tries to buy this product, system first checks whether quantity is > 0 and it is indeed > 0, proceeds to create a Transaction object and decrement quantity of product. The second user tries to buy the product, system rejects as quantity isn't > 0.
Unlucky: Both users try to buy the product simultaneously. For both, system confirmed quantity is > 0 and so created a Transaction object for both users, hence destroying the company image next day...
How to generally deal with this common scenario?
From similar cases i found on the net, one suggested solution is to use request queue, and process the request one by one. However, if all transactions are queued, and you're running business like Amazon (millions of transactions every now and then), how do we expect users to know whether or not their purchase succeeded shortly after they clicked that purchase now button?
One of the ways to solve this problem is to allow both users to order products simultaneously.
Then there are two possible situations:
One of the users doesn't finish a transaction (refuses to pay, closes a browser window etc). Then another one will have the requested amount of a product.
Both users finished their transactions. Then you will get a random user your product and say sorry to another one giving away a coupon with $10 to him/her.
The second situation should happen extremely rare. So you won't blow out all your money on coupons and your users will be happy whatever the outcome. But you still need to monitor the 2nd situation in order to react and make changes to your system if it happens more often than you expected.
I'm working on a web app with a lot of data, and would like some general tech stack advice. I'm a Django developer, but I haven't worked with this much data before.
Apologies for the general question, but I'd really appreciate some general advice. If it's really not right for SO, rather than just voting to close it, I'd really appreciate a suggestion for a forum where I could ask for this advice.
My database will have three tables, one of which will have approximately 500m rows (100GB of data). The data is read-only and changes infrequently, only once a month.
The large table (500m rows) is spending items each month for the past five years, and the other tables are the institutions doing the spending (~10k rows) and the items bought (~4000 rows). The models basically look like this:
class Organisation(models.Model):
name = models.CharField(max_length=200)
class SpendItem(models.Model):
name = models.CharField(max_length=200)
class Spend(models.Model):
spend_item = models.ForeignKey(SpendingItem)
organisation = models.ForeignKey(Organisation)
spend_value = models.FloatField()
processing_date = models.DateField()
I'll need to offer pages in the web app querying aggregating this spending data in various ways. For example, I might want to show a page per institution, with the total spend for each month, and the total spend per type of item. Or a page per item, with total spent, and spending by institution.
My initial plan was to have a Postgres back-end, since I know the shape of the data, and simply make queries through the Django ORM, or raw SQL if necessary for speed.
But I'm starting to get worried: will aggregate queries be much too slow over 500m rows? Will I need to pre-calculate all the aggregate queries? Should I also be looking into other technologies that I haven't used before, like Elasticsearch, or even BigQuery?
Another concern: is a Postgres database this size (presumably ~200GB with indexes) likely to run at an acceptable speed from an SSD, or do I need to pay for enough RAM to hold it all in memory? (Eeeek.)
I know the answer really is "try it and see", but I'd really appreciate any upfront advice from more experienced Django/Postgres/data developers. If you were working on an application this shape, how would you approach it?
I may NOT have understood the problem very clearly, but here's how i would approach it.
I won't take the overhead of elasticsearch/solr just for calculating aggregates, (in my opinion, its useful when you want FTS, ranking and stuff)
I would rather have an index on processing_date and take another two fields for last_indexing_date and last_aggregate (in each organisation maybe) and update these periodically using some background async task.
For real time details I would just pick the last_indexing_date and run an aggregate for spendings beyond that date, and finally sum it up with last_aggregate and update these fields as well.
Not sure what you meant by:
Create a usable web app that offers this information to those users
Hope this helps :)
I am writing a simple JavaScript which will update my price automatically (I know there are addons but they dont work with the nature of my products) when the user enters amount, size etc etc. I want to know how do I override the product price before/after it is sent to the shopping cart?
Example: The product price is 10€. The user select some variatons and then the price is 22,40€. I want to send that price to the checkout instead of the 10€.
So far I have written my JavaScript which updates the price based on user input and selections. I just need to know how to pass that new price variable and more important WHERE.
Any tips or help would be appreciated.
You mention "variations". Are you using attributes? If so, you can simply attach a price adjustment to each option value. That would be the quickest and most proper way to handle variation-specific pricing.