a. A single common field could be created and applied to either one or as many of the entry forms in that category. This would save having to set up the same custom field for each form.
b. Selection of custom fields in Custom Reports would be made easier and would only need one column for a common custom field which would report across all transaction types.
c. I believe that this set up would facilitate the reporting of line item custom fields in Custom Reports.
d. It could also open up the ability to have Custom Fields for other items such as employees and Chart of Accounts
I think that your reasons for not supporting these changes are either not an issue or can be overcome.
Say that you have a Custom field of “Region” (or Area) which you want to apply at a transaction level. So when you create this Custom Field there will be a list of forms to which this Custom Field could be selected to apply and against each form there could be tick box/options for position, display as column and print on form. This would overcome the first 2 issues you mention.
In regards to issues 3 and 4, if it is a common Custom Field (like “Region”) in 99% of cases you would not want a different description or a different type for each form. If you did, you could create another custom field (with similar but different title) and apply it to the form that required a difference.
your explanation still does not make it clear how this is easier, less time consuming and better organized than the current method of creating custom fields.
this is exactly the problem. majority of the custom fields are unique if you check the custom field requirements for each type of transaction. so adopting a technique which would help with the minority requirement is not a clever idea.
OK @sharpdrivetek I will try to explain it to you in step by step detail.
Aim: Create custom report that can list (and group, and sort) general ledger transactions by custom field titled “Region”. The criteria for this field might have only 2 regions (International, domestic) or it may have many regions within a country. It needs to be done at a transaction level as many of your suppliers/customers are multinationals. The transactions would include Cash Receipts (as distinct from AR receipts), Cash Payments (as distinct from AP Payments), Customer invoices, Customer Credit Notes, Supplier Invoices, Supplier Debit Notes and Journal Entries. Currently custom fields cannot be created for Receipts and Payments and this is not likely to change until the Manager System distinguishes between direct cash payments/receipts and AP/AR payments/receipts, but that’s another issue. So we will assume that all Supplier/Customer transactions are routed through AP/AR.
What is require without changes:
Step 1. Create 5 identical Custom Fields of “Region” for the 5 different transaction forms, Customer Invoice, Customer Credit Note, Supplier Invoice, Supplier Credit Note and Journal Entry.
Step 2. When creating the Custom Report it will require 5 separate columns to capture the Region custom field for each transaction. These 5 fields will make it impossible to group and sort by Region.
Requirements after changes:
Step 1. Create a single “Transaction” Custom Field of “Region” and mark it to be used by the 5 transaction forms.
Step 2. When creating Custom Report only 1 column for Region will be required and effective Grouping and sorting will be possible.
There is no problem as there would be no more work to create a unique custom field than there is to create a custom field at present.
is your topic about custom fields or custom reports?
such transactions will not reflect on your customer/supplier statement anyway. so these transactions are not related to your customers or suppliers entered in their respective tabs in Manager.
you only need to create a custom field for the customer or supplier tab which will show on all these transactions. you do not have to create separate custom fields for each transaction form.
what version of Manager are you using? the latest version of Manager enables you to create custom fields for Receipts & Payments tab.
like informed above, you only need to create one custom field for Supplier or Customer tab.
I feel that I have written something to offend you @sharpdrivetek because this comment is just being argumentative.
This topic is definitely not about customer/supplier statements.
The entities that you trade with are your customers/suppliers regardless of whether it is on a cash or credit basis.
A supplier/customer may operate from many locations in different regions so this is why it is needed at transaction level.
My mistake @sharpdrivetek I was working in a test database that did not have the receipts and payments tab activated. That increases the number of Region custom fields needed to be created to 7 and also the number of columns to capture these to 7.
not at all. i was just clarifying things because you mentioned about creating custom reports.
true. all i was trying to explain is that, in the perspective of Manager accounting software, a cash sale or purchase entered in the Receipts & Payments tab do not reflect in AR or AP ledger of your existing customer or supplier.
true. so irrespective of your suggestion you still have to enter the region in every transaction form when making an entry in Manager unless you are using the Copy To function.
your suggestion is about creating a custom field which is a onetime process in Manager for most business. creating a custom field is not something a user does every day. please understand that i am not against your suggestions for improvement. i was just trying to explain that it is an unnecessary trouble for the developer to redesign something which would only look different but practically provides the same function as it already does.
Correct. The suggestion does not require this part to change
Yes there is only a one time set up for a custom field, however the changes will reduce the number of Custom Fields required to be set up, but this is not the main benefit of the changes.
The benefits that I envisage the changes will facilitate are:
It will simplify selection of custom fields in Custom Reports.
It will facilitate better sorting and grouping on a Custom Field in Custom Reports over a wider number of transactions.
It could open up the possibility of using line item custom fields in Custom Reports.
It could also open up the ability to have Custom Fields for other items such as Chart of Accounts which may then facilitate selecting custom fields in standard reports.
Please understand that this suggestion was not made for the purpose of making something “look different”, but for improved functionality. I have tried to explain the improvement in functionality for you @sharpdrivetek and at this point cannot think of any way to explain it more clearly.
I’m mature enough to know that the developer may not be enthusiastic about an idea and will not be willing to use it. However, we will never know if the idea is not expressed on this forum.
I’m not sure how the changes suggested would make it better and there is a risk they would make it worse.
Currently custom fields can be made of various data types
Currently if identical custom field names and data type is used, the custom field contents can be passed between screens in Manager.
Custom fields are only created once per business
Currently whole business setups can be transfered between Manager business via “Localisations” or empty business shells used as templates (restored and renamed multiple times)
I have trouble seeing how having a customization data hierarchy would save significant user time. The complexity for infrequent user customization may instead decrease user customization efficiently. @generalegend sorry to be negative
If I understood you correctly @generalegend, I think what you propose is more or less equivalent to this scenario:
You have a dropdown list of say: {apples;oranges;pears}
This list appears in multiple types of transactions and/or tabs.
You want to have: 1. Centralized control over the list so you enter it once somewhere and later when you create the custom field you just point out to the list; and 2. In custom reports, you want the list to appear so you can filter once instead of going to each table and filter out by custom field.
If this is what you want, then I am fully behind you on this, however, I think “Custom Validation/Master Lists for Drop-Down Custom Fields” would be a more appropriate title – if that was what you meant.
There will be some time saving in setting up custom fields but this is not the main benefit. As expressed earlier there will be a substantial benefit for reporting especially custom reports.
Let me demonstrate with a scenario:
I have a retail business that sells goods to both domestic an international customers. I have online sales that are processed using cash receipts, and I also have some local sales on 30 days credit which are processed using customer invoices. I want to analyse these sales by both Region and Salesperson. I also want to capture both credit and cash refunds in the analyses.
I set up the 2 custom fields (Region and Salesperson) for Customer invoices
I set up 2 custom fields for Receipts and Payments
I set up 2 custom fields for Customer Credit Notes
Bear in mind that these are all separate variables - 6 of them
I create a custom report and the output looks like this:
The output in the blue encircled area is captured by selecting columns for the Customer invoice Region and Salesperson custom fields.
There is no output for Cash Receipts and Customer Credit notes (yellow encircled area) for 2 reasons:
The custom fields for Receipt & Payment, and Customer Credit notes are not available for selection in custom reports.
If these custom fields were available 4 more columns would be needed to capture this output. (Region and Salesperson for Receipts & Payments and also Region and Salesperson for Customer credit notes)
Grouping and sorting by either Region or Salesperson would not be effective with all these columns for essentially the one variable each for Region or Salesperson.
With the changes that I have suggested only 1 column would be required for Region and 1 for Salesperson and the grouping and sorting problem would be solved.
