Old behavior - Invoices created with Batch create respected Form default for Sales invoice. I used to get Line Descriptions I imported showing in the edit form for the invoice (Line descriptions is checked on my form default for sales orders). New behavior - Line descriptions checkbox remains unchecked for imported invoices and does not match form defaults. The line descriptions I imported are actually there they just don’t show up by default because the form default is not respected.
Old Behavior - When I batch create a sales invoice line with a non-inventory item the sales account from the non-inventory item would default onto the invoice line based on the item imported by batch create. New Behavior - although the non-inventory item imports correctly and appears on the line, the sales account is no longer defaulting from the non-inventory item.
I believe these to be bugs. The whole point of bringing in the items during batch create is to create the default accounts on the transactions, I do not want to have to manage the chart of account UUID’s in the source system.
If I understand correctly what you are doing, it sounds like you are performing a Batch Create without all necessary information. The Batch Create should govern. So if Line description is not set in Batch Create, it won’t appear on the resulting sales invoices.
Likewise, if no sales account is set for your non-inventory items, none will appear.
I do not have experience doing exactly what you describe, but I am surprised by your claim that options not in the Batch Create spreadsheet were ever followed.
Line description is set in batch create and is created. However if you open the invoice and hit edit it does not show until I check the line description check box. My form defaults for sales invoices have line description checked the batch create isn’t following the form defaults.
Sales account is correctly set on non inventory item. However although non inventory item is correctly imported to line in batch create and shows in item field account is not being populated onto the line as it used to. This appears to be a change/loss of functionality in batch create since the ‘this item can be sold’ check box went away on the non-inventory item.
Both issues are changes in batch create behavior not changes to data fields being provided /imported. Hope that helps.
There is a specific column (true or false) that you should set to true to enable inline description. Putting description in the description column is not enough.
Davide - Thanks. I’ll find that. That must be new since the change to put all the checkboxes for various fields on the form defaults. I do one large import about every quarter so clearly a change since the version I had when I imported the last quarter.
I do think that the batch create should either follow the form defaults or if a description is provided as I do and have done for a long time, its presence in the data should determine that the description shows up. One or other. The new requirement to manage all these default flags in the source system or interface data is an unnecessary burden when the logic could simply respect the form default setting data. How about - let the default for batch created transactions be as set in the form defaults unless overridden specifically by setting the flag in the import data?
I’ve always tried to keep batch create as simple as possible by bringing in the least data I could and allowing manager to do as much defaulting as it can.
I’m still hoping that the intended logic is that accounts should still default from items. Maybe @lubos can look at that issue.
Patch - I agree they are different functions never said otherwise. However, ultimately they are two different mechanisms to get an invoice entered. The resulting end invoice is one in the same document. The intent is to minimize how much data is needed in the import. Make the default for batch create follow the form defaults, allow the interface to override those defaults IF you populate the flags in batch create data. If the system doesn’t work like this each source system/interface now needs to deal with managing way more flags that it did a few months ago before all those flags were added to the invoice.
My batch creates have been working for a very long time. I am dealing with change here not first time creation. I absolutely did as you said when I first set up the process. None the less my intent is to populate the MINIMAL amount of fields when importing as possible and let batch create do the defaulting based on application settings whenever possible. This coding approach will also minimize interface recoding effort for users if and when more flags etc. are added.
No
Batch operations allows power users to rapidly update data to exactly what they want. It makes no assumptions about a specific users current task, simply doing exactly what it is requested in one step.
It is a low level interface to the data stored in Manager, as such if Manager’s back end structure changes, then batch create changes. The same applies to Manages API.
In contrast the interactive user interface guides the user to efficiently entering data. Date entry has many other dependencies and is optimised for “common” data entry tasks.
If you want guidance, use the interactive user interface. If you know the exact low level settings you want for many transactions, batch operations maybe more efficient. Choose the wrong approach and you will waste time
Patch - We shall agree to have a difference of opinion. My opinion is that we want to minimize required rework for anyone (power user or not) in recoding integrations each time a change occurs in Manager. Your opinion appears to be well - if you are a power user then deal with it and do whatever interface recoding is required every time there is a change in manager such as adding these new flags to the interface. I shall respectfully disagree and remain of the opinion that while it is good to add new flags to the interface and “powerusers” can use them if needed, it is also good to make interfaces such as batch-create respect as much of the defaulting of the core application as possible to mimimize data required to be populated unless the “power user” wants the interfaced data to do something different than the default within the application. We have a different philosophy with respect to interface architecture I guess. I’m sticking with my opinion.
Back to the issue:
Does this mean also that despite the fact that my non-inventory items have a sales account on them, you don’t think the system should default the default sales account from the item either any more when the item is specified in the batch create. This is a change in behavior for the worse. My source systems never needed to know about the chart of accounts in the target (manager) before. What’s your philosophy here - mine is this places an unnecessary and new burden on the source system/integration to know things they never needed to before. This is actually my point with both issues.
I am going to bow out of the discussion here and deal with the recoding but this is not a good approach either for the user or for support purposes and quite honestly I doubt it is what Lubos intended.
With respect to form defaults, I don’t think they have any business in batch operations, so I am sorry that I don’t agree right there.
But, I understood that you have set-up non-inventory item X to use account Y. But, when you batch create using item X, account Y is not used for the batch created transaction.
I didn’t try to reproduce this but if it’s true then that’s a bug. The primary purpose of non-inventory items is to automate classification to accounts, otherwise there’s absolutely no use for non-inventory items.
To summarize the situation, it seems the complaint is that incomplete Batch Create spreadsheets are producing different results than those obtained manually, which follow Form Defaults selections. @alasdair and @Ealfardan think this is a bug. @Patch does not. The question arises because additional options have been added for transactions, and @alasdair does not think users should have to complete these options in the spreadsheet during a Batch Create operation if choices have been made in Form Defaults.
I agree with @Patch, for the reasons he stated or implied:
Batch Create is a raw data insertion. It should only create what is defined in the data it contains. If something is left out of the record, the program should not insert it.
With Batch Create, the user should have full control to insert any data desired. This includes records that are different from Form Defaults. There could certainly be valid reasons for creating batches of invoices with different options than what a user would normally want for manually entered invoices.
Therefore, I will not classify this behavior as a bug. That is a determination @lubos would have to make.
Then I ask Lubos to look at this. The issue is due to CHANGED functionality making the batch create not work as efficiently as it did before. I believe this was unintended and at least with respect to non-inventory items a bug:
If I specify a non-inventory item in the batch create then (just like it did in older versions of the application) then the accounts should default from the non-inventory transaction to the resulting transaction lines created via catch create. In my opinion this is a bug. To require both the item and the account as required columns in the batch create does not make sense.
With respect to the line description not showing up, again this is a change since the addition of all the flags. Humour me and let’s for a moment say we renamed the ‘Form Defaults’ to ‘Transaction Defaults’, would your opinions then be any different, should not the interface respect the ‘transactions defaults’ unless we specifically call out a value in the interface to do something other than the default. Why is everyone suggesting that the default behavior ought to be to have to recreate the default behavior in each and every interface. Good grief - from a solution architect perspective I am not a big fan of designing interfaces to ensure maximum effort and maintenance required. Please please try to not make every change require significant effort to redo interfaces people already had in place just to keep them doing what was working fine previously.
@lubos - Look forward to hearing your opinion, I can deal with having to add the extra flag but now having to add the chart of accounts detail to my source systems so that I can feed both the item and it’s account and of course keep both in sync now whenever an account is updated for an item - that’s an integration maintenance maximization scheme right there. I’d rather maintain my item to Account relationship in one place - the manager non-inventory item (or inventory items) as my single source of truth please. This is what those items are for after all.
Mine would not. When you delve into raw data creation, I believe you need to accept responsibility for creating the raw data as well as claiming its benefits. Form Defaults provide more automation at the cost of giving up batch functionality. Batch Create gives complete flexibility at the cost of requiring more detailed intervention.
When I specify the UUID for a piece of master data during batch create, in this case a non-inventory item, the group think is that the other fields on that master data element - in this example account number should not default to the transaction but should be specified separately in other fields of the batch transaction. The group does not consider this a bug.
If that logic makes sense to everyone then I need to report other bugs for example - I am specifying the UUID for a customer and the customers address is defaulting onto the transaction. Following the group think here then quite clearly that is a bug… Surely we should have to duplicate and manage all the customer fields in each of our source systems in the same manner as we ought to be replicating and managing all the data elements of inventory items and non-inventory items according to the group.
Seriously. If we provide the UUID of a piece of master data in a batch create then the other data elements for that master data element should default onto the transaction unless a field is populated to a specific/alternate value. What’s the point of master data otherwise. As I have already stated, it used to work, functionality was changed, now it does not. It’s 100% a bug.
A bug is usually defined as an error in processing data in non- accordance with the specifications.
As there are no specifications, this is obviously difficult to prove but obvious bugs such as not calculating values correctly, incorrect labels are easy to identify.
But a disagreement as to how Batch Create works is not a bug - it may certainly be annoying and even be a reason for moving to a different software package
I am quite sure this change from old functionality where account defaulted to new where it no longer does was not a conscious revision but unintended as other things were revised - e.g. removal of flags in non-inventory item “can be sold”, “can be purchased” etc. I believe this change unintentionally broke existing logic/functionality.
If that’s not the definition of a bug, let’s call it an issue then.