Imagen,文本到圖像的擴散模型
Imagen, a text-to-image diffusion model
- 新聞連結: https://gweb-research-imagen.appspot.com/
- Hacker News評論連結: https://news.ycombinator.com/item?id=31484562
評論
9 歐元票
9-Euro-Ticket
評論
這些車票適用於所有“Nah- und Regionalverkehr”,明確排除 ICE、IC、EC(國際)和長途巴士(如慕尼黑和蘇黎世之間的巴士)
如果火車號以 RE 或 RB 開頭,那很好,但當然,那些是沿途每個村莊都會停的慢車。
這是為了生活在這裡並為 2 歐元 / 升燃料而苦苦掙扎的人們的利益,而不是那些輕率地支付 60 歐元來乘坐 ICE 的人。似乎沒有任何居住要求,但請記住,你不是這個的目標市場(除非你住在這裡並且正在為燃料價格而苦苦掙扎……)
我不知道這是否適用於城際交通,但對於城市內交通,例如 HVV(負責漢堡及周邊地區的公共交通網絡)每年售出 3000 萬張車票,我想知道他們真正要花多少錢使用上述所有相關因素來做到這一點。
這張票是德國議會簽署的支持方案的一部分。作為對不斷上漲的能源價格和由此產生的個人出行成本高昂的回應,該公司將支付約 25 億歐元的票價。
計費系統是工程師的噩夢
Billing systems are a nightmare for engineers
評論
如果你認為你認識他們,請關注https://twitter.com/aotearoa_ben/status/1526786701750050817 。
這是一項改變稅率的法律,如果
1. 購買發生在德克薩斯州。 2. 付款在特定的 2 天期限內結清。 3. 商品價格 < 100 美元。運費必須包含在商品的成本中。 4. 該項目屬於特定類別,幾乎可以肯定與您嘗試使用的任何分類系統都不匹配。
說真的,只舉一個例子, https://comptroller.texas.gov/taxes/publications/98-490/scho…指出只要符合條件的學校用品的成本,包含學校用品的套件就符合條件其中超過了不合格項目的成本。我保證您的會計系統中沒有該類別…
日期沒問題,一切都在月末、季度末或年末結算。
升級是降級簡化,客戶只能在預定義的日期/事件合法地更改關稅。
用法 – 是的,但文章中的示例甚至沒有涉及到這個的複雜性
冪等性並不是真正需要的,計費過程不是連續的,它是一個批處理作業。
現金收款不在計費軟件的範圍內。
徵稅很明確。是的,有多個不同稅率的計費項目,但不是太複雜。所有客戶都是當地人。
噩夢的部分是:
– 客戶可以有多個消費地點,地點可以有多個計價器,客戶可以要求在多張發票上拆分賬單或將多張賬單合併為一張發票
– 儀表可以隨時更換
– 儀表讀數可在完全獨立於計費周期的日期獲得。大多數消費數據只是預測。
– 當實際消耗數據可用時,必須重新計算並補償所有內容(在顯示差異的更正發票上)
– 實際消費數據可能是錯誤的,可能會在以後更正,甚至多次
– 消費積分可以隨時添加或刪除或移動到不同的客戶,但此信息僅在事後可用
– 對於某些客戶,價格可能會在結算週期中發生變化,但消費數據不可用該粒度
– 客戶法律信息(公司名稱、地址)可以在周期中更改
此外,它沒有提到金融監管的變化。印度在過去幾年的某個時候發生了變化,需要為印度客戶構建全新的系統。複雜性的一個例子是:該系統適用於在印度的客戶還是適用於在印度的企業(所有者可能不是)?
他也沒有提到欺詐,這基本上是未收回的支出,通常會導致退款。如果您收到過多的退款,您將被罰款。如果您收到更多退款,您將被踢出卡網絡,並且將不再能夠接受該網絡內的卡。
後付款(客戶獲得產品並隨後付款)模型會受到更多欺詐、未收費用等的影響。
與下游支付處理器打交道也很有趣。我還沒有與非常可靠的處理器或銀行合作過。有時他們會返回 500 個 http 代碼,然後處理付款,需要人工干預。有時,付款文件會發生這種情況,因為大多數銀行都會處理交易文件。