Upgrade Birt

[golfsailor]

are you considering upgrading Birt ?
I have some nice reports with birt version 2.3.1 wich I will be happy to submit.
Best regards

[Brian]

Hi,

We haven't got an upgrade in our immediate plans however I'm sure you're aware (you've probably already done this!) that you can use another version of Birt to the one we ship very easily.

If you have some interesting reports that you are willing to contribute that would be great!   Please post them to the contributions section.   

We'll take another look at our plans with regard to upgrading Birt...

Regards,
--Brian

[golfsailor]

Actually upgrading Birt is easy, and the new version is working much better. (At least a lot
easier to make new reports).

I guess there is a problem with the product attribute / option structure. Now the prices goes into the system per option or attribute, but the numbers (quantities) in stock is per combination..... and the prices may vary with the combination of options. Now there is a way around, (new product instead of option), however not a nice way. The right way should be to enter prices for the combination, which in turn causes a minor change in the price calculation routine. Any idea ?

Best regards

[julie]

Hi,

I'm not sure I understand the scope of the problem. Is it that the database structure makes it difficult to write certain BIRT reports ?

[golfsailor]

Hi again,
no problem getting the reports. The problem is a application problem which might depend on the db structure.
When entering product attributes / options there is 2 levels. Then when using this structure and
entering prices the application puts the prices not in a tree but in the flat structure. (The price is entered flat on the last level). However, the quantities is entered in the tree structure which makes the quantities take notice of the combination. For example : I have a lamp with E14 Socket and E27 Socket the price 1 and 2. Then the lamp could also have different color like red blue and so on. Each color have a different price adjustment like 1, 2 and 3. Now, the stock contains as it should the relevant quantity for each combination but the price will not be able to change for a certain combination. Let's say red should be cheaper with the E27 Socket.
Best regards

[julie]

Now I understand 

This is the way it was designed. What you suggest may be a little more flexible for some cases, but it is also more difficult to maintain since you have to enter a price (or multiple prices) for every combination.

Actually, in your example the lamp socket and color aren't real independent options since they aren't configurable independently. It would be more correct to create a list of combined options for which you can store the quantities in stock and a price adjustment. i.e.

Red E27
Blue E27
Red E14
Blue E14

[golfsailor]

Hi Julie,

well the 'problem' is that we have a system with the quantities for every combination, to keep track of the store. Pricing is not on the same level. We could say some products will be priced by the system not by the shop owner .... Of course instead of two products with 4*4 options we will have 16 products....

So, you are right, if there is no change in the system we have to find the solution somewhere else. If the design have some flaws, your system could be better than osCommerce changing them 

(The most flexible solution would be to add the price data in the Quantity table, or to keep the osCommerce compatability, add a new one... )

Best regards

[julie]

If the design have some flaws, your system could be better than osCommerce changing them 

We've moved away from osc compatibility a long time ago for all of our enhancements (i.e. promotions, cust groups, merchandising, multiple images, product tags, returns etc.) . When we decide to enhance the product with a new feature, it's either because we feel that this feature is required by the market or because we have many requests for it. At the moment you are the first and only person who has found this to be a problem as far as I am aware, so it won't be on our general roadmap for a while.

If you require it for your particular business and you'd like to use KonaKart, we can analyze it for you and offer you a fixed price / time quote. Please contact support at konakart dot com for that.

[golfsailor]

Hi Julie,

ok when we need the change I will contact you. I just thought the situation
having products with "automatic" prising is no good, and the system do keep track on the quantities in the right way. So I thought you was not aware of it and would consider correcting the bug for the next version 

Best regards
golfsailor

[julie]

As I said, it isn't a bug since it was designed that way and it only seems "no good" for you. We actually prefer the way it works at the moment where the system calculates the price rather than your suggested modification where the merchant would have to enter all of the prices for all combinations. Therefore we have no intention of changing it for the mainstream product.