Differences between revisions 6 and 20 (spanning 14 versions)
Revision 6 as of 2006-06-26 04:24:55
Size: 3694
Editor: FayezMoussa
Comment:
Revision 20 as of 2006-09-28 03:22:52
Size: 8118
Editor: FayezMoussa
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Debtor Sundy Invoices for rebates can be generated via two methods(a few other conditions must also be met):
 1. By [:PhonePlans:mobile phone plans]; and
 1. By stock items that have rebates specified on their records.

=== Rebates from Plans ===

Debtor sundry invoices are currently generated in posting by [:PhonePlans:mobile phone plans] which have rebates specified.

The rebate generating routine is started when posting detects a serial stock item (e.g an IMEI). It then proceeds to get the Model stock code that is associated with this serial item. Once it has the model stock code, it will appened the code with the '''plan''' that was chosen during the sale. This resulting code is then looked up in the stock file. For example, if a 3310 was sold on plan 7, the resulting code would be ''331007'' (check out the PhonePlans page for more info).

If a match is found, 3 debtor sundry invoices may be generated, depending whether or not the required rebate is present. The rebates are:
 * If the ''plan'' stock record has a '''non zero''' value in the '''rebate 1''' field, a sundry invoice will be generated on the '''first''' supplier on the ''plan'' record. The sundry invoice will only be generated if the supplier code can also be found in the debtor records. The first supplier stock code on the serial stock item will also be used for the reference on the sundry invoice. It is usually the same as the serial stock code.

 * If the ''plan'' stock record has a '''non zero''' value in the '''rebate 2''' field, a sundry invoice will be generated on the '''second''' supplier on the ''plan'' record. The sundry invoice will only be generated if the supplier code can also be found in the debtor records. The second supplier stock code on the serial stock item will also be used for the reference on the sundry invoice.

 * The third, and less common, sundry debtor invoice generated from a rebate is based on the '''current cost''' field on the '''serial stock item'''. If this field contains a '''non zero''' value, and if the '''second''' supplier on the record can be found in the debtor file, an invoice will be generated. The second supplier stock code on the serial stock item will also be used for the reference on the sundry invoice.

Currently the rebates that are generated are stored before hand during the sale. These rebates are stored on the '''rebate1''' and '''rebate2''' field on the transaction of the '''model stock item'''. These values are only currently used for reporting, and play no part in the generation of the sundry debtor invoices.
Debtor Sundry Invoices for rebates can be generated via two methods(a few other conditions must also be met):
 1. By Serial Stock items and their associated [:PhonePlans:mobile phone plans]; and
 1. By stock items that have rebates specified on their records. (Release 9 only)
Line 24: Line 8:
Sundry Debtor Invoices will be generated for any stock item('''other than model stock''') which has a rebate on its transaction line. The behaviour is very similar to above. Sundry Debtor Invoices will be generated for any stock item('''other than model stock''') which has a rebate on its transaction line. The transaction line rebate is generated normally from the rebates on the stock item. 
Line 26: Line 10:
'''Rebate1'''
 . The first supplier on the stock record must exist in the debtor file for a rebate to be generated. The first supplier stock code is used as a reference.
If either of rebate1 or rebate2 are present on the stock record, they will be transferred onto the transaction line.
During posting, a sundry debtor invoice will be generated if the following conditions are met:
Line 29: Line 13:
'''Rebate2'''
 . As for rebate1, but using the second supplier and supplier code on the stock record
 * The rebate is for a '''non zero''' value
 * For '''Rebate1''', the '''first supplier''' on the stock record is also set up as a '''valid debtor'''
 * For '''Rebate2''', the '''second supplier''' on the stock record is also set up as a '''valid debtor'''

=== Rebates from Serial Stock Items/Plans ===

Rebates for serial stock items are slightly more complicated. There are three types of rebates that can be generated from a serial stock item.

The first two rebates are based on the '''plan''' record that was selected when entering the model stock item. The third comes off the actual serial stock item.

There also a couple of situations where the rebates will be altered, based on other options or lines in the transaction. We will explain these later.

The first two rebates are calculated as follows. Note that they are almost exactly the same as the regular rebates, the only difference being that the rebates come off the plan record.

 * If the plan stock record has a '''non zero''' value in the '''rebate 1/2''' field, a sundry invoice will be generated on the '''first/second''' supplier on the plan record. The sundry invoice will only be generated if the supplier is also setup as a '''valid debtor'''. The first/second supplier stock code on the serial stock item will also be used for the reference on the sundry invoice. It is usually the same as the serial stock code.

The third rebate:

 * The third, and less common, sundry debtor invoice generated from a rebate is based on the '''current cost''' field on the serial stock item. If this field contains a '''non zero''' value, and if the '''second supplier''' on the serial stock record can be found in the debtor file, an invoice will be generated. The second supplier stock code on the serial stock item will also be used for the reference on the sundry invoice.

==== Serial Stock Rebates with associated component items ====

 * If a serial stock item is associated with some components (i.e selling the item results in a kit explosion), any matching rebates on the components are accumlated onto the existing serial stock rebates.

