Magento: How to decline order when total due > 0 - magento

Customer XYZ made an order 1234 for a total of $83.00 + $15 Shipping = $98.00
A $65 voucher was used and a $10 off promo (TAKE10) was used.
Remaining total was $23.00
Customer then went though checkout however was only charged $16.01 on her credit card
Order then completed in the system and become a processing order even though a $6.99 balance was still remaining to be paid - See screen shot
How to: Order should of declined or charged the full amount of $23.00
Please help me.

Related

Flexcube - Customer Account's status change from/to 'OVER' / 'NORM'

On Oracle Flexcube, in the sttm_cust_account table, there is an 'ACC_STATUS' column.
In this column value changes from/to 'OVER' <> 'NORM' on some conditions.
I need to find when and where this status changes? This status changes during EOD or changes with any JOB? Do anyone knows in which packages I can found logic?
I know the module where we can change manually status.
But now I need to find place where automatically changes these statuses
Thanks in advance
For Flexcube 14.0 and above is applicable that the automatic status change logic you must check the STATUS RULE button in Account class maintenance screen(Function_id:-STDACCLS).
The Automatic status change happens during EOD.
Also at the Account class level there is a Preference as Status change Automatic which you can override at the Account level
to indicate whether status change is automatic for this account class or account.
For Manual status change you have to refer the screen (function id:-STDSTCHN).
Please find the below from the manual regarding STATUS RULE maintenance
In this screen, you can define five conditions for each status applicable to an account class. An account will be said to be in a specific status if any one of the five conditions associated with the status holds true for an account. Conversely, if all the conditions are false, the account will automatically move to the next available status for which the condition is true.
A user defined status INTR is used for both OD and Loan accounts. When a loan is in adversity status and the customer pays the entire overdue amount, the status of the loan changes to a user defined account status ‘INTR’ rather than ‘NORM’, so would the other OD and loan accounts of the same customer across branches.
Only backward movement of any other status to INTR is applicable. The account status cannot change from NORM to INTR. The status sequence of INTR is maintained as the immediate sequence number next to NORM.
The following elements are available based on which you can build a condition for automatic status change. You can associate each of these elements with an account, in the ‘Customer Accounts Maintenance’ screen.
The set of elements are as follows:
Frozen
Dormant
No Debits
No Credits
Stop Payment
Current Status
In addition, the following elements will also be available for processing:
OD (overdraft) Days
Inactive Days
Overline Days
TOD (Temporary Overdraft) Days
Customer Classification
Due Count
Overdue Days
Customer Credit Ranking
Debit Interest Overdue Days
Overdue Limit Breach Days
Overdue Expiry Days
Overdue No Credit days
Principal Overdue Days
Principal Overdue Amount
Principal Overdue Local Currency Equivalent Amount
Interest Overdue Days
Interest Overdue Amount
Interest Overdue Local Currency Equivalent Amount
Charge Overdue Days
Charge Overdue Amount
Charge Overdue Local Currency Equivalent Amount
Account Interim Days
Appropriation Preference
You can define the appropriation sequence for overdraft accounts for each account status.
Appropriation sequence maintenance is mandatory if the ‘Component-wise Tracking for Overdraft’ is checked.
The appropriation preference sequence can be modified anytime and this will be applicable for the existing accounts also.This modification will effect only for future credits and appropriation.
Component with priority 1
Select the component with first priority from the adjoining drop-down list. The options available are:
Principal
Interest
Charge
Component with priority 2
Select the component with second priority from the adjoining drop-down list. The options available are:
Principal
Interest
Charge
Component with priority 3
Select the component with third priority from the adjoining drop-down list. The options available are:
Principal
Interest
Charge
Status Change for Overdraft Accounts
Oracle FLEXCUBE processes the status change for overdraft accounts based on the following rules:
Debit Interest OD Days
OD Limit Breach Days
OD Expiry Days
No Credit days
Account Interim Days
Debit Interest OD Days
The system processes the status change on overdraft account, if the customer fails to pay the debit interest of the overdraft account for specified number of days.
For example,
OD Utilization date: 01-Jan-2011
Days after which Status Change should happen: 90 Days
Debit interest due date: 01-Feb-2011
In this example, the system modifies the customer account status based on the status rule maintenance, if the customer fails to pay the debit interest by 02-May-2011.
OD Limit Breach Days
The system processes the status change on OD account, if the OD limit of the overdraft account is breached for a specified number of days. The system tracks the overdraft limit breach days based on the utilizations done at the line level.
OD Expiry Days
The system processes the status change on overdraft account, if the OD utilization of the overdraft account is not settled beyond the expiry date.
No Credit Days
The system processes the status change on OD account if there is no credit transaction into the overdraft account for a specified number of days.
Logical Operators
Logical Operators are indicators of certain conditions that you specify while building a rule. These operators are used in combination with the elements discussed earlier. The following is a list of logical operators that you would require to build a status rule:
Operator
Description
AND
The conjunction ‘and’
OR
The conjunction ‘or’
Greater than
=
Greater than or equal to (please note that there is no space between the two symbols)
<
Less than
<=
Less than or equal to (please note that there is no space between the two symbols)
< >
Not equal to (please note that there is no space between the two symbols)
=
Equal to
Oracle FLEXCUBE allows data store for tracking of SOD debit interest due. During Interest liquidation for debit interest, the system populates the SOD Debit Interest Due Data Store with the Amount Due as debit interest for the SOD utilized amount and the due date of payment for the interest amount.
The debit interest due amount is adjusted in the SOD utilized amount and the system checks for any credit entries for the SOD corresponding to the debit interest. During EOD, if any credit entry exists for the account, then the system does adjustments on the amount due for the SOD debit interest due data store. The system also adjusts the debit interest payment against the oldest available debit interest due amount, and so on.
Oracle FLEXCUBE provides SDEs for ‘SOD Due Count’ and ‘SOD Overdue Days’ for status rule generation. During EOD while running the status update batch, the system calculates SDE ‘SOD Due Count’ value as the count of the records having due amount not equal to zero from the SOD debit interest due data store. The system updates the ‘SOD Overdue Days’ with the number of days since the last debit interest payment done for the account.
Oracle FLEXCUBE provides an account status called ‘DIDF’ for an SOD account, which is available as part of ‘Status Rule Screen’. If the ‘SOD Due Count ’or ‘SOD Overdue Days’ satisfies the condition specified in the status change rule, then the system changes the status for the account to ‘DIDF’.
While running the status change batch, the system updates the ‘No Debit’ flag as ‘Y’ for ‘DIDF’ status account. If payment for the debit interest happens on the SOD account against the utilized amount, and if on recalculation the value of SDE ‘SOD Due Count’, or ‘SOD Overdue Days’ is not met, the status batch changes the status of the OD account from ‘DIDF’ to the previous account status and updates the ‘No Debit’ flag as ‘N’.
For more information you can check the CASA user manual

