Let's say we have invoice number #1 then invoice #2 but then I need to have a credit memo with number #3. After that of course I will need an invoice with number #4.
Is this possible?
No is the simple answer. Invoices, Credit Notes, Orders, & Customer Increment ID's have their own numbering system. The last increment ID for each object type is stored in the table eav_entity_store (take a look). You could override the class Mage_Eav_Model_Entity_Type and function fetchNewIncrementId() to possibly achieve what you are trying to do, but generally it's good practice to have sequential numbers for each object type and not share the numbering system between different objects. Auditors for example will want to see sequential order numbers and sequential invoice numbers otherwise it's easy to fiddle the books as it's difficult to work out if an invoice was deleted etc. I would check with accounts and auditors first to see if your allowed to do what you want too first.
Related
We car planning to store prices data to Memcache. prices are subject to car variant and location(city). This is how it is stored in the database.
variant, city, price
21, 48, 40000
Now the confusion is that how do we store this data into Memcache.
Possibility 1 : We store each price in separate cache object and do a multiget if the price of all variant belongs to a model need to be displayed on a single page.
Possibility 2 : We store prices at the model, city level. Prices of all variants of a model will be stored in a single object. This object will be slightly heavy but multiget wouldn't be required.
Need your help in taking the right decision.
TLDR: It all depends on how you want to expose the feature to your end users, and what the query pattern looks like.
For example:
If your flow is that a user can see all the variant prices on a detail page for a city, then you could use <city_id>_<car_model_id> as the key, and store all data for variants against that key (Possibility 2).
If the flow is that a user can see prices of all variants across cities on a single page, then you would need the key as <car_model_id> and store all data as Json against this key
If the flow is that a user can see prices of one variant at a time only for every city, then you would use the key <city_id>_<car_variant_id> and store prices.
One thing to definitely keep in mind is the frequency with which you may have to refresh the cache/ perform upserts, which in the case of cars should be infrequent (who changes the prices of a car every day/second). So, I would have gone with option 1 above (Possibility 2 as described by you).
I'm using Expresso-Store to process product orders for a non-profit. In addition to selling a range of handmade products we are offering visitors an option to donate.
I have most of the donation stuff working just fine. I used Justin Long's advice posted here: http://iamjustinlong.com/blog/single/accepting_donations_with_expresso_store/
As suggested I have created a channel for all the products and then a separate channel which holds a single "Donation" product with a cost of $1.00. The visitor adjusts the quantity of this item which results in a donation amount of $1.00 * qty.
The specific problem I'm running into is displaying the total quantity of items in the cart when there's also a "Donation" product added. Since the donation amount is determined by quantity * $1.00 but in reality it represents a single donation, my {order_qty} is way off since it includes the many multiples of Donation products.
I have a small cart icon that is displaying a number above and next to it with the {order_qty} but I need to exclude the donation product from this calculation. How might I go about this?
This would be fairly difficult to do using the current version. The best I can suggest is not to display the {order_qty} on your checkout page (most sites only display the total anyway).
However, in saying that, the next version of Store has first-class donations support, so it will soon be possible.
In one magento store that I am working at I got some problems with orders (the problem was generated by the fact that magento was by default rounding prices at a precision of 2 while 4 was necessary an taxes too).
I have fixed this problem so the new orders are stored with the corect sums, but there are some orders which need some recalculation.
One approach is to loop through orders and order_items table and set the correct sums.
But there are a lot of columns and some of them aren't very self speaking about what they represent (like hidden_tax_amount).
I know for sure that original_price and tax_percent are correct, then I have the quantities, so I belive some recalculations could be done easily, but only if I would know the rules.
So, do you know it?
Mage_Sales_Model_Quote has a method collectTotals(). This method is used to calculate all the price and tax data. Orders are created based on quote (most of the data is just copied from quote to order). This is difficult to recalculate all order data.
You can take a look at Mage_Sales_Model_Service_Quote class and its method submitOrder().
Or you can try to load order, then get its quote ($order->getQuote()), then run collectTotals() on $quote object. Finally in a foreach like loop you can copy desired values from quote to order. Don't forget to save() both objects.
I want to be able to send different order confirmation emails to new customers than to established customers.
I am already able to put a block in the email template to insert my own 'if' constructs based on order details.
I can get the customer data from the order id, e.g. the customer id, but how can I determine if they are a new customer?
Even if it is getting the customer creation date and checking if it is less than five minutes, I need a technique to determine if they are new from within my template code based on the order information.
Either way your going to just have to do calculations on created_at field in the customer_entity table. If not your going to have to find some specific window to consider customers as "new".
Don't think I'd put said logic in the template file but rather a model and just pass it a block to flag it or not.
I have a situation:
I have products that are in a CodeIgniter Cart custom store.
Each product has an ID associated with it, but also has options for it (sizes).
These sizes all have different prices. (We're talking about photos being sold at different print sizes).
Because CI Cart updates, adds and deletes based on the product ID inserted, I am not able to insert one product with 2 different sizes.
As of now, the only solution I can think of is to pass the ID to the cart as IMAGEID_OPTIONID so that it contains both IDs.
However, I thought there might be an easier, more uniform way of doing this?
Or a better solution than an ID that isn't (on it's own) associated with anything specific unless i explode it..?
I recently built a site that had these constraints. In short, you'll want to create a distinction between "products" and "product groups". Think of it as managing the most discrete data units. In reality, shirt X sized medium is actually a different thing than shirt X sized large...doubly so if you have prices that are built on these qualities (this becomes more realistic when you consider cloth patterns or colors).
So anyway, if you have a "groups" table, a "product_groups" table, and a "products" table, you can keep all of these ideas distinct. On your products table, you can have columns for "size" and "color" (and any other distinguishing property you can think of) and a column for "price". Alternatively, you can go even more hardcore and make separate pricing tables that match up prices to unique products (this would be especially useful if you want to keep track of historical prices and discounts).
Then in your cart you can simply attach product_ids to cart_ids and perform a couple of joins to determine what "group" this product is a part of, what pictures are in that group (or exist for that product), and so on. It's not a simple problem, but following this line of thought should help get you on the right path.
One last point: keeping track of unique products like this also makes inventory accounting much, much more straightforward.