Päävalikko

Etusivu
Uutiset
Tiedostot
Foorumi
- - - - - - -
Ohjeita ja vinkkejä
- - - - - - -
Lähetä uutinen

Kirjaudu

Tervetuloa, Vieras. Ole hyvä ja kirjaudu tai rekisteröidy.
11.02.2012, 17:04
Tunnus:
Salasana:


Kirjaudu käyttäjätunnuksen, salasanan ja istunnonpituuden mukaan

Unohtuiko salasana?

joomlafi.pngJoomla.fi on avattu!

Joomlaportal.fi:n foorumi suljetaan pian. Siirry uudelle sivustolle ja rekisteröidy: www.joomla.fi

 

FOORUMI on vainluku-tilassa, uusia aiheita ei voi aloittaa. Siirry uudelle Joomla.fi-sivuston foorumille

Uusi maksutapalisäosa: Ennakkomaksu
Joomlaportal.fi
11.02.2012, 17:04 *
Tervetuloa, Vieras. Ole hyvä ja kirjaudu tai rekisteröidy.

Kirjaudu käyttäjätunnuksen, salasanan ja istunnonpituuden mukaan
Uutiset:
 
   Etusivu   Ohjeet Haku Kirjaudu Rekisteröidy  
Sivuja: [1] 2 3 ... 5
  Tulostusversio  
Kirjoittaja Aihe: Uusi maksutapalisäosa: Ennakkomaksu  (Luettu 51238 kertaa)
teemu_m
Konkari
****
Viestejä: 164



Profiili WWW
« : 13.11.2006, 22:22 »

Tervehdys,

Omaa Joomla/VirtueMart -projektiani silmällä pitäen aloin kehittää maksutapalisäosaa (payment method add-on) ennakkomaksulle. Ennakkomaksun keskeisiä vaatimuksia on voida syöttää maksun saajan pankki- yms. tiedot erillään kaupan tiedoista, laskea Pankkiyhdistyksen standardin mukainen pankkiviitenumero, näyttää/lähettää tarvittavat tiedot asiakkaalle, sekä tehdä tarvittavat lisämerkinnät tilauksen tietoihin VirtueMartissa.

Päädyin kirjoittamaan kokonaisen lisäosan, koska muut löytämäni ratkaisut vaativat aina VirtueMartin koodin muokkaamista, mikä puolestaan olisi tarkoittanut jatkuvia vaivoja aina, kun VirtueMart päivittyy tuoreempaan versioon.

Olen testaillut lisäosaa jonkin verran kehitys(PHP5)- ja tuotantoservereillä(PHP4), mutta en varsinaisessa tuotantokäytössä. Kenenkään ei siis kannata suin päin laittaa lisäosaa tuotantosivustolle, mutta laajasta testauksesta muutoin olisi suunnatonta hyötyä. Kaikkinainen palaute olisikin erittäin tervetullutta. Julkaisen lisäosan myöhemmin (toivottavasti jo tällä viikolla) VirtueMartin foorumilla, jahka täällä kertyvän alustavan palautteen huomiot on tarvittaessa siirretty ensimmäiseksi päivitykseksi.

Olen kehittänyt ohjelmistoa englanniksi,  vaikka englanninkielen taitoni ei olekaan erityisen hurrattava, ja vaikka siitä onkin jonkin asteista haittaa myös muille suomenkielisille käyttäjille - suomalaisessa kehittäjä-/käyttäjäyhteisössä haitta on kuitenkin yleensä siedettävä/olematon.
Valitsin siis kuitenkin englannin, jotta lisäosa palvelisi Joomla!/VirtueMart -käyttäjiä myös Suomen ulkopuolella, sillä lukemani perusteella tälle maksutavalle on käyttöä myös muissa maissa.

Lisäosan voi ladata osoitteesta http://www.tyovaline.fi/oss/joomla/virtuemart/dirdepo/

Liitän alle vielä README-tiedoston sisällön. Paketissa on lisädokumentaatiota.

Kiitos kommenteista jo ennakkoon.

Koodia:
README - DirDepo

