[Erp5-users] Questions and answers about ERP5 Packing Lists, Accounting, Prepayments

[Vera Kurpas]

I had some questions concerning ERP5_trade and ERP5_accounting and
Bartek and Lukas answered them. I think the following information can
help other ERP5 uses. 

Q: Let's imaging that  I have the Packing List #1 which has the lines
with the same products as Packing List #2. Will they sum in Invoice if I
"ship" them together from list by "Change State"? Other words - do we
have aggregation?
A: yes. I mean, depends how you set up the system it is handled by
builders. You can aggregate by whatever you need.

Q: Are the account transactions built according to  invoice transactions
or according to PL?
A: Invoice transaction is an accounting transaction and it is built from
packing lists, but indirectly, through simulations which "atomise" the
PL so that a builder can aggregate as needed. Default aggregation is
1:1, so one packing list generates one invoice. But you can customise
builders to generate e.g. one invoice per month per customer, or
whatever.
Q: Does the builder make the automatic accounting entries?
A: Yes. When a builder generates an invoice, it adds invoice lines (what
the invoice is for) and accounting transaction lines.


Q: Could you explain what is the reason to repeat in
invoice the information from packing list?
A: That is general idea of document-oriented system in erp5. Same
applies to order <-> packing list <-> invoice. There is *causality*
workflow and having those information duplicated, you are able to have
business "view" of data - something keep in mind, that was ordered,
might it be that something different was delivered by packing list, and
something different was invoiced. 
Q: Order is the confirmation from the other party (like a part of a
contract). PL is a note of goods (resource) received. Invoice is
bookkeeping entries of sale (purchase) and resource movement?
A: Yes, yes, yes. You might try to run unit tests interactively to
see, what its done and why or try out express instance to figure this
out but in chain order, packing list, invoice. There is connection
between them by simulation system.
Q: I don't see the reason to repeat the information in invoice.
A: How otherwise you would be able to know, if what has to be
invoiced was invoiced?
Q: Interesting! Bookkeeping should the reflect the real quantity of
sold/purchased goods isn't it?
A: It is, thanks to delivery  builder and if you are sending
some goods, but adding transport to be invoiced what then?
Q: I have to make new PL or a line in PL.
A: You could have such configuration. Well - I do not see anything
wrong with data repetition in erp5. As you wrote - you might add
additional line to PL. Check unit tests.
Q: So did i understand correctly that information in invoice may not
be the aggregation of PLs? I mean can we have a line in invoice which
is
not from any PL?
A: Yes, of course. That's possible to have such situation. 
A: I think the repetition in invoice the information from packing list
is necessary because you can aggregate it in very different ways. So you
can't just hook invoice to packing list, because the invoice is doesn't
have to be related to any particular packing list. E.g. you ship many
products to many clients, but you pack things together per product and
per destination city (like sending a tank of oil to be delivered to all
clients in Odessa) and then you invoice a client for all deliveries in a
month. It is needed if one delivery is based on other, to know
divergences (differences) between them. Simulations are only some kind
of "precognition" what would happen, and documents with its states is
some kind of confirmation, that it will happen. So the invoices and
packing lists have entirely different structure and data. Therefore you
have data on PL, data on Invoices, and simulations between so that you
can check if all that has been shipped has also been invoiced. Delivery
can be fine-tuned by users, which are working on planned purchase
invoices.

Q: Don't your company make the prepayments?
A: No. Keep in mind, that system might be configured in a way that
after planning order, packing lists and invoice would be created, so
you'd be able to attach prepayment to invoice, treating its as future
accounting transaction, which need to be paid.
Q: That will not give me the possibility to know for what level is
the PO paid - especially if there are several prepayments. 
A: Some tips - BT5 are working example of ERP5 configuration. If
you are able to accept what is provided in them, at least for beginning,
that's good starting point.
A: Low level core of ERP5 is extremely configurable, even if in
few points some hand coding is needed. If your Payment Transaction will
for one PIT, which is for one PPL, which is for one PO than you are able
to figure out, how much is left to paid. But my advice is to start
playing with current working configuration to understand erp5 deeper,
than configure.
Q: Can't we use payment condition to generate prepayments?
A: Payment condition = trade condition. It is possible to use trade
condition as simulation modification to generate proper tree for
prepayment. But it might be possible to have more documents in planned
state after order simulation tree is generated, eg. packing list,
invoice and payment transaction in payment state and then automatic
adoption of simulation changes from "left to right", in sense from
order, through packing list and invoice to payment. That's how I feel it
is designed.

Thanks a lot to Bartek and Luke.

Vera Kurpas