Potrzebne tagi w wiadomościach

[Ks. Robak 314]

 

Aby zrobić automatyzację wiadomości potrzebny jest dostęp do następujących informacji - tagów:

 

-czy transakcja pochodzi z serwisu aukcyjnego

-znacznik czy paczka jest pobraniowa

-NIP klienta

-typ dokumentu końcowego

 

To póki co tyle co mi się nasunęło, że nie ma.

 

Uzasadnienie:

-informacja o tym czy transakcja pochodzi z serwisu aukcyjnego jest potrzebna aby zrobić szablon rozróżniający typ wiadomości do klienta, tzn. zawierający w swojej treści odpowiednie zwroty "allegro", "aukcja", "sklep", "reklamacja" - według potrzeb.

Obecnie wszędzie mam, że dziękuję za zakup na aukcji, a w potwierdzeniu wysyłki wszędzie informuję, że wysłano zakupione towary, podczas gdy niekiedy jest to wysyłka reklamacji (to czy jest to reklamacja można testować po polu "Dotyczy").

A jak chcę obsłużyć zamówienie emailowe, to muszę wyłączyć wiadomości automatyczne i wysyłać wiadomości ręcznie, z szablonów bez słów "allegro" czy "aukcja".

 

-czy paczka jest pobraniowa - to jest coś, co pozwoliłoby obsługiwać jednym szablonem wszystkie typy przesyłek. Obecnie wykombinowałem, że można sprawdzać czy jest pobraniowa po tagu "Pozostało do zapłaty", jak będzie równy "0,00 PLN" to znaczy że nie pobranowa. Ale fajnie jak by był tag specjalnie do tego celu.

 

-NIP i rodzaj dokumentu końcowego. To jest potrzebne do zrobienia szablonu rozróżniającego "konsumenta" od firmy. Dzięki temu możnaby wysyłać pouczenia z Ustawy o prawach konsumenta tylko do konsumentów, a do firm pouczenie, że zwrotów nie ma

Sam rodzaj dokumentu końcowego, czy sam NIP nie rozwiąże sprawy - może być faktura detaliczna bez NIP, lub NIP u klienta który wybrał paragon.

 

Dziękuję za uwagę.

[PanBanBan Marcin 185]

Aby zrobić automatyzację wiadomości potrzebny jest dostęp do następujących informacji - tagów:

 

-czy transakcja pochodzi z serwisu aukcyjnego

-znacznik czy paczka jest pobraniowa

-NIP klienta

-typ dokumentu końcowego

 

To póki co tyle co mi się nasunęło, że nie ma.

 

Uzasadnienie:

-informacja o tym czy transakcja pochodzi z serwisu aukcyjnego jest potrzebna aby zrobić szablon rozróżniający typ wiadomości do klienta, tzn. zawierający w swojej treści odpowiednie zwroty "allegro", "aukcja", "sklep", "reklamacja" - według potrzeb.

Obecnie wszędzie mam, że dziękuję za zakup na aukcji, a w potwierdzeniu wysyłki wszędzie informuję, że wysłano zakupione towary, podczas gdy niekiedy jest to wysyłka reklamacji (to czy jest to reklamacja można testować po polu "Dotyczy").

A jak chcę obsłużyć zamówienie emailowe, to muszę wyłączyć wiadomości automatyczne i wysyłać wiadomości ręcznie, z szablonów bez słów "allegro" czy "aukcja".

 

-czy paczka jest pobraniowa - to jest coś, co pozwoliłoby obsługiwać jednym szablonem wszystkie typy przesyłek. Obecnie wykombinowałem, że można sprawdzać czy jest pobraniowa po tagu "Pozostało do zapłaty", jak będzie równy "0,00 PLN" to znaczy że nie pobranowa. Ale fajnie jak by był tag specjalnie do tego celu.

 

-NIP i rodzaj dokumentu końcowego. To jest potrzebne do zrobienia szablonu rozróżniającego "konsumenta" od firmy. Dzięki temu możnaby wysyłać pouczenia z Ustawy o prawach konsumenta tylko do konsumentów, a do firm pouczenie, że zwrotów nie ma

Sam rodzaj dokumentu końcowego, czy sam NIP nie rozwiąże sprawy - może być faktura detaliczna bez NIP, lub NIP u klienta który wybrał paragon.

 

Dziękuję za uwagę.

Wow - nie przyszło mi nawet do głowy, że można by stworzyć maila automatycznego do reklamacji

Dobre pomysły, popieram.

 

