For 1 perhaps we just default to the same currency as the company record
- ie only allow importing of bank transactions from accounts in the same
currency as the company reports in - so the exchange rate defaults to 1.
So we just don't worry or care about currencies anymore.
I am not so good on workflow but intuitively I would have thought import
transactions from bank hold in a session object then analyse (ie do the
GL entries - or allocate to a supplier/vendor AP account ... what about
payments against a AR customer account too - rare but necessary to cover
off.The analysis entries adding additional object arrays under the bank
transactions import object array - just like with purchase invoices -
with GL and shipment arrays containing the whole details of all the
transactions then - hit the post/enter button and iterate through the
arrays diving down into the sub-arrays posting as one database
transaction - or perhaps one for each payment imported.
These transaction scripts are the trickiest in the system - I suggest
you have a good thorough understanding of the purchase invoice entry
logic and then you'll be in good shape to have a go at this.
Phil
>>
>> We then need some way to:
>>
>> 1. Specify the exchange rate to post transactions at between the
>> functional currency and the currency of the bank account
>> 2. Analyse the payments (or receipts) between numerous GL accounts -
>> potentially several GL accounts might be necessary to post a single payment.
>> 3. If a payment was to a supplier which needs to be posted against the
>> AP supplier account then we need to be able to select or specify the
>> supplier(vendor) code - the system then needs to create the supptrans
>> required.
>
> Hmm, you lost me here:
> 1. Okay, but this is only applicable if the functional currency and the
> bank currency are different right? How often does this happen? I can
> only imagine this could happen to me if I'm in the eurozone and open a
> dollar account? Also I *think* that my bank gives me exchange details
> when I make payments in other currencies. I might be able to snitch the
> exchange rate from there.
> 2. I've never been really strong on GL stuff, however if I look at the
> way my current accounting software works is:
> - create payment or invoice -> assign GL codes here
> - import banking details
> - match payments/invoices against imported bank details
> - finished
> 3. See 2. It would mean a bit of a different approach, but to me seems
> the easiest to implement and the easiest to 'operate' for a user?
>
>
>> Thinking as I type - maybe an import form that specifies the bank
>> account and the exchange rate, perhaps a date range for the transactions
>> to import - hit the button to get the transactions. Then an option to
>> click on the transaction that allows selection of AP payment or GL
>> payment. AP payment allows selection of the supplier (check in the same
>> currency as the payments). GL allows entry of several GL accounts and
>> amounts (in payment currency) reconciling back to the amount of the payment.
>
> Aha! This sounds like my 2 right?
>
>> If the array of payments had sub arrays for GL or AP transactions then
>> all the data could be held in a session class (as other transaction
>> posting scripts). Then when the analysis and supplier selection stuff
>> complete hitting the update/post button would do:
>>
>> 1. The banktrans entries for each payment
>> 2. The gltrans debit entries for the analysis array of each payment or
>> if an AP supplier payment the debit entry to CreditorsControl from the
>> company data session array the and the gltrans entry to credit the bank
>> account
>> 3. If an AP supplier payment then supptrans entry. The allocation to
>> supplier invoices would have to be done later.
>
> I think I got most of that.
>
>> Superb effort here Arnold this is great functionality that would be
>> brilliant to have in the main trunk.
>
> Thanks. To me it would mean that I can stop paying a subscription for
> accounting software, so there is some personal interest as well.
>
> At the moment I have a fairly dumb PHP file and I'm thinking about
> changing this to an OOP PHP file, so the class can be called from
> anywhere. This would probably give us most freedom in attaching it to
> the rest of webERP?
>
> One of the many problems seems to be that MT940 is not really a standard
> at all. I have three MT940 files now and, although most look pretty
> similar, actually all are different on details. This is something to
> consider, before moving it into the main trunk.
>
> Keep those ideas coming. Should we move this discussion to developer
> mailing list?
>
> Arnold.
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
>
http://moblin-contest.org/redirect.php?banner_id=100&url=/> _______________________________________________
> web-ERP-users mailing list
>
web-ERP-users@...
>
https://lists.sourceforge.net/lists/listinfo/web-erp-users>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
Web-erp-developers mailing list
Web-erp-developers@...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers
