Forums / Categories / PeopleSoft / Financials / Attachment Size Limitations

    Attachment Size Limitations

    Hello All,

    Next year we plan to require attachments to all non-interface journal entries.  The attachment will serve as backup.  Does your organization have attachment size limitation guidelines?

    Thank you in advance!

    Jo Ann Musgrave

    Director of Financial Information Systems

    Hi Justin - Thank you for the response!  Jo Ann

    Hi Jo Ann,

    We enforce this via file types.  We only allow .TIF black and white images to be attached.  We use a third party software "Image Now" to store the image on a file server and have the link back to PS.  We have imaging in almost every module including HR.  .tifs and bw attachments are substantially smaller.  I will say the business folks do not like not being able to attach excel or word in their native format.  They have to convert or scan to .tif.



    Hi Steve!

    Thank you for the response.  I really appreciate it.  Our IS Department landed on a 2MB size limit.  Attachments will be saved to a file server.  We will be giving our journal preparers guidelines on what to include in the attachments.


    Jo Ann

    Hey Jo Ann

    I think that enforcing any sort of size restriction is going to be difficult.  Most users don't really have the know-how to reduce the size of large files.  If, for example, the backup is a scanned document, the size could become very large quite easily and most users would not know how to reduce it, or even have the software on their computer to allow them to do so.  So, if you did have a size restriction in place, and a user had a file that was too big, they would be left to either violate the size restriction or violate the requirement to supply an attachment.

    If you are concerned about the overall volume of attachments, then I think it is important to have this discussion with your infrastructure folks.  You have the choice of putting attachments either in the database itself or on a separate file server.  There are pros and cons to each.  But, if you are expecting high volume, then it's probably best to use a file server in order to keep the size of your database at a manageable level.  High performance database storage is generally at a premium at most companies.  It's important to note that if you go with a file server approach, then there are extra steps you need to follow when you have dev/test environments to ensure that changes to attachments made in your test environment don't impact your production attachment storage.

    PeopleSoft Financials.

    Are you doing this within JDE E1?  If so, how is it working for you?  We have a separate custom application to store the JE supporting documentation.  We are looking to replace that, preferable in the long run with a SaaS application that we have a license for.  While in theory it makes sense to attach the supporting documentation directly to the JE, my concern is the massive DB growth that would occur if we allow users to do that within JDE.


    Kriss Lindell
    Director, Financial Applications
    Gallagher Technology Services | GTS Corporate Applications

Log in to reply

Looks like your connection to Quest Oracle Community was lost, please wait while we try to reconnect.