On 19 Feb 2009, at 05:49, Chris Travers wrote:
> ...
> Orders are not financial transactions. ...
Right. But from the below they can be turned into financial
transactions when I turn them into invoices?
> Otherwise, orders are basically pre-invoices and could be used as
> draft invoices.
Tha
On Wed, Feb 18, 2009 at 9:44 PM, Stroller
wrote:
>
> On 19 Feb 2009, at 00:50, Chris Travers wrote:
>> ...
>> You can already do this to an extent with orders vs invoices, but this
>> is a little different. For a draft sales invoice, one could not
>> create an authoritative view of the COGS until
On 19 Feb 2009, at 00:50, Chris Travers wrote:
> ...
> You can already do this to an extent with orders vs invoices, but this
> is a little different. For a draft sales invoice, one could not
> create an authoritative view of the COGS until it is approved because
> of the problem discussed before
On 18 Feb 2009, at 19:35, Chris Travers wrote:
> The short version of my last post is that I don't like building
> accounting systems where there are no clearly defined right numbers
> that are supposed to come out of it. Once we get off the basic GAAP
> (FASB/IASB common ground and accepted pro
On Wed, Feb 18, 2009 at 4:14 PM, Chris Bennett
wrote:
> As Chris suggested, a one button, quick reversal system would be great.
> Perhaps there may be a way of excluding the mistaken and their reversed
> transactions from informal reports (but never from formal reports).
>
Actually one of the ele
Chris Travers wrote:
> The short version of my last post is that I don't like building
> accounting systems where there are no clearly defined right numbers
> that are supposed to come out of it. Once we get off the basic GAAP
> (FASB/IASB common ground and accepted processes),* it becomes
> impos
The short version of my last post is that I don't like building
accounting systems where there are no clearly defined right numbers
that are supposed to come out of it. Once we get off the basic GAAP
(FASB/IASB common ground and accepted processes),* it becomes
impossible to define exactly how the
Turtle:
Part of the problem is that when you edit and repost an invoice, there
are a number of nasty corner cases which can bite you. Since the
workflow is non-GAAP, there are no accepted mathematical solutions to
this problem.
Let me give you an example. Suppose you sell an item which has a ve
On Friday 13 February 2009 11:43:12 David F. Skoll wrote:
> Sorry if this is getting off-topic for the devel list...
>
> > BTW, these aren't just non-standard workflows. From an accounting
> > perspective, they are wrong workflows because they break auditability.
> > Technically, you aren't suppo
On Wed, Feb 18, 2009 at 9:07 AM, David F. Skoll wrote:
\
> It would completely fail. We don't issue any security-sensitive
> messages over the IRC channel. And obviously, malicious users could
> easily spoof messages. If we were to do this seriously, we'd have to
> use a message bus with guaran
Chris Travers wrote:
> Actually, I think it is a very elegant solution. However, I would
> wonder about security issues in scaling up. It might work well for a
> 10 person company, but what if you want to add security-sensitive
> information over the messaging layer?
It would completely fail.
On Wed, Feb 18, 2009 at 8:03 AM, David F. Skoll wrote:
> Paul Wrightson wrote:
>
>> Wow - Enterprise Service Bus via IRC!
>
> Hey, if it's good enough to control a botnet with a hundred thousand hosts,
> it's good enough for a 10-person company. :-)
Actually, I think it is a very elegant solution
Paul Wrightson wrote:
> Wow - Enterprise Service Bus via IRC!
Hey, if it's good enough to control a botnet with a hundred thousand hosts,
it's good enough for a 10-person company. :-)
> What is the overhead of supporting the IRC and robots?
What do you mean by "overhead"? If you mean CPU or ne
Wow - Enterprise Service Bus via IRC!
What is the overhead of supporting the IRC and robots?
Did you consider MQ or similar?
Paul W
David F. Skoll wrote:
> sends a specially-formatted message on an internal IRC channel.
>
> On our desktops, we have robots listening on the IRC channel. When they
Ed W wrote:
> I would love to see a bit more about how you integrated Asterisk and Sugar?
When a call comes in, we make an system() call in the dialplan to a Perl
script that looks up the Caller*ID in Sugar. If it finds an account, it
sends a specially-formatted message on an internal IRC channe
David F. Skoll wrote:
> shaker Khzym wrote:
>
>
>> Thank you for your reply David.
>>
>
>
>> What tasks are available to you by integrating Ledgersmb with RT?
>>
>
> Well, instead of posting a long explanation to the list, have a look
> at these slides I made:
>
> http://media.skoll
16 matches
Mail list logo
