EN prepaid fillings: Unterschied zwischen den Versionen
| (20 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | |||
{{Vorlage:TOCright}} | {{Vorlage:TOCright}} | ||
==Preamble== | ==Preamble== | ||
| − | With the function "prepaid fillings" payments can be booked in advance on a company, which can be filled at the card reader afterwards. These | + | With the function "prepaid fillings" payments can be booked in advance on a company, which can be filled at the card reader afterwards. These prepayments are being booked on a vehicle of the corresponding company, which has to be assigned to a card. For adminstration and control purposes an account statement for the prepayments and the fillings is available. |
| Zeile 17: | Zeile 16: | ||
===Product registration=== | ===Product registration=== | ||
| − | [[File: | + | To be able to book the prepayments, a suitable product has to be registered first. Details to products under [[EN_products|products]]. |
| + | [[File:prepay_1.png|350px|top|left]] | ||
| + | {{clr}} | ||
| + | |||
| + | |||
| + | ===Card reader preparations=== | ||
| + | The card reader should have a periodical- or reducing-limit function. That means the limit calculated and given by Autopoll can be filled at the card reader. The card is being blocked by the card reader when the limit is reduced to zero and can only be reactivated when a new limit is transmitted from Autopoll. | ||
| − | + | Due to the fact that the prepaid bookings are amount bookings, the card reader should be able to handl e amount limits. | |
| + | |||
| + | |||
| + | ====Configuration with Autopoll==== | ||
| + | [[File:prepay_2.png|480px|top|left]] | ||
| + | |||
| + | In card readers, which are configured with Autopoll (e.x. Heconomy), the parameter "amount limit" (preselection amount) has to be activated and sent to the card reader. (For the Heconomy: Settings - card reader terminals - open the card reader - Devices - open the device - Master files) | ||
{{clr}} | {{clr}} | ||
| − | |||
| − | |||
| − | |||
| − | ====Configuration | + | ====Configuration in the card reader==== |
| − | [[ | + | Card readers, which are not configured with Autopoll (e.x. Hecstar), the correct configuration has to be done in the card reader directly by the card reader service personnel. Please pay attention to the card reader type specific details. E.x.: at a Hecstar periodic limits can not be configured for a single card, but only for a whole card group. Therefore the cards have to be organised correctly and matching in the Hecstar and in Autopoll. Details under [[EN_prepaid_Hecstar|prepaid Hecstar]]. |
| − | + | In case of the situation that the card reader could not handle amount limits, Autopoll will calculate a quantity limit on the base of the highest price for the products assigned to the card. (But this procedure should only be the second option) | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | === | + | ===Configuration of a prepaid card=== |
| − | [[File: | + | [[File:prepay_3.png|480px|top|left]] |
| − | + | The card, which shall be used as prepaid-card, has to be configured with the correct limit type. Data - Cards - All Single Cards - open the card - parameters. Details unter [[EN_cards|cards]] | |
{{clr}} | {{clr}} | ||
| + | |||
===Assignment to a vehicle/driver and company=== | ===Assignment to a vehicle/driver and company=== | ||
| − | [[File: | + | [[File:prepay_4.png|480px|top|left]] |
| − | + | Prepayment bookings in Autopoll can only be registered on vehilces/drivers and the correspondent company. Therefore the prepayer card has to be assigned to the correct vehilce or driver. | |
{{clr}} | {{clr}} | ||
| − | == | + | ==Prepayment booking== |
| − | [[File: | + | [[File:prepay_5.png|480px|top|left]] |
| − | + | Now a prepayment can be booked on the assigned vehicle. The registration will be done under Data - Other Movements. | |
| − | + | Important are the booking type ("Receipt texts", wrong translation, should be "prepayment") and the product ("prepayment" in our example). | |
| − | + | Furthermore the amount/price has to be input as negative value. | |
{{clr}} | {{clr}} | ||
==Transmission of the data to the card reader== | ==Transmission of the data to the card reader== | ||
| − | + | The changed cards have to be transmitted to the card reader/s. | |
| − | {{Vorlage:Achtung | ''' | + | {{Vorlage:Achtung | '''When working with limits and mileage input at the card reader, the pollings have to separated.''' |
| + | |||
| + | For details read [[EN_polling_process_limits_and_mileage_input|polling process limits and mileage_input]] | ||
| − | '''1. | + | '''1. polling 1 only the fillings from the card reader (thereby NO card transmission),''' |
| − | '''2. | + | '''2. the card limits will be calculated anew on the base of the new fillings, (respectively the mileage are being set)''' |
| − | '''3. | + | '''3. polling 2 transmission of all cards with the correct limits(and mileage values) to all the card readers.'''}} |
| − | [[File: | + | [[File:prepay_6.png|420px|top|left]] |
| − | 1. | + | 1. Polling 1 only fillings |
{{clr}} | {{clr}} | ||
| − | [[File: | + | [[File:prepay_7.png|420px|top|left]] |
| − | 3. | + | 3. Polling 2 only the cards |
{{clr}} | {{clr}} | ||
| − | == | + | ==Prepayer account statement== |
| − | + | The limit calculation will be done on the base of the prepayments and the stored fillings. This calculation could cover a long period and therefore reacts very sensitive on every change or false entry. Due to this fact it is recommended to execute the prepayer account statement on a monthly basis. During the creation of the account statement the prepayment bookings and fillings since the last account statement are being taken into account and a new closing entry value is being calculated and fixed, which is afterwards the base of the next account statement creation. Working with monthly closing entry values protects the whole prepayment process from manipulations and false entries. | |
| + | |||
===Menu call up=== | ===Menu call up=== | ||
| − | + | Under Evaluations-Prepayer the report of the account statement is being opened. | |
| − | [[File: | + | [[File:prepay_8.png|350px|top|left]] |
{{clr}} | {{clr}} | ||
===Test run=== | ===Test run=== | ||
| − | [[File: | + | [[File:prepay_9.png|350px|top|left]] |
| − | + | During the test run an account statement is being reported, but '''no''' closing entry is being booked. | |
{{clr}} | {{clr}} | ||
| + | |||
===Production run - real account statement=== | ===Production run - real account statement=== | ||
| − | {{Vorlage:Achtung | | + | {{Vorlage:Achtung | It is recommended to execute the report account statement in production run on a regular basis. Most customers do it monthly.}} |
| − | [[File: | + | [[File:prepay_10.png|350px|top|left]] |
{{clr}} | {{clr}} | ||
| − | [[File: | + | [[File:prepay_12.png|350px|top|left]] |
| − | + | Like in most of the Autopoll reports the affected transactions will be counted first and it is possible to repeat the report and/or to recalculate the prices. | |
{{clr}} | {{clr}} | ||
| + | |||
===Account statement=== | ===Account statement=== | ||
| − | + | After the creation the prepayer account statement can be stored for later questioning by the customer or can be handed over to the customer. | |
| − | [[File: | + | [[File:prepay_11.png|720px|top|left]] |
{{clr}} | {{clr}} | ||
| − | ==Re-use of a | + | |
| − | + | ==Re-use of a prepayer card== | |
| + | If a prepayer card is being returned or confiscated and shall be used again, it has to be secured that the "old" bookings are not integrated in the actual calculation. Because of the fact that the vehicle is the "account" on which the bookings are being done and administrated, the only solution is to register a new vehicle and assign it to the corresponding prepayer card. With this procedure the existing bookings stay unharmed and comprehensible. The new bookings run on a new account(vehicle) with no history. | ||
| − | ==Refund of the remaining amount when the | + | ==Refund of the remaining amount when the prepayer card is returned== |
| − | + | If a prepayer card is being returned and the prepaid amount was not filled completely, the prepaid card owner has the right to get the remaining amount refunded. To balance the prepayer card for the accounting the refund has to be booked in Autopoll. Therefore a manual filling has to be registered under Data - Fillings. You have to pay attention on the following values: | |
| − | * | + | * Date/Time = Date and time of the pay-out |
| − | * | + | * Product = "prepayment" |
| − | * | + | * Volume = 1 |
| − | * | + | * Receipt price = paid out remaining amount |
| − | * | + | * Company = the company in Autopoll on which all prepayment bookings are being done |
| − | * | + | * Vehicle = the affected vehicle |
| − | + | After this booking the account statement of the corresponding prepayer card respectively the vehicle shall report a zero as result. | |
==Additional hints== | ==Additional hints== | ||
| − | * | + | * For the amount limit function the card reader of type CR 2331 R3 requires at least E-prom release 11. |
| − | * | + | * Fillings will only reduce the limits, when they are assigned to the vehicle, which is assigned to the card. |
| − | * | + | * For the card reader of type Hecstar please read the extended [[EN_prepaid_Hecstar|description]]. |
[[Kategorie:EN_Plus]] [[Kategorie:EN_E1441]] | [[Kategorie:EN_Plus]] [[Kategorie:EN_E1441]] | ||
Aktuelle Version vom 23. April 2021, 13:01 Uhr
Preamble
With the function "prepaid fillings" payments can be booked in advance on a company, which can be filled at the card reader afterwards. These prepayments are being booked on a vehicle of the corresponding company, which has to be assigned to a card. For adminstration and control purposes an account statement for the prepayments and the fillings is available.
Pre-conditions
- Autopoll PLUS variant is required
- available from Autopoll version 3.5
- last bugfixing in version 4.2.2.417 FR01 (Jan. 2015).
- Autopoll extension E1441 Modul P1: extended invoicing is required
- a card reader type with a periodical limit, at best the card reader is able to work with an amount limit
Settings
Product registration
To be able to book the prepayments, a suitable product has to be registered first. Details to products under products.
Card reader preparations
The card reader should have a periodical- or reducing-limit function. That means the limit calculated and given by Autopoll can be filled at the card reader. The card is being blocked by the card reader when the limit is reduced to zero and can only be reactivated when a new limit is transmitted from Autopoll.
Due to the fact that the prepaid bookings are amount bookings, the card reader should be able to handl e amount limits.
Configuration with Autopoll
In card readers, which are configured with Autopoll (e.x. Heconomy), the parameter "amount limit" (preselection amount) has to be activated and sent to the card reader. (For the Heconomy: Settings - card reader terminals - open the card reader - Devices - open the device - Master files)
Configuration in the card reader
Card readers, which are not configured with Autopoll (e.x. Hecstar), the correct configuration has to be done in the card reader directly by the card reader service personnel. Please pay attention to the card reader type specific details. E.x.: at a Hecstar periodic limits can not be configured for a single card, but only for a whole card group. Therefore the cards have to be organised correctly and matching in the Hecstar and in Autopoll. Details under prepaid Hecstar.
In case of the situation that the card reader could not handle amount limits, Autopoll will calculate a quantity limit on the base of the highest price for the products assigned to the card. (But this procedure should only be the second option)
Configuration of a prepaid card
The card, which shall be used as prepaid-card, has to be configured with the correct limit type. Data - Cards - All Single Cards - open the card - parameters. Details unter cards
Assignment to a vehicle/driver and company
Prepayment bookings in Autopoll can only be registered on vehilces/drivers and the correspondent company. Therefore the prepayer card has to be assigned to the correct vehilce or driver.
Prepayment booking
Now a prepayment can be booked on the assigned vehicle. The registration will be done under Data - Other Movements.
Important are the booking type ("Receipt texts", wrong translation, should be "prepayment") and the product ("prepayment" in our example).
Furthermore the amount/price has to be input as negative value.
Transmission of the data to the card reader
The changed cards have to be transmitted to the card reader/s.
When working with limits and mileage input at the card reader, the pollings have to separated.
For details read polling process limits and mileage_input
1. polling 1 only the fillings from the card reader (thereby NO card transmission),
2. the card limits will be calculated anew on the base of the new fillings, (respectively the mileage are being set)
3. polling 2 transmission of all cards with the correct limits(and mileage values) to all the card readers.
1. Polling 1 only fillings
3. Polling 2 only the cards
Prepayer account statement
The limit calculation will be done on the base of the prepayments and the stored fillings. This calculation could cover a long period and therefore reacts very sensitive on every change or false entry. Due to this fact it is recommended to execute the prepayer account statement on a monthly basis. During the creation of the account statement the prepayment bookings and fillings since the last account statement are being taken into account and a new closing entry value is being calculated and fixed, which is afterwards the base of the next account statement creation. Working with monthly closing entry values protects the whole prepayment process from manipulations and false entries.
Menu call up
Under Evaluations-Prepayer the report of the account statement is being opened.
Test run
During the test run an account statement is being reported, but no closing entry is being booked.
Production run - real account statement
It is recommended to execute the report account statement in production run on a regular basis. Most customers do it monthly.
Like in most of the Autopoll reports the affected transactions will be counted first and it is possible to repeat the report and/or to recalculate the prices.
Account statement
After the creation the prepayer account statement can be stored for later questioning by the customer or can be handed over to the customer.
Re-use of a prepayer card
If a prepayer card is being returned or confiscated and shall be used again, it has to be secured that the "old" bookings are not integrated in the actual calculation. Because of the fact that the vehicle is the "account" on which the bookings are being done and administrated, the only solution is to register a new vehicle and assign it to the corresponding prepayer card. With this procedure the existing bookings stay unharmed and comprehensible. The new bookings run on a new account(vehicle) with no history.
Refund of the remaining amount when the prepayer card is returned
If a prepayer card is being returned and the prepaid amount was not filled completely, the prepaid card owner has the right to get the remaining amount refunded. To balance the prepayer card for the accounting the refund has to be booked in Autopoll. Therefore a manual filling has to be registered under Data - Fillings. You have to pay attention on the following values:
- Date/Time = Date and time of the pay-out
- Product = "prepayment"
- Volume = 1
- Receipt price = paid out remaining amount
- Company = the company in Autopoll on which all prepayment bookings are being done
- Vehicle = the affected vehicle
After this booking the account statement of the corresponding prepayer card respectively the vehicle shall report a zero as result.
Additional hints
- For the amount limit function the card reader of type CR 2331 R3 requires at least E-prom release 11.
- Fillings will only reduce the limits, when they are assigned to the vehicle, which is assigned to the card.
- For the card reader of type Hecstar please read the extended description.