Magento Order gets closed when doing a partial refund with adjustment fee in it

I have an issue in magento enterprise as follows
Place an order with 3 items in it
Redeem some money from the
customer's store credit when placing the order. For example if 200
is the total order amount, 50 should be paid from the customer's
store credit and 150 should be paid as normal payment.
Ship the order via backend
Create credit memo for any 1 item in the
order.
Add 1 in the adjustment fee field in the credit memo form
Save the credit memo.
The credit memo is created successfully, but the order status becomes closed. Due to this I am not able to raise another credit memo next time If I need to refund any or the remaining items in the order. This issue happens only if customer has redeemed his store creid in the order amount.
Could somebody please help me on this?

how do i set the paid amount and due amount manually after successful transaction in magento?

im running magento store 1.9.
please have a look at this scenario :
Grand total : 28000 Rs
I have special payment rule like:
if the grand total is greater than 25000 Rs then i will forward 30% of grand total to payment gateway for processing.
as usual payment gateway will process it accordingly and im getting the response as success.
after receiving payment success message, magento is saving order.
but the problem arises when i create an invoice from admin panel, even if the user had not paid the total amount completely, the invoice is creating as :
Grand Total : 28000
Total Paid : 28000
Total Due : 0.00
But the actual paid amount is 30% of Grand total.
we are using PayU india PG.
i can see that the payU integration code is doing the following after successful transaction
$order = Mage::getModel('sales/order');
-
-
-
$order->setState(Mage_Sales_Model_Order::STATE_PROCESSING, true);
$order->save();
$order->sendNewOrderEmail();
is there any way to set paid amount and manually, and hence there by to get due amount too?
i had tried :
$order->setBaseTotalPaid($amount)
but no use!!
i got it working by :
$order->setTotalPaid($amount);
and the due amount is set automatically!!!
why you are not using recurring profile, I think you need to use recurring profile here that will give you option to create seperate invoice and you can create it later.