1. A czy nie dałoby się częściowo tego załatwić już dziś? Bo np. Sello rozróżnia wiadomości mailowe dla przesyłek pobraniowych i płatnych z góry więc nie ma potrzeby tworzyć jednego szablonu wiadomości. Można to rozdzielić na dwa szablony wiadomości...

 

2. Nie rozróżnisz klienta po typie dokumentu końcowego i NIP'ie - to nic nie da. Bo konsument zawsze może wziąć fakturę i w niej podać NIP. Trzeba by tu jeszcze dołączyć warunek rozróżniający pola Imię i Nazwisko od Nazwy. I wtedy jeśli byłaby faktura +NIP +nazwa to można by przyjąć że jest to konsument. Ale nawet i tutaj zdarzają się klienci co w nazwie firmy wpisują np. myślnik lub piszą brak więc skuteczność takiego rozróżniania byłaby powiedzmy na poziomie 80%, a musi być 100% bo konsumentom musisz posłać co musisz posłać. Możliwość rozróżniania typu klienta podoba mi się ale chyba nie da się tego zrobić więc ja bym tutaj proponował uniwersalny zapis

 

Tylko czy do tego - wykombinowałeś już jak można by zrobić modyfikator AND bo wg mnie dałoby się, tylko nie wziąłem się jeszcze za niego. Na razie testuję OR ale już wychodzi mi na to, że do OR będzie można podać ile się chce warunków (w nieskończoność).

 

3. Tak samo zamiast rozróżniania po polu "Dotyczy" to wolałbym rozróżnianie po cechach transakcji bo jak w polu dotyczy pomylisz się i zrobisz literówkę (a jak się ma kilka osób w firmie to takie pomyłki zdarzają się nad zwyczaj często) to wyśle się zły mail.

 

4. To ja proponuję jeszcze do wiadomości mailowych tag lub modyfikator "załącz plik" - jeśli w tagu jest spełniony jakiś warunek to "załącz plik" i ścieżka do niego - najlepiej na serwerze, żeby nie było problemów z uprawnieniami dostępu Skończyłyby się prośby o możliwość dołączania do wiadomości plików:

a) z fakturami - trzeba by tylko wykombinować żeby drukując faktury z SGT równocześnie był tworzony plik pdf z  obrazem faktury w określonej lokalizacji, a potem to już tylko:

[dowolny tag]|załącz plik=`ścieżka do folderu\[Transakcja::DokumKoncowy]`

b) warunkami gwarancji,

c) procedurami reklamacji,

d) instrukcjami,

itd.

[gawcio . 21]

To ja proponuję jeszcze do wiadomości mailowych tag lub modyfikator "załącz plik"

TAK i jeszcze raz TAK, faktury, instrukcje do towaru, cuda:P

 

 

[PanBanBan Marcin 185]

To ja proponuję jeszcze do wiadomości mailowych tag lub modyfikator "załącz plik"

TAK i jeszcze raz TAK, faktury, instrukcje do towaru, cuda:P

LOL wiedziałem, że oddasz swój głos poparcia dla tej funkcjonalności

 

[Ks. Robak 314]

 

Wow - nie przyszło mi nawet do głowy, że można by stworzyć maila automatycznego do reklamacji

Dobre pomysły, popieram.

 

1. A czy nie dałoby się częściowo tego załatwić już dziś? Bo np. Sello rozróżnia wiadomości mailowe dla przesyłek pobraniowych i płatnych z góry więc nie ma potrzeby tworzyć jednego szablonu wiadomości. Można to rozdzielić na dwa szablony wiadomości...

 

 

Do wysłanych paczek pobraniowych faktycznie używam już teraz osobnego szablonu.

Ale dla nowych transakcji nie.

Już nie pamiętam dlaczego....

Może włączę na chwilę i sobie przypomnę

 

2. Nie rozróżnisz klienta po typie dokumentu końcowego i NIP'ie - to nic nie da. Bo konsument zawsze może wziąć fakturę i w niej podać NIP.

 

Faktura z NIPem to tylko i wyłącznie firma.

Konsumenci nie mają NIPów.

 

 

Tylko czy do tego - wykombinowałeś już jak można by zrobić modyfikator AND bo wg mnie dałoby się, tylko nie wziąłem się jeszcze za niego.

 

Hmmm.....

Tu jest dobre pytanie.

 

Bo wygląda na to, że "then" przyjmuje tylko wartość tekstową i nie da się tam wcisnąć kolejnego poziomu parsowania.

Nie mam pomysłu

 

 

Na razie testuję OR ale już wychodzi mi na to, że do OR będzie można podać ile się chce warunków (w nieskończoność).

 