The conditions for this are as follows (applies to both rebate 1 and 2):

 * The serial stock item must have a '''non zero''' rebate to begin with
 * The corresponding suppliers for the rebate on the component item and on the serial item are to be the '''same'''.

If these conditions are met, the component item has its rebate added to that of the serial stock item, and then it is cleared.

==== Serial Stock Rebates based on cost ====

The option '''Use Item Cost for Rebate 1''' ,in ''Category File Maintainence'' ({{{caaad}}}), affects how the first two serial item rebates are calculated.
If the option is set to '''Y''':

 * Rebate 1 will always be the cost of the serial stock item

 * Rebate 2 depends on whether or not the plan had a regular Rebate 1 specified
  * If Rebate 1 is specified, then Rebate 2 = Original Rebate 2 + Orignal Rebate 1 - Cost of serial stock item
  * If Rebate 1 is not specifed, then Rebate 2 remains unmodified

Please note that this option is applied '''after''' any combination of rebates with component lines has occurred.
Line 34: Line 59:
All these calculations for rebates occur at the point of sale. The '''header''' and the associated '''model stock lines''' are updated. During posting, the sundry debtor invoices are generated based on the values on the transaction lines. Once they have been generated, the rebates on the '''serial stock lines''' are cleared, so as to allow the reporting to work.

The cost on the model stock item is the sum of the costs of the serial stock items that reference the model stock item. We will assume that serial stock items refer to the first instance of a matching model stock item. Once again, the costs on the model stock items are used for reporting, and do not affect the calculation of the rebates.

----
[[Anchor(requestedchanges)]]
=== Requested Changes ===

----
Line 35: Line 69:
# 10385 - 31/08/06 (Completed 28/09/06)

Changes will be made to the way rebates are currently stored, and to the way debtor sundry invoices are generated.
Model Stock items will remain the same, with all the rebates associated with their respective imeis being accumlated onto the line.

Imei's will now also have the correct rebates stored onto their transaction lines in POS.
Any Kit Components that are associated with this particular Imei will be scanned for rebates. Rebate 1 will be stored on the component line, and accumlated into the header. Rebate 2 will either be accumlated onto the Imei line if the rebate 2 supplier matches, or kept on the component line seperately. The header and model stock line will be updated to reflect this.

During posting, we will use the values stored on the transaction lines, as opposed to loading it off the stock record, to generate the debtor sundry invoices.

For reporting, we will need to ensure that imei lines are treated as if there is no rebate on them.

Also, we will change rebate calculation so that rebate 2 is never lost. It will just have additional things added to it. Eg Instead of making rebate 2 = Rebate 1 - cost of serial stock, it will be rebate 2 += Rebate 1 - cost of serial stock item

Also the category option should be used off the plan

||'''Task'''||'''Time (hrs)'''||
||Programming - Rebates||4||
||Programming - Reporting (possibly longer, incase other reports need to be changed)||4||
||Testing||4||
||Quote and Documentation||4||
||'''Total'''||'''16'''||



#9991 - 14/08/06

We will modify the way costs are calculated on model stock items. Currently, the cost on the model stock item comes directly off the stock record. We will change this to make the cost on the model stock item to be the sum of the costs of the serial stock item that reference the model stock item. We will assume that the first serial stock items refer to the first instance of a matching model stock item. We will keep track of which model stock items have been accounted for, to avoid the problem of having the wrong costs stored on the transaction line.

We will also provide a new category option that will allow you to specify the way rebates are calculated. The default would be the current way. The new way that rebates are calculated would be as follows:

If there is no rebate 1:
 . Rebate 1 = cost of the serial stock item
 . Rebate 2 = Nominal Rebate 2
If there is a rebate 1, then
 . Rebate 1 = cost of the serial item
 . Rebate 2 = Nominal Rebate 1 - cost of the serial item.

||'''Task'''||'''Time (hrs)'''||
||Programming - Rebates||2||
||Programming - Costs||4||
||Testing||4||
||Quote and Documentation||2||
||'''Total'''||'''12'''||

Debtor Sundry Invoices Generated by Rebates

Debtor Sundry Invoices for rebates can be generated via two methods(a few other conditions must also be met):

  1. By Serial Stock items and their associated [:PhonePlans:mobile phone plans]; and

  2. By stock items that have rebates specified on their records. (Release 9 only)

Rebates from regular items

Sundry Debtor Invoices will be generated for any stock item(other than model stock) which has a rebate on its transaction line. The transaction line rebate is generated normally from the rebates on the stock item.

If either of rebate1 or rebate2 are present on the stock record, they will be transferred onto the transaction line. During posting, a sundry debtor invoice will be generated if the following conditions are met:

  • The rebate is for a non zero value

  • For Rebate1, the first supplier on the stock record is also set up as a valid debtor

  • For Rebate2, the second supplier on the stock record is also set up as a valid debtor

Rebates from Serial Stock Items/Plans

Rebates for serial stock items are slightly more complicated. There are three types of rebates that can be generated from a serial stock item.

The first two rebates are based on the plan record that was selected when entering the model stock item. The third comes off the actual serial stock item.

There also a couple of situations where the rebates will be altered, based on other options or lines in the transaction. We will explain these later.

