Evaluating xTuple: Credit Card expenses, AU GST and Time billing
Hello, I am doing another quick eval of xTuple (Postbooks edition) to see if I can use it in my small business.
This is a consulting business, where the primary product is billable hours. I am hoping someone can answer the following, as most of the forum discussion on these items seems to be a bit old:
1) Expenses - we try and confine all of our expenses to credit cards, which allows us to download a csv from our cc provider, ready for import. The discussion I have seen suggests that there isn't a way to import these expenses very easily (and then assign them to expense categories). Is that the case?
2) GST. Australian Sales Tax is recognisable when the money actually comes in or goes out, which is important for a small business with untimely customers. It is possible to get a tax report on income and expenses rather than on invoices? I have seen in the AU forum someone has written a script to do this outside of postbooks.
3) Time billing. This can be done manually of course, but currently I use OpenERP and enter my time in a timesheet, and I can produce either consolidated or per-item invoices for customers. Postbooks doesn't appear to have the same functionality, so I guess this would be done externally?
Thanks for your time,
Paul
Hey Paul,
We are the same sort of Australian business and have been using Postbooks for 6 weeks and as of 1st July officially using it as our only ERP/accounting system.
In summary, xTuple Postbooks is fantastic and meets our needs. There is a steep learning curve to get it setup and sometimes you feel like your banging your head against a wall but the investment is well worth it and shortomings easily outweighed by the positives.
Regarding GST: It sounds like you are using Cash Basis accounting rather than Accrual basis. If so then there is a NZ GST addon for Cash Basis accounting you can use. We are accruals basis so don't use it.
Regarding Time Billing: Buy the TE Pro addon from xChange. It's pricey at US$399 but it is well worth it for a services business in fact it's essential as you'd easily consume more than $400 of labour trying to mold xTuple to achieve the same functionality.
One note regarding TE Pro and invoicing from timesheets - you'll need to edit the functions *invoice* and *consolidateinvoice* under postgres schema *te* to do something useful with teitem_workdate as it does nothing with it. That is, your timesheet generated invoices don't show what date the line item was worked by the consultant which really isn't great for your customers. To get around this we add the contents of teitem_workdate into teitem_note so that the day worked shows up in the invoice in the note line item field.
Regarding Expenses: For customer reimbursable expenses TE Pro is also useful but your comment pretty much holds true. The whole cheque (check) centric payment paradigm of xTuple can be cumbersome for modern EFT/CC centric companies like ours where we don't even have company cheques/checks (on purpose) but the flip side is that there are some fantastic control-points in the process of AP vouchering/payment which helps when you are using credit cards to pay for foriegn currency items frequently and want to handle bank currency conversion fees etc. which are never on the invoice but appear on your bank statement a few days later.
Suggestion to anyone who reads this post: Utilise the Postgres DB and backup/restores and multiple DB's like company_production company_test then create some scripts which backup one and restore to the other to keep them in sync and then use the "test" DB for testing stuff before applying to your "production" DB. We also take a psql backup whenever a significant number of transactions/entries are made to facilitate quick roll-backs. We also have a DB called company_training and new employees are configured to use that while learning the system and each week or so it's erased (dropped) and refreshed with the latest company_production backup ie. it's a playpen/sandpit
Regards,
Johnathon
One more piece of advice to anyone from AU, NZ, UK companies reading this ....
Before you use the QuickStart wizard to configure your shiny new xTuple ERP system do this ...
Accounting -> Fiscal Calendar -> Fiscal Years and after that Accounting Periods and configure them for your company. By default they are Jan-Dec whereas in Australia we use July-June.
If you complete the Quickstart Wizard then go on your merry way and add a bunch of journal entries or transactions and later try to retrospectively correct incorrect Accounting Periods it will not let you and you'll be stuck with something like July being in Q3 instead of Q1.
Configuring Fiscal Years and Accounting Periods should really be the first steps in the Quickstart Wizard add-on.
If your searching for a solution to this problem then use psql to look at the records in schema *public*, tables *yearperiod* and *period* and column *period_quarter* etc. Assuming XXX = the correct quarter number and YYY = the period of of the incorrect period row then you should be able to do something like *
select * from yearperiod;
select period_id, period_start, period_end, period_name, period_yearperiod_id, period_quarter, period_number from period;
update period set period_yearperiod_id = XXX where period_id = YYY;
Finally, make sure your support agreement with xTuple is current before performing the above. You also might want to check with them before performing such an update. It worked for us but may cause problems for your database.