Re: Webtools Users and Permissions
Also https://localhost:8443/webtools/control/security On Wed, 2015-06-17 at 16:33 +0200, Pierre Smits wrote: Hi Gabrielle, The Party mgr is the application to use, when it comes to managing user data, including access permissions if you're not providing a self registration or self service mechanism. Best 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 Wed, Jun 17, 2015 at 4:00 PM, Gabrielle C. Nguyen gabrie...@gabriellenguyen.com wrote: Hello, I would like to create new users within Webtools. Ideally, they can login and have access to specific areas (CMS editor) only. Is this possible to create new users? So far, I cannot seem to find a way to do so. If so, is it possible to give these users access permissions? Any tips? Thank You, Gabrielle
New delegators for external datasources throw errors
https://cwiki.apache.org/confluence/display/OFBIZ/Load+Legacy+Data+by +Connecting+to+the+Legacy+Database suggests creating a separate delegator to contain the external datasource group-map elements But, https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips +-+Tricks+-+Cookbook+-+HowTo says to use the default delegator Creating a separate delegator causes startup to crash due to the default delegator not being able to find a helperName in getModelFieldTypeReader() so getModelFieldType() is performed on null: return this.getModelFieldTypeReader(entity).getModelFieldType(type); (GenericDelegator.java:561) If the group-map is redundantly specified in the default delegator then startup succeeds. Is this a bug? Shouldn't group-map for the external entity only have to be specified for the delegator that will use it? The calling code org.ofbiz.entity.model.ModelEntityChecker.checkEntities(ModelEntityChecker.java:111) has lines above it accounting for a helperName but just adds to warningList. Adding a continue statement in place of warningList.add() allows startup to succeed but errors are thrown related to the missing helperName once the external entities are referenced. Am I missing something when it comes to creating new delegators? To be honest I don't really know why I would need a separate one from default? Can someone explain? Below is the stacktrace: Caused by: java.lang.NullPointerException at org.ofbiz.entity.GenericDelegator.getEntityFieldType(GenericDelegator.java:561) ~[ofbiz-entity.jar:?] at org.ofbiz.entity.model.ModelEntityChecker.checkEntities(ModelEntityChecker.java:111) ~[ofbiz-entity.jar:?] at org.ofbiz.entity.GenericDelegator.init(GenericDelegator.java:224) ~[ofbiz-entity.jar:?] at org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:33) ~[ofbiz-entity.jar:?] at org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25) ~[ofbiz-entity.jar:?] at org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:200) ~[ofbiz-base.jar:?] at org.ofbiz.entity.DelegatorFactory $DelegatorConfigurable.call(DelegatorFactory.java:83) ~[ofbiz-entity.jar:?] at org.ofbiz.entity.DelegatorFactory $DelegatorConfigurable.call(DelegatorFactory.java:74) ~[ofbiz-entity.jar:?] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_45] at java.util.concurrent.Executors $RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_45] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_45] at java.util.concurrent.ScheduledThreadPoolExecutor $ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_45] at java.util.concurrent.ScheduledThreadPoolExecutor $ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_45] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[?:1.8.0_45] at java.util.concurrent.ThreadPoolExecutor $Worker.run(ThreadPoolExecutor.java:617) ~[?:1.8.0_45] at java.lang.Thread.run(Thread.java:745) ~[?:1.8.0_45] java.lang.NullPointerException
Re: Can't get a Relation to Create a FK Constraint
Hey Jacques, Its not supported for 13.07 either. Created JIRA as improvement: https://issues.apache.org/jira/browse/OFBIZ-6493 On Wed, 2015-06-10 at 09:49 +0200, Jacques Le Roux wrote: Le 10/06/2015 08:05, Christian Carlow a écrit : Hey Forrest, I confirm this same issue on the trunk. It seems foreign keys are not currently handled by extend-entity. I encountered this issue a while back but didn't to create an issue for it and manually created the relation in the database server. +1 to create a JIRA Yes please. Last year I added the possibility to enlarge the PKs lengths. I don't think it's related but I will check. A good way to check if it's a regression is to test with the current stable. Else it's an improvement. Could you please try that 1st? Jacques On Tue, 2015-06-09 at 17:20 -0700, Forrest Rae wrote: Hi Everyone, I'm having a heck of a time trying to get this to work. I have a list of business specific codes I want to apply to a quote. It's a large list that changes, so Enumeration wouldn't be right for me here. For the life of me, I can not figure out why there is no foreign key constraint created in the Postgres database for the relation on Quote. I'm using a database that has some quote data in it already, but I did try deleting all the quote records, extending the entity, and then adding the records back in via entity-engine-xml. Nothing I've tried results in a FK constraint being created at the database level. Any ideas? entity entity-name=MyCode package-name=org.ofbiz.common.my title=Classification Code Data Object Entity field name=code type=id-ne/field field name=description type=description/field field name=fromDate type=date-time/field field name=thruDate type=date-time/field prim-key field=code/ /entity extend-entity entity-name=Quote field name=myCode type=id-ne not-null=true/ relation type=one fk-name=QUOTE_MY rel-entity-name=MyCode key-map field-name=myCode rel-field-name=code/ /relation /extend-entity -Forrest
Re: Can't get a Relation to Create a FK Constraint
Hey Forrest, I confirm this same issue on the trunk. It seems foreign keys are not currently handled by extend-entity. I encountered this issue a while back but didn't to create an issue for it and manually created the relation in the database server. +1 to create a JIRA On Tue, 2015-06-09 at 17:20 -0700, Forrest Rae wrote: Hi Everyone, I'm having a heck of a time trying to get this to work. I have a list of business specific codes I want to apply to a quote. It's a large list that changes, so Enumeration wouldn't be right for me here. For the life of me, I can not figure out why there is no foreign key constraint created in the Postgres database for the relation on Quote. I'm using a database that has some quote data in it already, but I did try deleting all the quote records, extending the entity, and then adding the records back in via entity-engine-xml. Nothing I've tried results in a FK constraint being created at the database level. Any ideas? entity entity-name=MyCode package-name=org.ofbiz.common.my title=Classification Code Data Object Entity field name=code type=id-ne/field field name=description type=description/field field name=fromDate type=date-time/field field name=thruDate type=date-time/field prim-key field=code/ /entity extend-entity entity-name=Quote field name=myCode type=id-ne not-null=true/ relation type=one fk-name=QUOTE_MY rel-entity-name=MyCode key-map field-name=myCode rel-field-name=code/ /relation /extend-entity -Forrest
How should new committers handle backporting?
Should committers download the entire ofbiz repository to help with backporting? Is there a standard procedure new committers should follow for backporting? I was going to test my new committer privilege by applying my OFBIZ-6387.patch. Should I apply it to the release branches also?
Re: How should new committers handle backporting?
Thanks Adrian, I'll just keep supporting the trunk for now and worry about backporting later when it is requested. Just wanted to make sure it wasn't expected for each commit. On Mon, 2015-05-18 at 19:00 -0700, Adrian Crum wrote: I check out each branch I am interested in supporting. Adrian Crum Sandglass Software www.sandglass-software.com On 5/18/2015 6:37 PM, Christian Carlow wrote: Should committers download the entire ofbiz repository to help with backporting? Is there a standard procedure new committers should follow for backporting? I was going to test my new committer privilege by applying my OFBIZ-6387.patch. Should I apply it to the release branches also?
Re: violation of foreign key constraint ORDER_ITSG_CSHM
I think this issue will solve this problem once resolved: https://issues.apache.org/jira/browse/OFBIZ-6093 On Tue, 2015-04-14 at 11:10 -0700, ofbiz-noob wrote: I had create and import an xml Party entry for partyId=_NA_... and then give it the role of carrier, add it to the shipment methods, etc. I am still not sure why, when I selected a different method, this was the data being search for in the database. I am building my site form scratch, instead of modifying the example data. -- View this message in context: http://ofbiz.135035.n4.nabble.com/violation-of-foreign-key-constraint-ORDER-ITSG-CSHM-tp4666547p4666595.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Add support for SQL SIMILAR TO?
Is support for SQL SIMILAR TO worth a JIRA? I read somewhere that it isn't as widely implemented across SQL servers but is supposedly part of the standard. I was hoping to be able to perform a BETWEEN/LIKE query.
Facebook OFBiz Logo
The post earlier requesting Facebook sign-in capabilities reminded me that the OFBiz logo that appears on the Facebook info page looks really ugly. The logo appears fine on the actual Wikipedia page but recently the logo appearing on Facebook seems as if the colors are inverted. Has anyone updated the logo on Wikipedia recently which may have caused this issue?
Re: Facebook OFBiz Logo
https://www.facebook.com/pages/Apache-OFBiz/105858406114935 On Wed, 2015-03-04 at 10:29 +0100, Pierre Smits wrote: Hi Christian, Can you post a url? Best 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 Wed, Mar 4, 2015 at 10:28 AM, Christian Carlow christian.car...@gmail.com wrote: The post earlier requesting Facebook sign-in capabilities reminded me that the OFBiz logo that appears on the Facebook info page looks really ugly. The logo appears fine on the actual Wikipedia page but recently the logo appearing on Facebook seems as if the colors are inverted. Has anyone updated the logo on Wikipedia recently which may have caused this issue?
Re: Facebook OFBiz Logo
Seems Facebook is just linking in Wikipedia pages for content like this. On Wed, 2015-03-04 at 13:53 +0100, Jacopo Cappellato wrote: Quoting from the page: This Page is automatically generated based on what Facebook users are interested in, and not affiliated with or endorsed by anyone associated with the topic On Mar 4, 2015, at 1:41 PM, Pierre Smits pierre.sm...@gmail.com wrote: Hmm. I wonder who created that facebook page... Best 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 Wed, Mar 4, 2015 at 1:37 PM, Christian Carlow christian.car...@gmail.com wrote: https://www.facebook.com/pages/Apache-OFBiz/105858406114935 On Wed, 2015-03-04 at 10:29 +0100, Pierre Smits wrote: Hi Christian, Can you post a url? Best 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 Wed, Mar 4, 2015 at 10:28 AM, Christian Carlow christian.car...@gmail.com wrote: The post earlier requesting Facebook sign-in capabilities reminded me that the OFBiz logo that appears on the Facebook info page looks really ugly. The logo appears fine on the actual Wikipedia page but recently the logo appearing on Facebook seems as if the colors are inverted. Has anyone updated the logo on Wikipedia recently which may have caused this issue?
Re: createInvoicesFromReturnShipment for purchase return working?
Felt I may not have been clear in previous message. This pertains to purchase shipments. createInvoicesFromReturnShipment seems to work fine for sales returns. On Wed, 2015-03-04 at 08:15 -0600, Christian Carlow wrote: Can anyone enlighten me on how to get createInvoicesFromReturnShipment working? For purchaseReturnFound it looks for ItemIssuances related to the shipment but I've found no way to create item issuances for it. AddItemsFromInventory.groovy handles the shipment Order Items page where issuances can be created but depends on ShipmentItems existing which do not exist and cannot be created for Purchase Return. Is there functionality somewhere else that sets up item issuances for the shipment?
createInvoicesFromReturnShipment working?
Can anyone enlighten me on how to get createInvoicesFromReturnShipment working? For purchaseReturnFound it looks for ItemIssuances related to the shipment but I've found no way to create item issuances for it. AddItemsFromInventory.groovy handles the shipment Order Items page where issuances can be created but depends on ShipmentItems existing which do not exist and cannot be created for Purchase Return. Is there functionality somewhere else that sets up item issuances for the shipment?
Re: ShipmentReceipt potential bugs and potential enhancements proposal
Hey Jacques, Sorry, missed this back in January. No progress has been made on these issues but I do need the ShipmentReceipt to ReturnItem association immediately. I'll create a JIRA for further discussion. The first part still seems relevant as well. AcctgTrans are created when ShipmentReceipts are created but none are created to undo if ShipmentReceipt is cancelled. As for allowing ShipmentReceipt quantity fields to be updated after creation, Pierre's suggestion to use the Return entities seems the best approach so it can be disregarded as an issue. On Wed, 2015-01-07 at 22:40 +0100, Jacques Le Roux wrote: HI Christian, What is the situation here? Jacques Le 24/08/2014 02:17, Christian Carlow a écrit : When a ShipmentReceipt is created, an AcctgTrans is also created with the shipmentId field set but not the receiptId. Should the AcctgTrans.receiptId also be set since it exists? Also, when a ShipmentReceipt is cancelled, no AcctgTrans and corresponding debit/credit AcctgTransEntry records are created. Should cancelling ShipmentReceipt also trigger AcctgTrans and AcctgTransEntry creation? Also, does it make sense add an enhancement to allow the ShipmentReceipt quantityAccepted and quantityRejected fields to be altered? Sometimes quantityRejected is not known until the shipment quantity is received in full using quantityAccepted then stock moved to a location that evaluates for rejects. If the location determines rejects, shouldn't it be allowed to deduct ShipmentReceipt quantityAccepted and add quantityRejected? If so, can it be assumed altering should also trigger the creation of AcctgTrans and AcctgTransEntry records? I already asked about ShipmentReceipt modifications back when first joining the community: http://ofbiz.135035.n4.nabble.com/How-to-modify-received-and-rejected-quantities-of-shipment-receipts-td4648430.html In the post, Pierre suggested creating a return instead of altering the ShipmentReceipt but neither ReturnItem nor the other return entities make reference to the ShipmentReceipt to which it is supposed to apply. If returns are the proper way of handling rejected quantity determined after ShipmentReceipt, shouldn't some return entity like ReturnItem make reference to the ShipmentReceipt entity so that the rejected quantity can be determined? Waiting for community feedback before creating JIRAs.
Same action incorrectly applied to all promotion items for a single rule with no conditions and multiple product-specific actions
I created multiple discount promo actions for a single rule with no conditions which resulted in a single action being applied to all promotion items instead of only the one with a matching productId. Am I missing something or is this a bug?
Production run inventory tracking
Should production runs be extended to allow for inventory to be tracked within them? The goal would be to determine where pieces located to know the work load of a department. Tasks don't support location tracking but they do associate to FixedAssets which associate to Facility
Re: OrderItemShipGroupAssoc.lineName field worth a JIRA?
Thanks Pierre, https://issues.apache.org/jira/browse/OFBIZ-6056 On Wed, 2015-02-04 at 00:24 +0100, Pierre Smits wrote: Given that it might be a useful improvement to the feature set of OFBiz it is worth a JIRA of the type wish/improvement. You decide. Best 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 Tue, Feb 3, 2015 at 3:27 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: That could maybe be useful to others if it's documented in at least the data model (description of the field and its reason to be) Jacques Le 16/01/2015 14:40, Christian Carlow a écrit : Hey Jacques, Sorry, it was late when asked. I'm referring to cases when a customer submits an order they create offline with their own order, item, and item schedule names. For example, a company might submit an order named po1 for an item with 3 schedules named 0801, 0802, 0803. The customer expects the schedule names to appear for each shipment for their own internal tracking. In this case the orderItemSeqId and shipGroupSeqId are inadequate for representing the item schedule to them. On Fri, 2015-01-16 at 13:27 +0100, Jacques Le Roux wrote: Could you please elaborate what exactly is track customers-assign order item schedule names? Jacques Le 16/01/2015 05:18, Christian Carlow a écrit : Is adding a field like OrderItemShipGroupAssoc.lineName to track customers-assign order item schedule names worth a JIRA?
Is trunk supposed to fail for OpenJDK 1.8 on Fedora 21?
prepare:
classes:
[javac17] Compiling 141 source files
to /home/anon/workspace/ofbiz/framework/entity/build/classes
[javac17] warning: [options] bootstrap class path not set in
conjunction with -source 1.7
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/GenericDelegator.java:1415:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] public int storeAll(ListGenericValue values, boolean
doCacheClear, boolean createDummyFks) throws GenericEntityException {
[javac17]^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/model/ModelViewEntity.java:1340:
error: variable operator might not have been initialized
[javac17] throw new IllegalArgumentException([ +
this.viewEntityCondition.modelViewEntity.getEntityName() + ]: Could not
find an entity operator for the name: + this.operator);
[javac17]
^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:329:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] delegator.storeAll(valuesToWrite, doCacheClear,
createDummyFks);
[javac17] ^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:379:
warning: [deprecation] Configuration() in Configuration has been deprecated
[javac17] Configuration config = new
Configuration();
[javac17]^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:498:
warning: [deprecation] removeAll(List? extends GenericEntity,boolean) in
Delegator has been deprecated
[javac17]
delegator.removeAll(valuesToDelete, doCacheClear);
[javac17] ^
[javac17] Note: Some input files use unchecked or unsafe operations.
[javac17] Note: Recompile with -Xlint:unchecked for details.
[javac17] 1 error
[javac17] 4 warnings
BUILD FAILED
/home/anon/workspace/ofbiz/build.xml:421: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/build.xml:438: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/macros.xml:39: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/common.xml:91: Compile failed; see the
compiler error output for details.
Re: Is trunk supposed to fail for OpenJDK 1.8 on Fedora 21?
Awesome. Thanks Adrian.
On Thu, 2015-01-29 at 10:48 -0800, Adrian Crum wrote:
Fixed in rev 1655795. Thanks!
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/29/2015 9:53 AM, Christian Carlow wrote:
prepare:
classes:
[javac17] Compiling 141 source files
to /home/anon/workspace/ofbiz/framework/entity/build/classes
[javac17] warning: [options] bootstrap class path not set in
conjunction with -source 1.7
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/GenericDelegator.java:1415:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] public int storeAll(ListGenericValue values, boolean
doCacheClear, boolean createDummyFks) throws GenericEntityException {
[javac17]^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/model/ModelViewEntity.java:1340:
error: variable operator might not have been initialized
[javac17] throw new IllegalArgumentException([ +
this.viewEntityCondition.modelViewEntity.getEntityName() + ]: Could not
find an entity operator for the name: + this.operator);
[javac17]
^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:329:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] delegator.storeAll(valuesToWrite, doCacheClear,
createDummyFks);
[javac17] ^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:379:
warning: [deprecation] Configuration() in Configuration has been deprecated
[javac17] Configuration config = new
Configuration();
[javac17]^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:498:
warning: [deprecation] removeAll(List? extends GenericEntity,boolean) in
Delegator has been deprecated
[javac17]
delegator.removeAll(valuesToDelete, doCacheClear);
[javac17] ^
[javac17] Note: Some input files use unchecked or unsafe operations.
[javac17] Note: Recompile with -Xlint:unchecked for details.
[javac17] 1 error
[javac17] 4 warnings
BUILD FAILED
/home/anon/workspace/ofbiz/build.xml:421: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/build.xml:438: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/macros.xml:39: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/common.xml:91: Compile failed; see the
compiler error output for details.
Re: Is trunk supposed to fail for OpenJDK 1.8 on Fedora 21?
Build worked after reverting to Oracle's jdk 1.7
On Thu, 2015-01-29 at 11:53 -0600, Christian Carlow wrote:
prepare:
classes:
[javac17] Compiling 141 source files
to /home/anon/workspace/ofbiz/framework/entity/build/classes
[javac17] warning: [options] bootstrap class path not set in
conjunction with -source 1.7
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/GenericDelegator.java:1415:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] public int storeAll(ListGenericValue values, boolean
doCacheClear, boolean createDummyFks) throws GenericEntityException {
[javac17]^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/model/ModelViewEntity.java:1340:
error: variable operator might not have been initialized
[javac17] throw new IllegalArgumentException([ +
this.viewEntityCondition.modelViewEntity.getEntityName() + ]: Could not
find an entity operator for the name: + this.operator);
[javac17]
^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:329:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] delegator.storeAll(valuesToWrite, doCacheClear,
createDummyFks);
[javac17] ^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:379:
warning: [deprecation] Configuration() in Configuration has been deprecated
[javac17] Configuration config = new
Configuration();
[javac17]^
[javac17]
/home/anon/workspace/ofbiz/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:498:
warning: [deprecation] removeAll(List? extends GenericEntity,boolean) in
Delegator has been deprecated
[javac17]
delegator.removeAll(valuesToDelete, doCacheClear);
[javac17] ^
[javac17] Note: Some input files use unchecked or unsafe operations.
[javac17] Note: Recompile with -Xlint:unchecked for details.
[javac17] 1 error
[javac17] 4 warnings
BUILD FAILED
/home/anon/workspace/ofbiz/build.xml:421: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/build.xml:438: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/macros.xml:39: The following error occurred
while executing this line:
/home/anon/workspace/ofbiz/common.xml:91: Compile failed; see the
compiler error output for details.
Re: OrderItemShipGroupAssoc.lineName field worth a JIRA?
Hey Jacques, Sorry, it was late when asked. I'm referring to cases when a customer submits an order they create offline with their own order, item, and item schedule names. For example, a company might submit an order named po1 for an item with 3 schedules named 0801, 0802, 0803. The customer expects the schedule names to appear for each shipment for their own internal tracking. In this case the orderItemSeqId and shipGroupSeqId are inadequate for representing the item schedule to them. On Fri, 2015-01-16 at 13:27 +0100, Jacques Le Roux wrote: Could you please elaborate what exactly is track customers-assign order item schedule names? Jacques Le 16/01/2015 05:18, Christian Carlow a écrit : Is adding a field like OrderItemShipGroupAssoc.lineName to track customers-assign order item schedule names worth a JIRA?
Re: WorkOrderItemFulfillment.shipGroupSeqId added as part of primary key?
Hey Jacques, Yes, I was going to use the functionality to generate a department load report to indicate what and when production work needs to take place from customer orders. The functionality is especially important for displaying assembly elements of order items. For example, for an order for 10 of an item requiring 2 of an assembly element scheduled 5 one day and 5 for another, there doesn't seem to be an easy way to determine how much of the assembly element needs to be produced to meet the schedule due date. The report uses workEffort.estimatedCompletionDate as the due date but requires a separate WorkEffort for each OrderItemShipGroupAssoc. But having more than one production run per OrderItem is not supported due to WorkOrderItemFulfillment primary keys. On Fri, 2015-01-16 at 13:26 +0100, Jacques Le Roux wrote: I guess if you asked this question is because you have a need? If it's the case, could you please explain it? Examples always ease to think about a topic ;) Jacques Le 16/01/2015 02:10, Christian Carlow a écrit : Does an additional entity need to be created to extend WorkOrderItemFulfillment to support relations to more than one OrderItemShipGroupAssoc? WorkOrderItemFulfillment excludes shipGroupSeqId from the primary key so only 1 production run to be related OrderItem. Should something like WorkOrderShipFulfillment be created as a copy of WorkOrderItemFulfillment but includes shipGroupSeqId as part of the primary key?
OrderItemShipGroupAssoc.lineName field worth a JIRA?
Is adding a field like OrderItemShipGroupAssoc.lineName to track customers-assign order item schedule names worth a JIRA?
Find by orderName supported?
Can orders be searched by orderName? I didn't find a field at ordermgr/control/findorders. Searching by orderName over orderId is more relevant when customers specify the name of their order. If not is it worth a JIRA?
WorkOrderItemFulfillment.shipGroupSeqId added as part of primary key?
Does an additional entity need to be created to extend WorkOrderItemFulfillment to support relations to more than one OrderItemShipGroupAssoc? WorkOrderItemFulfillment excludes shipGroupSeqId from the primary key so only 1 production run to be related OrderItem. Should something like WorkOrderShipFulfillment be created as a copy of WorkOrderItemFulfillment but includes shipGroupSeqId as part of the primary key?
Product revision tracking supported?
Is there a way to track product revisions OOTB? I added a revision field to the Product entity because I could not find anything. If its not supported, is it worth a JIRA?
Error when clicking accounting transaction submenu items incorrectly rendered as anchor instead of hidden-form
Does anyone know why menu items might be rendered as anchor instead of hidden-form when set link-type is not set? Specifically, the submenu items at accounting/control/EditAcctgTrans are rendered as anchor so when clicked it throws an error related to the parameters not being passed securely. I checked the demo site and the links are rendering as hidden form. To reproduce: 1. Find and click a transaction at Accounting-Organization GL Settings-Accounting Transactions 2. Click a submenu links like Revert Accounting Transaction An error should be thrown after step 2. Hovering over the link shows that the parameters are being passed with GET rather than POST method.
Re: Are purchase orders supposed to calculate taxes?
Thanks Scott, I read that post too but wanted to make sure it was still valid since it was so old. I'll create a JIRA to remove tax calculations from purchase orders. On 12/29/2014 10:13 PM, Scott Gray wrote: http://markmail.org/message/mzbu3i336uu6csps As always, there's plenty of previous discussion if you search for purchase order tax on ofbiz.markmail.org Regards Scott On Tue, Dec 30, 2014 at 3:41 PM, Christian Carlow christian.car...@gmail.com wrote: If Accounting-Tax Authorities-Product Rates exists for a category of a purchase order product, taxes are applied to the purchase order. Is this correct or should taxes only apply to sales order? Isn't purchase order sales tax supposed to be manually added as adjustment?
Are purchase orders supposed to calculate taxes?
If Accounting-Tax Authorities-Product Rates exists for a category of a purchase order product, taxes are applied to the purchase order. Is this correct or should taxes only apply to sales order? Isn't purchase order sales tax supposed to be manually added as adjustment?
Re: Order Items are associated with neither requirements nor productions runs created by mrp events of type sales order shipment
Hey Pierre, This is not related to any demo data. I just created my own products of those types and orders for them. The marketing packages and configurable goods don't lead to the creation of requirements; they only lead to creation of production runs which are also linked to orders. Requirements are created by the MRP for orders of route linked products. Production runs are created by those MRP created requirements once approved. The problem is that the production runs aren't linked to the order like they are for the marketing package and configurable goods. It seems the orders should be linked to the requirements (appear at Order-Requirements-Orders) to provide the data for linking the production runs to the order. On 12/25/2014 03:36 PM, Pierre Smits wrote: HI Christian, In order to help me and others understand, could you elaborate with which product you are trying to achieve this? Is this related to a product in the demo data set? Also, With which products did you create the orders for the marketing packages and/or the configurable goods, that led to the creation of the requirements? It might help understanding the use case. Best 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 Mon, Dec 22, 2014 at 6:41 PM, Christian Carlow christian.car...@gmail.com wrote: Order Items are missing from Order - Requirement - Orders tab of requirements created by MRP events of type Sales order shipment. Because they are missing, production runs created by requirements when approved also lack order item association. After approving the requirement, I expected to see the production run created linked to order that caused its creation such as what happens for Configurable Goods and Marketing Packages. Is there a reason order item associations to requirements and production runs created by mrp events should not be implemented in a similar manner as those product types?
Order Items are associated with neither requirements nor productions runs created by mrp events of type sales order shipment
Order Items are missing from Order - Requirement - Orders tab of requirements created by MRP events of type Sales order shipment. Because they are missing, production runs created by requirements when approved also lack order item association. After approving the requirement, I expected to see the production run created linked to order that caused its creation such as what happens for Configurable Goods and Marketing Packages. Is there a reason order item associations to requirements and production runs created by mrp events should not be implemented in a similar manner as those product types?
One time fee adjustments possible?
Does OFBiz support one-time fee adjustments being invoiced without splitting the amount for each of the shipments through prorating? Users need the ability to add one-time fees and be invoiced only once for the total amount for only one of the shipments of an order item? Product Stores allow for prorating to be deactivated for shipping and tax adjustments but I haven't found an option for controlling other adjustments yet. But it seems better to have a prorate flag for the OrderAdjustment entity which can be chosen when adding to the cart. Is this worthy of a JIRA?
Re: One time fee adjustments possible?
Also, there seems to be no way to manually add an adjustment for an order item (only for a ship group). Is this functionality also worthy of a JIRA? On 10/10/2014 08:15 AM, Christian Carlow wrote: Does OFBiz support one-time fee adjustments being invoiced without splitting the amount for each of the shipments through prorating? Users need the ability to add one-time fees and be invoiced only once for the total amount for only one of the shipments of an order item? Product Stores allow for prorating to be deactivated for shipping and tax adjustments but I haven't found an option for controlling other adjustments yet. But it seems better to have a prorate flag for the OrderAdjustment entity which can be chosen when adding to the cart. Is this worthy of a JIRA?
Shouldn't the paginate bar appear regardless of the listSize gt viewSize?
Does anyone have a good reason why the paginate bar should disappear when the listSize gt viewSize? The bar is useful for determining the record count which can't be determined when it disappears due to the condition being met. Anyone else think this is worthy of a JIRA?
Is there a reason CustomTimePeriod Date types are not Timestamp?
Does anyone know why CustomTimePeriod fromDate and thruDate are of type date instead of timestamp? Because the fields are of type date, it causes issues when joining the it for date comparison for view-entities. For example: view-entity entity-name=OrderHeaderAndCustomTimePeriod package-name= member-entity entity-alias=OH entity-name=OrderHeader/ member-entity entity-alias=CTP entity-name=CustomTimePeriod/ alias-all entity-alias=OH/ alias-all entity-alias=CTP/ entity-condition condition-expr field-name=orderDate entity-alias=OH operator=greater-equals rel-field-name=fromDate rel-entity-alias=CTP/ condition-expr field-name=orderDate entity-alias=OH operator=less-equals rel-field-name=thruDate rel-entity-alias=CTP/ /entity-condition /view-entity The problem occurs when the OrderHeader.orderDate falls on the last day of the CustomTimePeriod.thruDate because the CustomTimePeriod.thruDate is converted to Timestamp but with time 00:00:00.000. Changing the CustomTimePeriod Date types to Timestamp seems like the easiest but I'm sure Accounting code will have to be changed.
@htmlTemplate.renderDateTimeField icon buttons disappear on some pages after refresh
When some pages that use @htmlTemplate.renderDateTimeField are refreshed the icons associated with those fields start to disappear. For example, the ShipBeforeDate fields of the ship groups at ordermgr/control/editOrderItems disappear one at a time for each refresh. Another example of this happening is at ordermgr/control/EditQuote for the QuoteIssueDate field but oddly the ValidFromDate and ValidThruDate don't exhibit the behavior even though they are the same type of field. Also, the statusId field of the ordermgr/control/EditQuote also gets unset after the first refresh which may be related. I'm not sure if this behavior is isolated to the @htmlTemplate.renderDateTimeField or also occuring for form-widget date-time type=timestamp/ fields as well. It's minor but still seems to be a bug. Is it worth creating a JIRA?
Having condition for fields using functions supported?
Is there anyway to implement a having condition for a field using a function? Such as below using SUM function?: SELECT te.time_entry_id, te.quantity_produced, sum(te2.quantity_produced) FROM time_entry te left outer join time_entry_assoc tea on te.time_entry_id = tea.time_entry_id_to left outer join time_entry te2 on tea.time_entry_id = te2.time_entry_id GROUP BY te.time_entry_id HAVING te.quantity_produced = sum(te2.quantity_produced)
ShipmentReceipt potential bugs and potential enhancements proposal
When a ShipmentReceipt is created, an AcctgTrans is also created with the shipmentId field set but not the receiptId. Should the AcctgTrans.receiptId also be set since it exists? Also, when a ShipmentReceipt is cancelled, no AcctgTrans and corresponding debit/credit AcctgTransEntry records are created. Should cancelling ShipmentReceipt also trigger AcctgTrans and AcctgTransEntry creation? Also, does it make sense add an enhancement to allow the ShipmentReceipt quantityAccepted and quantityRejected fields to be altered? Sometimes quantityRejected is not known until the shipment quantity is received in full using quantityAccepted then stock moved to a location that evaluates for rejects. If the location determines rejects, shouldn't it be allowed to deduct ShipmentReceipt quantityAccepted and add quantityRejected? If so, can it be assumed altering should also trigger the creation of AcctgTrans and AcctgTransEntry records? I already asked about ShipmentReceipt modifications back when first joining the community: http://ofbiz.135035.n4.nabble.com/How-to-modify-received-and-rejected-quantities-of-shipment-receipts-td4648430.html In the post, Pierre suggested creating a return instead of altering the ShipmentReceipt but neither ReturnItem nor the other return entities make reference to the ShipmentReceipt to which it is supposed to apply. If returns are the proper way of handling rejected quantity determined after ShipmentReceipt, shouldn't some return entity like ReturnItem make reference to the ShipmentReceipt entity so that the rejected quantity can be determined? Waiting for community feedback before creating JIRAs.
Re: FOP reports cann't refresh in the browser!
He is talking about parameters for reports generated by FOP being lost after a browser refresh. This issue still exists in the trunk. Specify a date range for any one of the reports on the OrderPurchaseReportOptions page and notice the date range parameters along with any others are lost once the report is refreshed. So far I've only been able to resolved by passing as fields submitted as GET instead of POST parameters but I don't like it as a solution. POST parameters should be preserved on browser refresh. On 08/05/2014 10:22 AM, Pierre Smits wrote: Sharan, You can paste the second part of the url 'ordermgr/control/OrderPurchaseReportOptions' into the demo environments of the project to get an idea of the issue. But nevertheless more information provided will aid in understanding the problem better. 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 Tue, Aug 5, 2014 at 4:23 PM, Sharan-F sharan.f...@gmail.com wrote: Hi Please can you give us a bit more information like what version of ofbiz is this happening in? The link you included is your own local host so I cant access it. Also what parameters did you use? This information will help us try to recreate the issue. Thanks Sharan -- View this message in context: http://ofbiz.135035.n4.nabble.com/FOP-reports-cann-t-refresh-in-the-browser-tp4653181p4653183.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: FOP reports cann't refresh in the browser!
Issue: OFBIZ-5700 https://issues.apache.org/jira/browse/OFBIZ-5700 On 08/05/2014 01:27 PM, Jacques Le Roux wrote: If there is not already a Jira issue, please someone create it, thanks Jacques Le 05/08/2014 18:07, Christian Carlow a écrit : He is talking about parameters for reports generated by FOP being lost after a browser refresh. This issue still exists in the trunk. Specify a date range for any one of the reports on the OrderPurchaseReportOptions page and notice the date range parameters along with any others are lost once the report is refreshed. So far I've only been able to resolved by passing as fields submitted as GET instead of POST parameters but I don't like it as a solution. POST parameters should be preserved on browser refresh. On 08/05/2014 10:22 AM, Pierre Smits wrote: Sharan, You can paste the second part of the url 'ordermgr/control/OrderPurchaseReportOptions' into the demo environments of the project to get an idea of the issue. But nevertheless more information provided will aid in understanding the problem better. 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 Tue, Aug 5, 2014 at 4:23 PM, Sharan-F sharan.f...@gmail.com wrote: Hi Please can you give us a bit more information like what version of ofbiz is this happening in? The link you included is your own local host so I cant access it. Also what parameters did you use? This information will help us try to recreate the issue. Thanks Sharan -- View this message in context: http://ofbiz.135035.n4.nabble.com/FOP-reports-cann-t-refresh-in-the-browser-tp4653181p4653183.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Shipping Accounts supported
Does OFBiz support shipping accounts for situations when the company ships the good but uses the customer shipping account for the shipping costs?
France geo questions
When choosing France as the country for creating contact info for a party, the state/province field is not populated. One reason for this is that the FRA record in the CountryAddressFormat entity does not have the geoAssocTypeId set. However, even when the geoAssocTypeId is set to REGIONS, the list is still not populated because the the corresponding Geo records geoTypeId is not set to one of STATE, PROVINCE, COUNTY, or MUNICIPALITY as required by getAssociatedStateList service. Instead they are set to REGION and COUNTY_CITY. This http://en.wikipedia.org/wiki/ISO_3166-2:FR explains France has 22 metro regions and 96 metro depts within the regions. Can someone advise how to correctly populate the state/province list? Should only the 22 regions be listed or should the 96 depts be listed with the region also indicated? Also should the REGION and COUNTRY_CITY geoTypeIds be added to the getAssociatedStateList service as compatible types? Also, the geoId of the France regions appear to be incorrect according to the wikipedia article above. For example, the GeoId of Alsace is FR-ALS however it is indicated as FR-A in the wikipedia article. Should these also be correct for consistency with ISO?
Re: France geo questions
I suppose populating the state/province list isn't really necessary so long as the country doesn't have cities that are named the same such as in USA. Therefore if France doesn't have more than one city named the same then my question can be disregarded. If the same rule applies to the other geo JIRA issues I created, which I assume is the case for Israel being so small, then they may potentially need to be reverted. The service doesn't require the state/province field so leaving the list empty doesn't cause any problems. On 04/01/2014 10:30 AM, Christian Carlow wrote: When choosing France as the country for creating contact info for a party, the state/province field is not populated. One reason for this is that the FRA record in the CountryAddressFormat entity does not have the geoAssocTypeId set. However, even when the geoAssocTypeId is set to REGIONS, the list is still not populated because the the corresponding Geo records geoTypeId is not set to one of STATE, PROVINCE, COUNTY, or MUNICIPALITY as required by getAssociatedStateList service. Instead they are set to REGION and COUNTY_CITY. This http://en.wikipedia.org/wiki/ISO_3166-2:FR explains France has 22 metro regions and 96 metro depts within the regions. Can someone advise how to correctly populate the state/province list? Should only the 22 regions be listed or should the 96 depts be listed with the region also indicated? Also should the REGION and COUNTRY_CITY geoTypeIds be added to the getAssociatedStateList service as compatible types? Also, the geoId of the France regions appear to be incorrect according to the wikipedia article above. For example, the GeoId of Alsace is FR-ALS however it is indicated as FR-A in the wikipedia article. Should these also be correct for consistency with ISO?
Re: France geo questions
Also, with regards to my question about the France geoIds not matching those of ISO codes, the same incompatibility exists for USA state geoIds so it isn't really an issue either unless the community agrees they should match which entails more geo work. On 04/01/2014 11:50 AM, Christian Carlow wrote: I suppose populating the state/province list isn't really necessary so long as the country doesn't have cities that are named the same such as in USA. Therefore if France doesn't have more than one city named the same then my question can be disregarded. If the same rule applies to the other geo JIRA issues I created, which I assume is the case for Israel being so small, then they may potentially need to be reverted. The service doesn't require the state/province field so leaving the list empty doesn't cause any problems. On 04/01/2014 10:30 AM, Christian Carlow wrote: When choosing France as the country for creating contact info for a party, the state/province field is not populated. One reason for this is that the FRA record in the CountryAddressFormat entity does not have the geoAssocTypeId set. However, even when the geoAssocTypeId is set to REGIONS, the list is still not populated because the the corresponding Geo records geoTypeId is not set to one of STATE, PROVINCE, COUNTY, or MUNICIPALITY as required by getAssociatedStateList service. Instead they are set to REGION and COUNTY_CITY. This http://en.wikipedia.org/wiki/ISO_3166-2:FR explains France has 22 metro regions and 96 metro depts within the regions. Can someone advise how to correctly populate the state/province list? Should only the 22 regions be listed or should the 96 depts be listed with the region also indicated? Also should the REGION and COUNTRY_CITY geoTypeIds be added to the getAssociatedStateList service as compatible types? Also, the geoId of the France regions appear to be incorrect according to the wikipedia article above. For example, the GeoId of Alsace is FR-ALS however it is indicated as FR-A in the wikipedia article. Should these also be correct for consistency with ISO?
Re: France geo questions
Thanks Jacques, I'll be more diligent when creating geo issues from now on. On 04/01/2014 12:54 PM, Jacques Le Roux wrote: There are cities names the same in France, but the postal code is the justice of the peace We can keep Israel geo data, can't hurt... I'd have to check geoIds againts ISO codes, but I guess if anybody complains then it must be OK (at least for now) Jacques Le 01/04/2014 18:53, Christian Carlow a écrit : Also, with regards to my question about the France geoIds not matching those of ISO codes, the same incompatibility exists for USA state geoIds so it isn't really an issue either unless the community agrees they should match which entails more geo work. On 04/01/2014 11:50 AM, Christian Carlow wrote: I suppose populating the state/province list isn't really necessary so long as the country doesn't have cities that are named the same such as in USA. Therefore if France doesn't have more than one city named the same then my question can be disregarded. If the same rule applies to the other geo JIRA issues I created, which I assume is the case for Israel being so small, then they may potentially need to be reverted. The service doesn't require the state/province field so leaving the list empty doesn't cause any problems. On 04/01/2014 10:30 AM, Christian Carlow wrote: When choosing France as the country for creating contact info for a party, the state/province field is not populated. One reason for this is that the FRA record in the CountryAddressFormat entity does not have the geoAssocTypeId set. However, even when the geoAssocTypeId is set to REGIONS, the list is still not populated because the the corresponding Geo records geoTypeId is not set to one of STATE, PROVINCE, COUNTY, or MUNICIPALITY as required by getAssociatedStateList service. Instead they are set to REGION and COUNTY_CITY. This http://en.wikipedia.org/wiki/ISO_3166-2:FR explains France has 22 metro regions and 96 metro depts within the regions. Can someone advise how to correctly populate the state/province list? Should only the 22 regions be listed or should the 96 depts be listed with the region also indicated? Also should the REGION and COUNTRY_CITY geoTypeIds be added to the getAssociatedStateList service as compatible types? Also, the geoId of the France regions appear to be incorrect according to the wikipedia article above. For example, the GeoId of Alsace is FR-ALS however it is indicated as FR-A in the wikipedia article. Should these also be correct for consistency with ISO?
Value of QuantityBreak and QuantityBreakType entities?
Can someone explain the value of the QuantityBreak and QuantityBreakType entities? Is the QuantityBreakType entity necessary? Why wouldn't the same quantity range be used regardless of the break types? Also, I noticed that the Shipping Estimates tab on the Catalog-Store app doesn't even reuse existing quantityBreaks with the same range and type. Isn't the point of having the QuanitityBreak entity to reuse the ids existing ranges? I'm trying to implement quantity ranges for QuoteItems and the QuantityBreak entities are introducing more complexity than seems necessary. I think I remember someone mentioning on JIRA that QuantityBreaks were something that should possibly be cleaned up.
Form Widget check all-checked=true not checking title checkbox
Hey community, When using form widget element check all-checked=true the checkbox included in the title that controls checking and unchecking all checkboxes does not get checked. Am I missing something or is this a bug worthy of a JIRA issue?
Re: What is the purpose of Routing Task Deliverable Products?
I'm moving forward since no one suggested any issues. I have a feeling that are aren't many out there using OFBiz for manufacturing and no one seems very familiar other than Pierre and Jacopo. A ProductReason entity will be used in place of the ProductAssocVarianceReason entity suggested in my previous post. The ProductReason entity will reference the varianceReasonId of the VarianceReason entity. I don't want to get too off track but it seems to make sense to generalize the VarianceReason entity into just a Reason entity with type and parent like other similar entities. I might include this in the manufacturing patches to come if no one is against it and it isn't too inconvenient. On 03/10/2014 12:34 PM, Christian Carlow wrote: Since by-product reason variance products wont exist ahead of time, they can't be related in the WorkEffortGoodStandard entity as is the way it is currently done. Instead, I think logic should be added to distinguish between PRUN_PROD_DELIV for the production run and its tasks and when used for a task, derive the variance reasons. In other words, use productId of ProductAssoc for WorkEffortGoodStandard for deliverable products which triggers the retrieval of the variance reasons defined in ProductAssocVarianceReason. Anyone see potential issues with this? On 03/10/2014 12:10 PM, Christian Carlow wrote: To provide the varianceReason drop down suggested in the previous post, and entity such as ProductAssocVarianceReason could be created for relating varianceReasons to the productId of ProductAssoc. Once the drop down is provided it, the ProductAssocVarianceReason can be used to automatically create new variant by-product records and related them in the ProductAssoc similar to the virtual variant auto-create methods. On 03/10/2014 11:56 AM, Christian Carlow wrote: If the reason field of ProductAssoc were changed to reference the VarianceReason entity instead of being an open entry field, then the ProductAssoc entity could be used for Deliverable Products definitions and the reasons could the only thing that appears in the drop down. Anyone predict limitations or problems with such a suggestion? On 03/10/2014 11:44 AM, Christian Carlow wrote: Can anyone think of reasons against changing the Routing Task Deliverable Products to reference ProductAssoc instead of Product? If BYPRODUCT and PRODUCT_REJECT were added as ProductAssocType then the entity could be used for implementing more advanced quantity checking rules when by-products are declared. On 03/10/2014 09:43 AM, Christian Carlow wrote: Thanks Pierre, I just discovered that Routing Task Deliverable Products controls the productId field of the production run inventory declaration form. Whenever a deliverable product is specified then the declaration form productId field changes to a drop down with only those deliverable products specified listed. If no deliverable products are specified then the productId becomes a lookup and allows any products to be declared. I was unaware deliverable products could limit the declaration form productIds. This discovery will allow me to progress further with OFBIZ-5568 https://issues.apache.org/jira/browse/OFBIZ-5568. It should be mentioned that preventing products other than those specified as deliverable products is limited to the front end in which a drop down appears only listing those deliverable products and that no backend code exist to guarantee that users cannot change the dropdown values using something like Firebug to hack the system and declare inventory for a product other than the ones specified as deliverable products. In other words, if I create a deliverable product PEPPERS for the DEFAULT_TASK but I use something like Firebug to change the drop down list value to PEPPERS-G, then no logic exists in the backend to prevent PEPPERS-G from being created. I think such prevention logic should be implemented in the backend as well. On 03/10/2014 09:12 AM, Pierre Smits wrote: Christian, Routing Task Deliverable Products are the products that can be declared as a result of the execution of the task. You could regard these as a the by-products of the production run. In an earlier thread I referenced yeast-residiue as a by product. In the beer brewing process this is (often) the output (beside beer, obviously) of the fermentation action, task or process step. Regards, Pierre Smits *ORRTIZ.COMhttp://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Form widget drop-down entity-option can have OR contraint applied?
I'm creating a form widget with a drop-down and need the entity-options to be contrained with an OR condition. This doesn't seem to be supported. Can someone confirm and should a JIRA issue be created?
Re: Form widget drop-down entity-option can have OR contraint applied?
Disregard. IN operator handles it. On 03/11/2014 02:30 PM, Christian Carlow wrote: I'm creating a form widget with a drop-down and need the entity-options to be contrained with an OR condition. This doesn't seem to be supported. Can someone confirm and should a JIRA issue be created?
Do form widgets support screenlet-title-bar buttons used throughout those implemented in FTL?
Many FTL forms use ul tags within the screenlet-title-bar tags to provide buttons in the title bar and are aligned to the right. Can this also be done for form widgets? I grepped for screenlet-title-bar and Forms.xml but got no results.
Demo site running slowly
Just letting whomever it concerns know the demo site is running slowly. I waited up to 5 minutes for the page to load but got nothing.
Re: Demo site running slowly
Actually it times out. On 03/11/2014 05:05 PM, Christian Carlow wrote: Just letting whomever it concerns know the demo site is running slowly. I waited up to 5 minutes for the page to load but got nothing.
What is the purpose of Routing Task Deliverable Products?
Can someone explain the purpose of Routing Task Deliverable Products? Are deliverable products supposed to be documents or actual products? I added a deliverable product record for the first task of a route but I do not notice any different in data after running and completing the production run.
Re: What is the purpose of Routing Task Deliverable Products?
Thanks Pierre, I just discovered that Routing Task Deliverable Products controls the productId field of the production run inventory declaration form. Whenever a deliverable product is specified then the declaration form productId field changes to a drop down with only those deliverable products specified listed. If no deliverable products are specified then the productId becomes a lookup and allows any products to be declared. I was unaware deliverable products could limit the declaration form productIds. This discovery will allow me to progress further with OFBIZ-5568 https://issues.apache.org/jira/browse/OFBIZ-5568. It should be mentioned that preventing products other than those specified as deliverable products is limited to the front end in which a drop down appears only listing those deliverable products and that no backend code exist to guarantee that users cannot change the dropdown values using something like Firebug to hack the system and declare inventory for a product other than the ones specified as deliverable products. In other words, if I create a deliverable product PEPPERS for the DEFAULT_TASK but I use something like Firebug to change the drop down list value to PEPPERS-G, then no logic exists in the backend to prevent PEPPERS-G from being created. I think such prevention logic should be implemented in the backend as well. On 03/10/2014 09:12 AM, Pierre Smits wrote: Christian, Routing Task Deliverable Products are the products that can be declared as a result of the execution of the task. You could regard these as a the by-products of the production run. In an earlier thread I referenced yeast-residiue as a by product. In the beer brewing process this is (often) the output (beside beer, obviously) of the fermentation action, task or process step. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: Possible Issue - appendOrderItem Service
This reminded me of my almost forgotten OFBIZ-5423 https://issues.apache.org/jira/browse/OFBIZ-5423 I created because the same form does not allow variant selections when virtual products are added which is required when adding items to the shopping cart before the order exists. Therefore the virtual product itself is added to the order which isn't supposed to be allowed to happen. I mentioned this to provide another example where this form is lacking and express likelihood of it containing more issues such as the one you mentioned. On 03/10/2014 09:45 AM, Adrian Crum wrote: Please create a Jira issue. Adrian Crum Sandglass Software www.sandglass-software.com On 3/10/2014 7:10 AM, darrell73s wrote: Hi Folks, I'm running 12.04.02, I'm using the appendOrderItem service in the order application. The service definition allows for an optional Map of order item attributes called itemAttributesMap. However, the addItemToApprovedOrder method in OrderServices isn't using that map from the service context, thus the order item attributes aren't being added to the item when it's added to the order. I've checked the addItemToApprovedOrder method in the trunk OrderServices, and the itemAttributesMap is not being utilized there either. I can fix and submit a patch (see implementation in updateOrderItems service), but wanted to ensure this wasn't a design choice. Thanks, Darrell -- View this message in context: http://ofbiz.135035.n4.nabble.com/Possible-Issue-appendOrderItem-Service-tp4648984.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Help clarifying proper use of production run quantity produced and rejected.
Production run declarations allow produced and rejected quantities to be declared but because of the various by-product scenarios that may exist, ambiguity is preventing me from determining how to properly use the fields. For example, for Pierre's yeast-residue brewery example, the product is being produced but it isn't the product the production run was created to produce. Therefore I'm not sure if the resulting yeast-residue should constitute quantity produced. The same ambiguity applies to Jacopo's defective tortilla scenario. Technically the tortilla isn't the same as the pizza the production run is meant to produce so declaring it as quantity rejected seems possibly correct. Are these fields supposed to be used only for tracking the goods quantities or are they meant to indicate quantities for non-production run goods as well? This ambiguity is preventing me from implementing additional functionality required by the customer.
Re: What is the purpose of Routing Task Deliverable Products?
Can anyone think of reasons against changing the Routing Task Deliverable Products to reference ProductAssoc instead of Product? If BYPRODUCT and PRODUCT_REJECT were added as ProductAssocType then the entity could be used for implementing more advanced quantity checking rules when by-products are declared. On 03/10/2014 09:43 AM, Christian Carlow wrote: Thanks Pierre, I just discovered that Routing Task Deliverable Products controls the productId field of the production run inventory declaration form. Whenever a deliverable product is specified then the declaration form productId field changes to a drop down with only those deliverable products specified listed. If no deliverable products are specified then the productId becomes a lookup and allows any products to be declared. I was unaware deliverable products could limit the declaration form productIds. This discovery will allow me to progress further with OFBIZ-5568 https://issues.apache.org/jira/browse/OFBIZ-5568. It should be mentioned that preventing products other than those specified as deliverable products is limited to the front end in which a drop down appears only listing those deliverable products and that no backend code exist to guarantee that users cannot change the dropdown values using something like Firebug to hack the system and declare inventory for a product other than the ones specified as deliverable products. In other words, if I create a deliverable product PEPPERS for the DEFAULT_TASK but I use something like Firebug to change the drop down list value to PEPPERS-G, then no logic exists in the backend to prevent PEPPERS-G from being created. I think such prevention logic should be implemented in the backend as well. On 03/10/2014 09:12 AM, Pierre Smits wrote: Christian, Routing Task Deliverable Products are the products that can be declared as a result of the execution of the task. You could regard these as a the by-products of the production run. In an earlier thread I referenced yeast-residiue as a by product. In the beer brewing process this is (often) the output (beside beer, obviously) of the fermentation action, task or process step. Regards, Pierre Smits *ORRTIZ.COMhttp://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: What is the purpose of Routing Task Deliverable Products?
If the reason field of ProductAssoc were changed to reference the VarianceReason entity instead of being an open entry field, then the ProductAssoc entity could be used for Deliverable Products definitions and the reasons could the only thing that appears in the drop down. Anyone predict limitations or problems with such a suggestion? On 03/10/2014 11:44 AM, Christian Carlow wrote: Can anyone think of reasons against changing the Routing Task Deliverable Products to reference ProductAssoc instead of Product? If BYPRODUCT and PRODUCT_REJECT were added as ProductAssocType then the entity could be used for implementing more advanced quantity checking rules when by-products are declared. On 03/10/2014 09:43 AM, Christian Carlow wrote: Thanks Pierre, I just discovered that Routing Task Deliverable Products controls the productId field of the production run inventory declaration form. Whenever a deliverable product is specified then the declaration form productId field changes to a drop down with only those deliverable products specified listed. If no deliverable products are specified then the productId becomes a lookup and allows any products to be declared. I was unaware deliverable products could limit the declaration form productIds. This discovery will allow me to progress further with OFBIZ-5568 https://issues.apache.org/jira/browse/OFBIZ-5568. It should be mentioned that preventing products other than those specified as deliverable products is limited to the front end in which a drop down appears only listing those deliverable products and that no backend code exist to guarantee that users cannot change the dropdown values using something like Firebug to hack the system and declare inventory for a product other than the ones specified as deliverable products. In other words, if I create a deliverable product PEPPERS for the DEFAULT_TASK but I use something like Firebug to change the drop down list value to PEPPERS-G, then no logic exists in the backend to prevent PEPPERS-G from being created. I think such prevention logic should be implemented in the backend as well. On 03/10/2014 09:12 AM, Pierre Smits wrote: Christian, Routing Task Deliverable Products are the products that can be declared as a result of the execution of the task. You could regard these as a the by-products of the production run. In an earlier thread I referenced yeast-residiue as a by product. In the beer brewing process this is (often) the output (beside beer, obviously) of the fermentation action, task or process step. Regards, Pierre Smits *ORRTIZ.COMhttp://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: What is the purpose of Routing Task Deliverable Products?
To provide the varianceReason drop down suggested in the previous post, and entity such as ProductAssocVarianceReason could be created for relating varianceReasons to the productId of ProductAssoc. Once the drop down is provided it, the ProductAssocVarianceReason can be used to automatically create new variant by-product records and related them in the ProductAssoc similar to the virtual variant auto-create methods. On 03/10/2014 11:56 AM, Christian Carlow wrote: If the reason field of ProductAssoc were changed to reference the VarianceReason entity instead of being an open entry field, then the ProductAssoc entity could be used for Deliverable Products definitions and the reasons could the only thing that appears in the drop down. Anyone predict limitations or problems with such a suggestion? On 03/10/2014 11:44 AM, Christian Carlow wrote: Can anyone think of reasons against changing the Routing Task Deliverable Products to reference ProductAssoc instead of Product? If BYPRODUCT and PRODUCT_REJECT were added as ProductAssocType then the entity could be used for implementing more advanced quantity checking rules when by-products are declared. On 03/10/2014 09:43 AM, Christian Carlow wrote: Thanks Pierre, I just discovered that Routing Task Deliverable Products controls the productId field of the production run inventory declaration form. Whenever a deliverable product is specified then the declaration form productId field changes to a drop down with only those deliverable products specified listed. If no deliverable products are specified then the productId becomes a lookup and allows any products to be declared. I was unaware deliverable products could limit the declaration form productIds. This discovery will allow me to progress further with OFBIZ-5568 https://issues.apache.org/jira/browse/OFBIZ-5568. It should be mentioned that preventing products other than those specified as deliverable products is limited to the front end in which a drop down appears only listing those deliverable products and that no backend code exist to guarantee that users cannot change the dropdown values using something like Firebug to hack the system and declare inventory for a product other than the ones specified as deliverable products. In other words, if I create a deliverable product PEPPERS for the DEFAULT_TASK but I use something like Firebug to change the drop down list value to PEPPERS-G, then no logic exists in the backend to prevent PEPPERS-G from being created. I think such prevention logic should be implemented in the backend as well. On 03/10/2014 09:12 AM, Pierre Smits wrote: Christian, Routing Task Deliverable Products are the products that can be declared as a result of the execution of the task. You could regard these as a the by-products of the production run. In an earlier thread I referenced yeast-residiue as a by product. In the beer brewing process this is (often) the output (beside beer, obviously) of the fermentation action, task or process step. Regards, Pierre Smits *ORRTIZ.COMhttp://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: Help clarifying proper use of production run quantity produced and rejected.
Thanks Pierre, You are correct, I'm the only one carrying the burden. So what you are saying is for a production run to create 10 of some amount of brews, the yeast would not constitute quantity produced specified in the left hand form? So there is yeast-residue left over after each of the 10 brews, you wouldn't declare a quantity produced of 2 (1 for beer 1 for yeast residue) but 1 for just the beer meant to be produced correct? On 03/10/2014 12:19 PM, Pierre Smits wrote: Christian, It seems to me that you are confusing yourself with your own reasoning Look at it from this simple and absolute perspective: when executing a production run that results in the end product beer the outcome of that intention is either beer (success) or no beer (failure). The rest is a by-product. Defective end products don't exist. Just end products (success), wanted by-products (e.g. waste - as in the bags the barley came in - or in the beer scenario yeast-residue) and unwanted by-products (the stuff that you get when failed) It also seem to me that you are the only one in your organisation carrying the burden of implementing business case/solution/process and technical adjustments. Beware of falling on the knife of your own promises. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: What is the purpose of Routing Task Deliverable Products?
Since by-product reason variance products wont exist ahead of time, they can't be related in the WorkEffortGoodStandard entity as is the way it is currently done. Instead, I think logic should be added to distinguish between PRUN_PROD_DELIV for the production run and its tasks and when used for a task, derive the variance reasons. In other words, use productId of ProductAssoc for WorkEffortGoodStandard for deliverable products which triggers the retrieval of the variance reasons defined in ProductAssocVarianceReason. Anyone see potential issues with this? On 03/10/2014 12:10 PM, Christian Carlow wrote: To provide the varianceReason drop down suggested in the previous post, and entity such as ProductAssocVarianceReason could be created for relating varianceReasons to the productId of ProductAssoc. Once the drop down is provided it, the ProductAssocVarianceReason can be used to automatically create new variant by-product records and related them in the ProductAssoc similar to the virtual variant auto-create methods. On 03/10/2014 11:56 AM, Christian Carlow wrote: If the reason field of ProductAssoc were changed to reference the VarianceReason entity instead of being an open entry field, then the ProductAssoc entity could be used for Deliverable Products definitions and the reasons could the only thing that appears in the drop down. Anyone predict limitations or problems with such a suggestion? On 03/10/2014 11:44 AM, Christian Carlow wrote: Can anyone think of reasons against changing the Routing Task Deliverable Products to reference ProductAssoc instead of Product? If BYPRODUCT and PRODUCT_REJECT were added as ProductAssocType then the entity could be used for implementing more advanced quantity checking rules when by-products are declared. On 03/10/2014 09:43 AM, Christian Carlow wrote: Thanks Pierre, I just discovered that Routing Task Deliverable Products controls the productId field of the production run inventory declaration form. Whenever a deliverable product is specified then the declaration form productId field changes to a drop down with only those deliverable products specified listed. If no deliverable products are specified then the productId becomes a lookup and allows any products to be declared. I was unaware deliverable products could limit the declaration form productIds. This discovery will allow me to progress further with OFBIZ-5568 https://issues.apache.org/jira/browse/OFBIZ-5568. It should be mentioned that preventing products other than those specified as deliverable products is limited to the front end in which a drop down appears only listing those deliverable products and that no backend code exist to guarantee that users cannot change the dropdown values using something like Firebug to hack the system and declare inventory for a product other than the ones specified as deliverable products. In other words, if I create a deliverable product PEPPERS for the DEFAULT_TASK but I use something like Firebug to change the drop down list value to PEPPERS-G, then no logic exists in the backend to prevent PEPPERS-G from being created. I think such prevention logic should be implemented in the backend as well. On 03/10/2014 09:12 AM, Pierre Smits wrote: Christian, Routing Task Deliverable Products are the products that can be declared as a result of the execution of the task. You could regard these as a the by-products of the production run. In an earlier thread I referenced yeast-residiue as a by product. In the beer brewing process this is (often) the output (beside beer, obviously) of the fermentation action, task or process step. Regards, Pierre Smits *ORRTIZ.COMhttp://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: Production Run Return Unused Materials To Warehouse allows all materials to be returned even if quantity produced has been declared
Thanks Jacopo, Since we've established the inventory declaration form should only be used for stocking in defective products, is there a way to prevent non-defective products from being declared with the form? Is there an easy way to determine if a product represents a defective one? If not, then would using the ProductAssoc entity to relate the defect (defective-tortilla) to the intended good (good-tortilla) with an assoTypeId=PRODUCT_DEFECTIVE be sufficient for modeling the data to used for applying product declaration limitation rules to the by-product declaration form? On 03/08/2014 12:22 AM, Jacopo Cappellato wrote: On Mar 8, 2014, at 2:38 AM, Christian Carlow christian.car...@gmail.com wrote: In Jacopo's pizza scenario, the tortilla technically represents a finished good (though different than the PRun good). But I think you are saying that the form should only be used for stocking-in degradated by-products such as processed-dough. I think we are all on the same line now: in my example, the tortilla by-product could be returned as a special productId as defective tortilla - do not sell to customers. Jacopo
Re: Production Run Return Unused Materials To Warehouse allows all materials to be returned even if quantity produced has been declared
Building on the idea I suggested, the ProductAssoc entity could then be used to prevent anything other than defective products associated with either the raw material or finished good from being declared. Can we agree that logic should be implemented in the service as well? On 03/08/2014 10:29 AM, Christian Carlow wrote: Thanks Jacopo, Since we've established the inventory declaration form should only be used for stocking in defective products, is there a way to prevent non-defective products from being declared with the form? Is there an easy way to determine if a product represents a defective one? If not, then would using the ProductAssoc entity to relate the defect (defective-tortilla) to the intended good (good-tortilla) with an assoTypeId=PRODUCT_DEFECTIVE be sufficient for modeling the data to used for applying product declaration limitation rules to the by-product declaration form? On 03/08/2014 12:22 AM, Jacopo Cappellato wrote: On Mar 8, 2014, at 2:38 AM, Christian Carlow christian.car...@gmail.com wrote: In Jacopo's pizza scenario, the tortilla technically represents a finished good (though different than the PRun good). But I think you are saying that the form should only be used for stocking-in degradated by-products such as processed-dough. I think we are all on the same line now: in my example, the tortilla by-product could be returned as a special productId as defective tortilla - do not sell to customers. Jacopo
Re: Why must production run task components be issued in descending order when associated with other tasks beside the first
I was mistaken in my initial post, the Issue Components button only issues components for its associated task. The Materials Required By The Running Task section lists all tasks that are currently running and still requiring materials. When Quick Start/Run All Tasks buttons are not clicked, only the currently running task appears in the Materials Required By The Running Task section because only one task can be started at a time and later ones can only be started once the prior has been complete. But when Quick Start/Run All Tasks buttons are clicked, then all tasks are put into the running state all all requiring materials appear in the Materials Required By Running Task section which allows for issuance of all tasks at once. Because of this, it seems the Issue Components button should appear for all tasks still requiring materials when the Quick Start/Run All Tasks buttons are clicked. However, both the Issue Components button and using the Materials Required By Running Task methods of issuance attempt to issue all materials and fail if all are not available. Therefore, the Actual Materials tab must be used to issue partial quantities manually. I guess the previous 2 methods are there for conveniency to be used only when all materials can be issued at once, otherwise the Actual Materials tab must be used. My primary reason for posting was to determine why I couldn't use the Issue Components button for more than one running task since materials may be received partially at different times. Since the Actual Materials tab can be used to do this, I don't think the Issue Components button not appearing for all running tasks is a big deal since those options are supposed to be used when all materials are available to be issued which isn't my case. I'll let the users know to use the use the actual materials tab when issuing materials. I'll be adding a patch soon that allows the Issue Components and Materials Required By Running Task issuance methods to be aware of materials already issued in the Actual Materials tab so more materials aren't issued than required. On 03/07/2014 02:24 AM, Pierre Smits wrote: Christian, What you are describing is creating an ad-hoc (blank) production run, where you add all the required components and resources (machines) prior to executing the production run. When doing a production run based on a recipe (BoM and production schema with tasks) you would assign a schema task (that uses the component) to the BoM component. This will ensure that components aren't issued from inventory before it is needed. Now when executing the production run and you don't activate 'Quick Start All Tasks) the first issuance button will appear after the first task has been started, the second issuance when the associated task is activated and so one. 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 03/06/2014 09:10 PM, Jacques Le Roux wrote: Damn, I should have read your last msg before answering to the earlier. I must say I'm not much versed in Manufacturing component. My answer was what I understood reading the excellent Sharan's book. I might have overlooked something.. https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Related+Books#OFBizRelatedBooks-GettingStartedwithApacheOFBizManufacturing; Jacques Le 06/03/2014 23:00, Christian Carlow a écrit : Strange...I just tested this functionality again but this time the button only issued for the task for which it is displayed which contradicts my last assumption. Meaning after the Issue Components button for the last task requiring materials is clicked, the button then appeared for the next last task requiring materials. Perhaps I did something different the first time around. I'll have to do more testing to be sure. Is there a reason the Issue Components button doesn't appear for all tasks requiring materials? On 03/05/2014 02:36 PM, Christian Carlow wrote: I guess the buttons purpose is to indicate the last task that requires materials? I initially posted this question because I thought that the button would have to be clicked for each of the prior tasks also requiring material issuances. Instead, the button actually issues components for all tasks requiring components, not just the last task requiring issuances for which the button appears. On 03/05/2014 02:24 PM, Christian Carlow wrote: Can someone explain why the Issue Components button appears for production tasks in descending order? To reproduce: 1. Create a production run for PIZZA 2. Assign PEPPERS-G to the first task and PEPPERS-H to the second using the Materials tab 3. Return to Edit Production Run tab and click Confirm 4. Click Quick Start All Tasks 5. Scroll down to the Tasks section and notice that second task (Preparation) is the only task that shows the Issue
Production Run Fail If Items Are Not Available in Materials Required By Running Task section not working
When the Fail If Items Are Not Available options are set to No and the Materials Required By The Running Task form is submitted, the same thing that happens when the value is set to Yes occurs. Is the No option supposed to allow issuances to occur even if the materials do not exist anywhere in inventory? What is the purpose of that field?
Re: Production Run Fail If Items Are Not Available in Materials Required By Running Task section not working
Sorry, I should have been more clear. The same error indicating that there is insufficient material inventory that occurs for the Yes options also occurs for the No option. On 03/07/2014 09:44 AM, Christian Carlow wrote: When the Fail If Items Are Not Available options are set to No and the Materials Required By The Running Task form is submitted, the same thing that happens when the value is set to Yes occurs. Is the No option supposed to allow issuances to occur even if the materials do not exist anywhere in inventory? What is the purpose of that field?
Production Run Return Unused Materials To Warehouse allows all materials to be returned even if quantity produced has been declared
Shouldn't the Return Unused Materials To Warehouse form limit the amount of materials that can be returned based on the amount that has been produced by the first production run task? In other words, for a production run to produce 10 pizzas requiring 10 PEPPERS-G as materials for example, if the first task produces 2 and rejects 2 then shouldn't the maximum quantity that can be returned be 6 since 4 can be considered to have been processed into WIP-variants? If so this problem is complicated by BOM materials required at different proportions which can't be determined if materials are added on the Actual Materials tab. Meaning that if 1 PIZZA requires 1 PEPPERS-G and 2 PEPPERS-H, then without the information being specified as BOMs, the proportion 2-1 for PEPPERS-H cannot be determined and therefore cannot have the material return limit rule applied correctly. This could be resolved by changing the Materials tab that appears before Production Runs are confirmed so that it accepts a proportional quantity rather than the actual quantity of the materials needed. In other words it would work just like the BOM quantity field. So for a production run to produce 10 PIZZA, rather than manually adding 10 PEPPERS-G and 20 PEPPERS-H, instead a BOM quantity of 1 would be specified for PEPPERS-G and 2 for PEPPERS-H. Then the production run would look at the quantity to produce times the BOM quantities to determine how much of single material is needed to produce a single good. So 10 PIZZAs are supposed to be produced so 1*10 = 10 PEPPERS-G and 2*10 = 20 PEPPERS-H.
Re: Production Run Return Unused Materials To Warehouse allows all materials to be returned even if quantity produced has been declared
Thanks Jacopo I think you might have thought that I was referring to the declaration form which allows for the productId to be specified. If so, then I was actually referring to the section below it labeled Return Unused Materials To Warehouse below it. For the pizza scenario, say 1 pizza requires as BOM, 1 big and 1 little dough with the big containing 2 little. Then for a production run to produce 1 pizza, if two big doughs were stocked out as materials, meaning 1 little dough will be left over, thenit seems maximum quantity produced would be 1. So there would be no conflict returning the 1 little because it would satisfy the material return limit I proposed. It seems as though the return app should know that the maximum amount that should be returned is 0.5. I can't think of a scenario where the following would apply: materialReturnQuantity materialIssueQuantity - (task1QuantityProduced + task1QuantityRejected) Fractions seem to be the only quantities that should be able to be returned when the following is satisfied: materialIssueQuantity - (task1QuantityProduced + task1QuantityRejected) == materialReturnQuantity On 03/07/2014 11:23 AM, Jacopo Cappellato wrote: On Mar 7, 2014, at 5:03 PM, Christian Carlow christian.car...@gmail.com wrote: Shouldn't the Return Unused Materials To Warehouse form limit the amount of materials that can be returned based on the amount that has been produced by the first production run task? In other words, for a production run to produce 10 pizzas requiring 10 PEPPERS-G as materials for example, if the first task produces 2 and rejects 2 then shouldn't the maximum quantity that can be returned be 6 since 4 can be considered to have been processed into WIP-variants? If I am not wrong that screenlet is intended to allow the return of potentially any product ids and quantity, not only the ones being issued as materials; I understand this may seem wrong but the idea is that it should be used to generate and store in warehouse products that represent side-effects of the main manufacturing process. For example, if you are preparing a pizza, and you realize you have issued too much dough, you may create a small tortilla instead of throwing away the unused material. Jacopo
Re: Production Run Fail If Items Are Not Available in Materials Required By Running Task section not working
Thanks Jacopo, It definitely helps. I thought its intended use was to issue materials/components even if they didn't exist in inventory. Since that's not the case I don't think its broken. On 03/07/2014 11:04 AM, Jacopo Cappellato wrote: Hi Christian, that part of the system definitely needs some love and I understand your confusion. If I well remember the intended behavior is the following: * if Fail If Items Are Not Available is set to Yes: the system will only issue materials that are not reserved by a sales order; i.e. in order to succeed you will need enough ATP * if Fail If Items Are Not Available is set to No: the system will possibly steal reserved items, if needed; i.e. in order to succeed you will need at least enough QOH * in both cases, if there is not enough QOH for the materials, the operation will fail I hope it helps, Jacopo On Mar 7, 2014, at 4:47 PM, Christian Carlow christian.car...@gmail.com wrote: Sorry, I should have been more clear. The same error indicating that there is insufficient material inventory that occurs for the Yes options also occurs for the No option. On 03/07/2014 09:44 AM, Christian Carlow wrote: When the Fail If Items Are Not Available options are set to No and the Materials Required By The Running Task form is submitted, the same thing that happens when the value is set to Yes occurs. Is the No option supposed to allow issuances to occur even if the materials do not exist anywhere in inventory? What is the purpose of that field?
Re: Production Run Return Unused Materials To Warehouse allows all materials to be returned even if quantity produced has been declared
Sorry, the bottom scenarios should be described like this instead: materialReturnQuantity (sum(WorkEffortInventoryAssign.quantity) of all tasks for productId) - (sum(WorkEffortInventoryProduced.quantity) for last task with inventory productId matching material productId) In other words, WorkEffortInventoryAssign and WorkEffortInventoryProduced would be used instead of the WorkEffort entity to determine how much can be returned. Granted the quantity field is added to the WorkEffortInventoryProduced table as suggested in an earlier post. On 03/07/2014 12:17 PM, Christian Carlow wrote: Thanks Jacopo I think you might have thought that I was referring to the declaration form which allows for the productId to be specified. If so, then I was actually referring to the section below it labeled Return Unused Materials To Warehouse below it. For the pizza scenario, say 1 pizza requires as BOM, 1 big and 1 little dough with the big containing 2 little. Then for a production run to produce 1 pizza, if two big doughs were stocked out as materials, meaning 1 little dough will be left over, thenit seems maximum quantity produced would be 1. So there would be no conflict returning the 1 little because it would satisfy the material return limit I proposed. It seems as though the return app should know that the maximum amount that should be returned is 0.5. I can't think of a scenario where the following would apply: materialReturnQuantity materialIssueQuantity - (task1QuantityProduced + task1QuantityRejected) Fractions seem to be the only quantities that should be able to be returned when the following is satisfied: materialIssueQuantity - (task1QuantityProduced + task1QuantityRejected) == materialReturnQuantity On 03/07/2014 11:23 AM, Jacopo Cappellato wrote: On Mar 7, 2014, at 5:03 PM, Christian Carlow christian.car...@gmail.com wrote: Shouldn't the Return Unused Materials To Warehouse form limit the amount of materials that can be returned based on the amount that has been produced by the first production run task? In other words, for a production run to produce 10 pizzas requiring 10 PEPPERS-G as materials for example, if the first task produces 2 and rejects 2 then shouldn't the maximum quantity that can be returned be 6 since 4 can be considered to have been processed into WIP-variants? If I am not wrong that screenlet is intended to allow the return of potentially any product ids and quantity, not only the ones being issued as materials; I understand this may seem wrong but the idea is that it should be used to generate and store in warehouse products that represent side-effects of the main manufacturing process. For example, if you are preparing a pizza, and you realize you have issued too much dough, you may create a small tortilla instead of throwing away the unused material. Jacopo
Re: Production Run Return Unused Materials To Warehouse allows all materials to be returned even if quantity produced has been declared
To be more specific, shouldn't this line in ProductionRunServices.java:
productionRunTaskReturnMaterial() be changed from:
if (quantity.compareTo(totalIssued.subtract(totalReturned) 0) {
to:
if
(quantity.compareTo(totalIssued.subtract(totalReturned).subtract(quantityProduced.add(quantityRejected)))
0) {
So that the ManufacturingProductionRunTaskCannotReturnMoreItems error is
thrown when trying to return materials that have been allocated as the
task quantity produced and rejected?
On 03/07/2014 02:16 PM, Christian Carlow wrote:
Sorry again (please bare with me its been a long day),
The scenario described in the first post was correct. I was getting
confused in my last post which can be disregarded.
On 03/07/2014 01:24 PM, Christian Carlow wrote:
Sorry, the bottom scenarios should be described like this instead:
materialReturnQuantity (sum(WorkEffortInventoryAssign.quantity) of
all tasks for productId) - (sum(WorkEffortInventoryProduced.quantity)
for last task with inventory productId matching material productId)
In other words, WorkEffortInventoryAssign and
WorkEffortInventoryProduced would be used instead of the WorkEffort
entity to determine how much can be returned. Granted the quantity
field is added to the WorkEffortInventoryProduced table as suggested
in an earlier post.
On 03/07/2014 12:17 PM, Christian Carlow wrote:
Thanks Jacopo
I think you might have thought that I was referring to the
declaration form which allows for the productId to be specified. If
so, then I was actually referring to the section below it labeled
Return Unused Materials To Warehouse below it.
For the pizza scenario, say 1 pizza requires as BOM, 1 big and 1
little dough with the big containing 2 little. Then for a
production run to produce 1 pizza, if two big doughs were stocked
out as materials, meaning 1 little dough will be left over, thenit
seems maximum quantity produced would be 1. So there would be no
conflict returning the 1 little because it would satisfy the
material return limit I proposed. It seems as though the return app
should know that the maximum amount that should be returned is 0.5.
I can't think of a scenario where the following would apply:
materialReturnQuantity materialIssueQuantity -
(task1QuantityProduced + task1QuantityRejected)
Fractions seem to be the only quantities that should be able to be
returned when the following is satisfied:
materialIssueQuantity - (task1QuantityProduced +
task1QuantityRejected) == materialReturnQuantity
On 03/07/2014 11:23 AM, Jacopo Cappellato wrote:
On Mar 7, 2014, at 5:03 PM, Christian Carlow
christian.car...@gmail.com wrote:
Shouldn't the Return Unused Materials To Warehouse form limit
the amount of materials that can be returned based on the amount
that has been produced by the first production run task? In other
words, for a production run to produce 10 pizzas requiring 10
PEPPERS-G as materials for example, if the first task produces 2
and rejects 2 then shouldn't the maximum quantity that can be
returned be 6 since 4 can be considered to have been processed
into WIP-variants?
If I am not wrong that screenlet is intended to allow the return
of potentially any product ids and quantity, not only the ones
being issued as materials; I understand this may seem wrong but the
idea is that it should be used to generate and store in warehouse
products that represent side-effects of the main manufacturing
process.
For example, if you are preparing a pizza, and you realize you have
issued too much dough, you may create a small tortilla instead of
throwing away the unused material.
Jacopo
Re: Production Run Return Unused Materials To Warehouse allows all materials to be returned even if quantity produced has been declared
Thanks Pierre, My issue is that the material return form allows quantity to be returned that has been declared/rejected a task. Meaning the task did something to it that constitutes a WIP rather than the original material that was issued. I think the quantityProduced and quantityRejected should be accounted for in the material return function as described in my previous post. I assume that the tortilla produced in Jacopo's scenario would be returned using the inventory producing declaration form rather than the material return form which this post is about. But now I think the correct way to handle the the tortilla scenario would be to return the dough material with a lotId and manually create a separate production run to produce a tortilla which would stock out the inventory lot from the previous production run. I created a patch which prevents more inventory quantity from being created in the right declaration form than quantityProduced + quantityRejected of the task (left declaration form). Meaning if I declare 1 quantityProduced and 1 quantityRejected for a task then the maximum amount of inventory quantity that can be produced is 2. Currently there is no limit to the amount of by-products that can result. This seems incorrect. I think the amount of by-products should be limited to the quantityProduced + quantityRejected declared for the task. On 03/07/2014 03:37 PM, Pierre Smits wrote: Christian, While the scenario presented by Jacopo is a surely a potentially unexpected nice-to-have feature in the feature set of OFBiz, you should ask yourself if that is something that you want in your manufacturing processes. Manufacturing processes are sets of controlled actions with predictable outcomes. When you are about to manufacture 100 units of your end product you would not want more than the required quantities of your components based on your BoMs. Anything issued more than required will cause extra actions like returning the surplus back to inventory, creating an extra end product (the tortilla as Jacopo outlined) that has not been ordered and might get stale in inventory, or even scrapping it due to quality degradation issues of the component. Anything issued less than required will delay the production run with potentially endangering the quality of the end product. Another aspect that you need to take into consideration is the cost of manufacturing involved. Your production run will lead to a cost of manufacturing that is based on (and in line with) the calculations made up front. When registering an extra (different) end product (again the tortilla) what would the effect be on the cost of manufacturing of both the intended end product and the extra? Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: Production Run Return Unused Materials To Warehouse allows all materials to be returned even if quantity produced has been declared
Thanks for the clarification Pierre, I agree that the inventory declaration form logic should prevent materials from being created as by-product inventory items. The question is how to properly define by-product. In Jacopo's pizza scenario, the tortilla technically represents a finished good (though different than the PRun good). But I think you are saying that the form should only be used for stocking-in degradated by-products such as processed-dough. If so I agree with you. Otherwise it seems as though the declaration form would need to incorporate logic to check that there is enough left over dough to actually make the tortilla. But that still seems incorrect since the production run tasks to produce the tortilla aren't being captured. Therefore it seems more correct to return/stock-in the dough as materials with a lotId and then issue/stock-out that lotId for a separate production run to create the tortilla. Also, the inventory declaration form allows the production run finished good to be produced which seems to violate the same rule as the materials mentioned above. I think the Production Run Declaration And Produce forms above should be used instead for stocking-in finished goods. I think the service that handles that form always sets the last task as the one that produced the PRun finished good. Based on that logic, can we agree that the last task should be the only one capable of producing the finished good and therefore prevent the PRun finished good from being declared using the inventory by-product declaration form? On 03/07/2014 06:34 PM, Pierre Smits wrote: Christian, Being able to define an unlimited number of by-products (and setting the associated quantities) is not incorrect. By-products are not the (surplus quantities of the) components issued, nor are they other end products. If pizza is the intended end result of a production run, then that is the end product. If you have issued more dough than needed, than the surplus is returned to inventory (for convenience sake other aspects like quality de If a bolt with 2 washers and a wingnut is your intended end result of a production run, then that is the end product that goes into inventory. And it is limited. If you have issued more washers than needed in the production run, then the surplus is returned to inventory (as a correction on the issuance). In the pizza analogy, the surplus dough (let us say 100 grams) can be regarded either as a returnable good (correction on issuance 100 grams) or as a by-product (e.g. waste as a result of quality degradation) that can potentially lead to cost recovery. In the latter case, the by-product cannot be the component issued but must be different product. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
createAcctgTransForWorkEffortInventoryProduced does not store inventoryItemId in AcctgTransEntry entity
Shouldn't the inventoryItemId be stored in the acctgTransEntry entity when created from production run task declarations or am I misunderstanding something? Also, shouldn't the original quantity that was credited be tracked also? There is no orig_quantity field in AcctgTransEntry as there is for the orig_amounts and orig_currency. Is there any reason an orig_quantity field shouldn't be added to the AcctgTransEntry entity? Without such a field, is there any other way to determine how much inventory a production run task produced? The WorkEffortInventoryProduced table only contains the inventoryItemId and workEffortId fields so the original quantity can't be determined after the InventoryItem quantities are updated.
Re: createAcctgTransForWorkEffortInventoryProduced does not store inventoryItemId in AcctgTransEntry entity
Perhaps adding a quantity field to WorkEffortInventoryProduced would be a better solution than adding fields to AcctgTransEntry? On 03/06/2014 12:28 PM, Christian Carlow wrote: Shouldn't the inventoryItemId be stored in the acctgTransEntry entity when created from production run task declarations or am I misunderstanding something? Also, shouldn't the original quantity that was credited be tracked also? There is no orig_quantity field in AcctgTransEntry as there is for the orig_amounts and orig_currency. Is there any reason an orig_quantity field shouldn't be added to the AcctgTransEntry entity? Without such a field, is there any other way to determine how much inventory a production run task produced? The WorkEffortInventoryProduced table only contains the inventoryItemId and workEffortId fields so the original quantity can't be determined after the InventoryItem quantities are updated.
Re: createAcctgTransForWorkEffortInventoryProduced does not store inventoryItemId in AcctgTransEntry entity
Adding a quantity field to WorkEffortInventoryProduced seems to be correct since it exists for WorkEffortInventoryAssign. WorkEffortInventoryAssign also has a statusId field but I'm not sure if its necessary to add to WorkEffortInventoryProduced also. I discovered that createAcctgTransForWorkEffortInventoryProduced doesn't store the inventoryItemId field while trying to figure out a way to track the original inventory quantities produced by production run tasks. Since my original intent has been satisfied I'm not as worried about the potential accounting issue described. If someone thinks its worth creating a JIRA issue to resolve it then it will be done. Otherwise I'm not sure how to proceed at the moment and will abandon it for now. On 03/06/2014 12:56 PM, Christian Carlow wrote: Perhaps adding a quantity field to WorkEffortInventoryProduced would be a better solution than adding fields to AcctgTransEntry? On 03/06/2014 12:28 PM, Christian Carlow wrote: Shouldn't the inventoryItemId be stored in the acctgTransEntry entity when created from production run task declarations or am I misunderstanding something? Also, shouldn't the original quantity that was credited be tracked also? There is no orig_quantity field in AcctgTransEntry as there is for the orig_amounts and orig_currency. Is there any reason an orig_quantity field shouldn't be added to the AcctgTransEntry entity? Without such a field, is there any other way to determine how much inventory a production run task produced? The WorkEffortInventoryProduced table only contains the inventoryItemId and workEffortId fields so the original quantity can't be determined after the InventoryItem quantities are updated.
Re: Why must production run task components be issued in descending order when associated with other tasks beside the first
Strange...I just tested this functionality again but this time the button only issued for the task for which it is displayed which contradicts my last assumption. Meaning after the Issue Components button for the last task requiring materials is clicked, the button then appeared for the next last task requiring materials. Perhaps I did something different the first time around. I'll have to do more testing to be sure. Is there a reason the Issue Components button doesn't appear for all tasks requiring materials? On 03/05/2014 02:36 PM, Christian Carlow wrote: I guess the buttons purpose is to indicate the last task that requires materials? I initially posted this question because I thought that the button would have to be clicked for each of the prior tasks also requiring material issuances. Instead, the button actually issues components for all tasks requiring components, not just the last task requiring issuances for which the button appears. On 03/05/2014 02:24 PM, Christian Carlow wrote: Can someone explain why the Issue Components button appears for production tasks in descending order? To reproduce: 1. Create a production run for PIZZA 2. Assign PEPPERS-G to the first task and PEPPERS-H to the second using the Materials tab 3. Return to Edit Production Run tab and click Confirm 4. Click Quick Start All Tasks 5. Scroll down to the Tasks section and notice that second task (Preparation) is the only task that shows the Issue Components button Shouldn't the Issue Components button appear for all tasks which require issuances? Is there a reason it only appears for the last task requiring issuances?
Why must production run task components be issued in descending order when associated with other tasks beside the first
Can someone explain why the Issue Components button appears for production tasks in descending order? To reproduce: 1. Create a production run for PIZZA 2. Assign PEPPERS-G to the first task and PEPPERS-H to the second using the Materials tab 3. Return to Edit Production Run tab and click Confirm 4. Click Quick Start All Tasks 5. Scroll down to the Tasks section and notice that second task (Preparation) is the only task that shows the Issue Components button Shouldn't the Issue Components button appear for all tasks which require issuances? Is there a reason it only appears for the last task requiring issuances?
Re: Why must production run task components be issued in descending order when associated with other tasks beside the first
I guess the buttons purpose is to indicate the last task that requires materials? I initially posted this question because I thought that the button would have to be clicked for each of the prior tasks also requiring material issuances. Instead, the button actually issues components for all tasks requiring components, not just the last task requiring issuances for which the button appears. On 03/05/2014 02:24 PM, Christian Carlow wrote: Can someone explain why the Issue Components button appears for production tasks in descending order? To reproduce: 1. Create a production run for PIZZA 2. Assign PEPPERS-G to the first task and PEPPERS-H to the second using the Materials tab 3. Return to Edit Production Run tab and click Confirm 4. Click Quick Start All Tasks 5. Scroll down to the Tasks section and notice that second task (Preparation) is the only task that shows the Issue Components button Shouldn't the Issue Components button appear for all tasks which require issuances? Is there a reason it only appears for the last task requiring issuances?
Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?
I've made more progress on this issue but it seems another entity might be needed to support the intended functionality. In a previous post I suggested adding the timeEntryId field to the InventoryItemDetail entity to track by-products created by production run task time entries. I need a way to determine how many by-products have actually been created by a task time entry and InventoryItemDetail.quantityOnHandDiff isn't sufficient because it doesn't account for possible InventoryItem corrections. Therefore an entity such as TimeEntryInventoryProduced will probably have to be created similar to WorkEffortInventoryProduced. On 02/27/2014 10:39 AM, Christian Carlow wrote: I'm now aware of more complexity. The inspector supervisor explained that partial inspections sometimes occur for which parts are moved from a manufacturing dept to an inspection dept that performs partial inspection and then sends to another manufacturing dept that ends up sending the parts to a final inspection dept for full inspection. But if rejects are declared at the final full inspection stage, then the fault is supposed to be applied to the initially manufacturing worker not the intermediate one that performs the work after partial inspection. I think the TimeEntryAssoc should be extended to handle inspection associations to both the prior manufacturing stage from which the pieces were sent and the manufacturing stage considered at fault for the rejects. Associations between the inspection stage to the prior manufacturing stage is necessary for the inspection dept to determine how many pieces are left to inspect. I think some field like timeEntryAssocTypeId could be used to distinguish associations of inspection time entries to the prior manufacturing stage from those to the faulty manufacturing stage. TIME_ENTRY_DEPENDENCY could be used to associate the inspection task to the prior manufacturing task and something like TIME_ENTRY_REJECT (with parent TIME_ENTRY_DEPENDENCY) could be used to indicate the faulty manufacturing task. This would possibly entail a new TimeEntryAssocType entity. On 02/27/2014 09:06 AM, Christian Carlow wrote: I suppose the TimeEntryAssoc entity could be extended to include quantityRejected and responsiblePartyId fields to eliminate the need for a separate TimeEntryRejectParty entity. On 02/27/2014 08:53 AM, Christian Carlow wrote: After making some progress on this issue by adding the timesheet/timeentry functionality to the production run task declaration services, I've encountered more difficulties implementing the needed functionality. I added a TimeEntryAssoc entity so that inspectors can directly inspect a manufacturing workers prior time entry. I was going to use the TimeEntryAssoc entity to determine the number of bad pieces per manufacturing worker by looking at the inspection timeEntry quantityRejected and extracting the related manufacturing time entry partyId. The problem with this is that sometimes rejected quantity on the inspection ticket might represent faults on the inspectors part rather than the manufacturers such as if the inspector drops parts. For this case the inspector should be considered the one who caused the bad piece not the manufacturer. To determine the party at fault for rejected pieces it seems there needs to be another entity created to track the info. Maybe something like TimeEntryRejectParty that divides the time entry rejected quantity and applies them to the parties actually responsible for the rejects. The only alternative I've come up with other than adding a new TimeEntryRejectParty is to assign the faulty partyId to the inventoryItemDetail record that would be created for the by-products declared to account for the rejects. But this method is dependent on by-products always being declared when rejects occur which might not always happen. Therefore it seems creating a dedicated entity like TimeEntryRejectParty is the better method. Anyone have any thoughts on this issue? On 02/24/2014 01:37 PM, Christian Carlow wrote: My last post can be disregarded, splitting the production run declaration into two different forms seems correct. There needs to be a way to relate time entries created from the first form to inventory item details created in the second form so that the types of rejects that were produced from time entries can be determined. On 02/24/2014 01:05 PM, Christian Carlow wrote: Is there a reason the two Production Run Declaration (manufacturing/control/ProductionRunDeclaration) forms cannot be combined into a single form? If the first form is used to declare rejections, why can't the by-products products be declared as inventory in the same form instead of having to be done using the second form? On 02/24/2014 12:36 PM, Christian Carlow wrote: Another related issue is how to determine the particular rejection reasons. Inspectors may declare rejected pieces
Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?
After making some progress on this issue by adding the timesheet/timeentry functionality to the production run task declaration services, I've encountered more difficulties implementing the needed functionality. I added a TimeEntryAssoc entity so that inspectors can directly inspect a manufacturing workers prior time entry. I was going to use the TimeEntryAssoc entity to determine the number of bad pieces per manufacturing worker by looking at the inspection timeEntry quantityRejected and extracting the related manufacturing time entry partyId. The problem with this is that sometimes rejected quantity on the inspection ticket might represent faults on the inspectors part rather than the manufacturers such as if the inspector drops parts. For this case the inspector should be considered the one who caused the bad piece not the manufacturer. To determine the party at fault for rejected pieces it seems there needs to be another entity created to track the info. Maybe something like TimeEntryRejectParty that divides the time entry rejected quantity and applies them to the parties actually responsible for the rejects. The only alternative I've come up with other than adding a new TimeEntryRejectParty is to assign the faulty partyId to the inventoryItemDetail record that would be created for the by-products declared to account for the rejects. But this method is dependent on by-products always being declared when rejects occur which might not always happen. Therefore it seems creating a dedicated entity like TimeEntryRejectParty is the better method. Anyone have any thoughts on this issue? On 02/24/2014 01:37 PM, Christian Carlow wrote: My last post can be disregarded, splitting the production run declaration into two different forms seems correct. There needs to be a way to relate time entries created from the first form to inventory item details created in the second form so that the types of rejects that were produced from time entries can be determined. On 02/24/2014 01:05 PM, Christian Carlow wrote: Is there a reason the two Production Run Declaration (manufacturing/control/ProductionRunDeclaration) forms cannot be combined into a single form? If the first form is used to declare rejections, why can't the by-products products be declared as inventory in the same form instead of having to be done using the second form? On 02/24/2014 12:36 PM, Christian Carlow wrote: Another related issue is how to determine the particular rejection reasons. Inspectors may declare rejected pieces as by-products during production run inspection steps that may be capable of rework. The percentage good by employee report mentioned in the previous post also displays the reasons associated with each rejection. Each of the rejection reason codes were converted to individual products within OFBiz, but the problem is how to relate those rejection products declared to the inspector work effort time entries. Adding timeEntryId to the InventoryItemDetail entity seems to provide a way of relating time entries created by production run task declarations. Is anyone against adding timeEntryId to InventoryItemDetail? On 02/24/2014 12:14 PM, Christian Carlow wrote: I changed the title to be more clear. The company ticket system has inspection functionality that allows inspectors to declare multiple types of rejects for the quantity specified on manufacturing tickets. This functionality doesn't seem supported in OFBiz. I've see no way to determine that a worker from a production run inspection task inspected work done by a particular worker in the prior manufacturing step. The company relies on this functionality to generated a percentage good by employee report that analyzes the inspections for rejections and looks at its related manufacturing ticket to determine which manufacturing workers produced rejects. I created OFBIZ-5532 https://issues.apache.org/jira/browse/OFBIZ-5532 to allow time entries to be created during production run task declarations. To support the functionality explained above, I think the an extension would be necessary for relating time entries. Something such as TimeEntryAssoc could be created to relate the inspection task time entry to the manufacturing task time entry so that the actual workers and associated quantities could be determined. On 02/24/2014 11:03 AM, Christian Carlow wrote: Does anyone know how to track manufacturing rejects by employee? I created a production run containing a first task that represents manufacturing work and a second that represents the inspection work. I need to be able to determine how many bad pieces were caused by the employee associated with the first manufacturing task based on rejection declarations by the employee associated with the second task. The only way I can think of supporting this is to have some relationship between the time entries that relate to the production
Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?
I suppose the TimeEntryAssoc entity could be extended to include quantityRejected and responsiblePartyId fields to eliminate the need for a separate TimeEntryRejectParty entity. On 02/27/2014 08:53 AM, Christian Carlow wrote: After making some progress on this issue by adding the timesheet/timeentry functionality to the production run task declaration services, I've encountered more difficulties implementing the needed functionality. I added a TimeEntryAssoc entity so that inspectors can directly inspect a manufacturing workers prior time entry. I was going to use the TimeEntryAssoc entity to determine the number of bad pieces per manufacturing worker by looking at the inspection timeEntry quantityRejected and extracting the related manufacturing time entry partyId. The problem with this is that sometimes rejected quantity on the inspection ticket might represent faults on the inspectors part rather than the manufacturers such as if the inspector drops parts. For this case the inspector should be considered the one who caused the bad piece not the manufacturer. To determine the party at fault for rejected pieces it seems there needs to be another entity created to track the info. Maybe something like TimeEntryRejectParty that divides the time entry rejected quantity and applies them to the parties actually responsible for the rejects. The only alternative I've come up with other than adding a new TimeEntryRejectParty is to assign the faulty partyId to the inventoryItemDetail record that would be created for the by-products declared to account for the rejects. But this method is dependent on by-products always being declared when rejects occur which might not always happen. Therefore it seems creating a dedicated entity like TimeEntryRejectParty is the better method. Anyone have any thoughts on this issue? On 02/24/2014 01:37 PM, Christian Carlow wrote: My last post can be disregarded, splitting the production run declaration into two different forms seems correct. There needs to be a way to relate time entries created from the first form to inventory item details created in the second form so that the types of rejects that were produced from time entries can be determined. On 02/24/2014 01:05 PM, Christian Carlow wrote: Is there a reason the two Production Run Declaration (manufacturing/control/ProductionRunDeclaration) forms cannot be combined into a single form? If the first form is used to declare rejections, why can't the by-products products be declared as inventory in the same form instead of having to be done using the second form? On 02/24/2014 12:36 PM, Christian Carlow wrote: Another related issue is how to determine the particular rejection reasons. Inspectors may declare rejected pieces as by-products during production run inspection steps that may be capable of rework. The percentage good by employee report mentioned in the previous post also displays the reasons associated with each rejection. Each of the rejection reason codes were converted to individual products within OFBiz, but the problem is how to relate those rejection products declared to the inspector work effort time entries. Adding timeEntryId to the InventoryItemDetail entity seems to provide a way of relating time entries created by production run task declarations. Is anyone against adding timeEntryId to InventoryItemDetail? On 02/24/2014 12:14 PM, Christian Carlow wrote: I changed the title to be more clear. The company ticket system has inspection functionality that allows inspectors to declare multiple types of rejects for the quantity specified on manufacturing tickets. This functionality doesn't seem supported in OFBiz. I've see no way to determine that a worker from a production run inspection task inspected work done by a particular worker in the prior manufacturing step. The company relies on this functionality to generated a percentage good by employee report that analyzes the inspections for rejections and looks at its related manufacturing ticket to determine which manufacturing workers produced rejects. I created OFBIZ-5532 https://issues.apache.org/jira/browse/OFBIZ-5532 to allow time entries to be created during production run task declarations. To support the functionality explained above, I think the an extension would be necessary for relating time entries. Something such as TimeEntryAssoc could be created to relate the inspection task time entry to the manufacturing task time entry so that the actual workers and associated quantities could be determined. On 02/24/2014 11:03 AM, Christian Carlow wrote: Does anyone know how to track manufacturing rejects by employee? I created a production run containing a first task that represents manufacturing work and a second that represents the inspection work. I need to be able to determine how many bad pieces were caused by the employee associated with the first
Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?
I'm now aware of more complexity. The inspector supervisor explained that partial inspections sometimes occur for which parts are moved from a manufacturing dept to an inspection dept that performs partial inspection and then sends to another manufacturing dept that ends up sending the parts to a final inspection dept for full inspection. But if rejects are declared at the final full inspection stage, then the fault is supposed to be applied to the initially manufacturing worker not the intermediate one that performs the work after partial inspection. I think the TimeEntryAssoc should be extended to handle inspection associations to both the prior manufacturing stage from which the pieces were sent and the manufacturing stage considered at fault for the rejects. Associations between the inspection stage to the prior manufacturing stage is necessary for the inspection dept to determine how many pieces are left to inspect. I think some field like timeEntryAssocTypeId could be used to distinguish associations of inspection time entries to the prior manufacturing stage from those to the faulty manufacturing stage. TIME_ENTRY_DEPENDENCY could be used to associate the inspection task to the prior manufacturing task and something like TIME_ENTRY_REJECT (with parent TIME_ENTRY_DEPENDENCY) could be used to indicate the faulty manufacturing task. This would possibly entail a new TimeEntryAssocType entity. On 02/27/2014 09:06 AM, Christian Carlow wrote: I suppose the TimeEntryAssoc entity could be extended to include quantityRejected and responsiblePartyId fields to eliminate the need for a separate TimeEntryRejectParty entity. On 02/27/2014 08:53 AM, Christian Carlow wrote: After making some progress on this issue by adding the timesheet/timeentry functionality to the production run task declaration services, I've encountered more difficulties implementing the needed functionality. I added a TimeEntryAssoc entity so that inspectors can directly inspect a manufacturing workers prior time entry. I was going to use the TimeEntryAssoc entity to determine the number of bad pieces per manufacturing worker by looking at the inspection timeEntry quantityRejected and extracting the related manufacturing time entry partyId. The problem with this is that sometimes rejected quantity on the inspection ticket might represent faults on the inspectors part rather than the manufacturers such as if the inspector drops parts. For this case the inspector should be considered the one who caused the bad piece not the manufacturer. To determine the party at fault for rejected pieces it seems there needs to be another entity created to track the info. Maybe something like TimeEntryRejectParty that divides the time entry rejected quantity and applies them to the parties actually responsible for the rejects. The only alternative I've come up with other than adding a new TimeEntryRejectParty is to assign the faulty partyId to the inventoryItemDetail record that would be created for the by-products declared to account for the rejects. But this method is dependent on by-products always being declared when rejects occur which might not always happen. Therefore it seems creating a dedicated entity like TimeEntryRejectParty is the better method. Anyone have any thoughts on this issue? On 02/24/2014 01:37 PM, Christian Carlow wrote: My last post can be disregarded, splitting the production run declaration into two different forms seems correct. There needs to be a way to relate time entries created from the first form to inventory item details created in the second form so that the types of rejects that were produced from time entries can be determined. On 02/24/2014 01:05 PM, Christian Carlow wrote: Is there a reason the two Production Run Declaration (manufacturing/control/ProductionRunDeclaration) forms cannot be combined into a single form? If the first form is used to declare rejections, why can't the by-products products be declared as inventory in the same form instead of having to be done using the second form? On 02/24/2014 12:36 PM, Christian Carlow wrote: Another related issue is how to determine the particular rejection reasons. Inspectors may declare rejected pieces as by-products during production run inspection steps that may be capable of rework. The percentage good by employee report mentioned in the previous post also displays the reasons associated with each rejection. Each of the rejection reason codes were converted to individual products within OFBiz, but the problem is how to relate those rejection products declared to the inspector work effort time entries. Adding timeEntryId to the InventoryItemDetail entity seems to provide a way of relating time entries created by production run task declarations. Is anyone against adding timeEntryId to InventoryItemDetail? On 02/24/2014 12:14 PM, Christian Carlow wrote: I changed the title
Shouldn't the maximum declaration amount of the task responsible for issuing components be limited to the amount issued?
Arbitrary quantityProduced values may be specified for production run declarations. In a previous post, it was agreed that the quantityProduced should be limited to the quantityProduced of the previous task. Shouldn't this logic apply to the task that is responsible for stocking out materials also? For example, if I have a production run to create 10 GZ-BASKET but issue only 1 of its GZ-1000 components, shouldn't the quantity produced of that task be limited to 1 since the remaining 9 GZ-1000 components haven't been issued yet? Currently it allows for any value such as 1000 to be entered as the quantityProduced.
Re: Shouldn't the maximum declaration amount of the task responsible for issuing components be limited to the amount issued?
If the quantityProduced amount for the material-stock-out task should be limited to the amount of materials issued, then I'm not sure how to handle tasks that might occur before the material-stock-out task. The first task of a production run is automatically chosen as the material-stock-out task if one isn't chosen. I can't think of a reason why material stock out would occur after prior tasks and if those prior tasks would need to declare quantityProduced. Anyone have suggestions? On 02/25/2014 10:21 AM, Christian Carlow wrote: Arbitrary quantityProduced values may be specified for production run declarations. In a previous post, it was agreed that the quantityProduced should be limited to the quantityProduced of the previous task. Shouldn't this logic apply to the task that is responsible for stocking out materials also? For example, if I have a production run to create 10 GZ-BASKET but issue only 1 of its GZ-1000 components, shouldn't the quantity produced of that task be limited to 1 since the remaining 9 GZ-1000 components haven't been issued yet? Currently it allows for any value such as 1000 to be entered as the quantityProduced.
How to track manufacturing rejects by employee?
Does anyone know how to track manufacturing rejects by employee? I created a production run containing a first task that represents manufacturing work and a second that represents the inspection work. I need to be able to determine how many bad pieces were caused by the employee associated with the first manufacturing task based on rejection declarations by the employee associated with the second task. The only way I can think of supporting this is to have some relationship between the time entries that relate to the production run tasks.
Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?
I changed the title to be more clear. The company ticket system has inspection functionality that allows inspectors to declare multiple types of rejects for the quantity specified on manufacturing tickets. This functionality doesn't seem supported in OFBiz. I've see no way to determine that a worker from a production run inspection task inspected work done by a particular worker in the prior manufacturing step. The company relies on this functionality to generated a percentage good by employee report that analyzes the inspections for rejections and looks at its related manufacturing ticket to determine which manufacturing workers produced rejects. I created OFBIZ-5532 https://issues.apache.org/jira/browse/OFBIZ-5532 to allow time entries to be created during production run task declarations. To support the functionality explained above, I think the an extension would be necessary for relating time entries. Something such as TimeEntryAssoc could be created to relate the inspection task time entry to the manufacturing task time entry so that the actual workers and associated quantities could be determined. On 02/24/2014 11:03 AM, Christian Carlow wrote: Does anyone know how to track manufacturing rejects by employee? I created a production run containing a first task that represents manufacturing work and a second that represents the inspection work. I need to be able to determine how many bad pieces were caused by the employee associated with the first manufacturing task based on rejection declarations by the employee associated with the second task. The only way I can think of supporting this is to have some relationship between the time entries that relate to the production run tasks.
InventoryItem partyId not set when created from production run declaration
Shouldn't the partyId of an InventoryItem record created from a production run declaration be set to the declaring worker? InventoryItem.partyId gets set to the SupplierPartyId when receiving purchase order shipments so it seems to make sense that workers should be the partyId of declaration-created inventory items. If so then the form for manufacturing/control/ProductionRunDeclaration needs to include a worker/partyId field.
Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?
Another related issue is how to determine the particular rejection reasons. Inspectors may declare rejected pieces as by-products during production run inspection steps that may be capable of rework. The percentage good by employee report mentioned in the previous post also displays the reasons associated with each rejection. Each of the rejection reason codes were converted to individual products within OFBiz, but the problem is how to relate those rejection products declared to the inspector work effort time entries. Adding timeEntryId to the InventoryItemDetail entity seems to provide a way of relating time entries created by production run task declarations. Is anyone against adding timeEntryId to InventoryItemDetail? On 02/24/2014 12:14 PM, Christian Carlow wrote: I changed the title to be more clear. The company ticket system has inspection functionality that allows inspectors to declare multiple types of rejects for the quantity specified on manufacturing tickets. This functionality doesn't seem supported in OFBiz. I've see no way to determine that a worker from a production run inspection task inspected work done by a particular worker in the prior manufacturing step. The company relies on this functionality to generated a percentage good by employee report that analyzes the inspections for rejections and looks at its related manufacturing ticket to determine which manufacturing workers produced rejects. I created OFBIZ-5532 https://issues.apache.org/jira/browse/OFBIZ-5532 to allow time entries to be created during production run task declarations. To support the functionality explained above, I think the an extension would be necessary for relating time entries. Something such as TimeEntryAssoc could be created to relate the inspection task time entry to the manufacturing task time entry so that the actual workers and associated quantities could be determined. On 02/24/2014 11:03 AM, Christian Carlow wrote: Does anyone know how to track manufacturing rejects by employee? I created a production run containing a first task that represents manufacturing work and a second that represents the inspection work. I need to be able to determine how many bad pieces were caused by the employee associated with the first manufacturing task based on rejection declarations by the employee associated with the second task. The only way I can think of supporting this is to have some relationship between the time entries that relate to the production run tasks.
Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?
Is there a reason the two Production Run Declaration (manufacturing/control/ProductionRunDeclaration) forms cannot be combined into a single form? If the first form is used to declare rejections, why can't the by-products products be declared as inventory in the same form instead of having to be done using the second form? On 02/24/2014 12:36 PM, Christian Carlow wrote: Another related issue is how to determine the particular rejection reasons. Inspectors may declare rejected pieces as by-products during production run inspection steps that may be capable of rework. The percentage good by employee report mentioned in the previous post also displays the reasons associated with each rejection. Each of the rejection reason codes were converted to individual products within OFBiz, but the problem is how to relate those rejection products declared to the inspector work effort time entries. Adding timeEntryId to the InventoryItemDetail entity seems to provide a way of relating time entries created by production run task declarations. Is anyone against adding timeEntryId to InventoryItemDetail? On 02/24/2014 12:14 PM, Christian Carlow wrote: I changed the title to be more clear. The company ticket system has inspection functionality that allows inspectors to declare multiple types of rejects for the quantity specified on manufacturing tickets. This functionality doesn't seem supported in OFBiz. I've see no way to determine that a worker from a production run inspection task inspected work done by a particular worker in the prior manufacturing step. The company relies on this functionality to generated a percentage good by employee report that analyzes the inspections for rejections and looks at its related manufacturing ticket to determine which manufacturing workers produced rejects. I created OFBIZ-5532 https://issues.apache.org/jira/browse/OFBIZ-5532 to allow time entries to be created during production run task declarations. To support the functionality explained above, I think the an extension would be necessary for relating time entries. Something such as TimeEntryAssoc could be created to relate the inspection task time entry to the manufacturing task time entry so that the actual workers and associated quantities could be determined. On 02/24/2014 11:03 AM, Christian Carlow wrote: Does anyone know how to track manufacturing rejects by employee? I created a production run containing a first task that represents manufacturing work and a second that represents the inspection work. I need to be able to determine how many bad pieces were caused by the employee associated with the first manufacturing task based on rejection declarations by the employee associated with the second task. The only way I can think of supporting this is to have some relationship between the time entries that relate to the production run tasks.
Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?
My last post can be disregarded, splitting the production run declaration into two different forms seems correct. There needs to be a way to relate time entries created from the first form to inventory item details created in the second form so that the types of rejects that were produced from time entries can be determined. On 02/24/2014 01:05 PM, Christian Carlow wrote: Is there a reason the two Production Run Declaration (manufacturing/control/ProductionRunDeclaration) forms cannot be combined into a single form? If the first form is used to declare rejections, why can't the by-products products be declared as inventory in the same form instead of having to be done using the second form? On 02/24/2014 12:36 PM, Christian Carlow wrote: Another related issue is how to determine the particular rejection reasons. Inspectors may declare rejected pieces as by-products during production run inspection steps that may be capable of rework. The percentage good by employee report mentioned in the previous post also displays the reasons associated with each rejection. Each of the rejection reason codes were converted to individual products within OFBiz, but the problem is how to relate those rejection products declared to the inspector work effort time entries. Adding timeEntryId to the InventoryItemDetail entity seems to provide a way of relating time entries created by production run task declarations. Is anyone against adding timeEntryId to InventoryItemDetail? On 02/24/2014 12:14 PM, Christian Carlow wrote: I changed the title to be more clear. The company ticket system has inspection functionality that allows inspectors to declare multiple types of rejects for the quantity specified on manufacturing tickets. This functionality doesn't seem supported in OFBiz. I've see no way to determine that a worker from a production run inspection task inspected work done by a particular worker in the prior manufacturing step. The company relies on this functionality to generated a percentage good by employee report that analyzes the inspections for rejections and looks at its related manufacturing ticket to determine which manufacturing workers produced rejects. I created OFBIZ-5532 https://issues.apache.org/jira/browse/OFBIZ-5532 to allow time entries to be created during production run task declarations. To support the functionality explained above, I think the an extension would be necessary for relating time entries. Something such as TimeEntryAssoc could be created to relate the inspection task time entry to the manufacturing task time entry so that the actual workers and associated quantities could be determined. On 02/24/2014 11:03 AM, Christian Carlow wrote: Does anyone know how to track manufacturing rejects by employee? I created a production run containing a first task that represents manufacturing work and a second that represents the inspection work. I need to be able to determine how many bad pieces were caused by the employee associated with the first manufacturing task based on rejection declarations by the employee associated with the second task. The only way I can think of supporting this is to have some relationship between the time entries that relate to the production run tasks.
Add Mis-Produced option to Physical Inventory Variances ReasonId dropdown to handle corrections to production run task quantity produced declarations?
Should another options such as Mis-Produced (VAR_MISPRODUCED) be added to the physical inventory variance reasonId dropdown? Inventory Items can created by production run declarations but there doesn't seem to be an adequate reason to describe corrections to the quantity produced when declared incorrectly.
Re: Add Mis-Produced option to Physical Inventory Variances ReasonId dropdown to handle corrections to production run task quantity produced declarations?
Or maybe have two separate reasons for increase and decrease such as is done for Mis-Shipped (VAR_MISSHIP_ORDERED, VAR_MISSHIP_SHIPPED). Maybe something like: VAR_MISPRODUCED_PRODUCED - Mis-Produced Produced (+) VAR_MISPRODUCED_NOTPRODUCED - Mis-Produced Not Produced (-) On 02/24/2014 02:56 PM, Christian Carlow wrote: Should another options such as Mis-Produced (VAR_MISPRODUCED) be added to the physical inventory variance reasonId dropdown? Inventory Items can created by production run declarations but there doesn't seem to be an adequate reason to describe corrections to the quantity produced when declared incorrectly.
exclude element supported in form widget auto-fields-service element?
Does the auto-fields-service form widget element support the exclude? I thought it was at least supported for auto-fields-entity but can't seem to get it working either.
Re: How to modify received and rejected quantities of shipment receipts?
Thanks Pierre, Do you know the purpose of the rejected quantity field in the receiving form since RMA is the correct way of returning items? On 02/21/2014 05:04 AM, Pierre Smits wrote: Christian, Normally, when goods are received and subsequently rejected by the QA/QI department an RGA/RMA needs to be negotiated with the supplier and received. Otherwise there would not be any legal grounds for getting a reimbursement for faulty products. In the scenario you outlined the following could/would apply: - receive 100% of the goods and put in inventory - get RGA/RMA for faulty products - do a return for faulty products (state RGA/RMA) - get credit note or replacement products. OOTB this functionality is available. Therefore no adjustments on entity model are required. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: How to modify received and rejected quantities of shipment receipts?
Sorry Pierre, Its the shipment receiving form: Facility - Receive Inventory or: https://demo-trunk.ofbiz.apache.org/facility/control/ReceiveInventory It includes a quantityAccepted and quantityRejected field. On 02/21/2014 06:39 AM, Pierre Smits wrote: Referring screens/forms fields as they appear in source helps others understand what you are talking about. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: How to modify received and rejected quantities of shipment receipts?
Hey Pierre, I just checked out the return/RMA form you suggested: ordermgr/control/createReturnItems And got this error when trying to create a return for a supplier order: The following required parameter is missing: [createReturnItem.returnItemTypeId] The returnItemTypeId field is hidden in the form and the value set to blank. Shouldn't this field be available as a drop down field referencing the ReturnItemType entity? On 02/21/2014 07:16 AM, Christian Carlow wrote: Sorry Pierre, Its the shipment receiving form: Facility - Receive Inventory or: https://demo-trunk.ofbiz.apache.org/facility/control/ReceiveInventory It includes a quantityAccepted and quantityRejected field. On 02/21/2014 06:39 AM, Pierre Smits wrote: Referring screens/forms fields as they appear in source helps others understand what you are talking about. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: How to modify received and rejected quantities of shipment receipts?
Nevermind, It seems the returnItemTypeId is supposed to be hidden and set according to the values listed in the ReturnItemTypeMap entity. I haven't yet determined why the value of the field is being set to blank yet. On 02/21/2014 07:37 AM, Christian Carlow wrote: Hey Pierre, I just checked out the return/RMA form you suggested: ordermgr/control/createReturnItems And got this error when trying to create a return for a supplier order: The following required parameter is missing: [createReturnItem.returnItemTypeId] The returnItemTypeId field is hidden in the form and the value set to blank. Shouldn't this field be available as a drop down field referencing the ReturnItemType entity? On 02/21/2014 07:16 AM, Christian Carlow wrote: Sorry Pierre, Its the shipment receiving form: Facility - Receive Inventory or: https://demo-trunk.ofbiz.apache.org/facility/control/ReceiveInventory It includes a quantityAccepted and quantityRejected field. On 02/21/2014 06:39 AM, Pierre Smits wrote: Referring screens/forms fields as they appear in source helps others understand what you are talking about. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: How to modify received and rejected quantities of shipment receipts?
I've determined the why the returnItemTypeId is blank in the return/RMA form. There exist no record for the RAW_MATERIAL order item type in the ReturnItemTypeMap entity. On 02/21/2014 07:57 AM, Christian Carlow wrote: Nevermind, It seems the returnItemTypeId is supposed to be hidden and set according to the values listed in the ReturnItemTypeMap entity. I haven't yet determined why the value of the field is being set to blank yet. On 02/21/2014 07:37 AM, Christian Carlow wrote: Hey Pierre, I just checked out the return/RMA form you suggested: ordermgr/control/createReturnItems And got this error when trying to create a return for a supplier order: The following required parameter is missing: [createReturnItem.returnItemTypeId] The returnItemTypeId field is hidden in the form and the value set to blank. Shouldn't this field be available as a drop down field referencing the ReturnItemType entity? On 02/21/2014 07:16 AM, Christian Carlow wrote: Sorry Pierre, Its the shipment receiving form: Facility - Receive Inventory or: https://demo-trunk.ofbiz.apache.org/facility/control/ReceiveInventory It includes a quantityAccepted and quantityRejected field. On 02/21/2014 06:39 AM, Pierre Smits wrote: Referring screens/forms fields as they appear in source helps others understand what you are talking about. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
