lms
lms copied to clipboard
chilek
Weryfikacja lms-payments.php
Czy nowa funkcja jest związana z jakimś problemem? Prosimy opisać.
Nie mamy pewności czy lms-payments.php wystawia faktury dla wszystkich zobowiązań.
Opisz swoją propozycję rozwiązania Proponuję:
- do tabeli
invoicecontentsdodaćassignmentidi powiązać kluczem zassignments.id- na tej podstawie moglibyśmy później weryfikować pracęlms-payments.phpi porównywać ilość wystawionych pozycji do ilości zobowiązań, - uzupełniać wartość
assigmnmentidskryptemlms-payments.phppodczas wystawiania faktur,
Dzięki temu uzyskalibyśmy również powiązanie zobowiązania(identyfikatora usługi) względem pozycji na fakturze i mielibyśmy dane do diagnozy.
@chilek ma to sens?
Nie mamy pewności czy
lms-payments.phpwystawia faktury dla wszystkich zobowiązań.
No jak nie ma pewności - przedział lms-payments.php od 27.0 działa już transakcyjnie.
Choć na pewno komunikaty w terminalu mogą stanowić zmyłkę, bo nawet jak, któreś zapytanie w transakcji wywali się-, to i tak kontynuuje pracę wyświetlając fałszywe informacje w terminalu.
Trzeba zastanowić się nad sposobem pozbycia się tej zmyłki - jeden z pomysłów jaki mi przychodzi teraz do głowy - sprawdzać po kluczowych zapytaniach SQL, czy nie zwracają błędów (LMSDB::Execute() z INSERT INTO i UPDATE zwracają liczbę wstawionych/zaktualizowanych rekordów, więc możliwe, że to jest jakiś punkt zaczepienia).
Dodam, że chodzi o spojrzenie bardziej całościowe na cały mechanizm. Obecnie nie ma możliwości porównania ilościowego pozycji faktur do zobowiązań po przebiegu skryptu.
Z drugiej strony patrząc na to - takie powiązanie nie powinno zaszkodzić prawda?
Chodzi tutaj o błędy bardziej niezwiązane z kodem np.
- dodało się zobowiązanie z "0" w kolumnie ilość,
- ustawiłem omyłkowo "bez faktury", etc etc etc
Nie wnikając w przyczynę błędu chciałbym wiedzieć najwcześniej jak to możliwe że on wystąpił - właśnie porównując ilość.
Trzeba zastanowić się nad sposobem pozbycia się tej zmyłki - jeden z pomysłów jaki mi przychodzi teraz do głowy - sprawdzać po kluczowych zapytaniach SQL, czy nie zwracają błędów (LMSDB::Execute() z INSERT INTO i UPDATE zwracają liczbę wstawionych/zaktualizowanych rekordów, więc możliwe, że to jest jakiś punkt zaczepienia).
A może wariantowo: a) najpierw generować wszystkie zapytania SQL i ładować je do bazy jedną transakcją b) użyć dostępnych od postgresa 8.0 zagnieżdzonych transakcji ?
Chodzi tutaj o błędy bardziej niezwiązane z kodem np.
- dodało się zobowiązanie z "0" w kolumnie ilość,
Da się faktycznie dodać z ilością "0"? Jeśli tak to chyba to jest błąd walidacji?
- ustawiłem omyłkowo "bez faktury", etc etc etc
Nie wnikając w przyczynę błędu chciałbym wiedzieć najwcześniej jak to możliwe że on wystąpił - właśnie porównując ilość.
Trzeba zastanowić się nad sposobem pozbycia się tej zmyłki - jeden z pomysłów jaki mi przychodzi teraz do głowy - sprawdzać po kluczowych zapytaniach SQL, czy nie zwracają błędów (LMSDB::Execute() z INSERT INTO i UPDATE zwracają liczbę wstawionych/zaktualizowanych rekordów, więc możliwe, że to jest jakiś punkt zaczepienia).
A może wariantowo: a) najpierw generować wszystkie zapytania SQL i ładować je do bazy jedną transakcją b) użyć dostępnych od postgresa 8.0 zagnieżdzonych transakcji ?
Da się faktycznie dodać z ilością "0"? Jeśli tak to chyba to jest błąd walidacji?
W jakiś sposób się się da - ale nie potrafię tego odtworzyć niestety na tą chwilę. Dla tego konkretnego problemu zrobiłem sobie mailowy raportownik - jak wystąpi ponownie będę o tym wiedział i usunę błąd.
Nie jest aż tak ważne jak to, żeby wiedzieć czy taka sytuacja wystąpiła i dla jakiego zasobu - z biegiem czasu przerobiliśmy już kilka dziwnych rzeczy których istotę ciężko było namierzyć od razu a po analizie zbiorczej danych już tak (np. mega brzydki problem we wtyczce billtecha, który kasował nie te wpisy z tabeli cash co powinien)