Magento what is hidden_tax_amount

Could somebody helpme pelase?. I see that Magento in almost all my orders is calculating a tax named hidden_tax_amount . What does this value is related with?. And how can I disable it?.
Here you can see what I'm talking about.
[hidden_tax_amount] => 4.3000
[base_hidden_tax_amount] => 4.3000
[hidden_tax_invoiced] => 4.3000
[base_hidden_tax_invoiced] => 4.3000
Edit:
Ok, I've been digging in my code and fount that this field was introduced in 1.6.0.0 (Mage/Sales/sql/sales_setup/mysql4-upgrade-1.5.9.9-1.6.0.0.php:1616) and the value is get or set here
Mage/Tax/Model/Sales/Total/Quote/Tax.php:391: $address->setShippingHiddenTaxAmount(0);
Mage/Sales/Model/Order/Invoice/Total/Tax.php:85: $totalHiddenTax += $order->getShippingHiddenTaxAmount();
And in Mage/Tax/Helper/Data.php you can find in line 1114 to 1116 the following condition
if ($current->getShippingHiddenTaxAmount() > 0) {
$taxClassAmount[0]['hidden_tax_amount'] = $current- >getShippingHiddenTaxAmount();
}
Then researching more about the issue I found that:
"hidden_tax_amount" holds the substraction of the actual tax amount (on the current order) from the tax amount that should have been applied if there was no discount http://forum.azmagento.com/how-to/grand-total-calculation-v142--82183.html .
What leads me to the point that this is due a wrong tax configuration from my side rather than a bug and is related with a shipping tax. If so, could some body point me in the correct direction please?
Thankyou very much!
For anyone looking to understand the porpouse of hidden_tax_amount let me tell you that is not a bug or a missconfiguration, it's a feature:
it is used by Magento to calculate the amount of tax that is not originally calculated when a product that has a tax is under discount.
For example, you have:
a product named "Pencil" with price of $100.00 and a tax of 16% so the final price will be $116.
a coupon code with 10% off for all the Pencils
(This is important) your store is configured to calculate the discount after tax.
The user will see a final price including tax of 104.4 that is the result of 116 - 11.6. And that is correct.
But legally you can't discount any amount from tax because your base tax is still 100 and not 104.4.
Then Magento hiddes that quantity of money in hidden_tax_amount.
For accounting porpouses this process is correct. Then you can show that value as Tax.
Hope this helps someone else!
I had to give the Magento tax/discount issue some serious thought recently.
To set this problem up, assume there are four parties involved in a transaction, the wholesaler, the retailer, the consumer and the tax man. Assume the retailer is selling an item for £100 to the consumer (including tax), the tax rate is 20% and the wholesaler is providing a 10% discount on the item
The vital point here is that the 10% discount is offered by the wholesaler, not by the retailer. The retailer will get the full £100 for the item, with the consumer paying £90 and the wholesaler making up the remaining £10.
The retailer owes tax on the full amount paid. That is, at a tax rate of 20% £15 of the £90 paid for by the consumer is tax, and £1.67 of the £10 paid by the wholesaler is tax, giving a total tax bill of £16.67 or 20% of the net price (£83.33).
When the consumer receives their invoice, it makes sense to show them only the tax that they have paid, not the total tax paid on the item. However for the retailers accounting, they need to see all the tax that is due, that is the tax due on the portion paid by the consumer paid and the tax due on the portion paid by the wholesaler.
The hidden tax is still tax which has to be paid by the retailer, but it should be hidden from the consumer, because its nothing to do with their part of the transaction.

Magento - unable to refund

When attempting a full refund in Magento 1.7.0.2 (there is no Adjustment Refund or Adjustment Fee being applied) but we are receiving the following message
This Refund would exceed the amount of the original transaction.
As a test, we have a staging site setup where we have replicated and refunded the order without any issues.
Below are the order totals in Magento
Subtotal £7.49
Discount £1.12 (15% off)
Tax £2.07
Shipping £4.95
Grand Total £11.32
Logging into the Payment Provider system, show the grand total as £11.31
Any ideas about what might be happening and what we can look into would be greatly appreciated?
Refunds can only be performed if the amount is equal to or less then the original purchased amount. If it does not meet this criteria you cannot issue that refund.

Resources