@kyoung14 , notice that invoices are alao segregated for orders with different:customer locations id Terms Id customer tax zone idso, you can leverage by out of -box functionality, you can say setup a new customer location (tax zone, terms) for each new group of orders (probably, thorough a customization). Though this approach is not perfect, it will allow taking care of future invoices grouping at the moment of order entry Also, you might try to customize (override) the FindOrCreateInvoice function to take desired fields into account , but I am not sure how safe it is
@ray20 , such data consistency issues should be addressed as suport case since it is customer specificWe never recommend inventing your own data correction scripts - there are really risky
@ray20 , this issue is addressed by db scripts, but we do not provide them here (because data needs to be studied first)Please create a support case (unless created already) and Acumatica support will address the issue
@jeffrose90 , this is a product limitation. The Purchase Accrual Details report ‘considers’ accrual account to be debited when a purchase receipt was released. In the case of drop shipments, the release or receipt does not create GL entries and, yes, updates only accrual report, which leads to this temporary inconsistency.Depending on the process/requiments, I see two possible solutions:Use the Order Based billing for purchase order. This will allow to create AP Bills before PO Receipts and release PO receipts only immediately before Customer invoice. This will allow avoiding this discrepancy Set up a separate accrual account for drop shipments (possible by means of a customization or a separate warehouse for drop shipment). This will allow to reconcile a ‘real purchase’ accrual account with Purchase Accrual reports (where it should be reconcilable) and reconcile ‘billed but not invoiced’ drop ship accuals via different GI/report which can be built by the customer
Hello @ray20, As far as I understood the scenario, you create an IN Issue document with 2 lines: Credit Memo and Issue to correct the cost of inventory. In this situation, since the Credit Memo line in IN Issue doesn’t have any link to the original invoice, the system uses the Average Cost of inventory. At the same time, for IN Issues lines with the Credit Memo type users can manually correct the Unit Cost and Ext. Cost values Another option I can see here is to create an IN Adjustment document where Unit Cost and Ext. Cost values are editable. As it’s mentioned, that the amount in an Invoice is correct and only the cost of inventory should be corrected, it’s possible to create an IN Adjustment either with the only line and specify there the Qty and Ext Cost for adjusting or with 2 lines, the same way as in an IN Issue with Credit Memo and Issue types in your example: Hope this helps, @Julia Golomidova Thank you Julia, very much help. And it can be a solution.
@timrodman , Purchase Receipts screen supports entering barcode because it is designed to serve a business process necessitating scanning, Unlike it, the Issues screen is not primarily supposed to support such process. It is primarily designed for support of ‘manual’ inventory issues (correction on back office level) and helping to release documents originating from other modules in case of issues. Of course, there can be other usages of the IN302000 as described by you, but the newly designed IN302020 screen can be used for this
@timrodman , what about Scan and Issue screen (IN302020)?
@nvadera7 , can you clarify how vendor freight is going to be recorder in drop ship PO? as a line type of Freight type?Anyway, there is no ready out-of-the box functionality to transfer freight from drop ship po to so or invoice, but I believe it can be done via a business event or a customization - you can enter sales orders with Ship Terms having ‘Freight Source Based On’ = Order and ‘Override Freight Price’ = true when drop ship po is create and released, copy the freight amount from PO to the SOOrder.CuryFreightAmt field Then this freight will be copied to invoiceI believe it could be no issue to set up business event for this, Let me know if further advice here is needed
@ray20 , exactly.The InReceiptStatus table is always updated on FIFO basis (or to be more exact, certainly for FIFO, Average and Standard valuation, and probably also for Specific, though the latter needs checking) This table is just an auxiliary one, needed only to track remaining quantities for each receipt. It is not used for calculation of COGS according to valuation method, and so there is such degree of freedom
The InCostStatus table contains data with breakdown set by the Valuation Method. In your example, it is Average (ValMethod = ‘A’) which means that it should contain 1 line per stock item and CostSiteId (which is normally a warehouse but can be a warehouse location if location is set to be costed separately). So, here InCostStatus table has really blank data for ReceiptNBr and ReceiptDAte (‘1900-01-01’ and ‘ZZ’ stand for ‘blank’). It is only FIFO valuation method which makes these fields fill in the InCostStatusUnlike it, INReceiptStatus contains receipt nbd and receipt data for every inventory receipt/return. Basically, these data should be realiable (only exception are inventory adjustments which do not create new InReceiptStatus but update existing ones by selection of oldest open. So basically, this table should deliver data you request. If you see, it is new correct for some case, special ivestigation is required
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.