-
Control Sales Tax on Miscellaneous Charges
The customer needs to calculate the sales tax on both - sales price and miscellaneous charges but does not want the miscellaneous charges amount to be impacted / decreased even after enabling the " Price include sales tax" checkbox. -
Bulk submissions and bulk approval of Free text invoice
Customer creates recurring AR invoice once a month and there are a lot of invoices which need to be submitted individually. The customer wants to submit multiple AR invoices at once for the approval. Adding to it, there should be a criteria to approve multiple AR invoices at once. -
BOM calculation group functionality should work for RM's Planned and Standard cost
When calculate price for raw material, the default order type is Purchase order. So logic use the latest cost price as calculation result. When calculate price for SFG, "Production order" type is used in the calculation. So the "Inventory price" is used as setting in calculation group. User should be able to calculate the inventory price for Raw material when the Item - Calculation group is mentioned as inventory Price model (but system is not calculating for as per the inventory price.) -
Bug 653345: During the picking process, WH workers need the ability to overwrite quantities above 20 without going into edit mode
Presently, the warehouse mobile device has a quantity wheel limited to 20. If item is more than 20, the wheel picks up correct quantity. But, if the item quantity is less than 20, customer has to take extra effort to go into edit mode, remove existing quantity and write new quantity. The warehouse mobile device should allow the system to by default populate the picking item quantity (in case if is >20) or permit to override the existing quantity (currently new value concatenates with the existing value).
-
During the picking process, WH workers need the ability to overwrite quantities above 20 without going into edit mode
Presently, the warehouse mobile device has a quantity wheel limited to 20. If item is less than 20, the wheel picks up correct quantity. But, if the item quantity is more than 20, customer has to take extra effort to go into edit mode, remove existing quantity and write new quantity. The warehouse mobile device should allow the system to by default populate the picking item quantity (in case if is >20) or permit to override the existing quantity (currently new value concatenates with the existing value).
-
Over production should reflected in started and remaining quantity
Currently there are 2 scenarios in production control > production floor execution which should be user configurable options according to below expectations:
- Over production should be reflected in started and remaining quantity - When the quantity gets overproduced in the PFE, it does not show the overproduced quantity in "remaining quantity" field. Expectations are to show these overproduced quantity in started as well as remaining quantity field.
- When qty is overproduced, next operation does not default produced qty in last step as start qty. Remaining qty does not consider overproduction -While previous operation shows the changed overproduced quantity, it should be added as "start quantity" and should show the same when user starts next job.
-
Catch-weight product receipt receive now does not work
Customer is using the standard receive now fields on the purchase order line, that do work exactly as expected for non-catch-weight products. however, for the catch-weight item the system should work same as non-catch-weight item.
At the time of posting product receipt, system throws an error message - "Insufficient inventory transactions with status Registered." Which does not always need to be considered by the user.
Catch weight is designed for partial and full visibility, in case if the customer uses it for partial visibility only, there is partial visibility of catch weight as the products are not measured and controlled as single units in all transactions. The items are not consumed or tracked for each actual weight. The aggregate weight is measured for the entire batch of the catch weight inventory e.g., receiving 100 chicken filets with a total weight of 40,7 kilograms and their individual weights vary within a narrow range.
In above case, register inventory will not be feasible for customer. It is better to keep the post packing functionality as simple as that for non catch weight items.
-
Suggesting location during put away doesn't validate the container type
When receiving a load from a purchase order the put location is determined by the location directives.
When the location suggested isn't available and the user request a new suggested location the system seems to not take all fields like the container type in consideration and then suggests a location (next open location) where the container isn't allowed.
The system fails to suggest a location where the container is allowed and suggests next open location. Instead, system should provide the next open location based on the container type.
-
System should consider exact amount in project cost transactions when doing negative PO lines on Project POs
Current scenario: When using a service item with negative quantity on project PO, system posts different amount to posted project transactions. (This issue occurs whenever a project product receipt is posted, amounts are different every time).
The issue is only with service item using negative quantity.
Expected scenario: System should post the transactions for exact cost mentioned in the Project PO line, even if the quantity is negative.
-
Posting profile in project account should reflect names based on correct posting type
Scenario 1: After invoicing a fixed price project, the posting type name is shown as Project WIP invoiced – on account, as per name it would indicate that this is an advanced type of account but the same name is used when Customer Invoice is generated and the same posting profile is used for Advance invoice.
posting type value is mentioned as “Project - WIP invoiced - on account”, but as this revenue is recognized, system still shows the value as "On Account Transactions"
Scenario 2: 2. After posting revenue, voucher transaction posting name is showing as accrued revenue, as per name it would indicate that this is a Balance Sheet account but actually it is not Balance Sheet account, it is a P & L account.
The posting type name shows that the postings are balance sheet type. However, the nature of posting is "Accrued revenue".
Above posting types confuses the customers as which ledger the posting was recorded. currently the system does not validate the posting type and gives incorrect names.
You’re offline. This is a read only version of the page.
