Olivier Gagnon NC Red Ribbon

Yes. It's pretty simple. If there was a tax rate change in a nexus where you collect, and instead of creating a NEW code you simply updated the old one, edited transactions will recalculate using the changed rate. If you are 100% sure you always created a new code instead of editing the existing one, I think that takes…

The Landed Cost functionality does not support that, no. However, wouldn't this be solved simply by setting a Shipping and a Handling cost on the order?

Check the Help under Accounting : General Accounting : Working with Budgets

Try 'invoice' instead of 'Invoice'

Is this a client or user event script?

The Landed Cost functionality is very important because it is the only way to increase the value of an item by adding on costs from seperate charges. For example, if I buy a widget for 100$, I can add on shipping and customs duty of 25$ and 15$ (hitting those Expense accounts seperatly on another Bill, by the way), making…

Reopening the period itself should be fairly safe. It's touching transactions that kills ya. By far the most common problem I've seen is Tax Rates recalculating because there was a rate change applied since. That one is bad. There's a slight risk of COGS recalculating, but that would be due to a complicated issue with…

Ok, unfortunately I'm not fluent enough un python to spot if there's any problems in the RESTlet call code. As you said this is how you usually do it and it works, I'll asume there isn't. So, unfortunatly, I don't see by reviewing this what the problem is. Either the credentials aren't correctly passes, the role is not…

Check the documentation for nlapiSearchRecord() or nlapiCreateSearch()

Hmm, can't recall if this matters, but try using the type of 'transaction' instead of 'invoice' in this case. EDIT: Wait, sorry. I just saw this is a search for "Transaction Numbering Log". I have no idea if this type is exposed to scripting. But, that's definately the issue. You're saying type is 'invoice' - it definitely…

Well, that's a good one. Maybe the "create po" field is hidden on the SO, so NS can't use it? Dunno, but let me know if you figure it out!

Basically, no, the drop ship/special order functionality has no means of detect a SO vs something else. If you tick in the box on the item, it's always going to do it. The only thing that comes to mind would be to uncheck the Special Order checkbox on the item record, and then simply manually tick in the make special order…

I've used FIFO numerous time and it has always behaved correctly. I would file a Case with NetSuite to look at this issue, it certainly should not have done that.

Best way I recommend is to set different External IDs. So all the lines you want in the first Journal, you mark as, say, 1000. Then the lines of the second journal are 1001, etc.

Yes it will, tested that a while back. Simply put, if you close a period where a transaction uses your item, you'll never be able to change the account on that item. Unless you reopen. And for the love of all that is holy, do not reopen.

If the Invoice came from a SO, and doubly so if you have inventory, crediting the Invoice won't work. If you credit it, the SO will still consider itself fully billed and will not let you raise a second Invoice from it. Voiding or deleting would be simplest.

What was the error you received? My guess would be your currencies did not pass. Try writing them out instead of using ISO codes (e.g. "Japanese Yen"). It should match what is found Lists->Accounting->Currencies

No, that's odd. This is clearly saying you tried to import an account with the same name multiple times. Did you check you CoA in NS to see which accounts succeeded in importing? Try doing Add and Update instead of just Add.

If you are asking is this is a temporary issue, then it is not. This is As Designed. Well, more like "too complicated of a problem for NS to fix" rather than specifically as designes, but whatever. I believe there is an enhancement request out there to address this problem. If you need to change the account on an item that…

Non-Inventory items not posting to COGS upon fulfullment is a fundamental aspect of Netsuite and that item type. If you want an additional impact, you will need to use scripting to auto-create a Journal Entry upon fulfillment containing the GL Impacts you want.

The trial balance is the standard report. Just like a standard income statement or balance sheet. Nothing fancy. Has been doing this each time when ever I just run the standard report. The report may be standard but the layout may be custom. This is rather unlikely, since if you have no idea what the difference between the…

This is not possible, the link is permanently lost. Sorry. If it's really, really, REALLY bad, then you can ask for a rollback from NS support, but this is very, very expensive and of course shuts down your system for a little while. Maybe just setting a custom field as a soft pointer will do the trick? You'd better check…

NS should be doing this automatically - there is in fact no need to close your period for NS to do the automatic carry over. Did you customize your Trial Balance or Income Statement layouts?

Hey Evan, I was looking into Deferred Revenue reval as well for a client. I'd be interested in a summary of the solution, though I shudder to think of what they must have done to solve this problem. I'm thinking reverse the original Rev Rec journal and recreate it using foreign currency?

This is not done by customizing the form. When you are creating your new item, you must select Serialized as its type.

Indeed, no config. We've recently coded something like this for a customer. It's tricky, you have to think well about the context. Some stuff is easy - like Journals or the Expense tab on Bills, you can straight up read and control the classes and accounts and stuff, so that's pretty standard. There is a definate…

Ahhh You dropship, that's the reason right there. Drop shipped items never hit inventory so there is no COGS. You have to go look up the Vendor Bill to get the cost of the item. This is actually a long standing issue with comissions based on profitability and even the Estimated Cost functionality - both are unable to…

Well if you're seeing 0-cost Inventory Items, you have a much bigger problem than commissions. If like you say you have 0 cost because the item was never purchased, then you're selling items you don't have stock for. Which is physically impossible, but the problem here is going to be serious accoutning issues. You have…

We are implementing a customer that essentially wants the same as you are describing. In their case, we did a customization to automatically create Journal Entries upon Receipt and then undo them at Bill time. The process your describing for the creation of manual journals would work as well, albeit with a little less…

Right, you see correctly. NetSuite does not support this. We've achieved this a few times using customization, but it's not simple.