Additional Fields Extension (Page 2 of 3)

Looks like you may have pdf debugging on...

Open your config.php file around line 37 you will see:-

File:\config.php
37:     $pdf_debug         = 0;    // display pdf source instead reports for debugging when $go_debug!=0

If it is set to one change it back to zero

After trying to completely over complicate it I found that:-

$popup_editors = $add_field_popup_editors;

Replaces the contents of the arrray $popup_editors with the contents of my new array with changed url's

I added this my new array to the top of sales_order_entry.php and it worked!

Now I have the problem of where (and how) to put it to the ext.

@notrinos, as I understand so far

ajax 'var editors' array is set on each page, so either:-

$popup_editors needs to be set before the ajax function callEditor by calling the function in post 30 above, this it seems would have to be by ajax?

or

an ajax function to change the var editors array

But FA seems to have made provision for this by including the editor_redirect function which is otherwise redundant

I would appreciate any help you can give on this please

Due to the number of conflicts created with the integrated version I have revised the ext so that it is non-integrated.
It was not as user friendly - now CSI additional info entry is now a two-step operation (eg Enter new customer data in FA core as std, then go to customer additional info (You can see FA core CSI details, but you cannot edit them... see screenshots below)) but the ext now has no conflicts with FA core. No changes to database.

Demo is here
Username: demouser
Password: 12345678

Code is here

New screenshots here:-

https://imgur.com/a/OV0R4nQ
https://imgur.com/a/PATDJRz
https://imgur.com/a/3DsSyev
https://imgur.com/a/UOtXCkI

If you have already installed additional fields then you are advised to change to this latest version as FA will not fully work with the old version. To do this:-

Method one:-
1. Make a backup of your database (Just in case)
2. Delete all files in /modules/additional_fields/
3. Down load the new version and unpack the contents to /modules/additional_fields/
4. Check access permissions change if necessary then log out and log in

Or

Method two:-
1. Make a backup of your database
2. Deactivate and delete the additional_fields ext
3. Down load the new version and unpack the contents to /modules/additional_fields/
4. Install and activate the additional_fields ext.
5. Restore the backup you created in step one
6. Check access permissions change if necessary then log out and log in

Please note: There are a number of file deletions, therefore a differences pack will not work

@kvvaradha @joe My apoligies for my late reply; I mis-read kvvaradha's post (or it was changed?) and was mulling over a response

Can you please clarify if: You want me to modify core files to incorporate custom fields as it was into the core for release FA2.5 (I think this is what you mean)

So a few thoughts:-

1. Use existing FA db tables where possible or db structure as is in additional fields ext.(which makes upgrading easier?)
2. Address options

1. Keep the existing address field as FA core and have additional address fields as extra info?

2. Use the existing FA core address field as the first 1/2/3/4 lines of the address then add extra fields for city, department, etc? This is quite a large change; customers, customer branches, suppliers, locations, company setup etc and all relevant reports

3. Separate fields for all lines of address? ie Address Line 1, Address Line 2 - 4 and then city, department, etc

4. Or another way not listed here?

3. Use dropdown lists for city, etc or empty box? Or a combo box that allow select from list or manual entry) Also I think its possible to use a flat file for a list of cities etc and then only store the value in the db. Users can then add their own 'locale'

4. Option in company setup to turn on/off custom fields?
5. Create a detail query for each CSI (I'm fairly sure I need help with this)

The following is all you will need:

CREATE TABLE `0_addlflds` (
  `FldName` varchar(30) NOT NULL,
  `TblName` enum('Customers','Suppliers','Items') NOT NULL,
  `FldType` enum('Text','Number','Date','DateTime','TimeStamp','Bool') NOT NULL,
  `FldSize` varchar(255) NOT NULL,
  `FldUIType` enum('EditBox','SelectBox','TextArea','Password','CheckBox','Radio','MultiSelect') NOT NULL,
  `FldUIChoices` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`FldName`)
) ENGINE=InnoDB;

CREATE TABLE `0_addlfld_values` (
  `TblPKid` int(10) unsigned NOT NULL,
  `FldName` varchar(30) NOT NULL,
  `FldVal` varchar(255) NOT NULL,
  PRIMARY KEY (`TblPKid`,`FldName`)
) ENGINE=InnoDB;

The id field of the 0_item_codes table is the Primary Key that can be used instead of the stock_id or the item_code field for linking into the additional fields extension's tables.

Can please explain how i can use this code ? I'm not into programming

@kvvaradha - It has been made clear by Joe/Janus that there will be no more DB changes in 2.4, i.e, Any modifications requiring DB changes will not be considered for V2.4 only for 2.5 and if they consider the modifications are right for FA.

Its relatively easy to add extra fields to the core, not so easy to include them in FA functionality, but including them now brings all the disadvantages of modifying core files - upgrades, management, etc.

Given the above a module seemed to be the only viable solution. The module I wrote is quite 'bulky' as I tried to incorporate as many additional fields as I thought users would want. (Each user/business would want there own fields) The original 'integrated' version did not work, which leads to the current version using extra pages: The remains bearing not much resemblance to the initial idea :-(

So my thoughts on your mod are - I'd think I'd leave just the custom fields from my module in, 4 for each of customers, Items and suppliers, that way users can label the fields to what they want. You can use any code from the module.

@kvvaradha - OK, Bit busy at the moment, but I'll have a think and post something.

Also, it seems 'Bin Number' is a definite inclusion in Items.

We have to add two tables for custom fields. One for the field definition and another one to store data of custom fields.

Actually I am thinking to extend this to sales invoice  and purchase invoice.

@poncho1234 - we have to focus on next major release. I can understand.  Let's try to contribute something to next release.

@Joe  users are eagerly waiting for the next major update. So let's focus on it.

Yes. But for more  customization get only one value from that minified string. We have to decode all the custom fields. May be a choice to do that.suppose if we have to bring hsn code for items. And we have to take tax reports based on hsn code. It might be complex to get and process the results.