Create or Clone a Payable

Follow

Comments

17 comments

  • Rebecca Ralls

    Just to verify that I am reading correctly: If a product is entered on an AP line (rather than being transferred from a PO), the Expense GL Account is still going to be populated from the Account default expense account instead of the product expense account?

    0
    Comment actions Permalink
  • Tony

    yes this is correct. If an AP is not created form a PO the default expense GL Account will be that set on the Account. If an AP is created from a PO the Default expense will be that of the product. You can overide the default in either use case. 

    0
    Comment actions Permalink
  • Rebecca Ralls

    Hi Tony, thanks for your response.  I'm not sure the most recent release conforms to your answer.

    In my testing of Financial Suite 3.7.2/ERP 3.5 (not sure if it is the same in other releases), if I add a product directly to an AP line, it is setting the expense GL Account based on the default expense GL account set on the vendor Account record and not based on the expense GL Account set on the product regardless of whether the product is marked as an Inventory product or not.

    Where if i put the inventory product on a PO and then create a payable from the PO, the product is - correctly - expensed to the Expense GL Account specified on the product.

    0
    Comment actions Permalink
  • Chad Meyer

    It seems that if you enter an AP with an error, pay it, you need to delete the Cash Disbursement to correct the error. This means that you lose the history of the voided check, unless you manually create a new Cash Disbursement with the same check number and mark it void.

    Is there a better way to handle this where the original voided check (Cash Disbursement) is retained?

    0
    Comment actions Permalink
  • Tony

    Chad,

    If you want to maintain al of the history you really need to book new adjusting entries. You can certainly void the cash disbursement, create a credit memo, apply it to the AP document and create a new AP record. 

    Thanks,

    Tony

     

    0
    Comment actions Permalink
  • JeaNae Remala

    It would be helpful if the GL Account Variables and GL Account # could be changed on A/P lines without having to delete cash disbursement batch (which could include dozens of checks), delete the cash disbursement,  un-post the A/P entry, make the quick GL Variable change, re-post the A/P,  re-pay the item, TRY to recreate a cash disbursement batch (good luck easily doing that when you deleted a batch that had dozens of checks in it), re-post the cash disbursement batch on the original date.  And if the bank rec has been completed already - you have to undo all of that work too.  OMG - two hours of work to make a quick fix to GL Variable or GL acdount posting error.

    The GL Variable or GL# doesn't change the $$ of the entry, the date it was posted, the date it was paid, the check number or cash disbursement batch it was posted in, or the bank rec it was included on.  Only the sub-classifications for reporting.  

    When many employees are entering POs, Invoices, etc. that eventually hit A/P, sometimes things get into wrong departments or GL Accounts.  The error isn't always evident until someone at a higher level is reviewing the F/S at month-end.  It's virtually impossible to make corrections easily, with out creating a ton of Journal Entries or undoing an entire month's work of work.

    Could this please be incorporated into a future release of Accounting Seed?  

     

    1
    Comment actions Permalink
  • Ryan Faulkingham

    Hi Jeanae,

    I understand your frustration around unposting and updating the variables, but this security is build in place so that users cannot easily change transactions, which will in turn affect all of the financial reports.

    An easier way to adjust a variable mistake is through a journal entry. Debit and Credit the same GL account, but just update the variable. The transaction will still have the incorrect variable tagged, but the reporting will be correct. 

    Feel free to submit a ticket to support with any other questions. 

    0
    Comment actions Permalink
  • JeaNae Remala

    Also, how can we revise standard GL reports to actually show transaction descriptions and other useful info other than transaction numbers? Our GL is so large, we have to download the standard  GL Activity report into Excel and there is not description that comes through, and since you can't drill down from the excel report, they are really of no value.  Thanks

    0
    Comment actions Permalink
  • Ryan Faulkingham

    Hi Jeanae,

    Depending on the report that you are running, try adding the "note" field as a column. This includes some helpful info like check numbers and references depending on which transaction is being reported on. 

    If you would like to see other specific fields, these could always be pulled over to the transaction object with a formula field. 

    0
    Comment actions Permalink
  • Rebecca Ralls

    Hi Jeanae,

    If you know how to create a custom report type, you can create a custom report type that pulls in ALL the good data from all of the related records using the edit layout feature, and then just use that as the basis for your GL reports instead of the standard transaction report type.

    If you don't, I can point you in the right direction, or set one up for you depending on your level of comfort with the system.

    I can be reached at rebeccaralls (at) gmail (dot) com.

    0
    Comment actions Permalink
  • Lloyd Leanse

    Ryan - I understand the point about security in your May 24, 2017 post  ("...this security is build in place so that users cannot easily change transactions") but each organization using Accounting Seed probably has slightly different needs for that kind of locking and it would be great if Accounting Seed would accommodate that variability.

    For example, AS could enable a permission which would enable a super user to, perhaps, check a box, edit the values in a bunch of GLAVs, GL Accounts, Accounts, Projects and Project Tasks, then uncheck that box to prevent even that super user from editing those values. In our case, for example, we would like to reassign Project and Project Task to a lot of records, and will probably want to again as our thinking about the schema of our Projects and Project Tasks continues to evolve.

    0
    Comment actions Permalink
  • JeaNae Remala

    I would concur with Lloyd.  The determination of what can be changed and by whom would work better for the users if this were determined through user permissions versus hard coded.  I understand certain fields can not be changed, but Projects/Project Tasks, GL Variables, GL Accounts on Paybles, etc. sometimes need correcting due to data entry errors and it is difficult to do this in many cases in the Accounting Seed product.

    0
    Comment actions Permalink
  • Rebecca Ralls

    Just as a counterpoint, I worked with Oracle - where you couldn't change *anything* after it had been posted for a couple hours and the only way to fix anything was through a journal entry - so I really appreciate that - while sometimes arduous - it is *possible* to go back and fix stuff in the original transactions.

    I tend to agree with Accounting Seed's current format which ensures that anything that affects/can change your financial reports is locked when the record is posted and the period is closed. Changing GL Accounts and GLAV Assignments will change your financial reports, and so it makes sense to me that there are a couple layers of security around changing these items once a record is posted and the period is closed.

    That said, there are a couple things that could really help curb some frustration with the ability to go back and fix errors - because everyone makes errors.

    • Projects & project tasks do not affect financials as they are not tracked in financial cubes, and I agree that it really would be nice to be able to edit those without unposting a record. But since they are written directly to the transaction record, I recognize the difficulty in implementing that change.
    • It would be SO MUCH BETTER if you could unpost and fix data in a reconciled transaction as long as you don't change the amount.  Having to unreconcile an item before fixing it is arduous (especially if you have to change many reconciled items at once) and prone to user error.  It's too easy to forget to go back and re-reconcile, and if there are several records it can be challenging to know what has to be re-rec'ed. (here's a feature request if you'd like to go vote &/or comment on it)
    • I think this is a work in progress & and has been somewhat addressed by recent releases - but the ability to fix a paid AP record without deleting the Cash Disbursement outright, can still be problematic.
    • The ability to open and close multiple periods at a go instead of having to manually open/close each period manually after waiting for the previous period to open/close would be greatly appreciated (feature request) - EDIT: OOOOH _ just saw this is a feature in the upcoming Daisy release! YAY!
    0
    Comment actions Permalink
  • Lloyd Leanse

    Under "Please Note" above this doc says:

    "After an account payable record has been paid, the system will not allow it to be un-posted. In order to un-post it, the associated cash disbursement must first be un-posted and deleted. This is a safety feature so that account payable amounts can't be edited after the record has been paid."

    However, it seems like we used to be able to delete the APD record, leaving the Cash Disbursement and Payable intact, unpost the Payable to edit something, repost it and then reapply the Cash Disbursement. If that isn't possible, I would like to suggest that this capability be added. It would still be very safe, since all Cash Disbursements are ultimately reconciled to the bank statement.

    0
    Comment actions Permalink
  • richa

    Craeted a Payable for a person Account . And the Payee field didn't populate.

    0
    Comment actions Permalink
  • Bao Do

    Hi Richa,

    When creating a Payable for a Person Account, the lookup field that should be populated is not the Account field but instead the Contact field.

    Thanks

    0
    Comment actions Permalink
  • richa

    Thank you so much.

    0
    Comment actions Permalink

Please sign in to leave a comment.