7 Responses to “Account overview, downloadable CSV files and more...”

1. bytte Says:
   September 5th, 2007 at 04:51 AM

   Great updates. I hope that one day we’ll be able to design our invoices and estimates ourselves. That would be a HUGE improvement.

2. Alan Bristow Says:
   September 5th, 2007 at 06:43 AM

   1. Each company would have one bricks Accounts dept’ and that would work with one currency, seems a good assumption. So associate a currency with each client company. 2. Work for a client company defaults to the currency set up for that client company. 3. When viewing accounts, possibly allow a default or optional view grouped by currency.

3. Simon Berg Says:
   September 5th, 2007 at 11:22 AM

   Nice! Keep up the good work!

   Simon

4. Seth B / Subimage Says:
   September 5th, 2007 at 12:10 PM

   Bytte

   Designing the HTML and CSS for custom invoices and estimates is coming, right after we work out this billing in other currency stuff ;)

   Alan

   Thats similar to what I’ve been thinking, although its only a little bit of the picture.

   Right now in dev you can define a “home currency” for a client. However, I’m going back and forth on how to actually display the different numbers.

   Here’s the thre options I’m deciding on…

   - Option 1. -

   We could show all numbers translated to that company’s home currency in their interface. However, as you know exchange rates change throughout the day and the numbers might be off, according to how the exchange rates are moving.

   - Option 2. -

   We could show all numbers (on the client interface) in your original currency, then your client’s currency underneath.

   This would provide a good frame of reference for your client, but still remain accurate.

   - Option 3. -

   We could do something similar to option 2, but only on the estimate and invoice documents…

   ...Thoughts?

5. Philip Stanley Says:
   September 7th, 2007 at 08:09 AM

   Hi Seth, I’m in favour of option 2 with tweaks – here’s an example from outside of Cashboard, but ‘real world’, current and complicated:

   I have a client company based in the UK who work in Romania on a US funded film:

   My client and his crew need Sterling or they have no internal value picture – they can’t feel the numbers; most of their costs are Sterling. They need to submit estimates and invoices in dollars to the US production accountants or they have no internal value picture.

   The constituent line items need to fit each internal value picture. Labour, hire and materials bills building into a 250,000+ sterling total over a few weeks are used to argue the toss before and during the work.

   The client accepts the estimate in their value picture in its entirety and any subsequent changes (normally uplifts, submission of expenses etc.) are matched off against that.

   Currently my advice on sending estimates has been to show each line item with (primary) sterling calculation and a (secondary) dollar sum translation.

   If the estimate is rebuffed and re-presented it is recalculated anew, but once accepted, the secondary currency is fixed.

   If a second or third or fourth estimate ensue they are calculated on the day, and again, on agreement, the dollar is fixed.

   If additions are incurred, they are calculated at make-up and again, fixed on submission.

   Having a floating, ‘always on’ calculation driven by the primary currency showing for the client figures would be an issue, creating the value view for either party of an apparent under or overspend. It is better (in terms of being grown up and accepting appropriate commercial risk) to shorten the billing periods and hence decrease the invoice values over a job to mitigate currency fluctuation.

   So I think one should show both as per option 2) as a courtesy for client understanding but for an accepted estimate and ensuing invoice all line items and that total should ‘appear’ locked off from further calculation.

   As to how you do it: Perhaps the easiest way is to REVERSE the primary/secondary currency calculation on an accepted estimate/invoice. In this way the client’s figures will stay locked, and fluctuation will be sucked up by the vendor – an acceptable commercial risk.

   Philip

6. Seth / Subimage Says:
   September 7th, 2007 at 02:49 PM

   Philip, definitely what I’m thinking. All figures would be shown in the original currency (which doesn’t fluctuate), and then in the translated currency for reference only.

   My assumption is that people get paid in their home currency anyhow. I don’t think clients will be sending checks in their home (translated) currency. Hopefully that assumption is correct :)

7. Philip Stanley Says:
   September 11th, 2007 at 11:38 PM

   Seth, I think your assumption is reasonable. On the film my clients were paid in their home currency (Sterling) by the US company – however, some other UK parties were asked to bill and were paid in dollars.

   My second half and last paragraph option for reversing and locking the secondary (client currency) at invoice would fix cost in the client currency for those situations, but on reflection I agree it may not be used by the majority of users.

   One of those ‘nice, but not now’ options methinks.

   Philip