Re: Implementing processes to support SupplierProduct.unitsIncluded field
On Jul 20, 2009, at 12:43 AM, Vince Clark wrote: Jacopo I'm concerned about breaking everything down to unit cost. This is why one of the solutions we have suggested to you for this is equivalent to how we are handling this on the sales side. We define a product at the unit level, but we do not sell this product. Instead, we create marketing packages that we call "retail packs". Then we set the price there. On the purchasing side, at least in our situation it is unusual for a supplier to provide unit or piece pricing. They only provide pricing for "vendor packs" or "wholesale packs" which are often really just some quantity greater than one of retail packs. So for example a vendor pack might really just be 10 retail packs. This is much like walking into a warehouse club like Sam's or Costco (not sure what the equivalents are in other regions) and buying a large quantity of chewing gum. When you open up the "vendor pack" that you purchased wholesale you will have 10 retail packs that can be sold individually. There is no price for the individual pack of gum when you purchase it wholesale. So it seems to me that if we can define the item, then create multiple marketing packages that reflect the quantities we can buy it in from our suppliers then we can define our supplier price on the marketing package and have a more realistic scenario of how we purchase. I think that what I have proposed meets all the above requirements. Under your scenario we would have to calculate the actual unit cost, which could create rounding errors. The unit cost is only computed when the inventory is received (and InventoryItem is created), but this will happen also if we implement the receiving/unpacking of "vendor packs" (marketing packages). Note that I do believe the functionality you are describing needs to work since there will be cases where the original item does need to be purchased in discrete quantities. But in that case I would avoid the calculation to determine the unit cost and just put in the proper unit cost in SupplierProduct. A check on the minimumOrderQuantity and orderQtyIncrements would make sense to make sure you are creating a PO the supplier will accept. I see unitsIncluded as really just a piece of information for items that would never be broken down to the individual unit, like a bag of screws that would never be sold as individual screws, but you do need to know how many are in the bag. I think that this information could be stored in Product. piecesIncluded field. If you take the approach I am suggesting you will need to fix the issue with not being able to receive a marketing package and have it properly broken down and put into inventory. This is the same problem that exists with returns so this could be a high value fix. I agree that implementing automatic mkt pkg disassembly would be a nice feature (however there will be other processes to fix, MRP and some reports, to properly show correct information if we purchase and sell different product ids that related to the same inventory); but for this specific use case scenario I just don't think it is needed. Jacopo Vince Clark vcl...@globalera.com (303) 493-6723 - Original Message - From: "Jacopo Cappellato" To: dev@ofbiz.apache.org Sent: Sunday, July 19, 2009 4:03:22 AM GMT -07:00 US/Canada Mountain Subject: Implementing processes to support SupplierProduct.unitsIncluded field Scenario: a company sells the product WG- to its customers at 0.1$ each. The company purchases WG- from a supplier, but the supplier sells it in boxes containing 1000 pieces of WG-, at the price of 5$ for a box. When the purchased products are received from the supplier, the boxes are opened and the individual WG- are put in warehouse, increasing the inventory units of WG-. Proposed data mapping: SupplierProduct. productId: WG- SupplierProduct. supplierProductId: WGBOX10 SupplierProduct. supplierProductName: Box containing 10 pieces of WG- SupplierProduct. unitsIncluded: 1000 SupplierProduct. lastPrice: 5$ (this means that the unit cost is 0.005$) Purchase Order for 2 boxes (2000 pieces): OrderItem.productId: WG- OrderItem.quantity: 2000 OrderItem.unitPrice: 5$ NOTE: during order entry the system should only allow quantities that are multiple of SupplierProduct. unitsIncluded NOTE: the above setup will require to change all the purchase documents (order, invoice etc...) to compute order item amount as: OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice For example, the purchase order PDF sent to the supplier will show: Product: WGBOX10 Quantity (OrderItem.quantity / SupplierProduct. unitsIncluded): 2 Unit Price: 5$ Total Amount (OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice): 10$ Is it an acceptable solution? Apart from this, everything should work just f
[jira] Updated: (OFBIZ-2738) (Accounting) Junit test case for servic - setFinAccountTransStatus.
[ https://issues.apache.org/jira/browse/OFBIZ-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Surya Kusumakar updated OFBIZ-2738: --- Attachment: Ofbiz_2738.patch Here is the test case patch for service setFinAccountTransStatus. -- Regards Surya Kusumakar > (Accounting) Junit test case for servic - setFinAccountTransStatus. > --- > > Key: OFBIZ-2738 > URL: https://issues.apache.org/jira/browse/OFBIZ-2738 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Sumit Pandit > Fix For: SVN trunk > > Attachments: Ofbiz_2738.patch > > > Write a jUnit Test case for new service - setFinAccountTrans status. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: all accounting specialists please read
Interesting point and sure we should consider this. Still I think that having a view from which you expect to see all entries...and where it can happen some are not shownperhaps do both? On Sun, 2009-07-19 at 09:43 -0700, BJ Freeman wrote: > It would seem that using _NA_ when the record is made would give you two > advantages. > 1) it would let you see all records > 2) let you use the _NA_ in searches to see what is not assigned. > > Hans Bakker sent the following on 7/19/2009 7:48 AM: > > I am digging in the accounting module and found the following I need > > your advice on. > > > > There is view called "AcctgTransAndEntries" > > > > this view links mainly the AcctgTrans and AcctgTransEntries together. > > > > However it also links the GlAccountId and the GlAccountClass in the > > view, which means if the transaction does not have a GlAccountId or > > GlAccountClassId it will not show. > > > > This 'anomaly' shows most on the invoice transactionlist at the bottom > > of the screen, if no glAccountId could be found the transaction is not > > listed, but is there. > > > > so it is proposed that these fields are optional in this view: > > - > > + > rel-optional="true"> > > > > > > - > > + > rel-optional="true"> > > > > HOWEVER. > > > > This view is used in many places in services. I scanned most of them and > > there is often a selection on GlAccount of GlAccountClass so the outcome > > should still be the same. > > > > So can i put in this change? I realize it could have some impact on the > > accounting processing and everybody should be aware of this change. > > On the other hand every service should get all the entries of a > > transaction and not only the ones with a filled account and class... > > > > Regards, > > Hans > > > -- Antwebsystems.com: Quality OFBiz services for competitive rates
Re: all accounting specialists please read
If the system cannot find the GLAccountId it is left null and the record is put in the error journal so it can be null Regards, Hans On Sun, 2009-07-19 at 17:15 -0500, Vince Clark wrote: > GlAccountId is a required field in AcctgTransEntry so I don't see how it > could not be there in the transaction. > > Vince Clark > vcl...@globalera.com > (303) 493-6723 > > - Original Message - > From: "Hans Bakker" > To: "dev" Sent: Sunday, July 19, 2009 8:48:20 AM GMT -07:00 US/Canada Mountain > Subject: all accounting specialists please read > > I am digging in the accounting module and found the following I need > your advice on. > > There is view called "AcctgTransAndEntries" > > this view links mainly the AcctgTrans and AcctgTransEntries together. > > However it also links the GlAccountId and the GlAccountClass in the > view, which means if the transaction does not have a GlAccountId or > GlAccountClassId it will not show. > > This 'anomaly' shows most on the invoice transactionlist at the bottom > of the screen, if no glAccountId could be found the transaction is not > listed, but is there. > > so it is proposed that these fields are optional in this view: > - > + rel-optional="true"> > > > - > + rel-optional="true"> > > HOWEVER. > > This view is used in many places in services. I scanned most of them and > there is often a selection on GlAccount of GlAccountClass so the outcome > should still be the same. > > So can i put in this change? I realize it could have some impact on the > accounting processing and everybody should be aware of this change. > On the other hand every service should get all the entries of a > transaction and not only the ones with a filled account and class... > > Regards, > Hans > -- Antwebsystems.com: Quality OFBiz services for competitive rates
Re: all accounting specialists please read
Hi If you think about unposted transactions or transactions that fall into the Error Journal then you can get the case where the GLAccountId isnt included in one or both sides of the accounting transaction. I think this normally happens because there is missing setup in the GL account defaults showing what the default account should be. Thanks Sharan Vince Clark wrote: > > GlAccountId is a required field in AcctgTransEntry so I don't see how it > could not be there in the transaction. > > Vince Clark > vcl...@globalera.com > (303) 493-6723 > > - Original Message - > From: "Hans Bakker" > To: "dev" Sent: Sunday, July 19, 2009 8:48:20 AM GMT -07:00 US/Canada Mountain > Subject: all accounting specialists please read > > I am digging in the accounting module and found the following I need > your advice on. > > There is view called "AcctgTransAndEntries" > > this view links mainly the AcctgTrans and AcctgTransEntries together. > > However it also links the GlAccountId and the GlAccountClass in the > view, which means if the transaction does not have a GlAccountId or > GlAccountClassId it will not show. > > This 'anomaly' shows most on the invoice transactionlist at the bottom > of the screen, if no glAccountId could be found the transaction is not > listed, but is there. > > so it is proposed that these fields are optional in this view: > - > + rel-optional="true"> > > > - > + rel-optional="true"> > > HOWEVER. > > This view is used in many places in services. I scanned most of them and > there is often a selection on GlAccount of GlAccountClass so the outcome > should still be the same. > > So can i put in this change? I realize it could have some impact on the > accounting processing and everybody should be aware of this change. > On the other hand every service should get all the entries of a > transaction and not only the ones with a filled account and class... > > Regards, > Hans > > -- > Antwebsystems.com: Quality OFBiz services for competitive rates > > > -- View this message in context: http://www.nabble.com/all-accounting-specialists-please-read-tp24557664p24562889.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Updated: (OFBIZ-2723) OFBiz 09.04 Chinese Localization
[ https://issues.apache.org/jira/browse/OFBIZ-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Yusen updated OFBIZ-2723: - Attachment: localization-zh-09.04-applications-party.patch > OFBiz 09.04 Chinese Localization > > > Key: OFBIZ-2723 > URL: https://issues.apache.org/jira/browse/OFBIZ-2723 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04 >Reporter: Shi Yusen > Attachments: localization-zh-09.04-applications-accounting.patch, > localization-zh-09.04-applications-content.patch, > localization-zh-09.04-applications-humanres.patch, > localization-zh-09.04-applications-manufacturing.patch, > localization-zh-09.04-applications-marketing.patch, > localization-zh-09.04-applications-order.patch, > localization-zh-09.04-applications-party.patch > > > I have started to localize OFBiz 09.04 to Chinese. I'll put all the patches > in this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Implementing processes to support SupplierProduct.unitsIncluded field
Jacopo I'm concerned about breaking everything down to unit cost. This is why one of the solutions we have suggested to you for this is equivalent to how we are handling this on the sales side. We define a product at the unit level, but we do not sell this product. Instead, we create marketing packages that we call "retail packs". Then we set the price there. On the purchasing side, at least in our situation it is unusual for a supplier to provide unit or piece pricing. They only provide pricing for "vendor packs" or "wholesale packs" which are often really just some quantity greater than one of retail packs. So for example a vendor pack might really just be 10 retail packs. This is much like walking into a warehouse club like Sam's or Costco (not sure what the equivalents are in other regions) and buying a large quantity of chewing gum. When you open up the "vendor pack" that you purchased wholesale you will have 10 retail packs that can be sold individually. There is no price for the individual pack of gum when you purchase it wholesale. So it seems to me that if we can define the item, then create multiple marketing packages that reflect the quantities we can buy it in from our suppliers then we can define our supplier price on the marketing package and have a more realistic scenario of how we purchase. Under your scenario we would have to calculate the actual unit cost, which could create rounding errors. Note that I do believe the functionality you are describing needs to work since there will be cases where the original item does need to be purchased in discrete quantities. But in that case I would avoid the calculation to determine the unit cost and just put in the proper unit cost in SupplierProduct. A check on the minimumOrderQuantity and orderQtyIncrements would make sense to make sure you are creating a PO the supplier will accept. I see unitsIncluded as really just a piece of information for items that would never be broken down to the individual unit, like a bag of screws that would never be sold as individual screws, but you do need to know how many are in the bag. If you take the approach I am suggesting you will need to fix the issue with not being able to receive a marketing package and have it properly broken down and put into inventory. This is the same problem that exists with returns so this could be a high value fix. Vince Clark vcl...@globalera.com (303) 493-6723 - Original Message - From: "Jacopo Cappellato" To: dev@ofbiz.apache.org Sent: Sunday, July 19, 2009 4:03:22 AM GMT -07:00 US/Canada Mountain Subject: Implementing processes to support SupplierProduct.unitsIncluded field Scenario: a company sells the product WG- to its customers at 0.1$ each. The company purchases WG- from a supplier, but the supplier sells it in boxes containing 1000 pieces of WG-, at the price of 5$ for a box. When the purchased products are received from the supplier, the boxes are opened and the individual WG- are put in warehouse, increasing the inventory units of WG-. Proposed data mapping: SupplierProduct. productId: WG- SupplierProduct. supplierProductId: WGBOX10 SupplierProduct. supplierProductName: Box containing 10 pieces of WG- SupplierProduct. unitsIncluded: 1000 SupplierProduct. lastPrice: 5$ (this means that the unit cost is 0.005$) Purchase Order for 2 boxes (2000 pieces): OrderItem.productId: WG- OrderItem.quantity: 2000 OrderItem.unitPrice: 5$ NOTE: during order entry the system should only allow quantities that are multiple of SupplierProduct. unitsIncluded NOTE: the above setup will require to change all the purchase documents (order, invoice etc...) to compute order item amount as: OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice For example, the purchase order PDF sent to the supplier will show: Product: WGBOX10 Quantity (OrderItem.quantity / SupplierProduct. unitsIncluded): 2 Unit Price: 5$ Total Amount (OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice): 10$ Is it an acceptable solution? Apart from this, everything should work just fine (when items are received into inventory etc...); the inventory item unit cost will be computed as: total amount / inventory units = (OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice) / OrderItem.quantity = 10 / 2000 = 0.005$ What do you think? Jacopo
Re: all accounting specialists please read
GlAccountId is a required field in AcctgTransEntry so I don't see how it could not be there in the transaction. Vince Clark vcl...@globalera.com (303) 493-6723 - Original Message - From: "Hans Bakker" To: "dev" + - + HOWEVER. This view is used in many places in services. I scanned most of them and there is often a selection on GlAccount of GlAccountClass so the outcome should still be the same. So can i put in this change? I realize it could have some impact on the accounting processing and everybody should be aware of this change. On the other hand every service should get all the entries of a transaction and not only the ones with a filled account and class... Regards, Hans -- Antwebsystems.com: Quality OFBiz services for competitive rates
[jira] Created: (OFBIZ-2739) This patch is for Improvent in HR module in Global Hr Setting tabs in Paygrade section.
This patch is for Improvent in HR module in Global Hr Setting tabs in Paygrade section. Key: OFBIZ-2739 URL: https://issues.apache.org/jira/browse/OFBIZ-2739 Project: OFBiz Issue Type: Improvement Components: humanres Affects Versions: SVN trunk Environment: Window XP, JDK 1.6, Processor :t5...@1.83ghz, 1.99GB of RAM Reporter: Pradeep Ruhil Priority: Minor Fix For: SVN trunk In this patch I have solved two problems that were ocurring in HR->Global HR Setting-> Pay Grades-> First : When you edit a pay grade id that is already created by clicking the payGradeId , it will redirect to edit Pay Grade Screen, In this when we press the save button it gives me this exception : The Following Errors Occurred: Error calling event: org.ofbiz.webapp.event.EventHandlerException: No rows to process. This is coming because in the controller.xml the service type is written 'service-multi' for the URI 'updatePayGrade' , as their are no multiple rows present in Edit Pay Grade screen, so thats why that error was coming. So i changed the service event type to 'service' and error was resolved. Second: This issue is that when you select any payGradeId that is already created and then you check the Salary Steps for that payGradeId, it was showing the Salary Steps of all the payGradeId present. So I resolved that issue and now it will display the Salary Step for the selected payGradeId only. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: all accounting specialists please read
It would seem that using _NA_ when the record is made would give you two advantages. 1) it would let you see all records 2) let you use the _NA_ in searches to see what is not assigned. Hans Bakker sent the following on 7/19/2009 7:48 AM: > I am digging in the accounting module and found the following I need > your advice on. > > There is view called "AcctgTransAndEntries" > > this view links mainly the AcctgTrans and AcctgTransEntries together. > > However it also links the GlAccountId and the GlAccountClass in the > view, which means if the transaction does not have a GlAccountId or > GlAccountClassId it will not show. > > This 'anomaly' shows most on the invoice transactionlist at the bottom > of the screen, if no glAccountId could be found the transaction is not > listed, but is there. > > so it is proposed that these fields are optional in this view: > - > + rel-optional="true"> > > > - > + rel-optional="true"> > > HOWEVER. > > This view is used in many places in services. I scanned most of them and > there is often a selection on GlAccount of GlAccountClass so the outcome > should still be the same. > > So can i put in this change? I realize it could have some impact on the > accounting processing and everybody should be aware of this change. > On the other hand every service should get all the entries of a > transaction and not only the ones with a filled account and class... > > Regards, > Hans > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator.
all accounting specialists please read
I am digging in the accounting module and found the following I need your advice on. There is view called "AcctgTransAndEntries" this view links mainly the AcctgTrans and AcctgTransEntries together. However it also links the GlAccountId and the GlAccountClass in the view, which means if the transaction does not have a GlAccountId or GlAccountClassId it will not show. This 'anomaly' shows most on the invoice transactionlist at the bottom of the screen, if no glAccountId could be found the transaction is not listed, but is there. so it is proposed that these fields are optional in this view: - + - + HOWEVER. This view is used in many places in services. I scanned most of them and there is often a selection on GlAccount of GlAccountClass so the outcome should still be the same. So can i put in this change? I realize it could have some impact on the accounting processing and everybody should be aware of this change. On the other hand every service should get all the entries of a transaction and not only the ones with a filled account and class... Regards, Hans -- Antwebsystems.com: Quality OFBiz services for competitive rates
Implementing processes to support SupplierProduct.unitsIncluded field
Scenario: a company sells the product WG- to its customers at 0.1$ each. The company purchases WG- from a supplier, but the supplier sells it in boxes containing 1000 pieces of WG-, at the price of 5$ for a box. When the purchased products are received from the supplier, the boxes are opened and the individual WG- are put in warehouse, increasing the inventory units of WG-. Proposed data mapping: SupplierProduct. productId: WG- SupplierProduct. supplierProductId: WGBOX10 SupplierProduct. supplierProductName: Box containing 10 pieces of WG- SupplierProduct. unitsIncluded: 1000 SupplierProduct. lastPrice: 5$ (this means that the unit cost is 0.005$) Purchase Order for 2 boxes (2000 pieces): OrderItem.productId: WG- OrderItem.quantity: 2000 OrderItem.unitPrice: 5$ NOTE: during order entry the system should only allow quantities that are multiple of SupplierProduct. unitsIncluded NOTE: the above setup will require to change all the purchase documents (order, invoice etc...) to compute order item amount as: OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice For example, the purchase order PDF sent to the supplier will show: Product: WGBOX10 Quantity (OrderItem.quantity / SupplierProduct. unitsIncluded): 2 Unit Price: 5$ Total Amount (OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice): 10$ Is it an acceptable solution? Apart from this, everything should work just fine (when items are received into inventory etc...); the inventory item unit cost will be computed as: total amount / inventory units = (OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice) / OrderItem.quantity = 10 / 2000 = 0.005$ What do you think? Jacopo