3. Tak samo zamiast rozróżniania po polu "Dotyczy" to wolałbym rozróżnianie po cechach transakcji bo jak w polu dotyczy pomylisz się i zrobisz literówkę (a jak się ma kilka osób w firmie to takie pomyłki zdarzają się nad zwyczaj często) to wyśle się zły mail.

 

 

Cechy to odrębna konieczność.

Potrzebne są i cechy i "Dotyczy" 

 

4. To ja proponuję jeszcze do wiadomości mailowych tag lub modyfikator "załącz plik" - jeśli w tagu jest spełniony jakiś warunek to "załącz plik" i ścieżka do niego - najlepiej na serwerze, żeby nie było problemów z uprawnieniami dostępu Skończyłyby się prośby o możliwość dołączania do wiadomości plików:

a) z fakturami - trzeba by tylko wykombinować żeby drukując faktury z SGT równocześnie był tworzony plik pdf z  obrazem faktury w określonej lokalizacji, a potem to już tylko:

[dowolny tag]|załącz plik=`ścieżka do folderu\[Transakcja::DokumKoncowy]`

b) warunkami gwarancji,

c) procedurami reklamacji,

d) instrukcjami,

itd.

 

 

To jest dobry pomysł.

 

Ale potrzebny jest jeszcze jeden mechanizm - zgłoszenie błędu.

Tak aby źle napisany skrypt, lub brakujący plik, poinformował użytkownika np. w logu, że coś jest nie tak. Mail wówczas nie może zostać wysłany.

Podobnie zresztą jak wadliwy szablon aukcji.

 

[PanBanBan Marcin 185]

Faktura z NIPem to tylko i wyłącznie firma.

Konsumenci nie mają NIPów.

Jak to nie mają. Przecież mam w moim SGT konsumentów co kupowali na fakturę z NIP'em. Dopiero teraz to wystarczy ludziom PESEL ale nic nie stoi na przeszkodzie, żeby klient konsument wziął fakturę i wpisał NIP. I wtedy w formule wyjdzie błąd

 

Tylko czy do tego - wykombinowałeś już jak można by zrobić modyfikator AND bo wg mnie dałoby się, tylko nie wziąłem się jeszcze za niego.

Hmmm.....

Tu jest dobre pytanie.

Bo wygląda na to, że "then" przyjmuje tylko wartość tekstową i nie da się tam wcisnąć kolejnego poziomu parsowania.

Nie mam pomysłu

Spokojnie... coś wykombinujemy

 

Ale potrzebny jest jeszcze jeden mechanizm - zgłoszenie błędu.

Tak aby źle napisany skrypt, lub brakujący plik, poinformował użytkownika np. w logu, że coś jest nie tak. Mail wówczas nie może zostać wysłany.

Podobnie zresztą jak wadliwy szablon aukcji.

Zgłoszenie błędu - raczej nie wydaje mi się to możliwe, choćby z tego powodu, że wpisując w szablonie aukcji tag możemy zrobić literówkę i wtedy zostanie potraktowany jako zwykły tekst. Raczej dla skomplikowanych wyrażeń trzeba będzie je samemu dobrze przetestować...

[Ks. Robak 314]

Faktura z NIPem to tylko i wyłącznie firma.

Konsumenci nie mają NIPów.

Jak to nie mają. Przecież mam w moim SGT konsumentów co kupowali na fakturę z NIP'em. Dopiero teraz to wystarczy ludziom PESEL ale nic nie stoi na przeszkodzie, żeby klient konsument wziął fakturę i wpisał NIP. I wtedy w formule wyjdzie błąd

 

 

 

Jak weźmie fakturę z NIPem to już będzie na działalność gospodarczą czyli nie konsument.

A jak się będzie upierał, że nie prowadzi działalności, tylko tak sobie wpisał stary NIP to należy mu zacytować kodeks karno skarbowy, gdzie za posługiwanie się nieprawdziwym numerem grozi kara do 10 lat ciężkich łagrów.

Jak chce zwracać w ciągu 14 dni to dobrze, ale najpierw będę zmuszony zgłosić przestępstwo skarbowe, niech Pan szykuje szczoteczkę i worek cebuli

[gawcio . 21]

Wspominałeś też o cechach, w tym miejscu też by się przydały, jeżeli cecha to "reklamacja" to szablon taki. Duże możliwości.

Najbardziej jednak ucieszył by mnie tag, który nazywałby się: "SQL", przyjmował by on wartość zapytania zdefiniowanego w jakimś słowniku, wtedy to już rzeczywiście były by nieograniczone możliwości:)

 

