As an administrator, you may define an item's cost (average, last or standard cost) on the CSV. On the other hand, there's global user security to determine if a user can see item cost or not. If the user cannot see item cost on a report, but is allowed to run the user-defined CSV export, the cost column(w) will be suppressed automatically.

If you did not define a location column on the CSV layout, then when you run that report, the system assumes one item per row, the location field is skipped automatically and "ALL" locations are assumed. If location is defined on the CSV layout, the system will export one item/location per row.  In the selection screen "3. Location," you can either hit Enter for "ALL" locations, or enter up to 10 specific locations.  See sample screen below:

We do not include non-netable location quantities when "ALL" locations are selected.  In Location File Maintenance, field "13. ATP Netable Loc" determines whether a location is netable.  A non-netable location may refer to a defective warehouse, service warehouse or consignment inventory warehouse, etc. where the inventory in those locations should not be counted as available to sell.

On the other hand, if you select a specific location in "3. Location" for non-netable locations, then we will include those non-netable locations regardless. Therefore, based on how you enter values in "3. Location," the result may be inconsistent. For example, let's say we have a total of three locations: 1, 2 and 3.  Let's assume 1 and 2 are netable locations and 3 is non-netable. If you choose to run a report by specifically entering location 1, 2 and 3, you will see location 3's numbers show up.  But if you choose to run a report for ALL locations, then location 3 does not show up. This inconsistency may confuse you.

While the rule to exclude non-netable locations when entering ALL locations generally makes sense for quantity on hand, on order, allocated, backorder, etc., it may not always be appropriate with history data for consignment inventory scenarios. To handle consigned inventory, we typically create a warehouse location and indicate "13. ATP Netable Loc" as "N" since those inventory items are currently stored at the customer's location and we don't want to include them as available to sell or use. On the other hand, we do want to include sales history for consignment inventory.  To solve this issue, we introduced a flag in Global Setup -> Dist -> Reordering Advice CSV Export -> screen 3 -> "1. Include Non-Netable Location in Sold Qty/Amt Column?" Default is "N" which means non-netable location sales history will not be included when you choose "ALL" locations.  But if you have this flag set to "Y," then the non-netable location sales history will be included. 

To make it easy to understand this principle, we break down quantity and amount data into two different categories: "Current" and "History."  Current refers to quantity on hand, allocated, on order,  and back order. "History" refers to quantity sold, sales amount...etc.  "History" data may be included for non-netable locations when "ALL" locations are chosen provided the Global Setup above is set to "Y." For a list of what code types are considered "Current" or "History," see the section "Reference B - Current vs. History Columns."

You can run and define User Defined CSV with the following path: I/M -> Reports -> Reorder Advice/User Def CSV. You may wish to let other users run the same User Defined CSV, but you may not want to let them define new, modify existing -- or worse -- delete the existing User Defined CSV template. Therefore, this path is only appropriate for the admin users.

The purpose of User Defined CSV Batch is to provide a pointer to a CSV file to be used by User Defined CSV Export as a pre-selected item. For example, if you have a list of items like:

And you'd like to use these items as input and analyze them through User Defined CSV export. This can be very useful when it is not possible to use the parameters provided by User Defined CSV to narrow down to the item list. To use this feature, you can store the items list in a CSV file.  The item number does not have to be the only column in the CSV.  But it must be the first column.  Therefore, any existing CSV file with an item as the first column can be used as the input CSV file to drive User Defined CSV Export. Please see the following KB article for details: http://support.elliott.com/knowledgebase/articles/1838167-feature-user-defined-csv-export-item-batch-suppo

Depending on how you define the template of User Defined CSV, you may experience slow performance when you run User Defined CSV export. When you retrieve ATP information, the system needs to read the detail ATP records.  If you have a large ATP database, this may slow down the performance somewhat. If you retrieve sales history information, it will try to get data from the IMLOCHST table, which should have reasonable speed.  However, when you try to get "QS" (Qty Sold) information, you could specify the quantity sold for a specific customer or customer type. If that is the case, the only way the system can calculate that information is by looking up the IMINVTRX table, which tends to be a big table, and that can  slow down the performance.

You may consider running the report on the PSQL server directly which can result in maybe 10 times performance improvement compared to running it from a workstation.  If there's a security restriction for doing so, you may consider running deferred processing on a PSQL server and letting any User Defined CSV Export that takes a long time run through deferred processing.  Defer Processing supports the "run now" feature which can help to shift the burden of running reports on the client side to the server to benefit performance. 

The following is a list of all valid code types (fields) in User Defined CSV:

In the Code Type search window, when you highlight each code type, the bottom of that window may display up to three more lines of explanation of the highlighted code. See sample screen below:

In the previous section, we discussed the relationship of non-netable locations and how they may affect current and history data presentation.  In short, quantity on hand, allocated, on order, etc. are considered "current" data.  Qty sold, sales amount, etc. are considered "history" data.  The following is a list that shows which code types are considered as "Current" or "History" data: