Jiwa

Hi guys,

I have a requirement to preset a default BAS code when an account number is selected for a journal set line item. To achieve this I need to add a custom field to the general ledger maintenance screen to record the default BAS code.

Following other samples was proceeding well, until I got a "CustomFieldValues is not a member" error ... when I checked the actual form, I discovered there is no custom fields tab. Can you advise the best approach to meet this requirement?

Cheers,
Neil.

General Ledger Maintenance does not have custom field support. I've logged enhancement #11694 to address this.

In the meantime, the way to achieve this would be to write a plugin that adds a control to the General Ledger Maintenance form that can display your custom BAS Code value. The plugin would also have to deal with displaying the value when a general ledger account is read, as well as reading and writing the value to a custom table you create - a table that links value to GL_Ledger.GLLedgerID.

If you cannot wait for enhancement #11694 and wanted to go down the plugin route, let me know and I'll endeavor to throw together a sample plugin. http://forums.jiwa.com.au/viewtopic.php?f=27&t=318 shows adding and populating controls on an existing form, but doesn't illustrate saving away data.

Hi Scott,

Yep, I think pursuing the plugin route is the go - adding the control to the form is probably more elegant for the client anyway. I will make a start based on the link you provided.

Cheers,
Neil

neil.interactit wrote:a requirement to preset a default BAS code when an account number is selected for a journal set line item.

You mean for when creating a local journal, yes? i.e. When a journal set is manually created and lines are manually added by a user.

Hi Scott,

Yes, the journal side of things (manipulating the line items) all looks straightforward ... it's the value to manipulate with that I need ... hence adding a field to general ledger "Default BAS Code". I have managed to add a combobox to the form (having some issues with positioning it) ... any guidance on best process for database interaction with the added field would be great!

Cheers,
Neil.

I'm writing a plugin now. I'm writing it in C# instead of VB as I need the practice. C# support for plugins was added in 7.0.116.0 (available for download at http://support.jiwa.com.au) - if your client has an earlier version (I suspect they do), you will have to convert my code to VB.

Can't make it too easy for you

WooHoo! I needed to dust off my VB.Net for these plugins ... bring on C#!

When will 116 (or 117) become the "current" version?

No idea. You could contact our support department and ask them when they plan to go through the test plan process I guess.

Right. I've attached a sample plugin. A sql script is included on the plugin as a "document" - save and run this sql script in SQL Management Studio to create the table used by the plugin.

The basic structure of the code is this:

1. Add some events when Setup is called.
2. When the general ledger maintenance form loads, setup and add our controls. Also set up some stuff in the business logic.
3. Every time a general ledger account is read, read our custom stuff from the database and update the display on the general ledger maintenance form.
4. Every time a general ledger account is saved, save our custom value to the database.
5. Every time a new general ledger account is created, reset our custom stuff to a default value and update the display on the general ledger maintenance form.

It's written in c#, and I've not done much c# work, so be gentle . I'd like to have put in some more defensive code, and re-factor it a bit more, but it would take me too long to figure out in c# at the moment. (ie. Why can't I do collection.contains() ??). I'd also consider changing the design completely such that it was split into 2 plugins - one that was business logic-centric and another that was form-centic. The current design does not cater for a 3rd party using the general ledger business logic without a form - they would not be able to see or use our custom "DefaultBASCode" field. I figure for our purposes here this is OK, however.

What is also noteworthy is the use of the generic object collection in the business logic object. I leveraged this so that I had access to what I needed no matter whether I was in a business logic event handler or a form event handler. Likewise, see the use of the business logic "client" property - this allows us to access the form when only the business logic is available.

Anyway, you should find it helpful, even if you end up converting it back to VB. Give me a yell if you have questions, or even some c# tips for me!