Skip to main content

When we try to confirm a shipment on the Shipments screen after a few seconds of processing we get an error saying this file already exists.  This is on a system we are preparing to go live with and have recently restored a snapshot (Settings and Business Accounts) which cleared out all the previous SOs and Shipments etc. I suspect a file is still present from testing previously but don’t know what file or where or even how to start to find out where or what it is. This seems to be only happening with Ship Via that are UPS based.

Does anyone have any idea how to troubleshoot?

Thanks,

Trace:

Phil

@ppowell Yeah I have an idea what might be happening. I have gotten into the guts of Acumatica’s label printing before. I noticed in the call stack there is a reference to rotating a UPS Label, so presumably that’s what we’re trying to attach here.

Acumatica uses a single file that is attached to the record to store label files. It is always the “zero record” in the array of attached files. I don’t remember whether it is visible or not to the end user… you can look in the attachments section of this record to see if you can find it. If more than one label is created, or you add a label where there was previously only one, it will refresh this file and create a single document with all labels for printing.

It’s likely that whether you can see this file from the GUI or not, there is a reference to it remaining in the database. I think in normal operations, the system should automatically delete the existing file and refresh it with new labels. But perhaps the database restore impacted file pointers or whatever… not quite sure without more info.


@rosenjon Thanks for the pointer.  

The problem was that when restoring the snapshot we had attachments being restored and a previous label name clashed with one it was trying to create.  After going into ‘Search in Files’ and clearing our all labels created before the snapshot was restored it works again.

 

Thanks,

Phil


Because the file name for the UPS Label is based on the Tracking Number, this:

 

  1. Breaks immediately when testing (because the tracking numbers are all “1ZXXXXXXXXXXXXXXXXX “
  2. Will break within 9 months for a high-volume shipper because of UPS re-using tracking numbers.

Is there a way to manipulate the filename so that it’s always unique?


@Jacob 

Breaks immediately when testing (because the tracking numbers are all “1ZXXXXXXXXXXXXXXXXX “

 

What breaks immediately?


@rosenjon 

 

The “This File Already Exists” error reoccurs.  UPS test mode returns a Tracking Number of “1ZXXXXXXXXXXXXXXXXX” for all labels.  That file gets stored with a name of “Label #1ZXXXXXXXXXXXXXXXXX.ZPL”  So, the moment I run a second Test Label, I get the “File Already Exists” error.


@Jacob Got it. I didn’t realize you were in test mode and UPS is returning the same tracking number every time. I guess the assumption is that (in production) even if UPS does recycle tracking numbers, the likelihood you ever get issued the same tracking number across all the different UPS customer in the world is probably really small.

I can think of a few different ways to fix this. The one I would probably do is go in with DnSpy, and modify the code for this connector to randomize the UPS tracking number received by UPS, when the tracking number matches the test tracking number. Then there will be no conflict.

Note to the Acumatica development team...it’s probably always a good idea to randomize file names that are based on some external identifier. For example, if the UPS tracking number is ABC123, then:

ABC123 + “-” + date() + rand(5) +this is just pseudocode]

Now the likelihood that we ever have a conflict is effectively zero. It also helps with debug, because we always know the date that the file was posted to the system, even if this isn’t tracked anywhere else. So if we get into a debug situation where we’re not sure how a file ended up somewhere, we have a useful piece of information about when the file post happened. If we want to reject files that are duplicates, we can do that deliberately, not as a result of the system failing due to a duplicate file name.


@rosenjon

Duplicate production tracking numbers are more common than you think.  I have over 250,000 from the last 8 years, some with a window as small as 9 months and an average window of about 3.5 years.


Duplicate production tracking numbers are more common than you think.  I have over 250,000 from the last 8 years, some with a window as small as 9 months and an average window of about 3.5 years.

@Jacob Wow, that’s crazy. I stand corrected!

If you are a programmer, I can walk you through how to fix this with dnSpy. If you aren’t, you may be out of luck, unless Acumatica has a fix.


@rosenjon I am a programmer (and have a team of them available).  A Timestamp to the millisecond appended to the file name should be sufficient, unless there are some unknown filename length constraints with DeviceHub.

 

We are still new with acumatica and haven’t done much customization (and nothing yet with dnSpy).  Any insights would be helpful!


This is from PX.Objects.SO.SOShipmentEntry.ShipPackages…(see below code snippet)

So yeah.. you can see that packageData.TrackingNumber is the file name, and packageData.Format is obviously ZPL (based on what you posted above). ZPL is a popular format for printing to a label printer.

So you could add a line similar to:

if(packageData.TrackingNumber == “1ZXXXXXXXXXXXXXXXXX”)

{

  var tracktest = System.DateTime.Now.ToUniversalTime();

  var faketrackingnumber = “1Zxxxxxxx” + tracktest.Substring(0, 10);

  packageData.TrackingNumber = faketrackingnumber;

}

A few things here:

  1. Editing the assembly in dnSpy is ok for testing purposes. Doing it for a production system is probably not so good. It sounds like this edit is mostly for testing UPS labels...but we’d have to discuss more if this will be required in the production system or not.
  2. If you do need the functionality in the production system, maybe using PXOverride would be better (shoudl be more upgrade proof than ediitng the assembly directly (.dll).
  3. The code I suggested will probably work, but should be tested against file length limitations, etc. It has not been tested or run in real life at all, so you should definitely do that before using it in any system.
  4. Also...you will need a development system where you have access to the Windows layer in order to edit assemblies and use them (there may be some way to upload an edited assembly through the Acumatica customization editor, but I don’t know how).
if (packageData.Image != null)
{
FileInfo fileInfo2 = new FileInfo(string.Format("Label #{0}.{1}", packageData.TrackingNumber, packageData.Format), null, packageData.Image);
try
{
uploadFileMaintenance.SaveFile(fileInfo2);
}
catch (PXNotSupportedFileTypeException innerException2)
{
throw new PXException(innerException2, "The carrier service has returned the file in the {0} format, which is not allowed for upload. Add the {0} type to the list of allowed file types on the File Upload Preferences form.", new objecto]
{
packageData.Format
});
}

 


Hi @Jacob,

I see that your partner has logged a Customer Care case on your behalf for this.  I added this Community thread to the case.

-thanks

Dana


Hi @Jacob - did you find a solution for this one? Thank you!


Reply