Product features and user-provided data

[Brian Ghidinelli]

A model question from the OfBizDatamodelBook PDFs and 
https://cwiki.apache.org/confluence/display/OFBENDUSER/Product+Features


I believe I understand I can have a ProductFeatureType of "Brand" with 
ProductFeatures of Hanes, American Apparel and Lacoste that could be 
related to my Product.


What if I have user-provided data for my product?  For example, I have a 
"Name to embroider on shirt" where I want to collect an arbitrary value 
from the buyer?


Once that's presented to the user in the purchase process as something 
like a text input field, where would OfBiz store that value for a 
particular Order Item?



Brian

Re: Can BigFish-eCommerce-v1.23 deploy on ofbiz 13.07.02

[Mike]

Hi Len.  What is the status of BigFish and 13.07.  I recently tried the
patch, had a few problems but managed to deploy it.  However, there were
errors in the UI after loading the demo data.

Is there another, updated 13.07 patch?  12.04 is now 4 years old.

Thanks.

On Thu, Oct 29, 2015 at 12:30 PM, Len Shein  wrote:

> Barou,
>
> We have created a patch to run BigFish with Ofbiz 13.07.  You can download
> the patch with instructions http://bigfish.solveda.com/bfDownload.html
> See specifically the following sections on the download page.
> -- Apply Bigfish files to make Bigfish compatible with Ofbiz 13.07
> -- BigFish 'Seed' Data
>
>
> Regards
> Len
>
>
> -Original Message-
> From: Barou [mailto:zsba...@gmail.com]
> Sent: Wednesday, October 28, 2015 10:31 AM
> To: user@ofbiz.apache.org
> Subject: RE: Can BigFish-eCommerce-v1.23 deploy on ofbiz 13.07.02
>
> Thanks very much Len
> I did tried your suggestion I and did not worked.
> Thank you for saving me lots of time.
> Any idea when the compatibility release you are talking about will be ?
> I am also using ofbiz but BigFish is really great.
>
>
>
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/Can-BigFish-eCommerce-v1-
> 23-deploy-on-ofbi
> z-13-07-02-tp4673888p4673954.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>

Re: Vendor credit memo

[Jacques Le Roux]

That's an interesting matter, answer and question, thanks Sharan!

Jacques


Le 10/08/2016 à 16:01, Sharan Foga a écrit :

Hi Oleg

I would use an invoice adjustment for the difference. The purchase invoice that 
is generated from the purchase order assumes that the invoice will be the same 
as the purchase order. When the real invoice appears it may be different so you 
need to be able to handle any variances and at the moment I think a invoice 
adjustment is an easy way to do it.

Sometimes I struggle a little with how payments have been implemented because I 
think they are being used to for 2 slightly different things. One is the amount 
that needs to be paid, and the other is the application of an amount to an 
invoice.  As OFBiz automatically generates the payment and the amount to be 
paid from the purchase order – it gives you the audit trail of the original 
transaction, so if you start adjusting the payment itself, you start to lose a 
bit of that visibility.

It is your choice and depending on how you want to work, it's flexible enough 
to do both.

I'd be interested to hear what other people have done in this situation too.

Thanks
Sharan

On 2016-08-10 14:58 (+0200), Oleg Andreyev  wrote:

Hi All,

I am working with project based on 13.07 and stuck trying to figure out how to 
apply vendor credit memo properly. I don’t mean accounting transactions. 
It’s clear. I mean how to get purchase invoice fully applied if it is issued 
for the full price but vendor issued a credit memo and buyer should apply 
payment with amount less than invoice because this memo. It seems this case 
does not have special solution in OFBiz. What’s come to mind is either 
negative invoice item adjustment or payment that equals to credit memo amount. 
However I think about credit memo as a kind of invoice rather than kind of 
payment.

What do you folks think of this case?

Thanks,
Oleg Andreyev

Re: Ofbiz Cookbook

[Jacques Le Roux]

Yes, and I believe, when we will have worked out Gradle stuff (at least: finishing it, adding plugins, correctly documenting the whole) we should 
gather to work on this and slowly replace/improve the old good Minilang


Could be the R17 main task?

Jacques


Le 12/08/2016 à 12:34, gil portenseigne a écrit :


+1

Indeed, and moreover in the wiki page you link, there is autocompletion 
configuration in IDE Integration part.

Thanks

Gil


Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :

+1

I think Jacopo has more to say about that :)

https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic

Jacques


Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :

I would like to add to what Scott already mentioned that minilang is not
only difficult to debug but also overly verbose.

However, minilang exists and continues to be used I think because of the
ctrl-space auto complete combined with XSD definitions for the statements.
This makes it a DSL (not too pretty) and this is something that we did not
provide a reasonable alternative for. Groovy makes a good candidate for an
alternative DSL but we don't have something yet which is comprehensively
documented with an easy auto-complete feature. This is very important for
many developers I think. So we need to think of a good alternative

On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray 
wrote:


I'm certainly no fan of minilang. I prefer something I can step through
with a debugger.

Regards
Scott

On 9/08/2016 20:55, "Paul Piper"  wrote:


Skip,

