Recommendation im Eigenbau, nicht nur für Magento

veröffentlicht in Consulting,Software Engineering am 16. Jun. 2014 Tags: , ,

Ist der Shop einmal aufgesetzt, fragt sich jeder Shopbetreiber wie man den Umsatz steigern könnte. Dafür gibt es viele Ansatzpunkte. Zum einen könnten durch mehr Werbung mehr Besucher auf die Shopseite gelenkt werden und zum anderen könnte durch eine Optimierung des Shops die Konversionsrate gesteigert werden. Es geht also darum, aus Besuchern Kunden zu machen. Diese beiden Ansatzpunkte sind Prozesse, die jeder Shopbetreiber beherrschen sollte, wenn er seinen Shop voranbringen will.

Ein weiterer Ansatzpunkt, ja sogar die Königsdisziplin, ist den bestehenden Kunden noch zu optimieren, um z.B. den Warenkorbwert zu steigern. Hierbei bietet sich Recommendation-Engine an. Dem Kunden werden so Cross- und Upselling Funktionen zur Verfügung gestellt. Oder wie man das von den großen Portalen kennt: „Kunden, die diesen Artikel gekauft haben, kauften auch:“

Bei Magento kann man Cross- und Upselling für Produkte manuell konfigurieren, was in größeren Shops nicht handelbar wäre. Meist wird dann zu bestehenden Modulen aus Magento-Connect gegriffen. Alternativ fällt die Funktion auch in einem Suchprojekt ab. Beide Lösungen aber haben den Nachteil, dass sie die Informationen über die Produkte und über das Kaufverhalten der Kunden nur oberflächlich verwenden.

recommendation

In Zusammenarbeit mit dem Kunden haben wir deshalb ein eigenes Recommendation für Magento entwickelt. Wir verfügen über das mathematische Know-How um dieses Problem fundiert angehen zu können und der Kunde bringt das Wissen über sein Produkt mit ein. Diese Kombination führt zu einem optimalen Ergebnis. Durch die Steigerung des Umsatzes finanziert sich diese Maßnahme von alleine.

Falls Sie auch ein für Sie optimiertes Produktempfehlungsmodul benötigen, dann nehmen Sie mit uns Kontakt auf. Wir helfen Ihnen gerne weiter!

Sie erreichen uns unter der Telefonnummer +49 (0)4105 5615699 oder per Mail an info@initos.com.

Über Markus Schneider

Als Analytiker und Informatiker ist Markus Schneider Experte für Shop- und ERP-Systeme. Dabei setzt er sein fundiertes Wissen insbesondere im Bereich der Open Source Software ein und kann verschiedene
Anwendungssysteme, z.B. Oxid eSales, OTRS, und Solr Suche, darin integrieren. Auch mit der Onlineshopsoftware Magento kennt sich Herr Schneider bestens aus. Zudem greift er auf gesammelte Erfahrungen unterschiedlicher Systeme wie Sage, SAP und speziell OpenERP zurück.

Report von den OpenDays 2014 in Louvain-la-Neuve

veröffentlicht in Consulting am 8. Jun. 2014 Tags: , , , ,

odoo_logo_color

Auch in diesem Jahr war initOS wieder bei den OpenDays, dem jährlichen Treffen aller OpenERP / Odoo Partner [5], dabei.
Dieses Mal hat das Treffen nicht wie im letzten Jahr an der Freien Universität in Brüssel [4] stattgefunden, sondern in der Retortenuniversitätsstadt Louvain-la-Neuve [1].

Nachdem die Firma hinter OpenERP, die OpenERP S.A., kurz vorher im Rahmen einer zweiten Finanzierungsrunde in Höhe von 10 Mio. [2] den Namen des Produkts erneut geändert hatte, war die Verunsicherung unter Partnern, aber auch unter den Nutzern recht groß. Zuwenig war gegenüber den Partnern und anderen Stakeholdern im Vorfeld bekannt gemacht worden und zu schlecht waren und sind die Informationen für diesen Schritt auch während und im Nachgang zum Pressetermin aufbereitet worden.

Dennoch konnten gerade die OpenDays für Klarheit innerhalb der Community sorgen und einige Dinge ins rechte Licht rücken. So ist zum Beispiel die Umbenennung der Marke von OpenERP in Odoo zunächst ein schlecht nachzuvollziehender Schritt gewesen. Nach Aussagen des Chief Sales Officers Xavier Pansaers jedoch ist das nötig gewesen, weil OpenERP bis dato schwach im nordamerikanischen Markt vertreten war und der Grund unter anderem darin identifiziert wurde, dass die Abkürzung ERP (Enterprise Resource Planning) vor allem ein Synonym für lange und risikoreiche Einführungsprojekte ist. Dem können wir zumindest, insofern es die U.S. amerikanische Denkweise betrifft, folgen.

