Sage 100

Customized a Packing Slip form (v2013) in which some fields are conditionally suppressed based on the value of the SkipPrintCompLine. Purpose: if the line is a kit item, print a set of field data. If a component, print a different set of field data. The fields sit on top of one another on the form. When printed from Shipping Data Entry, data displays as desired. When the packing list is printed for an invoice from history, the suppression isn't working. I can see the data when I DFDM the line in inv. hist. line, but there is nothing in the worktable. I'm thinking it's a bug, and the data isn't getting passed to the worktable. Before I open a case with Sage, can anyone tell me if they have encountered this and found it's something else?

Credit card post-auths are the same way. It's the same work file, but the fields are populated differently. I usually just create a different form to use when printing from history.

Hey Bill - What would you do differently to the form?

I tried this once too and it didn't work. I think the conflict is in the work file and the location the form is now being called from. It doesn't jive. Packing lists don't generate from historical data. I know the form still calls out the same crystal work file and theoretically speaking should work regardless of where I call the form from. But in this case I suspect that there is a link behind the scene since this work table pulls data from shipping entry, and the work table itself is no longer being populated with data. Now the work file is only a template. I ended up replicating the shipment in a copy company and generated the forms I needed that way. (That's my story and I'm sticking to it)

From the way back machine, I 've encountered the issue. As I recall, the data appears differently in the open SO/packing/invoice tables than it is stored in the AR history tables. Not sure if we created a UDF in SO to store the data which is passed to the history table and brought back during reprints. I thought is was crazy at the time and probably still is crazy. Right hand/left hand consistency issues. That is my story that I will deny I ever said it........

I'll recommend the workaround, and appreciate your input @JoanSerr. I think that if invoices can be printed from history, so should packing lists (and I'm sticking to my story, too) :-) What, nobody ever forgets to put put the packing list in the box?

Hey send a note to Diane Coffman. She is looking for quick fixes....

I can confirm that once the invoice is updated you can no longer rely on work file and instead need to utilze AR invoice history header/detail tables. You can create and ask them to use a different form when printing from history or drop in a sub report to replace just the data not coming across. We had to do two sub reports just to bring across freight terms and 2nd sales person when reprinting invoice from history. In crystal you can also use the function ""Set Data source location"" to copy and remap the old form specific fields to use history files rather than work table. I used this function in the past to map old versions of crystal reports to newer file structures with differnt field names or tables, and it worked like a charm.

Are the UDF's sourced from both files (AR history and SO Entry)?

Can you join the history file to the work file and get at the data that way?

Wishful thinking. Is there a way to add the packing list to Paperless?

@JeffSchwenk - I will drop a line to Diane Coffman. And thanks to all for the input.

So there's more to the story. I tried adding the AR History Detail table to the form. When I didn't get the right result, I found that the value of the SkipPrintCompLine field gets written to AR History Detail as a ""Y"" for the kit item (no change to the value if it's a component item). For the record, the ""Print Detail"" box in Sls Kit Maint is unchecked. If it's checked, the value of this field is set to ""Y"" in S/O Entry. Will check with client to see if they want me to open a case or use @JoanSerr's workaround. Or try @JeffSchwenk's.

You can look for a blank cost of goods sold account to identify kit component items in AR History Detail. I have several reports/forms using that. Not sure if that is universal or controlled by a setting somewhere but I checked several of our clients and they were all that way.

That is exactly what I was talking about. The SO value is changed when it is updated to AR history. I dug into the way back machine to the form in question (five years ago) and I think this is the suppression formula used to control the display of the line. Client closed their doors 3 years ago so I don't have access to a current form.... formula = {SO_InvoiceWrk.ItemType} in array ("""", ""4"") or _ PreviousValue({@InvoiceNoLineNo}) = {@InvoiceNoLineNo} or _ ({SO_InvoiceWrk.SalesKitLineKey} <> """" and {SO_InvoiceWrk.ExplodedKitItem} = ""N"") or _ {SO_InvoiceWrk.ExplodedKitItem} = ""C"" Unfortunately, I am not very fluent in Crystal so this may or may not be the key.....

I think I got it licked - waiting for the client to give me final approval. I used @BernieLehman's suggestion and used the COGS account in my suppression criteria. Now, who has Diane Coffman's email address?

Diane.Coffman@sage.com Ext 347016