Jest jeszcze kwestia notatek, można sprawdzić notatkę do transakcji, ale nie można notatki z paczki, moje reklamacje nie mają powiązanych transakcji, dlatego też przydał by się tag, notatek z paczek.

[Bartosz Rosa 1 785]

Bo wygląda na to, że "then" przyjmuje tylko wartość tekstową i nie da się tam wcisnąć kolejnego poziomu parsowania.

 

Niestety obecnie jestem z dala od możliwości sprawdzenia poniższego rozwiązania, ale możesz spróbować realizacji ANDa w ten sposób. (niesprawdzone rozwiązanie)

[Towar::Nazwa|contains=`telefon`|then=`[Towar::Nazwa|contains=`czerwony`|then=`[szablon::Blok::czerwony_telefon]`|else=``]`|else=``]

 

Najpierw rozparsuje się blok o nazwie czerwony_telefon, w drugiej iteracji sprawdzona zostanie nazwa towaru czy jest w niej słowo czerwony, jesli tak, to tag zamieniony zostanie na wartość bloku, jeśli nie to jego wartość będzie pusta. W trzeciej iteracji jeśli w nazwie jest słowo telefon to tag przyjmie wartość zwróconą przez THEN, czyli blok albo nic. Jeśli takiego słowa nie będzie to przyjmie nic. Innymi słowy aby na końcu powstał wynik zawierający treść bloku, oba słowa czyli czerwony i telefon muszą być w nazwie.

[Ks. Robak 314]

Przetestuję, ale jak zwykle nie mam czasu...

Pewnie w sobotę najszybciej ....

[PanBanBan Marcin 185]

Bo wygląda na to, że "then" przyjmuje tylko wartość tekstową i nie da się tam wcisnąć kolejnego poziomu parsowania.

 

Niestety obecnie jestem z dala od możliwości sprawdzenia poniższego rozwiązania, ale możesz spróbować realizacji ANDa w ten sposób. (niesprawdzone rozwiązanie)

[Towar::Nazwa|contains=`telefon`|then=`[Towar::Nazwa|contains=`czerwony`|then=`[szablon::Blok::czerwony_telefon]`|else=``]`|else=``]

 

Najpierw rozparsuje się blok o nazwie czerwony_telefon, w drugiej iteracji sprawdzona zostanie nazwa towaru czy jest w niej słowo czerwony, jesli tak, to tag zamieniony zostanie na wartość bloku, jeśli nie to jego wartość będzie pusta. W trzeciej iteracji jeśli w nazwie jest słowo telefon to tag przyjmie wartość zwróconą przez THEN, czyli blok albo nic. Jeśli takiego słowa nie będzie to przyjmie nic. Innymi słowy aby na końcu powstał wynik zawierający treść bloku, oba słowa czyli czerwony i telefon muszą być w nazwie.

 

Okej - przyznaję się szczerze, że ja wymiękam po tym weekendzie z modyfikatorami...

 

Powyższy zapis AND w teorii wygląda okej ale nie działa tak jak powinien. Nazwa towaru to:

telefon gsm czerwony

 

Przypadek 1

W szablonie aukcji wstawiamy następujący kod:

{Blok=`czerwony_telefon`}ma się wstawić ten blok{/Blok}

[Towar::Nazwa|contains=`telefon`|then=`[Towar::Nazwa|contains=`czerwony`|then=`[szablon::Blok::czerwony_telefon]`|else=``]`|else=``]

Po wystawieniu towaru z tego szablonu generuje się takie coś

