On Mon, Aug 8, 2011 at 2:19 PM, Nigel Titley <[email protected]> wrote:
> No, unfortunately that doesn't work. If I supply goods to one customer > in France for whom I have the VAT number then I don't charge VAT but I > have to report it on the ECSL form. On the other hand for his neighbour > next door, for whom I don't have the VAT number, I charge VAT at the UK > rate and *don't have to report it on the ECSL form (but I do have to > report it as VAT). Ok, so per customer then. The tax form system of 1.3 would be virtually ideal for this. You could create three tax forms and attach them to customer accounts, then track what's reportable or not, and report on it. The only issue is accrual vs cash (the current reports are cash-basis, but accrual is easier to implement so that's not an obstacle). > >> Would it be helpful to require that a transaction be tied to a >> location (either store or shipping address)? Then reports could be >> generated using some sort of location-specific logic. It would also >> help with things like the SST insanity that seems to be sweeping the >> US. > > No... it is customer specific... hence our solution using Sales > accounts. You *could* use rough logic like Perfect. That makes this largely a reporting issue in 1.3. > > But this only works for us because we don't sell zero rated goods like > baby clothes. So basically we need to write EU vat tax reports. > Cash is an option in UK, and can be helpful with cashflow Ok, so the 1099 reports can serve as a basis there, though will probably have to be tweaked for local rules. > >> > Although my personal needs would probably be served by a solution like >> > Nigel's, I'd like to warn for the explosion of a chart of accounts, if too >> > many information requirements are encoded into the accounts. I've worked >> > for >> > a company where 2 accounts have been blown up into 64 accounts, simply >> > because they encoded required reporting information into them. >> > The information encoded into the accounts was derived classification from >> > the customers. As a result, the accountant was forced to redo the >> > derivation >> > regularly, finding differences and creating reclassification postings to >> > keep accurate reporting information. > > I agree... it's a pain, but I can't think of any other way to do it in a > general and portable fashion. >From what you are saying in 1.2, that's probably the case. In 1.3, we have additional ways to categorize customers for tax reporting which should help this a lot. > >> Just to be clear, in the end we would want to support whatever ways >> people in the community find most helpful. The larger issues have to >> do with inventory tracking items and the fact that sales accounts >> don't admit readily of this sort of default that Nigel is doing in >> that case as a generally applicable approach. > > I'd really like to understand what the issues are with inventory > tracking and multiple sales accounts. Ok.... so example.... suppose I sell items I want to track in different categories. Maybe I sell complete computers, computer repair services, and computer parts. I might set up sales accounts like: 4110 Computer Systems 4120 Computer Parts 4130 Computer Repair Services 4140 IT Consulting Services Now I want to categorize sales by defaulting a customer account to an income account. I can't do that per se. Instead I would have to suffix them like: 4110-01 Computer Systems, VAT Taxable 4110-02 Computer Systems, Exmpt non-export 4110-03 Computer Systems, Export etc. However with the default account stuff, I fundamentally cannot track accounts across multiple criteria. Consequently, it can't work as a general solution even if it works for a single customer. > You need to record whether the delivery was made under the intra-EU > reverse VAT scheme, but in my view that's a less general solution. Ok. Have to think about that more. >> >> > Nigel, does the above sound like what your perl script for ECSL form >> > submission is doing? > > Yes, roughly. What my perl script does is searches for all invoices to > EU countries (which, I must say, would be easier to do if the country > fields were constrained to a list) and which have zero VAT. But as I > say, this only works because we don't sell food and baby clothes. 1.3 constrains countries to a list. > > If we could set general attributes onto transactions then this would > work in the general case and we could extract the appropriate reports. > I'd be very happy to go down this route rather than the sales account > route. Ok,so what 1.3 does for you (and this is new since the patch was commissioned is): 1) Allow tax forms to be attached to customers/vendors. So you can say "this vendor is an ECSL vendor" and "This customer is an ECSL customer." You could also say "This vendor is a VAT vendor" and "This customer is a VAT customer" as well as "This customer is a VAT export customer" etc. This should make the reporting a LOT easier. 2) Countries are constrained to a list. Is there anything else that would have to be stored that is not? Bet wishes, Chris Travers ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
