In the latest version (23.10.18), there is an update for custom field functionality. Previously, the program allowed users to copy the content of custom fields when utilizing the Copy to feature between different document types. For instance, if you had the same custom field in both Sales Quote and Sales Invoice, the content from custom field on Sales Quote would be directly copied over to custom field on the Sales Invoice.
There is now more advanced autofill mechanism, enhancing the overall user experience. This mechanism works directly within the form itself.
For example, assume there’s a custom field named “SKU” present in both “Inventory Item” and “Sales Invoice - Line”.
First, you would set SKU on Inventory Item level.
Now, when you’re creating or editing a sales invoice line and select an inventory item, the content of the “SKU” custom field from the “Inventory Item” will be automatically populated into the custom field on the “Sales Invoice - Line” you’re currently working on.
before you made this feature it was working perfectly for me, speacially when making purchase order I get the SKU number to easilly purchase the item with suppliers
but now I type the SKu manually handly on the paper after printing the PO because it does not show on the PO as before
Not sure what the problem is. I assume you would use Item Code for the Inventory item to complete the SKU (is not Manager terminology!). When creating a Purchase order you can start typing this number in the item field and it will show. Also in the view screen it will show as the first part of the item name (see screenshot of a test business purchase order using Manager v23.11.9.1130 where SKU101 is prepended to the item name under Item column).
My problem is when I create a new purchase order, the SKU column does not appear, nor does the “Page Yeild” column, which previously appeared in the purchase order and sales invoices (see the attached image as an example of what was previously).
First of all, great improvement @lubos (as always!)
However, I’ ve noticed some issues (very reasonable at the level of the first implementation).
For example, let’s say that we have the Custom Field “XXX” (text custom fields - not the obsolete ones) for “Supplier” and “Payment”.
When we create a “New Payment” from Payments tab and select the Supplier (as payee), then the price of the respective Custom Field “XXX” is shown (all is ok so far). However, if we made a mistake (e.g. selecting another Supplier than the correct one) and we would change that, then the Custom Field “XXX” does not change (remains the same as before without any update). In this case, I noticed that we should 1st) clear the content of the Custom Field “XXX” and 2nd) select the “Supplier” to have the update of custom field’s content.
The same issue occurs when we select to create a “New Payment” from Purchase Invoices tab - view screen options. The supplier is as the purchase invoice, but the Custom Field “XXX” does not have any content; we need to clear the Supplier’s content and then select the same again to have an update in the Custom Field “XXX”.
The same problem when we edit “Payments”; we need to clear the content of the Custom Field “XXX” before we change the Supplier in order to have an updated result (in the custom field).
Maybe I am missing something here, otherwise these issued may be addressed.
What you are missing is that this is how the program has always worked. Editing a transaction is different from creating one. When editing, as much of the previous content as might make sense is preserved.
Users often clone or copy transactions to save work or promote consistency for various reasons. Once you’ve entered something, the program has no way to know which other fields you might want to change just because you have changed one. You might, for example, want to change a supplier’s name while leaving all other content from the earlier choice the same. The identical thing happens when you change an inventory item after first selecting another. You might be doing that to offer a customer an upgrade at the same price as a lower quality product. The behavior is the same whether creating or updating transactions.
You might be irritated by this behavior. I can assure you many others would be irritated by your suggestion. A user might have invested considerable effort creating the content your suggestion would wipe out. The developer long ago decided not to surprise users by replacing content they had not changed. The delete-and-reselect feature is a quick and easy solution.
If that was the intended action/outcome, it’s ok; I understand the philosophy of the programme and I really support that.
My thoughts just derived from the following:
especially, as the example I gave before:
Please note that I do not have any significant problem with that; I just mentioned these cases a) in the event the developer has not noticed the respective results and b) in order to make my own arrangements based on how this new feature works.
I think @evans is making a valid point here. The new autofill feature introduced here generally works by selecting some predefined option from dropdown(recepient, item name etc), which then autofill values in respective custom input fields. These values are data associated or specially setup for that chosen dropdown option.
Suppose TPIN is defined for 1 customer, and then that customer is selected in the begining while creating an invoice, and in the middle of creating that invoice, if the customer is changed, TPIN custom field value still has the OLD(previous customer TPIN), which in my opinion most ppl would forget to change, & how is the user suppose to remember correct TPIN for any customer, which they would need to update the initial autofilled value. This limitation infact reduces the scope of this feature which otherwise is so great for automating work & saving lots of time and effort.
Same happens with line item custom field also.
I think autofill value, attributes etc of one item is mostly unique for that item, but chosing another item does not update autofilled value, attributes of previous item. so if user first chooses one item, which autofills its attributes in custom field, & the if user changes the item , the custom fields still has old attributes, which will appear against new item in view screen also, which would be a mistake or not correct in most cases.
I think overwriting with autofill values of newly chosen option should be available when changing old options (that had previously already autofilled their particular autofill value in custom fields).
I just tried this autofill (23.11.24.1164), autofill doesn’t fill in again if the custom field is already filled in, even though we change the master we choose.
If we leave the customfield on the invoice empty, autofill works, but often takes the customfield value from another master.
In my opinion, custom fields that come from the Master, should work like Units in Inventory Items. Autofilled and cannot be changed via Invoice and can only be changed via Master.
It looks like the system must separate custom fields used for the Master and custom fields used in Transaction documents.
Custom fields on the master will automatically be included in the transaction document when the master is used or selected.