Allerdings macht natürlich die reine Umbenennung des Namens ein Einführungsprojekt nicht weniger aufwendig und die im Oktober 2013 von Odoo vorgeschlagene Kick-Start Einführung ist bei deutschen KMU nur in sehr handverlesenen Fällen überhaupt ein sinnvoller Ansatz [6,7]. Um dieses Problem auf der konzeptuellen Ebene zu lösen, hat man bei OpenERP/Odoo beschlossen, die zuvor als einzelne Module verfügbaren Funktionsbündel (wie zum Beispiel CRM oder Projektmanagement) als sogenannte Business Apps zu betrachten. Jeder dieser Business Apps kann einzeln installiert und genutzt werden (unter Nutzung der Odoo Plattform) und mit dem Wachstum des Unternehmens und seiner Anforderungen um weitere Business Apps (wie zum Beispiel e-Commerce und Websitebuilder) erweitert werden. Partner können ihre Module und Erweiterungen ebenso über den App Store bereitstellen. Der Vorteil dieses modularen Aufbaus ist, dass der Kunde auch nur diejenigen Funktionen tatsächlich supporten lassen sollte, die er wirklich nutzt. Aktuell sieht die neue Servicestruktur so aus, dass jeder aktive Nutzer [12] für die Wartung, Updates, die Zusicherung unbeschränkter Bugfixes, das Hosting (wenn dies gewünscht auf Servern von OpenERP/Odoo) und die Migration eine Pauschale von 12 Euro pro Funktionsbündel bezahlt [3]. Der Kunde im e-Commerce, der einen eigenen Login hat und seine Versandadresse schreibend ändern können soll (und muss) gilt aktuell als aktiver Nutzer. Damit sorgt er im Zweifel für sehr hohe Wartungskosten. Wir gehen deshalb davon aus, dass  -so jedenfalls unsere Hoffnung und nach einigen Aussagen von Odoo Mitarbeitern- bald noch einmal eine geringfügige Korrektur an dem Preismodell durchgeführt wird. Ohnehin ist sowohl die Preisgestaltung des Services als auch die Sicherstellung seiner Qualität noch verbesserungsfähig.

Wir haben vor Ort die Chance genutzt diese Punkte gegenüber dem Gründer und Erfinder von Odoo Fabien Pinckaers, dem Marketing- und Renewal Team und der Verantworlichen Leiterin des Supportteams Phuong Luu -wie auch vielen anderen der Odoo Partner- klarzumachen. Wir denken und glauben daher daran, dass sich an dieser Strategie in Kürze noch etwas ändern wird. Wir werden jede wesentliche Änderung jedefalls zeitnah mitteilen und diese auch unseren Kunden zur Verfügung stellen.

Eine weitere wesentliche Errungenschaft dieser OpenDays war die Gründung der ODOO Community Assosiaction (OCA), um deren frich gewählten Präsidenten (Joël Grand-Guillaume vom Partner CamptoCamp [9]). Die OCA ist eine Interessenvertetung vieler Partner, Nutzer und freier Softwareentwickler, die es sich zum Ziel gesetzt hat, durch geteilten Aufwand (shared effort) und das Einwerben von Mitteln (fundraising), gemeinsame Entwicklungsaktivitäten und Produktentwicklungen voranzubringen (z.B. Lokalisierung für die verschiedenen Länder, OpenUpgrade zur Migration [11]), um zum einen die Entwicklung des Produktes über die Aktivitäten von OpenERP S.A. hinaus zu beschleunigen und so auch ein gewisses strategisches Gegengewicht der Partner und Nutzer gegenüber Odoo S.A. zu platzieren. Zwar brachte Fabien Pinckaers berechtigterweise zum Ausruck, dass das Geschäftsmodell von Odoo S.A. durch einige dieser Entwicklungen (wie z.B. OpenUpgrade) empfindlich leiden könnte, aber alles in allem herrschte Konsens darüber, dass in der Summe der Vor- und Nachteile mit der OCA ein wesentlicher Entwicklungsschritt hin zu einer der bedeutensten Plattformen für Enterprise Computing getan worden ist und dieser lange überfällig war. Die initOS GmbH & Co. KG begrüßt diesen Schritt außerordentlich und wird sich zunächst als Unternehmen und sicher auch individuel aktiv an der OCA beteiligen.

Im Übrigen ist ein sehr offener und konstruktiver Umgang der Partner untereinander festzustellen. Sowohl national wie auch international. Das gemeinsame Ziel ist nicht weniger als die bedeutenste Enterprise Application Plattform der Welt zu werden und damit Fabien Pinckaers einstigen Traum in die Realität umzusetzen [2].

Der europäische Markt besteht aus über 99% kleiner und mittlerer Unternehmen (KMU) von denen die Mehrheit ein solches System in den nächsten Jahren einführen wird oder werden muss, um weiterhin wettbewerbsfähig zu bleiben. Deshalb und aufgrund der grundsätzlich offenen Kultur von Open Source Projekten, kommt die weitreichende Kollaboration nicht nur diesen, sondern vor allem auch deren Kunden und dem Produkt selbst zugute.

Die deutschen Partner planen im Übrigen noch in diesem Jahr eine gemeinsame Veranstaltung für Kunden und Interessenten durchzuführen. Wir werden selbstverständlich über News zum Thema informieren, sobald diese vorliegen.

