Cash Sales

[hanlynnkyaw]

Hi Edward,

We are also testing and playing around with this really cool package. I would like to clarify the way post function works in Ledger.php.

Scenario I: For the sake of simplicity, the following are assumed for scenario I. 1) There is only one line item. 2) There is no tax involved. 3) The amount involved is $ 100.00

For this scenario I, can we check if the the following entry should be posted to ledger table? Debit Bank-COA $100.00 Credit Operating Rev-COA $100.00

Scenario II: For the sake of simplicity, the following are assumed for scenario II. 1) There is only one line item. 2) The amount entered in the line item is $ 100.00 3) The amount entered as amount received is $ 100.00 (for transaction) 4) There is a sales tax of 7% involved. 5) The line item amount is assumed to be inclusive of sales tax.

For this scenario II, can we check if the the following entry should be posted to ledger table? Or should the ledger table be posted with a slightly different entries other than the one listed below? Debit Bank-COA $100.00 Credit Operating Rev-COA $93.46 Credit Vat-COA $6.54 (The line item amount is assumed to be inclusive of sales tax.)

Thanks in advance.

Best regards, Han

[ekmungai]

Hi Han,

Thanks a lot for your feedback, it helps me improve the package a lot as well as keep me motivated. Scenario I seems about right, though I'm not familiar with the COA acronym. For the second scenario, I'm afraid the line items amount at the moment assume that all the amounts are vat exclusive, so to accomplish the above result the entry in the line item would have to be entered as $93.46 so that the $6.54 can be calculated by the system. I should perhaps have a flag to indicate if the amount in the line item is inclusive or exclusive. Hmm.

Regards, Edward

[hanlynnkyaw]

Hi Edward,

Thanks for your reply. By COA, I meant to say "Chart of Accounts". Yes we have tested and as you have advised, we noted the system assumed the line items are vat exclusive. To me, it is not essential to have a flag. Just need to highlight in the documentation that the line items are vat exclusive.

I have another question with regards to client receipt for a credit sales. For the client receipt, we are assuming that it will involves the two steps below.

Step 1: Transaction Table $clientReceipt = ClientReceipt::create([ 'account_id' => Account::RECEIVABLE, 'date' => Carbon::now(), 'narration' => "Example Client Payment", ]);

Step 2: Line Item Table //Line Item Table $clientReceiptLineItem = LineItem::create([ 'vat_id' => $zeroVat->id, 'account_id' => $bankAccount->id, 'vat_account_id' => $saleVatAccount->id, 'description' => "Part payment for Client Invoice", 'quantity' => 1, 'amount' => 50, ]);

Question: Vat_id is mandatory in line item table as the column is not nullable. But there could be occasions where user might have deleted zeroVat entry in vat lookup table. If this happens, we will not be able to create the line item for a client receipt transaction. Do you have any idea how we should make vat_id as nullable without affecting the other aspects of the package (e.g., account statements in the report session)?

Best regards, Han

[ekmungai]

Hi Han,

The vat_id column is protected against deletion on the database level by foreign key constraints, so it can never be deleted. Secondly, should it be deleted on the code end, this deletion is only 'soft' in that the record is marked as having been deleted or destroyed but it still exists on the database so all previous transactions that had used it retain their validity. The idea of having a mandatory vat for every line item is that theoretically all transactions have a vat rate, even if that rate is zero. Allowing a nullable vat column could potentially play havok especially with generating tax reports which always demand a vat rate. I suppose one could always create a check that says a null vat object corresponds to the 0 vat rate, but I feel is would be introducing avoidable complexity.

Regards, Edward

[hanlynnkyaw]

Hi Edward,

This makes sense. Thanks for your reply.

Best regards, Han