ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taher Alkhateeb <slidingfilame...@gmail.com>
Subject Re: Budget/forecasting function in accounting
Date Thu, 02 Apr 2015 09:24:56 GMT
Hi Everyone,

Accounting by its very nature is complex and elaborate. I would suggest
instead of creating a new component instead to do the following:
1- simplify the transaction processing screens and reports
2- move all the complexity into the setup screens (parameters) and reduce
menu entries.

So in essence, I think we can really simplify the accounting module by
hiding most stuff into the setup screens and not expose everything the way
we are doing it right now.

My 2 cents

On Thu, Apr 2, 2015 at 11:22 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> So this will be in continuation of https://issues.apache.org/
> jira/browse/OFBIZ-3169 right?
>
> I agree with Pierre to have a specialpurpose component. In the same
> spirit, should we not separate budget from forecasting?
>
> http://www.accountingtools.com/questions-and-answers/
> what-is-the-difference-between-a-budget-and-a-forecast.html
> http://www.financialpreneur.com/?p=162
> http://support.quickbooks.intuit.com/support/articles/INF13041
>
> My 2cts
>
> Jacques
>
> Le 02/04/2015 08:09, Pierre Smits a écrit :
>
>> Hans, All,
>>
>> Might I suggest to separate current budget entities and functionalities
>> from the accounting component into a separate (e.g. special purpose)
>> component. Current accounting application is
>> (screen-/user-experience-wise)
>> already overcrowded with a lot, and adding more might make it even more
>> complex to explain.
>>
>> Separation from accounting enables you and the rest of the OFBiz community
>> to offer the budgeting functionality as an optional to potentials and keep
>> the the additionals (functional documentation, manuals) as concise as
>> possible, while at the same time eventual JIRA issues contained and better
>> visible than when integrated in accounting.
>>
>> 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 Thu, Apr 2, 2015 at 3:57 AM, Hans Bakker <h.bakker@antwebsystems.com>
>> wrote:
>>
>>  Thank you all for your interest.
>>>
>>> We plan to follow chapter 8 of the data model resource book vol 1. I hope
>>> you understand that we first have to find out what this customer
>>> requires,
>>> then generalize the implementation and then i can present the result if
>>> the
>>> customer agrees to contribute it. From that point on, comments on the
>>> implementation can be implemented. The planned implementation with the
>>> customer is June this year.
>>>
>>> Now i see there is interest, I will keep you informed of any
>>> developments.
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> On 01/04/15 17:32, Jacopo Cappellato wrote:
>>>
>>>  Interesting.
>>>> OFBiz has already a "Fiscal Gl Type" field in the transactions (with
>>>> possible values "Budget" etc...) but currently only "actual" type is
>>>> used.
>>>>
>>>> Jacopo
>>>>
>>>> On Apr 1, 2015, at 10:09 AM, Hans Bakker <h.bakker@antwebsystems.com>
>>>> wrote:
>>>>
>>>>   Good day,
>>>>
>>>>> we have a request from a customer to implement a full budget function
>>>>> into accounting of which the entered values should also appear on the
>>>>> standard P&L and balance sheet of a specific organization. Yes this
is
>>>>> a
>>>>> multi company accounting implementation.
>>>>>
>>>>> Anybody any thoughts on this or would like to work with us? I did not
>>>>> not yet discuss this with our customer if this function can be
>>>>> contributed
>>>>> or not, i just would like to know if there is interest of the OFBiz
>>>>> users
>>>>> in general.
>>>>>
>>>>> Because i will be visiting ApacheCon in Austin in 2 weeks, we could
>>>>> also
>>>>> discuss it there?
>>>>>
>>>>> Regards,
>>>>> Hans Bakker
>>>>> CEO http://antwebsystems.com
>>>>>
>>>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message