The first two rebates are calculated as follows. Note that they are almost exactly the same as the regular rebates, the only difference being that the rebates come off the plan record.

  • If the plan stock record has a non zero value in the rebate 1/2 field, a sundry invoice will be generated on the first/second supplier on the plan record. The sundry invoice will only be generated if the supplier is also setup as a valid debtor. The first/second supplier stock code on the serial stock item will also be used for the reference on the sundry invoice. It is usually the same as the serial stock code.

The third rebate:

  • The third, and less common, sundry debtor invoice generated from a rebate is based on the current cost field on the serial stock item. If this field contains a non zero value, and if the second supplier on the serial stock record can be found in the debtor file, an invoice will be generated. The second supplier stock code on the serial stock item will also be used for the reference on the sundry invoice.

Serial Stock Rebates with associated component items

  • If a serial stock item is associated with some components (i.e selling the item results in a kit explosion), any matching rebates on the components are accumlated onto the existing serial stock rebates.

The conditions for this are as follows (applies to both rebate 1 and 2):

  • The serial stock item must have a non zero rebate to begin with

  • The corresponding suppliers for the rebate on the component item and on the serial item are to be the same.

If these conditions are met, the component item has its rebate added to that of the serial stock item, and then it is cleared.

Serial Stock Rebates based on cost

The option Use Item Cost for Rebate 1 ,in Category File Maintainence (caaad), affects how the first two serial item rebates are calculated. If the option is set to Y:

  • Rebate 1 will always be the cost of the serial stock item
  • Rebate 2 depends on whether or not the plan had a regular Rebate 1 specified
    • If Rebate 1 is specified, then Rebate 2 = Original Rebate 2 + Orignal Rebate 1 - Cost of serial stock item
    • If Rebate 1 is not specifed, then Rebate 2 remains unmodified

Please note that this option is applied after any combination of rebates with component lines has occurred.


All these calculations for rebates occur at the point of sale. The header and the associated model stock lines are updated. During posting, the sundry debtor invoices are generated based on the values on the transaction lines. Once they have been generated, the rebates on the serial stock lines are cleared, so as to allow the reporting to work.

The cost on the model stock item is the sum of the costs of the serial stock items that reference the model stock item. We will assume that serial stock items refer to the first instance of a matching model stock item. Once again, the costs on the model stock items are used for reporting, and do not affect the calculation of the rebates.


Anchor(requestedchanges)

Requested Changes


ChangeLog

# 10385 - 31/08/06 (Completed 28/09/06)

Changes will be made to the way rebates are currently stored, and to the way debtor sundry invoices are generated. Model Stock items will remain the same, with all the rebates associated with their respective imeis being accumlated onto the line.

Imei's will now also have the correct rebates stored onto their transaction lines in POS. Any Kit Components that are associated with this particular Imei will be scanned for rebates. Rebate 1 will be stored on the component line, and accumlated into the header. Rebate 2 will either be accumlated onto the Imei line if the rebate 2 supplier matches, or kept on the component line seperately. The header and model stock line will be updated to reflect this.

During posting, we will use the values stored on the transaction lines, as opposed to loading it off the stock record, to generate the debtor sundry invoices.

For reporting, we will need to ensure that imei lines are treated as if there is no rebate on them.

Also, we will change rebate calculation so that rebate 2 is never lost. It will just have additional things added to it. Eg Instead of making rebate 2 = Rebate 1 - cost of serial stock, it will be rebate 2 += Rebate 1 - cost of serial stock item

Also the category option should be used off the plan

Task

Time (hrs)

Programming - Rebates

4

Programming - Reporting (possibly longer, incase other reports need to be changed)

4

Testing

4

Quote and Documentation

4

Total

16

#9991 - 14/08/06

We will modify the way costs are calculated on model stock items. Currently, the cost on the model stock item comes directly off the stock record. We will change this to make the cost on the model stock item to be the sum of the costs of the serial stock item that reference the model stock item. We will assume that the first serial stock items refer to the first instance of a matching model stock item. We will keep track of which model stock items have been accounted for, to avoid the problem of having the wrong costs stored on the transaction line.

We will also provide a new category option that will allow you to specify the way rebates are calculated. The default would be the current way. The new way that rebates are calculated would be as follows:

If there is no rebate 1:

  • Rebate 1 = cost of the serial stock item
  • Rebate 2 = Nominal Rebate 2

If there is a rebate 1, then

  • Rebate 1 = cost of the serial item
  • Rebate 2 = Nominal Rebate 1 - cost of the serial item.

Task

Time (hrs)

Programming - Rebates

2

Programming - Costs

4

Testing

4

Quote and Documentation

2

Total

12

#9792 - 26/06/06

We will modify posting so that any stock item (other than model stock) with a rebate on the transaction line will generate a sundry debtor invoice. The first supplier(?) on the stock record will be used as above (i.e it must also exist in the debtor file). If a reference is needed we could again use the supplier stock code(?) on the record.

Task

Time (hrs)

Programming

2

Testing

2

Quote and Documentation

2

Total

6


CategoryAllphones

Rebates (last edited 2013-09-18 06:09:34 by localhost)