| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37848 |
7 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 |
10 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 |
11 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 |
11 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 |
11 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 |
11 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 |
19 d 7 h |
ranu |
/trunk/ |
aging po approval mail to some collected users |
|
| 37735 |
21 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 |
25 d 8 h |
ranu |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
rbm ranking mailer |
|
| 37686 |
25 d 8 h |
ranu |
/trunk/ |
for rbm ranking mail on month end |
|
| 37675 |
25 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 |
26 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 |
27 d 8 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 |
27 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 |
28 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. |
|
| 37613 |
28 d 23 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Receive internal transfer stock that was billed but never GRNed
Stock moved between our own warehouses is dispatched against an internal purchase order and
billed, but the destination warehouse still has to receive it by hand through the portal. Where
that never happened the units exist on an invoice and nowhere in inventory, and there is no way
to clear a backlog of them short of keying each invoice in again.
This adds a cron one-off that receives them. Per invoice it builds the rows the Excel GRN upload
would have carried and hands them to PurchaseOrderService.addPORowModels, which creates the
supplier invoice, the purchase and the inventory items in a single call, so none of receiving is
reimplemented here - the portal and this take the same path and can only ever agree.
It is deliberately narrow about what it will touch. Only INTERNAL buyers, because nothing should
be able to receive a partner's goods on their behalf. Only invoices with no supplier invoice
already recorded, so a repeat run skips what it has already done rather than receiving twice.
Only invoices resolving to a single purchase order, since addPORowModels resolves one order for
the whole map it is given and would otherwise attribute an invoice to the wrong one - for the
same reason each invoice is passed on its own. A serialized line whose serial number is missing
aborts its invoice instead of creating a unit no scan could ever match.
Each invoice commits or rolls back on its own, so one bad invoice cannot undo the ones already
received, and a dry run reports what it would receive without writing anything.
The receipt is recorded against the destination warehouse, which is what warehouse inventory is
keyed by. The buyer on the order is read only to confirm the store is internal; partner side
inventory is a separate receipt and is not touched. |
|
| 37602 |
30 d 11 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Remove no-op refreshSnapshotAgeing task; restore originalInventoryItemId backfill call
refreshSnapshotAgeing ran every 30 minutes aggregating warehouse.inventoryItem.rootInvoiceDate,
a column nothing ever wrote, so its UPDATE ... JOIN matched zero rows on every run and
currentinventorysnapshot.oldest_invoice_date was never populated on any of 11,686 rows.
Removed along with the sessionFactory field it was the only consumer of.
Application.java had migrations.migrateWarehouseOriginalInventoryItemId(batchSize) commented
out while still logging 'Starting migration...' and 'Migration completed.', so
--migrateOriginalInventoryItemId reported success while doing nothing. Restored the call;
it remains opt-in via the CLI flag and cannot fire on its own.
Requires profitmandi-dao r37601 (entity fields removed). |
|
| 37567 |
32 d 14 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Schedule the catalogue delist daily at 05:30
Runs 30 minutes before the existing 06:00 scheduledPushDataToSolr in the same
class, so the same morning's reindex publishes it. A bulk UPDATE fires no
TagListingChangeListener event, so without that ordering the portal would lag
until 18:00.
Gated on catalog.autoDelist.enabled with an inline default of true - env profiles
have no fallback between each other, so a key missing from one profile's
properties would otherwise stop the context booting.
Also exposes --delistDeadListings for a manual run, honouring the same flag. |
|
| 37510 |
41 d 7 h |
ranu |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
sales target and achievement added cron and flags |
|
| 37503 |
41 d 9 h |
ranu |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
sales target and achievement added cron and flags |
|