Showing posts with label AP. Show all posts
Showing posts with label AP. Show all posts

Thursday, December 9, 2010

AP or AR Accruals

This is a little trick that we've found useful to:
  1. shorten AP check stubs that were many pages long
  2. allow pre-processing of AR checks that settle against many invoices

AR
We had the situation where we were receiving advance notice of a payment coming from a customer (this could be useful for EDI, etc).  For us, the checks settle against lots of invoices - often in the thousands - and we wanted to do the work of settling the payment against the proper invoices ahead of time so that when the check actually arrived, it was quick to process.

We did this by creating Payment Journal 'accrual' transaction where there is a debit and credit canceled each other out. The offset account is arbitrary because the transaction just goes in and out.  In the example below, you can see two anticipated checks represented.  Note that the journal balance is 0 - no net effect.


Use the Function, Settlement button to settle one side of the transactions against the open invoices that will be paid.  This leaves a single open transaction to settle against when the check actually arrives.  (Alternatively, you can use the open transaction editing screen to do the settlement against the invoices)

AP
On the AP side, we've used this method to handle the situation where a check is paying for many AP invoices.  In this case the problem was that the check stubs were very long and caused many checks to be voided so that all the invoice lines could be printed.  We solved this by entering an 'accrual' Invoice Journal transaction and settling it against the many invoices.  Then the other side of the transaction is settle against by the Payment Journal and only one line shows on the check stub.

Wednesday, October 27, 2010

Mark All for Open Cust Trans and Open Vend Trans

We have situations where there are lots of open transactions that need to be settled against each other.  This can be the case if auto settlement is turned off.

One solution is to add a "Mark All" button to the custOpenTrans or vendOpenTrans forms.  This button "checks" the mark checkbox on every line.  The user can then uncheck several lines if needed and Update to settle the lines.

The code below is an example of what we used on the open vendor transaction screen.  The code is very similar on the AR side.  One note: I used vendTable.AccountNum in the code below.  That should be generalized to work with any buffer that is passed into the open trans form.

void customMarkAll()
{
    VendTransOpen   localVendTransOpen;
    VendTrans       localVendTrans;
    container       conSum;

    int             linesProcessed;
    ;

    //show wait cursor
    startLengthyOperation();

    element.lock();

    //remove all prior markings
    specOffsetVoucher.deleteSpecifications();
    settle.empty();

    ttsbegin;
    while select localVendTransOpen where localVendTransOpen.AccountNum == vendTable.AccountNum
    {
        localVendTrans = VendTrans::find(localVendTransOpen.RefRecId);

        specOffsetVoucher.create(localVendTransOpen.TableId,
                                             localVendTransOpen.RecId,
                                             localVendTransOpen.AmountCur,
                                             localVendTrans.CurrencyCode);

        settle.insert(localVendTransOpen.RecId,localVendTransOpen.AmountCur);

        linesProcessed++;
    }
    ttscommit;

    element.unLock();

    //calculate totals for display
    conSum = custVendSettle_Vend.openSumRemainAmount(common,currencyCode);
    remainAmountCur = conpeek(conSum,1);
    remainAmountMST = conpeek(conSum,2);
    element.initCashDiscTotal();

    element.initVendBalance();

    //refresh the screen with the calculated totals
    element.redraw();

    //remove wait cursor
    endLengthyOperation();

    box::info(strfmt("%1 Vouchers Marked",linesProcessed));

}

Wednesday, September 22, 2010

Purchase Order Print "Correct" Quantity

Standard AX functionality when printing an AP Purchase Order is to print the quantity of the Delivery Remainder (PurchLine.RemainPurchPhysical).  The Delivery Remainder is lowered as receipts are posted against the PO, so a PO that is printed after receipts have been posted can look confusing.  The PO will show a lower quantity and a lower dollar amount.

You can add the following code to class/purchFormLetter.createParmLine to show to total quantity of the PO: the delivery remainder plus the qty already received.

...
else
{
    [newPurchParmLine.ReceiveNow,  newPurchParmLine.RemainBefore      , newPurchParmLine.RemainAfter      ] = this.qtyPurch (_purchLine, naReal());
    [newPurchParmLine.InventNow,   newPurchParmLine.RemainBeforeInvent, newPurchParmLine.RemainAfterInvent] = this.qtyInvent(_purchLine, naReal());
}
//existing code above

//New Code: add the qty that was received already to the delivery remainder
if (purchParmUpdate.SpecQty == PurchUpdate::All && purchParmUpdate.DocumentStatus == DocumentStatus::PurchaseOrder)
{
    newPurchParmLine.ReceiveNow = _purchLine.RemainPurchPhysical + _purchLine.receivedInTotal();
}