2,051

(10 replies, posted in Setup)

Normally it is.  I don't know why in your case it is not, maybe you have some buggy configuration on your server.
Janusz

2,052

(6 replies, posted in Accounts Receivable)

Yes, FA was (following webERP) designed firstly for B2B market, so db structure is not optimized for retail sales. Nevertheless both approaches are correct, so it is up to you which way to choose. If new customers will be imported from osC automatically and we want to support also invoices for companies, seems the better way is to create both customer and branch record.

Janusz

2,053

(6 replies, posted in Accounts Receivable)

tom wrote:

I just did some more testing and I see that if I change the address in the branch it does not effect the Sales Order.

So what effect will modifying the Branch have on any current or past sales orders (or invoices or...)?

Modifying adresses in customer/branch sales order delivery address unless you reedit SO.

In fact algorithm of selection of delivery address on new SO is quite logical:
- select branch mailing address if not empty
else
- select branch billing adress if not empty
else
- select company address
That's all.

tom wrote:

I saw the "Retail Customers" in the demo an have considered putting all the web orders under a single FA customer and using the branches for each individual osC customer address.

And if the customer changed their address, I was going to update their FA Customer Branch accordingly.

I am just looking for any bad things that could happen by doing things this way...

All should work right. The only problem can be changed branch address between  sales order is received and moment of delivery. In this case all not delivered sales orders should be updated.

I can not think of a good reason to not create a FA user for each osC user
(except maybe lazyness LOL)

At that point I might as well create Branches on the fly as Ship To addresses
change... which it typically rare with my customer base

I guess you mean customers not users? You can use 'Retail' customer with many branches, or you can create unique customer record for every your client. The first option cannot be used for multiply companies because GST number is stored  in customer, not in branch record. For retail customers GST number is obsolete.

janusz

2,054

(10 replies, posted in Setup)

Time printed on reports is current server local time as returned by php date() function .
see php documentation and function Now() on file date_functions.inc.
Janusz

2,055

(40 replies, posted in Report Bugs here)

Customers currency is stored in  debtors_master.curr_code.
Janusz

2,056

(40 replies, posted in Report Bugs here)

You probably have broken database. The message can be displayed only when customer selected has not home currency set.

With some effort I've created the database with only fictional home currency defined. No exrate check during SO/SI entry and no errors.

Janusz

2,057

(4 replies, posted in Wish List)

First we are planning to improve PO functionality, so this could be a part of this changes. I will move the thread to wish list forum, to not overlook it later.
Janusz

2,058

(4 replies, posted in Manufactoring)

Sales kit is simply predefined set of items which does not exist phisically in inventory. You can select sales kit as any other item during sales entry, but after selection the kit is exploded to items. E.g. you can define sales kit 'Engine oil replacement' containing 5l of synthetic oil, 1 oil filter and 1pcs of (dummy item te service) 'Oil replacement'. After selection you will end with the three positions on invoice.
Janusz

2,059

(6 replies, posted in Accounts Receivable)

Sales order is not fiscal document, so there is not a problem to change customer parameters after SO entry. No tax is calculated during sales order.

In contrary Sales Invoice/Delivery has all crucial data like taxes, delivery address etc stored in tables, so changing customer data does not change already entered docs, as far as you do not reedit old documents.
Janusz

2,060

(6 replies, posted in FA Modifications)

Good idea.

2,061

(4 replies, posted in FA Modifications)

In our data model company have only one tax number, and one official address for billing as well. This data is printed on invoice regardless of exact delivery source, because the inventories are not separated businesses.

Janusz

No. Again cash accounts are derived from current user POS. So if you have also 3 users with 3 different POS, then yes, you should have postings to 3 GL accounts. If you operate from the same user account all is posted to related POS's account.
Janusz

You have 'Cash account' displayed so I understand you have cash sales selected.
In this case the two parameters are get from POS definition, not the customer/branch.
Janusz

2,064

(7 replies, posted in Wish List)

Interesting. English is anyway most used language in international transactions, so we should support at least two options: english and native descriptions. We should consider the idea of additional selector in customer setup.
Janusz

2,065

(1 replies, posted in Wish List)

We have done better use with item categories in 2.2 version code. In next release most item parameters are defaulted from category selected. See our unstable demo at http://fa2.iron.from.pl
Janusz

2,066

(4 replies, posted in Accounts Receivable)

Ok, I think we can extend the field in next release. So, what length would be enough for german market?
Janusz

2,067

(2 replies, posted in Translations)

