This document is a compilation of the fixes that are built into Microsoft
Dynamics AX 3.0 with Service Pack 6 (SP6). All issue numbers are bug
numbers that Microsoft and its partners can use to track these problems to
resolution. Microsoft Knowledge Base (KB) numbers, when they are available, are
linked to the published Knowledge Base on Partner Source (you must have access
to Partner Source to access these links).
This document contains information
similar to what can be found in the Microsoft Knowledge Base for a customer fix request
escalation. Because some Microsoft Knowledge Base articles for these fixes are
not yet published, this information is only as complete and accurate as is
currently possible.
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #2846 | Not available | The percentage per line in the Vendor top 100 and Customer top 100 reports was calculated incorrectly. | • Problem The percentage per line in the Vendor top 100 and Customer top 100 reports was calculated incorrectly. The issue occurred because the calculation of the totalRevenue and totalQty total sums in the \Classes\PurchReport_Ranking\writesortArray method for the Vendor top 100 report and the totalRevenue, totalQty, and totalContributionMargin total sums in the \Classes\SalesReport_Ranking\writeSortArray method for the Customer top 100 report was incorrect. • Solution The code in the \Classes\PurchReport_Ranking\writesortArray and \Classes\SalesReport_Ranking\writeSortArray methods has been updated to correct the calculation. |
\Classes\PurchReport_Ranking \Classes\SalesReport_Ranking \Reports\purchRanking \Reports\saleslRanking |
| #3350 | Not available | When users created a purchase order from a sales order, the quantity on the purchase order line was not always correct because the inventory unit was used instead of the sales unit. | • Problem When users created a purchase order from a sales order, the quantity on the purchase order line was not always correct because of an incorrect unit conversion. This happened if a different unit was set up on an item for inventory and sales order. The conversion to quantity in the purchase unit was done by using the inventory unit instead of the sales unit. • Solution Unit setup on the sales line is considered when the system converts the quantity into the purchase unit. Because the PurchAutoCreate_Sales class is expecting that the quantity is in the inventory unit, and because the class is used from other locations, the quantity is saved in the inventory unit in TmpFrmVirtual and converted to the sales unit when it is displayed. This is performed in the PurchCreateFromSales form that populates the TmpFrmVirtual table. |
\Forms\PurchCreateFromSales |
| #4191 | Not available | When the user created a purchase order, the Orderer field in the Purchase order form was not filled in. | • Problem When the user created a purchase order, the Orderer field located under Administration on the Setup tab of the Purchase order form was not filled in. The issue occurred because the procedure for updating the PurchPlacer field during the initialization of the PurchTable table was missing. • Solution The code has been modified to update the PurchPlacer field of the PurchTable table when the system calls the InitValue method in the PurchTable table by using the EmplTable::userId2EmplId(curUserId()) method. |
\Data Dictionary\Tables\PurchTable |
| #4294 | Not available | The user could not enter any transactions for the customer if the Stopped parameter was set to ‘All’. However, in the Free text invoice form, the user could enter transactions and no warning message was displayed. | • Problem The user could not enter any transactions for the customer if the Stopped parameter was set to ‘All’. However, in the Free text invoice form, the user could enter transactions and no warning message was displayed. The issue occurred because the orderAccount field was not checked for the Stopped parameter from the CustTable table when the user selected a customer in the CustFreeInvoice form. • Solution The validateField() method in the CustInvoiceTable table has been modified to check the OrderAccount field. A warning message is displayed if the user tries to select the record with the stopped customer. |
\Data Dictionary\Tables\CustInvoiceTable |
| #4307 | Not available | The FreightZone (UPS Zone) initialization was missing during the initialization of a purchase order. | • Problem The FreightZone (UPS Zone) initialization was missing during the initialization of a purchase order. The issue occurred because the FreightZone (UPS Zone) initialization was missing in \Data Dictionary\Tables\PurchTable\Methods\ initFromVendTable. • Solution The FreightZone (UPS Zone) initialization has been added to \Data Dictionary\Tables\PurchTable\Methods\ initFromVendTable. |
\Data Dictionary\Tables\PurchTable\Methods\initFromVendTable |
| #4602 | Not available | If the user invoice updated a purchase order without previously running the packing slip update, the physical cost amount was not updated with the price stated in the Invoice update dialog box. | • Problem If the user invoice updated a purchase order without previously running the packing slip update, the physical cost amount was not updated with the price stated in the Invoice update dialog box. Instead, a physical cost amount was retrieved from the purchase order line. The issue occurred because during the invoice update the price from the Invoice update dialog box was very rarely taken to fill in the inventTrans.costAmountPhysical field (\Classes\InventMov_Purch\useEnteredPriceAsCost). • Solution A condition has been added to the if statement in \Classes\InventMov_Purch\useEnteredPriceAsCost. Also, the \Classes\InventMovement\updateLedgerPhysical method has been overridden in the InventMov_Purch class and has been modified to make sure that inventTrans.costAmountPhysical is filled from the purchase order line if it has not been modified in the Invoice update dialog box. |
\Classes\InventMov_Purch\useEnteredPriceAsCost \Classes\InventMov_Purch\updateLedgerPhysical |
| #6452 | Not available | Incorrect amounts/quantities were transferred to the Intrastat form if the item being purchased or sold had different units for the purchase orders/sales orders and the inventory. | • Problem Incorrect amounts/quantities were transferred to the Intrastat form (Basic > Periodic > Foreign trade > Intrastat) by using the Transfer functionality (the Transfer button) if an item had a unit conversion setup (Inventory management > Items > Setup > Unit conversion) and different units were set for the purchase or sales order and inventory (the Quantity tab of the Items form). The issue occurred because there were differences in the units that were used in the \Classes\IntrastatTransfer\calcVendPackingSlipAmount and \Classes\IntrastatTransfer\loadFromVendPckSlpJour methods. • Solution The \Classes\IntrastatTransfer\calcVendPackingSlipAmount and \Classes\IntrastatTransfer\loadFromVendPckSlpJour methods have been modified to fix the issue. |
\Classes\IntrastatTransfer\mapInsertInvoice \Classes\IntrastatTransfer\loadFromVendInvoiceJour \Classes\IntrastatTransfer\loadFromVendPckSlpJour \Classes\IntrastatTransfer\calcVendPackingSlipAmount \Classes\IntrastatTransfer\loadFromCustInvoiceJour \Classes\IntrastatTransfer\loadFromCustPckSlpJour \Classes\IntrastatTransfer\calcCustPackingSlipAmount \Classes\IntrastatTransfer\loadFromProjInvoiceJour \Classes\IntrastatTransferIT\loadFromCustInvoiceJour \Classes\IntrastatTransferIT\loadFromCustPckSlpJour \Classes\IntrastatTransferIT\loadFromVendInvoiceJour \Classes\IntrastatTransferIT\loadFromVendPckSlpJour \Classes\IntrastatTransferIT\loadFromProjInvoiceJour |
| #7041 | Not available | The SalesBalance and SumTax fields of the VendInvoiceJour table were filled in incorrectly when the same voucher number was used for several lines of the Invoice journal of the ‘Daily’ type. | • Problem The SalesBalance and SumTax fields of the VendInvoiceJour table were filled in incorrectly when the same voucher number was used for several lines of the Invoice journal of the ‘Daily’ type. The issue occurred because the Tax::taxTotalVoucher method that is used to calculate the value for TaxSum did not allow for the line number while it was calculating the tax for the whole voucher. Also, SalesBalance was calculated incorrectly when invoiceAmount was negative. • Solution The Tax::taxTotalVoucher method has been substituted with Tax::taxTotalVoucherDateRecId. Also, the conditional re-assignment of the sumTax field has been moved down. |
\Classes\VendVoucher\createInvoiceJournal |
| #7952 | Not available | The user could not use the Copy from all functionality to its full extent because the transaction tracking message appeared under certain conditions. | • Problem The user could not use the Copy from all functionality to its full extent because the transaction tracking message appeared under certain conditions. The issue occurred because of the unbalanced ttsbegin/ttscommit pair. • Solution The code has been modified so that the transaction is committed before it calls the promptConvertCurrencyCode method of the PurchTable table, and a new transaction starts after the call has solved the issue. |
\Classes\PurchCopying\copyHeader |
| #8209 | Not available | When the user registered an invoice, linked it to a purchase order and then tried to link more purchase orders to that invoice during the approval, the invoice could not be posted. | • Problem When the user registered an invoice, linked it to a purchase order and then tried to link more purchase orders to that invoice during the approval, the invoice could not be posted. The update was canceled with an error message notifying the user of the imbalance. When the invoice was linked to one purchase order during the registration, it was not possible to link more orders to it during the approval. This was caused by the posting settings that did not allow for more than one order being referenced by the invoice. • Solution The code has been modified so that the sumBy, sumPurchID and sumNum fields are changed if more than one order is linked to the invoice during the approval. |
\Classes\PurchFormLetter_ApproveJournal\chooseLines |
| #8785 | Not available | ItemId and County were ignored by the Intrastat compression functionality (Basic > Periodic > Foreign trade > Intrastat > Update > Compression). | • Problem An error occurred after compressing Intrastat transactions (Basic > Periodic > Foreign trade > Intrastat > Update > Compression) and the item number and county were not transferred if a purchase order was invoiced by a vendor from the European Union country. The issue occurred because of the incorrect initialization of the Intrastat record fields. • Solution The code has been modified to add the ItemId and County fields to the Intrastat record during the compression. |
\Data Dictionary\Tables\Intrastat\Field
Groups\CompressionOfIntrastat \Classes\IntrastatCompression\classDeclaration \Classes\IntrastatCompression\createNewIntrastat \Classes\IntrastatCompression\difference |
| #9966 | Not available | The physical Delivery remainder field was updated incorrectly on a purchase order, after the user posted an invoice for the credit note, if the previously posted packing slip for this credit note was posted by using the Receive now field with a negative value. | • Problem The physical Delivery remainder field was updated incorrectly on a purchase order after the user posted an invoice for the credit note if the previously posted packing slip for this credit note was posted by using the Receive now field with a negative value. The qtyRemainNew variable in the CalcQtyPurch and CalcQtyInvent methods always had a positive value regardless of the Credit Remaining quantity check box state. However, it must be zero when the Credit Remaining quantity check box is cleared. In another case, when the Credit Remaining quantity check box was selected two times on the packing slip (Receive now) update and invoice update (All), the ordered quantity was positive and update quantity was negative, the qtyRemainNew variable could have an incorrect doubled quantity. • Solution The logic in the CalcQtyPurch and CalcQtyInvent methods of the PurchQuantity_Invoice class has been updated to correct the calculation of the quantity for the Deliver remainder. |
\Classes\PurchQuantity_Invoice |
| #10454 | Not available | It was not possible to use the Go to the Main Table functionality (available in the shortcut menu) in the Reference number field on a purchase order line if this line was automatically created from the Production module and Reference type was equal to ‘Production line’. |
• Problem |
\Data Dictionary\Tables\PurchLine\Relations |
| #11807 | KB908910 | When the user created a purchase order credit note by using the Create credit note functionality, this led to incorrect inventory values after the inventory recalculation where the FIFO method was used. | • Problem When the user created a purchase order credit note by using the Create credit note functionality, inventory values after an inventory recalculation, where the FIFO method was used, were incorrect. When such a credit note was posted, the cost amount of the credit note issue inventory transaction differed from the original invoice transaction cost. The difference between the purchase invoice cost and the credit note cost was posted on the Purchase account and Consumption account. While running the inventory recalculation, regardless of whether the user previously marked the original transaction when a credit note was created, the system settled that transaction with another one according to the FIFO model. The issue occurred because there was no field in the PurchLine table that contained information about InventTransIdReturn as it was in SalesLine. Therefore, when the system populated the InventTrans table from PurchLine as it created a credit note, the InventTransIdReturn and InventRefTransId fields remained blank. This led to the loss of information and finally the user could not define which LotID was actually returned and therefore could not settle it correctly. • Solution Marking for the return transactions has been implemented by using standard marking logic. |
\Data
Dictionary\Tables\InventTrans\Methods\updateMarking \Classes\PurchCopying_CreditNote\copy |
| #12125 | Not available | If the Check for packing slip number used parameter in the Accounts payable parameters form was set to ‘Accept duplicates’ or ‘Warn in case of duplicates’ and more than one packing slip was posted from the same purchase order with identical packing slip numbers, each journal line in the Packing slip journal form was shown two times. | • Problem If the Check for packing slip number used parameter in the Accounts payable parameters form (Account payable > Setup > Parameters) was set to ‘Accept duplicates’ or ‘Warn in case of duplicates’ and more than one packing slip was posted from the same purchase order with identical packing slip numbers, each journal line in the Packing slip journal form (Accounts payable > Purchase order > Inquiries > Packing slip) was shown two times. The issue occurred because of an error in the design in \Data Dictionary\Tables\VendPackingSlipPurchLink. • Solution The InternalPackingSlipID field has been added to \Data Dictionary\Tables\VendPackingSlipPurchLink to uniquely identify records for the Packing slip journal line with the required relation to the \DataDictionary\Tables\VendPackingSlipJour table and initialize this field correctly when the Packing slip journal form is called. Also, an upgrade job has been created to update the existing data. |
\Data
Dictionary\Tables\VendPackingSlipPurchLink\Methods\initFromVendPackingSlipJour \Data Dictionary\Tables\VendTable\Methods\checkPackingSlip \Classes\ReleaseUpdateDB_V25toV30\initJobs \Classes\ReleaseUpdateDB_V30toV30SP\initJobs \Classes\ReleaseUpdateDB_V30toV30SP\updateVendPckSlpPurchLink |
| #12527 | Not available | Item sales tax group was included in the miscellaneous charges allocation for the purchase order lines, although the item sales tax group was not specified for the miscellaneous charges. | • Problem When the miscellaneous charges code (Accounts payable > Setup > Misc. charges > Misc. charges codes) was specified for a debit item and credit customer/vendor and this miscellaneous charges code was applied in a purchase order header (Accounts payable > Purchase order > Setup > Misc. charges), the item sales tax group of the purchase order line was applied for the miscellaneous charges allocation, although it was not specified in the Miscellaneous charges transactions form (Accounts payable > Purchase order > Setup > Misc. charges). The same problem affected sales order lines. The issue was caused by an error in the initialization code. • Solution The initialization code has been corrected to skip the item sales tax group assignment if it is not specified for the miscellaneous charges transaction. |
\Data Dictionary\Tables\MarkupTrans\Methods\initFromPurchLine \Data Dictionary\Tables\MarkupTrans\Methods\initFromSalesLine |
| #13795 | Not available | When users used the Posting invoice form (Accounts payable > Periodic > Purchase order update > Invoice), an error occurred when the user changed the Quantity field value two times on the Parameters tab. The same issue occurred in the Posting purchase order, Posting receipts list, and Posting packing slip forms. | • Problem When users used the Posting invoice form (Accounts payable > Periodic > Purchase order update > Invoice) without purchase orders created for update, an error occurred when the user changed the Quantity field value two times on the Parameters tab. The same issue occurred in the Posting purchase order (Accounts payable > Periodic > Purchase order update > Purchase order), Posting receipts list (Accounts payable > Periodic > Purchase order update > Receipts list), and Posting packing slip (Accounts payable > Periodic > Purchase order update > Packing slip) forms. When the user changed the Quantity field value in the Posting invoice form without purchase orders created for the update, the system created an empty record in the PurchParmTable table in the \Forms\PurchEditLines\Methods\calcTotals method. Either during the second attempt to change the Quantity field value without purchase orders created for update or after opening the form again and doing so, the system tried to create another empty record in the mentioned table and this led to an error message. This occurred because, for the PurchParmTable table, the ParmIdPurchIdIdx unique index exists, which consists of PurchId and ParmId. • Solution The code has been modified to prevent the system from creating an unnecessary empty record in the PurchParmTable table in the \Forms\PurchEditLines\Data Sources\PurchParmUpdate\Fields\SpecQty\Methods\modified method. |
\Forms\PurchEditLines\Methods\calcTotals |
| #15008 | Not available | The SQL critical error message appeared if a blanket order had seven hundred or more associated purchase orders and the user tried to find the attached purchase orders by selecting the blanket order and clicking Inquiries > Attached purchase orders. | • Problem The SQL critical error message appeared if a blanket order had seven hundred or more associated purchase orders and the user tried to find the attached purchase orders by selecting the blanket order and clicking Inquiries > Attached purchase orders. The issue occurred because the database has upper limits for the size of where clauses and the current business logic added the OR condition to the query for every release order attached to a blanket order. • Solution The query has been changed to use the exists join construction. |
\Classes\PurchTableForm_Links\queryPurchTable |
| #15664 | Not available | The Deliver remainder field was not updated correctly in purchase orders and sales orders when the user clicked Functions > Deliver remainder. | • Problem The Deliver remainder field was not updated correctly in purchase orders and sales orders when the user clicked Functions > Deliver remainder. The issue occurred because the PurchLine data source in the PurchTable form was not reread when the PurchUpdateRenmain form was closed and accordingly, the SalesLine data source in the SalesTable form was not reread when the SalesUpdateRenmain form was closed. • Solution The closeOk() method has been modified in the PurchUpdateRenmain and SalesUpdateRenmain forms so that corresponding data sources are reread. |
\Forms\PurchUpdateRemain \Forms\SalesUpdateRemain |
| #15924 | Not available | In the Enterprise Portal, when the user opened the Price agreements form, the form label was Sales prices instead of Purchase prices. | • Problem In the Enterprise Portal, when the user opened the Price agreements form, the form label was Sales prices instead of Purchase prices. The issue occurred because an incorrect label was used. • Solution The code has been modified to use the correct label for the Price agreements Web form. |
\Web\WebForms\EPPricediscTableInfo\setCaption |
| #15929 | Not available | Users could not add any Item sales tax group in the miscellaneous charges of the order line when Misc charges code had a Debit type equal to ‘Item’ and a Credit type equal to ‘Ledger account’. | • Problem Users could not add any Item sales tax group in the miscellaneous charges of the order line when Misc charges code had a Debit type equal to ‘Item’ and a Credit type equal to ‘Ledger account’. The issue occurred because the Item sales tax group field was disabled regardless of the value of the miscellaneous sales tax. • Solution The Item sales tax group field has been enabled and a new method has been created to determine whether there is a new sales tax. |
\Data Dictionary\Tables\MarkupTrans \Forms\MarkupTrans \Forms \MarkupAllocation \Classes\Tax |
| #16587 | KB915187 | No check for the consistency of the purchase type between the header and the order line was performed in the Purchase order form. | • Problem No check for the consistency of the purchase type between the header and the order line was performed in the Purchase order form. Therefore, a purchase line that did not have any inventory transactions could be created. The issue occurred because the validateWrite method of the PurchLineType class did not call the checkPurchType method. • Solution A call to the checkPurchType method has been added in the validateWrite method to check a purchase line for the purchase type. |
\Classes\PurchLineType\validateWrite |
| #17699 | KB920633 | When Microsoft Dynamics AX 3.0 showed amounts of money with more than two places for pennies, checks were not printed correctly because the string representation of pennies was not numeric. | • Problem When Microsoft Dynamics AX 3.0 showed amounts of money with more than two places for pennies, checks were not printed correctly because the string representation of pennies was not numeric. The issue was caused by the assumption in the standard NumeralsToTxt() function that only two decimal places were specified for pennies. • Solution The code has been modified to extend support for N decimal places for pennies by rounding them to two decimal places when showing the amount of money in checks. |
\Classes\Global\numeralsToTxt \Classes\Global\numeralsToTxt_ES |
| #17736 | KB920887 | The Deviations in cost price report showed incorrect information if the item unit price value was set not equal to ‘1’ and purchase order was posted with the value other than the standard cost value. | • Problem The Deviations in cost price report showed incorrect information if the item unit price value was set not equal to ‘1’ and purchase order was posted with the value other than the standard cost value. The issue occurred because of the incorrect cost amount calculation for a purchase line. • Solution The inventTableModule.priceUnit() method has been removed from the calculation statement. |
\Reports\PurchVariencesCostPrice\Designs\ReportDesign\AutoDesignSpecs\Body:PurchLine\Methods\executeSection |
| #17971 | KB921947 | When the user changed an existing sales order from ordinary to intercompany, the system created the corresponding intercompany purchase order of the ‘Journal’ type with no lines transferred. | • Problem When the user changed an existing sales order from ordinary to intercompany, the system created the corresponding intercompany purchase order of the ‘Journal’ type with no lines transferred. The issue occurred because, in the \Classes\SalesTableType\interCompanyMirror method, the PurchTable buffer read from the PurchTable table, which was empty (because it was not previously created) and no initialization was done for the basic parameters because salesTable.fieldChanged(fieldName) was needed for this. Also, after users created an incomplete intercompany PurchTable entry, no lines transfer was done. • Solution The create variable has been added to the \Classes\SalesTableType\interCompanyMirror method. |
\Classes\SalesTableType\interCompanyMirror \Classes\SalesTableType\update \Classes\SalesLineType\interCompanyMirror \Classes\SalesLineType\update \Classes\PurchTableType\interCompanyMirror \Classes\PurchTableType\update \Classes\PurchLineType\interCompanyMirror \Classes\PurchLineType\update |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #1981 | Not available | When the user created a sales order and populated it from another sales order, the system did not copy the total discount percentage to a new header and the order was of the ‘Returned item’ order type. This could cause an inconsistency between the sales order and the returned item order. | • Problem When the user created a sales order and populated it from another sales order (Functions > Copy from all in the header area of the Sales order/PurchTable form), the system did not copy the total discount percentage to the new header and the order was of the ‘Returned item’ type. This could cause an inconsistency between the sales order and the returned item order. The issue occurred because while populating a new sales table from another one, the DiscPercent field was not transferred at all. • Solution The code has been modified so that the total discount for the new order is populated from the original sales order when the original sales order has been invoice updated and the new order is of the ‘Returned item’ type. |
\Data Dictionary\Tables\SalesTable\Methods\initFromSalesTable \Data Dictionary\Tables\PurchTable\Methods\initFromPurchTable |
| #4253 | Not available | When the user created a purchase order from an already existing sales order for an item without the main vendor account specified for an item and then, in the Create purchase order form that appeared, selected the value in the Vendor account field, the Quantity field was set to ‘zero’. | • Problem When the user created a purchase order (Accounts receivable > Sales order > Functions > Create purchase order) from an already existing sales order for an item without the main vendor account specified for an item (Inventory management > Items > References > Vendor) and then, in the Create purchase order form that appeared, selected the value in the Vendor account field, the Quantity field was set to ‘zero’. This was only possible when the user opened the Create purchase order form for the first time. The issue occurred because of a mistake in the \Forms\VendAccountItemLookup\Methods\run method. • Solution The call of super() has been moved before this.setSelectMode() in the \Forms\VendAccountItemLookup\Methods\run method to correct the mistake. |
\Forms\VendAccountItemLookup\Methods\run |
| #4351 | Not available | When the Automatic reduction invoice check box was selected on the Updates tab of the Accounts receivable parameters form, the "Transaction has already been posted" error message appeared under certain circumstances during the invoice update. | • Problem When the Automatic reduction invoice check box was selected on the Updates tab of the Accounts receivable parameters form (Accounts receivable > Setup > Parameters), the "Transaction has already been posted" error message appeared under certain circumstances during the invoice update. The issue occurred because the UpdateNow method of the SalesFormLetter_Invoice class had an incorrect code sequence. There was a line with the continue command, which caused the while loop to continue without reading the next record. • Solution The code has been modified to skip the lines where Amount equals ‘0’ if the Automatic reduction invoice check box is selected. |
\Classes\SalesFormLetter_Invoice\updateNow |
| #5394 | Not available | The user could delete a customer even if a free text invoice was created for this customer. | • Problem The user could delete a customer even if a free text invoice was created for this customer. The issue occurred because the delete action was missing on the CustTable table. • Solution A new delete action has been created on the CustTable table to prohibit the deleting of a customer if a free text invoice has been created for this customer. |
\Data Dictionary\Tables\CustTable |
| #5413 | Not available | When the user set up a continuous number sequence for the EU Sales list form (Basic > Setup > Foreign trade > Intrastat parameters > Number sequences), then created a new record in the EU sales list form (Basic > Periodic > Foreign trade > EU sales list) and clicked the Transfer button, an error occurred because of the non-unique values of the Dispatch field. | • Problem When the user set up a continuous number sequence for the EU Sales list form (Basic > Setup > Foreign trade > Intrastat parameters > Number sequences), then created a new record in the EU sales list form (Basic > Periodic > Foreign trade > EU sales list) and clicked the Transfer button, an error occurred because of the non-unique values of the Dispatch field. The issue occurred because of code inaccuracies in the \Classes\EUSalesListTransfer and \Classes\EUSalesListTransferBE classes. • Solution The number sequence fetching routine for the dispatchId field has been modified. The seqNum field is initialized correctly now. |
\Classes\EUSalesListTransfer\run \Classes\EUSalesListTransferBE\run |
| #6156 | Not available | When users posted an invoice on a sales order where the invoice account differed from the order account, the Tax exempt number of the order account was printed on the invoice, but it should have been the Tax exempt number of the invoice account. | • Problem When users posted an invoice on a sales order where the invoice account differed from the order account, the Tax exempt number of the order account was printed on the invoice, but it should have been the Tax exempt number of the invoice account. The issue occurred because the VATNum field was not initialized in the initInvoiceAccount method of SalesTable. • Solution The code has been modified to transfer Tax exempt number and the other payment information. |
\Data Dictionary\Tables\SalesTable\Methods\initInvoiceAccount |
| #6434 | Not available | When the user created a release order from the blanket order with the Reservation field set to ‘Manual’ on the Setup tab of the Sales order form, the items of the newly created sales order were automatically reserved, although this should only be possible if the Reservation field is set to ‘Automatic’. | • Problem When the user created a release order (Accounts receivable > Sales order > Functions > Create release order) from the blanket order with the Reservation field set to ‘Manual’ on the Setup tab of the Sales order form, the items of the newly created sales order were automatically reserved, although this should only be possible if the Reservation field is set to ‘Automatic’. The issue occurred because of an incorrect check procedure in the \Classes\InventUpd_Estimated class. • Solution The code of the \Classes\SalesLineType class has been modified so that the \Classes\InventUpd_Estimated class is not called for orders that have references to the Blanket order and the manual reservation method. |
\Classes\SalesLineType |
| #7144 | Not available | The EU sales list report was filled with the delivery address instead of the invoice address. | • Problem The EU sales list report was filled with the delivery address instead of the invoice address. Therefore, if the user invoiced a US customer who has a delivery address in Germany, this address would have been transferred to the EU sales list report. The issue occurred because of a mistake in the code. • Solution The code has been modified so that the CustInvoiceJour.InvCountry field is now used instead of CustInvoiceJour.DlvCountry when transferring records to the EUSalesList table. Also, an additional check has been added to make sure that only EU addresses can be transferred to EUSalesList. |
\Classes\EUSalesListTransfer |
| #7401 | Not available | Values of the Vendor account and Quantity fields in the Create purchase order form were not updated after the query execution during the select operation (CTRL+F3) when new sales lines were retrieved. | • Problem Values of the Vendor account and Quantity fields in the Create purchase order form were not updated after the query execution during the select operation (CTRL+F3) when new sales lines were retrieved. The fieldsInitiated variable was equal to TRUE in \Forms\PurchCreateFromSalesOrder\Methods\select, which made update of the Vendor account and Quantity not possible for all sales lines in the Create purchase order form after the user executed the query during the select operation (CTRL+F3) when new sales lines were retrieved. • Solution The code has been modified so that the Vendor account field is initialized from the InventTable table and the Quantity field is initialized from the SalesLine table for all sales lines in the Create purchase order form. |
\Forms\PurchCreateFromSalesOrder\Methods\ClassDeclaration \Forms\PurchCreateFromSalesOrder\Methods\init \Forms\PurchCreateFromSalesOrder\Methods\insertMinMaxQty \Forms\PurchCreateFromSalesOrder\Methods\initFields \Forms\PurchCreateFromSalesOrder\Methods\select \Forms\PurchCreateFromSalesOrder\Methods\includeAll \Forms\PurchCreateFromSalesOrder\Data Sources\SalesLine\Methods\executeQuery \Classes\PurchCreateFromSalesOrder\querySalesLine |
| #8266 | Not available | The change of the sales order line amount was not considered in the total discount calculation. | • Problem The change of the sales order line amount was not considered in the total discount calculation. The issue occurred because the discount percent, as soon as it was calculated, did not change if the amounts changed. • Solution The code has been modified so that the total discount percent is set to ‘zero’ if the amount changes in a way that it does not meet the trade agreement discount settings. |
\Forms\PurchTable\Designs\Design\[Group:Line]\[ButtonGroup:ButtonLine]\[MenuButton:ButtonLineDiscCalc]\Button:EndDisc\Methods\clicked \Data Dictionary\Maps\PriceDiscHeading\Methods\updateFinalDisc |
| #8822 | Not available | Multiple "Error executing code: Overflow in internal run stack." error messages appeared when the user tried to open the Transaction Code window from a form in Microsoft Dynamics AX 3.0 by using the Go to the Main Table functionality. | • Problem Multiple "Error executing code: Overflow in internal run stack." error messages appeared when the user tried to open the Transaction Code window from a form in Microsoft Dynamics AX 3.0 by using the Go to the Main Table functionality. The issue occurred only when the Transaction code field on the Other tab in the lines area in the Purchase order form was not empty. The issue occurred because the AutoQuery property of the IntrastatTransactionCode form was always set to ‘No’. • Solution The AutoQuery property on the TransactionCode data source of the IntrastatTransactionCode form has been changed so that the query used to generate the form is not automatically created (AutoQuery set to ‘Yes’). |
\Forms\IntrastatTransactionCode\Data Sources\TransactionCode |
| #8882 | Not available | When the user tried to create a production order from a sales line with the ‘BOM’ item type and inventory dimension, which included Serial number, the values of the Serial number inventory dimension were not passed to the Create production order form. | • Problem When the user tried to create a production order from a sales line with the ‘BOM’ item type and inventory dimension, which included Serial number, the values of the Serial number inventory dimension were not passed to the Create production order form. The issue occurred because of a mistake in the \Data Dictionary\Tables\ProdTable\Methods\initFromSalesLine class. • Solution The \Data Dictionary\Tables\ProdTable\Methods\initFromSalesLine method has been modified. When a production order is created, all non-empty dimension values are passed to the corresponding field of InventDim linked to ProdTable. Also, the \Data Dictionary\Tables\ProdTable\Methods\initFromProdBOM method has been modified with the same logic. When the BOM line is of the ‘Production’ item type and the main BOM is estimated, the production order for the BOM line is created with all dimensions passed, which are specified in the BOM line. Also, after the ProdTable record is created from SalesLine in the \Classes\InventUpd_Estimated\createEstimatedInventTrans method, the marking in the InventTrans.InventRefTransId field for the SalesLine transaction related to the ProdTable transaction is filled in and the reservation for the SalesLine transaction is performed. After these changes, the InventTrans record for the corresponding SalesLine has the same InventTrans.DimenisonId as the ProdTable transaction record, and has a reference to that record, InventTrans.StatusIssue is set to ‘Reserved ordered’. |
\Classes\InventUpd_Estimated\createEstimatedInventTrans \Data Dictionary\Tables\ProdTable\Methods\initFromSalesLine \Data Dictionary\Tables\ProdTable\Methods\initFromProdBOM |
| #8898 | Not available | When the user created a sales order, posted a picking list with the Set inventory transactions to ‘Picked’ check box cleared in the Accounts receivable parameters form, and after that decided to change the item dimensions in the sales order line, deleted the existing picking list and posted another picking list, the updated item dimensions were not reflected in the Picking list registration form. | • Problem When the user created a sales order, posted a picking list with the Set inventory transactions to ‘Picked’ check box cleared in the Accounts receivable parameters form, and after that decided to change the item dimensions in the sales order line, deleted the existing picking list and posted another picking list, the updated item dimensions were not reflected in the Picking list registration form. The issue occurred because there was no check made before saving the changes in the order line. SalesLine was updated, but InventTrans was not, which led to an inconsistency between SalesLine and InventTrans. • Solution The code has been modified to forbid changing dimensions after the picking list has been posted. Therefore, if dimensions on the sales order line are to be changed when a picking list is already posted, the user should delete the existing picking list first and then change dimensions in the new picking list. |
\Data
Dictionary\Tables\SalesLine\validateModifyItemDim \Classes\SalesLineType\validateModifyItemDim \Forms\SalesTable\Data Sources\InventDim\Fields\inventBatchId\Methods\validate \Forms\SalesTable\Data Sources\InventDim\Fields\wMSLocationId\Methods\validate \Forms\SalesTable\Data Sources\InventDim\Fields\wMSPalletId\Methods\validate \Forms\SalesTable\Data Sources\InventDim\Fields\InventSerialId\Methods\validate \Forms\SalesTable\Data Sources\InventDim\Fields\InventLocationId\Methods\validate \Forms\SalesTable\Data Sources\InventDim\Fields\ConfigId\Methods\validate \Forms\SalesTable\Data Sources\InventDim\Fields\InventSizeId\Methods\validate \Forms\SalesTable\Data Sources\InventDim\Fields\InventColorId\Methods\validate |
| #8907 | KB895917 | During payment scheduling, TradeTotals.calc() returned
lineAmount equal to ‘0’ because the lines were already posted and
unitQty also equals to ‘0’. Logically, the invoice amount was also equaled to ‘0’ and payment scheduling was performed only for the miscellaneous charges amount. Therefore, validation between the scheduled amount and invoice amount failed and an error message appeared. The issue with payment scheduling occurred during the free text invoice posting when miscellaneous charges had the Keep check box cleared. The markup transaction was deleted from the MarkupTrans table before the payment scheduling algorithm started. Logically, the miscellaneous charges amounts are not considered during payment scheduling. |
• Problem During payment scheduling, TradeTotals.calc() returned lineAmount equal to ‘0’ because the lines were already posted and unitQty also equaled to ‘0’. Logically, the invoice amount was also equal to ‘0’ and payment scheduling was performed only for the miscellaneous charges amount. Therefore, validation between the scheduled amount and invoice amount failed and an error message appeared. The same issue occurred if misc.charges were applied for lines or were not applied at all. In both cases payment lines were incorrectly calculated for SalesTable. The issue with payment scheduling occurred during the free text invoice posting when miscellaneous charges had the Keep check box cleared. The markup transaction was deleted from the MarkupTrans table before the payment scheduling algorithm started. Logically, the miscellaneous charges amounts are not considered during payment scheduling. • Solution The code has been modified to calculate the payment schedule before the sales lines are posted. This also considers the user’s modifications of the payment schedule in the Sales order/Posting invoice forms. The payment schedule is not calculated for credit notes. Also, the payment scheduling is performed before the deletion of the misc. charges transaction from the MarkupTrans table. |
\Classes\SalesFormLetter_Invoice\createPaymentSched \Classes\SalesFormLetter_Invoice\ copyPaymentSched \Classes\SalesFormLetter_Invoice\updateNow \Tables\SalesTable\copyPaymentSched \Tables\CustInvoiceJour\validatePaymentSched \Data Dictionary\Tables\VendPaymSched\Methods\validateWrite \Data Dictionary\Tables\CustPaymSched\Methods\validateWrite \Data Dictionary\Tables\PaymSched\Methods\validateWrite \Classes\CustPostInvoice\run |
| #8908 | KB899006 | When users created a sales release order from a blanket order, the
delivery date was specified for each line on the Release order
form. This date was the delivery date for the created sales line. When the
released sales order was of the intercompany type, a purchase order was
automatically created as a mirror of the sales order. The issue was that the delivery date on the created purchase line was taken from the purchase header and not from the sales line. Instead, the sales line delivery date was specified in the Confirmed delivery date field of the purchase line. |
• Problem When users created a sales release order from a blanket order, the delivery date was specified for each line on the Release order form. This date was the delivery date for the created sales line. When the released sales order was of the intercompany type, a purchase order was automatically created as a mirror of the sales order. The issue was that the delivery date on the created purchase line was taken from the purchase header and not from the sales line. Instead, the sales line delivery date was specified in the Confirmed delivery date field of the purchase line. The issue occurred because an incorrect delivery date was copied during the intercompany mirroring. • Solution The code has been modified to use axPurchLine.DeliveryDate instead of axPurchLine.confirmedDlv in the \Classes\ SalesLineType\interCompanyMirror method. |
\Classes\SalesLineType\interCompanyMirror \Data Dictionary\Tables\PurchLine\Methods\interCompanyUpdateNow \Classes\PurchLineType\interCompanyMirror |
| #8909 | KB899267 | An incorrect posting profile was used when the user invoice updated a purchase order by using the Invoice approval journal. This occurred when the posting profile was changed when posting the Invoice register journal. | • Problem An incorrect posting profile was used when the user invoice updated a purchase order by using the Invoice approval journal. This occurred when the posting profile was changed when posting the Invoice register journal. The correct posting profile was not obtained in the InitJournal method of the PurchFormLetter_ApproveJournal class. In this case the posting profile had an empty value, and the system used the default posting profile from the parameters of the Accounts payable module. The posting profile from the header of the purchase order and posting profile from the parameters were different in this case. Therefore, an incorrect summary account from the default posting profile was used when updating a purchase order by using the Invoice approval journal. • Solution The logic of updating a purchase order by using the Invoice approval journal has been corrected. |
\Classes\PurchFormLetter_ApproveJournal\InitJournal |
| #8912 | KB899346 | When the user deleted all sales order lines from a sales order with a number that was not the highest number, the focus moved to the sales order with the highest number. | • Problem When the user deleted all sales order lines from a sales order with a number that was not the highest number, the focus moved to the sales order with the highest number. When the user deleted all sales order lines in the SalesTable form, the delete() method of the SalesLine data source called the research() method for the SalesTable data source that refreshed all records on this data source. After this the focus was moved to the last record in the form. • Solution Modifications have been made so that users are never moved to a different sales order when they delete a sales order line. |
\Forms\SalesTable |
| #8913 | KB900328 | It was possible to post the invoice before the packing slip when users posted a packing slip on an intercompany sales order and afterward posting an invoice based on the packing slip. | • Problem It was possible to post the invoice before the packing slip when users posted a packing slip on an intercompany sales order and afterward posting an invoice based on the packing slip. Therefore, the physical inventory posting doubled and the quantity received was doubled in the purchase order. The InterCompanyUpdateAllowed method of the CustInvoiceJour table is used to determine whether invoice posting is enabled or not. The issue occurred because there was no check performed in this method if a related packing slip that had not been updated was present. • Solution A check has been added in the InterCompanyUpdateAllowed method to determine whether a related packing slip that is not posted is present. |
\Data Dictionary\Tables\CustInvoiceJour |
| #8914 | KB897236 | The Bar code information was not updated correctly in the sales line if a configurable item (with Configuration specified) was used. | • Problem The Bar code information was not updated correctly in the sales line if a configurable item (with Configuration specified) was used. In the \Data Dictionary\Tables\InventItemBarcode\Methods\findItemId method, the Bar code information was only found if an item had no dimensions specified (inventDimId was blank). • Solution The Bar code information for an item is found and updated by using the created \Data Dictionary\Tables\ InventItemBarcode\Methods\findSalesBarcodeDimensions method and considering item dimensions specified. Also, the Bar code information is updated for an item if item dimensions are changed after creation of the sales line. The same issue with bar codes has been resolved for the configured items in purchase orders. |
\Data
Dictionary\Tables\InventItemBarcode\Methods\findSalesBarcodeDimensions \Data Dictionary\Tables\InventItemBarcode\Methods\findPurchBarcodeDimensions \Data Dictionary\Tables\SalesLine\Methods\initBarcode \Data Dictionary\Tables\PurchLine\Methods\initBarcode \Data Dictionary\Tables\SalesLine\Methods\initItemDim \Data Dictionary\Tables\PurchLine\Methods\initItemDim \Classes\SalesLineType\initFromInventTable \Classes\PurchLineType\initFromInventTable |
| #8915 | KB900408 | An intercompany purchase order and marked purchase order did not reflect changes in the original sales order. | • Problem An intercompany purchase order and marked purchase order did not reflect changes in the original sales order. • Solution Only the Intercompany functionality is supposed to reflect the change in the original (source) sales order for the intercompany purchase order by design. Users can show a warning message about the presence of the marked purchase order to the users when they try to change the original (source) sales order. Therefore, users can manually change the marked purchase order if there is a need. |
\Data
Dictionary\Tables\SalesLine\Methods\referenceWarningTxtFieldModified \Data Dictionary\Tables\SalesLine\Methods\warningForReferenceFieldModified \Data Dictionary\Tables\PurchLine\Methods\referenceWarningTxtFieldModified \Data Dictionary\Tables\PurchLine\Methods\warningForReferenceFieldModified \Classes\SalesLineType\validateWrite \Classes\PurchLineType\validateWrite |
| #9068 | Not available | If the user sorted customers by name in \Reports\SalesCustItemStatistics, customers were sorted per period and not as a total list of customers. | • Problem If the user sorted customers by name in \Reports\SalesCustItemStatistics, customers were sorted per period and not as a total list of customers. The issue occurred because the system prepared two sets of invoice transactions (for the first and the second period) and then processed it simultaneously sorting by OrderAccount in \Reports\SalesCustItemStatistics\Methods\fetch. • Solution One common set of invoice transactions is formed, instead of two sets in \Reports\SalesCustItemStatistics\Methods\fetch, and then sequentially processed. This enables the sorting of customers by an arbitrary field from the CustTable table. |
\Reports\SalesCustItemStatistics\Methods\ClassDeclaration \Reports\SalesCustItemStatistics\Methods\fetch \Reports\SalesItemCustStatistics\Methods\ClassDeclaration \Reports\SalesItemCustStatistics\Methods\fetch |
| #10171 | Not available | Incorrect line number values were inserted while adding supplementary items in the sales order with several sales lines by clicking Calculation > Supplementary items. Also, the sorting order of the items was incorrect. | • Problem Incorrect line number values were inserted while adding supplementary items in the sales order with several sales lines by clicking Calculation > Supplementary items. Also, the sorting order of the items was incorrect. The issue was caused by an error in the \Data Dictionary\Maps\SalesPurchLine\Methods\nextLineNum method where the next line number value was calculated incorrectly and in the \Classes\SuppItemCreate\run method where the sorting order of lines was incorrect. • Solution The code in the \Data Dictionary\Maps\SalesPurchLine\Methods\nextLineNum and \Classes\SuppItemCreate\run methods has been corrected. |
\Data Dictionary\Maps\SalesPurchLine \Classes\SuppItemCreate |
| #10257 | Not available | A record in the CustTable table for a one-time customer was created before the appropriate record in the CustInvoiceTable table, which prevented CustTable being populated with customer data from the Free text invoice form. | • Problem A record in the CustTable table for a one-time customer was created before the appropriate record in the CustInvoiceTable table, which prevented CustTable being populated with customer data (Name and Address) from the Free text invoice form (Accounts receivable > Free text invoice). The issue occurred because the address information was not updated in the CustTable table record for a one-time customer when a record was inserted in the CustInvoiceTable table. • Solution The code has been modified to update the address information in the CustTable table record for a one-time customer when a record is inserted in the CustInvoiceTable table. |
\Data
Dictionary\Tables\CustTable\Methods\initFromCustInvoiceTable \Data Dictionary\Tables\CustInvoiceTable\Methods\insert \Data Dictionary\Tables\CustInvoiceTable\Methods\transferToOnetimeCustomer |
| #12089 | KB907255 | If there were many sales orders in the system, clicking the Post button in the Sales order form took a long time to display the associated menu items. Also, incorrect menu items could be displayed. | • Problem If there were many sales orders in the system, clicking the Post button in the Sales order form took a long time to display the associated menu items. Also, incorrect menu items could be displayed. The issue occurred because of incorrect where condition on the select statement in the \Classes\SalesTableType\checkSalesQty method. • Solution The where condition has been corrected in the \Classes\SalesTableType\checkSalesQty method. |
\Classes\SalesTableType\sheckSalesQty |
| #12879 | Not available | When the user upgraded Microsoft Dynamics AX 3.0 from Service Pack 3 to Service Pack 6 an error occurred if there were returned goods (negative quantity) marked as scrap. | • Problem When the user upgraded Microsoft Dynamics AX 3.0 from Service Pack 3 to Service Pack 6 an error occurred if there were returned goods (negative quantity) marked as scrap. The issue occurred because of a mistake in the updateSalesLine() method of the ReleaseUpdateDB_V30toV30SP class. • Solution The code has been modified so that when processing inventory transactions, the system skips records if they do not have the respective inventory transaction, because scarp lines no longer have an inventory transaction. |
\Classes\ReleaseUpdateDB_V30toV30SP\updateSalesLine |
| #13416 | Not available | When users created a purchase order from a sales order, the transaction code from the sales order header and lines was not copied to the new purchase order. The transaction code was not copied also when the intercompany purchase order or sales order was created. | • Problem When users created a purchase order from a sales order (Accounts receivable > Sales order > Functions > Create purchase order), the transaction code (the Other tab, Foreign trade group) from the sales order header and lines was not copied to the new purchase order. The transaction code was not copied also when the intercompany purchase order or sales order was created. The issue occurred because the transaction code was not initialized when a purchase order was created from a sales order or the intercompany sales order or purchase order was created. • Solution The code has been adjusted to correctly initialize transaction code when a purchase order is created by using the sales order and the intercompany purchase order or sales order is created. |
\Data Dictionary\Tables\PurchLine\Methods\initFromSalesLine \Data Dictionary\Tables\PurchTable\Methods\initFromSalesTable \Data Dictionary\Tables\SalesLine\Methods\interCompanyUpdateNow \Data Dictionary\Tables\SalesTable\Methods\interCompanyUpdateNow \Data Dictionary\Tables\PurchLine\Methods\interCompanyUpdateNow \Data Dictionary\Tables\PurchTable\Methods\interCompanyUpdateNow \Classes\PurchLineType\interCompanyMirror \Classes\PurchTableType\interCompanyMirror \Classes\SalesLineType\interCompanyMirror \Classes\SalesTableType\interCompanyMirror |
| #13421 | Not available | An incorrect Infolog error message appeared when the user posted a picking list with a quantity more than the ordered one even if the over-delivery was allowed and the quantity was within the over-delivery percentage range. | • Problem An incorrect Infolog error message appeared when the user posted a picking list with a quantity more than the ordered one even if the over-delivery was allowed and the quantity was within the over-delivery percentage range. • Solution Modifications have been made so that the appropriate error message ("Insufficient inventory transactions") is used for both picking procedures. Over-delivery and picking can be achieved by using the picking list registration process (two-step picking). The registration accepts larger quantities (up to the allowed percentage). |
\Classes\SalesFormLetter_PickingList \Classes\SalesFormLetter_PickingListJournal |
| #13449 | Not available | Records in the EU sales list report could be duplicated. | • Problem Records in the EU sales list report could be duplicated. Every time that the system added a record to the EUSalesList table it set the EUSalesList field of the custInvoiceJour (or projInvoiceJour) table to ‘dispatchID’. This ID showed that the record had already been transferred to EUSalesList, but this was disregarded during the next transfers. • Solution To make duplicating not possible, one more method has been added and now a new EUSalesList record is only created provided the custInvoiceJour (or projInvoiceJour) field of EUSalesList is blank. To make sure that the mechanism is functioning correctly, code has been added to blank the respective EUSalesList fields of the custInvoiceJour (or projInvoiceJour) table while deleting the records from the EUSalesList table. |
\Data Dictionary\Tables\EUSalesList\Methods\clearReferences \Data Dictionary\Tables\EUSalesList\Methods\delete \Classes\EUSalesListTransfer\loadFromCustInvoiceJour \Classes\EUSalesListTransfer\loadFromProjInvoiceJour |
| #13993 | Not available | The external code was not deleted when the user deleted a customer, which resulted in orphan records in that table. | • Problem The external code was not deleted when the user deleted a customer, which resulted in orphan records in that table. When users deleted a record in CustTable, child records in ExtCodeValueTable were not deleted. The same issue occurred with the certain number of the tables, namely ZipCode, VendTable, Unit, State, MarkupTable, InventTable, InventDimCombination, DlvTerm, DlvMode, CustTable, County, Currency, Country, and CompanyInfo. • Solution A DeleteAction of the cascade type has been added on each of the previously listed tables. |
\Data Dictionary\Tables\ZipCode \Data Dictionary\Tables\VendTable \Data Dictionary\Tables\Unit \Data Dictionary\Tables\State \Data Dictionary\Tables\MarkupTable \Data Dictionary\Tables\InventTable \Data Dictionary\Tables\InventDimCombination \Data Dictionary\Tables\DlvTerm \Data Dictionary\Tables\DlvMode \Data Dictionary\Tables\CustTable \Data Dictionary\Tables\County \Data Dictionary\Tables\Currency \Data Dictionary\Tables\Country \Data Dictionary\Tables\CompanyInfo |
| #14018 | Not available | In some cases the Sales order form was blocked immediately after it opened. | • Problem In some cases the Sales order form was blocked immediately after it opened. This occurred if an invoiced sales order was the last entry in the sales order area and, in the Accounts receivable parameters form, Safety level of invoiced orders was set to ‘Locked’, Check credit limit for sales order was set to ‘Header’ and miscellaneous charges that had the Keep check box selected and Category set to ‘Fixed’ was applied. The issue occurred because the \Forms\SalesTable\Data Sources\SalesTable\Methods\active method analyzed creditLineCheck of custParameter and if its value was ‘Head’, then the salesTable.estimate field was calculated. When salesTable was updating the validateWrite method and returned the FALSE value and the last entry in the salesTable grid was invoiced, the Sales order form was blocked. • Solution The code has been modified to prevent the blocking of the Sales order form. |
\Forms\SalesTable |
| #15063 | Not available | An SQL error occurred when the user tried to locate the sales order attached to the blanket order if there were more than seven hundred sales orders associated to this blanket order. | • Problem An SQL error occurred when the user tried to locate the sales order attached to the blanket order by clicking Inquiries > Attached sales orders if there were more than seven hundred sales orders associated to this blanket order. The issue occurred because the database has upper limits for the size of where clauses. Also, the current business logic added the OR condition to the query for every release order attached to a blanket order. • Solution The query has been modified to use the exists join construction. |
\Classes\SalesTableForm_Links\querySalesTable |
| #16336 | Not available | If the user posted a proforma picking list, the deliver remainder quantity on a sales order was changed incorrectly. | • Problem If the user posted a proforma picking list, the deliver remainder quantity on a sales order was changed incorrectly. The issue occurred because a call of the subSalesLineRemain method is needed in the delete method of the SalesPickingListJournalLine table to update the deliver remainder quantities, but, if picking list proforma was posted, no actual update occurred. • Solution A condition has been added to make sure that the quantities on the sales line are updated only when physical posting is performed. |
\Data Dictionary\Tables\SalesPickingListJournalLine |
| #16974 | Not available | An Infolog message contained unrelated information when the user created a credit note for the invoiced sales order if the specified quantity exceeded the possible quantity. | • Problem An Infolog message contained unrelated information when the user created a credit note for the invoiced sales order if the specified quantity exceeded the possible quantity. The issue occurred because an exception was not intercepted in the X code and therefore created a critical stop error in \Forms\SalesCopying\Methods\canClose. • Solution To avoid a critical stop error, an exception is processed in the try/catch block of code. |
\Forms\SalesCopying\Methods\canClose \Forms\PurchCopying\Methods\canClose \Classes\SalesTotals\ShowTaxLine \Classes\PurchTotals\ShowTaxLine |
| #17200 | Not available | After the sorting of the Description field, the next line number for the CustInvoiceLine table was identical to the one of the already existing line numbers. Therefore, a free text invoice could not be posted. | • Problem After the sorting of the Description field, the next line number for the CustInvoiceLine table was identical to the one of the already existing line numbers. Therefore, a free text invoice could not be posted. The issue occurred because of a mistake in the mechanism of assigning new line numbers for the CustInvoiceLine table. • Solution A new method has been created to make sure that a newly assigned line number is unique. |
\Data
Dictionary\Tables\CustInvoiceLine\Methods\nextLineNum \Forms\CustFreeInvoice\Data Sources\CustInvoiceLine\Methods\write |
| #17324 | Not available | The Return Lot Id was not considered during the receipt physical update. | • Problem The Return Lot Id was not considered during the receipt physical update. Therefore, an incorrect physical amount was posted in inventory and ledger, ledger posting on physical accounts was missing if no inventory price was specified for an item, and a difference appeared between the financial amount and physical amount. The issue occurred because the system took the cost price for an item in \Classes\InventMovement\estimatedFinancialValue. • Solution The code has been modified to apply the same update logic as during the return financial update. |
\Classes\InventMov_Sales\estimatedPhysicalValue \Classes\InventUpd_Physical\updateTransPhysicalReturnedReceipt |
| #17678 | Not available | When the user created an intercompany sales or purchase order, the Posting profile and Transaction code fields were not populated from the parameters to the destination order. | • Problem When the user created an intercompany sales or purchase order, the Posting profile and Transaction code fields were not populated from the parameters to the destination order. The issue was caused by an incorrect (or absent) functionality that passed the posting profile and transaction code to the sales/purch tables. • Solution The AxPurchTable and AxSalesTable classes where the sales/purch tables are initialized have been corrected. |
\Classes\AxPurchTable\setPostingProfile \Classes\AxPurchTable\setTransactionCode \Classes\AxSalesTable\setTableFields \Classes\AxSalesTable\setTransactionCode \Classes\AxSalesTable\setPostingProfile |
| #17733 | KB921051 | The "Cannot edit a record in Sales orders (SalesTable). Another user changed one or more fields in the record, or the Form has not selected all fields. Use Restore on the Command menu to get the new value" error message appeared when the user changed the record in the sales order header by using two client sessions. | • Problem The "Cannot edit a record in Sales orders (SalesTable). Another user changed one or more fields in the record, or the Form has not selected all fields. Use Restore on the Command menu to get the new value" error message appeared when the user changed the record in the sales order header. This happened when another user previously updated the mentioned order (for example, packing slip update) from another client. Also, the Check credit limit for sales order parameter was set to ‘Header’ and Credit limit type was set to ‘Balance’ in the Accounts receivable parameters form. The issue occurred because of a conflict between the clients when one client has the outdated data and tries to update the record that was already changed by another client. • Solution The code has been modified to reread the record before making it active during the record update. |
\Forms\SalesTable\Data
Sources\SalesTable\Methods\active \Forms\SalesTable\Data Sources\SalesTable\Methods\validateWrite |
| #17776 | Not available | When users posted intercompany invoices (Sales order > Inquiries > Invoice > Intercompany > Invoice posting) from an intercompany sales order invoice with more that six hundred sales order lines, the "Cannot select a record in Purchase table... " SQL error message appeared. | • Problem When users posted intercompany invoices from an intercompany sales order invoice, the system constructed an SQL query adding ranges on PurchLine InventTransId (for each needed PurchLine). If many PurchLines were processed (many ranges were added), this led to an inadmissibly large query which could not be handled. The issue was caused by adding too many ranges on PurchLine InventTransId (for example, number of lines was six hundred) in \Data Dictionary\Tables\CustInvoiceJour\Methods\interCompanyUpdate method. • Solution The code has been corrected in the \Data Dictionary\Tables\CustInvoiceJour\Methods\interCompanyUpdate method to avoid using an SQL statement that is so large. |
\Data
Dictionary\Tables\CustInvoiceJour\Methods\interCompanyUpdate \Data Dictionary\Tables\CustPackingSlipJour\Methods\interCompanyUpdate |
| #17988 | KB922094 | When the value of the Direction field was not specified in the Compression of Intrastat setup, the compression functionality merged records from the Intrastat form with the different Direction values. | • Problem When the value of the Direction field was not specified in the Compression of Intrastat setup, the compression functionality merged records from the Intrastat form with the different Direction values. The issue was caused by the incomplete determination of the Direction field for a new Intrastat record in the \Classes\IntrastatCompression\createNewIntrastat method, when expWeight and impWeight were not calculated. • Solution The formula to determine the Direction field value when expWeight and impWeight are not calculated has been corrected in the \Classes\IntrastatCompression\createNewIntrastat method. |
\Classes\IntrastatCompression\createNewIntrastat |
| #17993 | KB922598 | The current return cost price was lost when updating the quantity on the sales order line. | • Problem The current return cost price was lost when updating the quantity on the sales order line. The \Classes\SalesLineType\initSalesQty method was called when updating the quantity and the cost price was set to zero inside this method never being restored. • Solution The return cost price is specified if the quantity on a sales line is negative. The cost price is taken from the item table, because at this point it seems unreasonable to recalculate the cost price based on the actual quantity and on-hand value (instead of the posting stage). |
\Classes\SalesLineType\initSalesQty |
| #19104 | KB925689 | When the user manipulated (updated) Return Lot ID on a sales line, Return Lot ID was not saved correctly in InventTrans. | • Problem When the user manipulated (updated) Return Lot ID on a sales line, Return Lot ID was not saved correctly in InventTrans. Modified Return Lot ID was not taken correctly from the sales line. That is why when the user changed Return Lot ID on the sales line in \Data Dictionary\Tables\InventTrans\Methods\updateTransIdReturn method, Return Lot ID was taken for analysis from the InventTrans record and not from the sales line. • Solution The \Classes\InventUpd_Estimated\updateFieldsChange method has been corrected to provide the mechanism of updating InventTrans with a new value of Return Lot ID. |
\Classes\InventUpd_Estimated\updateFieldsChange \Classes\InventUpd_Estimated\createEstimatedInventTrans |
| #19107 | KB925021 | The value of the Delivery remainder field became incorrect after two partial deliveries and one return. | • Problem The value of the Delivery remainder field (the Quantity tab in the lines area) became incorrect after two partial deliveries and one return. The issue occurred because an incorrect value of RemainSalesPhysical (the SalesLine table) – Delivery remainder on the Quantity tab for a sales line and Qty (the InventTrans table) was populated from the RemainAfter and RemainAfterInvent fields of the SalesParmLine table. • Solution The appropriate corrections have been made in the \Classes\SalesQuantity_Invoice class for methods \Classes\SalesQuantity_Invoice\calcQtyInvent and \Classes\SalesQuantity_Invoice\calcQtySales, which calculate RemainAfter and RemainAfterInvent respectively, to calculate these figures correctly and taking into consideration invoice returns. |
\Classes\SalesQuantity_Invoice\calcQtyInvent \Classes\SalesQuantity_Invoice\calcQtySales \Classes\PurchQuantity_Invoice\calcQtyInvent \Classes\PurchQuantity_Invoice\calcQtyPurch \Forms\SalesEditLines\Data Sources\SalesParmUpdate\Fields\CreditRemaining\Methods\modified |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description | ||||||||||||||||||
| #1470 | Not available | It was not possible to search and filter records in the Batch lookup combo box. | • Problem It was not possible to search and filter records in the Batch lookup combo box. The issue occurred because during the check performed in the \Forms\InventBatchIdLookup\Data Sources\InventBatch\Methods\executeQuery method the exeQueryBatch variable after the first execution always had the TRUE value. • Solution The line of code blocking the following execution of the ExecuteQuery() method in the InventBatch and InventDim tables after the first execution has been removed. |
\Forms\InventBatchIdLookup\Data
Sources\InventBatch\Methods\executeQuery \Forms\InventBatchIdLookup\Data Sources\InventDim\Methods\executeQuery | ||||||||||||||||||
| #2130 | Not available | When the Inventory by inventory dimension aging report was run with a range set for the Warehouse field of the Inventory dimensions table on the Range tab, the report appeared empty. | • Problem When the Inventory by inventory dimension aging report (Inventory management > Reports > Status > Inventory by inventory dimension aging) was run with a range set for the Warehouse field of the Inventory dimensions table on the Range tab, the report appeared empty. However, the report ran correctly when the user selected the Group totals check box for this dimension. The \Reports\InventAgeDim report contains two data sources: InventDim and tmpInventAge(TmpInventAge) that are inner joined through the InventDim.inventDimId == TmpInventAge.inventDimId relation. The report is initialized and called from the InventReport_AgeDim extends InventReport_Age class. The issue occurred because of mistakes in the code of the \Classes\InventReport_AgeDim\calcAll method. The method initialized the query without considering the user’s ranges input. Therefore, the records for the TmpInventAge data source were collected with an incorrect inventDimId value, which resulted in an empty final join for the report. • Solution The new initFromQueryBuildRange(QueryBuildDataSource _queryBuildDataSource) method has been introduced in the InventDimParm table. This method goes through QueryBuildDataSource passed as a parameter and initializes InventDimParm according to the usage of the data source ranges. This method is called in \Classes\InventReport_AgeDim\calcAll to initialize the report query correctly. |
\Classes\InventReport_AgeDim\calcAll \Data Dictionary\Tables\InventDimParm\Methods\initFromQueryBuildRange | ||||||||||||||||||
| #2343 | Not available | Financial dimensions were not copied to the stock transaction table when declaring scrap in quarantine orders. | • Problem Financial dimensions were not copied to the stock transaction table when declaring scrap in quarantine orders. The issue occurred because of the \Classes\InventMov_Vir_QuarantineLoss\ Dimension method where the financial dimension was copied from InventTable for an item specified in the quarantine order. • Solution The codes in the \Classes\InventQuarantineOrder_Scrap and \Classes\InventMov_Vir_QuarantineLoss have been modified so that financial dimensions are copied from the quarantine order to the transaction table. |
\Classes\InventQuarantineOrder_Scrap \Classes\InventMov_Vir_QuarantineLoss | ||||||||||||||||||
| #3273 | Not available | When the user created a release order based on a blanket order, which had a vendor account that differed from the invoice account, the Invoice account field was not filled in correctly in the released purchase order. | • Problem When the user created a release order based on a blanket order, which had a vendor account that differed from the invoice account, the Invoice account field was not filled in correctly in the released purchase order. The issue occurred because the PurchAutoCreate class had the setPurchTable method, which initialized fields from the PurchTable table while InvoiceAccount received the account number from the VendTable table. • Solution The code has been modified so that the invoice account number is obtained from the purchTable table. |
\Classes\PurchAutoCreate \Classes\PurchAutoCreate_tmpPurchLine \Classes\PurchAutoCreate_Sales | ||||||||||||||||||
| #3482 | Not available | The Accounts receivable > Sales order > Inventory > On-hand > Items on order > Inventory > Dimension display feature did not work in the Item on order form. | • Problem The Accounts receivable > Sales order > Inventory > On-hand > Items on order > Inventory > Dimension display feature did not work in the Item on order form. The issue concerned the InventDimParmFixed form initialization. The inventDimSetupObject method was not initialized from the InventTransOnOrder form in the InventDimSetupObject class. • Solution The Inventory button has been removed from the Item on order form. |
\Forms\ InventTransOnOrder | ||||||||||||||||||
| #4199 | Not available | An uninformative message appeared if one of the ledger accounts to be updated during the inventory closing was not specified on an item. | • Problem An uninformative message appeared if one of the ledger accounts to be updated during the inventory closing was not specified on an item. There was no additional information about what item/item group caused this error, which means that in big databases, it is very difficult to find the item and continue closing/recalculation. The LedgerVoucherTransObject.check() showed an error message if ledger account was not specified. It was done on the stage of ledger posting when transactions were already adjusted. That is why it was not possible to recognize the item where the account was not specified. • Solution The code has been modified to call LedgerVoucherTransObject.checkData() on the inventory side (in the InventAdjustPost class) when LedgerVoucher is only being prepared. The same check has been implemented for the inventory journals validation. |
\Classes\InventAdjustPost\updateNow \Classes\InventAdjustPost\addLedger | ||||||||||||||||||
| #4261 | Not available | In the On-hand forms, a zero cost price was displayed if a combination cost price was used. However, if the Use combination cost price check box was selected for an item, the standard cost price was displayed. | • Problem In the On-hand forms, a zero cost price was displayed if a combination cost price was used. However, if the Use combination cost price check box was selected for an item, the standard cost price was displayed. When the system called the averageCostPriceUnit display method of either the InventOnhandItem, InventOnhandMovement or InventOnhandReserve form, the value of the InventDimId field was empty. Therefore, it was not possible to find a combination cost price without the correct item dimensions. While the InventDimId field was empty in the averageCostPriceUnit method of either the InventOnhandItem, InventOnhandMovement or InventOnhandReserve form, it was not possible to find the correct dimensions and the combination cost price for an item. In this case the value of the combination cost price was zero in the On-hand forms. • Solution The correct InventDimId value has been included in the averageCostPriceUnit method of the InventOnhandItem, InventOnhandMovement, and InventOnhandReserve forms (for the InventOnhandReserve form, two new methods have been added to the InventSum data source: the averageCostPriceUnit display method and the InventDim method. Also the DataMethod property for the CostPricePcs field has been changed). When the system calls the averageCostPriceUnit display method, the system has values for item dimensions. Using item dimensions helps find the correct InventDimId value and pass it to the costPricePcs method. |
\Forms\InventOnhandItem\Data
Sources\InventSum\Methods\averageCostPriceUnit \Forms\InventOnhandReserve\Data Sources\InventSum\Methods\averageCostPriceUnit \Forms\InventOnhandReserve\Data Sources\InventSum\Methods\inventDim \Forms\InventOnhandReserve\Designs\Design\[Tab:Tab]\[TabPage:Onhand]\[Group:InventOnHand]\RealEdit:CostPricePcs \Forms\InventOnhandMovement\Data Sources\InventSum\Methods\averageCostPriceUnit | ||||||||||||||||||
| #4438 | Not available | When the user was going to post and print a picking list from the sales order and selected the Reservation check box on the Other tab of the Posting picking list form, the system ordered these two actions in an incorrect way. | • Problem When the user was going to post and print a picking list from the sales order and selected the Reservation check box on the Other tab of the Posting picking list form, the system ordered these two actions in an incorrect way. The first command was to create and print the picking list and the second to reserve items. Because of that, when the user updated the picking list for the first time, there was only one line generated in the Picking list form. However, if the user cleared the Posting check box and then posted, the user would have a regular picking list at the second time. The issue occurred because the SalesPickingListJournalLine table was updated from the InventTrans table before the latter was updated (split) itself. • Solution The InventTrans transactions have been split for the insert() method of the SalesPickingListJournalLine table before creating the corresponding SalesPickingListJournalLine transactions, which are used for printing the picking list. The SalesPickingListJournal report has been modified to correct printing of the dimension fields. |
\Classes\SalesFormLetter_PickingListJournal \Reports\SalesPickingListJournal \Classes\InventDimCtrl_Rep_Sales | ||||||||||||||||||
| #4694 | Not available | The Search and filter function for serial numbers did not work on the Serial number and On-hand tabs. | • Problem The Search and filter function for serial numbers did not work on the Serial number and On-hand tabs. When the user performed a search by using the Find button in the Serial number form, the data source was not refreshed because of an error in the InventDimItem.executeQuery() method. The exeQueryItem variable always had the TRUE value after the first execution. • Solution The line of code blocking the execution of the ExecuteQuery() method after the first execution has been removed. |
\Forms\InventSerialIdLookup | ||||||||||||||||||
| #5691 | Not available | The Closed date for the inventory transaction was not retrieved correctly, which caused the transaction to be closed on an incorrect date. | • Problem The Closed date for the inventory transaction was not retrieved correctly, which caused the transaction to be closed on an incorrect date. The issue occurred because of the sorting by index and the reverse order of fetched settlements. • Solution The code has been modified to use maxof() instead of reverse to find out the latest settlement. |
\Data Dictionary\Tables\InventTrans\lastSettleDate | ||||||||||||||||||
| #5693 | Not available | When a sales order was packing slip updated before the item was purchased and the Include physical value check box was selected for an Inventory model group, the Inventory value per item group report displayed incorrect values after the inventory was closed. | • Problem When a sales order was packing slip updated before the item was purchased and the Include physical value check box was selected for an Inventory model group (Inventory management > Setup > Inventory > Inventory model groups), the Inventory value per item group report (Inventory management > Reports > Status > Inventory value > Inventory value per item group) displayed incorrect values after the inventory was closed. The issue occurred because settlement transactions with the Physical value settlement model were included in the \Classes\InventSumFinancialItem\setValueQty method query. • Solution The code has been modified so that settlement transactions of the Physical value settlement model have been excluded from the calculation of the values for the Inventory value per item group report. |
\Classes\InventSumFinancialItem\setValueQty | ||||||||||||||||||
| #6443 | Not available | During the purchase order invoicing, the latest purchase price and the latest cost price were not updated when the invoicing was canceled at first, and then successfully performed. | • Problem During the purchase order invoicing, the latest purchase price and the latest cost price were not updated when the invoicing was canceled at first, and then successfully performed. The issue was caused by the caching properties of the InventTableModel table. Its CacheLookup property was set to ‘Found’. Therefore, in updateLastCostPrice and updateLastPurchasePrice, the system used the cached data instead of the up-to-date data. • Solution The reread() method is used for the just retrieved data set on two methods to solve the issue. Also, a conditional statement has been added to the calcLastPurchPrice() method of the PurchFormLetter_Invoice class to make sure that the latest purchase price is not updated by the credit note. |
\Data
Dictionary\Tables\InventTable \Classes\PurchFormLetter_Invoice | ||||||||||||||||||
| #8188 | Not available | Reversing a registration in the Transfer journal caused the reversed quantity to be assigned to an incorrect warehouse, because the From warehouse value from the journal line was used. | • Problem Reversing a registration in the Transfer journal (Inventory management > Journals > Item transaction > Transfer) caused the reversed quantity to be assigned to an incorrect warehouse, because the From warehouse value from the journal line was used. The issue occurred because an incorrect inventory dimension was used for InventTrans.inventDimId. • Solution The code has been modified to use the inventory dimension value for InventTrans.inventDimId from inventJournalTrans.InventTransId when the user reverses a registration in the Transfer journal. |
\Classes\InventMovement \Classes\InventMov_Jour_TransferIssue \Classes\InventUpd_Registered | ||||||||||||||||||
| #8322 | Not available | The result of marking a purchase order line against a sales order line was incorrect if the Auto button was used. | • Problem The result of marking a purchase order line against a sales order line was incorrect if the Auto button was used. In the \Forms\InventMarking\Methods\markTmp method, _tmp.QtyRemain did not change during marking, which led to errors in the marking functionality. • Solution The logic of the marking methods has been modified to ensure correct marking. |
\Forms\InventMarking\Methods\autoMark \Forms\InventMarking\Methods\markTmp | ||||||||||||||||||
| #8347 | Not available | In some cases, the calculation of the financial cost amount was incorrect. | • Problem In some cases, the calculation of the financial cost amount was incorrect. This occurred because the receipt quantity with the ‘0’ financial value was included in the calculation of the financial cost amount for the marked issue transactions. • Solution The code has been modified so that receipts updated as a packing slip return as a "normal" receipt is not considered during the calculation of the financial cost. |
\Tables\InventTrans\calcMarkedCostValue | ||||||||||||||||||
| #8899 | KB900247 | When users posted the Tag counting journal and transferring lines to a Counting journal, financial dimensions were not transferred to the counting lines according to ItemId. | • Problem When users posted the Tag counting journal and transferring lines to a Counting journal, financial dimensions were not transferred to the counting lines according to ItemId. Therefore, the user had to enter dimensions on the counting lines manually. The issue occurred because, in \Classes\InventJournalCheckPost_Tag\initInventJournalTransCount, financial dimensions were not initialized. • Solution The code has been modified to automatically specify the financial dimensions for a specific item while posting the Tab counting journal. |
\Classes\InventJournalCheckPost_Tag\initInventJournalTransCount | ||||||||||||||||||
| #8900 | KB899743 | In certain cases the shipment template date criteria was not applied correctly. | • Problem If the user selected the ‘today’ date criteria and opened the Query window by clicking Criteria in the Shipment templates form, the shipment template date criteria was not applied correctly. When a new (non-manual) shipment is initialized, it calls the initFromTemplate() method on the WMSShipment table. Among other fields, it initializes the packedQuery field. If a QueryRun object was already present in the template (and it was if the Criteria dialog was opened), it would take the saved query. Otherwise, it would call the WMSShipmentTemplate.queryRun() method. This method applied the appropriate date filter. • Solution The code has been modified so that whenever a new shipment is created by the wizard or by using the auto-add mechanism, the query range for the Date field is updated before executing the query. |
\Data Dictionary\Tables\WMSShipment\Methods\initFromTemplate | ||||||||||||||||||
| #8910 | KB900394 | When the user created a sales order and entered an item which had the Configuration dimension activated, and when the warehouse item setup was performed for each configuration with the respective location, the location was not updated and remained the same as in the previously defined configuration after the configuration change. | • Problem When the user created a sales order (Account receivable > Sales order) and entered an item which had the Configuration dimension activated, and when the warehouse item setup was performed for each configuration with the respective location, the location was not updated and remained the same as in the previously defined configuration after the configuration change. The issue occurred because if the location was not cleared before modifying InventDim, it did not follow the change and remained the same. • Solution The location clearing procedure has been added to the modified methods on three InventDim fields. |
\Forms\SalesTable\Data
Sources\InventDim\Fields\configId\Methods \Forms\SalesTable\Data Sources\InventDim\Fields\InventSizeId\Methods \Forms\SalesTable\Data Sources\InventDim\Fields\InventColorId\Methods \Forms\SalesTable\Data Sources\InventDim\Fields\InventLocationId\Methods | ||||||||||||||||||
| #8911 | KB900334 | When users posted several journal lines from the Profit/Loss journal and some lines (but not the first one) had CostAmount equal to ‘0’, the CostAmount value for this line was taken from the previous journal line. | • Problem When users posted several journal lines from the Profit/Loss journal (Inventory management > Journals > Item transaction > Profit/Loss) and some lines (but not the first one) had CostAmount equal to ‘0’, the CostAmount value for this line was taken from the previous journal line. The updateFinancial method in the InventMovement class handles posting the profit & loss amount. The amount to be posted was set by using the last amount posted to the ledger by calling ledgerVoucher.lastAmountMST(). However, when the amount to post was zero, no ledger transaction was created. For that reason the amount was taken from the previous journal line. • Solution The check on whether CostAmount(updateNow.parmCostAmountCur() is equal to zero has been added to the \Classes\InventMovement\updateLedgerFinancial method and depending on the result, either CostAmount equal to ‘0’ or the actual value of CostAmount is used. |
\Classes\InventMovement\updateLedgerFinancial | ||||||||||||||||||
| #8919 | Not available | Not all controls were visible and available on the Method page of the Item allocation keys wizard when the DPI font setting was set to ‘120 DPI’. | • Problem Not all controls were visible and available on the Method page of the Item allocation keys wizard when the DPI font setting was set to ‘120 DPI’. The issue occurred because the height of the MethodTxt HTML control was not limited so that it would ensure that all controls were visible and available on the Method page of the Item allocation keys wizard. • Solution The height of the MethodTxt HTML control is now limited. Therefore the text and all controls are visible and accessible on the Method page of the Item allocation keys wizard. |
\Forms\ForecastItemAllocationDefaultDataWizard\Designs\Design\[Tab:Tab]\[TabPage:MethodTab]\
Methods\pageActivated \Forms\ReqItemTableWizard\Methods\run \Forms\ReqItemTableWizard\Designs\Design\[Tab:ctrlTab]\[TabPage:WelcomePage]\Methods\ pageActivated \Forms\ReqItemTableWizard\Designs\Design\[Tab:ctrlTab]\[TabPage:CovRuleTab]\Methods\ pageActivated | ||||||||||||||||||
| #9079 | Not available | The performance of the Picking line form was poor. | • Problem The performance of the Picking line form was poor. Opening this form could take two minutes if the database contained three million or more InventDim records. The issue occurred because of an index problem when the RouteId range was applied in the select statement. • Solution The WMSOrderTrans data source query has been improved. |
\Forms\WMSPickingLine\Data sources\WMSOrderTrans\Methods\executeQuery | ||||||||||||||||||
| #9560 | KB899592 | When the user tried to print the lines of BOM in which the sub-BOM item occurred more than three times, printing stopped on the third occurrence of the item. | • Problem When the user tried to print the lines of BOM in which the sub-BOM item occurred more than three times, printing stopped on the third occurrence of the item. The issue occurred because the circularBOMMap map in the \Classes\BOMHierarchyReport\scanDownVersion method was filled incorrectly. The code did not allow the same sub-BOM to occur in different brunches. That is why the system stopped printing if the same item occurred multiple times. • Solution The \Classes\BOMHierarchyReport\scanDownBOM and \Classes\BOMHierarchyReport\scanDownVersion methods have been modified. Processing of the circularBOMMap map has been corrected. |
\Classes\BOMHierarchyReport\scanDownBOM \Classes\BOMHierarchyReport\scanDownVersion | ||||||||||||||||||
| #9623 | KB901113 | When the user performed a BOM calculation on a parent by using its component, the cost price of an item was incorrectly "scaled" by the conversion factor. | • Problem When the user performed a BOM calculation on a parent by using its component, the cost price of an item was incorrectly "scaled" by the conversion factor. This should not occur, because the base U.O.M. and BOM U.O.M. are the same. The issue occurred because of a mistake in the BOM calculation logic. • Solution The code has been modified so that when the Use purchase price agreements parameter is used and the BOM cost price is calculated depending on the Use price parameter, the system checks if the conversion factor is needed for InventTableModule of the current BOM. |
\Data Dictionary\Tables\InventTable | ||||||||||||||||||
| #10172 | Not available | Two quarantine transfers were weakly linked, which sometimes caused an disbalance in the cost values. | • Problem Two quarantine transfers were weakly linked, which sometimes caused an misbalance in the cost values. The issue occurred because of the disbalance in the cost values for quarantine transactions within two quarantine pairs. • Solution The code has been modified so that during the physical update of a receipt, the first pair of quarantine transactions (transfer to quarantine) is updated physically (not financially). Also, during the end of quarantine, both quarantine pairs (transfers to/from quarantine) are financially updated, which avoids the disbalance between the quarantine transactions within two quarantine pairs. |
\Data
Dictionary\Tables\InventQuarantineOrder\Methods\qtyEndedPhysical \Data Dictionary\Tables\InventQuarantineOrder\Methods\qtyStartedFinancial \Data Dictionary\Tables\InventQuarantineOrder\Methods\startFinancial \Classes\InventTransIdSum_InventLocation\classDeclaration \Classes\InventTransIdSum_InventLocation\calcSum \Classes\InventTransIdSum_InventLocation\parmInventLocationType \Classes\InventTransIdSum_InventLocation\construct \Classes\InventTransIdSum_InventLocation\newQuarantine \Classes\InventTransIdSum_InventLocation\newStandard \Classes\InventQuarantineOrder_Scrap\run \Classes\InventQuarantineOrder_Split\classDeclaration \Classes\InventQuarantineOrder_Split\beginLedger \Classes\InventQuarantineOrder_Split\commitLedger \Classes\InventQuarantineOrder_Split\run \Classes\InventMovement\canInventTransBeFinancialUpdated \Classes\InventMovement\mustUpdateInventTableCostPrice \Classes\InventQuarantineUpdEnd\updateQuarantineOrder \Classes\InventUpd_Financial\updateFinancialIssue \Classes\InventUpd_Financial\updateFinancialReceipt \Classes\InventUpd_Physical\newInventQuarantineOrder \Classes\InventMov_Quarantine\classDeclaration \Classes\InventMov_Quarantine\canInventTransBeFinancialUpdated \Classes\InventMov_Quarantine\mustUpdateInventTableCostPrice \Classes\InventMov_Quarantine\parmInventDirection \Classes\InventMov_Quarantine\remainFinancialUnit \Classes\InventMov_Quarantine\remainPhysical \Classes\InventMov_Quarantine\transIdSum \Classes\InventMov_Quarantine\transIdSumTransId \Classes\InventMov_Quarantine\transSign \Classes\InventMov_QuarantineInvent\classDeclaration \Classes\InventMov_QuarantineInvent\canInventTransBeFinancialUpdated \Classes\InventMov_QuarantineInvent\remainFinancialUnit \Classes\InventMov_QuarantineInvent\remainPhysical \Classes\InventMov_QuarantineInvent\transIdSum \Classes\InventMov_QuarantineInvent\transIdSumTransId \Classes\InventMov_QuarantineInvent\transSign \Classes\InventQuarantineUpdStartUp\updateQuarantineOrder | ||||||||||||||||||
| #10587 | Not available | When the Block editing parameter of the Life Science was selected on either the Inventory or Production form, it was possible to activate the multiple BOM-version or Route-version with the overlapped date intervals. | • Problem When the Block editing parameter of the Life Science was selected on either the Inventory or Production form (Inventory management > Setup > Parameters > Bill of material tab and Production > Setup > Parameters > General tab), it was possible to activate the multiple BOM-version or Route-version with the overlapped date intervals. The issue occurred because, in the \Classes\RouteVersionActivate and \Classes\BOMVersionActivate classes, which can activate the BOM-version or Route-version, the checking for the overlap date intervals was not implemented. • Solution The check for the overlapping date intervals has been added to the \Classes\RouteVersionActivate\validate and \Classes\BOMVersionActivate\validate methods. |
\Classes\RouteVersionActivate \Classes\BOMVersionActivate | ||||||||||||||||||
| #10752 | Not available | When the user tried to run the Consistency check with Check/Fix set to ‘Correct error’ for Warehouse management > Pallets, the error message was displayed for those pallets with the incorrectly calculated Height value. | • Problem When the user tried to run the Consistency check (Basic > Periodic > Consistency check) with Check/Fix set to ‘Correct error’ for Warehouse management > Pallets, the error message was displayed for those pallets with the incorrectly calculated Height value. The issue occurred because the ttsbegin/ttscommit transaction statements and the forupdate table property were missing. • Solution The ttsbegin/ttscommit transaction statements have been added to the \Data Dictionary\Tables\WMSPallet\Methods\checkFixDimensions method. The true parameter has been added to the WMSPallet::find() method to select the record with the forupdate property and update the selected record in the copy variable. Also, the \Classes\WMSConsistencyCheck_Pallet\run method has been modified to calculate the error amount. |
\Data
Dictionary\Tables\WMSPallet\Methods\checkFixDimensions \Classes\WMSConsistencyCheck_Pallet\run | ||||||||||||||||||
| #10811 | Not available | An incorrect on-hand quantity was retrieved for the inventory Counting journal line if blank/filled-in inventory dimensions were used. | • Problem When the inventory Counting journal (Inventory management > Journals > Item counting > Counting) was used for an item with the active Location and Warehouse dimensions for the dimension group and there were receipts with both blank and filled-in locations for this item, the on-hand item quantity was shown incorrectly. The issue was caused by an incorrect initialization of inventory dimensions for the Counting journal line. • Solution The code has been modified to allow for the dimensions setup from the Counting journal and the one on the counting line in a way of merging active keys (set to ‘Yes’) into one InventDimParm used to retrieve the on-hand quantity. |
\Classes\InventMov_Jour_Loss_SumUp\dateOnHandPhysical | ||||||||||||||||||
| #10870 | Not available | For a marked sales order and production order when scraping items during the ‘Report as Finished’ production order, the ‘ReservOrdered’ issue transaction did not change its status to ‘On Order’. This led to an inconsistency of marking/reservation. | • Problem For a marked sales order and production order when scraping items during the ‘Report as Finished’ production order, the ‘ReservOrdered’ issue transaction did not change its status to ‘On Order’. This led to an inconsistency of marking/reservation. In the \Data Dictionary\Tables\InventTrans\Methods\deleteMarking method, when the ‘Ordered’ receipt transaction was deleted and the deletion of the marking was required, the system deleted the marking by using ReservPhysical then ReservOrdered. Even facing the ‘ReservOrdered’ issue transaction the system did not flush IssueStatus to ‘On Order’. • Solution The \Data Dictionary\Tables\InventTrans\Methods\deleteMarking method has been modified to change the order by which the system fetches candidates for the deletion of the marking and to flush IssueStatus to ‘On Order’ each time the system faces the ‘ReservOrdered’ issue transaction with the just-deleted marking. |
\Data Dictionary\Tables\InventTrans\Methods\deleteMarking | ||||||||||||||||||
| #10989 | Not available | It was not possible to obtain information about the Ordered Reserved items amount by using the On-hand report. | • Problem It was not possible to obtain information about the Ordered Reserved items amount by using the On-hand report (Inventory management > Reports > On-hand inventory). The issue occurred because the Reserved Ordered field was not included in the On-hand report. • Solution The design of the InventOnHand report (\Reports\InventOnhand) has been updated by adding a new column for the Ordered Reserved items amount, which should be taken from the ReservOrdered field of the InventSum table. |
\Reports\InventOnhand | ||||||||||||||||||
| #11488 | KB908253 | When items with specified serial numbers were partially sold, there were lines with the zero on-hand inventory quantity in the inventory Counting journal (Inventory management > Journals > Item counting > Counting) created by using the Create > On-hand button. | • Problem When new lines in the inventory Counting journal (Inventory management > Journals > Item counting > Counting) were created by using the Create > On-hand functionality (the Create > On-hand button in the Journal lines form) for the item with the serial number that was specified and this item was partially sold, there were lines with the zero on-hand quantity for that item. The issue was caused by a mistake in the code of the \Classes\InventCountCreate_Base\createInventJournalTrans method where fetched records to be displayed were not checked for the available on-hand inventory. • Solution The optional Show zero lines check box has been inserted in the Create on-hand counting journal (Inventory management > Journals > Item counting > Counting > Lines > Create > On-hand) to check whether to create lines with zero on-hand quantity or not. |
\Classes\InventCountCreate \Classes\InventCountCreate_Base | ||||||||||||||||||
| #11579 | KB908797 | Ledger posting was not performed if a critical stop error occurred during the inventory closing/recalculation. | • Problem Physical value adjustments update the item’s physical value. However, ledger posting was not performed if a critical stop error occurred during the inventory closing/recalculation. During the financial update, physical ledger accounts were reversed according to the physical value that was updated by the inventory closing/recalculation, which resulted in a critical stop error. During the cancellation of the inventory closing/recalculation with a critical stop error, storno ledger posting can be done only for the ENDED closing/recalculation. Therefore, the mismatch between the inventory and the ledger occurred after a cancellation. Example: 1. Posting of a sales packing slip.
2. Recalculation performed with a critical stop error made the physical value adjustment for the inventory transaction 1.43. No ledger posting is performed. 3. Posting of a sales invoice (recalculation performed with a critical error is not canceled yet). Reverse of physical accounts.
The influence of physical adjustment equals 1.43. 4. When the recalculation performed with a critical error is canceled, the mismatch between inventory and ledger occurs by a factor of 1.43 because it is not posted in ledger. • Solution Physical value adjustments for financially updated transactions are analyzed during the cancellation of the closing/recalculation, which resulted in a critical error and storno ledger posting is performed to balance inventory and ledger. |
\Classes\InventAdj_Cancel\run \Classes\InventAdj_Cancel\cancelPhysicalValueSettlements | ||||||||||||||||||
| #11582 | KB908798 | The system did not perform a check for a circular structure when the user exited the BOM after creating it if the Level of circularity parameter was set to ‘BOM’ in the Inventory parameters form. | • Problem The system did not perform a check for a circular structure when the user exited the BOM after creating it if the Level of circularity parameter was set to ‘BOM’ in the Inventory parameters form (Inventory management > Setup > Parameters). The issue occurred because the \Forms\BOMConsistsOf form did not contain the code checking the circularity of BOM.BOMId. • Solution The \Data Dictionary\Tables\BOMParameters\Methods\mustCheckBOMCircularityBOM method has been added to the BOMparameters table. Also, the \Forms\BOMConsistsOf and \Forms\BOMDesigner forms have been modified to check for circularity in the canClose method. |
\Data
Dictionary\Tables\BOMParameters\Methods\mustCheckBOMCircularityBOM \Forms\BOMConsistOf\Methods\canClose \Forms\BOMDesigner\Methods\canClose | ||||||||||||||||||
| #11787 | Not available | An incorrect adjustment calculation and posting for the receipt and issue transactions occurred when the issue settlement was split and readjusted for the previously settled receipt-issue. | • Problem An incorrect adjustment calculation and posting for the receipt and issue transactions occurred when the issue settlement was split and readjusted for the previously settled receipt-issue. The loop in InventCostItemDim.updateReceiptAdjustmentTrans selects receipt settlements with the same Lot ID and associated issueSettlements with the same SettleTransId. The starting point for the calculation is settlementReceipt with the appropriate quantity. It usually works, although one situation is not considered - when the issue settlement is split for different quantities. For example:
The amount to re-adjust = -1000.00. When the loop worked, it took the first issue settlement (for example, -1) and tried to allocate -1000.00 for this issue, which was incorrect because the settled quantities were not the same (100 and -1). Additional actions led to an incorrect adjustment calculated for an issue, and sometimes to the positive cost value of this issue (which led to the calculation and posting of an error adjustment for the receipt, which is definitely incorrect). The second issue settlement (-99) was not considered because of the break of the loop: if (allocateQty == 0) (the
quantity was taken from the receipt and was completely allocated on the
first iteration with issue
1).{ break; } • Solution settlementIssue with the appropriate quantity should be the starting point for the calculation instead of settlementReceipt. Therefore, the receipt is not adjusted. |
\Classes\InventCostItemDim\updateReceiptAdjustmentTrans | ||||||||||||||||||
| #11969 | Not available | An error in rounding occurred while the receipt adjustment was performed during the inventory closing. | • Problem Receipt adjustments in inventory closing had an error in the rounding mechanism. If an adjustment amount was so small that the issue it was distributed to was less than 0.01 cent, the total receipt adjustment was posted as an error adjustment. Also, if the settled amount divided by the receipt quantity did not total the actual cost value (because of rounding), an error adjustment would be repeated in each successive recalculation or closing. This would only stop when the difference became less than the minimum transfer value. • Solution The updateReceiptAdjustmentTrans method of the InventCostItemDim class has been corrected to determine rounding adjustments and not post an error adjustment unless the adjustment is financially closed or some issues were adjusted while others were not (amount less than 0.01). |
\Classes\InventCostItemDim\updateReceiptAdjustmentTrans | ||||||||||||||||||
| #13061 | Not available | The packing slip transaction was shown if the user invoice updated a purchase order without packing slip updating though this transaction was never created. | • Problem The packing slip transaction was shown if the user invoice updated a purchase order without packing slip updating though this transaction was never created. The InventTransPosting.postedValue() method always returned sum(costAmountPhysical) for InventTransPostingType::Physical from InventTrans regardless of the actual posting in ledger. For example, if the user posted an invoice without a packing slip, there was no actual posting for the physical update in the ledger, but the method returned a non-zero amount and the line was added in the report. • Solution The code has been modified so that if running the invoice update of a purchase order and the transaction is not updated physically, the system updates the transaction physically by using the same voucher and having no ledger transactions related to physical update. The logic has been corrected to put an additional condition when the sum of physical posted value is encountered in General ledger. |
\Classes\InventReport_Balance\createFromInventTransPosting \Data Dictionary\Tables\InventTransPosting\Methods\postedValue | ||||||||||||||||||
| #13583 | Not available | Standard cost priced items under certain circumstances had settlement transactions with every recalculation. This happened if the item was sold, the standard cost price was afterward changed and then the item was returned. | • Problem Standard cost priced items under certain circumstances had settlement transactions with every recalculation. This happened if the item was sold, the standard cost price was afterward changed and then the item was returned. When the item was returned, the financial update found that the return cost was different from the current standard cost price and created a settlement immediately, changing the cost amount of the transaction to the current standard cost price. The price of the original issue and the return were then different. The next recalculation of the item would find that the issue and the return had different costs, but should have had identical costs (return lot ID). An adjustment was then made. Now the cost of the issue and return receipt were the same. Later, the recalculation process picked the same receipt transaction and found that it was for a standard cost price item, but the cost was not the standard cost (transaction). The receipt was readjusted to the standard cost and the cost of the issue and receipt were different again. This would repeat with every recalculation. According to Microsoft Dynamics AX 3.0 design, transactions connected by a return lot ID should have the same cost. The recalculation tried to ensure this was the case. This was contradicting a later step, which ensures that standard cost transactions have the standard cost. • Solution The standard cost is taken from the original issue when financially updating the return receipt. No settlement is created, and the issue/receipt cost is identical. This prevents the recalculation from performing the first settlement (return lot ID). It also prevents the second adjustment because the transaction cost and standard cost (transaction) are the same. Nevertheless, an additional correction has been made. Therefore, the readjustment to the standard cost never occurs for sales-returned, standard cost price items. |
\Classes\InventUpd_Financial\updateFinancialReceipt \Classes\InventUpd_Financial\updateStdCostPrice \Classes\InventCostItemDim\updateReceiptAdjustmentTrans | ||||||||||||||||||
| #14019 | Not available | Linking a new data source in Closing and adjustment > Adjustment > Transactions caused transactions to be fetched two times. | • Problem Linking a new data source in Closing and adjustment > Adjustment > Transactions caused transactions to be fetched two times. The issue occurred because if a new data source was added dynamically, QueryRun.next() retrieved the same transaction two times. • Solution The code has been modified to prevent adding the same transaction two times. |
\Classes\InventAdjTransactSelect\run | ||||||||||||||||||
| #14593 | Not available | In a 3-tier configuration, the configuration rules did not work correctly if the user tried to select the configuration for an item which had the configuration route and corresponding configuration rules. | • Problem In a 3-tier configuration, the configuration rules did not work correctly if the user tried to select the configuration for an item which had the configuration route and corresponding configuration rules. In a 3-tier configuration, the \Classes\ConfigTmpSave\saveValueSearchRules method packed the values of the ConfigTmpSave and ConfigHierarchyChoose classes into containers, created a server static copy of the ConfigTmpSave class named tmpSaveServer, and ran the tmpSaveServer.saveValueSearchRules method on server. However, after that only the tmpSaveServer class values were unpacked into the ConfigTmpSave class. • Solution The code has been modified so that if the \Classes\ConfigTmpSave\saveValueSearchRules method runs its static copy on the server, the values from tmpSaveServer.hierarchyChoose().pack() are unpacked into the ConfigHierarchyChoose class. |
\Classes\ConfigTmpSave | ||||||||||||||||||
| #14730 | Not available | When some item transactions with different configuration dimensions existed in the system and the user tried to rename one of the configurations while the old configuration differed from the new only if there are symbols (uppercase or lowercase), the corresponding records from InventSum were deleted. | • Problem When some item transactions with different configuration dimensions existed in the system and the user tried to rename one of the configurations while the old configuration differed from the new only if there are symbols (uppercase or lowercase), the corresponding records from InventSum were deleted. When the user tried to rename one of the item dimensions and differences between the new and old dimensions were only in the lower or upper case of symbols, the corresponding inventory dimension record did not change. That is why, in the methods of the \Classes\InventDimRenameDimValue class, the old and new dimension number had the same number of InventDimId. However, in this case it is incorrect to find the record from InventSum with the new InventDimId and throw the values out of the record with the old dimension. • Solution The \Classes\InventDimRenameDimValue\handleTable_InventSum method has been modified to avoid deleting the InventSum records. |
\Classes\InventDimRenameDimValue | ||||||||||||||||||
| #14793 | Not available | The sales order reservation status did not change when using the blanket order for purchasing. | • Problem The sales order reservation status did not change when using the blanket order for purchasing. The reservation status remained ‘Reserved Ordered’ even after the purchase order was invoiced (the ‘Reserved Physical’ status was expected in this case). The issue occurred because blanket order inventory transactions were not processed when changing transaction statuses in the updateDimReservePhysical method of the InventUpdate class. • Solution The code has been modified so that blanket order-based transactions are considered when changing transaction status during update. By default, the isBlanketOrderReference method has been introduced in the InventMovement class that returns FALSE. However, it is overridden in the InventMov_Purch and InventMov_Sales classes to define whether the transaction passed as an argument is a blanket order or not. |
\Classes\InventUpdate \Classes\InventMovement \Classes\InventMov_Purch \Classes\InventMov_Sales | ||||||||||||||||||
| #15109 | Not available | Because of one of the active inventory storage dimensions selected as non-physical some scenarios allowed users to reserve a higher number than really available for reservation, which caused a negative physical on-hand even if it was prohibited by the inventory model group. | • Problem Because of one of the active inventory storage dimensions selected as non-physical some scenarios allowed users to reserve a higher number than really available for reservation, which caused a negative physical on-hand even if it was prohibited by the inventory model group. For active, but not physical storage dimensions, the physical on-hand control was activated during reservation only if those dimensions had the Blank receipt/issue check boxes selected. Otherwise the system used standard reservation logic, which could cause negative physical on-hand even if it was not allowed by the inventory model group. • Solution The code has been modified to activate the physical on-hand control during reservation for the item dimension setup if any non-physically controlled storage dimension exists without considering the Blank receipt/issue check box status. |
\Classes\InventUpd_Reservation\isInventSumEqualPhysicalInvent | ||||||||||||||||||
| #15354 | Not available | If the Include physical value check box was selected on the Inventory model group of an item, the physical cost value differed from the financial cost value after the user posted the inventory Transfer journal. Also, under certain circumstances, the physical cost amount was calculated incorrectly. | • Problem If the Include physical value check box was selected on the Inventory model group of an item, the physical cost value differed from the financial cost value after the user posted the inventory Transfer journal. Also, under certain circumstances, the physical cost amount was calculated incorrectly. There was a block of code in the financialIssueCostValue method of the InventMovement class, which adjusted the financial cost value if the system was set up to include physical value. However, this was unacceptable for transfer, because in this case the financial cost value should be exactly equal to the physical cost value. Actually, the whole method here was redundant, because no calculation was needed if there was a transfer. The \InventMovement\estimatedFinancialValue method would take the inventOnHand object as the financial inventory on hand when it represented physical inventory if the Include physical value check box was not selected. • Solution The financialIssueCostValue method has been overridden in the InventMov_Jour_Transfer class to ensure that financial cost value is made equal to the physical cost value (which is already filled in on this stage of posting). If the physical and financial dimension setup (inventDimParm) is not the same, the actual financial inventory on-hand is determined, and the price based on those values is calculated. |
\Classes\InventMov_Jour_Transfer\financialIssueCostValue \Classes\InventMovement\estimatedFinancialValue \Classes\InventOnHand\parmInventDimParm | ||||||||||||||||||
| #15653 | Not available | 1. Under certain circumstances inventory
recalculation fell into loop until "maximum throughputs" was reached.
Adjustments would grow with every
loop. 2. Incorrect adjustments were made when transactions were financially updated, but with a date beyond the inventory closing/recalculation date. The situation might have occurred if the Include physical value check box was selected for an inventory model group. 3. Incorrect adjustments to transaction cost were made if there were standard cost items and minimum throughput transactions. |
• Problem This issue was based on hotfix 9298 and addressed additional problems. 1. Under certain circumstances (including physical value, recalculation and a financially later updated receipt applied to a transfer or quarantine) hotfix 9298 would cause the inventory recalculation to loop until "maximum throughputs" was reached. Adjustments would grow with every loop. 2. Incorrect adjustments were made when transactions were financially updated, but with a date beyond the inventory closing/recalculation date. The situation might have occurred if the Include physical value check box was selected for an inventory model group. 3. Incorrect adjustments to transaction cost were made if there were standard cost items and minimum throughput transactions. The code did not consider that even if a transaction was financially updated it might not be eligible for settlements, as the financial date is a future date. The \Classes\InventCostItemDim\updateClosingCosting method was called for every linked receipt/issue pair according to their inventory model or marking (used by updateModelFIFOLIFO, updateModelLIFODate, updateModelAverage, and updateSettleRefTransId). This method checked if the current run was a recalculation or either transaction is not financially updated. In that case the issue was put in a map with the calculated adjustment amount. The map was later picked up and adjustments were created, but no quantities or amounts were settled. If the conditions were not met, the method would create an actual settlement. The issue occurred because one or both transactions were financially updated and would therefore create an adjustment or settlement. A similar situation was caused by updateReceiptAdjustment() calls to updateReceiptsAdjustmentTrans() for future financially updated transactions. _adjustmentLater might include a minimum throughput value, which was required for the second part of updateReceiptAdjustmentTrans(). The looping was caused by calculating an adjustment, putting it into mapSettleValue, but not posting it. The map values would be used by the following issues/receipts and led to incorrect adjustments. Because neither of these transactions were updated in the future, those adjustments would complete and be carried forward to the next iteration where the process started over again, entering an infinite loop. • Solution For every matched receipt/issue pair (according to the inventory model), a check runs if either of them is financially updated with a future date and the current run is a closing. In that situation, no adjustment is made. The pair remain linked to each other, and neither the issue nor the receipt is used to settle other transactions. Instead, the transactions are settled when a closing is performed at a later date (>= financial update of pair). Minimum throughput transactions that are posted to transactions have their standard cost readjusted by posting the required settlement. No adjustments are allowed to any transaction that is financially updated after the closing/recalculation date. To avoid infinite looping, an additional restriction has been applied: recalculation adjustments are not "blown up", if either the receipt or the issue are financially updated later. "Blowing up" an adjustment means that when running the recalculation it is allowed to make the assumption that, for example, when looking at a receipt of 1 and an issue of 10, all 10 would have the cost of the receipt of 1. That is because the goal of a recalculation is not to obtain exact cost, but a good approximation of cost. |
\Classes\InventCostItemDim\updateClosingCosting \Classes\InventCostItemDim\updateTransIdReceipt | ||||||||||||||||||
| #15726 | Not available | The user could not delete a location that was not used for one warehouse, because the system informed that this location was used in the Warehouse items table for another warehouse. | • Problem The user could not delete a location that was not used for one warehouse, because the system informed that this location was used in the Warehouse items table for another warehouse. The issue occurred because, while deleting a record from WMSLocation, the system did not check other item dimensions in the related InventItemLocation table. • Solution The InventItemLocation relation and delete action have been deleted from WMSLocation, and the validateDelete method has been updated. The validateDelete method checks other storage dimensions. |
\Macros\InventDimExistsJoin \Data Dictionary\Tables\WMSLocation | ||||||||||||||||||
| #16141 | KB917364 | Incorrect financial amount calculation was performed during production costing. | • Problem Incorrect financial amount calculation was performed during production costing. The issue occurred when the material took into account physical transactions (the Include physical value check box selected) and a non-standard cost model was applied. During the costing, the amount was transferred from the materials level to the product level, which caused an incorrect cost price for the final product. The issue occurred because of a mistake in the financial amount calculation formula for issues with the Include physical value model. • Solution The financial amount calculation formula, applied for issues with the include physical value model, has been modified. |
\Data Dictionary\Tables\InventSum\Methods\CostPricePcs \Data Dictionary\Tables\InventSum\Methods\validateWrite \Classes\InventMovement\financialIssueCostValue \Classes\InventUpd_Financial\classDeclaration \Classes\InventUpd_Financial\updateFinancialIssue \Classes\InventUpd_Financial\inventOnHandFinancialCache \Classes\InventUpd_Financial\updateInventOnHandFinancialCache \Macros\inventDimExistsJoin | ||||||||||||||||||
| #16745 | Not available | If the Simulation check box was selected while the Tag counting journal was posted, the system, by mistake, created a new Counting journal without lines. | • Problem If the Simulation check box was selected while the Tag counting journal was posted, the system, by mistake, created a new Counting journal without lines. The issue occurred because of an incorrect methods calling sequence in the \Classes\InventJournalCheckPost_Tag\postJournal method. A new Counting journal header was created before the information to be shown was created if the Simulation check box was selected. • Solution The code has been modified so that when posting the Tag counting journal with the Simulation check box selected, only the information about the expected adjustment instead of the current posting is shown, and no new journal is created. |
\Classes\InventJournalCheckPost_Tag\postJournal | ||||||||||||||||||
| #16997 | Not available | Multiple errors occurred with the reservation of marked issue transactions during the receipt physical update or dimension change (estimation). | • Problem Multiple errors occurred with the reservation of marked issue transactions during the receipt physical update or dimension change (estimation). In particular, a marked receipt could cover the reservation of the unmarked issue/issue marked with another receipt. Also, the unmarked receipt could cover the reservation of the marked issue. The issue occurred because, in the \Classes\InventUpdate\updateDimReserveChange method, incorrect issue inventory transaction was selected for the inventory dimension update. • Solution The code has been modified so that now a marked receipt can cover the reservation of only opposite marked issue transactions and an unmarked receipt can cover the reservation of only unmarked issue transactions. |
\Classes\InventUpdate\updateDimReserveChange \Classes\InventUpdate\writeInventTrans \Forms\PurchCreateFromSalesOrder\Designs\Design\[Group:GroupParameters]\CheckBox:ReserveInvent | ||||||||||||||||||
| #17439 | Not available | When Inventory closing adjusted an issue (material consumption), according to a receipt (product receipt) (both had the same item), and later the issue transferred that adjustment on a higher level, the system fell into an infinite loop because the transactions could not be balanced. On each iteration, the adjustment of the issue and receipt rose. | • Problem When Inventory closing adjusted an issue (material consumption), according to a receipt (product receipt) (both had the same item), and later the issue transferred that adjustment on a higher level, the system fell into an infinite loop because the transactions could not be balanced. On each iteration, the adjustment of the issue and receipt rose. Inventory closing had no logic behind the BOM circularity cases. A child issue transaction (BOM line/Prod line) that had InventTransIdFather linked to receipt through InventTransId was adjusted and settled by that receipt, which caused a later transfer costs back from the issue to the receipt and looping afterward. • Solution The code has been modified so that the child consumption transaction (production line and BOM line) is not adjusted by the parent transaction for the same item to avoid additional transfer back (from a child to a parent) and looping. |
\Classes\InventCostItemDim\updateModelAverage \Classes\InventCostItemDim\updateModelFIFOLIFO \Classes\InventCostItemDim\updateModelLIFODate \Classes\InventCostItemDim\updateSettleRefTransId | ||||||||||||||||||
| #17675 | KB921179 | The user was not able to use Quarantine Management if serial number control was used (the Serial number control check box was selected for the Serial dimension). | • Problem The user was not able to use Quarantine Management if serial number control was used (the Serial number control check box was selected for the Serial dimension). The issue occurred because of a mistake in the design of the rule describing the Serial number control check box. • Solution New checks have been added for the transfer from and to quarantine orders for items that have the Serial number control check box selected. |
\Classes\InventMovement\isTransfer \Classes\InventMovement\updateSerialNumReceipt \Classes\InventMov_WMSTransport\isTransfer \Classes\InventMov_Quarantine\isTransfer \Classes\InventMov_Jour_Transfer\isTransfer | ||||||||||||||||||
| #17677 | KB921461 | If one user posted the picking list for a new sales order and another user activated shipment at the same time (the same customer was used), the line from the new sales order was added to the old shipment with status ‘Registered’ and in addition a new shipment was created that has the new sales order lines. | • Problem If one user posted the picking list for a new sales order and another user activated shipment at the same time (the same customer was used), the line from the new sales order was added to the old shipment with status ‘Registered’ and in addition a new shipment was created that has the new sales order lines. The \Data Dictionary\Tables\WMSOrder\Methods\autoAddShipment method was used to add WMSOrder to a shipment. First, it searched for an existing shipment with status ‘Registered’. If such a shipment was found, it verified whether it could be added to the shipment or not (the \Data Dictionary\Tables\WMSShipment\Methods\canWMSOrderBeAdded method was used). If positive, it added WMSOrder to the shipment. The issue occurred if shipment activation was run (by another user) during the call to the canWMSOrderBeAdded method. Also, the issue occurred if during the activation process another user manually added WMSOrder to the shipment with the status ‘Registered’. • Solution The code has been modified so that if one user is posting a picking list, the shipment being activated by another user is only activated when all lines of a picking list are posted. Also, all lines of the picking list being posted are added to the activated picking list. If another user has already activated the shipment, a new shipment is created, and all lines from the picking list that are posted by another user are included in this newly created shipment. |
\Data Dictionary\Tables\WMSOrder \Forms\WMSShipmentOrder | ||||||||||||||||||
| #18320 | KB922818 | Items could be incorrectly reserved when the dimensions display setup was saved. | • Problem Items could be incorrectly reserved when the dimensions display setup was saved. The dimensions display setup was saved per form and not per item. Therefore, the system could reserve a quantity from an incorrect dimension by using the saved setup. • Solution The code has been modified so that a user’s saved dimension display setup is overridden if there is a reservation with intersection of the saved InventDimParm and InventDimParm primary dimensions. |
\Classes\InventDimCtrl_Frm_OnHand\initFromCaller | ||||||||||||||||||
| #18340 | KB922844 | The Offset account field was editable in all inventory journals while it should only be editable in the inventory movement journals. | • Problem The Offset account field was editable in all inventory journals while it should only be editable in the inventory movement journals. All inventory journals used the same form (\Forms\InventJournalTable) and there was no check for the Offset account field on the General tab to disable it. • Solution The \Classes\InventJournalFormTable class code has been modified to resolve the issue. |
\Classes\InventJournalFormTable\enableButtonsActive \Classes\InventJournalFormTable \fieldLedgerAccountIdOffset | ||||||||||||||||||
| #18350 | KB922881 | Inventory transactions were incorrectly updated when the user changed the date or quantity in the inventory Transfer journal with an automatic reservation for an item that had the Date-controlled reservation check box selected on the item inventory model group. | • Problem Inventory transactions were incorrectly updated when the user changed the date or quantity in the inventory Transfer journal with an automatic reservation for an item that had the Date-controlled reservation check box selected on the item inventory model group. After the quantity or transaction date were changed, inventory transactions represented an incorrect inventory dimension (item should be respectively set up) and incorrect reservation information. The core of the issue was in the InventJournalTrans table update method. Because the Transfer journal represents two inventory movement transactions (the issue from one place and receipt to another place), two objects of the InventUpd_Estimated class were created. When the estimation was updated (the updateNow() method was called), the system performed the reservation update. The issue was that the system updated the reservation on the receipt transaction by using InventDimId from the receipt transaction, but the issue inventory transaction was updated actually. That is why the issue inventory transaction received the receipt’s inventDimID. • Solution The code has been modified to restrict automatic reservation updating for the receipt transaction. |
\Data Dictionary\Tables\InventJournalTrans\Methods\update | ||||||||||||||||||
| #18373 | KB922904 | After the upgrade to Microsoft Dynamics AX 3.0 Service Pack 5 the user was not able to change the unit in the Item table. | • Problem After the upgrade to Microsoft Dynamics AX 3.0 Service Pack 5 the user was not able to change the unit in the Item table. This occurred in a 3-tier configuration with the Sales force automation module license absent. The issue occurred because the additional code has been introduced by another fix in the \Data Dictionary\Tables\InventTrans\Methods\openTransactionsExist method, which used two tables from different modules in one statement. • Solution The changes that were introduced by another fix have been rolled back to resolve this issue. |
\Data Dictionary\Tables\InventTrans\Methods\openTransactionsExist | ||||||||||||||||||
| #18384 | KB922932 | When the adjustment was forced from an issue to a receipt that used the standard cost model, rare situations might occur when the cost value became negative for this receipt because its standard cost was ‘0’ or the adjustment from components were higher than the standard cost for the whole product. | • Problem When the adjustment was forced from an issue to a receipt that used the standard cost model, rare situations might occur when the cost value became negative for this receipt because its standard cost was ‘0’ or the adjustment from components were higher than the standard cost for the whole product. In this case the error adjustment reversed the original one that created a settlement with Prod receipt/Prod receipt offset ledger accounts instead of Prod receipt/Std. cost loss/profit. This led to misbalance between the real adjustment amounts of the consumed materials and the amount posted in General Ledger on the Std. cost loss/profit/Prod receipt offset ledger accounts. The issue occurred because of a block of code in InventCostItemDim.updateTransIdReceipt(), which created an error adjustment. It should not be done for standard cost items because the relevant logic for adjusting this kind of item is executed later in InventCostItemDim.updateReceiptAdjustmentTrans(). • Solution A additional condition has been added to skip the execution of the mentioned block of code for standard cost items. |
\Classes\InventCostItemDim\updateTransIdReceipt |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #8783 | Not available | When firming a planned transfer order the planned purchase order disappeared from the dynamic explosion screen accessed from a sales order line. | • Problem When firming a planned transfer order the planned purchase order disappeared from the dynamic explosion screen accessed from a sales order line. The issue occurred because the functionality for processing firmed production orders during the explosion was missing. • Solution The logic for building the explosion tree for inventory transfer orders has been corrected. |
\Classes\ReqTransExplode\insertDerived \Data Dictionary\Tables\ReqTrans\Methods\reqTransInventTransfer |
| #10060 | Not available | After manual modification of the Delivery date field value in the Planned orders form, the Requested date field was not automatically updated. The user had to close the form and open it again to see the modified entry in the Requested date field. | • Problem After manual modification of the Delivery date field value in the Planned orders form, the Requested date field was not automatically updated. The user had to close the form and open it again to see the modified entry in the Requested date field. When the user modified the Delivery date field value in the Planned order form, the ReqTrans data source in the ReqTransPO form was not updated because the doReReadReqTrans boolean variable in the \Classes\ReqTransFormPO\reqPoDSWritePost method had the FALSE value. • Solution The code has been modified to update the ReqTrans data source when the user modifies, saves or leaves the record in the form. Also, the doReReadReqTrans variable has the TRUE value in the \Classes\ReqTransFormPO\reqPoDSWritePost method. |
\Classes\ReqTransFormPO |
| #10197 | Not available | The system correctly created planned production orders, but a Cancel action message was generated for them all at the same time. The system also tended to suggest that the current orders were to be increased. If there was a limit for the Maximum order quantity, the system only reached a quantity that might be far from enough. This led to a negative Accumulated amount. | • Problem The system correctly created planned production orders, but a Cancel action message was generated for them all at the same time. The system also tended to suggest that the current orders were to be increased. If there was a limit for the Maximum order quantity, the system only reached a quantity that might be far from enough. This led to a negative Accumulated amount. The system generated planned production orders in two steps. At first, the net requirement was calculated, and the required quantity was calculated correctly. During the second step the system created the increase action with an incorrect quantity. This led to the negative Accumulated amount. • Solution The business logic for generating master plan action messages has been corrected. When the system finds an open purchase order, it generates an action on the purchase order that increases the quantity regardless of the Maximum order quantity. At the same time, planned production orders have the Cancel action. |
\Classes\ReqCalc\actionCalcDimTransSum |
| #10696 | Not available | If a purchase order was created as a planned purchase order and then it was firmed, the warehouse was not transferred from the order header to the order lines. | • Problem If a purchase order was created as a planned purchase order and then it was firmed, the warehouse was not transferred from the order header to the order lines. The issue occurred because when a planned purchase order was being created, the CovInventDimId field in the ReqPo table was filled with an incorrect value. This occurred because, in the first phase of creating the order, the system was not aware of InventLocationId. Therefore it could not find the correct InventDim to fill in CovInventDimId. However, instead of filling in CovInventDimId from VendTable, the system left the CovInventDimId field filled with the ‘Axapta’ value. Finally, this led to transferring of the blank value to the PurchLine table. • Solution The algorithm of populating the PurchLine table while creating a purchase order from the planned purchase order has been modified to ensure that the warehouse is specified correctly. |
\Classes\ProdPurch \Classes\ReqTransPoMarkFirm \Classes\ProdUpdCostEstimation |
| #11613 | KB908067 | Changing the values of the BOM and Route fields to a different version on the Setup tab in the Planned order form did not affect the attached Bill of material in the Derived requirement form or in the Explosion form for the planned production order. Also, when firming the planned production order, change of the BOM version or the Route version was not respected. | • Problem Changing the values of the BOM and Route fields to a different version on the Setup tab in the Planned order form did not affect the attached Bill of material in the Derived requirement form or in the Explosion form for the planned production order. Also, when firming the planned production order, change of the BOM version or the Route version was not respected. The issue occurred because the BOMId value initialized in \Classes\BOMSearch\newReqCalculation was based on the not updated reqPo table with the non-current ItemBOMid. The reqPo table in \Classes\WrkCtrMasterData_Req\update that had CacheLookUp equal to the NotInTTS parameter, was incorrectly updated. • Solution The code has been modified so that initialization of the new BOMId in \Classes\BOMSearch\newReqCalculation is handled correctly. TTS is skipped before executing doUpdate() for the ReqPO table in \Classes\WrkCtrMasterData_Req\update. |
\Data
Dictionary\Tables\ReqTrans \Classes\BOMSearch \Classes\WrkCtrMasterData_Req \Forms\ReqTransPo \Data Dictionary\Tables\ReqPO \Classes\ReqTransFormPO |
| #11781 | Not available | Requirements for the sales order lines were not displayed in the Net requirements form when the user created a sales order with several lines and then immediately ran Forecast scheduling for all items. | • Problem Requirements for the sales order lines were not displayed in the Net requirements form when the user created a sales order (Accounts receivable > Sales order) with several lines and then immediately ran Forecast scheduling (Master planning > Periodic > Forecast scheduling) for all items. The issue occurred because, in \Classes\ReqCalcForecastItemTable\insertData, the committed inventSumTTSLog entries were deleted. Therefore, the Master scheduling of the ‘Net change’ type did not work when Forecast scheduling was executed for deleted records in InventSumTTSLog. • Solution The code has been modified to prevent the deletion of the committed inventSumTTSLog records when Forecast scheduling is being executed for all items. |
\Classes\ReqCalcForecastItemTable |
| #11824 | Not available | Capacity reservations for actual production orders and projects were not considered when planning with a plan other than the two default plans (parameters). | • Problem Capacity reservations for actual production orders and projects were not considered when planning with a plan other than the two default plans (parameters). If finite capacity planning was enabled, this led to incorrect results because planned orders were allocating resources that were actually already allocated to actual orders. Therefore, planned dates were unreliable and potentially incorrect. The issue occurred because reservations for actual orders were loaded only if ReqParameters::autoUpdateDynamicPlan() returned TRUE. In particular, this was the case when the current plan was the default static plan and the default dynamic plan existed, but was not the current plan and if auto copy was enabled. • Solution The code has been modified so that reservations for actual orders are always reloaded. If the current plan is the default dynamic plan, only reservations from that plan are loaded. For every other plan, actual reservations are loaded from the default dynamic plan, all planned reservations come from the current plan. |
\Classes\WrkCtrSlotConflict \Classes\WrkCtrReservedSum |
| #12969 | Not available | Production order capacity reservations were deleted upon job rescheduling starting with the second operation when the status of jobs from the first operation was not set to ‘Ended’. | • Problem Production order capacity reservations were deleted upon job rescheduling starting with the second operation when the status of jobs from the first operation was not set to ‘Ended’. The scheduling is based on the specific JobId, which is specified in the ProdParmScheduling table. When the job rescheduling was being executed, transactions were not created in the WrkCtrCapRes table if JobId was specified. • Solution Modifications have been made so that the capacity reservation is not deleted if there is a job rescheduling when the status of jobs from the first operation is not set to ‘Ended’. |
\Classes\WrkCtrScheduleJobs |
| #13166 | KB911745 | If the user set up an inventory dimension group so that Master Planning was done with Coverage Plan by Dimension and set up a Warehouse hierarchy, then planned transfer orders could be created when MRP was run. If a planned transfer order was converted to a planned purchase order and Master Scheduling was run on only that item, the planned transfer order was not removed from planned orders. | • Problem If the user set up an inventory dimension group so that Master Planning was done with Coverage Plan by Dimension and set up a Warehouse hierarchy, then planned transfer orders could be created when MRP was run. If a planned transfer order was converted to a planned purchase order and Master Scheduling was run on only that item, the planned transfer order was not removed from planned orders. When Master Scheduling was run for the second time on the chosen item, the \Classes\ReqCalc\deleteItemRequirement method does not delete the record from ReqTrans with RefType == ReqRefType::TransferDemand. However, if a planned transfer order was converted to a planned purchase order, the pair for ReqRefType::TransferDemand record with RefType == ReqRefType::TransferPlannedOrder was converted to RefType == ReqRefType::Purch. That is why the planned transfer order was not removed. • Solution The code of \Classes\ReqCalc\deleteItemRequirement has been modified to add more checking so that if the pair for the ReqTrans record with the ReqTrans.RefType == ReqRefType::TransferDemand type exists with the ReqTrans record with the RefType == ReqRefType::TransferPlannedOrder type, the record cannot be deleted. |
\Classes\ReqCalc\deleteItemRequirement |
| #13628 | Not available | Future days might have been calculated incorrectly if items had issue or receipt margins. | • Problem Future days might have been calculated incorrectly if items had issue or receipt margins. The \Data Dictionary\Tables\ReqTrans\futuresDaysBaseDate() display method was called from setFields() on the same table to calculate future days as FutureDays = FutureDate - futuresDaysBaseDate(). The method returns ReqDate for BOM line transactions and ReqDateDlvOrig for all others. The future date should be calculated based on ReqDateDlvOrig at all times. • Solution The futuresDaysBaseDate() method stays unchanged for the display purpose. It is no longer used in the actual calculation. Instead, the calculation is changed to FutureDays = FutureDate - ReqDateDlvOrig. |
\Tables\ReqTrans |
| #13985 | Not available | The BOM number and the route number were lost when the user created a manual planned production order. | • Problem The BOM number and the route number were lost when the user created a manual planned production order (Master planning > Planned orders). The issue occurred only when the user had a BOM where the From date and To date fields were filled in. The issue occurred because of the incorrect initialization consecution of BOM number, route number and Delivery date in the \Data Dictionary\Tables\ReqPO\Methods\initFromItemId method. The Delivery date was initialized after the BOM and Route numbers initialization. However, to choose the BOM and Route numbers the system should know the delivery date, so the delivery date should be initialized first. • Solution The \Data Dictionary\Tables\ReqPO\Methods\initFromItemId method has been modified to eliminate the issue. The Delivery date (ReqPO.reqDate) field is now initialized before BOM number and route number initialization. |
\Data Dictionary\Tables\ReqPO\Methods |
| #15355 | Not available | Capacity reservations were deleted if Futures messages were set up on a Master plan, but were disabled on a Coverage group. | • Problem Capacity reservations were deleted if Futures messages were set up on a Master plan, but were disabled on a Coverage group. The issue occurred because the system always returned TRUE in the mustTransBeFuturesMarked method regardless of what was the value of the Futures messages option in the Coverage group. • Solution A check has been added to the mustTransBeFuturesMarked method so that the system checks the Future messages option in the Coverage group with other checks and returns the corresponding ‘TRUE’ or ‘FALSE’ value. |
\Classes\ReqPlanData\mustTransBeFuturesMarked |
| #15356 | Not available | The system stopped responding when a new user was created, upgrade to Service Pack 4 was performed and then newly created user tried to release a production order. | • Problem The system stopped responding when a new user was created, upgrade to Service Pack 4 was performed and then newly created user tried to release a production order (Production > Production orders > Update > Release). The issue occurred because, when the query was run and the database returned more recently inserted records, records were deleted and inserted repeatedly. • Solution The code of the \Classes\ReqCalc\covCreateSafetyInvent method has been modified to insert the required transactions outside the loop. |
\Classes\ReqCalc\covCreateSafetyInvent |
| #15792 | KB912473 | When the MinMax coverage code and Max order quantity were used, the system did not suggest enough planned production orders. The customer could not use min/max together with the Max order quantity. | • Problem When the MinMax coverage code and Max order quantity were used, the system did not suggest enough planned production orders. The customer could not use min/max together with the Max order quantity. The system did not create enough planned orders to fulfill the maximum quantity when the MinMax rule was set and the order’s quantity options were defined. • Solution The logic has been corrected to create enough planned orders to fulfill the maximum quantity when the MinMax rule is set and the order’s quantity options are defined. |
\Classes\ReqCalc\ |
| #16118 | Not available | A sales forecast for an item could be entered in the Item form by clicking Forecasting > Sales. | • Problem A sales forecast for an item could be entered in the Item form by clicking Forecasting > Sales.The core of the issue was that the user could not extrapolate the old forecast to a new forecast because the inventory forecast was not updated correctly. When the sales forecast value was updated with the selected Quantity field by using the Edit budget transaction form, the \Classes\ForecastMani\setField method updated only the SalesQty field in the ForecastSales table according to the specified Factor and Constant parameters. • Solution The \Classes\ForecastMani\setField method has been updated. The inventQty field has also been updated according to the Factor and Constant parameters and salesQty in the Edit budget transaction form. |
\Classes\ForecastMani |
| #17154 | KB919130 | When full master planning regeneration was run for all items, the Net requirements form was not populated with serial numbers. When a single item was run by using master planning or when the net requirements plan was updated, all the serial numbers appeared. | • Problem When full master planning regeneration was run for all items, the Net requirements form was not populated with serial numbers. When a single item was run by using master planning or when the net requirements plan was updated, all the serial numbers appeared. The issue concerned the \Data Dictionary\Tables\InventDimParm\Methods\isFlagReqCalcOptimal method where the dimFields container holds a list of ids from the InventDim table, but the elements was compared to the InventDimParm field ids. • Solution The isFlagReqCalcOptimal() method has been modified. The elements are now converted to the InventDimParam field ids before comparing. |
\Data Dictionary\Tables\InventDimParm |
| #17197 | KB919697 | When the user opened master scheduling for an item set up to be stocked in a quarantine warehouse, the planned purchase order and the quarantine orders showed an incorrect action message. | • Problem When the user opened master scheduling for an item set up to be stocked in a quarantine warehouse, the planned purchase order and the quarantine orders showed an incorrect action message. The issue occurred in the \Classes\ReqCalc\actionCalcDimTrans method where the receipt quantity was moved to another receipt transaction depending on the quantity obtained from the reqTransCov (the receiptCov variable) transaction. The quarantine receipt transaction contributed to creating an incorrect RecTransCov transaction and therefore, an incorrect action message. • Solution The \Classes\ReqPlanData\mayTransBeActionCovTo method has been modified so that transactions with the quarantine ‘refType’ are filtered out. |
\Classes\ReqPlanData |
| #18180 | KB923208 | Pegging was incorrectly updated in the Master planning explosion and not according to the reservation. This caused false lead-times and incorrect delivery dates. | • Problem Pegging was incorrectly updated in the Master planning explosion and not according to the reservation. This caused false lead-times and incorrect delivery dates. The ReqTransCov records were incorrectly updated in the Master planning explosion. The system updated the ReqTransCov records not considering a reference to RecIds. This led to an incorrect reference between the ReqTransCov table and ReqTrans. The remaining ReqTransCov record after the update had an incorrect IssueRecId and referred to the deleted ReqTrans Issue. The pegging was not shown in the Net Requirements. • Solution The code has been modified to update the pegging correctly. The remaining ReqTransCov refers to the correct ReqTrans issue. The pegging is shown in the Net Requirements. The system considers the current coverage and creates a planned purchase order for a sales order. |
\Classes\ReqTransUpdate\updateLogAddQty \Classes\ReqTransUpdate\updateReqTransCov |
| #18303 | KB921061 | A future date for a sales order was suggested when the order was already referenced to a started production order. | • Problem A future date for a sales order was suggested when the order was already referenced to a started production order. The issue was caused by the incorrect calculating of future dates for production orders with the status equal to or greater than ‘Started’. • Solution The \Classes\ReqCalc\futuresCalcDimTrans method has been modified to avoid future date calculations for production orders with the status equal to or greater than ‘Started’. |
\Classes\ReqCalc\futuresCalcDimTrans |
| #18496 | Not available | If a sales order line had a delivery date outside the coverage time fence, then, if the delivery date was moved within the coverage time fence, the sales order explosion did not pick up the line. | • Problem If a sales order line had a delivery date outside the coverage time fence, then, if the delivery date was moved within the coverage time fence, the sales order explosion did not pick up the line. During the explosion update, the system processes records in the InventSumLogTTS table. If the delivery date was changed on a sales line, the system should update the related record in the ReqTrans table. However, if the previous sales line delivery date was outside the coverage time fence, the system did not create the ReqTrans record. In this case later, when the delivery date was moved within the coverage time fence, the system could not find the related ReqTrans record for update and did not create a new requirement. Later, during the explosion update, the system did not find any requirements and the sales order explosion did not pick up the sales line requirement. • Solution The explosion functionality has been modified and if the delivery date is moved within the coverage time fence, the sales order explosion picks up the line. |
\Classes\ReqTransUpdate\createReqTrans \Classes\ReqTransUpdate\updateLogAddQty \Classes\ReqTransUpdate\updateLogfields |
| #18555 | KB924651 | When user used the Item requirement statistics per month by period, the output was incorrect. | • Problem When user used the Item requirement statistics per month by period, the output was incorrect. The issue occurred because an unnecessary suffix was added at the start of the period string in the intvMthName method of \Data Dictionary\Tables\ReqPO. • Solution The code has been modified so that the counter from the Filter Week field does not appear in the Period field. |
\Data Dictionary\Tables\ReqPO\Methods\intvMthName \Data Dictionary\Tables\WrkCtrCapRes\Methods\intvMthName \Data Dictionary\Tables\WrkCtrCapRes\Methods\intvWkName |
| #18558 | KB924109 | When the user created a planned transfer order and tried to click Go to the Main Table in the shortcut menu for the planned purchase reference: Transfer requirements number in the Pegging form, the Reference type and Number of Pegging record was changed after closing the Net requirements form. | • Problem When the user created a planned transfer order and tried to click Go to the Main Table in the shortcut menu for the planned purchase reference: Transfer requirements number in the Pegging form, the Reference type and Number of Pegging record was changed after closing Net requirements. While the Net requirements form is opening, in the tmpReqInventDim.linkActive data source method, the system was tying to find reqTransCaller – from which reqTrans record the form was called. The issue was caused by an incorrect execution of the ReqTrans.findCommon method when reqTrans.RefType == reqRefType::TransferDemand. In this case the system was positioned to an incorrect record onto the ReqTrans table when the Net requirements form was opened from the Planned orders form and then closed. • Solution The ReqTrans.findCommon method has been modified to avoid positioning onto an incorrect record in the Pegging form. |
\Data Dictionary\Tables\ReqTrans\Methods\findCommon |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #10399 | Not available | When the user trying to create a sales line for modeling enabled an item and calculated the delivery date in the Approval dialog box in the Enterprise Portal, the date was not calculated. | • Problem When the user trying to create a sales line for modeling enabled an item and calculated the delivery date in the Approval dialog box in the Enterprise Portal, the date was not calculated. The issue occurred because of the calculation of the delivery date implemented in a Web-class. In Enterprise Portal, the sales line and sales order are created after the user completes the creation dialog box. However, for the delivery date calculation, the sales line should be presented when the user tries to calculate it. • Solution The code has been modified to emulate creating a sales order and sales line while calculating the delivery date. The delivery date is calculated from the Enterprise Portal’s Product Builder Approval dialog box and from the standard dialog box in Microsoft Dynamics AX 3.0. |
\Forms\PBAFrontEndWebApprove\Methods\init \Classes\ReqCalcScheduleItem_PBAWeb\main \Classes\PBARunApproveFormsWeb\clickedCancel \Classes\EP\createSalesOrder |
| #12106 | Not available | When users used the table selection from the InventSize table, itemid was not displayed correctly in the Product Builder module. | • Problem When users used the table selection from the InventSize table, itemid was not displayed correctly in the Product Builder module. Different inventory dimensions were shown correctly, but all were shown with the same itemid although they belonged to different itemid's. The issue occurred because the tmpVal map was filled incorrectly. • Solution The algorithm for filling in the map of values for the selection list has been modified. Keys and Values have been shifted to avoid overwriting Values with the same Keys. |
\Classes\PBAValidationWin\varTableValAdd |
| #15002 | Not available | The Product Builder module had a mistake in storing the user's configuration selections for a model. The selections were stored in a separate table as copies of the originals. | • Problem The Product Builder module had a mistake in storing the user's configuration selections for a model. The selections were stored in a separate table as copies of the originals. Therefore, when updating the value in the original table the change was not reflected in the Product Builder configuration attached to the sales order line. The issue occurred because the PBATableInstance table kept the user’s configuration selections as values in the Value column. Therefore, the changes in the original were not propagated to this table. • Solution The code has been modified to store the RecId references to the original data when it deals with the primary keys for the ‘Table’ type Product Builder variables. When it loads the values, the system verifies whether the original has changed and updates the Value field with the new value. |
\Data Dictionary\Extended Data Types\PBAValueRef \Data Dictionary\Tables\PBATableInstance\Fields\ValueRef \Data Dictionary\Tables\PBATableInstance\Methods\postLoad \Data Dictionary\Tables\PBATableInstance\Methods\update |
| #15107 | Not available | Error messages that contain information that a product model did not exist for an item were displayed when users ran the consistency check. | • Problem Error messages that contain information that a product model did not exist for an item were displayed when users ran the consistency check (Basic > Periodic > Consistency check) even when the Product Builder license code was removed from the license. The issue occurred because the check of PBAItemId and ItemId on SalesLine and PurchLine was made without considering the situation when an item is not connected to a product model, the modeling is not enabled or when the license code for Product Builder is disabled. • Solution An additional check has been created in the checkItemPbaId method to avoid error messages during the consistency check. |
\Data Dictionary\Tables\PurchLine\Methods\checkItemPBAId \Data Dictionary\Tables\SalesLine\Methods\checkItemPBAId |
| #15847 | Not available | If a modeling variable of the ‘Table’ type was created and the number of a new record in the corresponding table defined in the properties of the variable exceeded 255, it was not possible to select a record index higher than 255 in the list of the Product Builder user dialog form. | • Problem If a modeling variable of the ‘Table’ type (Product Builder > Setup > Modeling variables) was created and the number of a new record in the corresponding table defined in the properties of the variable exceeded 255, it was not possible to select a record index higher than 255 in the list of the Product Builder user dialog form (Product Builder > Product models > Functions > Test model or Accounts receivable > Sales order > Functions > Configure line), because the value was immediately changed to the value that corresponded to index = new_value - mod(new_value/256)*256. The Table field of the PBATmpBuildForm table was bound to the Extended data type of the ‘Enum’ type to create the combo box control for the Product Builder user dialog form. However, this Extended data type was not connected to any enum to make the storage of the table records available. That is why the Table field could not contain a value higher than 255 like enum. Therefore, neither could the combo box. The value with an index higher than 255 selected in the combo box was automatically changed by the kernel to the value that is in range of 255. • Solution The DataField control (connected to the Table field of the PBAtmpBuildForm table) has been replaced with the combo box control that is not connected to any field with a particular name (TableControl). The controlMethodOverload property of the PBAFrontEndControl form has been set to TRUE, which makes the dynamic modified method overloading available for a control. This method should be named as controlName_modified(), which behaves like any modified method for a control. That is why all the controls for the table variables have the same names. The method is needed for setting the values of the table variables in the PBAtmpBuildForm table and invoking the validateField method on this table, which starts the sequence of rule validation. Previously, variable values and controls were distinguished by their names. Names for tables are the same now; names are distinguished by data source ids, because data sources are also created dynamically for every variable. |
\Forms\PBAFrontEndTree \Forms\PBAFrontEndForm \Data Dictionary\Tables\PBATmpBuildForm \Classes\PBAValidationWin \Classes\PBAValidation \Classes\PBABuildForm \Classes\PBABuildFrontEnd \Classes\PBABuildFrontEndFormWeb |
| #16100 | Not available | Performance reduced significantly when large product modules were compiled. | • Problem Performance reduced significantly when large product modules were compiled. The issue was caused by the call to the \Classes\PBALib\strLineCount method inside the while loop condition in the \Classes\PBALib\codeNodeParser, which means that the routine to count the number of lines ran when for every line in the code snippet. • Solution The code has been modified to provide declaring of a local variable and call the \Classes\PBALib\strLineCount method when in the \Classes\PBALib\codeNodeParser method. |
\Classes\PBALib\codeNodeParser |
| #18482 | KB924180 | When the user created a default route in the Modelling tree node and then used the default route ID to create the route node, an error occurred if a route was added after the last route (or before the first route) presented in the default route. | • Problem When the user created a default route in the Modelling tree node and then used the default route ID to create the route node, an error occurred if a route was added after the last route (or before the first route) presented in the default route. The issue was caused by the insufficient determining of the OprNumNext field (the next operation) for the last route added from the default route. The affected methods are PBALib.createRoute() and PBALib.trimRoute. • Solution A link to the next operation for the route created from the default route is added if this route has the Next operation field filled in. |
\Classes\PBALib\createRoute \Classes\PBALib\trimRoute |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #1872 | Not available | The reversed route transactions were displayed in the Work in process report. If the user deleted the production order, the route transactions still remained in the report. | • Problem The system reversed route transactions when the status of the production order was reset to ‘Released’, ‘Scheduled’, ‘Estimated’, or ‘Created’, which is a correct behavior. However, the reversed route transactions were displayed in the Work in process report (Production > Reports > Balance > Work in progress). If the user deleted the production order, the route transactions still remained in the report though they had no sense because they were not supposed to be in the report at all. The ProdRouteTrans table has the Cancelled field, which is a flag that states whether a production order is cancelled or not. When resetting the status of a production order to either ‘Released’, ‘Scheduled’, ‘Estimated’, or ‘Created’, the createLinesProdRouteTrans() method of the ProdJournalCreateRoute class changed the value of the Cancelled field to ‘Yes’, while in other cases this field was set to ‘No’. • Solution The code has been modified to filter route transactions in the ProdResourcesInProgress report according to the status of the Cancelled field. |
\Reports\ProdResourcesInProgress |
| #3074 | Not available | Item transactions were split or incorrectly saved after changing the value of the Good quantity field and then deleting the record without saving it in the newly created Report as finished journal. | • Problem Item transactions were split or incorrectly saved after changing the value of the Good quantity field and then deleting the record without saving it in the newly created Report as finished journal (Production order > Journals > Report as finished). When the value of the Good quantity field in the newly created Report as Finished journal was changed and the record was deleted without being saved, cashed values of the ProdJournalProd.qtyGood field were used in the \Data Dictionary\Tables\ProdJournalProd\Methods\delete and \Data Dictionary\Tables\ProdJournalProd\Methods\subProdtableRemain methods. • Solution The \Data Dictionary\Tables\ProdJournalProd\Methods\delete method has been modified to avoid using an incorrect quantity from the buffer. |
\Data Dictionary\Tables\ProdJournalProd\Methods\delete |
| #4368 | Not available | Under certain circumstances the scheduling of secondary operations was aborted and incorrect error messages appeared claiming that there were insufficient resources. | • Problem Under certain circumstances the scheduling of secondary operations was aborted and incorrect error messages appeared claiming that there were insufficient resources. The ProdJobWorkCenterTable\loadWrkCtr() method loads all work centers for a work center group into an array excluding all work centers already used for the same operation (primary/secondary). Individual workcenters are then assigned to jobs based on a fixed index (see ReqJobUpdate\createAllProdJobs and createOneProdJob). If the index was out of bounds, the conflict occurred. • Solution The code has been modified so that ProdJobWorkCenterTable has two new class level maps: mapRequiredJobType and mapRequiredWorkCtr. The idea of these maps is to obtain a full picture of all requirements for an operation including all primary and secondary operations before assigning them to specific jobs. ReqJobUpdate\createAllProdJobs and createOneProdJob have been changed to update these maps instead of assigning a final work center to reqRouteJob. The final assignment is completed only when the full situation is known: see modified ReqJobUpdate\run, calling the new method insertProdRouteJobWrkCtrId. This method updates reqRouteJob after matching requirements to available workcenter resources (ProdJobWorkCenterTable\matchWrkCtrRequirements). matchWrkCtrRequirements first takes all workcenters requested by the operation and stores them in mapAvailWrkCtr. Unlike mapRequiredWrkCtr, the key to this map has both values filled, both workcenter group and id. With the mapAvailWrkCtr map the matching can start. Specific work centers go first, followed by work center groups. Every oprPriority#numPrimary#numSecondary combination is always handled by one and the same work center for all job types. Each time a match is made, the available load% in mapAvailWrkCtr is decreased accordingly. If no work center can fulfill a requirement, an error message is shown. |
\Classes\ProdJobWorkCenterTable \Classes\ReqJobUpdate \Classes\ProdJobUpdate |
| #9408 | KB902417 | Incorrect material consumption was calculated when the "Standard but Rounding-up Measurement" formula was used in the setup of a BOM line. | • Problem Incorrect material consumption was calculated when the "Standard but Rounding-up Measurement" formula was used in the setup of a BOM line. When the user created a production order with Production quantity equal to ‘600’ and then updated its status to ‘Estimated’, the estimated quantity on a production BOM line was calculated incorrectly if a BOM line had the following setup: Formula = Standard, Quantity = 1, Per series = 600, Rounding-up = Measurement, Multiples = 1. The issue occurred because while calculating the calcDim1 variable in the \Classes\BOMCalcConsumption\calcConsumptionPrim method, ‘1’ was divided by a very small figure. The same issue occurred with calculation of the calcDim3 variable. • Solution The calculation of variables has been modified to avoid the rounding of decimals. |
\Classes\BOMCalcConsumption\calcConsumptionPrim |
| #9512 | Not available | When the user tried to register a production order item from the Report as finished form with the quantity bigger than the ordered one, an error occurred. | • Problem When the user tried to register a production order item from the Report as finished form (Production > Production orders > Update > Report as finished) with the quantity bigger than the ordered one, an error occurred. When the select forupdate statement from the ProdTable table was executed in the system for the first time and after that all the ttsbegin statements were closed by ttscommit, the ProdTable table still had the forupdate property. However, in the next marked transaction without the explicit select forupdate statement from the ProdTable table the ProdTable.doUpdate function caused an error. • Solution The \Classes\InventTransWMS_Register\updateInvent method has been modified to avoid problems with the old select forupdate and ttsbegin - ttscommit statements. When the user clicks the Posting button in the Registration inventory form, the ProdTable table is reselected now with the forupdate statement. |
\Classes\InventTransWMS_Register\updateInvent \Data Dictionary\Tables\ProdTable\Methods\findRecId |
| #10210 | Not available | It was possible to set the ‘Production’ BOM line type for an item, which had the ‘Item’ item type by changing it in the BOM form (Production > Production orders > BOM). | • Problem It was possible to set the ‘Production’ BOM line type for an item, which had the ‘Item’ item type by changing it in the BOM form (Production > Production orders > BOM). The issue occurred because the validation of the BOM line type field value was absent in \Data Dictionary\Tables\ProdBOM. • Solution Validation code has been added to check the value of the BOM line type field. |
\Data
Dictionary\Tables\ProdBOM \Classes\ProdBOMType \Classes\ProdBOMType_Phantom \Classes\ProdBOMType_Production |
| #10481 | KB898442 | If the user posted a production picking list, the production order obtained the ‘Route consumption’ status. However, if the user did the same for a production order, the remaining status became ‘Report as finished’, which was incorrect. | • Problem If the user posted a production picking list, the production order obtained the ‘Route consumption’ status. However, if the user did the same for a production order, the remaining status became ‘Report as finished’, which was incorrect. The issue occurred because the ProdRoute.BackOrderStatus field was not set when firming. • Solution The code has been modified to set the ProdRoute.BackOrderStatus field when firming. |
\Classes\ReqTransPoMarkFirm |
| #10631 | Not available | The accumulated scrap percentage was not calculated correctly for the route operation in the Route form (Inventory management > Items > Route, General tab, Accumulated field) during the Route updating operation (Route > Functions > Route updating) when a scrap percentage was specified for the work center (Basic > Work center groups > Work centers button, Operation tab, Scrap percentage field). | • Problem When a scrap percentage was specified for the work center (Basic > Work center groups > Work centers button, Operation tab, Scrap percentage field) and a new route was created for an item (Inventory management > Items > Route, Create route button) and a new operation was added, there was an error in the calculation of the accumulated scrap percentage (General tab, Accumulated field) for the operation with this work center specified during the route updating operation (Route > Functions > Route updating). The accumulated scrap percentage was always equal to ‘1’. When the scrap percentage was equal to zero for the route operation and the work center was specified, an error percentage was taken from this work center in the \Classes\RouteInventForm\ prodRouteDSExecuteQueryPre method, but the accumulated scrap percentage was not calculated in this case. • Solution The code of the \Classes\RouteInventForm class has been modified to correctly calculate the accumulated scrap percentage for the operation when the scrap percentage is specified for the work center during the route updating operation (Route > Functions > Route updating). |
\Classes\RouteUpdate |
| #10820 | Not available | If the user used the Route card journal to report a partial quantity for a production order as finished, the good quantity that was already reported from the Route card journal was not populated when the production order was reported as finished for the remaining quantity. | • Problem If the user used the Route card journal to report a partial quantity for a production order as finished, the good quantity that was already reported from the Route card journal was not populated when the production order was reported as finished for the remaining quantity. The issue was caused by a mistake in the code of the proposalQtyGood method of the ProdUpdReportFinished class. • Solution The calculation of the good quantity for reporting a production order as finished has been modified. |
\Classes\ProdUpdReportFinished\proposalQtyGood |
| #10858 | Not available | Status of the production order could not be updated to ‘Cost accounted’ (Production > Production orders > Update > Costing) for the item with several configurations if the Report as finished check box was selected because of an error in the Reported as finished journal. | • Problem When the production order (Production > Production orders) was created for a configurable item with different configurations and a configuration was selected, there was an error in updating the status of the production order to ‘Cost accounted’ (Production > Production orders > Update > Costing) with the Report as finished check box selected when the status was updated non-consequently (not step-by-step). The issue was caused by the partial initialization of data in the \Classes\ProdUpdReportFinished method when the status of the production order was not updated step-by-step. • Solution The code has been modified to correctly initialize data while updating the status of the production order to ‘Cost accounted’ non-consequently. |
\Classes\ProdUpdReportFinished |
| #10957 | Not available | When the user used the Copy function from the production route to base data route, it was not possible to copy contents of the Description field (the note) from the production operation. | • Problem When the user used the Copy function from the production route to base data route, it was not possible to copy the contents of the Description field (the note) from the production operation. The issue occurred because, when the user copied the data route by using base data to production data and production data to base data for transferring doc references, the needed RecId was not available in the routeOpr line. • Solution A new variable has been created that contains the line from the prodRoute table with the needed ReqId. |
\Classes\RouteCopyToRoute \Classes\RouteCopyToProd \Forms\RouteInventProd |
| #11576 | KB908794 | If the BOM Consumption check box was selected (in the journal lines or on the Setup tab in the Route card/Job card journal group), the route card created a picking list even if there was nothing to pick for that operation. Also, if posting a route or job card with the BOM consumption check box selected, a Picking list journal was created and posted when posting the Route card/Job card journal. If, for some reason (no inventory, missing dimensions and so on) the picking list could not be posted, it received (or kept) the ‘Locked by system’ status and no lines were present. | • Problem If the BOM Consumption check box was selected (in the journal lines or on the Setup tab in the Route card/Job card journal group), the route card created a picking list even if there was nothing to pick for that operation. Also, if posting a route or job card with the BOM consumption check box selected, a Picking list journal was created and posted when posting the Route card/Job card journal. If, for some reason (no inventory, missing dimensions and so on) the picking list could not be posted, it received (or kept) the ‘Locked by system’ status and no lines were present. The issue occurred because if the BOM Consumption check box was selected, the journals were created early in the posting process, before the actual consumption was known. • Solution The code has been modified so that in this situation the system deletes the Picking list journal if it detects that it is empty. And, if the created journal is not empty but an error occurs when posting a route card or job card with the BOM consumption check box selected, the newly created Picking list journal is not posted or locked and the lines are present so that the user can fix or add whatever information is incorrect or missing and then manually post it. |
\Classes\ProdJournalCreateBOM\isJournalEmpty \Classes\ProdJournalCheckPost\postProdJournalTableBOM |
| #12304 | Not available | The remaining on order transactions for the BOM components were deleted if the user cost updated a partially consumed and reported as finished a production order after having previously cleared the End job or Report as finished check boxes. | • Problem The remaining on order transactions for the BOM components were deleted if the user cost updated a partially consumed and reported as finished a production order after having previously cleared the End job or Report as finished check boxes. The issue occurred because the financial object in \Classes\InventUpd_Financial that had the remainPhysical and remainPhysicalUnit parameters was incorrectly initialized. • Solution The code has been modified to correctly handle the initialization of the financial object in \Classes\InventUpd_Financial. |
\Classes\InventUpd_Financial |
| #13007 | Not available | The BOM consumption parameter was ignored when the system updated a production order to ‘Report as finished’ and did not post the Picking list journal. | • Problem The BOM consumption parameter was ignored when the system updated a production order to ‘Report as finished’ and did not post the Picking list journal. The issue occurred because the \Classes\ProdJournalCheckPostProd\checkTrans method contained a mistake in the code. • Solution The code has been modified so that the system verifies whether the automatic consumption is set and if there is a Picking list journal created. Then, the system stops the report-as-finished update of the production. |
\Classes\ProdJournalCheckPostProd\checkTrans |
| #13439 | Not available | When the user maximized the Gantt form, clicked Refresh and then clicked Setup > Setup or Setup > Color, the maximized status of the Gantt form was not saved and size of the form was changed. | • Problem When the user maximized the Gantt form, clicked Refresh and then clicked Setup > Setup or Setup > Color, the maximized status of the Gantt form was not saved and size of the form was changed. The issue occurred because the design of the SysoperationProgressForm form had the WindowResize property set to ‘Fixed’. Therefore, whenever the form was shown, the maximized status of MDI windows was reset. • Solution The code has been modified to remember the maximized status of the Gantt form before the refresh action and to return this state after the refresh action is finished. |
\Forms\Gantt\Designs\Design\[ButtonGroup:ButtonGroup]\Button:Refresh\Methods\clicked \Forms\Gantt\Designs\Design\[ButtonGroup:ButtonGroup]\[MenuButton:MenuButton]\Methods\clicked \Classes\WinAPI\getWindowPlacement \Classes\WinAPI\isWindowMaximized |
| #13479 | Not available | When posting a Route card journal, capacity reservations were not updated even though the Update capacity plan check box was selected in the Production parameters form. | • Problem When posting a Route card journal, capacity reservations were not updated even though the Update capacity plan check box was selected in the Production parameters form. The functionality worked fine if the Production III license key was available. It should have also worked with the Production II license key, because capacity reservations and operation scheduling are not limited to Production III. \Classes\ProdJournalCheckPostRoute only updated capacity reservations if the ProdTable.schedStatus enum field was set (was not ‘None’). Possible values were ‘None’, ‘OperationScheduled’, and ‘JobScheduled’. Without the Production III license key, the value was always ‘None’ and capacity reservations were not updated. • Solution The ConfigurationKey property of \Data Dictionary\Tables\ProdTable\SchedStatus has been changed from ProdShop to ProdRouting. |
\Data Dictionary\Tables\ProdTable |
| #13842 | KB912781 | If the user partly updated the production order as report as finished
with the End Job check box selected, the remaining quantity of the
production order was not considered and there were no inventory
transactions with the quantity equal to the remaining one and the status
set to ‘Ordered’. However, if the user made a mistake when reporting the order as finished and then applied the Reset status function to reset the status of the production order to ‘Created’, ‘Calculated’, ‘Planned’ or ‘Released’, the inventory transaction with the ‘Ordered’ status was created again, but with an incorrect quantity. |
• Problem If the user partly updated the production order as report as finished with the End Job check box selected, the remaining quantity of the production order was not considered and there were no inventory transactions with the quantity equal to the remaining one and the status set to ‘Ordered’. However, if the user made a mistake when reporting the order as finished and then applied the Reset status function to reset the status of the production order to ‘Created’, ‘Calculated’, ‘Planned’ or ‘Released’, the inventory transaction with the ‘Ordered’ status was created again, but with an incorrect quantity. The issue occurred because, when resetting the status of the production order from ‘Reported as Finished’ to ‘Created’, ‘Calculated’, ‘Planned’ or ‘Released’, the remaining quantity to be reported as finished was not considered if the Reported as finished quantity was less than the Scheduled quantity of the production order. • Solution The Reset status functionality has been modified to work correctly when resetting the status of the production order from ‘Reported as Finished’ to ‘Created’, ‘Calculated’, ‘Planned’ or ‘Released’. |
\Classes\ProdUpdStatusDecrease_Finished\endUpdateProduction |
| #13933 | Not available | After users created a production order, when one of the components was not available on-hand, it was not possible to reschedule a production order with the limited material after replacing the production BOM component with an item that was available on-hand. | • Problem After users created a production order, when one of the components was not available on-hand, it was not possible to reschedule a production order with the limited material (Production > Production orders > Update > Job scheduling form, the Finite material check box) after replacing the production BOM component with an item that was available on-hand. The issue was caused by an incorrect functionality of the production order scheduling. If the user scheduled the production order, then reset its status and ran the scheduling again, the old schedule dates from the ReqTrans table were used. • Solution Now when the user tries to reset the status from ‘Scheduled’, the planned orders (created by the last scheduling) is deleted and ReqTrans.FuturesDate is cleared to avoid using them in the following scheduling of the production order. |
\Classes\ProdUpdStatusDecrease_Schedule \Classes\ReqCalcExplodeProd \Classes\ReqCalcExplode |
| #16584 | KB912204 | When a phantom BOM was not linked to a defined operation, phantom routes were exploded with incorrect BOM levels causing incorrect scheduling sequence. | • Problem When a phantom BOM was not linked to a defined operation, phantom routes were exploded with incorrect BOM levels causing incorrect scheduling sequence. The \Data Dictionary\Tables\ProdRoute\Methods\findPhantomBOMFirst method returns the route line a phantom route is linked to (has to be completed before). The method handles three cases (parameters) in this sequence: 1) _oprNumPhantom; 2) _oprNumBOM; 3) _oprNumFirst. If a line with _oprNumPhantom is found, it is returned. Otherwise _oprNumBOM is searched and returned. If that line is not found, _oprNumFirst is searched and returned. When the phantom BOM was not linked to a defined operation (and therefore must be completed before the start of the parent), BOM.OprNum was equal to zero and _oprNumOffset held the number of the last route operation of an ancestor. Therefore, since BOM.OprNum + _oprNumOffset was passed to the findPhantomBOMFirst method, incorrect route lines were found and returned. • Solution The code has been modified so that if the Oper.No. field (Inventory management > Items > BOM > Lines > General tab) is blank, phantom routes is inserted before the first operation in the BOM. |
\Classes\ProdUpdCostEstimation \Classes\ReqTransPoMarkFirm |
| #16586 | KB915330 | When the user inserted new operations, the system did not schedule them correctly. It only reset the operations that were already reset to the ‘Started’ status. | • Problem When the user inserted new operations, the system did not schedule them correctly. It only reset the operations that were already reset to the ‘Started’ status. The issue occurred because the if (_prodTable.qtySched != _prodTable.qtyCalc)
code blocked the recalculation and newly added operations were not
included in the production costing when doing reestimation of the
production order when it is in the ‘Started’
status.• Solution The code has been modified so that when doing the reestimation of the production order when its status is ‘Started’, newly added operations are included in the production costing. |
\Classes\ProdUpdCostEstimation\costEstimateOperations |
| #16589 | KB916078 | When updating the production order as ‘Started’ or ‘Report as
finished’ with the End-mark route check box selected, the
operations in the Route card journal were not end-marked. Also, when updating the production order as ‘Started’ or ‘Report as finished’ with the End-mark picking list check box selected, the lines in the Picking list journal and the operations in the Route card journal were end-marked. |
• Problem When updating the production order as ‘Started’ or ‘Report as finished’ with the End-mark route check box selected, the operations in the Route card journal were not end-marked. Also, when updating the production order as ‘Started’ or ‘Report as finished’ with the End-mark picking list check box selected, the lines in the Picking list journal and the operations in the Route card journal were end-marked. The issue occurred because the incorrect _prodParmStartUp.EndPicklist parameter was passed in parmEndUpdate. • Solution The code has been modified so that the End-mark functionality is related to the correct journal. |
\Classes\ProdJournalCreateRoute\newReportFinished \Classes\ProdJournalCreateRoute\newStartUp |
| #17132 | Not available | If a sub-BOM Line type was set to ‘Phantom’ with Consumption is set to ‘Constant’, the consumption requirements of the items within the phantom BOM were incorrectly calculated when the user created a production order and ran the Estimation update. | • Problem If the sub-BOM Line type was set to ‘Phantom’ with Consumption is set to ‘Constant’, the consumption requirements of the items within the phantom BOM were incorrectly calculated when the user created a production order and ran the Estimation update. The issue was caused by an incorrect calculation of the consumption requirement of items expanded from the phantom BOM with Consumption is set to ‘Constant’. While exploding this sub-BOM the new consumption parameters were calculated, but the system did not consider the fact that Consumption is was set to ‘Constant’ in the phantom line. Therefore, the new Consumption quantity was calculated based on the parameters of the parent phantom BOM. However, the Consumption is parameter in the expanded line was not changed from ‘Variable’. • Solution The code has been modified to inherit the Consumption is parameter from the phantom BOM if the phantom has the ‘Constant’ consumption and the phantom line has the ‘Variable’ consumption. |
\Data Dictionary\Maps\BOMMap\Methods\initFromPhantom |
| #17445 | Not available | When the user had a phantom BOM with a zero quantity, which used the standard formula and had an item included that used the consumption formula calculation, then this item was included to the production BOM. | • Problem When the user had a phantom BOM with a zero quantity, which used the standard formula and had an item included that used the consumption formula calculation, then this item was included to the production BOM. When the phantom BOM exploded during estimation, its quantity was not considered in the top BOM. • Solution The code has been modified so that an item having the consumption formula that is included in the phantom BOM with the zero quantity are not included in the production BOM. |
\Data
Dictionary\Maps\BOMMap \Classes\ProdUpdCostEstimation \Classes\ReqTransPoMarkFirm \Data Dictionary\Tables\BOM \Data Dictionary\Tables\ProdBOM |
| #17701 | KB920337 | The scheduled start date and time for the operations in a sequence was calculated incorrectly after users ran master scheduling. | • Problem The scheduled start date and time for the operations in a sequence was calculated incorrectly after users ran master scheduling. The issue occurred because an incorrect date and time was scheduled in the \Classes\WrkCtrScheduleJobs\runRoute method while setting routeSchedDate and routeSchedTime for route operations from different levels in series. • Solution The code has been modified to correct the setting operation behavior correctly with the starting date and time. |
\Classes\WrkCtrScheduleJobs |
| #17810 | Not available | When the user set a production order to ‘Report as finished’ and specified a greater quantity (Good quantity + Error quantity) than was started with the Accept error option turned off, Microsoft Dynamics AX 3.0 posted this quantity without any errors. | • Problem When the user set a production order to ‘Report as finished’ and specified a greater quantity (Good quantity + Error quantity) than was started with the Accept error option turned off, Microsoft Dynamics AX 3.0 posted this quantity without any error messages showing. The issue occurred because in the \Classes\ProdJournalCheckPostProd\checkTrans method the quantity of common good and error RAF with the started quantity was not checked during the Report as finished process. • Solution The \Classes\ProdJournalCheckPostProd\checkTrans method has been modified to control the started quantity and Good quantity + Error quantity in the Report as finished process. |
\Classes\ProdJournalCheckPostProd |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #10226 | Not available | It was possible to bundle project jobs and indirect activities by using the registration forms. It was also possible for a supervisor to create registrations directly in the Calculate and Approve forms. The user could create bundles with project and indirect activity jobs in these forms and calculate registrations with bundled project/indirect activity jobs, which is incorrect. | • Problem Shop Floor Control enables employees to register on production jobs, project jobs, and indirect activities. Employees can create bundles of production jobs. This indicates that they work on several jobs at the same time. However, it was possible to bundle project jobs and indirect activities by using the registration forms. It was also possible for a supervisor to create registrations directly in the Calculate and Approve forms. The user could create bundles with project and indirect activity jobs in these forms and calculate registrations with bundled project/indirect activity jobs, which is incorrect. The issue occurred because the bundling properties were not checked for bundles of indirect activities and project jobs. • Solution The code has been modified to perform checking of bundles in the setSignInOutTransId() method of the JmgProfiles class. If an illegal bundle is detected, an error is set on the line. |
\Classes\JmgProfiles |
| #11055 | Not available | When an employee was absent from work, it was not possible to register two different absence reasons on the same day. | • Problem When an employee was absent from work, it was not possible to register two different absence reasons on the same day. When a new line was created in the absence grid in the Approve form, the Journal registration type field was not set to ‘Absence’. When the absence line was created during the calculation, the Journal registration type field was set to ‘Absence’, which made it possible for the user to select absence categories. The issue occurred because the handleNormTime() method of the JmgProfiles class handled the calculation of the norm time profiles that only handled only one absence zone. • Solution The code has been modified so that, by default, the Journal registration type is set to ‘Absence’. Also, the registration of multiple absence reasons has been made possible. |
\Forms\JmgCalcApprove |
| #11056 | Not available | When transferring registrations from the Shop Floor Control to the Project module, project dimensions were always used instead of the registration dimensions. | • Problem Employees can make registrations on project jobs by using the Shop Floor Control module. When such registrations are calculated, approved, and transferred, a project Hours journal is created. The time spent by employees on projects is transferred from the Shop Floor Control module to the Project module. On each registration in Shop Floor Control it is possible to specify the dimensions to which the registration should be associated. These dimension values are then used when transferring registrations to other modules. However, when project registrations were transferred, the dimension values that were defined on the project were always used. The issue occurred because, in the projJournalTrans.initFromProjTable() method, the dimensions were initialized with dimension values fetched from ProjTable. • Solution The code has been modified so that, in the JmgPostStandardSystem._projTime() method, dimension values on the ProjJournalTrans record is overridden by the dimension values from the registration after a call of the projJournalTrans.initFromProjTable() method. |
\Classes\JmgPostStandardSystem |
| #12239 | Not available | If, while registering production jobs, an employee reported the process job as finished before the setup job, the operation was not marked as finished in the Production module. | • Problem In Shop Floor Control, users can register time on production jobs based on route operations. A setup and process job id is assigned to each operation in the production route. Shop Floor Control can be configured in such a way that quantity and status changes that were made through registrations are reflected directly on the production. When both the setup and process job are reported as finished by using Shop Floor Control, the corresponding operation is marked as finished in the Production module. Also, if all operations are marked as finished, the production is marked as finished. However, if an employee reported the process job as finished before the setup job, the operation was not marked as finished, which is incorrect. The operation should be marked as finished regardless of the sequence the setup and process jobs are reported as finished. Shop Floor Control reports progress to the Production module through the Route card journals. The operation was not marked as finished because no journal was created based on the feedback on setup jobs. The creation of the Route card journals was handled by the _prodQty method of the JmgPostStandardSystem class. This method returned without doing anything if Shop Floor Control was detected to be running on the Route job level and the registered job was a setup job. • Solution The _prodQty() method has been modified so that if the operation is reported as finished, based on the feedback from a setup job, then a journal is created. In this journal, the Operation completed check box is selected. |
\Classes\JmgPostStandardSystem |
| #12244 | Not available | It was possible to delete indirect activities if they were already used in setting up a profile or payment agreement or when users were overriding either of these. | • Problem It was possible to delete indirect activities if they were already used in setting up a profile or payment agreement or when users were overriding either of these. Indirect activities were stored in the JmgIpcActivity table. There was only one delete action on this table pointing to JmgProfileSpec. This handled setup of profiles, but not overriding profiles. Also, the delete actions for the payment agreements and registrations were missing. • Solution The delete actions have been added to JmgIpcActivity to handle the setup of the profiles, payment agreements, and registrations. |
\Data dictionary\Tables\JmgIpcActivity |
| #12248 | Not available | In the Profile relation form, it was possible for the user to specify two different profiles that could be used in the same interval. In this case the system picked one profile at random to use as the employee's profile. | • Problem It was possible for the user to specify two different profiles that could be used in the same interval in the profile relations for a specific Profile group. In this case the system picked one profile at random to use as the employee's profile. The issue occurred because there was no validation on overlapping profiles. • Solution The validation of overlapping time intervals has been added to the validateWrite() method of the JmgProfileRelation table. |
\Data Dictionary\Tables\JmgProfileRelation |
| #12355 | Not available | If an employee working on a bundle, added additional jobs to this bundle in the Job registration form and entered start quantity, the start quantity was not registered in the system. | • Problem In Shop Floor Control,users can bundle several production jobs to indicate that an employee is working on several jobs at the same time. If an employee is already working on a bundle, additional jobs can be added to this bundle through the Shop Floor Control > Registration > Job registration form. However, when doing this, and entering a start quantity, the start quantity was not registered in the system. The issue occurred because the selected JmgTermReg record had an incorrect time. The JmgTermReg record was selected with the select statement that always returned the active registration for the employee with the lowest timestamp that can refer to the job, on which the employee was already registered on, before making the addition to the bundle. Therefore, the timestamp on the jmgTermReg record was not the one of the latest registration. • Solution The select statement that was mentioned earlier has been modified so that the active registration with the latest timestamp is selected. |
\Classes\JmgSignInJob_Form |
| #12556 | Not available | During the calculation of employee registrations, the time registered as absence was not deducted from the calculated overtime. | • Problem During the calculation of employee registrations, the time registered as overtime reducing absence was not deducted from the calculated overtime. The issue occurred because of an error in the code. • Solution The code that converts the time registered on illegal absence from type ‘Overtime’ to type ‘Standard time’ has been replaced. |
\Classes\JmgProfiles |
| #12971 | Not available | There were no dimension values set on the payment items generated based on the ‘Flex-’pay agreement lines if dimensions were taken from employees. | • Problem There were no dimension values set on the payment items generated based on the ‘Flex-’pay agreement lines if dimensions were taken from employees. The issue is that ’Flex-’pay items are the only wage type that is not generated on registration. Therefore, when generating the JmgPayEvents record, there were no dimension values assigned, because they were always taken from the registration. • Solution The transfer algorithm has been modified so that when a JmgPayEvents record with the wage type JmgPaySpecTypeEnum::FlexSub is generated, dimension values are set to those assigned to the employee if Shop Floor Control is set up to use employee dimension values. If Shop Floor Control is set up to use dimension values from jobs, no dimension values are set on the ‘Flex-’pay items. The modification is performed in the sumPayEventsSec method of the JmgProfiles class. During the iteration of time events, it is checked whether a ‘Flex-’profile time event is found. If so, dimension values are taken from the employee. Dimension values are not previously assigned to the event, because there are no registrations. |
\Classes\JmgProfiles |
| #14108 | Not available | An error occurred if the user tried to recalculate employee balances if two or more pay items existed for the same employee in the same period. | • Problem An error occurred if the user tried to recalculate employee balances if two or more pay items existed for the same employee in the same period. The recalculation of employee balances is handled in the JmgPayCount class. The sumEmployee method recalculates the balances for a specified employee. This method iterates pay items based on a count unit, and creates or updates entries in the JmgPayCountSum table. If the jmgPayCountSum record was to be updated, it was not selected for updating, which is incorrect. • Solution The code has been modified so that the JmgPayCountSum record is selected for updating in the sumEmployee method of the JmgPayCount class. |
\Classes\JmgPayCount |
| #14874 | Not available | When an employee registered on a switch code by using the Job queue registration form, a stop job registration was automatically created for each job the user was active on. | • Problem When an employee registered on a switch code by using the Job queue registration form, a stop job registration was automatically created for each job the user was active on. This means that after the user registered on the switch code, he or she was no longer active on any job, which is incorrect. Creating registrations in the Job queue form is conducted through the JmgTermSigning class. The issue occurred because the switch code jobs were handled exactly as an indirect activity of the ‘Job’ type in this class. • Solution The JmgTermSigning class has been modified so that switch code registrations are handled different from indirect activities of the ‘Job’ type . If a registration is made on a switch code, then the system does not request feedback and does not stop the jobs that the employee is currently working on. Preventing the feedback form to be displayed has been done by changing the JmgTermSigning.isFeedbackRequired() method. This method has been modified so that it returns FALSE if the user makes a registration on a switch code. Preventing jobs from being stopped has been done by changing the JmgTermSigning.stopJobs() and JmgTermSigning.stopBreak() methods. These methods have been modified so that if the user makes a registration on a switch code, these methods are returned immediately. |
\Classes\JmgTermSigning |
| #15132 | Not available | An error occurred if the user created a process registration directly from the Calculate or Approve form and wanted to edit the started quantity on this registration. | • Problem Users can create, edit, or delete registrations directly from the Calculate or Approve form in the Shop Floor Control module. On process registrations, users can change quantity reports by clicking the Quantity reports button in the Calculate or Approve form. An error occurred if the user created a process registration directly from the Calculate or Approve form and wanted to edit the started quantity on this registration. The issue occurred because the JmgStampJournalTrans record on which the start quantities are edited, was not selected for updating. • Solution To have the JmgStampJournalTrans record selected for updating, the setStartupQuery() method of the JmgProdStartupForm has been modified. |
\Classes\JmgProdStartupForm |
| #15231 | Not available | In the Missing clock-out form, the Date field could be left blank while the user entered the date and time for the missing clock-out, which created an invalid registration. | • Problem Shop Floor Control lets the user insert the missing clock-out registrations for employees who have already left. This is performed in the Calculate or Approve forms by clicking the Missing clock-out button. This displays a form that lets the user enter the date and time for the missing clock-out. However, the Date field could be left blank, which created an invalid registration. The issue occurred because the validateMissingTrans method did not validate the date and time values entered by the user. • Solution The code has been modified so that the Date and Time fields are also validated. If these fields appear to be not filled in, an error message is shown. |
\Forms\JmgMissingClockInOut |
| #16223 | Not available | The user was able to edit time stamps on the Times tab of the Electronic time-card form after the registration was edited and approved by the supervisor. | • Problem Users can enter time registrations by using the electronic time-card in Shop Floor Control. When employees want to edit their time registrations, they start by locking the day in the Electronic time-card form. Then registrations are entered and the day is unlocked again. After registrations are entered, a supervisor calculates the registrations. After registrations are calculated it should not be possible for employees to edit their registrations. However, it was possible to edit time stamps on the Times tab in the electronic time-card. The Electronic time-card form uses two data sources: JmgStampJournalTable and JmgStampJournalTrans. In the active() method of the JmgStampJournalTable form, the allowEdit property of the lower grid was set based on the Calculated field from the selected JmgStampJournalTable record. This handled the fields on the General tab, but not the fields on the Times tab. • Solution Instead of setting the allowEdit property on the grid, the allowEdit, allowDelete, and allowCreate properties of the JmgStampJournalTrans data source have been set according to the Calculated field of the selected JmgStampJournalTable record. This handles all fields based on the JmgStampJournalTrans data source. |
\Forms\JmgJobRegistration |
| #18011 | Not available | The sales price information set up in Project > Setup > Prices > Sales price – Hour was not transferred from the Approve form to the Hours journal in the Project module when the user registered time on projects by using the Shop Floor Control module. | • Problem Users can register time on projects by using the Shop Floor Control module. When an employee’s registrations are transferred from the Approve form, a project Hours journal is created. The issue was that lines in that journal did not have a sales price that reflects the setup in Project > Setup > Prices > Sales price – Hour. The issue occurred because the ProjHourSalesPrice::findSalesPrice() deprecated method was used instead of the ProjHourSalesPrice::findHourSalesPrice() method while initializing the Sales price field of the journal line. • Solution A call of the ProjHourSalesPrice::findSalesPrice() method has been replaced with a call of the ProjHourSalesPrice::findHourSalesPrice() method. |
\Classes\JmgPostStandardSystem |