Oxprices module

English forums
1

Hi there :slight_smile:

As a total newbie, I am supposed to create a kinda module to handle prices differently. It should enable shop admins to enter multiple prices with a from-date and the shop should then process the price according to the current date (this is also required for statistics purposes, so all prices have to be documented, the solution with updatepricetime in the oxarticles table is not enough). So, there I go, creating a new table for prices and adding a field in the oxprice2article table to hold the priceid + adding a tab in product management in backend to view & manage these (product prices + scale prices / period). This is the point where I have to get the shop to process my table when loading prices instead the oxarticles table. I was kinda thinkin that oxarticle would be the only class to fiddle with (override some functions), but I’m not quite sure about this. Any ideas guys if there is anything else I should be aware of or if I’m approaching this whole thing from the right angle at all?

Another thing, this should be for a PE, but I only have CE to test on. Are there any differences in the core? I’ve never seen a PE to be honest, so I have no idea which parts are encrypted, but I’m guessing the templates are freely customizable (including admin templates)?

:-] Thanxx

Oh, I forgot: can anyone tell me something about oxvarminprice field (oxarticles table)? For parent articles, oxvarminprice is the same as oxprice and for variants oxvarminprice always stays 0. What is it good for?

2

in case of module development there are no relevant differences between CE and PE (i develop modules for our PE shop in a CE shop, too)

the table oxprice2article is for staggered prices, so i think its the wrong way to use this table.

in my oppinion, you should never change a runnig system, it means: use a module only if you cant reach your aims without it. Whereever you change the default functions with a module, there are relatively huge potential for bugs and errors.

In your case, i would try this things:
if there are just a couple of articles, i would use actionos to change prices. There you can benefit from the “active from - active to” system and you can assign articles you want to this action.

also you could create multiple articles for one product with different priceces, which are “acrive from - to” and covers this way all the price changing thing.

or… perpahs an ERP system can support such a price changing structure.

3

Danke Mann :slight_smile: Ich hätte schon fast gewettet daß wenn überhaupt jemand reagiert, bist du es :smiley:
anyway, english is easy(er) so here I go again:

the table oxprice2article is for staggered prices, so i think its the wrong way to use this table.

i didn’t get that… what do u mean by staggered prices? staffelpresie, right? what do u mean by wrong way to use it?
this thing should enable saving arbitrary number of scale prices per price (price period), not per article, which is why i added a field. i realize that loading the relevant scale prices per period is something that i would have to take care of as well.

if there are just a couple of articles, i would use actionos to change prices. There you can benefit from the “active from - active to” system and you can assign articles you want to this action.

Is that the Discounts (Rabatte) thing that u mean? that would mean going in to the discount menu for each article and setting up a discount for each of them + for each pricing period separately, if i’m not mistaken.

also you could create multiple articles for one product with different priceces, which are “acrive from - to” and covers this way all the price changing thing.

sounds good. this whole thing is actually supposed to be also relevant for statistics purposes where the company can follow a certain article, its sales and prices, blaablaa… I’m not sure what the implications of splitting the product into X articles would be… Except that, it is the client’s wish to be able to administer a product’s prices in a nice easy fashion, without having to click his way through a million pages and repeat steps along the way… although i’m not sure how creating multiple articles per product is done, but i’m guessing the beloved client wouldn’t be too happy.

All in all, I am not the admin-to-be of this shop, I am just a miserable very junior web developer, and this thing has to be done, period… C’est la vie…

Well, I realize it could get megabuggy, which is why I will need any help available :smiley:

4

how will you collect the statistics? based on article number or oxid? you can have multiple artciles with same article number (so if your statistics are based on article number, there is no problem).

e.g. you want to sell a Car. Lets say:
in january it gonna cost 25 000 euro
in february it gonna cost 23 500 euro
in march 21 234

now you can create an article “car”, it costs 25k euro and the article is active from 1st january up to the 31th january.
now you copy this article and just change it to be active from 1st february up to 28th february and costs 23 500 €.

this way the first article would “disappear” at the night between 1st january and 2nd february and the second article will be active.

will your articles get absolute or percentage scale prices?

5

emmm… i’m looking and looking… can’t see any setting for active from and to dates

6

ok i see what u did there :smiley:

click Master Settings -> core Settings -> perfomance
and check there "Check “Active From/To” when loading Products"
click “save” below

go to: administer products -> products
now you can choose between “active” and “active from … to…”

7

Whats wrong with the feature “update price on a defined time”? No need to work with multiple copies of items with different prices and “active from / to” for achiving this.
Prices are stored in old orders (unless you recalculate them). Will there be no ERP behind the shop storing order history and other customer related things like invoices and so on?

8

Good morning…

Well, it is all nice the way you peeps describe it, but I don’t seem to have the choice to get the whole thing out of the way this easy…

First of all, there is a need to store different purchase prices (einkaufspreis) with different dates. And then, if over a period of time, a certain article didn’t sell at all, not a single piece, there is no order to read the selling price for this period from, but they still want to be able to access this price (don’t ask me why).

Here’s what I thought I could do and please do correct me if I’m on the wrong track:
I have this additional tab where the admin can enter the product prices per period, and store them in the additional prices table. I wanted to extend the oxarticle class to read the prices from this table instead the article table, and originally I thought all other classes use an oxarticle instance when accessing any article properties, but that is not the case. Only God knows how much of the whole system I would have to overwrite to get this thing working this way. So, I’m thinking, I could use my new table just as a price/date storage for the statistics that we will later have to build, and adjust a certain function in oxarticlelist, which deals with setting the update price to the given date (the backend option to update price at a date-time of choice, which would of course be blended out). This function at the moment does following: it checks the db for articles with an updatepricetime that is older than now() and overwrites the prices with the updateprices. Now if I alter this function to check the dates from my table and overwrite prices in the oxarticles table with those from my table, wouldn’t that be a solution? This function is used by classes oxshopcontrol, oxmaintenance, and is executed on a regular basis + on random shop access from a user, that is what the comments said. So, what do u think? :slight_smile:

9

Sounds good :wink: