run action in Order Search

Sorry if this is something others have asked and answered, but I did try searching first.
Any one know what the option create file does? (like where etc).
Also there are two drop downs one lets you select create file, approve order etc, what is the other for?

[Jacques Le Roux]

This is supposed to create a PDF, I just tried on trunk demo and it seems not to work.
I will later check what's happening there, anyway those are really minor features (with print which does not work also)

The 2nd drop-down is to select a printer, it uses: printServices = PrintServiceLookup.lookupPrintServices(null, null);

HTH

Jacques

Le 11/08/2014 21:55, [hidden email] a écrit :

> Sorry if this is something others have asked and answered, but I did try
> searching first.
> Any one know what the option create file does? (like where etc).
> Also there are two drop downs one lets you select create file, approve order
> etc, what is the other for?
>
>
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/run-action-in-Order-Search-tp4653403.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

Thank you. I will remove for now on my version. Be cool if it worked.
I am doing my own version of P.O.

I also see a check box in add item (under P.O. view - edit items page) , that says over ride price.
next to the price field. I don't recall seeing this on any of the other price entry screens.

I did not see it update the supplier last price (I figured if checked it would leave it and if not it would update it, but neither seemed to update the supplier last price field).

Just curious, maybe you know what it impacts and if I need to leave it on the form.

I should of figured out the printer thing. Mine had an option for boomaga (I installed for testing printing without a printer, but forgot). I just tested print and it came up and has a save as pdf option.
I may put it back. I hated removing the run action thing looked very cool, for mass updates.
I am trying to make the screens as simple as possible, so I will run past my boss for a opinion, but I appreciate understanding what is supposed to do, I am sure I can just remove the create file option.
Also I am doing P.O. and it has quick ship option, so it might need a bit of filtering based on if P.O. or Order.
Pretty odd that they chose to share the module, as they are pretty different tasks.

[Jacques Le Roux]

Le 13/08/2014 19:17, [hidden email] a écrit :
> Thank you. I will remove for now on my version. Be cool if it worked.
> I am doing my own version of P.O.
>
> I also see a check box in add item (under P.O. view - edit items page) ,
> that says over ride price.
> next to the price field. I don't recall seeing this on any of the other
> price entry screens.

This is once you have created the order indeed, ie when it's ready to ship. There is also an option to change quantity to ship on this screen
You can also change the price and the quantity while putting product in the cart in the 1st screen (use check and recalc for that)

>
> I did not see it update the supplier last price (I figured if checked it
> would leave it and if not it would update it, but neither seemed to update
> the supplier last price field).

At this moment it's no longer a supplier price, it's a price of an order item in a cart...
You can't change a Product.price or SupplierProduct.lastPrice, only price of the product in cart...

Jacques

>
> Just curious, maybe you know what it impacts and if I need to leave it on
> the form.
>
>
>
>
>
>
> -----
> Joel Fradkin
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/run-action-in-Order-Search-tp4653403p4653446.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

I understand it changes the price in the cart, but what does override price check-box impact?
It seemed to change the price if it was checked , and also if it was not checked.
I would think if you put a price in for a product from a supplier, it should update the last price in the screen where you apply a supplier to a product. Maybe I just do not understand the whole process, but if I buy x at 2.00 the first time it should set that last price field at 2.00 and if I buy again for 2.50 it should update it, so when I place another order the default price is now 2.50.

Joel

[Jacques Le Roux]

Le 13/08/2014 22:43, [hidden email] a écrit :
> I understand it changes the price in the cart, but what does override price
> check-box impact?
> It seemed to change the price if it was checked , and also if it was not
> checked.

Are you speaking only when the order has been created or also before?
For me, on trunk demo, before creation, there are no issue prices or/and quantity are only changed for selected (checked) items
After I noted indeed that even if you don't check an item for quantity it can be changed. Not the same for price, it needs to be checked to be changed