Direct Deposit Payment Method add-on for VirtueMart (http://www.virtuemart.com/)

General notes - see this README
Installation and user manual - see /doc/user/index.html
Class documentation for developers - see /doc/class/index.html
Changelog - see CHANGELOG
License (GNU GPL) - see LICENSE

Direct deposit as a payment method:
1. Customer selects products to his online shopping basket.
2. During the checkout process he is given a selection of different payment
   methods.
3. If he selects direct deposit, the online shop software (VirtueMart in this
   case) shows him a 'confirmation/thank you' message at the final step of
   checkout process. A confirmation message and order details are also send
   to customer's email address.
   DirDepo, as a payment method add-on, adds a table of information necessary
   for the direct deposit to the end of 'confirmation/thank you' message at the
   final step of checkout process. An other separate email, containing the
   direct deposit information, is also sent to the customer's email address.
   Direct deposit information contains info about the online vendor, the
   customer, the order and the invoicer.
   The vendor and the invoicer don't have to be the one and same party of the
   business transaction. For example 'the vendor', an online shop, might be
   just a marketing name for company, which is the actual invoicer, who
   should receive the direct deposit. On the other hand, the vendor and the
   invoicer can be the very same company or person.
   Most important pieces of direct deposit information are the name of invoicer,
   invoicers's bank and bank account number, bank reference number (or some other
   unique identifier of the deposit) and the total sum of the order.
4. VirtueMart records the order as a 'pending order' into the database. DirDepo
   adds the bank reference number into the order's payment history.
5. Sometime during the following days the customer makes a direct deposit
   to the invoicer's bank account for the sum of the order.
6. The invoicer notes that a deposit has been received and informs the vendor
   about it. The deposit can be linked to a particular order by the bank reference
   number.
7. The vendor updates the order status from 'pending' to 'confirmed'. VirtueMart
   is capable to send a status update notification to the customer if the vendor
   choses so.
8. Vendor finishes the order process (collects items of the order, packs them and
   sends the packet to the customer).

Some notes about the pitfalls of direct deposit as a payment method:
- The customer needs to trust the online vendor, because he is not protected by
  a third party like a credit card company.
  The vendor needs a good reputation, or the customer has to be protected for
  example by a law. Or - the customer has to just take his changes of being
  fooled by a rogue online vendor.
- The customer might never make the deposit.
  The vendor needs to keep book about the pending deposits and their age.
  Maybe the order has to be canceled after certain amount of time? Maybe the
  vendor has to contact the customer before the order can be concidered as
  'canceled'?
  Does the vendor procure or manufacture the order items before the deposit is
  received? Is vendor capable to sell them to some other customer, if this
  particular deposit is never received?
  Does the vendor even send the order to the customer before the deposit is
  received? What if the vendor is fooled by a rogue customer?
  Propably most vendors choose to keep the order pending and don't process the
  order any further before the deposit is received.
- The customer might use wrong bank reference number or no reference at all.
  The invoicer notes he has received a deposit, but can't link it to any
  particular order, because bank reference is wrong or missing. Maybe even
  the sum of deposit is wrong, and maybe the deposit doesn't contain any
  information about its originator? In that case the vendor doesn't have any
  way to know who's order should be completed. Will this upset the customer,
  even if it is actually his fault?
  The importance of bank reference is strongly underlined at DirDepo messages.
  At least finnish bank reference numbers have a checksum that greatly reduce
  the risk of incorrect reference numbers, since the bank validates the
  number before the customer is able to make his deposit. Do all countries have
  a similar bank reference standard? I guess not. How about international bank
  transactions? AFAIK, no. In those cases you may be able to use a message text
  in the deposit as a reference information field, but as an informal message
  it is not validated by a bank.
- Keeping eye on the received transactions does require some labor, especially
  if the reference numbers are wrong or missing very often.
  At least some finnish banks offer their online customers a possibility to
  download an ASCII-file containing a list of lately received deposits and
  their related information like the reference number. Maybe DirDepo or some
  other piece of software will some day include functionality to import such
  a list to VirtueMart and update related orders accordingly?
- I've red how some people are terrified of publishing their online shop's bank
  account number on the internet. If it is insecure to reveal your shop's bank
  account number to a customer during checkout or in the information email,
  then direct deposit isn't for you.
  In Finland it is a normal everyday routine to publish the bank account number
  of a invoicing company to a customer who is being invoiced, and I don't see
  any real risks in it.

Benefits of direct deposit (at least in Finland):
- Cheap. Doesn't require any contracts with third parties, like credit card
  companies, banks or post office, and thus no monthly payments, service fees
  or provisions. A normal bank account is all that is needed.
- Technically simple. No complicated electronic payment gateway transactions.
- Customers are familiar with the basic concept (paying invoices thru a bank).
  Most customers have online banking account, and are thus likely to make
  the deposit quickly after the order.
