Search options (Page 3 of 6)

Thank you. Your efforts are most appreciated. As are those of Joe and Janusz, of course.

I'll install it tonight. I shouldn't need any of the fancier features, so hopefully it's good enough for production use. (I presume it's still beta grade, but I'll take my chances.)

Have we done away with the non-UTF encodings yet?

I wouldn't bother with A5. Even if I wanted to print the documents in A5 format, I would generate them in A4 and scale the file down either when saving it or (preferably) when it goes to the printer.

Have you looked at the usual tools for pdf and ps manipulation? pdftk, gs and the like?

Adding a prefix should be simple enough. The tricky bit is to have the sequence reset for each new month. I guess it could be bolted on using a separate field in the database, but internally the documents would still have a plain sequence number.

OK, I was wrong on that. I could have sworn there was one, but... Sorry.

If you have the accounts in a CSV file, I'm sure Joe can generate the required sql. That seems to be how it's usually done.

On a more constructive note, one thing we might consider would be reusing COAs defined by/for other projects. Has anyone looked into this?

If you don't mind account names in Dutch, there is indeed a Belgian COA you could use.

I suggest you install it, and have a look. If it looks (structurally) correct, you could replace the account names in the sql file with their French equivalents. You only need to do this for the accounts you actually use, but if you translate all of them the new file can be included in the repo for the benefit of all Belgians. Or, at least, some of them.

As for the language pack, I suspect the problem is that it expects the fr_FR locale to be installed on the server, and you probably have fr_BE. If you do get it installed, there may be a few tweaks required but they should be minimal. Even if there are no differences, we should still have a language pack for fr_BE.

That would allow you to greet them with "Dear Mr. Joe" or "Dear Mr. Joe Smith", but not with the far more appropriate "Dear Mr. Smith".

And prepending the title to the surname would yield "Dear Joe Mr. Smith", which is even worse.

For now the best way is the "Dear" + name1 + name2, suggested in the first post, but the proper way would be adding a "title" field to the contact. That's a change that should not break anything.

I don't know how the templates are handled, but ideally they should be translated/adapted according to local customs. And while we're at it, the contacts should probably have a language field as well, so that documents can be issued in that particular language. That would be a nice touch in bilingual countries. Or for anyone doing business in more than one language, for that matter.

I import daily (invoiced) sales from a Prestashop server as journal entries. It's not an ideal solution in my case, as I'd really like to keep track of payments/allocations using FA, but for POS data it's all you need.

Since you basically only need to split the total between sales and tax, and book the amounts to the appropriate accounts, you could use a "quick entry". And if you manage to get the data out of Unicenta programmatically, you can feed it into FA with a single curl call. (Actually two. You'll need one to login and create a session.) You wouldn't even need the CSV import plugin I use.

Let me know if you need any help.

I suspect it's auto(-matic), rather than "self-". While my Spanish is somewhat limited, it seems to be a service for electronic invoices (and/or payment of them) in Mexico. And the ruby code which (I guess) provides an interface to it is written by the same chap who wrote "our" REST API.

He might well have planned to exchange invoice data between Autofactura and FA, using a ruby-based web service. But the API was abandoned (?) before it was finished, so who knows what was actually planned...

The obvious "solution" would be to increase the prices...

(I know 1.79 is supposed to look cheaper than 1.80, but I'm not at all convinced. Personally, I think round figures somehow look more "honest".)

Or you could perhaps adjust the rounding settings. Either globally or by adding a test somewhere to not round when the product is a kit. (In fact, applying rounding at that stage might well be a bug. Perhaps someone else knows the intended behaviour.)

There is an extension for importing journal entries from a CSV file, but that's probably not going to help much. And with that number of transactions, you'd be better off writing them to the database directly.

There have been a few attempts at REST and SOAP API's for this kind of thing, but I don't think anything has ever been completed.

The "numbers" you are seeing are really strings, and they are correctly sorted - but alphabetically. Just pad the numbers with leading zeroes and you'll get what you were expecting.

The only explanation I can think of is if privileges are set on a user basis, from the group's "template" when a group is joined.

Doesn't make much sense, but... At least it would explain why new users get the appropriate privileges.