PO ledger posting

ddinh

Dear all,

Does anyone have request to setup for PO ledger posting in AX as below:

1. Post Packing slip/ Good Receipt to ledger account. The posting will be:

Packing Slip:
Db: Inventory account – Good received but not invoiced – temporary value
Cr: AP account - Good received but not invoiced - temporary value

Invoice:
2. Reversal Good received but not invoiced
Db: AP account - Good received but not invoiced – temporary value
Cr: AP/Vendor – actual value.

Any recommendation/suggestion would be highly appreciated.

Thanks,
David

AdamRoue

What is the issue with setting this up?

kranthi

ddinh wrote:

Invoice:
2. Reversal Good received but not invoiced
Db: AP account - Good received but not invoiced – temporary value
Cr: AP/Vendor – actual value.

When you post invoice - It will reverse the entry made during the Packing Slip.
and post the actual invoice.
The entries would be

Cr: Inventory account – Good received but not invoiced – temporary value
Db: AP account - Good received but not invoiced - temporary value

Db: Inventory Account.
Cr: Vendor Ledger Account.

ddinh

Thanks, but the purpose of this setup is that they don't want to see the reversal.

AdamRoue

So they do not want to see the reversal of the packing slip postings - what happens with cost differences?

Anyway slightly irrelevant, this this is the way the system works - explain why it works this way and the advantages, convince the user this is correct, it is a new system, get used to new ways, failing that quote them on how to compeletely re-write the posting routines and they will then agree they can live with the way it has been programmed.

ddinh

Many thanks AdamRoue,

Yes I do for sure convince our customer. But you know they did compare with they way their old system work named Primavera.

anyway, they are customer we should try to serve them in our best ability.

Thanks again,
David

AdamRoue

If you give in to each demand because the old system did this and did that then you will completely redesign AX to reproduce the old system, which begs the question why change? Whilst there are always elements that can be taken the customer has to understand the way the new system works, and work with it, redesigning the base functionality to mirror the old system will cost them a lot of money and will make upgrades very difficult - it it your job as the consultant to try as hard as possible for this not to happen.