view · edit · sidebar · attach · print · history




  • Rapflag support for Poloniex must calculate correct balance
  • ODDB: Parse Swissmedic and lists
  • Keep in Mind



Rapflag support for Poloniex must calculate correct balance

The daily balance is not yet calculated correctly.

My commit of last week for poloniex got merged. No new gem version has been released however. Opened to ask for a new gem version.

When calling gem install rapflag the poloniex gem version 1.0.0 is installed, whereas bundle install says Using poloniex 1.0.2 from (at master@c777885). Therefore rapflag installed via gem install rapflag does not work. Till we get a new version of the poloniex gem we must use bundle exec bin/rapflag.

The following error in the calculation of the daily balances must be done.

  • Example is 2017-03-25.
  • the algo reads the Purchases wrongly.
    • the 22527.59 were GNT purchased for ~1 BTC sold not 22527.59 BTC purchased
    • Similarly line 14 wrongly reads 85.62 BTC Purchased when it should read ~44 XMR bought (and withdrawn from Poloniex (out to Bitfinex) same day)
    • and ~42 ZEC bought (and withdrawn from Poloniex same day).

Reason for the errors is that sales/purchases must be changed. Sales/purchases did not take into account the exchange rate.

Pushed commit Fix sales/purchases and use rate for trades. Issue 6 should be fixed if you pull the newest commit and run bundle exec bin/rapflag -p.

Pushed commits Create also dump files under output/poloniex and Fixed calculation of purchases. Used a + instead of * for rate, which fixed an embarrasing typo.

Pushed commit Calculate balance from start. Added some more fields

Comparing my output with the one given shows that my balance increase slower than the ones to be compared again. Where does these gains stem from?

ODDB: Parse Swissmedic and lists

We must parse the following list, which mention products which are not (or no longer) in stock

Later we must add a status icon red 🚦 with links to the corresponding list in the additional informatin between PI and name of preparation.

For parsing the list we must create a similar plugin as for the comarketing. Looking at the XLSX file from swissmedic. I think we should add the following information into the concerned registration

  • nomarketing_category: (Column E: Abgabekategorie) Found the following values A, A+, B, B/D, C, D, E.
  • nomarketing_date: (Column A Datum der Meldung)
  • nomarketing_since: (Column F Nicht-Inverkehrbringen ab)

There is an additional list with just 2 entries for the homeopathic and anthroposophic medicinal products without indication under Swissmedic: No marketing / interruption to distribution of authorized medicines. I think we will just ignore it for the moment.

The drugshortage list the concerned packages with are identified by their GTIN. They list 5 categories

  • ID Bewertung Art der Meldung
  1. Die Firma gibt ihre Daten selber ein und hat sich verpflichtet diese a jour zu halten (Exclusive Access) in der Regel Firmenmeldungen; möglicherweise sind die Produkte noch über Grossisten verfügbar.
  2. Die Firma versendet Updates an die Kunden; die Bewirtschaftung der Meldungen erfolgt durch in der Regel Firmenmeldungen; möglicherweise sind die Produkte noch über Grossisten verfügbar.
  3. Die Firma meldet vereinzelt Lieferengpässe an die Kunden Firmenmeldungen oder Meldungen aus dem Markt.
  4. Die Firma informiert die Kunden nicht (direkt) oder nur selektiv; Meldungen werden durch das Netzwerk generiert Firmenmeldungen oder Meldungen aus dem Markt.
  5. Verhandlungen laufen Firmenmeldungen oder Meldungen aus dem Markt.

For each package the following information is listed

  • Bezeichnung
  • GTIN
  • Pharmacode
  • Firma
  • Datum letzte Mutation
  • Tage seit erster Meldung
  • Status
  • Datum Lieferfähigkeit
  • mögliche Alternativen

The element also contain a link to the detailed informaition: Eg. I think this could be probably the only information we need to store as an additional method in the Package class.

Working now first on parsing the drugshortage, as it is the easier target. Here Zeno wants the content of the following fields of the details:

  • erste Meldung
  • Status des Engpasses
  • ca. Datum der Wiederherstellung der Lieferfähigkeit
  • Datum der letzten Mutation

Found an error in the list of drugshortage. The second preparation has an invalid GTIN (only 12 digits) 762860504332 for AEROCHAMBER PLUS inkl.Maske Erwachsene. Added a jobs/update_drugshortage. Running it locally.

view · edit · sidebar · attach · print · history
Page last modified on April 10, 2017, at 05:06 PM