`|else=``]

Czyli powyższy kod AND nie działa

ALE PanBanBan potrafi dzięki swoim niezliczonym testom sprawić żeby zaczął działać czyli przypadek 2a i 2b

 

Przypadek 2a

W szablonie aukcji wstawiamy następujący kod. Czyli generujemy blok przed wyrażeniem AND

{Blok=`czerwony_telefon`}ma się wstawić ten blok{/Blok}

[Towar::Nazwa|contains=`telefon`|then=`[szablon::Blok::czerwony_telefon]`|else=``]
[Towar::Nazwa|contains=`telefon`|then=`[Towar::Nazwa|contains=`czerwony`|then=`[szablon::Blok::czerwony_telefon]`|else=``]`|else=``]

 

Po wystawieniu towaru z tego szablonu generuje się takie coś

ma się wstawić ten blok
ma się wstawić ten blok

Czyli nie wiedząc czemu jeśli w szablonie aukcji wcześniej wygenerujemy blok to wyrażenie działa, a jak nie wygenerujemy tego bloku to wyrażenie nie działa Możemy to zrobić również w sposób z przypadku 2b

 

Przypadek 2b

W szablonie aukcji wstawiamy następujący kod:

{Blok=`czerwony_telefon`}ma się wstawić ten blok{/Blok}

[szablon::Blok::czerwony_telefon]
[Towar::Nazwa|contains=`telefon`|then=`[Towar::Nazwa|contains=`czerwony`|then=`[szablon::Blok::czerwony_telefon]`|else=``]`|else=``]

 

Po wystawieniu towaru z tego szablonu generuje się takie coś

ma się wstawić ten blok
ma się wstawić ten blok

 

Nie wiem - może ilość przebiegów parsera ma tutaj znaczenie

Proszę - niechże ktoś to potwierdzi bo naprawdę wymiękam

 

W każdym razie przypadek 2a i 2b generuje się prawidłowo ale generuje 2 razy to samo więc w pierwszym wygenerowaniu bloku - ukrywamy go stosując hide czyli ostateczny zapis tego wyrażenia powinien wyglądać tak:

 

Przypadek 3

W szablonie aukcji wstawiamy następujący kod:

{Blok=`czerwony_telefon`}ma się wstawić ten blok{/Blok}

[Towar::Nazwa|contains=`telefon`|then=`[szablon::Blok::czerwony_telefon]`|hide|else=``]
[Towar::Nazwa|contains=`telefon`|then=`[Towar::Nazwa|contains=`czerwony`|then=`[szablon::Blok::czerwony_telefon]`|else=``]`|else=``]

 

Po wystawieniu towaru z tego szablonu generuje się takie coś

ma się wstawić ten blok

 

Czyli ostatecznie dałoby się zrealizować zapis AND ukrywając dodatkowe wygenerowania bloku ale dla konkretnego przypadku trzeba by przetestować wszystkie możliwe warianty. A powinno to działać tak jak zapisał Bartek, czyli bez tych dodatkowych generowań bloku...

[Bartosz Rosa 1 785]

A powinno to działać tak jak zapisał Bartek, czyli bez tych dodatkowych generowań bloku...

Powinno i tak będzie działać. Parser miał problem z poprawnym parsowaniem potrójnie zagnieżdżonych tagów .

[gawcio . 21]

Czy ma ktoś pomysł jak natomiast zrealizować operator OR?

 

Chodzi o to, że nie mogę realizować tego linijka pod linijką ponieważ w przypadku kiedy Klient zakupi dwa towary to wyświetlą się dwie wiadomość:

 

[Transakcja::ListaTowarow|contains=`towar1`|then=`[szablon::Blok::1]`|else=``]
[Transakcja::ListaTowarow|contains=`towar2`|then=`[szablon::Blok::1]`|else=``]

 

Chodzi o to aby użyć klasycznego OR czyli jeżeli w przesyłce znajduje się towar1 lub towar2 lub oba to wyświetli się blok1.

[PanBanBan Marcin 185]

Czy ma ktoś pomysł jak natomiast zrealizować operator OR?

 

Chodzi o to, że nie mogę realizować tego linijka pod linijką ponieważ w przypadku kiedy Klient zakupi dwa towary to wyświetlą się dwie wiadomość:

 

[Transakcja::ListaTowarow|contains=`towar1`|then=`[szablon::Blok::1]`|else=``]
[Transakcja::ListaTowarow|contains=`towar2`|then=`[szablon::Blok::1]`|else=``]

 

Chodzi o to aby użyć klasycznego OR czyli jeżeli w przesyłce znajduje się towar1 lub towar2 lub oba to wyświetli się blok1.

Też będę potrzebował coś podobnego ale nie miałem czasu tego przetestować.

 

Ja bym popróbował z:

-AND podanym przez Bartka,

-AND i negacją warunku,

-blokiem w bloku,

 

Na pewno da się to jakoś zrobić Niestety nie mam czasu żeby obecnie posiedzieć nad tym więc jak coś wykombinujesz to bym prosił o podanie Twojego sposobu, a jak nie to kiedyś się za to wezmę ale to raczej w maju...

[Bartosz Rosa 1 785]

Można spróbować takiego rozwiązania:

 

[Transakcja::ListaTowarow|contains=`towar1`|then=`[szablon::Blok::1]`|else=`[Transakcja::ListaTowarow|contains=`towar2`|then=`[szablon::Blok::1]`|else=``]`]

 

Na osłodę dodam, że w kolejnej wersji można będzie tagi pisać już wielu liniach, nawet rozdzielając je < br > i <p> .

 

ORy i ANDy też będziemy opracowywać, ale nie wiem czy w kolejnej wersji.