Chris Travers wrote: > Orders are not financial transactions. Also 1.2 shipping module only > hits orders, not invoices (not saying this is relevant to your > question, just being thorough). > > Otherwise, orders are basically pre-invoices and could be used as > draft invoices. >
For me it's the whole allocation of payments to invoices only which causes me issues. If there was more scope to track "prepayments" then the workflow would work better. I guess consider a medium sized ecommerce business to see the expected workflow (opentaps / ofbiz seems to model this well). - Customer creates shopping basket (kind of a quote) - Customer clicks buy. Now have an order - Some sort of payment process takes place to at least reserve the money - Stock allocated and packed - Create proforma invoice based on stock ready to be shipped (may be only part of an order) - Money drawn down (may have happened already for special orders or other special cases) - Check process that goods are not dispatched if payment not fully received - Dispatch goods - Some accounting person signs off that the invoices are valid and they become "part of the accounting system" Friends in other small businesses handle the above usually by having two systems. They have their operational system which is usually somewhere between Excel/Word and an order system like ZenCart. Then these orders are printed out once they are final and double entered (or imported) into Sage where they are then set in stone. The problem with SL/LSMB seems to be that we rush far too quickly into the "in Sage" step and there is not enough flexibility in the pre stages to track all the possible workflows where we want the order to stay fluid and editable. I guess another side issue is that only certain parts of an "invoice" are the legal invoice. Other aspects of that step, such as serial numbers, notes, etc are all just for our own purposes and technically part of "the order". For example in the UK an invoice is simply the piece of paper which has name, address, registered number, amount paid, vat, etc on it and has to be reproducable. The details of the order such as where it was dispatched, serial numbers, how the payment was taken, notes, etc are things we track only for our own benefit Additionally there is no requirement in any country I am aware of to track COGS for a given transaction going forward, ie you can fiddle with the accounting system as much as you like as long as you can reproduce the "invoice" sent to the customer. However, there IS obviously a point that these aggregated COGS must become set in stone and these will be various regulatory stages such as tax returns and company reporting - only at that point will the COGS need to become fixed and unchanging Does this help? Ed W ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