- Deposits are transfered fairly fast between banks. If customer and invoicer
  use the same bank group, the transaction takes place within a day.
  Transactions between different bank groups takes two to three days.
- Customers don't have to give credit card numbers or any other sensitive
  information to the vendor.

Known limitations of DirDepo:
- At the moment DirDepo is still in alpla state, meaning that it hasn't been
  widely tested in live online shops.
- Only one invoicer per VirtueMart:
  VirtueMart can have several vendors operating under one online shop. At
  the moment it is impossible to configure different invoicer settings for
  different vendors. All vendors need to share the same invoicer settings.
- VirtueMart can have several different instances of any particular payment
  method. It is possible to use DirDepo for several different direct deposit
  payment method instances, but they all need to share the same invoicer
  settings. If this is a problem for your online shop, you need to duplicate
  DirDepo by renaming one file and the subclass in it.
AFAIK, these two limitations above would require changes to the core code of
VirtueMart, or the vendorId and method code would have to duplicated on
configuration form and so on.
- DirDepo doesn't validate its input. This isn't a big problem or a security
  risk, because none of its input is directly from the customer. All
  DirDepo's input comes thru VirtueMart, which validates the user input. But
  the shop administrator needs to think carefully of what he inserts into the
  configuration settings.
This limitation shouldn't be difficult to fix, but it does require some labor.
At the moment the limitations above are not a top priority on my todo list,
because I don't need them personally on my own VirtueMart installation.
- My native language is finnish and my english isn't very good. So the
  DirDepo code and documentation is full of terrible english and bad
  terminology ;) I do how ever feel that it is more beneficial to the
  Joomla/VirtueMart OSS community if I publish DirDepo in english instead of
  finnish. I also feel that it is more beneficial to myself as a learning
  experience and as a peer review and code contributions.
For example corrected english output template file are very welcome.

Benefits of DirDepo:
- Fairly easy to install.
- Doesn't require any modifications to Joomla/VirtueMart core code.
- Support for multiple output languages.
- Output template files easily modified to suit each invoicers needs.
- Ease to extend to fit different banking processes.
- Free of charge. Open source.

At the moment DirDepo add-on includes a subclass which implements direct
deposit process suitable to finnish banking standards. This implementation is
in english and finnish.
Since DirDepo add-on is programmed in Object Oriented fashion, it should be
fairly simple to write other subclasses, which implement slightly different
banking processes for other banking standards. Other languages should be easy
to implement as well.
Please consider to contribute your subclasses, modifications and translations
to the public in the spirit of free and open source software.

