Subversion Repositories SmartDukaan

Rev

Show changed files | Details | Compare with Previous | Blame | RSS feed

Filtering Options

Rev Age Author Path Log message Diff
38009 10 h 42 m amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ chore(cron): drop CLI flags for removed one-time margin CN/DN remediation

Removes --corrMarginCNs, --genDNs, --genDNsForCNs, --cancelMarginDnIrns, --regenMarginIrns and
their ScheduledTasks wrappers; the CreditNoteService methods behind them were deleted in dao.
 
37995 2 d 7 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ fix(mail): rotate sdtech@smartdukaan.com Gmail app password

Old app password rejected with 535-5.7.8 BadCredentials since 2026-11-02 04:00;
all googleMailSender (smtp.gmail.com:465) mail failing. New password verified
(AUTH 235 Accepted) from the prod app server.
 
37938 14 d 8 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ Store status lifecycle: temporary activation expiry and weekly closure reminder

- checkPartnerActiveStore returns expired temporary activations to their previous status
(the old job failed with a NullPointerException on permanently active stores)
- Mondays 09:00: stores suspended for more than 7 days mailed to Neeraj with the other closers in CC
 
37933 14 d 11 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ feat(credit): --sendLoanDefaultBlockMails one-shot catch-up mail for current loan-default blocks (needs dao r37930)  
37918 17 d 8 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ Fixed mail sender everywhere  
37848 31 d 7 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ feat(warehouse): daily 10:00 mail of stock in suspended/inactive warehouses (--sendSuspendedWarehouseStockAlert for a one-off); Shopify sync warehouse from shopify.warehouseId (default 13372 HR-NSSPL/UPW) instead of WAREHOUSE_NAME_MAP UP-WEST/NOIDA  
37833 34 d 23 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ feat(cron): --retryIrn re-files rejected e-invoices after their data is corrected - reset and filing in one transaction so the scheduled IRN job cannot race it  
37832 35 d 0 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ feat(cron): --closeMovementPO closes movement POs the way the PO screen's Close does (refund live orders, preclose); dry run by default  
37828 35 d 1 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ fix(cron): movement billing looks POs up inside a transaction (driver has none - 'Could not obtain transaction-synchronized Session'); failure message no longer claims nothing was raised  
37827 35 d 2 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ feat(cron): --autoCreateMovementPO raises an internal movement PO from an upload file as the operator; dry run previews every PO, line, price and origin; --bill dry-runs billing of the raised POs  
37825 35 d 2 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ feat(cron): --autoBillMovement bills internal movement POs (dry run by default)

Bills the orders a movement PO raised the way the order management screen does:
orders parked on the Dummy (brand without a source mapping) are re-pointed to the
source vendor warehouse holding the stock (split when it spans several), serialized
units take IMEIs oldest first at qty 1 with a good last scan, then acceptOrders ->
addBillingDetailsForGrouppedOrders -> checkOrderDispatchEligibility, one invoice per
transaction, all-or-nothing. IRN / e-way bill follow from the existing cron job.

Usage: --autoBillMovement --pos=PO1,PO2 --email=<operator> --provider=<id> [--live]
Dry run (default) plans and validates only - billing opens its own REQUIRES_NEW
transaction (createLoanForBilling) that a rollback would not undo. Refuses a
transaction over 900 invoice lines (NIC caps an IRN at 1000). Prints the invoice
list for --autoGrnInternal.
 
37751 43 d 7 h ranu /trunk/ aging po approval mail to some collected users  
37735 45 d 13 h amit /trunk/profitmandi-cron/src/main/ Remove dead third-party integrations: cron

- Toffee: attachToffeeInvoices (schedule already commented out), toffeeRollback
and the --tc option; tofee.* keys in run.properties
- Bharti Assist: sendBAGPendingPolicies, testBag/mapBag and the --bag /
--mapbag options
- HyperTrack geofence one-offs (--createGeofence, --getAllGeofences,
--deleteGeofences) and their hardcoded account keys
- SmartPing injection in ScheduledTasks; leftover DTDC comment
- aramex.tracking.url in run.properties
 
37687 49 d 8 h ranu /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ rbm ranking mailer  
37686 49 d 8 h ranu /trunk/ for rbm ranking mail on month end  
37675 49 d 11 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ Remove the dead Samsung and Amazon Selenium paths

