Credit without return to inventory to stock

I’m having some problems finding information on this. In a system I used to use, we could do a credit using the item number and choose to either return to stock, or not return to stock, scraping the item at the customer site. In Navision I have found that you can use Inventory Value Zero with the return orders module, but this would still create a quantity adjustment at zero cost. I saw someone suggested to put this quantity into a scrap location to separate it from my available qty on hand, but I still need to do something with the quantity. Also, creating this type of transaction also changes my average cost. I can do an inventory adjustment monthly to remove the qty from scrap location, but this item journal transaction puts a cost in, even if I blank them out in the journal. It also adjusted my average cost to zero after posting the journal. This seems like a pretty basic function, is what I looking for available at all in Navision?

From what I understand, the case is something like the Customer has an item that you sold them. The item is faulty and unusable, so you don’t wnat it back, BUT you want ot giv eth ecustomer a credit for the the item.

The way to do this is Navision is simple.

You create a Retrun Order or a Credit Memo to that Cusotmer. You create a line of type GLAccount, and select the account where you want the credit amonut to hit the GL. Post the credit, and done. In the case that you do this often, it may be easier to use a resouce instead of a GL Account, but you need to decide this according to your business practices.

There are many cases that you might not want to return the stock (i.e. the cost to return damaged goods exceeds the value of the return). Unfortunately the ability to not receive the goods back into inventory is missing in Navisions Returns Granule. However, in the return reason code you should select a dummy location and mark the zero cost for these type items. Then when you make the inventory adjustment (be sure to select the same location) to remove them from the inventory select the return line as the applies-to entry, this might keep the cost from being posted. I am hoping that Navision corrects this oversight in a future release. If you just make a credit memo and use a g/l account instead of the item through the returns module, then it will always overstate the units that you sold. I assume you are not using location SKU’s and that is why the cost is still calculated on the adjustment, since it uses the item card average cost rather than the location SKU average cost, that would be zero for returned items set to zero cost on return.

Instead of using a GL Account, you could also create a Credit Memo using an Item Charge and assign it to the sales item entry this credit memo pertains.

In this way you would be able to know for which item you made that return.

Thanks everyone, I’m going to take another look at charge items, I didn’t know I could apply it to a posted invoice, I thought only to items on that order. We are currently doing this using gl accounts, but having lots of trouble tracking back what items a customer has been credited for, and sometimes duplicating credits because of it. We’re currently having to read through each CM description to determine what item it was for. Hopefully this will be fixed in 5.0. I’ll also try doing the application when doing the item journal adjustment and see if that fixes my cost problem.

My approach would be to set up a return reason code called, defective

make it inventory value zero and default location “SCRAP”

do your credit and enter on the line the the return reason, this will bring the item back into the scrap location inventory at zero value.

Then once a month or so, run a physical inventory journal on the “SCRAP” location, and zero out the counted qty, post the journal. all items will be out of inventory. You will have a record of all defective items, the customer will be credited for the correct item, and your inventory will be correct.

this is not ideal but it will give you the detail on what parts have been credited, what was scrapped, ect. and is standard functionality.

Hi Teresa

Please ensure you are happy with the cost implications of bringing stock back in at zero and the timing issues over period ends if you process in this manner. Using an item charge or direct to G/L will prevent the cost fluctuation of bringing an item back into stock at zero.

The costing is my issue, however I’ve found that the item charges uses shipments to apply to, and we don’t use the standard navision shipments, so I have no invoices there to apply these to. Also, using the GL account doesn’t allow for tracking back to an item, this is our concern, with knowing what customers where credited for which items, so that a credit isn’t duplicated.

Sorry so if you do not ship the goods out what do you do?

If this is a modified area for you it maybe difficult to use standard item charges - but perhaps this is your best route - get them to work with your system!

The only other real alternative is to put it to the GL and in the second line define the item and invoice etc, and then at least you have a record of the transaction. However if there are enough transactions to warrant errors you really should consider getting item charges to work for you.

We do ship out our goods, but through a customization we did, in effect, the sales shipment line table never gets populated. I’m trying to get the system to use the sales invoice line table for the information, and it coming along well, but I still have to code deeper, item charges is deeply inbedded into the posting. Only thing with doing like this, I get a reference to the item number in the value entry, but not to the invoice that the credit is for, so that still leaves a gap, unless I was to also modify the value entry to store invoice number. I’m not sure how deeply I really want to modify this. I can use return order and return to a scrap location the only problem with that still is when I do an item journal to reduce the quantity, my costs are affected, and there is an actual cost placed on the value entry. We might just have to stick with using GL entries in the credits.

If you use the physical inventory journal as I mentioned above, you can change the posting group of the journal, so that the negative adjustment entry is made to the same g/l account as the inventory side of the entry,