I fear that you may be right with regards to minilang and the community,
though luckily with your own projects you can set your own standards. I
learned the hard way that minilang leads to more cluttered code and

though

there are some benefits (the automapping of service maps or entity-auto

for

creating crud services), I would strongly recommend anyone to rather

invest

the time into proper java or groovy code.

As for the use of widgets over ftl, perhaps it is worth noting that we
streamlined both for Scipio ERP. They share the same underlying set of
macros and will create the hence create the same HTML & classes as are
defined by your theme. So if people prefer to use widgets, they can. We
relied on this, when cleaning up & converting usable screens alot, as not
always it would make sense to transfer them to ftl.

That being said, our goal is to further replace widgets by ftl logic as

we

move along. For both minilang and widgets the reason on our end is that
neither technology is used anywhere outside of the ofbiz project and thus
adds to the overall learning-curve for newcomers. We much rather rely on
trusted alternatives that are easier to pick up for our project ;)

Cheers,
Paul



--
View this message in context: http://ofbiz.135035.n4.nabble.
com/Ofbiz-Cookbook-tp4690647p4690733.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Ofbiz Cookbook

[gil portenseigne]

+1

Indeed, and moreover in the wiki page you link, there is autocompletion 
configuration in IDE Integration part.


Thanks

Gil


Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :

+1

I think Jacopo has more to say about that :)

https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic 



Jacques


Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :

I would like to add to what Scott already mentioned that minilang is not
only difficult to debug but also overly verbose.

However, minilang exists and continues to be used I think because of the
ctrl-space auto complete combined with XSD definitions for the 
statements.
This makes it a DSL (not too pretty) and this is something that we 
did not
provide a reasonable alternative for. Groovy makes a good candidate 
for an

alternative DSL but we don't have something yet which is comprehensively
documented with an easy auto-complete feature. This is very important 
for

many developers I think. So we need to think of a good alternative

On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray 


wrote:


I'm certainly no fan of minilang. I prefer something I can step through
with a debugger.

Regards
Scott

On 9/08/2016 20:55, "Paul Piper"  wrote:


Skip,

I fear that you may be right with regards to minilang and the 
community,
though luckily with your own projects you can set your own 
standards. I

learned the hard way that minilang leads to more cluttered code and

though
there are some benefits (the automapping of service maps or 
entity-auto

for

creating crud services), I would strongly recommend anyone to rather

invest

the time into proper java or groovy code.

As for the use of widgets over ftl, perhaps it is worth noting that we
streamlined both for Scipio ERP. They share the same underlying set of
macros and will create the hence create the same HTML & classes as are
defined by your theme. So if people prefer to use widgets, they 
can. We
relied on this, when cleaning up & converting usable screens alot, 
as not

always it would make sense to transfer them to ftl.

That being said, our goal is to further replace widgets by ftl 
logic as

we
move along. For both minilang and widgets the reason on our end is 
that
neither technology is used anywhere outside of the ofbiz project 
and thus
adds to the overall learning-curve for newcomers. We much rather 
rely on

trusted alternatives that are easier to pick up for our project ;)

Cheers,
Paul



--
View this message in context: http://ofbiz.135035.n4.nabble.
com/Ofbiz-Cookbook-tp4690647p4690733.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Ofbiz Cookbook

[Jacques Le Roux]

+1

I think Jacopo has more to say about that :)

https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic

Jacques


Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :

I would like to add to what Scott already mentioned that minilang is not
only difficult to debug but also overly verbose.

However, minilang exists and continues to be used I think because of the
ctrl-space auto complete combined with XSD definitions for the statements.
This makes it a DSL (not too pretty) and this is something that we did not
provide a reasonable alternative for. Groovy makes a good candidate for an
alternative DSL but we don't have something yet which is comprehensively
documented with an easy auto-complete feature. This is very important for
many developers I think. So we need to think of a good alternative

On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray 
wrote:


I'm certainly no fan of minilang. I prefer something I can step through
with a debugger.

Regards
Scott

On 9/08/2016 20:55, "Paul Piper"  wrote:


Skip,

I fear that you may be right with regards to minilang and the community,
though luckily with your own projects you can set your own standards. I
learned the hard way that minilang leads to more cluttered code and

though

there are some benefits (the automapping of service maps or entity-auto

for

creating crud services), I would strongly recommend anyone to rather

invest

the time into proper java or groovy code.

As for the use of widgets over ftl, perhaps it is worth noting that we
streamlined both for Scipio ERP. They share the same underlying set of
macros and will create the hence create the same HTML & classes as are
defined by your theme. So if people prefer to use widgets, they can. We
relied on this, when cleaning up & converting usable screens alot, as not
always it would make sense to transfer them to ftl.

That being said, our goal is to further replace widgets by ftl logic as

we

move along. For both minilang and widgets the reason on our end is that
neither technology is used anywhere outside of the ofbiz project and thus
adds to the overall learning-curve for newcomers. We much rather rely on
trusted alternatives that are easier to pick up for our project ;)

Cheers,
Paul



--
View this message in context: http://ofbiz.135035.n4.nabble.
com/Ofbiz-Cookbook-tp4690647p4690733.html
Sent from the OFBiz - User mailing list archive at Nabble.com.