On 8/1/07, Eduardo Huertas <..hidden..> 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