[OFBiz] Users - Automatic Purchasing
Locked
12
12
Re: Users - Automatic Purchasing
 
|
Re: Users - Automatic Purchasing
|
|
Re: Users - Automatic Purchasing
|
|
Yes, that is pretty much what needs to be done. The code shouldn't be too bad, and it would be great to get this back in place (it's obviously been out of commission for a while, ever since the data model and other changes to support multiple shipping destinations per order). -David On Jan 10, 2006, at 9:15 AM, David Welton wrote: >> Our current system is built with the idea that we have a number of >> suppliers with potentially hundreds of thousands of different >> products, which we could not possibly stock (nor do we want to keep >> that much junk in our warehouse!), so what we need to do is generate >> orders for those suppliers every day or every few days with the >> following criteria: >> >> 1) If we are going to miss the ship-date we promised to a customer if >> we don't order from the supplier *now*. >> >> 2) Otherwise, only order from the supplier if we have a 'minimum >> order' (in terms of either number of products, or money). > > checkInventoryAvailability in > ofbiz/applications/product/src/org/ofbiz/product/inventory/ > InventoryServices.java > seems to have some of the characteristics we need. Basically, since > we try to stock as little as possible, I guess we could consider most > all of our orders to be "back orders". A lot of the logic in > checkInventoryAvailibility is good stuff, for instance cancelling > orders if they have waited more than thirty days. > > The code is not currently functional, though, it would seem: > > "r4642 | jonesde | 2005-03-10 01:30:33 +0100 (Thu, 10 Mar 2005) | 1 > line > > Changed to not run inventory availability services that does > backorder notices a > nd such, needs to be updated for OrderItemShipGroup, now will just > show warning > message instead of throwing exceptions" > > And the TODO says: > > // TODO: change to get all OrderItemShipGroup records for > // the order, then get items per ship group > > So.... to do that... I would... > > 1) select all ordershipgroups where orderid = the one I want. > 2) foreach ordershipgroup, go through its associated items, and run > the subsequent logic on them, possibly cancelling them. > 3) Continue on as before at line 515: if (orderItems != null) { > > Is that more or less correct? > > Thanks, > -- > David N. Welton > - http://www.dedasys.com/davidw/ > > Linux, Open Source Consulting > - http://www.dedasys.com/ > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
smime.p7s (3K)
Re: Users - Automatic Purchasing
|
|
Re: Users - Automatic Purchasing
|
|
On Jan 11, 2006, at 6:34 AM, David Welton wrote: > Hrm... pardon me if I write to the list partly as a way to "think > out loud". > > The idea of having order ship groups is to be able to split one order > ship group into several if needs be, correct? > > Perhaps #3 above is incorrect then - the loop that begins like this: > > if (orderItems != null) { > List toBeStored = new ArrayList(); > Iterator orderItemsIter = orderItems.iterator(); > while (orderItemsIter.hasNext()) { > ............. > > ought to be in the loop I'm coding that iterates like so: > > Iterator orderShipGroupsIter = orderShipGroups.iterator(); > while (orderShipGroupsIter.hasNext()) { > GenericValue orderShipGroup = (GenericValue) > orderShipGroupsIter.next(); > > So that orderItems is reset each time and we only deal with those that > pertain to the orderGroup at hand. from a OrderItemShipGroupAssoc entity query for each OrderItemShipGroup. The "orderItems" there could come from that or you could iterate through a "orderItemShipGroupAssocList" and then get the OrderItem value for each, or whatever. > By the way... these entity things, like findByAnd - do they directly > map to select statements, or... how do they work? Yes, all Entity Engine calls that involve database interactions just translate into some sort of SQL statement that gets sent to the database through JDBC. The actual SQL generated can vary in certain cases for different databases as configured in the datasource element in the entityengine.xml file. -David _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - Automatic Purchasing
|
|
Re: Users - Automatic Purchasing
|
|
On Jan 12, 2006, at 12:23 PM, David Welton wrote: >> Yes, however you do it the list of items per ship group must come >> from a OrderItemShipGroupAssoc entity query for each >> OrderItemShipGroup. The "orderItems" there could come from that or >> you could iterate through a "orderItemShipGroupAssocList" and then >> get the OrderItem value for each, or whatever. > > I think I ended up with that. I would have been happier with some > kind of SQL join rather than hitting the database inside a while loop, > but I guess for now it'll do. The way around this is to use a view entity so the details are joined with each row, avoiding a database round trip in each iteration. There may even be a view-entity defined for this already. >>> By the way... these entity things, like findByAnd - do they directly >>> map to select statements, or... how do they work? > >> Yes, all Entity Engine calls that involve database interactions just >> translate into some sort of SQL statement that gets sent to the >> database through JDBC. The actual SQL generated can vary in certain >> cases for different databases as configured in the datasource element >> in the entityengine.xml file. > > Ok. > > In any case, I sent a patch off. It's probably not right, hopefully > whoever looks at it will be able to tell me just what is wrong with it > so that I'll learn. > > A few more things I can think of... 30 days is hard coded into the > code in a lot of places. Might be a nice thing to be able to > configure. > > Then, the one I'm interested in is being able to generate requirements > (I think?) when items are backordered. To do this, I need to... > > 1) Create a service that looks at everything that is backordered. > 2) Foreach thing that is backordered, create a requirement. > 3) ... vague in my mind, but requirements lead to orders ... this > needs to be automated, and at some time interval. > 4) Call the new service from the code that I patched. > > ... ? done. Back ordered just means that there was insufficient inventory, and there is a requirement creation option to do so only when there is insufficient inventory. -David _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - Automatic Purchasing
|
|
Re: Users - Automatic Purchasing
|
|
On Jan 13, 2006, at 11:21 AM, David Welton wrote: >>> Then, the one I'm interested in is being able to generate >>> requirements >>> (I think?) when items are backordered. To do this, I need to... >>> >>> 1) Create a service that looks at everything that is backordered. >>> 2) Foreach thing that is backordered, create a requirement. >>> 3) ... vague in my mind, but requirements lead to orders ... this >>> needs to be automated, and at some time interval. >>> 4) Call the new service from the code that I patched. >>> >>> ... ? >> >> I think the way the stuff is currently implemented this is already >> done. Back ordered just means that there was insufficient inventory, >> and there is a requirement creation option to do so only when there >> is insufficient inventory. > > Hrm... where does one find this? I had a look through order and > facility and didn't notice it... that can be used to specify what to do when the product is out of stock. In a way this is a fairly limiting place to put the field since you can only specify the stuff for product regardless of the store, facility, etc. There are related settings, like inventory settings, that are per store and/or per product. Anyway, the different options for this can be seen in the Enumeration entity's table, or in the ProductTypeData.xml file. For the Enumeration the enumTypeId="PROD_REQ_METHOD". -David _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - Automatic Purchasing
|
|
| Free forum by Nabble | Edit this page |