for instance, I created a General Product Posting Group called “PHYSICAL” then for the set up the “Inventory Adjustment Account” is set to my g/l account for inventory adjustments (in my case) 602

Our inventory account is “115” so when I post a phyiscal inventory journal the negative adjustments credit 115 and debit 602

If I changed the adjustment account to be 115, then both the debit and credit would offset each other and the net would be zero cost to inventory. this is what you want.

the average item cost should be correct,

the average cost will not be correct if any movement hads happened to the item. In any fast moving, fast price changing industry the average cost can almost guarantee to have altered. In this scenario the exact cost reversing funciton should be used, but users do not like the additional required processing to get accurate costing in the system, whilst accounts don’t like the inaccurate fluctuations of costs if they don’t. Always a fun battle of wills this one.

As an idea Teresa have you tried exact cost reversing, bringing the items into a different location and running a periodic physical inventory journal on the location?

I am not sure if you are using SKU’s or of your actual costing method, and whether you have costing per location turned on, also not sure if you are using item tracking which adds cost differences in. I would have a look at exact cost reversing as well if I was you.

as far as I know the average cost should be correct following the suggestion by John:

  1. post the return from customer in a specific location e.g SCRAP - it should work also if you don’t flag “Inventory Value Zero”
  2. post a negative adj in SCRAP location applying to the item ledger entry created in 1 immediately after it - I don’t think that you can wait end of month a do a physical inventory to empty that location, because till then the average cost would be wrong, unless you are using cost by location.

Lets assume we have the following entries:

  • 03/01/07 purchase 10 unit cost 100 cost value 1000
  • 04/01/07 sale 1 cost 100
  • 05/01/07 purchase 10 unit cost 120 cost value 1200
  • 06/01/07 return 1 cost X
  • 06/01/07 negative adj 1 cost X
  • 08/01/07 purchase 10 unit cost 130

the average cost of the item should be

  • 03/01/07 average cost 100
  • 04/01/07 average cost 100
  • 05/01/07 average cost = (9100 + 10120) / 19

the average is impacted by the sale, but in this case the item is a scrap is not a return we can sell again.

If it would be a return then I agree with Steven that you have to use exact cost reversing, but this is not the case.

hope this helps.

obviously I don’t know your customization … and maybe you already know that in standard NAV you could create sales shipment document also when you post direct invoice. To do this just flag the field Shipment on Invoice in Sales & Receivables Setup

Hi Patty

I think the issue is caused where timings occur. You sell an item in January 2006, it is returned in October 2006, the credit is issues in December 2006, the negative adjustment is done in January 2007.

In a cost fluctuating business with currency involved accountants do not generally like the way these costs are then reflected on a monthly basis. However this is the downside of average costing and timing differences. Depending upon the set up they either flush through, or if you are truly average costed, they accurately reflect the average cost.

I think if we set the debit and credit account the same in the physical adjustment, like David mentioned, then this should work for us, regardless of what the cost is at that time (months after the original transaction), the item will go in and out at the same cost. We use average costing for some of our items, standard cost for most though. I think this will work for us, thanks everyone.

Sorry you’ll have to forgive me here.

Are you saying you return the stock into inventory and then remove it on a physical inventory journal where the adjustment code balances out the inventory asset account? I only ask as this leaves the value in the inventory asset account.

I am probably misunderstanding, but the return will increase inventory, the physcial adjustment has no affect, so it is left in inventory [8-)]

I know this post is 3 years old but I have one question.

I am using NAV 5.0 SP1.

I am thinking of going the route of creating a location for ‘scrap / warranty’.

So when i process the credit memo / return order, I want to make sure the Unit Price defaults in so the customer gets their credit, and i want to zero out the UNIT COST ($) field correct? This way it will go into my ‘scrap / warranty’ location at zero cost, and at the end of the month I can do an adjustment to get rid of quantity from my scrap / warranty location.

Unless there is something new in 5,0 SP1 that I don’t know about.

If you are scrapping it at the end of the month why write the cost in as zero - this will only mess up the average cost, write it in at the exact cost of the outbound, or the average and take the hit when you write it off.

I was only using this suggestion from earlier…

My approach would be to set up a return reason code called, defective

make it inventory value zero and default location “SCRAP”

do your credit and enter on the line the the return reason, this will bring the item back into the scrap location inventory at zero value.

Then once a month or so, run a physical inventory journal on the “SCRAP” location, and zero out the counted qty, post the journal. all items will be out of inventory. You will have a record of all defective items, the customer will be credited for the correct item, and your inventory will be correct.

this is not ideal but it will give you the detail on what parts have been credited, what was scrapped, ect. and is standard functionality.

If there is a better option, let me know. Thanks.