#1076 internal server error AP Transaction
When entering a new AP Transaction without filling in Invoice Created, I get an Internal Server Error referring me to the Apache error log, which states...
Wed Feb 19 16:19:36.135360 2014] [authz_core:error] [pid 13456:tid 2903427904] [client 192.168.15.112:58463] AH01630: client denied by server configuration: /var/lib/ledgersmb/css/ledgersmb.css, referer: http://192.168.15.3/ledgersmb/ap.pl
DBD::Pg::st execute failed: ERROR: invalid input syntax for type date: ""
LINE 17: crdate = '',
^ at LedgerSMB/AA.pm line 403.
DBD::Pg::st execute failed: ERROR: current transaction is aborted, commands ignored until end of transaction block at LedgerSMB.pm line 833.
2014/02/19 16:19:42 - ERROR - LedgerSMB::dberror LedgerSMB.pm (1099) -- Logging SQL State 25P02, error 7, string ERROR: current transaction is aborted, commands ignored until end of transaction block
Can't use string ("LedgerSMB::Setting") as a HASH ref while "strict refs" in use at LedgerSMB.pm line 941.
Compilation failed in require at /usr/share/ledgersmb/ap.pl line 7.
[Wed Feb 19 16:19:42.971443 2014] [cgid:error] [pid 13456:tid 2895035200] [client 192.168.15.112:58464] Premature end of script headers: ap.pl, referer: http://192.168.15.3/ledgersmb/ap.pl
Related
Discussion
Hi Mark,
Which LedgerSMB version do you use? (That is, 1.3, obviously, but which patch version? 1.3.XX?)
Bye,
Erik.
1.3.37
On Wed, Feb 19, 2014 at 8:44 AM, Erik Huelsmann ehuelsmann@users.sf.netwrote:
Related
Bugs:
#1076I confirmed this issue.
Technically if the invoice does not contain when it created, it should be the transdate automatically.
I try to figure out, where to setup the default in AP/AR transaction (not sales invoice, that already has default value):
$form->{crdate} = $form->{transdate} if (!$form->{crdate});
Check the revision [r6878].
I committed a fix for this kind of issue:
on post we just fill empty crdate value with transdate, same as in duedate case.
Please test it, I think it will solve AP/AR transaction issues: it will always get value.
Related
Commit: <Commit _id='5164860434309d2e82ce4139:6878' tree_id='3c28ea3495b60e6c63b77411bb7a8c8f86b1e3aa' committed=I{'date': datetime.datetime(2014, 2, 19, 20, 1, 20, 330000), 'email': '', 'name': 'pongracz'} authored=I{'date': datetime.datetime(2014, 2, 19, 20, 1, 20, 330000), 'email': '', 'name': 'pongracz'} message='Fix for bug #1076 : We fill the empty crdate field with transdate on post, silently, no error, no warning. We do the same as in missing duedate field. This only dangerious where invoice creation date exists and important to compare the issue date with transdate. They will need patch the code to use warning instead of silent date filling. Anyway, this also true for duedate.' parent_ids=I['5164860434309d2e82ce4139:6877'] child_ids=I['5164860434309d2e82ce4139:6879'] repo_ids=I[ObjectId('5164860434309d2e82ce4139')]>
Last edit: Pongracz Istvan 2014-02-19
Also committed to 1.4 [r6879]
Related
Commit: <Commit _id='5164860434309d2e82ce4139:6879' tree_id='509bed964ff9fee85a759d815c958214de02da13' committed=I{'date': datetime.datetime(2014, 2, 19, 20, 8, 12, 859000), 'email': '', 'name': 'pongracz'} authored=I{'date': datetime.datetime(2014, 2, 19, 20, 8, 12, 859000), 'email': '', 'name': 'pongracz'} message='Fix for bug #1076 : We fill the empty crdate field with transdate on post, silently, no error, no warning. We do the same as in missing duedate field. This only dangerious where invoice creation date exists and important to compare the issue date with transdate. They will need patch the code to use warning instead of silent date filling. Anyway, this also true for duedate.' parent_ids=I['5164860434309d2e82ce4139:6878'] child_ids=I['5164860434309d2e82ce4139:6880'] repo_ids=I[ObjectId('5164860434309d2e82ce4139')]>
I close this issue, as I checked it is working in AR/AP transaction as expected:
users can ignore this field, it will be populated with transdate.
confirmed in 1.3 branch, thanks
Hi,
First of all, I am very happy to see this fix--it's certainly a usability issue leaving unfixed.
However, I wonder if it's fixed correctly. I mean, I would think we would want the default date to be today, not the transaction date. That way it would reflect when the invoice was actually created, not the transaction date somebody entered.
It's not a date I currently use or care about -- but I could see it helping track down statement balances, if we got into a dispute with a customer about a back-dated bill -- it would show when the invoice was actually added to the system, whereas the transaction date would be the effective date.
Hi John,
Thanks for your comment!
Some things about the situation:
A company is able to issue (sales) invoice in the following ways:
When we use sales invoice from ledgersmb (product or services), we already force the invoice created day to the current day, the user cannot modify it and saved on post.
Any other case, when the user enter other invoices from other systems, the invoice created date cannot be forced to today, because the field value is unknown and independent of ledgersmb. For example the operator only enters all incoming (or outgoing from other systems or book) invoices once a month: it is his responsibility to enter the correct days or ignore it.
I found some invoice from Germany for example, where only the Transdate exists on the invoice, there is no other date on the invoice. In this case we use this date for invoice created and due date, too.
In Hungary there are some rules, how to fill an invoice if one pays in cash or wire transfer, continuous delivery like cellphone or electricity costs or a one-time project.
If we want to force all rules into ledgersmb, it will break other's workflow, just like this one additional field.
In this case, the user has to know the basic, how to issue a correct invoice. Anyway, I think it is the user's responsibility to know the basic of the business.
The Plan B could be that the user (sysadmin/app admin) makes changes to the original code to meet his/her requirements.