You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Pierre Smits <pi...@apache.org> on 2021/11/19 07:53:28 UTC

Fwd: OFBiz implementatie

Hi All,

FYI a feedback I had from a prospective integrator . Would not withhold it
from you. It is in Dutch, but I am confident that together with the AI of
Google Translate (and the likes) you should be able to get the gist.

If not, feel free to ask


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


---------- Forwarded message ---------
Subject: Re: OFBiz implementatie
To: Smits, Pierre <pi...@gmail.com>


Goedemorgen Pierre,



Dank voor je mail en jij ook de beste wensen!



Om eerlijk te zijn hebben we besloten niet verder te investeren in Ofbiz.
Het belangrijkste punt waar we tegen aanliepen is gebrek aan documentatie
en community. Er is zeker wel een community, maar de grootte is beperkt. De
meeste errors die ik tegenkom en ga googlen geven geen (relevante)
zoekresultaten waardoor je zelf vaak lang aan het zoeken bent. De
documentatie is er wel, maar heel beperkt. Zowel voor de gebruiker als de
developer. Als ik tegen een vraagstuk van de klant oploop en ga zoeken dan
vind ik heel algemeen hoe je bijvoorbeeld een factuur aanmaakt, maar niet
exact wat het idee is achter payment preferences, payments, applyen van
payments etc.



Ik merk ook dat de klant het vaak heel omslachtig vindt. In deze zelfde
functionaliteit zie je bijvoorbeeld dat er aan een order een factuur zit en
aan de factuur een betaling. Deze betaling kan op ‘betaald’ staan terwijl
de factuur niet op betaald staat. Dan moet de klant dus handmatig aangeven
dat de factuur ook betaald is. Dit soort zaken heb ik uiteindelijk maar
opgelost door het via een cronjob recht te trekken, want de code was iets
te complex om dat aan te passen zonder mijzelf heel veel testwerk op de
hals te halen.



Ondertussen ken ik aardig de weg in de code waardoor het nu ook wel een
stuk sneller gaat. Vanuit andere (niet-ERP) systemen weet ik dat het nooit
wenselijk is om de core code aan te passen ivm de mogelijkheid tot updaten.
Dit wilde ik ook niet in Ofbiz doen, maar ik kwam er al snel achter dat je
hier niet aan ontkomt. Aan de mailinglist merk ik ook dat dit vaak
aangeraden wordt. Je kunt prima nieuwe, losstaande modules ontwikkelen. Je
kunt daarmee alleen niet functies aan andere modules aanpassen of
toevoegen. Op zich is dat natuurlijk gewoon een keuze, toen ik dit eenmaal
geaccepteerd had ging het ontwikkelen op zich prima.



Ik merk dat de shift van Java naar GroovyScript op zich wel fijn is. Dit
versnelt het ontwikkelen aanzienlijk doordat je niet steeds Ofbiz opnieuw
hoeft te starten. Het nadeel is nu alleen dat je soms aan het zoeken bent
binnen templates, service definities, groovyscripts en javacode voordat je
gevonden hebt wat je zocht. Dat is nu wellicht een transitie, maar is voor
een developer niet altijd handig.



Het klinkt nu heel negatief, maar dat is ook niet mijn bedoeling. Het
grootste pijnpunt zit vooral in de documentatie. Ik ben te vaak tegen
vragen van de klant aangelopen die ik zelf eigenlijk ook niet goed kon
beantwoorden. Of het bugs zijn of dat er een logische reden voor is weet ik
ook niet altijd. Nog een voorbeeld: als je een order aan het invoeren bent
kun je de prijs aanpassen. Als je vervolgens het aantal aanpast wordt de
prijs weer teruggezet naar de originele prijs. Is dat een bewuste keus of
een bug? Zo zijn er heel veel van die kleine dingen die soms wellicht via
documentatie af te vangen zijn. Had mij een hoop zoeken door de code en
frustraties bij de klant gescheeld :).



Als Ofbiz een grotere aantrekkingskracht moet krijgen zijn er een aantal
zaken waar de focus nu op moet liggen:



   - Documentatie
   - Webpos
   - Design
   - Koppelingen met bestaande webshops



De documentatie lijkt mij ondertussen duidelijk. De webpos werkt nog heel
buggy en niet in lijn met de order manager. Ik begrijp dat deze module ook
nog vrij nieuw is, dus dat is op zich logisch. Het design zie ik vooral als
een quick win. Wij hebben er zelf een beetje aan gesleuteld (obv het
default theme) en dit er uit gekregen:

[image: Afbeelding met schermafbeelding Automatisch gegenereerde
beschrijving]



Blijft een kwestie van smaak, maar ik denk dat dit al een stuk cleaner en
vooral moderner oogt. Als je het interessant vindt kan ik eens kijken voor
je of we dit makkelijk los kunnen trekken en toe kunnen voegen in het
project zodat anderen het ook kunnen gebruiken. Ik moet even checken of er
dan geen klant-specifieke zaken in zitten namelijk. Zo weet ik dat we
bepaalde items verborgen hebben die deze klant toch niet ging gebruiken om
het overzichtelijk te houden. Ik ben ook bang dat we de CSS overriden ipv
de originele CSS aanpassen, dus dat zouden we dan ook op moeten schonen.



Wat mijn laatste punt betreft, koppelen aan webshops, denk ik dat daar best
veel interesse kan liggen. Het is moeilijk om te concurreren aan andere
webshop platformen. Daar ligt ook niet de kracht van Ofbiz. Als je zorgt
voor een kant-en-klare koppeling met bijvoorbeeld/o.a. Magento trek je een
veel breder publiek. Magento is niet heel sterk in de backend afhandeling,
dus daar ligt zeker een gat.



Mocht je meer willen weten, laat het gerust horen!



Met vriendelijke groet / Kind regards,



***** *******

Solutions Architect



****** B.V.

******* 11

2516 AC Den Haag



T +31 70 *** ** **