There are four documents: Purchase Order Purchase Invoice Sales Order Sales Invoice They all have common header with Company, Counterparty, Argreement, Number and Date fields. Also they have common tabular sections having Item, Quantity, Price and Amount columns.
I need to choose Accumulation registers for those documents. Can you explain me the technique for this?
It is not philosophical, but routine practical question ) Generally the structure and set of registers is defined in according to structure of reports and other queries of your application. For your example possible registers could be: - Stock: of Balances type, Item as dimension, Quantity as resource - Sales: of Turnovers type, Company, Counterparty and Item as dimensions, Quantity and Amount as resources
I need to build the following reports: Stock by items Sales by items, customers and sales orders Purchases by items, vendors and purchase orders Cashflow by counterparties and items Profit and loss statement by items Balances of not fulfilled purchase orders by vendors and items Balances of not fulfilled customer orders by customers and items
"Stock by items ": Stock(saldo type: Item - quantity, amount (amount you need for item-cost calculation) "Sales by items, customers and sales orders" Sales(only tournovers): deal(order) item count, saleamount, cost(amount in purchases price) "Purchases by items, vendors and purchase orders" Purchases(only tournovers): deal(purchases order) count amont "Cashflow by counterparties and items " Money(saldo type: Account(bank,cash) amount Profit and loss statement by items - Sales "Balances of not fulfilled purchase orders by vendors and items Balances of not fulfilled customer orders by customers and items": Balance(saldo type): Deal Amount - only Items balances You can get from Stock register If you want to look orders balances I recomend you add 2 registers saldo type SaleOrders(deal item qnty amount) and PurchaseOrders(same...)
I've followed your advice and have some questions:
The Cashflow Statement requires the data to be split into categories. So the petty cash/bank account is not enough, I need to add a classification as an Enumeration, the values are:
- Decrease (increase) in accounts receivable - Increase (decrease) in liabilities (A/P, taxes payable) - Sale (repurchase) of stock
Where sales and purchases go to Sale (repurchase) of stock, and advances while exist go to accounts payable/accounts receivable.
I am going to add the following documents for payment receipts: Sales Invoice Receipt Purchase Invoice Receipt
And here is the question: Which is the best document to place the Activity attribute: the Sales/Purchase Invoice or Sales/Purchase Invoice Receipt?
P.S.: If I really need to create those documents or it is fine to use statuses Paid/Unpaid in invoices?
I think you need next documents: Order(sales) Sale-invoice Purchase-Order Purchase-Invoice Two Bank receipts(in out) Two Cash reseipts(cash in order,cash out order) For taxes(vat and etc.) and others(sorry i don't know what mean A/P) i think you need special accumulation saldo registers linked to the invoices for example: Taxes: Client Invoice Tax ---- TaxAmount and same for purchase taxes This registers open amounts for taxes. i don't know how are closing taxes like VAT in your country. In Russia our accountants are using special SalesBook and PurchaseBook to close this registers.
I think You can control Paid/Unpaid status through Balance accumulation(saldo type) register.
Well yes, those documents look reasonable, but for a small company it becomes a little bit complicated to manage all of those documents. I'm thinking on creating a single document with several additional attributes: dates and numbers of payment and shipping. And provide all necessary print forms for those documents. If I'm making a big mistake doing like that?
Cause you'll have one big table with all attributes wich you need for all documents. Thas'll making database very slowly, cause there is one principe of databases normalization theory: truncating one big table to the many atom(simple)-tables. 1. When somebody will open documents for editing payment operation He(She) have to open datas for all another's operations. 2. And you'll lost great posibilities of 1S: Multiuser working with you'r database: for example: When your salesmanager editing sale-part of you'r big documents you'r accountant are unable to edit(add) information about payment and etc... I hope you understand my bad russian.
Thanks, Cocos, interesting idea. So the documents are like interfaces to registers? If we have several document types, posting to a single register (which is the main data storage) we can allow different interfaces to the same data? For example if one person is changing a comment to the delivery (one set of register resources) and the other one is changing the delivery address (the other set of that register resources) there will be no locks while opening the same data for edit due to they open differen (but linked) document types?
No problem,This different documents use DIFFERENT RECORD-sets of one register and 1S make multiuser-changes to the register table without troubles. Handred users able to work with one register in one time. But when one user open one document antother users's can open this document only in readonly mode.