> On Jul 24, 2019, at 1:08 PM, Rosi Dimova wrote:
>
> Hi Frank,
>
>> On 24 Jul 2019, at 17:47, Frank H. Ellenberger
>> wrote:
>>
>> Hi Rosi,
>>
>>> Am 24.07.19 um 09:12 schrieb Rosi Dimova via gnucash-devel:
>>> :
>>> I never understood this decision to make translators part of dev-team.
But what you are speaking of here appears to me to be more of a document
management or inventory management feature, not an accounting feature.
I’d be inclined to agree with John, that is out of scope for GnuCash.
I understand the industry might have a need for such features, particularly
open
Hi Frank,
> On 24 Jul 2019, at 17:47, Frank H. Ellenberger
> wrote:
>
> Hi Rosi,
>
>> Am 24.07.19 um 09:12 schrieb Rosi Dimova via gnucash-devel:
>> :
>> I never understood this decision to make translators part of dev-team.
>
> you are our ambassador to all Bulgarian speaking people. :-)
>
Hi Rosi,
Am 24.07.19 um 09:12 schrieb Rosi Dimova via gnucash-devel:
:
> Besides, when personal interests of actual developers step in, GPL might be a
> tough task to keep. As already told you, I’m no software developer and the
> only experience in my life is this translation. Yet it is far
Hi Maf, you're welcome; thanks for letting me know.
The dates are printed via gnucash's date-printer and will probably obey
the locale or general preferences setting. Try Preferences/Date
I'm still considering how to incorporate the UK rules into the current
merged report; I now know the
Hi Christopher,
I've just submitted the first MTD VAT return using GC and the report you very
kindly wrote.
The only glitch discovered in actual production use is that the dates exported
by the report in to the CSV file and hence read by the bridging spreadsheet
need to have a 4-digit year,
> On 24 Jul 2019, at 7:32, John Ralls wrote:
>
>
>
>> On Jul 23, 2019, at 11:59 AM, Rosi Dimova wrote:
>>
>> Hello,
>>
>>
>>> On 23 Jul 2019, at 20:18, John Ralls wrote:
>>>
>>> That would be *way* out of scope for GnuCash. The only effect on accounting
>>> is when the change in