To be franck, I never understood why there were those checkboxes. Because OFBiz should be able to compare by itself and store only changed values.
IIRW, when you look into programming details it makes more sense (easier coding) but still we could get rid of these checkboxes with a "little" effort
Even when the underlying service is called out of the normal UI context (I recently fixed an issue with the underlying service at
http://svn.apache.org/viewvc?view=revision&revision=r1616940)

> I would think if you put a price in for a product from a supplier, it should
> update the last price in the screen where you apply a supplier to a product.
> Maybe I just do not understand the whole process, but if I buy x at 2.00 the
> first time it should set that last price field at 2.00 and if I buy again
> for 2.50 it should update it, so when I place another order the default
> price is now 2.50.

Actually this is not by product but by order item, so the changes are not persisted

Note that all these behaviours are common to SOs and POs

Jacques

>
> Joel
>
>
>
> -----
> Joel Fradkin
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/run-action-in-Order-Search-tp4653403p4653469.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

[Jacques Le Roux]

Le 13/08/2014 19:28, [hidden email] a écrit :

> I should of figured out the printer thing. Mine had an option for boomaga (I
> installed for testing printing without a printer, but forgot). I just tested
> print and it came up and has a save as pdf option.
> I may put it back. I hated removing the run action thing looked very cool,
> for mass updates.
> I am trying to make the screens as simple as possible, so I will run past my
> boss for a opinion, but I appreciate understanding what is supposed to do, I
> am sure I can just remove the create file option.
> Also I am doing P.O. and it has quick ship option, so it might need a bit of
> filtering based on if P.O. or Order.
> Pretty odd that they chose to share the module, as they are pretty different
> tasks.

Nope, it's not quick ship but quick receive ;) and there is an option to decide in which facility...

OFBiz UI is based on the underlying data model which follows the "The Data Model Resource Book"
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Related+Books
It's quite great to have orders (SOs and POs) to share the same entity and just have a type for each!

Jacques

>
>
>
>
> -----
> Joel Fradkin
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/run-action-in-Order-Search-tp4653403p4653447.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

I have the book, so I will look at what you reference.
Yes It is nice they share entity, but I do not agree with sharing the same coding module.
In my opinion I think it would be much clearer to have PO separate. The code (ftl etc, have not studied the java) is not done in a way that shared elements are seperated and decorated to add the functionality of the module. If I am working on PO I should not have to see SO code, it should be in a different child. Its like every page has all this logic that says is it a P.O. or a S.O. I have not had an issue fixing it up the way I want and I love working in ofbiz now. So I am not being critical, its great to get a working module with so much functionality.

Thinking about it I don't even think its great to share the same entity.
Unless there is a mechanism to keep the file size small.
I am no expert, but I imagine it impacts performance having to look at type in regards to relationships.
Also over all data size. Maybe P.O. and S.O. just don't generate enough records for this to be an issue, but I imagine since it  is part of the business data flow, it would probably get very large. When performance becomes a major issue some schemes to pick up speed is to use different tables, even different databse servers etc. Just a thought.

[Adrian Crum-3]

It would be helpful if you read the book. A PO and SO are the same
thing, the only difference is who is selling and who is buying.

Making them separate entities would introduce a lot of redundant data
and code.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/14/2014 1:30 PM, [hidden email] wrote:

> Thinking about it I don't even think its great to share the same entity.
> Unless there is a mechanism to keep the file size small.
> I am no expert, but I imagine it impacts performance having to look at type
> in regards to relationships.
> Also over all data size. Maybe P.O. and S.O. just don't generate enough
> records for this to be an issue, but I imagine since it  is part of the
> business data flow, it would probably get very large. When performance
> becomes a major issue some schemes to pick up speed is to use different
> tables, even different databse servers etc. Just a thought.
>
>
>
> -----
> Joel Fradkin
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/run-action-in-Order-Search-tp4653403p4653523.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

[Pierre Smits]

Hi Joel,

That is why we at ORRTIZ.COM created different solutions for CRM and SRM.
Though the underlying datamodel is the the same, Purchase isn't Sales and
have different requirements.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Thu, Aug 14, 2014 at 2:07 PM, [hidden email] <
[hidden email]> wrote:

> I have the book, so I will look at what you reference.
> Yes It is nice they share entity, but I do not agree with sharing the same
> coding module.
> In my opinion I think it would be much clearer to have PO separate. The
> code
> (ftl etc, have not studied the java) is not done in a way that shared
> elements are seperated and decorated to add the functionality of the
> module.
> If I am working on PO I should not have to see SO code, it should be in a
> different child. Its like every page has all this logic that says is it a
> P.O. or a S.O. I have not had an issue fixing it up the way I want and I
> love working in ofbiz now. So I am not being critical, its great to get a
> working module with so much functionality.
>
>
>
> -----
> Joel Fradkin
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/run-action-in-Order-Search-tp4653403p4653521.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

I agree they are different.
The underlying data set might be the same, but sharing a table and using a type is not a good idea for performance. The entity maybe could even stay the same, but just from a data storage and speed thought it would be better to use two tables and eliminate the need for type to be introduced. Also if you ever try and read data, when the table is larger even with proper indexes it is slower on larger data sets. At least that is what I found testing with Postgres (might be different with the ofbiz engine).
I had 250 concurrent users on a system I was in charge of and I was always trying to figure out how to get the speed up. Many of our smaller companies were fine, so indexing does make a difference, but when the tables got more then say 500,000 records it would get much slower than when the table was small. We had all our clients for the most part on one DB. I found when I moved some of the realy big clients off to their own instance making the over size of the Postgres DB smaller the speed came up (even though that client still had the same number of records). I was surprised as I thought with proper indexing the number of records in the table would ot significantly impact speed. Maybe there were other issues, but I spent a bit of time on it and implemented a few more DB (pain separating out the data). Thats why I think it would be better to use two tables, but maybe if both tables are in the same DB it doesnt make a difference. We are not going to have that kind of stress so no worries here it works ok as is.

[Adrian Crum-3]

I have worked with OFBiz systems that had millions of orders, and
performance was not a problem.

I strongly encourage you to spend more time understanding design
patterns in OFBiz.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/14/2014 6:36 PM, [hidden email] wrote:

> I agree they are different.
> The underlying data set might be the same, but sharing a table and using a
> type is not a good idea for performance. The entity maybe could even stay
> the same, but just from a data storage and speed thought it would be better
> to use two tables and eliminate the need for type to be introduced. Also if
> you ever try and read data, when the table is larger even with proper
> indexes it is slower on larger data sets. At least that is what I found
> testing with Postgres (might be different with the ofbiz engine).
> I had 250 concurrent users on a system I was in charge of and I was always
> trying to figure out how to get the speed up. Many of our smaller companies
> were fine, so indexing does make a difference, but when the tables got more
> then say 500,000 records it would get much slower than when the table was
> small. We had all our clients for the most part on one DB. I found when I
> moved some of the realy big clients off to their own instance making the
> over size of the Postgres DB smaller the speed came up (even though that
> client still had the same number of records). I was surprised as I thought
> with proper indexing the number of records in the table would ot
> significantly impact speed. Maybe there were other issues, but I spent a bit
> of time on it and implemented a few more DB (pain separating out the data).
> Thats why I think it would be better to use two tables, but maybe if both
> tables are in the same DB it doesnt make a difference. We are not going to
> have that kind of stress so no worries here it works ok as is.
>
>
>
> -----
> Joel Fradkin
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/run-action-in-Order-Search-tp4653403p4653546.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

Thanks for the advice. I will. I am glad it handles millions of records without performance issues.
We will not have that kind of work load. Maybe it was somethign to do with config. Postgres is pretty complex.I had hired some consulting help at the time to tweak the config. I did find it helped to break out the data to a different server. But that might of been specific to my situation. I always thought indexed data should not be impacted, but in my case just the size of the database did make a difference.
I have not changed any patterns in my mods to ofbiz. I am using a hot-deploy project and just doing ftl and widget mods. I think what I was saying is sharing an ftl for P.O. and S.O. makes every other line check and do different screens. I think it would be easier to have two components (P.O., and S.O.), but I am very happy to have what was done and had no issues getting it to do what I need. I have found a few issues,and will make sure that its not already in jirra and add per instructions.