AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
My feedback
61 results found
-
1 vote
An error occurred while saving the comment -
2 votes
An error occurred while saving the comment See sample screen
-
3 votesAdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
An error occurred while saving the comment Maybe we can allow user to highlight the shortage “Hold” transaction in ATP screen and directly drill down to WO Inquiry?
-
1 vote
-
5 votes
An error occurred while saving the comment This logic is handled by NEWDATE.PL which is used by 63 programs. There are other *DATE*.PL copy book. If we investigate this issue, we should also investigate other copy books.
-
13 votes
An error occurred while saving the comment Add Stocking & Selling to Stock Ratio to Order and Invoice Line Item Database.
Currently, the line item qty match the line item UOM. On the other hand, the line item selling price is always in stocking UOM. Line item does not store selling to stocking ratio in line item and depend on the item master. If the item master selling UOM and ratio should change in the future, this can cause problem. See the following KB article: https://support.elliott.com/knowledgebase/articles/2011331-the-impact-of-changing-item-selling-unit-of-measur
It is suggested that we should store the selling ratio in the line if user should use selling UOM. This will prevent potential future problem.
An error occurred while saving the comment In Elliott V9, we will incorporate all custom mod required database changes into the standard database. Custom mod data fields or tables will be visible in Elliott user interface through Global setup flag. It is important that we maintain one standard database with one setup of standard DDF without customization. We should speak with CyberMac to incorporate their database as well. This change is necessary if we should move toward to fully utilize relational database.
An error occurred while saving the comment Need an index to quickly identify of a PO line item by item number with date so we can quickly see if this PO line item is the last PO for this particular item and hence allow to update item vendor "6. Last Purchase Cost" in the PO changed mode. We currently do not update "6. Last Purchase Cost" field even if the PO line item FOB cost is changed because we don't know if the PO line item is the latest PO for this item.
An error occurred while saving the comment Note: This was requested in Version 8.x but there is not filler space available.
AP Transaction Processing - Add distribution level reference
Currently, AP Transaction Processing allows the entry of a Voucher Reference, which ultimately carries through to APDSTHST.APDSTHST_VOUCHER_REF for every distribution made against that voucher.
Propose adding a distribution level reference, allowing a unique reference to be added for each distribution made against a voucher.
Add APTRXDST.NEW_AP_DIST_REF
Add APDSTHST.APDSTHST_DIST_REF
Add both references to resultant APDISFIL record.Expand AP Invoice Import Utility Detail Record Layout to include DIST_REF.
This is particularly useful when processing vouchers for credit card statements - which often contain a variety of charges which may require/benefit from a unique reference per distribution, as opposed to the single reference from the voucher entry itself.
An error occurred while saving the comment The workstation ID field in PRINTWIN table should be expanded beyond current 10 digits. This is because sometime the workstation ID can be Loc+Workstation ID, or sometime it can be 2 Digits Form+Workstation ID. Both scenario make them 12 digits. So the Workstation ID is truncated after 8 digits. If you name the workstation in such a way so it may duplicate if using the first 8 digits, then this can cause printing problem.
An error occurred while saving the comment Elliott Price Code is very flexible. However, there are users suggested that Elliott should offer solution to make the pricing easier to maintain. So we are thinking of the following two solutions:
Solution 1 – Split Price Code Tables into Two
We will need to split the price codes into two tables:
(1) Price codes, which support price code 1 – 8. Pricing is not setup in price codes, instead price codes point to pricing policy table.
(2) Pricing policy. Setup pricing, including discount, price, markup, minimum price, and the quantity break pricing (if any).
You can have multiple price codes records per pricing policy.Think of the idea this way, we can break up the top part of the price code file maintenance (customer type) into the “price code” table. We then break the pricing part (including item number, pricing, discount/marktup/price/min-price) into the pricing policy table. Then we link them to gether.
So when you are going to change pricing, you only need to change the pricing policy table, and no need to change price code table. If you want to add ore remove a customer type from a pricing policy, then change the price code table and no need to change pricing policy.
Solution 2 – Add More Price Fields into Item Master
The other solution is we can also add maybe 3 level pricing into the item master, so you can have the following price:
1. Item Price
2. Item Price 1
3. Item Price 2
4. Item Price 3
5. Item Minimum Price
Then when you setup the price code, you can indicate that your pricing is:
Discount (Base on Item Price)
Fixed Price
Markup (base on item cost)
Minimum Price
Item Price 1
Item Price 2
Item Price 3
If you don’t use Fixed Price, then when you change the price in the future, you just change the item’s price fields above. You only change the price codes if certain customers, or customer types need to be changed to apply to a different level of price.An error occurred while saving the comment Support 5 additional search keys of the attribute of customer, items, ship-to...etc.
An error occurred while saving the comment Improve the lot number tracking capability per Avi. Create the database that will be capable of doing that first. Then gradual add the ability down the road.
An error occurred while saving the comment We should probably consider adding volume information to the bin master level so we can determine how full a bin may be. The volume information including cubic feet, length, width, height? Also, a lot of time, the pallet size is important too. In many case, what's store at the bin is pallet, not the indivisual item. Not sure where to put that information.
An error occurred while saving the comment Someone suggested that the Freight Account should be removed from the Order Billing Screen and the invoice posting should always get the freight account from ship via code setup.
Currently, the freight account is determined at the time of entering the Order Billing Screen. It default to the freight account in the ship via code. One Elliott user choose to access billing screen during regular order entry. But they don't know the ship via code yet at the time of order entry, so they use a generic ship via code, and result the billing screen use the generic ship via code freight account. Later on, the ship via code is changed before the order is shipped. But the freight account in order header stay the same.
So it is suggested that Elliott should always determine the freight account base on Ship Via code on the order header upon invoice posting. If that is the case, then we should not even store freight account in order header file at all. We are evaluating whether we should remove freight account from order header file or not. Please comment and let us know your opinion.
An error occurred while saving the comment Regarding Sheryl Manz's comment on 6/6/17 4:40AM, we do intend to introduce 12 months accumulator fields for customer, vendors and some other master table. This will be similar to the 12 months accumulator in IMLOCHST (I/M Location History).
An error occurred while saving the comment Regarding Bob Goldberg's comment on 4/4/2017 12:02, we will ensure that we have the necessary database structure to support 6 lines x 60 characters for address. We are thinking using attribute to support it in the future. Therefore, we will expand the attribute reference field from 35 characters to 60 characters with V9. But we will not support this feature with the initial Elliott V9 release though.
An error occurred while saving the comment Regarding Aaron Keating's comment on 3/17/2017, yes, we can make this change. In addition, I suggest to add customer type to the order header as well. We can then optionally allow user to change customer type at the order header level base on Global Setup. This will allow different pricing for the customer base on the new customer type at the order.
As for the starting source of sales, it is already in the order line item audit trail table. We agree that it make sense to put in the order line item, and then carry over the invoice line item, as well as CPHSTTRX table.
An error occurred while saving the comment Regarding Aaron Keating's comment on 2/16/2017, yes, you can continue to run Elliott V8.x in production, and V9 in a separate folder/database for testing purpose. Once testing is satisfactory, you can then do a final conversion and switch on V9. Unlike V7.5, you cannot run on V8 and V9 concurrently.
There will be changes to VIEWS due to the database structure had been changed. One example is APOPNFIL table used to have two type of records - vouchers and checks. In V9, they are separated into two different tables.
An error occurred while saving the comment Regarding Shyeryl Manz's comment on 2/10/17, just as a FYI, we currently a more finite level attribute security through "Supervisory Relationship". With that, you can consider a more restrictive approach with Global Security flags and Attribute Code Shareable for Read, Change and Delete flags. See knowledge base article: http://support.elliott.com/knowledgebase/articles/870954-feature-enhanced-security-for-attributes for more detail.
An error occurred while saving the comment Regarding Avi Weissbard's comment on 1/31/2017:
5. We will support unit cost and unit price up to 6 decimals. Since not all users want that many decimals, so we will introduce the following flags in company setup:
Number of Decimals For Unit Price
Number of Decimals For Unit Cost
The default value are 4 which match Elliott V7/V8 design. The valid values can be from 2 - 6. We will introduce new AP to make the coding easier to support various number of decimals user choose to go with. At the database level, it is always 6 decimals. The flags here is only for the screen and report printing masking.An error occurred while saving the comment Regarding Avi Weissbard's comment on 1/31/2017:
1. Search by name - Elliott V9 will use case insensitive key, therefore, there's no need for the upper case search field and thus eliminated in V9.
2. We support up to 10 reference fields in customer, vendors, items...etc. In the past, they are searchable as user definable index (5 additional key). In V9, we will extend the user definable index to all 10 reference fields.
3. Noted and we will discuss internally.
4. We currently plan to support unit price at 9,999,999.9999 in Elliott V9.
5. Noted and we will discuss internally.
6. Yes, we will support Lot number up to 18 digits.
7. We will have better support for lot number in V9. In the initial Elliott V9 release, the lot number capability will not be as robust as serial number. We intend to make the V9 database capable supporting robust lot number feature like serial number. Those features may take time to develop like V9.1, V9.2...V10...etc. A good database schema is like a solid foundation. That is what we are trying to do with V9. We intend to build on this solid foundation for may robust features to come.An error occurred while saving the comment There are users suggest that Elliott V9 need to support plus work order with scheduling date at the routing level. Currently, Elliott plus work order support start and due date at the work order header level. But some users produce items that may take 2 weeks to produce. They need the scheduling at the routing level which SFC do. Then they need to print production scheduling report and material pick ticket for the date which is base on routing scheduling date. Without this feature, they can't covert to plus work order.
-
4 votesunder review ·AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
responded
This project is not trivial. But we think it can be a useful features to prevent users open up files over night that cause backup issue. At the moment, we are placing this as a somewhat low priority item for 8.6. So do not expect an update with this new feature in the near future.
We are evaluating it to allow users to set policy on a workstation by workstation basis for "Auto Logout Time" in Setup area. You could set a workstation to, say, logout at 21:00 every night. The setting will be saved to local registry. Hence you need to set this up on a workstation by workstation basis unless you add group policy.
-
3 votes
-
4 votes
-
2 votesunder review ·AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
responded
If we should make this change, a global setup flags will be needed in COP -Func -> Pick/Pack Ticket/Ship Label setup. A flag like "51. Print None Stock Items on Pick Ticket?" will be introduced. The default value should be "N' so the existing users will not be affected by this new feature.
My thinking is this flag should apply to both the line items on pick ticket and kit components under the line item. Do you agree?
An error occurred while saving the comment If we should make this change, a global setup flags will be needed in COP -Func -> Pick/Pack Ticket/Ship Label setup. A flag like "51. Print None Stock Items on Pick Ticket?" will be introduced. The default value should be "N' so the existing users will not be affected by this new feature.
My thinking is this flag should apply to both the line items and kit components. Do you agree?
AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
-
2 votes
-
3 votesAdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
-
1 vote
-
2 votesunder review ·AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
responded
in Elliott 8.6, we are moving toward using Report Desk to replace Export Processor. We can consider add Product Category as a group to UDR Invoice History by item Report.
AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
An error occurred while saving the comment This is to Netcellent's Developer.
Currently, UDR Invoice History By Item has a template with the following join:
SELECT * FROM CPINVHDR
left join cpinvlin on cpinvlin.inv_itm_inv_no = inv_no
left join arcusfil on arcusfil.cus_no = inv_customer_no
left join imitmfil on imitmfil.item_no = inv_itm_itm_no
left join imlocfil on imlocfil.loc_code = inv_mfg_location
[Where] cpinvlin.inv_itm_itm_no <> ' ' and inv_transit_sts <> 'Y' and inv_transit_sts <> 'R' and ((inv_type <> 'C' and inv_itm_qty_to_ship <> 0) or inv_type = 'C')
[UserWhere]We need to change this join with the followings:
1. Use CPINVLIN as the primary table and inner join to CPINVHDR.
2. Left Join IMCATFIL from ITEM_PROD_CAT, it could be argue left join from INV_ITEM_PROD_CAT. Both has its pros and cons. I think we need to play by ear.
3. Left Join IMUSRDEF.
4. Let Join ARSLMNFIL from the 1st Salesman in CPINVHDR
5. Left Join ARSHPFIL.The Report Filter should mostly based on CPINVLIN:
* INV_ITEM_ITEM_N0
* INV_ITEM_INV_DATE
* INV_ITEM_CUST_NO
* INV_ITEM_INV_NO
These are either the leading key segment in CPINVLIN except INV_ITEM_INV_DATE which is part of the key, but not the leading segment. -
4 votes
-
2 votesAdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
An error occurred while saving the comment There is a feature to print packing list by box if you perform shipment verification. See KB article: https://support.elliott.com/knowledgebase/articles/1132636-feature-print-packing-list-by-box-number
-
2 votes
An error occurred while saving the comment We should consider copying orders from order history, invoice history and maybe archive history?
AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
-
3 votes
An error occurred while saving the comment If we want to keep track of the users who enter the transaction in the subledger, that means we first need to add the user-id to the distribution file like ARDISFIL, APDISFIL , IMDISFIL ...etc. But we only have 10 bytes left with these table and we don't want to use all all the fillers of these tables. In addition, we need to add user-id to places like APTRXFIL and all other related transaction tables. This will become a big project. Therefore, I don't think we can afford to track the original user who enter the transaction. But tracking the user who post the transaction is possible. We can add that to GLJNLHST and GLTRXFIL. But that would seems to be an incomplete solution
An error occurred while saving the comment I would suggest to add the original users who create the distribution in the first place. So we are not just tracking the user who post the GL journal entry, we keep track of the user who post the COP Sales Journal, PO Receiving, New AP Trx...etc. To do that, we need to add the user field to each distribution table like ARDISFIL, APDISFIL, IMDISFIL..etc.
Then we have the issue of which user to keep track, is it the user who post, or the user wo enter the transaction in the first place? Since many users use "Defer Processing" to post, so keeping track of the posting users may not be not informative. If we should keep track of the user who enter the transaction, that could become a lot more complicated. Take a sales order as an example, that could be the user who enter the order, the user wo print the pick ticket or the use who print the invoice. In AP, it would seems to make sense of keep track of the user who enter the voucher in the first place. But it may be question of AP check, do we keep track of the user who prepare the payment selection, or do we track the user who print AP checks? They may be the same, may not . For General Journal, it is pretty clear that it should be the user who enter the journal entry in the first place, instead of the user who post.
It would seems to me that here's a lot of issue to fine tune this change.
AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
-
3 votesAdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
-
4 votesunder review ·AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
responded
This project is declined because to export notes in export processor will result in poor performance because we do not use index in Export Processor. On the other hand, the Report Desk in Elliott 8.6 can be used to print or export notes to CSV or xlsx. So that's a better solution for a generic notes export function.
AdminEdward M. Kwang - NETcellent System, Inc.
(CEO / Founder, NETcellent Systems, Inc.)
supported this idea
·
The workaround at the moment is to introduce a global setup flag like:
Are All Users Allow to Delete Other A/R Batches? Y/N (default is Y)
If this flag is set to “N”, then we popup a window to allow you to specify the admin users (up to 20) who can delete.