[ 
https://issues.apache.org/jira/browse/OFBIZ-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658363#action_12658363
 ] 

David E. Jones commented on OFBIZ-2097:
---------------------------------------

Does anyone care about multi-organization support in OFBiz? If so, could you 
please help me communicate with Hans about issues with this sort of approach? I 
already tried with the issue of billing for WorkEfforts and he ignored me 
there, and evidently it really didn't make it through because this is going in 
the same direction.

Doing things based on an organizationPartyId associated with the user is BAD 
BAD BAD, and basically kills the multi-organization support in OFBiz.

In the WorkEffort example: you want the organization associated with the 
WorkEffort, and NOT with the user logged in. For example say you have a project 
WorkEffort and you want to do billing for it, and there is a service provider 
Party associated with the WorkEffort. If a user logs in to bill for that 
WorkEffort and the organizationPartyId is associated with the user then it 
doesn't matter who the service provider organization is, the user's 
organizationPartyId will be the from Party on the invoice. In other words, 
different people could login to generate the invoice and have different from 
Parties on the invoice, based solely on who is logged in.

Internal Organization parties should be associated with things like 
ProductStore, WorkEffort, etc, etc... but NOT with the logged in user or the 
Party associated with the logged in user.

Am I the only who sees a problem with this? Am I losing my mind? Hello? Anyone?

> show organizationPartyId in header, rewrote financial history for a party in 
> relation to the organizationParty
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-2097
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2097
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: accounting, party
>    Affects Versions: SVN trunk
>            Reporter: Hans Bakker
>            Assignee: Hans Bakker
>             Fix For: SVN trunk
>
>         Attachments: organizationPartyHist.diff
>
>
> Because this is a rather bigger change i first put it as proposal. When no 
> major objections i will commit it in a few days.
> first of all if only one currency is being used for the currency of the 
> organizationPartyId, there are no changes to the system.
> So, when I was changing the financial history to accommodate invoices being 
> in different currency as the organization partyId, I saw that having the 
> current organizationPartyId defined, is an essential requirement. Building on 
> the organizationPartyId in preferences it is required to know at any time 
> what the current assignment is. That is why I added it to the global context 
> and show it on the top header.
> The invoice/payment worker was changed to be able to select the currency to 
> be displayed.
> The changes more in detail:
> 1. introduced 2 new variables in the global context:
>       a. organizationPartyId
>       b. organizationPartyUomId
> the organizationPartyId is stored in the users preferences and can be changed 
> there.
> Created a new entry in general.properties to define a default 
> organizationPartyId when not set for the current logged in user.
> Showed the organizationPartyId in the header now. It gets a bit full there 
> perhaps we should move the language and location to the user preferences 
> screen because not change often?
> 2. Paymentworker and Invoice worker if now aware of the different invoice 
> currencies and invoice amounts can now be retrieved in the actual or 
> organizationPartyUomId currency.  If everything is the organizationParty 
> currency, there is no functional change to the system
> 3. Financial history now displays these two currencies when available making 
> use of the new new payment/invoice worker methods.
> 4. New payment screen entry now only allows Disbursement and Taxpayment for 
> outgoing payments and receipts for incoming payments.
> 5. removed many 'key-field-name' entries where not required in the payment 
> forms
> 6. invoice PDF button "other currency" now only shows if there is a other 
> currency available  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to