On 8/1/07, Eduardo Huertas <[EMAIL PROTECTED]> wrote:
>
>
> Ok, I droped all DB. I tried first with Colombia's
> chart accounts. Added a customer, a vendor, an item.
> Then a vendor's invoice with that item. Now that I
> had inventory tried POS->Sale and ... No way!!
Ok. This is to be expected. See below.
Ok, then tried with another DB. This time with default
> DB. I thought this have to be bullet prooff ... Nah!
> Same error!
Ok.
Well, I tried with the same default DB, now with the
> modified line:
>
> $pos_config{till_accno} = 1200;
Please attach your complete, modified pos.conf.pl *and* your chart of
accounts. The error indicates a mismatch between the two. In fact, it is
best to include both of these *and* the HTML output of the main frame with
the POS sale screen in it. That way I have enough information to know what
is actually going on.
The POS framework is not designed at the moment to work out of the box-- it
requires some advanced configuration because there are many different
possible environments, and these work well for different sorts of
businesses.
And ... NOP!
>
> The same error!
So folks, I think you won't have any trouble
> replicating this error, it's out of the box.
Sure. See below.
I don't know if anyone has this in production with
> 1.2.7 version. Haven't tried another version.
>
> I want to emphasize that Sales Invoice works
> correctly.
>
> So what happens with POS->Sale?
Ok, the major difference with regard to accounts between the sales invoice
screen and the POS screen is that the POS screen automatically assumes that
the money is going into an account which represents the money drawer of the
register. Unlike the sales invoice screen where you select an account, the
account is selected for you here and this must be configured before it
works.
By default, till accounts follow the convention of 1300.x where x is the
identifier of the cash drawer. If the cash drawer. For a casher-based
till, x is the employee id. For a terminal-based till, x is the last octet
of the IP address. The terminal-based id conventions are likely to change
in the future as this does not seem to be a good global practice.
Hope this helps,
Chris Travers
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ledger-smb-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
