I have done this both ways, either filling in the missing information (in the tables), or deleting from the tables and starting over. I personally would opt for the deleting and starting over.

-Victoria

Thanks,
Raul

It may be possible, but will depend on the specifics of how you enter data into GP. Table IV30301 has a list of ‘related’ receipts and sales of inventory which you can link to table IV30300 for more detail. If the way you enter receipts and your inventory item set up allow it, you should be able to use these tables to determine what receipts of inventory went to which sales invoices. From there you can link back to the POP10500 table to determine the PO numbers for your inventory receipts.

-Victoria

Thanks.
Aaron

Excellent – glad you were able to find a solution.

-Victoria

That’s a bit past the level of code that I typically post on my blog, as it can get very complicated, very quickly. This kind of coding is something that my company can provide as a consulting project if you are interested.

-Victoria

Thanks
Raouf

To have the line item not repeated for each serial number you would need to have the serial numbers in a separate section of the Crystal report – take a look at the sample SOP reports included with GP Reports Viewer for an example of this. The serial numbers are in the Details a section. The section will grow as needed based on however many serial numbers you have for each line and is a quick and easy way to add serial numbers to your report.

I am not sure if it is possible to put multiple serial numbers on a single line separated by commas directly in Crystal. The way we have done this in the past is to create a SQL function to loop through the serial numbers and concatenate then into one string. Then that function is used in a stored procedure that the Crystal report is based on.

-Victoria

I suspect these are ‘orphaned’ records….so they probably should be deleted, but a much safer way of cleaning this kind of stuff up would be to run Check Links on the Sales series.

-Victoria

I’ve been using your site for several years now, and appreciate the quality and quantity of information you provide. Thank you for providing such a valuable resource.

I’ve encountered an issue where I have 126 blank invoices showing up in the SOP10100 table dated for 1/1/1900. If I try to edit these, I get the message that they are already posted. I can write a query to simply delete these records from SOP10100, but was slightly concerned about side effects. Do you have any suggestions on a different way to handle these?

Thanks,
Chris

From what you’re describing a couple of thoughts come to mind:

• If the only objective is to print individual packing slips per ship to address, why not create all the ‘customers’ as ship to addresses under one customer (Groupon), put the appropriate ship to address on each sales order line and then make sure your packing slips print one report per ship to address on the line item level? This may actually be the default behavior in GP, you’d just need to double check this.
• There is a product from Trinity called consolidated invoicing that may be able to help: http://www.trinitypartner.com/products_and_modules/consolidated_invoicing.htm

-Victoria

We are still fairly new to GP and are on GP2010. We do a lot of business with .coms and recently ran a Groupon for our products. When we do this, we ship from our warehouses to the consumer but we invoice the retailer. We have to enter the orders separately to generate packing slips for the warehouse but then we end up creating an invoice for every sales order. For Groupon, this means a thousand invoices to a customer we made up. We have to invoice obviously to update inventory but these invoices never go out to either the consumer or to Groupon who pay us automatically. Is there a way to group a whole bunch of sales orders to the same customer id on one invoice? We would like to be able to do all for a day or even a week at a time.

Thank you very much!

Scot

Definitely not a known issue and unfortunately in a heavily customized environment that is most likely the culprit. It may also not be something in the code that modifies the SOP10100 or SOP10200 tables directly, you may be looking at too limited of a scope.

-Victoria

Thank you for your prompt response. We are currently on Dynamics GP 10.0 SP5 but have had this same issue since at least version 8.0. As for are we heavily customized, unfortunatley the answer is yes. I am new here at the company as their GP developer and I am currently reviewing the code for anywhere the SOP10100 and or the SOP10200 tables are modified or updated by the code. Before I got too deep I though I would check and see if this was a known issue that had a fix or process in place to stop it from happening.

Thanks again,

Lonnie

Sounds like you have tried to duplicate this and are not able to, so this may be a really tough one to troubleshoot. I have not seen this happen with out-of-the-box GP under optimal conditions. However, I have seen similar strangeness happen once in a while in environments that were heavily customized and/or were experiencing connectivity issues on the network or resource issues on the server. I know this is a very general statement, but it is really impossible to get into specifics without a lot more details. If you said that this happens once a year with high transaction volume, I would maybe write if off as some crazy glitch. But if it is happening several times a week, then there is definitely something that is routinely causing this.

Is the issue actually seen if you look at the tables in SQL? In other words, do the line items actually make their way onto the incorrect transaction? Or is it simply a display issue where the data the users are seeing on the screen is not the same as what is in the tables?

Do you have any modifications, customizations or 3rd party products installed? Is the data being entered manually on the Sales Transaction Entry window? What version of GP, by the way?

-Victoria

We have been dealing with an odd situation at our company for years. It is impossible to duplicate using any set of criteria that I can come up with but still the issue occurrs several times a week. We have several people entering sales orders all day long. Every once in a while, the line items (SOP10200) from one order will end up associated with the order (SOP10100) that was entered by a different user. Have you ever seen this and if so, is there something I can do to stop this from happening?

Thanks,

Lonnie Nelson

Typically orders with no customer ID are orphaned records that just need to get cleared out…. Are these orders in SOP10100 or SOP30200? Have you run Check Links on the Sales Series to see if that clear these up?

-Victoria