It depends where exactly the problem arise. I guess the two meanings are in Sales and Purchasing modules and never appear together. In this case separated message file can be created and used in Purchase module.

Another approach is used by Freeciv .org community (see http://freeciv.wikia.com/wiki/Internationalization). Their way forces using translation files also for english language.

Yet another approach is desribed in gettext documentation:
http://www.gnu.org/software/gettext/man … mbiguities

So far nobody reported ambiguity problems in other languages (although I could find some in polish translation wink), so if the problem is only in a couple of places maybe the easiest turnaround would be to distinct conflicting strings with e.g. different number of spaces added?

Janusz

2,068

(4 replies, posted in Accounts Receivable)

Yes, you should also change the last value in line 243 of customers.php from 40 to 100. NB the current value is inconsistent with database field length which is 60.
Janusz

2,069

(5 replies, posted in Setup)

Hello,
Good idea. I was looking some time ago after the payroll software which can be easily integrated into FA. To not reinvent the wheel I suggest you to get look into Payroll project on Sourceforge. This is LAMP based software with very FA alike user interface philosophy, and it is compact. Of course it needs rewriting the code to make it consistent with the rest of FA source, but at least you have ready to use database tables structure.
If you want to contribute the final payroll code to FA project, I can help you with advisory regarding FA framework. Contact me on: janusz at iron dot from dot pl.

Janusz

2,070

(12 replies, posted in Setup)

There is no detailed instruction how to write modules. The best way is to download some modules from our download section and learn by example.
Janusz

2,071

(1 replies, posted in Translations)

Hello,
Yes, the last messages file was generated without the external strings. Non-standard themes are not included in CVS source, so they have not appeared in translation file.
I think it will be fixed somehow in CVS soon.
Janusz

Currently there is not much use from purchasing data, however we plan to improve this in next release. As far as it is implemented in accordance with FA programming philosophy used in the rest of the code, there should be no problem here. We try to have any natural default setting wherever we can use some optional data in FA. In this case when no purchasing data is defined for given supplier, inventory item description/uom should be retrieved for PO. Thisi is how I see this.
Janusz

2,073

(6 replies, posted in Report Bugs here)

I'm still not sure what do you want to achieve.  IIf you need paged customer table you don't have to reinvent the wheel. We have table pager implemented in db_pager.inc file.

No, leaving the option does not change customer list selector into a table of course. But in fact there is not too much place on the page and customer record contains quite a lot of data, so using list selector instead of a table (even paged) is optimal solution. We try to implement user interface in such a way that scrolling page up and down is not needed.

Layout import from xls file seems to be interesting option, especially for those who have  already reports generated by another accounting  third party software.

Janusz

2,074

(6 replies, posted in Report Bugs here)

yeshuawatso wrote:

You're right but could one not close the parameter out  and run a sub-query  Either way it's still a potential danger.

I can't provide proof of concept code for mysql, but definitely this was security hole.

While I'm on a roll ( and being lazy), I'm trying to remove some of the columns in the invoice header2 (cust  ref, our ref, etc) but for the life of me, I can't seem to find where the columns are being set. I can see where the lines and fills are being drawn, but the vertical separations seem to be perplexing me.

Vertical lines are set in lines 47-50 of header2.inc.

Also, I'd like save the generated invoices in a blob table with the customers id in a batch function, but the generation only seems to occur on demand primarily (excluding the cache). Any pointers would be appreciated.

Yes, all reports including documents like invoices are generated on demand from db data. But in any case the resulting pdf is stored in temporary file in company/0/*.pdf. See line 385 or 410 of pdf_report.inc You can catch the pdf code here.

BTW, I couldn't wait to figure out how to generate the tables created by the UI classes (actually, I think their just functions that could easily be combined into a single class) so I made a dirty table and some while loops to generate list data into normal tables. My reasoning comes from the Ajax and the constant guessing (or maybe choosing the first one) of the list (products, customers, etc) and having to continually run wildcard searches. I would like if someone would to look at the file and convert it to more compatible (similar) code setup that the project already has in use. This would help me implement the code in other areas where searching may not be the fastest option (e.g. small number of records.)

If you simply want to have all customers available in list selector without searching - set 'Search Customer List' option in company preferences to off. This is good for small databases, but for the company data containing hundreds or thousands of customers you'll better leave this option on. The same list selector behaviour and related  company preference option you have for suppliers and items.

Janusz

2,075

(3 replies, posted in Setup)

You can add following line in login.php and header.php:

echo "<link rel=\"icon\" type=\"image/png\" href=\"path_to_icon\icon.png\">";

Janusz