How can create a report that shows the master and detail rows in the same report?
I am working on trying to prepare statement for customers of their invoices and credits.
The structure is:
Customer
Invoice
Credit
Credit Detail
Payment
Payment Detail
The scenario for a customer:
A customer can have multiple Invoices,
Each Invoice can have multiple credits issued against a particular invoice.
Each Invoice can have multiple payments.
The statement should produce each outstanding invoice and list any payments or credits towards the invoice grouped under them.
There may be situations that the customer can have credits issued against no invoice. This also needs to be displayed without any invoice.
I need some advise on how this can be done using Winforms Report using RDLC.
I created statementdata and statementdetail table that is preprocessed consolidating all invoices with their credit and payment amounts along with credits that were not issued to invoice instead to the customer (special credit). StatementDetail table will have the details of the credits and payments. Once we have this it becomes a master detail scenario. This made me easily show a statement with the following structure.
Customer Name and Address - Header
invoice 1 - Detail Section
Details for Invoice 1 payment - Sub Grouping
Details for Invoice 1 credits - Sub Grouping
invoice 2
Details for Invoice 2 payment
Details for Invoice 2 credits
etc.,
Thanks
Related
I am having difficulty designing the database for the following requirement, your suggestions / advice is highly appreciated
There is a Collector Table which illustrates the People who collect the payments for the respective invoices from the Customers.
Problem:
There are three ways a debtor invoice is cleared / collected.
Cash Payments
Check Payments
Credit Notes
Cash Payments: are pretty straight forward, its a matter of settling an invoice with the cash received
Check payments: if made then the following details of the checks should be recorded.
a) Check 'Post Date'
b) Check Number
c) Check Value
Credit Notes: will be raised against an invoice if they return some item against a specific invoice or if they overpaid a sum beyond an invoice value (trust me people do this)
What i cannot get my head around is how do i normalize a table which can store all three:
should i have one table for all the three types of transactions?
when the customer pays by check how do i go about recording the check attributes (ex: post date, check number, value etc)
Please advice
System has many users belongs to a company. Admin user of the company can entry customers and each customer may have invoices with payment amount. The customer invoice amount need to be paid and should be inserted in double entry system in transaction master table.
Data Models are followings:
User
Company
Customer
Invoice
Transaction Master
My initial approach will be:
Company will have a one to many relationship with users
in invoice table, the details will be saved.
My questions are:
Do I need to create any relationship between customers and invoices tables?
How the transaction master table will be created? (double entry system refers to have debit and credit accounts, that's all my knowledge)
Yes, you need to create a relationship between customers and invoices table. Every invoice will have one customer. Every customer will have none, one, or many invoices. You will need a unique identifier to be stored in each file.
Transaction file is a much deeper subject. I assume you mean Ledger Transactions. Generally you will group a transaction with one or more debit entries matched with one or more credit entries with an associated reference number which will point to the invoice transaction. You would group references in a batch, usually called a session, and assign a session number at batch posting time which would have the post date.
These are the basic minimum answers to a very vague question on a potentially complex subject, but hopefully it will help get you started in the right direction for further research.
I have an interesting one that I have searched for and can't find the solution to.
I am working with a developer who is trying to integrate our incident management tool into Palladium, a finance tool and we're stuck on being able to import invoices correctly.
Scenario
There is a view that contains the invoices but there's several elements to the invoice. The view here shows all the billing parts and includes value amounts for Products and Expenses but it doesn't show details of the products or expenses as there may be multiple line items in that invoice. There are 2 further views one containing the product information and one containing the expense information. There is a common field that can be used to reference the invoice in each of these views called Billing_Log_RecID.
Here's how the default invoice search view looks when exported. I've selected entries where there are products and/or expenses added.
What I need to do is display in a view a line item for each invoice but break out the multiple expense or product items into I guess separate columns so for example
Inv1 COMPANYNAME COMPANYID INVTOT PROD1 PVAL1 PROD2 PVAL2 etc EXP1 EVAL1 EXP2 EVAL2 etc, there's never likely to be more then 2-3 different items but to be safe 5 is a good number.
Here's an example of a query showing products attached to an invoice, I have highlighted where there are multiple lines.
The same exists for the expense items
Hope someone can help.
Dave
I am designing an e-commerce website that has the following scenario:
A customer can purchase items and create an order.
The order may have unknown fee that will be added after the customer
pays the total amount of the items. That is, the customer pays
certain amount first. The order adds some fee and changes the total.
And the customer pays again for the difference. But the two (or
more) payments are associated with the same order.
(Optional) The customer can submit a single payment for multiple
orders.
Currently, I have an Order table and each order may consist of multiple OrderLineItems (simplified schema):
Order
=====
customer
line_items
total
status
OrderLineItem
=============
price
quantity
order
product
A payment is associated with an order (simplified schema):
Payment
=======
order
payment_account
total
result
It seems to be very hard to support the multiple payments for a single order scenario in the current implementation. I reckon that I have to introduce immutable invoices in the system, and the payment should be associated with an invoice instead of an order. However, I would need some help with the order/invoice/payment modeling for the above scenario. Some specific questions I have:
An order and an invoice look very similar to me (e.g. both have
items and totals). What is the major difference in typical
e-commerce systems?
How should I model invoices for my scenario? Should I have
OrderLineItems for an Order AND InvoiceLineItems for an Invoice?
Some preliminary thoughts: I will have multiple invoices associated
with a certain order. Whenever the order changes the total, I have
to somehow calculate the difference and send a new/immutable invoice
to the customer. Then, the customer can pay and the payment will be
associated with the invoice.
Would love to hear some advice. Much appreciated. Thanks!
There are a lot of questions here, I'll try to address as many as I can. A lot of the issues are the business model rather than the data model.
Firstly, you are right that you need an immutable invoice. Once an invoice is created you cannot alter it, the standard way of handling a change in invoice is to issue a credit note and a new invoice.
Think about the relations between the tables: the Order does not need to hold the lineItems as these are referenced the other way, i.e.
Order
=====
orderId
customerId
status
OrderLineItem
=============
orderLineItemId
orderId
product
price
quantity
So to view the order you join the tables on orderId. There's also no need to store the total as that is calculated from the join.
Try not to duplicate your data: your invoice will reference orderLineItems, but not necessarily the same ones in the order. For example, the customer orders an A and a B, but B is out of stock. You ship A and create an invoice that references orderLineItemId for A. So your invoice tables might look like:
invoice
=======
invoiceId
status
invoiceLineItem
===============
invoiceId
orderLineItemId
quantity
In other words there's no need to have the details of the item. You may be wondering why you don't just add an invoiceId to the orderLineItem table - the reason is the customer might order 10 of item A, but you only ship 8 of them, the other two will go on a subsequent invoice.
Payments are not made against orders, they are against invoices. So your payments table should reference the invoiceId.
Then you touch on reconciliation. If everything was perfect, the customer would make a payment against a particular invoice, even if a partial payment. In reality this is going to be your biggest headache. Suppose the customer has several outstanding invoices for amounts x, y and z. If they make a payment of p, which do you allocate it against? Perhaps in date order, so that if p>x the remainder is allocated against y. What if p=z? Perhaps the customer is intending to pay z now but is disputing y and has mislaid x? How you deal with these sorts of things is up to you, but I can say that most invoicing systems do it very badly indeed.
I am building a new business application for my personal business which has close to ~100 transactions of sale and purchase per day. I am thinking of having Separate tables to record the sale and purchase with another linked table for Items that were sold and a seperate linked table with items that were purchased.
Example:
**SaleTable**
InvoiceNo
TotalAmt
**SaleTableDetail**
LinkedInvNo
ProductID
Quantity
Amount
etc.,
would this design be better or would it be more efficient to have one transactiontable with a column stating sale or purchase?
-From an App/Database/Query/Reporting Perspective
An invoice is not the same as a sales order. An invoice is a request for payment. A sales order is an agreement to sell products to a party at a price on a date.
A sales order is almost exactly the same as a purchase order, except you are the customer, and a sales order line item can reference a purchase order line item. You can put them in separate tables, but you should probably use Table Inheritance (CTI, extending from an abstract Order). Putting them in the same table with a "type" column is called Single Table Inheritance and is nice and simple.
Don't store totals in your operational db. You can put them in your analytic db though (warehouse).
You are starting small, thats a quick way to do. But, I am sure, very shortly you will run into differences between sale and purchase transactions, some fields will describe only a sale and some fields that will be applicable only for purchases.
In due course, you may want to keep track of modifications or a modification audit. Then you start having multiple rows for the same transaction with fields indicating obsoletion or you have to move history records to another table.
Also, consider the code-style-overhead in all your queries, you got to mention the Transaction Type as sale or purchase for simple queries.
It would be better to design your database with a model that maps business reality closest. At the highest level, everything may abstract to a "transaction", with date, amount and some kind of tag to indicate amount is paid or received against what context. That shouldn't mean we can have a table with Tag, Date, Amount, PayOrReceive to handle all the diverse transactions.