As DirDepo is free (free as in speech, see http://www.fsf.org/) and
open source (see http://www.opensource.org/) software, it is free
(free as in beer) of charge.
If you feel that DirDepo is a great add-on to your VirtueMart online shop, and
that you have benefited financially of it, and if you feel you would like to
make a monetary donation, please donate a suitable amount to VirtueMart
(see http://www.virtuemart.com/).

Edit: Poistin vanhan ZIP-paketin ja korjasin oheista linkkiä osoittamaan paketin sijasta hakemistoon.
« Viimeksi muokattu: 14.11.2006, 19:33 kirjoittanut teemu_m » tallennettu

Aivomatic Oy: avoimen lähdekoodin verkkomaksuohjelmistot - www.aivomatic.com
jerppe
Konkari
****
Viestejä: 159



Profiili
« Vastaus #1 : 14.11.2006, 12:29 »

Tuo viitenumero maksu on oikein tervetullut.
Olen ladannut zip.tiedoston koneelleni, nyt minulle on vielä epäselvää että kun olen purkanut zip.tiedoston, niin liitänkö kaikki dirdepo kansiossa olevat tiedostot ja alikansiot ja erillisen ps_dirdepo_fi tiedoston suoraan payment kansioon. Näyttää kieltä
tallennettu
teemu_m
Konkari
****
Viestejä: 164



Profiili WWW
« Vastaus #2 : 14.11.2006, 13:09 »

liitänkö kaikki dirdepo kansiossa olevat tiedostot ja alikansiot ja erillisen ps_dirdepo_fi tiedoston suoraan payment kansioon. Näyttää kieltä

Hyvä kysymys - dokumentaatio voisi olla selvempikin tuolta osin. Korjaan tilannetta lähiaikoina myös pakettiin.

ps_dirdepo_fi.php -tiedosto tulee polkuun
{joomlaInstallDir}/administrator/components/com_virtuemart/classes/payment/ps_dirdepo_fi.php

dirdepo -hakemisto tulee polkuun
{joomlaInstallDir}/administrator/components/com_virtuemart/classes/payment/dirdepo/

Paketissa dirdepo-hakemiston alla olevat tiedostot ja alihakemistot tulee em. polun alle.
Eli esim. {joomlaInstallDir}/administrator/components/com_virtuemart/classes/payment/dirdepo/ps_dirdepo.php


Toinen asia, joka on jäänyt mainitsematta olemassa olevassa dokumentaatiossa, on versiotiedot:
Joomla! 1.0.11 + VirtueMart 1.0.7
En ole testannut aiemmissa versioissa.

'Tuotantoserverillä' PHP 4.3.9 + MySQL 4.1.20. Kehityskoneella on PHP 5.1.? + MySQL 5.0.? (se ei ole nyt tässä käsillä, enkä muista tarkkoja versioita).

P.S. edit: Saattaisi muuten olla parempi, jos paketoin uudelleen niin, että hakemistorakenne on paketissakin Joomlan asennuspolusta lähtien.
« Viimeksi muokattu: 14.11.2006, 13:30 kirjoittanut teemu_m » tallennettu

Aivomatic Oy: avoimen lähdekoodin verkkomaksuohjelmistot - www.aivomatic.com
lokki
Täysjäsen
***
Viestejä: 140


Profiili
« Vastaus #3 : 14.11.2006, 13:45 »

Itse asentelin tuon eilen ilta myöhällä ja asennus onnistui kerralla ihan ohjeiden mukaan, vaikken mikään Joomala/PHP asiantuntija (vielä) olekkaan. Testailla olen ehtinyt vasta vähän mutta hyvin tuntuu toimivan.

Jos jotain pientä viilaamista asiakkaista ajatellen mainitsisi niin tuon viitenumeron voisi pätkiä viiden numeron sarjoihin.  Osat joista viitenumero muodeostetaan näyttäisivät olevan kohtuullisen helposti muutettavissa (kunhan opettelen PHP:tä) ajattelin yrittää koota viitenumeron vuodesta, asiakasnumerosta ja laskunnumerosta + tarkisteesta.

Mielessä pyöriin ajatuksia siitä, että lasku "lomaketta" voisi muokata vähän enemmän perinteisen laskun näköiseksi. Toisaalta tarvetta olisi myös saada vakioasiakkaille lasku eräpäivällä eli sellainen joka laitetaan toimituksen mukaan tai toimitetaan erikseen postissa...
tallennettu

Aina on olemassa yksi mahdollisuus, eikä sekään ole viimeinen!
jerppe
Konkari
****
Viestejä: 159



Profiili
« Vastaus #4 : 14.11.2006, 13:51 »

Uusi asennuspaketti voisikin olla ihan paikallaan, asensin äskettäin ohjeiden mukaan ( ehkä) mutta Virtuemartissa oli kuitenkin vanha käytössä. Yritin luoda uutta maksutapaa mutta oli vanha taulu, ehkä tein jotain väärin, kun olen näissä polku jutuissa vähän pihalla.  Näyttää kieltä
Käytössäni on Joomla! 1.0.11 ja virtuemart 1.07.
tallennettu
jerppe
Konkari
****
Viestejä: 159



Profiili
« Vastaus #5 : 14.11.2006, 15:04 »

Nyt en kyllä tajua yhtään että miksi en saa toimimaan uutta maksutapaa.  Huh

Jäänkin odottamaan kun saat paketoitua uudelleen hakemistorakenteen ja laitat jakeluun.  Näyttää kieltä

Siinä asennuksessa on nyt joku sellainen kohta jota en saa uppoamaan tajuntaani. Yleensä kyllä olen saanut onnistumaan foorumilla olevien pakettien lisäämisen ilman ongelmia.  Näyttää kieltä ,kuten esimerkiksi Joomla! ja Virtuemart päivityksetkin.
tallennettu
teemu_m
Konkari
****
Viestejä: 164



Profiili WWW
« Vastaus #6 : 14.11.2006, 15:26 »

tuon viitenumeron voisi pätkiä viiden numeron sarjoihin.

Totta. Niinhän tuo Suomen Pankkiyhdistyksen standardi itse asiassa näyttää suosittavan.

Viiden merkin ryhmiin pätkimisen jälkeen viite tulisi siis olemaan 'VUUUU UUOOO OOOOC'.

Onnistunee seuraavalla koodilla:
Koodia:
<?php
$number
= strrev(chunk_split (strrev($number), 5, ' '))
?>


Lainaus
Osat joista viitenumero muodeostetaan näyttäisivät olevan kohtuullisen helposti muutettavissa (kunhan opettelen PHP:tä) ajattelin yrittää koota viitenumeron vuodesta, asiakasnumerosta ja laskunnumerosta + tarkisteesta.

Joo, pitäisi onnistua hyvin vähällä modistamisella. Esim. yksinkertaisin mahdollinen modistettu ps_dirdepo_fi::makeBankRef()

Koodia:
function makeBankRef()
{
    $refNum = date('Y').
    str_pad($this->ddInfo['user_id'], 5, '0', STR_PAD_LEFT).
    str_pad($this->ddInfo['order_id'], 7, '0', STR_PAD_LEFT);
    $this->ddInfo['bank_ref'] = $refNum.$this->countBankRefCheckSum($refNum);
}

(No jos ollaan oikein tarkkoja, niin tuohan ei ota tilauksen päivämäärää, vaan koodi suorittamisen päivämäärän. Vuodenvaihteen paikkeilla muutaman sekunnin aikana voisi tulla väärä vuosiluku. Parempi olisi käyttää muuttujaa ddInfo['order_date'], mutta en nyt millään viitsi ruveta vääntämään sillä toimivaa funktiota. Pitää ottaa huomioon, että 'order_date':n muoto vaihtelee kaupan localen mukaan.)

Nykyinen formaattihan on seuraava:

Numeric format is 'VUUUUUUOOOOOOOC' where:

    * V = Vendor Id, length can change, no padding.
    * U = User ID, max length 5 character, left padding with zeros. Max value 99999.
    * O = Order ID, max length 7 character, left padding with zeros. Max value 9999999.
    * C = checksum according to Finnish Banker's Assosiation standard. Length one character.

Itse en pidä tuota erityisen seinään naulattuna formaattina. Yleisen käytettävyyden kannalta tuntuisi hyödylliseltä, että Vendor Id on osa viitettä siltä varalta, että vendoreita on useita. Itselläni ja monella muulla sellaista tarvetta ei varmasti ole. Ja loppu viimein kaikki muut tiedot voi kaivella esiin tilausnumeron kautta.

Nyt kun ajattelen asiaa tarkemmin, niin tuo nykyinen viiteformaatti on tarpeettoman pitkä. Pankkiyhdistyksen sallima pituus on 4-20 merkkiä, mutta tuo 15 merkkiäkin on asiakkaan kannalta kovin pitkä naputeltava.

Hyviä ideoita paremmasta viiteformaatista otetaan mielellään vastaan. Itse olen jotenkin taipuvainen tiputtamaan koko UserId:n pois.

Lainaus
Mielessä pyöriin ajatuksia siitä, että lasku "lomaketta" voisi muokata vähän enemmän perinteisen laskun näköiseksi.

Jos joku keksii oikein fiksun näköisen templaten, niin sehän ois kiva. Nykyinen on kuta kuinkin suora kopio VirtueMartin omasta tilauksenvahvistusviestistä.


Lainaus
Toisaalta tarvetta olisi myös saada vakioasiakkaille lasku eräpäivällä eli sellainen joka laitetaan toimituksen mukaan tai toimitetaan erikseen postissa...

Tämä saattaa kiinnostaa itseänikin, tosin tämän hetken aikomukseni on hanskata perinteinen/sähköinen laskutus täysin erillisellä yhteistyökumppanin ERP-järjestelmällä.

Mutta pitäisikös laskujen olla numeroitu numerosarjalla, jossa ei ole katkoksia välissä? DirDepossahan ei ole sellaisen numerosarjan muodostamiseen mitään toiminnallisuutta.
tallennettu

Aivomatic Oy: avoimen lähdekoodin verkkomaksuohjelmistot - www.aivomatic.com
lokki
Täysjäsen
***
Viestejä: 140


Profiili
« Vastaus #7 : 14.11.2006, 17:41 »


Lainaus
Totta. Niinhän tuo Suomen Pankkiyhdistyksen standardi itse asiassa näyttää suosittavan.

Onnistunee seuraavalla koodilla:
Koodia:
<?php
$number
= strrev(chunk_split (strrev($number), 5, ' '))
?>


Mihinkä tiedostoon ja kohtaan tämä pitäisi laittaa?

Lainaus
Nyt kun ajattelen asiaa tarkemmin, niin tuo nykyinen viiteformaatti on tarpeettoman pitkä. Pankkiyhdistyksen sallima pituus on 4-20 merkkiä, mutta tuo 15 merkkiäkin on asiakkaan kannalta kovin pitkä naputeltava.

Olen samaa mieltä, lyhyt viitenumero on mukava käyttää. Viitenumeron tarkoitushan on yksilöidä maksusuoritus vastaanottajan tarpeiden pohjalta. Useimmille varmasti riittää tuo laskunumero tähän yksilöimiseen...

Lainaus
Jos joku keksii oikein fiksun näköisen templaten, niin sehän ois kiva. Nykyinen on kuta kuinkin suora kopio VirtueMartin omasta tilauksenvahvistusviestistä.

Muistaakseni pankkiyhdistyksen sivuilta löytyi aikanaan xls/doc lomake, josta muokkaamalla sais ehkä jotain... Joskus vuosia sitten olen käyttänyt tuota pohjana kun koodailin Delphillä laskutusjärjestelmää, sen jälkeen on koodaus taidot vähän päässyt repsahtamaan  Surullinen

Lainaus
Tämä saattaa kiinnostaa itseänikin, tosin tämän hetken aikomukseni on hanskata perinteinen/sähköinen laskutus täysin erillisellä yhteistyökumppanin ERP-järjestelmällä.
Itse tässä vasta tutkin ja kehittelen eri vaihtoehtoja tuon verkkokaupan suhteen. Toistaiseksi VM tällä ennakkomaksu jutulla vaikuttaa ihan toimivalta paketilta. Vieläkun tuohon sais tuon verkkomaksu jutun jostain niin paketti olis kasassa  Hymyilee

Lainaus
Mutta pitäisikös laskujen olla numeroitu numerosarjalla, jossa ei ole katkoksia välissä? DirDepossahan ei ole sellaisen numerosarjan muodostamiseen mitään toiminnallisuutta.
Olishan tuo aivan loistavaa ja vielä niin että tuon saisi nollattua aina vuoden alussa tai niin että laskunumeron sais asetettua alkamaan jostain tietystä kohtaa (tämä saattaa VM:llä olla toki mahdollista jo nyt).

« Viimeksi muokattu: 14.11.2006, 17:43 kirjoittanut lokki » tallennettu

Aina on olemassa yksi mahdollisuus, eikä sekään ole viimeinen!
teemu_m
Konkari
****
Viestejä: 164



Profiili WWW
« Vastaus #8 : 14.11.2006, 18:32 »

Mihinkä tiedostoon ja kohtaan tämä pitäisi laittaa?

Se oli enempi teoreettinen esimerkki chunk_split() -funktion käytöstä. Sisällytin sen uusimpaan versioon muiden muutosten mukana.

Tämän viestiketjun pohjalta päivitetyn version (0.1.1) voi ladata osoitteesta http://www.tyovaline.fi/oss/joomla/virtuemart/dirdepo/

Tässä pätkä CHANGELOG:ia
Koodia:
- - - - - 0.1.1 - - - - -

2006-11-14 Teemu Mäntynen <teemu.mantynen@tyovaline.fi>
  * ps_dirdepo_fi.php / ps_dirdepo_fi::makeBankRef()
    - User ID is no longer part of the bank reference number, and Order Id is
      padded to 6 characers instead of 7. Changed because 15 characters is too
      long and might cause too much typing errors for customers.
    - Reference number is split into chunks of five characters to make the number
      more easily readable for the customers and to follow the Finnsh Bankers'
      Association's standard.

  * README
    - Added information about development envinroment (Joomla! 1.0.11,
      VirtueMart 1.0.7 etc.).

  * /doc/user/index.html
    - Added more detailed information about installation directories.

  * ZIP-package
    - Included installation directory structure.
tallennettu

Aivomatic Oy: avoimen lähdekoodin verkkomaksuohjelmistot - www.aivomatic.com
lokki
Täysjäsen
***
Viestejä: 140


Profiili
« Vastaus #9 : 14.11.2006, 22:06 »

Viitenumero ryhmittyy nyt hienosti...

Yritin rakennella tuota laskulomaketta mutta vielä ei syntynyt mitään julkaisukelpoista.  Virnistää

tallennettu

Aina on olemassa yksi mahdollisuus, eikä sekään ole viimeinen!
mijo
Täysjäsen
***
Viestejä: 148


Profiili
« Vastaus #10 : 15.11.2006, 09:20 »

Mallia laskuille: http://www.pankkiyhdistys.fi/sisalto/common/showpage.asp?id=450

(itse käytetty malleja muussa yhteydessä mm. yhdistyksen jäsenmaksuissa)
tallennettu
jerppe
Konkari
****
Viestejä: 159



Profiili
« Vastaus #11 : 15.11.2006, 12:24 »

Nyt on asennettu ennakkomaksu.
Se asentuikin jouhevasti  kun maltoin lukea kaikki ohjeet.  Näyttää kieltä
Uuden maksutavan luomisessa sekoilin kunnes kävin ohjeet läpi.
Ohjeet olivatkin erittäin yksityiskohtaiset ja selkeät.
Täytyykin nyt jäädä odottelemaan jos lokki saisi rakenneltua vielä sitä laskulomaketta, eipä silti, kyllä tuolla nykyiselläkin tulee hyvin toimeen.  Virnistää
tallennettu
teemu_m
Konkari
****
Viestejä: 164



Profiili WWW
« Vastaus #12 : 15.11.2006, 13:11 »

Tulipa tuossa mieleeni vielä sellainenkin, että DirDepo ei käsittele vendorin valuuttalaji-tietoa mitenkään (kannassa _#_vm_vendor.vendor_currency). Suurin osa käyttäjistä voi luonnollisesti hanskata tämän käyttämällä kiinteää merkkijonoa template-tiedostossa, mutta yleiskäytännöllisyyden nimissä sellainen pitää vielä lisätä.

Jos joku par'aikaa vääntää uutta templatea, niin voi ainakin mielessään lisätä sinne jo placeholderin {dirDepoVendorCurrency}. Template toimii toki ilmankin (minkä vain placeholderin voi poistaa, mutta uusia ei voi keksiä ihan tuosta vain omasta päästään).

Tuleeko teille mieleen jotain tietokenttiä mitä siihen voisi vielä lisätä? Voisin yrittää lisäillä kaikki kerralla, että ei tarvitse jokaisesta ahaa-elämyksestä tehdä aina uutta versiopakettia Iskee silmää

Suuri kiitos lokille ja mijolle template-asian tutkiskelusta.
tallennettu

Aivomatic Oy: avoimen lähdekoodin verkkomaksuohjelmistot - www.aivomatic.com
pauli_m
Tulokas
*
Viestejä: 18


Profiili
« Vastaus #13 : 22.11.2006, 17:13 »

Kiitokset ensinnäkin kehittäjille tärkeästä "työstä"!

Itselläni seuraavanlainen ongelma:

Käytössä J1.0.10 ja VM 1.0.7

Kun käytän tätä ennakkomaksua, niin se käyttäytyy samanlailla kuin postiennakolla tilaisi. Eli tilaajalle tulee tilauksesta tieto, mutta ilman tilitietoja ja viitenumeroita mitä pitäisi tällä ennakkomaksulla tulla. Lisäksi minulle ei tule mitään tietoa meiliin tilauksesta. Käsittääkseni sekin pitäisi tulla kun on laitettu se meiliosoite sinne configurationiin...

Mielestäni kaiken olen asentanut oikein. Onko vika Joomlan versiossa? Pitääkö päivittää 11-versioon ja tuleeko mitään ongelmia päivityksessä vai säilyykö kaikki asetukset yms. ennallaan?

« Viimeksi muokattu: 22.11.2006, 17:16 kirjoittanut pauli_m » tallennettu
teemu_m
Konkari
****
Viestejä: 164



Profiili WWW
« Vastaus #14 : 22.11.2006, 18:06 »

Eli tilaajalle tulee tilauksesta tieto, mutta ilman tilitietoja ja viitenumeroita mitä pitäisi tällä ennakkomaksulla tulla. Lisäksi minulle ei tule mitään tietoa meiliin tilauksesta.

Ennakkomaksukikkulan pitäisi ensinnäkin näyttää checkoutin viimeisessä vaiheessa (siinä jossa yleensä vain lyhyesti kiitetään ja kerrotaan, että tilausvahvistus on lähetetty emailiin) extrataulukko, jossa on ennakkomaksu suorittamiseen tarvittavat tiedot (saajan nimi, pankki, viite, summa jne.).

Toisekseen ennakkomaksukikkulan pitäisi lähettää erillinen email, jossa on nuo samaiset ennakkomaksun suorittamiseen tarvittavat tiedot. Eli VirtueMartin tavalliseen tilausvahvistus-emailiin ei lisätä mitään tai siitä ei poisteta mitään, vaan sen lisäksi lähetetään siis erillinen email.

Lainaus
Mielestäni kaiken olen asentanut oikein.

Oletko varmasti muistanut maksutavan konfigurointi-ikkunan toisella sivulla ("asetukset") lisätä vaaditun PHP-koodin "Payment Extra Info" -kenttään? Jos Ennakkomaksu on asiakkaan valittavissa, mutta ei tee mitään (edes aiheuta virheilmoituksia), niin ekaksi tulee mieleen, että toi ao. koodi  puuttuu.

Koodia:
<?php
/**
 * This script has to be inserted into the Payment Method Configuration Form's Payment Extra Info field
 *
 * When VirtueMart runs this script, the script collects info from VirtueMart and
 * configuration file, and passes the info to DirDepo, and tells DirDepo to run
 * all the necessary methods.
 * @package DirDepo
 * @uses ps_dirdepo_fi::ps_dirdepo_fi()
 * @uses ps_dirdepo::setLanguage()
 * @uses ps_dirdepo::setInfo()
 * @uses ps_dirdepo::sendMail()
 * @uses ps_dirdepo::getDebugMessages()
 * @uses ps_dirdepo::getErrorMessages()
 * @uses ps_dirdepo::echoCheckoutMessage()
 * @uses ps_dirdepo::updateOrder()
 */

global $vars;

/**
 * Run DirDepo only at the end of checkout process
 */
if($vars['page'] == 'checkout.thankyou'){
    
/**
     * Requires the ps_dirdepo_fi class
     */
    
require_once (CLASSPATH."/payment/ps_dirdepo_fi.php");
    
/**
     * Requires the configuration file
     */
    
require_once (CLASSPATH."/payment/dirdepo/ps_dirdepo_fi.cfg.php");
    global
$mosConfig_fromname, $mosConfig_lang, $sess;
    
$DirDepo = new ps_dirdepo_fi();
    
$DirDepo->setLanguage($mosConfig_lang);
    
$DirDepo->setInfo($db->f('order_id'),
                    
$db->f('vendor_id'),
                    
$db->f('payment_method_id'),
                    
$db->f('payment_method_name'),
                    
$mosConfig_fromname,
                    
DIRDEPO_EMAIL_SUBJECT,
                    
DIRDEPO_INVOICER_NAME,
                    
DIRDEPO_INVOICER_BANK,
                    
DIRDEPO_INVOICER_ACCOUNT,
                    
DIRDEPO_INVOICER_VAT_ID,
                    
DIRDEPO_INVOICER_IBAN,
                    
DIRDEPO_INVOICER_BIC,
                    
DIRDEPO_INVOICER_DAYS_WITHIN,
                    
DIRDEPO_INVOICER_PHONE,
                    
DIRDEPO_INVOICER_EMAIL,
                    
DIRDEPO_INVOICER_FAX,
                    
DIRDEPO_INVOICER_ADDRESS1,
                    
DIRDEPO_INVOICER_ADDRESS2,
                    
DIRDEPO_INVOICER_ZIP,
                    
DIRDEPO_INVOICER_CITY,
                    
DIRDEPO_INVOICER_STATE,
                    
DIRDEPO_INVOICER_COUNTRY,
                    
$sess->url(SECUREURL."index.php?page=account.order_details&order_id=".$db->f('order_id')),
                    
DIRDEPO_EMAIL_FORMAT
                    
);
    
$DirDepo->sendMail();
    
$vmLogger->debug($DirDepo->getDebugMessages());
    if(
$DirDepo->isError()){
        
$vmLogger->err($DirDepo->getErrorMessages());
    } else {
        
$DirDepo->echoCheckoutMessage();
        
$DirDepo->updateOrder();
    }
}
?>


Entä oletko koittanut ajaa VirtueMartia Debug-tilassa? Ennakkomaksukikkulan pitäisi näyttää liuta debug-tietoja.


Lainaus
Onko vika Joomlan versiossa? Pitääkö päivittää 11-versioon...

En osaa sanoa, en ole ikinä koittanut.

tallennettu

Aivomatic Oy: avoimen lähdekoodin verkkomaksuohjelmistot - www.aivomatic.com
Sivuja: [1] 2 3 ... 5
  Tulostusversio  
 
Siirry:  

MySQL pohjainen foorumi PHP pohjainen foorumi Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Validi XHTML 1.0! Validi CSS!