Sollten Sie Fragen zum Produkt, der strategischen Entwicklung oder ähnlichen Themen haben, zögern Sie nicht uns anzurufen.
Ihr kontinuerliches und bitte durchaus auch kritisches Feedback, spielt gerade bei der Entwicklung von Open Source Software wie Odoo eine unschätzbar wichtige Rolle!

Sie erreichen uns unter der Telefonnummer +49 (0)4105 5615699 oder per Mail an info@initos.com.

Ihr initOS-Team

[1] http://de.wikipedia.org/wiki/Louvain-la-Neuve
[2] https://www.odoo.com/blog/Odoo-Blog-1/post/The-OpenERP-StoPricing-Q3-2014-158
[3] https://www.odoo.com/blog/Odoo-Blog-1/post/Odoo-The-New-OpenERP-156
[4] http://www.ulb.ac.be/
[5] https://www.odoo.com/partners
[6] http://www.linuxtag.org/2014/de/programm/vortragsdetails/?eventid=1408
[7] http://chemnitzer.linux-tage.de/2014/de/vortraege/detail/271
[8] https://www.odoo.com/page/about-us
[9] https://twitter.com/jgrandguillaume
[10] http://odoo-community-association.org/
[11] https://github.com/OpenUpgrade/OpenUpgrade
[12] https://openerp.my.openerp.com/forum/Help-1/question/I-will-be-charged-by-active-users-does-this-mean-how-many-people-use-the-program-or-how-many-clients-I-have-in-my-database-6477

Über Frederik Kramer

Technischer Geschäftführer der initOS GmbH & Co. KG und Doktorand am Magdeburg Research and Competence Cluster (MRCC) der Otto-von-Guericke-Universität Magdeburg ist Ihr Experte im Bereich der Strategischer Nutzung von Open Source Software im Unternehmen.

OpenERP / Odoo Magento Connector: Product import with taxes

veröffentlicht in Consulting,Software Engineering am 6. Jun. 2014 Tags: , ,

Many countries have different tax rates for different kinds of goods and services. For ecommerce applications at least two software components have to know the right taxes for products: the online shop software and the backing ERP system. Once you have configured your products with tax rates correctly in your Magento online web shop, you don’t want to configure them in OpenERP/Odoo again when you have imported them with the OpenERP Magento Connector.
The product import of the connector does not import the taxes because there is no easy mapping between taxes in Magento and the complex tax and accounting functionality of OpenERP/Odoo. But such a mapping can easily be defined in a custom add-on that extends the connector.

Based on the value of tax_class_id-field of the Magento product, we want to fill all four relevant income/expense account and purchase/sale tax rate fields in OpenERP/Odoo that are shown in the following image.

Tax rate and tax account configuration of a product in OpenERP

Tax and account configuration of a product in OpenERP

For a German company with 19% and 7% tax rates, the mapping could be as shown below. If you have not customized your OpenERP Magento Connector yet, you can find a good tutorial at the official homepage of the connector.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
@magento_myversion
class CustomProductImportMapper(ProductImportMapper):
    _model_name = 'magento.product.product'
 
    @mapping
    def tax_class_id(self, record):
        value = record.get('tax_class_id', '-1')
        if value == '1':
            sess = self.session
            tax_ids = sess.search('account.tax',
                [('description', '=', '19% USt'), ('type_tax_use', '=', 'sale'), ('parent_id', '=', False)])
            supplier_tax_ids = sess.search('account.tax',
                [('description', '=', '19% VSt'), ('type_tax_use', '=', 'purchase'), ('parent_id', '=', False)])
            account_income = sess.search('account.account',
                [('code', '=', '440000')])
            account_expense = sess.search('account.account',
                [('code', '=', '540000')])
            result = {'taxes_id': [(6, 0, [tax_ids[0]])],
                      'supplier_taxes_id': [(6, 0, [supplier_tax_ids[0]])],
                      'property_account_income': account_income[0],
                      'property_account_expense': account_expense[0],
                     }
        elif value == '2':
            sess = self.session
            tax_ids = sess.search('account.tax',
                [('description', '=', '7% USt'), ('type_tax_use', '=', 'sale'), ('parent_id', '=', False)])
            supplier_tax_ids = sess.search('account.tax',
                [('description', '=', '7% VSt'), ('type_tax_use', '=', 'purchase'), ('parent_id', '=', False)])
            account_income = sess.search('account.account',
                [('code', '=', '430000')])
            account_expense = sess.search('account.account',
                [('code', '=', '530000')])
            result = {'taxes_id': [(6, 0, [tax_ids[0]])],
                      'supplier_taxes_id': [(6, 0, [supplier_tax_ids[0]])],
                      'property_account_income': account_income[0],
                      'property_account_expense': account_expense[0],
                     }
        else:
            result = {}
        return result

Über Thomas Rehn

Der ausgebildete Mathematiker Thomas Rehn ist begeisterter Problemlöser in C++, Java, Perl, PHP und Python. Seine jahrelange Erfahrung als System-Administrator sorgt für den reibungslosen Betrieb unserer Web-, Datenbank und Applicationserver. Nebenbei ist er Autor von und Contributor zu verschiedener mathematischer Open-Source-Software.

Nächste Seite »