Both were manual one-shots that nothing runs any more, and each started an
850MB chrome tree that now has to queue on the browser lane, so they are cost
without a caller.

Evidence they are dead rather than merely idle:
- No crontab entry, no cron.d file and no script references --samsung or
--amazonPurchase, and neither flag appears even once in cron.log.
- fofo.activated_imei has ZERO Samsung rows written by the cron (auth_id 0) in
the last 90 days. All 2,331 Samsung rows in that window are auth_id 307, i.e.
the human CSV upload, most recently 16-Sep. The scraper is not what keeps
Samsung current; people are.
- ScheduledSkeleton.fetchImeiActivation() had already been retired in place --
its @Scheduled was commented out with 'No longer scheduled'.
- RunOnceTasks.amazonPurchase() reads /Users/amit/Downloads/amazon.xlsx, a
laptop path that cannot exist on the server.

Removed: SamsungIMEIActivationService, the whole scheduled/amazon package
(AmazonPurchaseService, OrderSummary, OrderRow, AmazonUser), their RunOnceTasks
callers and helpers (fetchImeiActivation, amazonPurchase, getOrderSummary,
parseRow), the two Application CLI blocks and the retired ScheduledSkeleton
wrapper. The amazon package had no importers outside RunOnceTasks.

Both also leaked a chrome profile dir on every run -- AmazonPurchaseService
never called quit() at all, and SamsungIMEIActivationService called it outside
any finally -- so this removes two leak sources rather than fixing them.

Untouched: RunOnceTasks.mailDashboardScreenshots() is a third dead Selenium
one-shot (also zero invocations) but it mails a report, so it is left for a
separate decision.
 
37658 50 d 9 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ Remove Mandii onboarding tasks from cron (r37655)

RunOnceTasks loses mandiiUser/mandiiUsers, their setCreditAccount helper and
the now-unused encodeFileToBase64Binary, plus the MandiiService autowire -
133 lines that pushed partner KYC into Mandii and wrote back MANDII credit
accounts. The matching --mandiiUser / --mandiiUsers CLI options are dropped
from Application. ScheduledTasks had an unused MandiiService field.
OnBoardingRelatedSchelduleTask imports follow services.mandii -> services.kyc.
 
37636 51 d 9 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ refactor(cron): remove vendoritempricing one-offs; log catalog migration listing prices

- Remove migrateVendorItemPricing (2023 one-off) and its flag; fixOrders no longer reads vendoritempricing
- CatalogMigration sets listing prices via TagListingPriceService
 
37631 51 d 13 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ feat(mail): wire inactive-recipient filter, clean addresses, remove attendance alerts

Wire MailRecipientFilter into both mail senders. Remove inactive hardcoded recipients, fix typo addresses, send market-share reminder to tech@. Delete sendAttendanceMorningAlert/EveningAlert, sendMailToHR and their CLI options.
 
37617 52 d 20 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ Undo an internal GRN so its invoice can be received again

A receipt taken before the serials were split left stock that cannot be corrected in place: a
serialised unit is held one to a row, so an invoice that should have created several rows created one,
and the rows that are missing cannot be added without also unpicking the running figures the receipt
moved. Reversing the receipt and taking it again through the same path is the only way to arrive at
what the invoice actually says.

The reversal removes what receiving created - the scans, the inventory units, the invoice items, the
purchase and the supplier invoice - and gives back the two running figures it moved: the warehouse
availability, and the quantity taken off the purchase order line. Both are worked out from the rows
being deleted rather than recomputed, so whatever the receipt added is exactly what comes off. A
purchase order the receipt closed is opened again. Availability is kept only as a running count with
nothing to rebuild it from, which is why it is adjusted by what is known to have been added rather
than by anything inferred.

An invoice whose stock has moved since is refused, not worked around. A unit that has been scanned out
or partly consumed is no longer the receipt's to remove, and deleting around it would leave the
warehouse holding stock that no record explains. Each invoice is reversed on its own so one refusal
leaves the rest untouched, and a dry run reports everything it would delete and every figure it would
change without writing.

Invoices are named explicitly rather than selected by date, so a reversal can only ever touch what it
was given.
 

Show All