Weryfikacja lms-payments.php

[interduo]

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 invoicecontents dodać assignmentid i powiązać kluczem z assignments.id - na tej podstawie moglibyśmy później weryfikować pracę lms-payments.php i porównywać ilość wystawionych pozycji do ilości zobowiązań,
• uzupełniać wartość assigmnmentid skryptem lms-payments.php podczas 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?

[chilek]

Nie mamy pewności czy lms-payments.php wystawia 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).

[interduo]

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?

[interduo]

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 ?

[chilek]

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 ?

[interduo]

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)