It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by roger
Pages 1
The main issue in such cases is to avoid duplicate IDs such as order numbers, invoice, etc. between the offline DB and the online DB.
Both start from the same starting point after a synchronization, but the moment a transaction is entered both will start with the next available number. Now both DBs have a new transaction with the same transaction ID, unless you operate with a different transaction number offset in the two databases.
Plain DB synchronization is unlikely to solve the issue.
Hi Janusz,
With locale you mean the PO and MO files?
As I said I used the same set on a different server and it worked just fine.
Roger
I have installed Frontaccounting 2.1 on a Linux server.
I installed Spanish language through the setup menu option.
I changed to default, changed my preferences, loged out closed browser and still all text would show in Englich only. The same PO and MO files worked perfectly on a windows server.
I assume there may be a PHP parameter I need to check on my server?
I'd appreciate any hints on where to look for solving the problem!
Great, I am really looking forward to it
Thanks
Hi Joe,
where is release 2.1 available? I can fin 2.06 only
Roger
Hi Joe,
The other thing I noticed was that while the debit is reflected correctly on the GL account, the bank account does not show the transaction! Any thoughts on solving that?
Thanks
Roger
Thanks
Hi Joe,
This would be even better. In this case I would also have to be able to specify thepayment details as the payment may be in cash or cheque or card. Except in cash I would need to collect the refrence number and be able toi chage the GL account. So basically I would have to bring most of the Customer Payment logic in too.
My approach would in addition allow for mixed payments, meaning part with a cheque and res with cash for example, assuming you keep the context of the invoice after the first paymenmt and can chose to enter an other Customer Payment. Once you get to the Payment screen the amount due would be prefilled (now less).
Also I think the way I propose would require very few changes to the curren code and on the other hande keep the Payment logic intact in one single place. This way we do not risk to have to maintain two identical pieces of code.
One last thing I forgot in my request: After the payment is processed we would need a link to print the Invoice.
Roger
While we wait for the day we have a propper POS as requested elswhere, I think many of us who need to be able to do over the counter sales would benefit from a simple direct payment facility as follows:
1) On the screen after a invoice has been entered there should be a new link leading to the payment page. The invoice context should be carried over.
2) In the payment page the client details and amount would be prefilled based on the invoiced
3) When submitting the payment the allocation of the payment to the invopice will happen in the background automatically.
This will allow for a quick sales proces by using direct invoiceing followed by the payment screen for payment and allocation in one step. I guess this would not require mayor changes other than detecting the contect information of a invoice being present when starting the customer payment page with a couple conditional forks.
Has there been any progress in this?
An alternate option I could think of is to move the currency definition from the client level to the branch level which would allow for billing in different currencies to the same client, yet keeping records separated?
Is the solution I used correct or does it cause any risks/issues?
How do I add lien wrapping when printing a long field?
In particular I would like to show the Item description in its full length on Sales orders, invoices, purchase orders, etc., even if the description exceeds the single line space provided.
Ideally I would eve like to have the option to print these documents with the long descritpion.
Any help (or even better updated reports) would be much appreciated.
Hi Joe,
I check the module and found an error:
On line 38 you use db_escape() function to clean the $description field. This results in the addition of single quotes arround the quotes in $description.
Later in line 67 and 85 when building the SQL statements for update and insert there is yet an other sigle quote arround %description resulting in a SQL error.
Removing these quotes seams to solve the problem.
Regards
Roger
I copied the lates version to my webserver and unpacked it.
When accessing the site for the first time I expected to be run through the setup process as usually. Instead I end up on the Logon screen with the below warnings:
Warning: session_save_path() [function.session-save-path]: open_basedir restriction in effect. File() is not within the allowed path(s): (/home/ingusol/:/usr/lib/php:/usr/local/lib/php:/tmp) in /home/ingusol/public_html/prueba/frontaccounting/includes/session.inc on line 44
Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /home/ingusol/public_html/prueba/frontaccounting/includes/session.inc:44) in /home/ingusol/public_html/prueba/frontaccounting/includes/lang/language.php on line 80
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/ingusol/public_html/prueba/frontaccounting/includes/session.inc:44) in /home/ingusol/public_html/prueba/frontaccounting/includes/lang/language.php on line 80
Warning: Cannot modify header information - headers already sent by (output started at /home/ingusol/public_html/prueba/frontaccounting/includes/session.inc:44) in /home/ingusol/public_html/prueba/frontaccounting/includes/lang/language.php on line 82
Any ideas what may be wrong with this site's configuration?
Thanks
It would be adding a lot of flexibility to add an editable memo field on the item level in all sales and purchase orders, deliveries, invoices, etc.
This would allow to document specific agreements and further specifications on the item level, e.g. to have a specific logo inprint, or specific packaging type, etc.
I think the dimensions are a very good functionality. I do feel though that to make them really universally usefull there are a few areas which need to be added:
1. Inventory Locations should have the possibility to assigna a dimension to. This would allow to setup different branches of a company and track each branch's sales, procurement and costs with its respective dimension filter.
2. On Sales and Procurement transactions It should be possible to change the dimension for this transaction. This is especially necesary if you use dimensions to track projects and you for instance bill multiple projects to the same client.
I tried to use the new logo upload functionality in the company setup. Allthough I could select a file on my local HD clicking the Browse button. It would not get iploaded to the server when I press the Update button.
There may be a bug here?
Thanks
Roger
I have updated the Spanish translation (Argentine version) for R 2.0 and would like to share it. Please tell me how to send you the files
Pages 1
FrontAccounting forum → Posts by roger
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.